सौ साल की भाषा

अप्रैल 2003

(यह निबंध PyCon 2003 में दिए गए एक मुख्य भाषण से लिया गया है।)

सौ साल में जीवन कैसा होगा, इसका अनुमान लगाना मुश्किल है। कुछ बातें ही हैं जिनके बारे में हम निश्चित रूप से कह सकते हैं। हम जानते हैं कि हर कोई उड़ने वाली कारें चलाएगा, ज़ोनिंग कानूनों को ढीला कर दिया जाएगा ताकि सैकड़ों मंजिलों वाली इमारतों की अनुमति मिल सके, ज़्यादातर समय अंधेरा रहेगा, और सभी महिलाओं को मार्शल आर्ट की ट्रेनिंग दी जाएगी। यहाँ मैं इस तस्वीर के एक विवरण पर ज़ूम करना चाहता हूँ। वे उन उड़ने वाली कारों को नियंत्रित करने वाले सॉफ़्टवेयर को लिखने के लिए किस तरह की प्रोग्रामिंग भाषा का उपयोग करेंगे?

इसके बारे में सोचना इसलिए ज़रूरी है क्योंकि हम वास्तव में इन भाषाओं का उपयोग करेंगे, बल्कि इसलिए कि अगर हम भाग्यशाली हैं, तो हम इस बिंदु से उस बिंदु तक जाने वाले रास्ते पर भाषाओं का उपयोग करेंगे।

मुझे लगता है कि प्रजातियों की तरह, भाषाएँ भी विकासवादी वृक्ष बनाएँगी, जिसमें हर जगह से मृत-अंत शाखाएँ निकलती रहेंगी। हम यह पहले से ही देख सकते हैं। कॉबोल, अपनी कभी-कभी लोकप्रियता के बावजूद, कोई बौद्धिक वंशज नहीं रखता है। यह एक विकासवादी मृत-अंत है - एक नीएंडरथल भाषा।

मैं जावा के लिए भी इसी तरह के भाग्य की भविष्यवाणी करता हूँ। लोग कभी-कभी मुझे मेल भेजते हैं, "आप कैसे कह सकते हैं कि जावा एक सफल भाषा नहीं होगी? यह पहले से ही एक सफल भाषा है।" और मैं मानता हूँ कि यह है, अगर आप सफलता को उस पर लिखी गई पुस्तकों द्वारा लिए गए शेल्फ स्पेस (विशेषकर उस पर व्यक्तिगत पुस्तकों द्वारा) या उन अंडरग्रेजुएट की संख्या से मापते हैं जो मानते हैं कि उन्हें नौकरी पाने के लिए इसे सीखना होगा। जब मैं कहता हूँ कि जावा एक सफल भाषा नहीं होगी, तो मेरा मतलब कुछ और विशिष्ट है: कि जावा एक विकासवादी मृत-अंत बन जाएगा, जैसे कॉबोल।

यह सिर्फ एक अनुमान है। मैं गलत हो सकता हूँ। मेरा यहाँ उद्देश्य जावा को नीचा दिखाना नहीं है, बल्कि विकासवादी वृक्षों के मुद्दे को उठाना है और लोगों को यह पूछने के लिए प्रेरित करना है कि भाषा X वृक्ष पर कहाँ है? यह सवाल पूछने का कारण सिर्फ यह नहीं है कि हमारे भूत, सौ साल बाद, कह सकें, मैंने आपको बताया था। ऐसा इसलिए है क्योंकि मुख्य शाखाओं के करीब रहना उन भाषाओं को खोजने के लिए एक उपयोगी अनुमान है जो अभी प्रोग्राम करने के लिए अच्छी होंगी।

किसी भी समय, आप शायद एक विकासवादी वृक्ष की मुख्य शाखाओं पर सबसे खुश होते हैं। जब भी नीएंडरथल अभी भी बहुत सारे थे, नीएंडरथल होने में बहुत बुरा होना चाहिए था। क्रो-मैग्नन लगातार आते रहते थे और आपको पीटते रहते थे और आपका खाना चुराते रहते थे।

मैं जानना चाहता हूँ कि सौ साल में भाषाएँ कैसी होंगी, इसका कारण यह है कि मुझे पता है कि अब मुझे पेड़ की किस शाखा पर दांव लगाना चाहिए।

भाषाओं का विकास प्रजातियों के विकास से अलग है क्योंकि शाखाएँ अभिसरण कर सकती हैं। उदाहरण के लिए, फोरट्रान शाखा, एल्गोल के वंशजों के साथ विलय होती हुई प्रतीत होती है। सिद्धांत रूप में यह प्रजातियों के लिए भी संभव है, लेकिन यह कोई भी कोशिका से बड़ा होने की संभावना नहीं है।

अभिसरण भाषाओं के लिए अधिक संभावना है क्योंकि आंशिक रूप से संभावनाओं का स्थान छोटा है, और आंशिक रूप से क्योंकि उत्परिवर्तन यादृच्छिक नहीं हैं। भाषा डिजाइनर जानबूझकर अन्य भाषाओं से विचारों को शामिल करते हैं।

भाषा डिजाइनरों के लिए यह सोचना विशेष रूप से उपयोगी है कि प्रोग्रामिंग भाषाओं का विकास कहाँ तक जाने की संभावना है, क्योंकि वे तदनुसार निर्देशन कर सकते हैं। उस स्थिति में, "मुख्य शाखा पर बने रहें" एक अच्छी भाषा चुनने के तरीके से कहीं अधिक हो जाता है। यह भाषा डिजाइन के बारे में सही निर्णय लेने के लिए एक अनुमान बन जाता है।

किसी भी प्रोग्रामिंग भाषा को दो भागों में विभाजित किया जा सकता है: मौलिक ऑपरेटरों का एक समूह जो भूमिका निभाता है स्वयंसिद्ध, और भाषा के बाकी हिस्से, जिन्हें सिद्धांत रूप में इन मौलिक ऑपरेटरों के संदर्भ में लिखा जा सकता है।

