भाषा डिज़ाइन के बारे में पांच प्रश्न

मई 2001

(ये कुछ नोट्स हैं जो मैंने 10 मई 2001 को MIT में प्रोग्रामिंग भाषा डिज़ाइन पर एक पैनल चर्चा के लिए बनाए थे।)

1. प्रोग्रामिंग भाषाएँ लोगों के लिए हैं।

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

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

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

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

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

2. अपने और अपने दोस्तों के लिए डिज़ाइन करें।

यदि आप प्रोग्रामिंग भाषाओं के इतिहास को देखें, तो उनमें से कई बेहतरीन भाषाएँ उन लेखकों के लिए डिज़ाइन की गई थीं जो उनका उपयोग करते थे, और कई सबसे खराब भाषाएँ दूसरों के उपयोग के लिए डिज़ाइन की गई थीं।

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

इसका भाषा की अमूर्तता से कोई लेना-देना नहीं है। C काफी निम्न-स्तरीय है, लेकिन इसे इसके लेखकों के उपयोग के लिए डिज़ाइन किया गया था, और यही कारण है कि हैकर इसे पसंद करते हैं।

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

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

3. प्रोग्रामर को यथासंभव अधिक नियंत्रण दें।

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

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

4. संक्षिप्तता का लक्ष्य रखें।

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

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

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

5. हैकिंग क्या है, इसे स्वीकार करें।

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

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

1. बड़े पुस्तकालयों को कैसे व्यवस्थित करें?

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

2. क्या लोग वास्तव में प्रीफिक्स वाक्यविन्यास से डरते हैं?

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

3. सर्वर-आधारित सॉफ़्टवेयर के लिए आपको क्या चाहिए?

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

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

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

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

4. कौन सी नई अमूर्तताएँ खोजने के लिए बची हैं?

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

1. आप जो चाहें वह भाषा उपयोग कर सकते हैं।

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

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

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

2. गति प्रोफाइलर्स से आती है।

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

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

3. आपको एक एप्लिकेशन की आवश्यकता है जो एक भाषा के डिज़ाइन को चलाए।

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

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

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

4. एक भाषा को फेंकने योग्य कार्यक्रम लिखने के लिए अच्छी होनी चाहिए।

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

5. वाक्यविन्यास अर्थशास्त्र से जुड़ा है।

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

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

1. नई प्रोग्रामिंग भाषाएँ।

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

2. समय-शेयरिंग।

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

3. दक्षता।

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

इसलिए मुझे लगता है कि दक्षता महत्वपूर्ण होगी, कम से कम गणनात्मक बाधाओं में। यह विशेष रूप से महत्वपूर्ण होगा कि I/O तेज़ हो, क्योंकि सर्वर-आधारित अनुप्रयोग बहुत अधिक I/O करते हैं।

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

1. क्लाइंट।

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

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

2. ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग।

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

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

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

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

3. समिति द्वारा डिज़ाइन।

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

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