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

मई 2001

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. थ्रोअवे प्रोग्राम लिखने के लिए भाषा का अच्छा होना आवश्यक है।

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

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

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

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

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

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

2. समय-साझाकरण.

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

3. दक्षता.

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

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

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

1. ग्राहक.

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

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

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

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

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

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

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

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

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

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