नर्डों का बदला

मई 2002

"हम सी++ प्रोग्रामर्स के पीछे थे। हमने उनमें से कई को लगभग आधा लिस्प तक खींच लिया।"

• गाय स्टील, जावा विनिर्देश के सह-लेखक

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

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

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

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

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

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

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

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

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

सभी प्रोग्रामिंग भाषाएं समकक्ष हैं कि मानने का नुकसान यह है कि यह सच नहीं है। लेकिन लाभ यह है कि यह आपका जीवन काफी सरल बना देता है। और मुझे लगता है कि यही कारण है कि यह विचार इतना व्यापक है। यह एक आरामदायक विचार है।

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

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

गणित के साथ पकड़ना

मतलब यह है कि लिस्प को पहली बार जॉन मैकार्थी ने 1958 में खोजा था, और लोकप्रिय प्रोग्रामिंग भाषाएं अब तक उन विचारों को पकड़ रही हैं जिन्हें उसने उस समय विकसित किया था।

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

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

जैसा कि मैकार्थी ने बाद में कहा,

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

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

यह समय के लिए एक बड़ा आश्चर्य था। मैकार्थी ने बाद में एक साक्षात्कार में इसके बारे में क्या कहा, यह इस प्रकार है:

स्टीव रसेल ने कहा, देखो, मैं इस eval को... प्रोग्राम क्यों नहीं करता, और मैंने उससे कहा, हो, हो, तुम सिद्धांत और व्यवहार को मिला रहे हो, यह eval पढ़ने के लिए है, न कि कंप्यूटिंग के लिए। लेकिन उसने आगे बढ़कर ऐसा ही किया। अर्थात, उसने मेरे पेपर में eval को [IBM] 704 मशीन कोड में कंपाइल किया, बग्स को ठीक किया, और फिर इसे एक लिस्प इंटरप्रेटर के रूप में विज्ञापित किया, जो यह निश्चित रूप से था। इसलिए उस समय लिस्प ने वह रूप ले लिया जो आज भी है....

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

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

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

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

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

लिस्प को अलग क्या बनाता है

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

शर्तीय। एक शर्तीय एक if-then-else संरचना है। हम अब इन्हें सामान्य मान लेते हैं, लेकिन फोर्ट्रान I में ये नहीं थे। इसमें केवल एक शर्तीय goto था जो मूल मशीन निर्देश पर आधारित था।

एक फ़ंक्शन प्रकार। लिस्प में, फ़ंक्शन एक डेटा प्रकार हैं जैसे कि पूर्णांक या स्ट्रिंग्स। उनका एक सादृश्य प्रतिनिधित्व है, वे चरों में संग्रहीत किए जा सकते हैं, तर्कों के रूप में पारित किए जा सकते हैं, और इत्यादि।

पुनर्कृति। लिस्प पहली प्रोग्रामिंग भाषा थी जो इसका समर्थन करती थी।

गतिशील टाइपिंग। लिस्प में, सभी चर प्रभावतः पॉइंटर हैं। मूल्य ही हैं जिनका प्रकार होता है, न कि चर, और चर को असाइन या बाइंड करना पॉइंटर कॉपी करना है, न कि वे जिस पर इशारा करते हैं।

गार्बेज-संग्रह।

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

यह अंतर फोर्ट्रान I में प्राकृतिक था क्योंकि आप कथनों को घेर नहीं सकते थे। और इसलिए जबकि गणित के लिए आप अभिव्यक्तियों की आवश्यकता रखते थे, कुछ और लौटाने का कोई मतलब नहीं था, क्योंकि कुछ भी इसका इंतजार नहीं कर रहा था।

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

एक प्रतीक प्रकार। प्रतीक वास्तव में एक हैश टेबल में संग्रहीत स्ट्रिंग्स के पॉइंटर हैं। इसलिए आप एक पॉइंटर की तुलना करके समानता जांच सकते हैं, प्रत्येक वर्ण की तुलना करने के बजाय।

कोड के लिए एक नोटेशन जो प्रतीकों और स्थायी मूल्यों के पेड़ों का उपयोग करता है।

पूरा भाषा वहीं है। पठन-समय, कंपाइल-समय और रन-समय के बीच कोई वास्तविक अंतर नहीं है। आप पठन के दौरान कंपाइल या चलाया जा सकता है, पठन या चलाया जा सकता है कंपाइल के दौरान, और पठन या कंपाइल रन-समय पर किया जा सकता है।

पठन-समय पर कोड चलाना लिस्प के वाक्य-विन्यास को पुनर्प्रोग्राम करने देता है; कंपाइल-समय पर कोड चलाना मैक्रोज का आधार है; रन-समय पर कंपाइल एमेक्स जैसे कार्यक्रमों में एक्सटेंशन भाषा के रूप में लिस्प के उपयोग का आधार है; और रन-समय पर पठन s-अभिव्यक्तियों का उपयोग करके क

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

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

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

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