मुझे लगता है कि मौलिक ऑपरेटर किसी भाषा के दीर्घकालिक अस्तित्व में सबसे महत्वपूर्ण कारक हैं। बाकी आप बदल सकते हैं। यह उस नियम की तरह है कि घर खरीदते समय आपको सबसे पहले स्थान पर विचार करना चाहिए। बाकी सब कुछ आप बाद में ठीक कर सकते हैं, लेकिन आप स्थान को ठीक नहीं कर सकते।

मुझे लगता है कि यह महत्वपूर्ण है कि स्वयंसिद्ध अच्छी तरह से चुने गए हों, बल्कि यह भी कि उनमें से कुछ ही हों। गणितज्ञों ने हमेशा स्वयंसिद्ध के बारे में ऐसा महसूस किया है - जितने कम, उतना अच्छा - और मुझे लगता है कि वे कुछ समझ रहे हैं।

कम से कम, भाषा के मूल को करीब से देखना एक उपयोगी व्यायाम होना चाहिए ताकि यह देखा जा सके कि क्या कोई ऐसा स्वयंसिद्ध है जिसे बाहर निकाला जा सकता है। मैंने अपने एक ढीठ व्यक्ति के रूप में लंबे करियर में पाया है कि क्रूफ क्रूफ पैदा करता है, और मैंने इसे सॉफ़्टवेयर में देखा है साथ ही बिस्तरों के नीचे और कमरों के कोनों में भी।

मेरा अनुमान है कि विकासवादी वृक्ष की मुख्य शाखाएँ उन भाषाओं से होकर गुजरती हैं जिनके सबसे छोटे, सबसे साफ कोर होते हैं। जितनी अधिक भाषा आप स्वयं में लिख सकते हैं, उतना ही अच्छा।

बेशक, मैं सौ साल में प्रोग्रामिंग भाषाएँ कैसी होंगी, यह पूछने में भी एक बड़ी धारणा बना रहा हूँ। क्या हम सौ साल में भी प्रोग्राम लिख रहे होंगे? क्या हम कंप्यूटर को यह नहीं बताएंगे कि हम उनसे क्या करवाना चाहते हैं?

इस विभाग में अभी तक बहुत प्रगति नहीं हुई है। मेरा अनुमान है कि सौ साल बाद लोग अभी भी कंप्यूटर को प्रोग्राम का उपयोग करके बताएंगे कि वे क्या करना चाहते हैं, जिन्हें हम पहचानेंगे जैसे। ऐसे कार्य हो सकते हैं जिन्हें हम अभी प्रोग्राम लिखकर हल करते हैं और सौ साल में आपको उन्हें हल करने के लिए प्रोग्राम लिखने की ज़रूरत नहीं होगी, लेकिन मुझे लगता है कि आज हम जिस तरह की प्रोग्रामिंग करते हैं, उसका एक अच्छा हिस्सा अभी भी होगा।

सौ साल में किसी भी तकनीक के बारे में अनुमान लगाना अभिमानी लग सकता है। लेकिन याद रखें कि हमारे पास पहले से ही लगभग पचास साल का इतिहास है। सौ साल आगे देखना एक समझने योग्य विचार है जब हम विचार करते हैं कि पिछले पचास वर्षों में भाषाएँ कितनी धीरे-धीरे विकसित हुई हैं।

भाषाएँ धीरे-धीरे विकसित होती हैं क्योंकि वे वास्तव में तकनीकें नहीं हैं। भाषाएँ संकेतन हैं। एक प्रोग्राम एक औपचारिक विवरण है उस समस्या का जिसे आप चाहते हैं कि कंप्यूटर आपके लिए हल करे। तो दर प्रोग्रामिंग भाषाओं में विकास की दर अधिक है गणितीय संकेतन में विकास की दर की तरह, कहें, परिवहन या संचार। गणितीय संकेतन विकसित होता है, लेकिन उस विशाल के साथ नहीं छलांग जो आप तकनीक में देखते हैं।

सौ साल में कंप्यूटर किससे बने होंगे, यह अनुमान लगाना सुरक्षित लगता है कि वे अब से बहुत तेज होंगे। अगर मूर का नियम जारी रहता है, तो वे 74 क्विंटिलियन (73,786,976,294,838,206,464) गुना तेज होंगे। यह तरह का कल्पना करना मुश्किल है। और वास्तव में, गति विभाग में सबसे संभावित भविष्यवाणी यह हो सकती है कि मूर का नियम काम करना बंद कर देगा। जो कुछ भी हर अठारह महीने में दोगुना होना चाहिए, वह अंततः किसी प्रकार की मौलिक सीमा के खिलाफ चलने की संभावना है। लेकिन मुझे विश्वास करने में कोई परेशानी नहीं है कि कंप्यूटर बहुत अधिक होंगे तेज़। भले ही वे केवल एक मामूली लाख गुना तेज हों, इससे प्रोग्रामिंग के लिए जमीनी नियम बदल जाने चाहिए भाषाएँ काफी हद तक। अन्य बातों के अलावा, वहाँ अधिक जगह होगी कि अब क्या माना जाता है धीमी भाषाएँ, जिसका अर्थ है भाषाएँ जो बहुत कुशल कोड नहीं देती हैं।

और फिर भी कुछ अनुप्रयोगों को अभी भी गति की आवश्यकता होगी। कुछ समस्याएँ जिन्हें हम हल करना चाहते हैं कंप्यूटर द्वारा बनाए गए कंप्यूटर; उदाहरण के लिए, जिस दर पर आपको वीडियो छवियों को संसाधित करना होता है, वह इस बात पर निर्भर करता है कि दूसरा कंप्यूटर किस दर पर उन्हें उत्पन्न कर सकता है। और समस्याओं का एक और वर्ग है जिसमें स्वाभाविक रूप से चक्रों को सोखने की असीमित क्षमता होती है: छवि प्रतिपादन, क्रिप्टोग्राफी, सिमुलेशन।

