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

मार्गदर्शक दर्शन

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. ब्रेविटी - प्रतिभा की बहन

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

मेरा मानना ​​है कि कार्यक्रमों को छोटा बनाने वाली लगभग सभी चीजें अच्छी हैं। पुस्तकालय कार्यों का एक बहुत कुछ होना चाहिए, जो कुछ भी निहित हो सकता है - ऐसा होना चाहिए; वाक्यविन्यास अधिक संक्षिप्त होना चाहिए; यहां तक ​​कि संस्था के नाम भी कम होने चाहिए।

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

5. हैकिंग क्या है, इसे पहचानें।

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

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

खुले मुद्दे

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

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

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

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

3. आपको सर्वर सॉफ़्टवेयर की क्या आवश्यकता है?

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

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

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

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

4. किन नए अमूर्त को खोलना बाकी है?

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

अल्पज्ञात रहस्य

1. आप अपनी इच्छानुसार किसी भी भाषा का उपयोग कर सकते हैं

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

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

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

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

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

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

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

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

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

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

4. भाषा को एक बार के कार्यक्रम लिखने के लिए उपयुक्त होना चाहिए।

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

5. शब्दार्थ से संबंधित सिंटेक्स

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

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

समय के साथ वापस आने वाले विचार

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

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

2. समय साझा करना

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

3. दक्षता

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

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

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

जाल और जाल

1. ग्राहक

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

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

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

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

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

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

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

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

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

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