सौ साल की भाषा

अप्रैल 2003

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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