मैं इसका उल्लेख मुख्य रूप से एक मजाक के रूप में करता हूं, लेकिन यह बिल्कुल सच है। अगर आप एक ऐसी भाषा को परिभाषित करते हैं जिसमें car, cdr, cons, quote, cond, atom, eq और फ़ंक्शन को सूचियों के रूप में व्यक्त करने का एक संकेत है, तो आप लिस्प का बाकी सब कुछ बना सकते हैं। यही लिस्प की परिभाषित विशेषता है: मैकार्थी ने लिस्प को इस आकार में इसलिए दिया ताकि यह संभव हो।

जहां भाषाएं महत्वपूर्ण हैं

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

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

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

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

केंद्रीय बलों

मैं यह नहीं कह रहा कि अनकॉमन प्रौद्योगिकियों का उपयोग करने में कोई लागत नहीं है। पॉइंटी-हेयर्ड बॉस इस चिंता में पूरी तरह से गलत नहीं है। लेकिन क्योंकि वह इन जोखिमों को नहीं समझता, वह उन्हें बढ़ा-चढ़ाकर प्रस्तुत करता है।

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

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

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

लाइब्रेरीज़ की महत्वपूर्णता भी एप्लिकेशन पर नि

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

वास्तव में, एक अधिक शक्तिशाली भाषा का चयन करना संभवतः आपकी टीम के आकार को कम कर सकता है, क्योंकि (क) यदि आप एक अधिक शक्तिशाली भाषा का उपयोग करते हैं, तो आपको संभवतः इतने हैकर्स की आवश्यकता नहीं होगी, और (ख) अधिक उन्नत भाषाओं में काम करने वाले हैकर्स संभवतः अधिक स्मार्ट होंगे।

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

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

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

औसत होने की कीमत

एक कम शक्तिशाली भाषा का उपयोग करके आप कितना खोते हैं? वास्तव में, इस बारे में कुछ आंकड़े भी हैं।

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

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

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

तो लिस्प में अपने कार्यक्रम लिखने से आपके कार्यक्रम कितने छोटे हो जाते हैं? लिस्प और सी के बीच मैंने जो भी संख्याएं सुनी हैं, वे लगभग 7-10 गुना रही हैं। लेकिन न्यू आर्किटेक्ट पत्रिका में आईटीए के बारे में एक हाल ही का लेख में कहा गया था कि "एक लाइन लिस्प 20 लाइन सी को प्रतिस्थापित कर सकती है", और चूंकि यह लेख आईटीए के अध्यक्ष के उद्धरणों से भरा हुआ है, इसलिए मैं मान सकता हूं कि उन्होंने यह संख्या आईटीए से ली है। यदि ऐसा है, तो हम इस पर भरोसा कर सकते हैं; आईटीए का सॉफ्टवेयर कई सी और सी++ के साथ-साथ लिस्प भी शामिल करता है, इसलिए वे अनुभव से बोल रहे हैं।

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

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

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

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

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

एक रेसिपी

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

बड़ी संगठनों में, इस दृष्टिकोण का वर्णन करने के लिए प्रयुक्त शब्द "उद्योग की सर्वश्रेष्ठ प्रथा" है। इसका उद्देश्य पॉइंटी-हेयर्ड बॉस को जिम्मेदारी से बचाना है: यदि वह "उद्योग की सर्वश्रेष्ठ प्रथा" का चयन करता है, और कंपनी हार जाती है, तो उसे दोषी ठहराया नहीं जा सकता। उसने चयन नहीं किया, उद्योग ने किया।

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

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

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

परिशिष्ट: शक्ति

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

(यह बढ़ाकर, न कि प्लस है। एक संचयक को संचित करना होता है।)

कॉमन लिस्प में यह इस तरह होगा:

(defun foo (n)
(lambda (i) (incf n i)))

और पर्ल 5 में,

sub foo {
my ($n) = @_;
sub {$n += shift}
}

जिसमें लिस्प वर्शन से अधिक तत्व हैं क्योंकि पर्ल में आपको मैन्युअल रूप से पैरामीटर निकालने होते हैं।

स्मॉलटॉक में कोड लिस्प से थोड़ा लंबा है

foo: n
|s|
s := n.
^[:i| s := s+i. ]

क्योंकि हालांकि सामान्य रूप से लेक्सिकल चर काम करते हैं, आप एक पैरामीटर में एक असाइनमेंट नहीं कर सकते, इसलिए आपको एक नया चर s बनाना होता है।

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

function foo(n) {
return function (i) {
return n += i } }