यदि कुछ अनुप्रयोग तेजी से अक्षम हो सकते हैं जबकि अन्य हार्डवेयर द्वारा वितरित की जा सकने वाली सभी गति की मांग करना जारी रखते हैं, तो तेज़ कंप्यूटर का मतलब होगा कि भाषाओं को कुशलता की एक व्यापक श्रेणी को कवर करना होगा। हमने देखा यह पहले से ही हो रहा है। कुछ के वर्तमान कार्यान्वयन लोकप्रिय नई भाषाएँ पिछले दशकों के मानकों के अनुसार चौंकाने वाली तरह से बेकार हैं।

यह सिर्फ प्रोग्रामिंग के साथ ऐसा नहीं होता है भाषाएँ। यह एक सामान्य ऐतिहासिक प्रवृत्ति है। जैसे-जैसे तकनीकें बेहतर होती जाती हैं, प्रत्येक पीढ़ी ऐसी चीजें कर सकती है जो पिछली पीढ़ी बेकार समझती होगी। तीस साल पहले के लोग इस बात पर हैरान होंगे कि हम कितनी लापरवाही से लंबी दूरी की कॉल करते हैं। सौ साल पहले के लोग और भी हैरान होंगे कि एक पैकेज एक दिन बोस्टन से मेम्फिस के रास्ते न्यूयॉर्क तक जाएगा।

मैं आपको पहले ही बता सकता हूँ कि उन सभी अतिरिक्त चक्रों का क्या होने वाला है जो तेज़ हार्डवेयर हमें देने जा रहा है अगले सौ साल में। वे लगभग सभी बर्बाद होने वाले हैं।

मैंने प्रोग्राम करना तब सीखा जब कंप्यूटर की शक्ति दुर्लभ थी। मुझे याद है कि अपने बेसिक प्रोग्राम से सभी रिक्त स्थान निकाल दिए गए थे ताकि वे 4K TRS-80 की मेमोरी में फिट हो जाएं। इस सभी अत्यधिक अक्षम सॉफ़्टवेयर के बारे में सोचना एक ही काम बार-बार करके चक्रों को जलाना मेरे लिए थोड़ा घृणित लगता है। लेकिन मुझे लगता है कि यहाँ मेरे अंतर्ज्ञान गलत हैं। मैं ऐसे व्यक्ति की तरह हूँ जो गरीब होकर पला-बढ़ा है, और डॉक्टर के पास जाने जैसी महत्वपूर्ण चीज़ के लिए भी पैसे खर्च करने से बचता है।

कुछ प्रकार के अपव्यय वास्तव में घृणित होते हैं। उदाहरण के लिए, एसयूवी, तर्क के अनुसार घृणित होंगे, भले ही वे ऐसे ईंधन पर चलते हों जो कभी नहीं खत्म होगा और कोई प्रदूषण नहीं उत्पन्न करेगा। एसयूवी घृणित हैं क्योंकि वे एक घृणित समस्या का समाधान हैं। (मिनिवैन को अधिक कैसे बनाया जाए मर्दाना।) लेकिन सभी अपव्यय बुरे नहीं होते हैं। अब जब हमारे पास बुनियादी ढांचा है इसका समर्थन करने के लिए, अपनी लंबी दूरी की कॉल के मिनटों की गिनती करना शुरू हो जाता है। अगर आपके पास संसाधन हैं, तो सभी फ़ोन कॉल को एक तरह की चीज़ के रूप में सोचना अधिक सुंदर है, चाहे दूसरा व्यक्ति कहीं भी हो।

अच्छा अपव्यय है, और बुरा अपव्यय है। मुझे दिलचस्पी है अच्छे अपव्यय में - वह प्रकार जहाँ, अधिक खर्च करके, हम प्राप्त कर सकते हैं सरल डिजाइन। हम अवसरों का लाभ कैसे उठाएंगे नए, तेज़ हार्डवेयर से हमें मिलने वाले चक्रों को बर्बाद करने के लिए?

गति की इच्छा हम में इतनी गहराई से समा गई है, हमारे नन्हे कंप्यूटरों के साथ, कि इसे दूर करने के लिए एक सचेत प्रयास की आवश्यकता होगी। भाषा डिजाइन में, हमें सचेत रूप से तलाश करनी चाहिए ऐसी स्थितियाँ जहाँ हम दक्षता का व्यापार कर सकते हैं, यहाँ तक कि सुविधा में सबसे छोटी वृद्धि के लिए भी।

अधिकांश डेटा संरचनाएँ गति के कारण मौजूद हैं। उदाहरण के लिए, आज कई भाषाओं में स्ट्रिंग और सूचियाँ दोनों हैं। अर्थपूर्ण रूप से, स्ट्रिंग सूचियों का एक उपसमुच्चय है जिसमें तत्व हैं वर्ण। तो आपको एक अलग डेटा प्रकार की आवश्यकता क्यों है? आपको वास्तव में इसकी आवश्यकता नहीं है। स्ट्रिंग केवल दक्षता के लिए मौजूद हैं। लेकिन भाषा के अर्थ को अव्यवस्थित करना लंगड़ा है प्रोग्राम को तेज़ी से चलाने के लिए हैक के साथ। किसी भाषा में स्ट्रिंग होना प्रतीत होता है समयपूर्व अनुकूलन का मामला।

अगर हम किसी भाषा के मूल को स्वयंसिद्धों के समूह के रूप में सोचते हैं, निश्चित रूप से कोई अतिरिक्त स्वयंसिद्ध होना घृणित है जो कोई अभिव्यंजक नहीं जोड़ता है शक्ति, केवल दक्षता के लिए। दक्षता है महत्वपूर्ण, लेकिन मुझे नहीं लगता कि यह इसे प्राप्त करने का सही तरीका है।

उस समस्या को हल करने का सही तरीका, मुझे लगता है, अलग करना है किसी प्रोग्राम का अर्थ कार्यान्वयन विवरणों से। सूचियों और स्ट्रिंग दोनों के बजाय, केवल सूचियाँ रखें, कंपाइलर को अनुकूलन सलाह देने के कुछ तरीके के साथ जो इसे स्ट्रिंग को सन्निहित बाइट के रूप में बिछाने की अनुमति देगा यदि आवश्यक हो।

