सौ साल की भाषा

अप्रैल 2003

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

टिप्पणियाँ

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

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