हर कुछ साल में कोई नई प्रोग्रामिंग भाषा इस वादे के साथ सामने आती है कि वह उस पुराने समझौते को खत्म कर देगी, जिसने चुपचाप यह तय किया है कि सॉफ्टवेयर कैसे बनता है। जूलिया ऐसी ही एक भाषा है। इसे इस तरह डिज़ाइन किया गया कि यह पायथन जितनी आसानी से लिखी जा सके, लेकिन C जितनी तेज़ भी हो। यह वह मेल था जो दशकों से वैज्ञानिकों, इंजीनियरों और शोधकर्ताओं को खलने वाली एक दरार को भरने के लिए सोचा गया था। सामने आने के इतने साल बाद भी जूलिया पायथन की जगह नहीं ले पाई, और सच कहें तो इसके आसपास भी नहीं पहुंची। लेकिन इसकी वजह किसी सीधी-सादी नाकामी की कहानी से कहीं ज़्यादा दिलचस्प है।
वे लेख जिन्होंने प्रोग्रामरों की सोच गढ़ी
कंप्यूटिंग की दुनिया के कुछ लेख आज भी घोषणापत्र जैसे पढ़े जाते हैं। जॉन बैकस के 1977 के निबंध "कैन प्रोग्रामिंग बी लिबरेटेड फ्रॉम द वॉन न्यूमैन स्टाइल?" ने एक बिलकुल नई सोच को जन्म दिया और हास्केल जैसी फंक्शनल भाषाओं की नींव रखने में मदद की। कुछ लेख चेतावनी की तरह हैं। केन थॉम्पसन ने 1984 के अपने लेख "रिफ्लेक्शंस ऑन ट्रस्टिंग ट्रस्ट" में दिखाया कि किसी कंपाइलर में चुपके से पिछला दरवाज़ा कैसे बैठाया जा सकता है, और इस एक प्रदर्शन ने शायद अनगिनत सुरक्षा खामियों को पनपने से रोक दिया। एड्सगर डायक्स्ट्रा ने 1972 के अपने लेख "द हंबल प्रोग्रामर" में साथी कोडरों से कहा कि वे अपनी ही चतुराई पर भरोसा न करें और "इंसानी दिमाग की बुनियादी सीमाओं" को स्वीकार करें।
यहां सबसे अहम है केनेथ आइवरसन का 1979 का गहरा और महत्वाकांक्षी व्याख्यान, "नोटेशन ऐज़ अ टूल ऑफ थॉट"। आइवरसन का कहना था कि गणितीय नोटेशन सिर्फ लिखने का छोटा रास्ता नहीं है, जैसे कार्बन डाइऑक्साइड के लिए CO2 या MMMDCCCLXXXVIII की जगह 3,888। अच्छा नोटेशन नई अंतर्दृष्टियों तक पहुंचना भी आसान बना देता है। गणितज्ञ अल्फ्रेड नॉर्थ व्हाइटहेड ने इसे बहुत पहले यूं कहा था: "एक अच्छा नोटेशन दिमाग को हर गैरज़रूरी काम से मुक्त करके उसे और ऊंची समस्याओं पर ध्यान लगाने के लिए आज़ाद कर देता है।"
दो भाषाओं का काम एक ही भाषा से
आइवरसन को उनका ट्यूरिंग अवॉर्ड APL के लिए मिला, एक अजीब-सी दिखने वाली भाषा जिसकी शुरुआत दरअसल अलग-अलग भाषाओं के बीच पुल बनाने वाली एक नोटेशन प्रणाली के तौर पर हुई थी। वैज्ञानिक कंप्यूटिंग के शुरुआती दौर में प्रोग्रामरों को एक भाषा यानी गणितीय नोटेशन में सोचना पड़ता था, लेकिन प्रोग्राम किसी दूसरी भाषा में लिखना पड़ता था, जैसे फोरट्रान में। APL को इस तरह बनाया गया कि बड़े और बोझिल ऑपरेशन समीकरणों जितने संक्षेप में लिखे जा सकें, कोड की पूरी-पूरी लाइनें सिमटकर + या × जैसे एक-दो चिह्नों में बदल जाएं। आखिरकार APL जितनी अपनाई गई, उससे कहीं ज़्यादा प्रभावशाली साबित हुई, पर इससे कोई फर्क नहीं पड़ता। वह अपनी बात साबित कर चुकी थी: दो भाषाओं को एक में मिलाया जा सकता है।
यही गुत्थी उस समस्या के केंद्र में है जिसे "दो भाषाओं की समस्या" कहा जाता है। शोधकर्ता अपना पहला मॉडल धीमी लेकिन सहूलियत भरी पायथन में बनाते हैं, फिर जहां रफ्तार सबसे ज़रूरी होती है, उन हिस्सों को C++ या रस्ट जैसी तेज़ पर कम मिलनसार भाषाओं में दोबारा लिखते हैं। AI कोडिंग एजेंटों की पूरी फौज भी इस दिक्कत को दूर नहीं कर सकती, क्योंकि आप किसी धीमी भाषा को चाहे जितना निखार लें, एक सचमुच तेज़ भाषा उसे फिर भी पीछे छोड़ देगी।
यह अदला-बदली हर जगह मौजूद है
ऐसी "यह लो या वह" वाली सौदेबाज़ी सॉफ्टवेयर से कहीं आगे भी दिखती है। मिसाल के तौर पर, निर्माण के क्षेत्र में एक तरह की "दो सामग्रियों की समस्या" है। किसी ढांचे का शुरुआती नमूना बनाने के लिए लकड़ी बेहद लचीली सामग्री है, एक नौसिखिया भी आरी और कील से ऐसी इमारत जोड़ सकता है जो टिकी रहे। लेकिन गगनचुंबी इमारत खड़ी करने में यह किसी काम की नहीं। इससे एक सीधा सवाल उठता है: अगर कोई ऐसी सामग्री हो जो लकड़ी जितनी आसानी से गढ़ी जा सके पर स्टील जितनी मज़बूत हो तो? या कोड की भाषा में कहें तो, कोई ऐसी भाषा जो पायथन जितनी सहज हो पर C जितनी तेज़?
यही सपना जूलिया के रचनाकारों ने पूरा करने की ठानी। उन्होंने खुद को बड़े फैलाव से बयां किया: मैटलैब के मंझे हुए इस्तेमालकर्ता, लिस्प के जानकार, पायथन के दीवाने, रूबी और पर्ल के शौकीन, जिन्होंने अपने ही कहे मुताबिक किसी भी समझदार इंसान से कहीं ज़्यादा R प्लॉट बना डाले थे, और जो अपनी सबसे प्रिय भाषा के तौर पर C का नाम लेते। उन्होंने लिखा कि इनमें से हर भाषा "काम के कुछ पहलुओं के लिए बिलकुल सटीक है और कुछ के लिए बेहद खराब।" वे चाहते थे "एक ऐसी भाषा जो ओपन सोर्स हो, उदार लाइसेंस के साथ," कुछ ऐसा जो "सीखने में बेहद आसान हो, फिर भी सबसे गंभीर हैकरों को खुश रखे।" जूलिया को वही एक भाषा बनना था जो इन सबको जोड़ दे।
एक भाषा, जिसका चेहरा अपनापन लिए था
बहुत से लोगों की नज़र में जूलिया 2017 में आई, इसके सिंटैक्स के स्थिर होने से एक साल पहले, सेबेस्टियन सियुंग के व्याख्यानों के ज़रिए। सियुंग एक न्यूरोसाइंटिस्ट हैं जो इसका इस्तेमाल कनेक्टोम, यानी दिमाग में तंत्रिका मार्गों के पूरे नक्शे को उतारने में कर रहे थे। पहली चीज़ जो ध्यान खींचती थी, वह बस इसका नाम था, इस क्षेत्र में, जहां भद्दे नामों की भरमार है, यह प्यारा और अपना-सा लगता था: बेढंगी PL/I, भद्दी अर्लंग, टाइपिंग में असहज C++, और सिरे से रोगमय MUMPS, जो हैरानी की बात है कि आज भी अमेरिकी स्वास्थ्य सेवा प्रणाली की रीढ़ बनी हुई है।
इस सुहावने नाम के नीचे असली डिज़ाइन-अनुशासन छिपा था। जूलिया के रचनाकारों ने उन तमाम जालों का अध्ययन किया था जिनमें दूसरी भाषाएं फंसती रही थीं, और फिर पूरे क्षेत्र से बेहतरीन विचार बटोरे, यह याद दिलाते हुए कि नई भाषा गढ़ने जैसे नाज़ुक काम से पहले गहरी पड़ताल ज़रूरी है।
तो फिर इसने पायथन की जगह क्यों नहीं ली?
इसके बावजूद जूलिया स्टैक ओवरफ्लो के सबसे लोकप्रिय भाषाओं वाले सालाना चार्ट में नज़र नहीं आती। इसने पायथन की जगह नहीं ली, आसपास भी नहीं। इसकी वजहें तीन हिस्सों में हैं। पहली, कोई प्रोग्रामिंग भाषा भी इंसानी भाषा की तरह उतनी ही मज़बूत होती है जितना उसमें रचा गया काम, यानी उसका इकोसिस्टम और टूलिंग। पायथन का दायरा इतना विशाल है कि उसे हिलाना नामुमकिन है। दूसरी, जूलिया को बिग टेक का साथ कभी नहीं मिला। इतिहास गवाह है कि जब कोई गुमनाम भाषा अचानक शिखर तक पहुंची, तो उसके पीछे किसी बड़ी कंपनी की सरपरस्ती थी: एपल ने iOS विकास के लिए ऑब्जेक्टिव-C को आगे बढ़ाया, गूगल ने एंड्रॉयड के लिए कोटलिन को।
तीसरी वजह सबसे अहम है और यह पूरे सवाल को ही पलट देती है: दरअसल कुछ गलत हुआ ही नहीं। जूलिया एक सीमित दायरे वाली भाषा है, और जो काम वह करती है, उसके लिए वह बखूबी सफल है। पूरी संभावना है कि यह आगे भी बनी रहेगी, छोटी पर सच में चहेती। यह पहले से ही ASML, CERN और नासा जैसे संस्थानों में, और दवा खोज व उन्नत मशीन लर्निंग जैसे गंभीर कामों में मुश्किल जिम्मेदारियां संभाल रही है।
वह समस्या, जिसे शायद कोई भाषा हल न कर पाए
अगर जूलिया किसी दिन पायथन की जगह ले भी ले, तो यह मानने की ठोस वजह नहीं है कि वह "दो भाषाओं की समस्या" को आखिरकार सुलझा देगी, या कोई भी भाषा ऐसा कर पाएगी। यह जुमला भले वैज्ञानिक कंप्यूटिंग में सबसे ज़्यादा उछाला जाता हो, पर यही दरार सॉफ्टवेयर के हर कोने में मौजूद है। गेमिंग में इंजन C++ में लिखे जाते हैं पर उनकी स्क्रिप्टिंग लुआ में होती है। सर्वर बैकएंड पर पायथन, रूबी और जावास्क्रिप्ट जैसी आसान भाषाओं की भीड़ रोज़मर्रा का काम संभालती है, जबकि जहां असली रफ्तार चाहिए, वहां जिम्मेदारी गो या रस्ट पर आ जाती है। इसे उलट दें तो भी पैटर्न वही रहता है: गो या रस्ट में फ्रंटएंड बनाने की गंभीर कोशिशें पूरी तरह नाकाम रही हैं।
इसका मतलब यह नहीं कि यह दीवार हमेशा के लिए है। हो सकता है भविष्य में आइवरसन जितना पैना कोई सोचने वाला आखिरकार इस खाई को हमेशा के लिए पाटने का रास्ता निकाल ले। जिस दिन ऐसा होगा, उनके ट्यूरिंग लेक्चर को सुनना वाकई फायदे का सौदा होगा।