चूँकि गति किसी प्रोग्राम के अधिकांश भाग में मायने नहीं रखती है, इसलिए आप नहीं करेंगे आमतौर पर इस तरह के सूक्ष्म प्रबंधन से परेशान होने की आवश्यकता है। यह कंप्यूटर के तेज़ होने के साथ-साथ अधिक से अधिक सच होगा।

कार्यान्वयन के बारे में कम कहने से प्रोग्राम भी बनना चाहिए अधिक लचीला। जब कोई प्रोग्राम लिखा जा रहा होता है तो विनिर्देश बदल जाते हैं, और यह न केवल अनिवार्य है, बल्कि वांछनीय भी है।

"निबंध" शब्द फ्रांसीसी क्रिया "essayer" से आया है, जिसका अर्थ है "कोशिश करना"। मूल अर्थ में एक निबंध कुछ ऐसा है जिसे आप यह पता लगाने के लिए लिखते हैं कि आप क्या समझ रहे हैं। यह होता है सॉफ़्टवेयर में भी। मुझे लगता है कि कुछ बेहतरीन प्रोग्राम निबंध थे, इस अर्थ में कि लेखकों को शुरू में पता नहीं था ठीक है कि वे क्या लिखने की कोशिश कर रहे थे।

लिसप हैकर्स पहले से ही लचीले होने के मूल्य के बारे में जानते हैं डेटा संरचनाओं के साथ। हम प्रोग्राम के पहले संस्करण को लिखते हैं ताकि वह सब कुछ सूचियों के साथ कर सके। ये प्रारंभिक संस्करण इतने चौंकाने वाले अक्षम हो सकते हैं कि यह एक सचेत प्रयास की आवश्यकता है कि वे क्या कर रहे हैं, इस बारे में न सोचें, जैसे, मेरे लिए कम से कम, स्टेक खाने के लिए एक सचेत प्रयास की आवश्यकता है कि यह कहाँ से आया है।

सौ साल में प्रोग्रामर सबसे ज़्यादा क्या ढूँढ रहे होंगे, वह है एक भाषा जहाँ आप एक अविश्वसनीय रूप से फेंक सकते हैं अक्षम संस्करण 1 एक प्रोग्राम का कम से कम संभव के साथ प्रयास। कम से कम, इस तरह हम इसे वर्तमान समय में वर्णित करेंगे शर्तें। वे कहेंगे कि वे एक ऐसी भाषा चाहते हैं जो प्रोग्राम करने में आसान है।

अक्षम सॉफ़्टवेयर घृणित नहीं है। जो घृणित है वह एक भाषा है जो प्रोग्रामर को अनावश्यक काम करने के लिए मजबूर करती है। प्रोग्रामर का समय बर्बाद करना सच्ची अक्षमता है, मशीन का समय बर्बाद नहीं करना। यह कंप्यूटर के तेज़ होने के साथ-साथ और भी स्पष्ट होता जाएगा।

मुझे लगता है कि स्ट्रिंग से छुटकारा पाना पहले से ही कुछ ऐसा है जिसके बारे में हम सोच सकते हैं। हमने इसे Arc में किया, और ऐसा लगता है एक जीत; कुछ ऑपरेशन जो नियमित अभिव्यक्तियों के रूप में अजीब होंगे वर्णित किया जा सकता है आसानी से पुनरावर्ती कार्यों के रूप में।

डेटा संरचनाओं का यह समतलीकरण कहाँ तक जाएगा? मैं सोच सकता हूँ ऐसी संभावनाएँ जो मुझे भी चौंका देती हैं, मेरे विवेकपूर्ण रूप से विस्तृत मन के साथ। क्या हम सरणियों से छुटकारा पा लेंगे, उदाहरण के लिए? आखिरकार, वे हैश टेबल का एक उपसमुच्चय है जहाँ कुंजियाँ पूर्णांकों के वैक्टर हैं। क्या हम हैश टेबल को स्वयं सूचियों से बदल देंगे?

इससे भी चौंकाने वाली संभावनाएँ हैं। उदाहरण के लिए, 1960 में मैकार्थी द्वारा वर्णित लिसप में संख्याएँ नहीं थीं। तार्किक रूप से, आपको संख्याओं की एक अलग धारणा रखने की आवश्यकता नहीं है, क्योंकि आप उन्हें सूचियों के रूप में दर्शा सकते हैं: पूर्णांक n को n तत्वों की सूची के रूप में दर्शाया जा सकता है। आप इस तरह से गणित कर सकते हैं। यह बस असहनीय रूप से अक्षम है।

वास्तव में किसी ने भी संख्याओं को सूचियों के रूप में लागू करने का प्रस्ताव नहीं दिया। वास्तव में, मैकार्थी का 1960 का पेपर उस समय लागू करने के लिए अभिप्रेत नहीं था। यह एक सैद्धांतिक अभ्यास था, ट्यूरिंग मशीन के लिए एक अधिक सुरुचिपूर्ण विकल्प बनाने का प्रयास। जब किसी ने, अप्रत्याशित रूप से, इस पेपर को लिया और इसे एक काम करने वाले लिसप दुभाषिया में अनुवाद किया, तो संख्याओं को निश्चित रूप से सूचियों के रूप में नहीं दर्शाया गया था; उन्हें बाइनरी में दर्शाया गया था, जैसा कि हर दूसरी भाषा में होता है।

क्या कोई प्रोग्रामिंग भाषा संख्याओं को एक मौलिक डेटा प्रकार के रूप में प्राप्त करने के लिए इतनी दूर जा सकती है? मैं यह एक गंभीर प्रश्न के रूप में नहीं पूछता, बल्कि भविष्य के साथ चिकन खेलने के तरीके के रूप में पूछता हूं। यह एक अपरिवर्तनीय बल की एक अचल वस्तु से मिलने के काल्पनिक मामले की तरह है - यहां, एक अकल्पनीय रूप से अक्षम कार्यान्वयन अकल्पनीय रूप से महान संसाधनों से मिल रहा है। मुझे नहीं पता कि क्यों नहीं। भविष्य बहुत लंबा है। अगर हम कोर भाषा में स्वयंसिद्धों की संख्या को कम करने के लिए कुछ कर सकते हैं, तो ऐसा लगता है कि t अनंत तक पहुंचने पर दांव लगाने का पक्ष होगा। यदि विचार सौ वर्षों में अभी भी असहनीय लगता है, तो शायद यह हजार में नहीं होगा।

