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

मई 2001

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

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

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

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

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

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

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

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

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

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

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

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

2 बाहरी कारक

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

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

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

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

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

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

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

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

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

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

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

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

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

z को y में जोड़ें

इसके बजाय

z = x+y

कुछ ऐसा जो उसकी बुद्धि का अपमान करने और ईश्वर के विरुद्ध पाप करने के बीच हो।

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

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

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

4 हैकेबिलिटी

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6 पुस्तकालय

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

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

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

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

7 वाक्य रचना

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

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

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

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

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

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

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

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

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

8 दक्षता

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

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

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

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

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

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

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

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

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

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

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

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

9 समय

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

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

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

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

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

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

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

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

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

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

10 पुन: डिजाइन

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

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

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

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

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

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

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

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

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

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

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

11 लिस्प

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

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

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

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

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

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

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

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

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

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

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

12 ड्रीम भाषा

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

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

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

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

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

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

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

नोट्स

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

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

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

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