(इंसाफ के लिए, पर्ल भी इस अंतर को बरकरार रखता है, लेकिन इसे टाइपिकल पर्ल तरीके से संभालता है जहां आप रिटर्न को छोड़ सकते हैं।)

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

def foo(n):
s = [n]
def bar(i):
s[0] += i
return s[0]
return bar

पायथन उपयोगकर्ता वैध रूप से पूछ सकते हैं कि वे क्यों नहीं लिख सकते

def foo(n):
return lambda i: return n += i

या यहां तक कि

def foo(n):
lambda i: n += i

और मेरा अनुमान है कि वे शायद एक दिन ऐसा करेंगे। (लेकिन यदि वे पायथन को लिस्प में विकसित होने का इंतजार नहीं करना चाहते हैं, तो वे हमेशा...)

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

पायथन विशेषज्ञ इस समस्या को पायथन में हल करने का प्राथमिक तरीका यह है कि वे या तो लिखते हैं

def foo(n):
class acc:
def __init__(self, s):
self.s = s
def inc(self, i):
self.s += i
return self.s
return acc(n).inc

या

class foo:
def __init__(self, n):
self.n = n
def __call__(self, i):
self.n += i
return self.n

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

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

अन्य भाषाओं के बारे में क्या? इस वक्तव्य में उल्लिखित अन्य भाषाओं - फोर्ट्रान, सी, सी++, जावा और विजुअल बेसिक - में यह स्पष्ट नहीं है कि क्या आप वास्तव में इस समस्या को हल कर सकते हैं। केन एंडरसन कहते हैं कि जावा में निम्नलिखित कोड लगभग इतना करीब है जितना आप प्राप्त कर सकते हैं:

public interface Inttoint {
public int call(int i);
}

public static Inttoint foo(final int n) {
return new Inttoint() {
int s = n;
public int call(int i) {
s = s + i;
return s;
}};
}

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

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

यह एक मजाक की तरह लगता है, लेकिन यह बड़े प्रोग्रामिंग परियोजनाओं में इतनी बार होता है कि इस घटना के लिए एक नाम है, ग्रीनस्पन का दसवां नियम:

किसी भी पर्याप्त रूप से जटिल सी या फोर्ट्रान कार्यक्रम में कॉमन लिस्प का आधा अनौपचारिक रूप से निर्दिष्ट बग-रहित धीमा कार्यान्वयन होता है।

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

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

नोट्स

IBM 704 CPU एक रेफ्रिजरेटर के आकार का था, लेकिन काफी भारी। CPU का वजन 3150 पाउंड था, और 4K RAM एक अलग बॉक्स में था जिसका वजन 4000 पाउंड था। सब-जीरो 690, घरेलू रेफ्रिजरेटरों में से सबसे बड़ा, 656 पाउंड का होता है।

स्टीव रसेल ने 1962 में पहला (डिजिटल) कंप्यूटर गेम, स्पेसवार, भी लिखा।

यदि आप किसी पॉइंटी-हेयर्ड बॉस को लिस्प में सॉफ्टवेयर लिखने देने के लिए धोखा देना चाहते हैं, तो आप उसे बता सकते हैं कि यह XML है।

यहां अन्य लिस्प डायलेक्ट्स में संचयक जनरेटर है:

Scheme: (define (foo n)
(lambda (i) (set! n (+ n i)) n))
Goo:    (df foo (n) (op incf n _)))
Arc:    (def foo (n) [++ n _])

एरान गैट का "उद्योग की सर्वश्रेष्ठ प्रथा" पर दुखद कहानी ने मुझे इस आम रूप से गलत लागू होने वाले वाक्यांश को संबोधित करने के लिए प्रेरित किया।

पीटर नोर्विग ने पाया कि डिजाइन पैटर्न में से 16 में से 23 पैटर्न लिस्प में "अदृश्य या सरल" थे।

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

संबंधित:

इस वार्ता के बहुत से लोगों ने जवाब दिया है, इसलिए मैंने उन मुद्दों से निपटने के लिए एक अतिरिक्त पृष्ठ बनाया है जो उन्होंने उठाए हैं: रिवेंज ऑफ द नर्ड्स पर।

यह LL1 मेलिंग सूची पर भी एक व्यापक और अक्सर उपयोगी चर्चा छेड़ दी। विशेष रूप से एंटन वैन स्ट्रेटन द्वारा भेजे गए मेल पर देखें।

LL1 पर कुछ मेल ने मुझे शक्ति है संक्षिप्तता में भाषा शक्ति के विषय में गहराई से जाने के लिए प्रेरित किया।

संचयक जनरेटर बेंचमार्क के कैनोनिकल कार्यान्वयन का एक बड़ा सेट अपने पृष्ठ पर एकत्रित किया गया है।

जापानी अनुवाद, स्पेनिश अनुवाद, चीनी अनुवाद