इस बारे में स्पष्ट होने के लिए, मैं यह प्रस्ताव नहीं कर रहा हूं कि सभी संख्यात्मक गणना वास्तव में सूचियों का उपयोग करके की जाएंगी। मैं प्रस्ताव कर रहा हूं कि कार्यान्वयन के बारे में किसी भी अतिरिक्त संकेतन से पहले, कोर भाषा को इस तरह परिभाषित किया जाए। व्यवहार में कोई भी प्रोग्राम जो किसी भी मात्रा में गणित करना चाहता है, संभवतः संख्याओं को बाइनरी में दर्शाएगा, लेकिन यह एक अनुकूलन होगा, कोर भाषा के अर्थशास्त्र का हिस्सा नहीं।

चक्रों को जलाने का एक और तरीका है कि एप्लिकेशन और हार्डवेयर के बीच सॉफ़्टवेयर की कई परतें हों। यह भी एक प्रवृत्ति है जिसे हम पहले से ही होते हुए देख रहे हैं: कई हालिया भाषाओं को बाइट कोड में संकलित किया जाता है। बिल वुड्स ने एक बार मुझसे कहा था कि, एक नियम के रूप में, व्याख्या की प्रत्येक परत गति में 10 के कारक की लागत है। यह अतिरिक्त लागत आपको लचीलापन खरीदती है।

आर्क का पहला संस्करण इस तरह की बहु-स्तरीय धीमेपन का एक चरम मामला था, जिसमें संगत लाभ थे। यह एक क्लासिक "मेटा-सर्कुलर" दुभाषिया था जो कॉमन लिसप के शीर्ष पर लिखा गया था, जिसमें मैकार्थी के मूल लिसप पेपर में परिभाषित eval फ़ंक्शन से एक निश्चित पारिवारिक समानता थी। पूरी बात केवल कुछ सौ पंक्तियों का कोड थी, इसलिए इसे समझना और बदलना बहुत आसान था। हमारे द्वारा उपयोग किया जाने वाला कॉमन लिसप, CLisp, स्वयं एक बाइट कोड दुभाषिया के शीर्ष पर चलता है। तो यहां हमारे पास व्याख्या के दो स्तर थे, उनमें से एक (शीर्ष वाला) चौंकाने वाला अक्षम था, और भाषा प्रयोग करने योग्य थी। बमुश्किल प्रयोग करने योग्य, मैं मानता हूं, लेकिन प्रयोग करने योग्य।

सॉफ़्टवेयर को कई परतों के रूप में लिखना एप्लिकेशन के भीतर भी एक शक्तिशाली तकनीक है। बॉटम-अप प्रोग्रामिंग का अर्थ है एक प्रोग्राम को परतों की एक श्रृंखला के रूप में लिखना, जिनमें से प्रत्येक ऊपर वाले के लिए एक भाषा के रूप में कार्य करता है। यह दृष्टिकोण छोटे, अधिक लचीले कार्यक्रमों को प्राप्त करने की प्रवृत्ति रखता है। यह उस पवित्र कंठ, पुन: प्रयोज्यता के लिए भी सबसे अच्छा मार्ग है। एक भाषा परिभाषा के अनुसार पुन: प्रयोज्य है। आप अपने एप्लिकेशन के जितने अधिक भाग को उस प्रकार के एप्लिकेशन को लिखने के लिए एक भाषा में नीचे धकेल सकते हैं, आपके सॉफ़्टवेयर का उतना ही अधिक हिस्सा पुन: प्रयोज्य होगा।

किसी तरह पुन: प्रयोज्यता का विचार 1980 के दशक में ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग से जुड़ गया, और इसके विपरीत कोई भी सबूत इसे मुक्त करने में सक्षम नहीं लगता है। लेकिन हालाँकि कुछ ऑब्जेक्ट-ओरिएंटेड सॉफ़्टवेयर पुन: प्रयोज्य है, लेकिन इसे पुन: प्रयोज्य बनाने वाला इसकी बॉटम-अपनेस है, न कि इसकी ऑब्जेक्ट-ओरिएंटेडनेस। पुस्तकालयों पर विचार करें: वे पुन: प्रयोज्य हैं क्योंकि वे भाषा हैं, चाहे वे ऑब्जेक्ट-ओरिएंटेड शैली में लिखे गए हों या नहीं।

मैं ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के पतन की भविष्यवाणी नहीं करता, वैसे। हालाँकि मुझे नहीं लगता कि इसके अच्छे प्रोग्रामरों को बहुत कुछ देना है, कुछ विशिष्ट डोमेन को छोड़कर, यह बड़े संगठनों के लिए अप्रतिरोध्य है। ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग स्पेगेटी कोड लिखने का एक टिकाऊ तरीका प्रदान करता है। यह आपको पैच की एक श्रृंखला के रूप में कार्यक्रमों को जोड़ने देता है।

बड़े संगठन हमेशा इस तरह से सॉफ़्टवेयर विकसित करते हैं, और मुझे उम्मीद है कि यह सौ वर्षों में भी उतना ही सच होगा जितना आज है।

जब तक हम भविष्य के बारे में बात कर रहे हैं, हमें समानांतर गणना के बारे में बात करनी चाहिए, क्योंकि यहीं पर यह विचार रहता है। अर्थात्, कोई फर्क नहीं पड़ता कि आप कब बात कर रहे हैं, समानांतर गणना कुछ ऐसा प्रतीत होता है जो भविष्य में होने वाला है।

क्या भविष्य कभी उससे आगे निकल जाएगा? लोग कम से कम 20 वर्षों से समानांतर गणना के बारे में कुछ आसन्न के रूप में बात कर रहे हैं, और इसने अभी तक प्रोग्रामिंग अभ्यास को बहुत अधिक प्रभावित नहीं किया है। या नहीं किया है? पहले से ही चिप डिज़ाइनरों को इसके बारे में सोचना पड़ता है, और इसलिए बहु-सीपीयू कंप्यूटरों पर सिस्टम सॉफ़्टवेयर लिखने की कोशिश करने वाले लोगों को भी सोचना पड़ता है।

