नर्ड्स का बदला

मई 2002

"हम C++ प्रोग्रामर के पीछे थे। हम उनमें से बहुतों को Lisp तक आधे रास्ते तक खींचने में कामयाब रहे।"

• गाय स्टील, जावा स्पेक के सह-लेखक

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

क्या Lisp को अलग बनाता है

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

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

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

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

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

कचरा संग्रह।

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

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

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

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

प्रतीकों और स्थिरांक के पेड़ों का उपयोग करके कोड के लिए एक संकेतन।

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

पढ़ने के समय कोड चलाने से उपयोगकर्ता Lisp के सिंटैक्स को फिर से प्रोग्राम कर सकते हैं; संकलन समय पर कोड चलाना मैक्रोज़ का आधार है; संकलन रनटाइम पर कोड Emacs जैसे प्रोग्राम में एक एक्सटेंशन भाषा के रूप में Lisp के उपयोग का आधार है; और रनटाइम पर पढ़ना कार्यक्रमों को s-अभिव्यक्तियों का उपयोग करके संवाद करने में सक्षम बनाता है, एक विचार जिसे हाल ही में XML के रूप में फिर से बनाया गया है।

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

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

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

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

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

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

जहाँ भाषाएँ मायने रखती हैं

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

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

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

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

अभिकेन्द्रीय बल

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

एक नुस्खा

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

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

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

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

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

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

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

(यह 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 _])

एरन गेट की दुखद कहानी JPL में "उद्योग का सर्वोत्तम अभ्यास" ने मुझे संबोधित करने के लिए प्रेरित किया यह आम तौर पर गलत तरीके से लागू किया गया वाक्यांश।

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

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

संबंधित:

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

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

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

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

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