एक सौ साल की भाषा

अप्रैल 2003

(यह निबंध PyCon 2003 में एक मुख्य भाषण से प्राप्त है.)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

नोट्स

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

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