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

मई 2001

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. आप जो चाहें वह भाषा इस्तेमाल कर सकते हैं।

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

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

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

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

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

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

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

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

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

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

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

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

5. सिंटैक्स सिमेंटिक्स से जुड़ा है।

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

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

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

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

2. टाइम-शेयरिंग।

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

3. दक्षता।

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

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

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

1. क्लाइंट।

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

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

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

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

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

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

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

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

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

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