वैकल्पिक कार्यान्वयन की समस्या (Alternative Implementation Problem)

वैकल्पिक कार्यान्वयन की समस्या

लेखक सॉफ़्टवेयर दुनिया में बार-बार सामने आने वाली वैकल्पिक कार्यान्वयन की समस्या पर बात करते हैं। लेखक का अनुभव मुख्यतः dynamic typed programming languages को optimize करने का रहा है।

• PyPy प्रोजेक्ट ने Python के लिए एक उन्नत JIT compiler विकसित किया, लेकिन व्यवहार में इसका लगभग उपयोग नहीं हुआ। Python लगातार नई features जोड़ता रहा, इसलिए PyPy के लिए उसके साथ तालमेल बिठाना कठिन था.
• LuaJIT को बहुत सराहा जाता है, लेकिन Lua भाषा लगातार नई features जोड़ती रही, जिसके कारण LuaJIT कई versions पीछे रह गया.
• TruffleRuby JIT ने सबसे प्रभावशाली performance दिखाई, लेकिन CRuby की तुलना में feature compatibility की कमी के कारण इसका deployment सीमित रहा.

सबक: वैकल्पिक कार्यान्वयन लगभग अनिवार्य रूप से असफल होने वाला विकल्प है

• यदि आप एक वैकल्पिक कार्यान्वयन बनाते हैं, तो आप आधिकारिक implementation के बदलावों पर निर्भर होने से बच नहीं सकते.
• आधिकारिक implementation परियोजना की दिशा को नियंत्रित करता है, और वैकल्पिक implementation को बस उसका पीछा करना पड़ता है.
• पारंपरिक रूप से, interpreted languages के लिए JIT implementation बनाते समय, interpreter में नई features जोड़ना कहीं अधिक तेज़ होता है, इसलिए आधिकारिक implementation, JIT से आगे निकल सकता है.

YJIT: CRuby के भीतर Ruby JIT compiler का कार्यान्वयन

• YJIT भी एक Ruby JIT है, लेकिन इसे CRuby के भीतर ही implement करने का निर्णय लिया गया.
• इसके कारण YJIT शुरुआत से ही CRuby की सभी features के साथ 100% compatible हो सका.
• अब यह Ruby का आधिकारिक JIT बन चुका है और Shopify, Discourse, GitHub आदि में deploy किया जा रहा है.

व्यापक दृष्टिकोण से सबक

• Crystal भाषा, जो मौजूदा भाषाओं जैसी दिखती है लेकिन compatible नहीं है, उसे भी केवल सीमित सफलता मिली.
• जो चीज़ मौजूदा भाषा जैसी दिखे लेकिन compatible न हो, वह लोगों को केवल भ्रमित करती है.
• नई programming language बनाते समय, किसी मौजूदा भाषा का subset बनने की कोशिश करने के बजाय अपना अलग रास्ता चुनना बेहतर है.
• तभी आप दूसरी implementations की performance, features या libraries से बंधे बिना अपनी गति और अपनी दिशा में विकसित हो सकते हैं.

GN⁺ की राय

• इस लेख में वर्णित 'वैकल्पिक कार्यान्वयन की समस्या' केवल programming languages ही नहीं, बल्कि विभिन्न software और hardware systems बनाते समय भी ध्यान रखने योग्य बात है.
• यदि ध्यान केवल stability और compatibility पर रहे, तो innovation कठिन हो सकता है. लेकिन वास्तविक users के नज़रिये से compatibility एक बहुत महत्वपूर्ण तत्व है. नई तकनीक और user-friendliness के बीच संतुलन बनाना महत्वपूर्ण है.
• दीर्घकालिक दृष्टि से, किसी नए project को बनाते समय यह पर्याप्त रूप से सोचना ज़रूरी है कि वह 'किसके साथ compatible है' और 'उसे किस दिशा में विकसित करना है'.
• नई programming language बनाते समय, केवल किसी मौजूदा भाषा का syntax मिलता-जुलता बना देना भ्रम ही बढ़ाता है. इसके बजाय अपनी स्पष्ट philosophy और direction रखना अधिक उचित है.
• बाज़ार में प्रतिस्पर्धा करने से अधिक, रचनात्मक और मौलिक solutions प्रस्तुत करना दीर्घकाल में सफलता की संभावना बढ़ाता हुआ लगता है.

[GN⁺]

Hacker News की राय

• जब किसी नए alternative implementation को विकसित करते समय उसकी architecture मौजूदा version से अलग हो, तो जो चीज़ें पुराने version में आसान थीं, वे नए version में बहुत कठिन हो सकती हैं। उदाहरण के लिए, अगर proprietary software section unit पर load/save करता है, जबकि नया version पूरे document को memory में लोड करता है, तो attachment जोड़ने की सुविधा देने के लिए नए version की पूरी architecture बदलनी पड़ सकती है.
• किसी मौजूदा implementation के alternative के रूप में खुद को position करना अक्सर हारने वाला प्रस्ताव होता है। "Python + X" के रूप में marketing करने वाले project के लिए official version से प्रतिस्पर्धा करना मुश्किल होता है। लेकिन अगर MicroPython की तरह उसे microcontroller के लिए design किया गया हो, और वह CPython से प्रतिस्पर्धा करने के बजाय दूसरे microcontroller programming environment से प्रतिस्पर्धा करे, तो वह सफल हो सकता है.
• Compatibility के दावों के बावजूद, व्यवहार में पुराने language features के लिए भी compatibility अक्सर कम होती है, और यही alternative implementation के असफल होने का कारण बनता है। Ruby और Python के मामले में native C extension के लिए support की कमी इसका उदाहरण है.
• Startup शुरू करने के अनुभव के अनुसार, बुनियादी features का पीछा करने के बजाय यह दिखाना चाहिए था कि architecture enterprise features को support कर सकती है, और किसी स्पष्ट differentiator पर ध्यान देना चाहिए था.
• Developers, JIT से अधिक language features और interoperability को महत्व देते हैं। मौजूदा project में योगदान देने की बजाय अपना parallel project बनाना आसान होता है, लेकिन यह पूछना चाहिए कि वह आखिर किसके लिए है। आत्ममुग्धता में फँसने से बचना चाहिए.
• Wrapper code standard से भटक जाता है और documentation की कमी के कारण तकलीफ़ पैदा करता है। केवल वही features जोड़ना बेहतर है जो सच में ज़रूरी हों, और defaults का उपयोग करना चाहिए.
• यह MySQL compatibility की वजह से TiDB को हुई समस्याओं जैसा है। सिद्धांत में यह open protocol है, लेकिन व्यवहार में Chrome इसका नेतृत्व करता है.
• Kotlin का कोई उल्लेख नहीं था.