असली सवाल यह है कि अमूर्तता की सीढ़ी पर समानांतरता कितनी दूर जाएगी? सौ वर्षों में क्या यह एप्लिकेशन प्रोग्रामरों को भी प्रभावित करेगा? या क्या यह कुछ ऐसा होगा जिसके बारे में कंपाइलर लेखक सोचते हैं, लेकिन जो आमतौर पर अनुप्रयोगों के स्रोत कोड में अदृश्य होता है?

एक बात जो संभावित लगती है वह यह है कि समानांतरता के अधिकांश अवसर बर्बाद हो जाएंगे। यह मेरी अधिक सामान्य भविष्यवाणी का एक विशेष मामला है कि हमें दी जाने वाली अधिकांश अतिरिक्त कंप्यूटर शक्ति बर्बाद हो जाएगी। मुझे उम्मीद है कि, अंतर्निहित हार्डवेयर की जबरदस्त गति के साथ, समानांतरता कुछ ऐसी होगी जो उपलब्ध होगी यदि आप इसके लिए स्पष्ट रूप से पूछते हैं, लेकिन आम तौर पर उपयोग नहीं की जाती है। इसका तात्पर्य है कि सौ वर्षों में हमारे पास जिस तरह की समानांतरता होगी, वह विशेष अनुप्रयोगों को छोड़कर, विशाल समानांतरता नहीं होगी। मुझे उम्मीद है कि सामान्य प्रोग्रामरों के लिए यह प्रक्रियाओं को फोर्क करने में सक्षम होने जैसा होगा जो सभी समानांतर में चलते हैं।

और यह, डेटा संरचनाओं के विशिष्ट कार्यान्वयन के लिए पूछने की तरह, कुछ ऐसा होगा जो आप किसी प्रोग्राम के जीवन में काफी देर से करते हैं, जब आप इसे अनुकूलित करने का प्रयास करते हैं। संस्करण 1 आम तौर पर समानांतर गणना से प्राप्त होने वाले किसी भी लाभ को अनदेखा करेंगे, जैसे कि वे डेटा के विशिष्ट प्रतिनिधित्व से प्राप्त होने वाले लाभों को अनदेखा करेंगे।

विशेष प्रकार के अनुप्रयोगों को छोड़कर, समानांतरता सौ वर्षों में लिखे जाने वाले कार्यक्रमों में व्याप्त नहीं होगी। यदि ऐसा होता है तो यह समयपूर्व अनुकूलन होगा।

सौ वर्षों में कितनी प्रोग्रामिंग भाषाएँ होंगी? हाल ही में बड़ी संख्या में नई प्रोग्रामिंग भाषाएँ दिखाई दे रही हैं। इसका एक कारण यह है कि तेज़ हार्डवेयर ने प्रोग्रामरों को गति और सुविधा के बीच अलग-अलग व्यापार बंद करने की अनुमति दी है, यह इस बात पर निर्भर करता है कि आवेदन क्या है। यदि यह एक वास्तविक प्रवृत्ति है, तो सौ वर्षों में हमारे पास जो हार्डवेयर होगा, वह केवल इसे बढ़ाना चाहिए।

और फिर भी सौ वर्षों में केवल कुछ व्यापक रूप से उपयोग की जाने वाली भाषाएँ हो सकती हैं। मेरा ऐसा कहने का एक कारण आशावाद है: ऐसा लगता है कि यदि आप वास्तव में अच्छा काम करते हैं, तो आप एक ऐसी भाषा बना सकते हैं जो धीमे संस्करण 1 लिखने के लिए आदर्श हो, और फिर भी कंपाइलर को सही अनुकूलन सलाह के साथ, बहुत तेज़ कोड भी उत्पन्न करेगा जब आवश्यक हो। इसलिए, चूँकि मैं आशावादी हूँ, मैं भविष्यवाणी करने जा रहा हूँ कि स्वीकार्य और अधिकतम दक्षता के बीच विशाल अंतर के बावजूद, सौ वर्षों में प्रोग्रामरों के पास ऐसी भाषाएँ होंगी जो इसके अधिकांश हिस्से को फैला सकती हैं।

जैसे-जैसे यह अंतर चौड़ा होता जाएगा, प्रोफाइलर अधिक महत्वपूर्ण होते जाएँगे। अभी प्रोफाइलिंग पर बहुत कम ध्यान दिया जाता है। बहुत से लोग अभी भी यह मानते हैं कि तेज़ अनुप्रयोग प्राप्त करने का तरीका तेज़ कोड उत्पन्न करने वाले कंपाइलर लिखना है। जैसे-जैसे स्वीकार्य और अधिकतम प्रदर्शन के बीच का अंतर चौड़ा होता जाएगा, यह स्पष्ट होता जाएगा कि तेज़ अनुप्रयोग प्राप्त करने का तरीका एक से दूसरे तक एक अच्छा मार्गदर्शक होना है।

जब मैं कहता हूं कि केवल कुछ भाषाएँ हो सकती हैं, तो मैं डोमेन-विशिष्ट "छोटी भाषाओं" को शामिल नहीं कर रहा हूं। मुझे लगता है कि ऐसी एम्बेडेड भाषाएँ एक बहुत अच्छा विचार हैं, और मुझे उम्मीद है कि वे बढ़ेंगी। लेकिन मुझे उम्मीद है कि उन्हें इतनी पतली खाल के रूप में लिखा जाएगा कि उपयोगकर्ता नीचे की सामान्य-उद्देश्य भाषा देख सकें।

