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

मई 2001

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

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

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

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

1 लोकप्रियता की मैकेनिक्स

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

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

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

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

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

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

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

2 बाहरी कारक

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

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

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

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

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

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

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

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

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

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

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

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

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

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

के बजाय

z = x+y

लिखे, उसके बुद्धि का अपमान और ईश्वर के खिलाफ पाप के बीच का कुछ होगा।

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

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

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

4 हैकेबिलिटी

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

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

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

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

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

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

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

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

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

5 फेंक देने वाले कार्यक्रम

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

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

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

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

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

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

सी वहां था क्योंकि यह ऑपरेटिंग सिस्टम के साथ आया था। पर्ल वहां था क्योंकि यह मूल रूप से प्रणाली प्रशासकों के लिए एक उपकरण था, और आपका पहले से ही इसे स्थापित कर दिया था।

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

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

6 लाइब्रेरी

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

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

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

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

7 वाक्य-रचना

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

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

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

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

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

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

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

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

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

8 दक्षता

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

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

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

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

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

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

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

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

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

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

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

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

9 समय

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

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

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

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

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

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

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

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

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

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

10 पुनर्डिजाइन

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

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

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

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

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

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

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

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

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

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

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

11 लिस्प

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

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

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

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

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

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

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

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

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

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

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

12 सपना भाषा

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

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

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

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

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

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

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

टिप्पणियाँ

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

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

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

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