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

मई 2001

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

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

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

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

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

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

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

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

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

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

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

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

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

3. प्रोग्रामर को जितना संभव हो उतनी नियंत्रण दें।

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

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

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

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

मुझे लगता है कि कार्यक्रमों को छोटा बनाने के लिए लगभग कुछ भी करना अच्छा है। लाइब्रेरी फ़ंक्शन होने चाहिए; जो कुछ भी निहित हो सकता है वह होना चाहिए; वाक्य-रचना कठोर होनी चाहिए; यहां तक कि चीजों के नाम भी छोटे होने चाहिए।

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

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

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

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

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

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

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

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

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

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

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

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

4. क्या नए सार्वजनिक अवधारणाएं खोजी जा सकती हैं?

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

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

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

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

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

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

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

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

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

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

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

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

4. एक भाषा को त्वरित कार्यक्रम लिखने के लिए अच्छा होना चाहिए।

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

5. वाक्य-रचना और अर्थशास्त्र जुड़े हुए हैं।

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

मैं हाल ही में रॉबर्ट मॉरिस से बात कर रहा था, और उन्

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

3. दक्षता।

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

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

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

1. क्लाइंट।

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

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

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

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

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

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

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

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

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

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