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

मई 2001

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

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

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

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

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

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

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

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

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

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

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

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

2 बाह्य कारक

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

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

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

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

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

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

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

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

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

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

यह देखते हुए कि आप किसी भी भाषा के लिए आवश्यक तीन चीजें उपलब्ध करा सकते हैं - एक निःशुल्क कार्यान्वयन, एक पुस्तक, तथा हैक करने के लिए कुछ - तो आप ऐसी भाषा कैसे बना सकते हैं जो हैकर्स को पसंद आए?

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

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

x को y में जोड़ने पर z प्राप्त होता है

के बजाय

ज़ेड = एक्स+वाई

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

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

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

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

4 हैकेबिलिटी

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

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

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

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

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

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

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

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

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

5 थ्रोअवे प्रोग्राम

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

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

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

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

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

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

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

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

6 पुस्तकालय

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

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

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

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

7 वाक्यविन्यास

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

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

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

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

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

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

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

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

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

8 दक्षता

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

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

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

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

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

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

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

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

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

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

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

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

9 समय

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

11 लिस्प

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

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

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

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

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

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

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

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

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

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

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

12 स्वप्न भाषा

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

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

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

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

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

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

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

नोट्स

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

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

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

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