भविष्य की भाषाओं को कौन डिजाइन करेगा? पिछले दस वर्षों में सबसे रोमांचक रुझानों में से एक पर्ल, पायथन और रूबी जैसी ओपन-सोर्स भाषाओं का उदय रहा है। भाषा डिजाइन हैकर्स द्वारा संभाला जा रहा है। अब तक के परिणाम गड़बड़ हैं, लेकिन उत्साहजनक हैं। उदाहरण के लिए, पर्ल में कुछ आश्चर्यजनक रूप से नए विचार हैं। कई आश्चर्यजनक रूप से बुरे हैं, लेकिन यह हमेशा महत्वाकांक्षी प्रयासों के लिए सच होता है। अपने वर्तमान उत्परिवर्तन की दर पर, भगवान जानता है कि पर्ल सौ वर्षों में क्या विकसित हो सकता है।

यह सच नहीं है कि जो नहीं कर सकते, वे पढ़ाते हैं (मेरे जानने वाले कुछ बेहतरीन हैकर्स प्रोफेसर हैं), लेकिन यह सच है कि बहुत सी चीजें हैं जो पढ़ाने वाले नहीं कर सकते। शोध बाध्यकारी जाति प्रतिबंध लगाता है। किसी भी शैक्षणिक क्षेत्र में ऐसे विषय होते हैं जिन पर काम करना ठीक होता है और अन्य जो नहीं होते हैं। दुर्भाग्य से स्वीकार्य और निषिद्ध विषयों के बीच अंतर आमतौर पर इस बात पर आधारित होता है कि शोध पत्रों में वर्णित होने पर काम कितना बौद्धिक लगता है, बजाय इसके कि अच्छे परिणाम प्राप्त करने के लिए यह कितना महत्वपूर्ण है। चरम मामला शायद साहित्य है; साहित्य का अध्ययन करने वाले लोग शायद ही कभी ऐसा कुछ कहते हैं जो इसे उत्पादित करने वालों के लिए थोड़ी सी भी उपयोगी हो।

हालांकि विज्ञान में स्थिति बेहतर है, आपके द्वारा किए जा सकने वाले काम के प्रकार और अच्छी भाषाएँ उत्पन्न करने वाले काम के प्रकार के बीच ओवरलैप बहुत कम है। (ओलिन शिवर्स ने इस बारे में स्पष्ट रूप से बड़बड़ाया है।) उदाहरण के लिए, प्रकार शोध पत्रों का एक अटूट स्रोत प्रतीत होते हैं, इस तथ्य के बावजूद कि स्थिर टाइपिंग वास्तविक मैक्रोज़ को रोकता है - जिसके बिना, मेरी राय में, कोई भी भाषा उपयोग करने लायक नहीं है।

प्रवृत्ति केवल भाषाओं के "शोध" के बजाय ओपन-सोर्स प्रोजेक्ट के रूप में विकसित होने की ओर नहीं है, बल्कि भाषाओं को कंपाइलर लेखकों के बजाय उन अनुप्रयोग प्रोग्रामरों द्वारा डिज़ाइन किया जा रहा है जिन्हें उन्हें उपयोग करने की आवश्यकता है। यह एक अच्छी प्रवृत्ति लगती है और मुझे उम्मीद है कि यह जारी रहेगा।

सौ वर्षों में भौतिकी के विपरीत, जो लगभग अनिवार्य रूप से अनुमान लगाना असंभव है, मुझे लगता है कि सिद्धांत रूप में अब एक ऐसी भाषा डिजाइन करना संभव हो सकता है जो सौ वर्षों में उपयोगकर्ताओं को पसंद आए।

एक भाषा को डिजाइन करने का एक तरीका यह है कि आप बस उस प्रोग्राम को लिखें जिसे आप लिखना चाहेंगे, चाहे वह कोई कंपाइलर हो जो इसका अनुवाद कर सके या हार्डवेयर जो इसे चला सके। जब आप ऐसा करते हैं तो आप असीमित संसाधनों को मान सकते हैं। ऐसा लगता है कि हमें आज भी सौ वर्षों में असीमित संसाधनों की कल्पना करने में सक्षम होना चाहिए।

कोई कौन सा प्रोग्राम लिखना चाहेगा? जो सबसे कम काम हो। सिवाय इसके कि काफी नहीं: जो होगा सबसे कम काम अगर प्रोग्रामिंग के बारे में आपके विचार पहले से ही उन भाषाओं से प्रभावित नहीं होते हैं जिनका आप वर्तमान में उपयोग करते हैं। ऐसा प्रभाव इतना व्यापक हो सकता है कि इसे दूर करने के लिए बहुत प्रयास की आवश्यकता होती है। आपको लगता होगा कि यह हमारे जैसे आलसी प्राणियों के लिए स्पष्ट होगा कि किसी प्रोग्राम को कम से कम प्रयास के साथ कैसे व्यक्त किया जाए। वास्तव में, हमारे पास जो संभव है, उसके बारे में हमारे विचार इतने सीमित होते हैं कि हम जिस भी भाषा में सोचते हैं, उससे प्रोग्राम के आसान सूत्र बहुत आश्चर्यजनक लगते हैं। वे कुछ ऐसे हैं जिन्हें आपको खोजना होगा, न कि कुछ ऐसा जिसमें आप स्वाभाविक रूप से डूब जाएं।

यहां एक उपयोगी चाल है लंबाई का उपयोग प्रोग्राम को लिखने में कितना काम लगता है, इसके अनुमान के रूप में करना। पात्रों में लंबाई नहीं, बल्कि अलग-अलग सिंटैक्टिक तत्वों में लंबाई - मूल रूप से, पार्स ट्री का आकार। यह बिल्कुल सच नहीं हो सकता है कि सबसे छोटा प्रोग्राम लिखने के लिए सबसे कम काम है, लेकिन यह काफी करीब है कि आप संक्षिप्तता के ठोस लक्ष्य के लिए लक्ष्य रखना बेहतर समझते हैं, कम से कम काम के धुंधले, आस-पास के लक्ष्य के बजाय। फिर भाषा डिजाइन के लिए एल्गोरिथम बन जाता है: एक प्रोग्राम को देखें और पूछें, क्या इसे लिखने का कोई तरीका है जो छोटा हो?

