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

मई 2001

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

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

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

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

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

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

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

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

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

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

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

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

2 बाहरी कारक

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

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

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

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

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

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

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

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

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

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

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

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

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

add x to y giving z

इसके बजाय

z = x+y

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

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

4 हैकबिलिटी

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

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

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

कॉमन लिसप में मैं अक्सर एक संरचना के क्षेत्रों के माध्यम से पुनरावृति करना चाहता था

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6 लाइब्रेरी

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

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

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

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

7 सिंटैक्स

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

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

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

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

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

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

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

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

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

8 दक्षता

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

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

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

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

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

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

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

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

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

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

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

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

9 समय

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

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

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

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

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

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

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

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

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

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

10 पुनर्निर्माण

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

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

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

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

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

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

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

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

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

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

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

11 लिसप

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

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

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

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

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

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

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

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

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

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

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

12 सपनों की भाषा

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

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

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

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

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

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

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

नोट्स

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

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

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

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