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

मई 2001

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

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. समिति द्वारा डिजाइन।

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

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