व्यवहार में, एक काल्पनिक सौ साल की भाषा में प्रोग्राम लिखना अलग-अलग डिग्री तक काम करेगा, यह इस बात पर निर्भर करता है कि आप कोर के कितने करीब हैं। सॉर्ट रूटीन जिन्हें आप अभी लिख सकते हैं। लेकिन अब यह अनुमान लगाना मुश्किल होगा कि सौ वर्षों में किस तरह के पुस्तकालयों की आवश्यकता हो सकती है। संभवतः कई पुस्तकालय ऐसे डोमेन के लिए होंगे जो अभी तक मौजूद नहीं हैं। उदाहरण के लिए, यदि SETI@home काम करता है, तो हमें एलियंस के साथ संवाद करने के लिए पुस्तकालयों की आवश्यकता होगी। जब तक कि निश्चित रूप से वे इतने उन्नत नहीं हैं कि वे पहले से ही XML में संवाद करते हैं।

दूसरे चरम पर, मुझे लगता है कि आप आज कोर भाषा को डिजाइन करने में सक्षम हो सकते हैं। वास्तव में, कुछ तर्क दे सकते हैं कि इसे 1958 में पहले ही ज्यादातर डिजाइन किया गया था।

अगर सौ साल की भाषा आज उपलब्ध होती, तो क्या हम उसमें प्रोग्राम करना चाहेंगे? इस प्रश्न का उत्तर देने का एक तरीका पीछे मुड़कर देखना है। अगर आज की प्रोग्रामिंग भाषाएँ 1960 में उपलब्ध होतीं, तो क्या कोई उनका उपयोग करना चाहता?

कुछ मायनों में, जवाब नहीं है। आज की भाषाएँ ऐसे बुनियादी ढाँचे को मानती हैं जो 1960 में मौजूद नहीं थे। उदाहरण के लिए, एक भाषा जिसमें इंडेंटेशन महत्वपूर्ण है, जैसे पायथन, प्रिंटर टर्मिनलों पर बहुत अच्छी तरह से काम नहीं करेगी। लेकिन ऐसी समस्याओं को अलग रखते हुए - मान लीजिए, उदाहरण के लिए, कि सभी कार्यक्रम केवल कागज पर लिखे गए थे - क्या 1960 के दशक के प्रोग्रामर उन भाषाओं में प्रोग्राम लिखना पसंद करते जिनका हम अब उपयोग करते हैं?

मुझे ऐसा लगता है। कुछ कम कल्पनाशील लोग, जिनके पास प्रोग्राम क्या होता है, इस बारे में उनके विचारों में प्राचीन भाषाओं की कलाकृतियाँ बनी हुई थीं, उन्हें परेशानी हो सकती थी। (बिना पॉइंटर अंकगणित के आप डेटा को कैसे हेरफेर कर सकते हैं? बिना गोतो के आप फ्लो चार्ट कैसे लागू कर सकते हैं?) लेकिन मुझे लगता है कि सबसे चतुर प्रोग्रामर को आज की भाषाओं का अधिकतम लाभ उठाने में कोई परेशानी नहीं होती, अगर उनके पास होती।

अगर हमारे पास अब सौ साल की भाषा होती, तो यह कम से कम एक बेहतरीन छद्म कोड बनाती। इसे सॉफ्टवेयर लिखने के लिए इस्तेमाल करने के बारे में क्या? चूँकि सौ साल की भाषा को कुछ अनुप्रयोगों के लिए तेज़ कोड उत्पन्न करने की आवश्यकता होगी, संभवतः यह हमारे हार्डवेयर पर स्वीकार्य रूप से अच्छी तरह से चलने के लिए पर्याप्त कुशल कोड उत्पन्न कर सकती है। हमें सौ साल बाद के उपयोगकर्ताओं की तुलना में अधिक अनुकूलन सलाह देनी पड़ सकती है, लेकिन यह अभी भी एक शुद्ध जीत हो सकती है।

अब हमारे पास दो विचार हैं जो, यदि आप उन्हें मिलाते हैं, तो दिलचस्प संभावनाओं का सुझाव देते हैं: (1) सौ साल की भाषा, सिद्धांत रूप में, आज डिज़ाइन की जा सकती है, और (2) ऐसी भाषा, यदि वह मौजूद होती, तो आज प्रोग्राम करने के लिए अच्छी हो सकती है। जब आप इन विचारों को इस तरह से रखते हुए देखते हैं, तो यह सोचना मुश्किल नहीं है कि सौ साल की भाषा अब क्यों नहीं लिखने की कोशिश करें?

जब आप भाषा डिजाइन पर काम कर रहे होते हैं, तो मुझे लगता है कि ऐसा लक्ष्य होना और उसे सचेत रूप से ध्यान में रखना अच्छा होता है। जब आप गाड़ी चलाना सीखते हैं, तो वे आपको जो सिद्धांत सिखाते हैं उनमें से एक यह है कि कार को सड़क पर खींची गई धारियों के साथ हुड को संरेखित करके नहीं, बल्कि दूरी में किसी बिंदु पर निशाना लगाकर संरेखित करें। भले ही आप केवल अगले दस फीट में क्या होता है, इसके बारे में परवाह करते हैं, यह सही उत्तर है। मुझे लगता है कि हम प्रोग्रामिंग भाषाओं के साथ भी ऐसा कर सकते हैं और करना चाहिए।

नोट्स

मेरा मानना है कि लिसप मशीन लिसप पहली भाषा थी जिसने इस सिद्धांत को अपनाया था कि घोषणाएँ (गतिशील चर की घोषणाओं को छोड़कर) केवल अनुकूलन सलाह थीं, और एक सही प्रोग्राम के अर्थ को नहीं बदलेंगी। कॉमन लिसप ऐसा स्पष्ट रूप से कहने वाला पहला प्रतीत होता है।

धन्यवाद ट्रेवर ब्लैकवेल, रॉबर्ट मॉरिस और डैन गिफिन को इस के ड्राफ्ट पढ़ने के लिए, और गुइडो वैन रोसम, जेरेमी हिल्टन और पायथन क्रू के बाकी लोगों को मुझे पायकॉन में बोलने के लिए आमंत्रित करने के लिए।