लोकप्रिय होना

मई 2001

(यह लेख एक प्रकार की व्यावसायिक योजना के रूप में लिखा गया था नई भाषा. इसलिए इसमें एक अच्छे प्रोग्रामिंग भाषा की सबसे महत्वपूर्ण विशेषता की कमी है: बहुत शक्तिशाली अमूर्तताएँ।)

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

एक भाषा को लोकप्रिय बनाने के लिए क्या आवश्यक है? क्या लोकप्रिय भाषाएँ अपनी लोकप्रियता के लायक होती हैं? क्या एक अच्छी प्रोग्रामिंग भाषा को परिभाषित करने की कोशिश करना सार्थक है? आप इसे कैसे करेंगे?

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

1 लोकप्रियता की यांत्रिकी

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

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

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

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

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

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

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

2 बाहरी कारक

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

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

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

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

कॉमन लिस्प अप्रिय है क्योंकि यह एक अनाथ है। यह मूल रूप से हैक करने के लिए एक प्रणाली के साथ आया था: लिस्प मशीन। लेकिन लिस्प मशीनें (साथ ही समानांतर कंप्यूटर) 1980 के दशक में सामान्य प्रयोजन प्रोसेसर की बढ़ती शक्ति द्वारा कुचल दी गईं। कॉमन लिस्प शायद लोकप्रिय रह सकता था यदि यह यूनिक्स के लिए एक अच्छी स्क्रिप्टिंग भाषा होती। यह, अफसोस, एक भयानक बुरी है।

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

एक प्रोग्रामिंग भाषा को एक अच्छी कार्यान्वयन की आवश्यकता होती है, और यह मुफ्त होनी चाहिए। कंपनियाँ सॉफ़्टवेयर के लिए भुगतान करेंगी, लेकिन व्यक्तिगत हैकर नहीं करेंगे, और यही हैकर हैं जिन्हें आपको आकर्षित करने की आवश्यकता है।

एक भाषा के बारे में एक पुस्तक भी होनी चाहिए। पुस्तक पतली, अच्छी तरह से लिखी गई, और अच्छे उदाहरणों से भरी होनी चाहिए। K&R यहाँ आदर्श है। इस समय मैं लगभग कहूंगा कि एक भाषा के पास O'Reilly द्वारा प्रकाशित एक पुस्तक होनी चाहिए। यही हैकरों के लिए महत्वपूर्ण होने की परीक्षा बनती जा रही है।

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

3 संक्षिप्तता

यह देखते हुए कि आप किसी भी भाषा की तीन चीजें प्रदान कर सकते हैं - एक मुफ्त कार्यान्वयन, एक पुस्तक, और कुछ हैक करने के लिए - आप एक ऐसी भाषा कैसे बनाते हैं जो हैकरों को पसंद आएगी?

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

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

x को y में जोड़कर z देना

इसके बजाय

z = x+y

उसकी बुद्धिमत्ता के लिए एक अपमान और भगवान के खिलाफ एक पाप के बीच कुछ है।

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

संक्षिप्तता एक जगह है जहाँ मजबूत प्रकार की भाषाएँ हार जाती हैं। सभी अन्य चीजें समान होने पर, कोई भी एक प्रोग्राम की शुरुआत एक ढेर सारे घोषणाओं के साथ नहीं करना चाहता। जो कुछ भी निहित हो सकता है, उसे होना चाहिए।

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

4 हैक करने की क्षमता

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

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

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

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

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

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

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

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

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

5 फेंकने योग्य प्रोग्राम

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

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

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

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

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

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

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

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

6 पुस्तकालय

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

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

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

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

7 व्याकरण

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

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

एक अधिक गंभीर समस्या प्रीफिक्स नोटेशन की फैलावता है। विशेषज्ञ हैकरों के लिए, यह वास्तव में एक समस्या है। कोई भी (aref a x y) नहीं लिखना चाहता जब वे a[x,y] लिख सकते हैं।

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

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

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

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

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

एक प्रसिद्ध लिस्प हैकर ने मुझे बताया कि उसका CLTL का प्रति फॉर्मेट अनुभाग पर खुलता है। मेरा भी। यह शायद सुधार की गुंजाइश को इंगित करता है। इसका मतलब यह भी हो सकता है कि प्रोग्राम बहुत सारे I/O करते हैं।

8 दक्षता

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

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

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

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

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

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

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

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

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

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

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

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

9 समय

एक लोकप्रिय भाषा को अंतिम तत्व की आवश्यकता होती है: समय। कोई भी एक ऐसी भाषा में प्रोग्राम लिखना नहीं चाहता जो गायब हो सकती है, जैसा कि कई प्रोग्रामिंग भाषाएँ करती हैं। इसलिए अधिकांश हैकर एक भाषा के चारों ओर होने की प्रतीक्षा करने की प्रवृत्ति रखते हैं, इससे पहले कि वे इसका उपयोग करने पर विचार करें।

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

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

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

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

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

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

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

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

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

10 पुन: डिज़ाइन

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

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

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

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

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

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

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

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

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

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

यहाँ एक समाधान यह हो सकता है कि सिस्टम को इस तरह डिज़ाइन किया जाए कि इंटरफेस क्षैतिज हों न कि ऊर्ध्वाधर - ताकि मॉड्यूल हमेशा ऊर्ध्वाधर रूप से अमूर्तता की परतें हों। फिर इंटरफेस एक में से एक का स्वामित्व होगा। दो स्तरों में से निचला एक भाषा होगी जिसमें ऊपरी लिखा गया है, जिस स्थिति में निचला स्तर इंटरफेस का स्वामी होगा, या यह एक दास होगा, जिस स्थिति में इंटरफेस को ऊपरी स्तर द्वारा निर्धारित किया जा सकता है।

11 लिस्प

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

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

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

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

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

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

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

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

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

सर्वर-आधारित एप्लिकेशनों के लिए कोर भाषा समर्थन होना एक और बड़ा लाभ हो सकता है। उदाहरण के लिए, कई उपयोगकर्ताओं के साथ कार्यक्रमों के लिए स्पष्ट समर्थन, या प्रकार टैग के स्तर पर डेटा स्वामित्व।

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

12 द ड्रीम लैंग्वेज

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

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

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

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

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

भाषा परतों में बनाई गई है। उच्च-स्तरीय अमूर्तताओं को निम्न-स्तरीय अमूर्तताओं से बहुत पारदर्शी तरीके से बनाया गया है, जिन्हें आप चाहें तो पकड़ सकते हैं।

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

नोट्स

[1] आधुनिक विचार के बहुत करीब मैक्रोज़ का प्रस्ताव 1964 में टिमोथी हार्ट द्वारा किया गया था, लिस्प 1.5 के रिलीज़ होने के दो साल बाद। प्रारंभ में जो गायब था, वह था चर कैप्चर और कई मूल्यांकन से बचने के तरीके; हार्ट के उदाहरण दोनों के अधीन हैं।

[2] व्हेन द एयर हिट्स योर ब्रेन में, न्यूरोसर्जन फ्रैंक वर्टोसिक एक बातचीत का वर्णन करते हैं जिसमें उनके मुख्य निवासी, गैरी, सर्जनों और इंटर्निस्टों ("पिस्सू") के बीच के अंतर के बारे में बात करते हैं:

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

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