हैकर और पेंटर

मई 2003

(यह निबंध हार्वर्ड में एक अतिथि व्याख्यान से लिया गया है, जिसमें पूर्वोत्तर में एक प्रारंभिक वार्ता को शामिल किया गया है।)

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

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

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

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

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

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

शायद एक दिन "कंप्यूटर विज्ञान" यूगोस्लाविया की तरह अपने घटक भागों में टूट जाएगा। यह एक अच्छी बात हो सकती है। खासकर अगर इसका मतलब मेरे मूल देश, हैकिंग की स्वतंत्रता हो।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

क्योंकि हैकर वैज्ञानिक के बजाय निर्माता होते हैं, इसलिए रूपकों को विज्ञान में नहीं, बल्कि अन्य प्रकार के निर्माताओं के बीच खोजना सही जगह है। पेंटिंग हमें हैकिंग के बारे में और क्या सिखा सकती है?

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

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

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

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

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

लेखक भी ऐसा करते हैं। बेंजामिन फ्रैंकलिन ने एडिसन और स्टील के निबंधों के बिंदुओं को सारांशित करके और फिर उन्हें पुन: पेश करने का प्रयास करके लिखना सीखा। रेमंड चैंडलर ने जासूसी कहानियों के साथ भी ऐसा ही किया।

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

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

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

(बड़ी कंपनियों की संरचना इसे उनके लिए करना कठिन बनाती है, इसलिए यहां एक और जगह है जहां स्टार्टअप को फायदा होता है।)

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

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

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

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

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

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

यदि कोई हैकर केवल एक कार्यान्वयनकर्ता होता, जो एक विनिर्देश को कोड में बदलता, तो वह खाई खोदने वाले की तरह एक छोर से दूसरे छोर तक अपना रास्ता बना सकता था। लेकिन अगर हैकर एक निर्माता है, तो हमें प्रेरणा को ध्यान में रखना होगा।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

प्रोग्राम लोगों के पढ़ने के लिए लिखे जाने चाहिए, और केवल संयोग से मशीनों द्वारा निष्पादित किए जाने के लिए।

आपको न केवल अपने उपयोगकर्ताओं के लिए, बल्कि अपने पाठकों के लिए भी सहानुभूति की आवश्यकता है। यह आपके हित में है, क्योंकि आप उनमें से एक होंगे। कई हैकर्स ने एक प्रोग्राम लिखा है केवल छह महीने बाद उस पर लौटने पर यह पता लगाने के लिए कि उन्हें यह नहीं पता कि यह कैसे काम करता है। मैं ऐसे अनुभवों के बाद पर्ल से दूर रहने वाले कई लोगों को जानता हूं। [7]

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

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

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

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

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

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

लियोनार्डो के समय में पेंटिंग उतनी अच्छी नहीं थी जितनी उसके काम ने इसे बनाया। हैकिंग कितनी अच्छी साबित होती है, यह इस बात पर निर्भर करेगा कि हम इस नए माध्यम के साथ क्या कर सकते हैं।

नोट्स

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

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

[3] आप कॉलेज में प्रोग्रामिंग के बारे में जो सीखते हैं वह किताबों या कपड़ों या डेटिंग के बारे में आप जो सीखते हैं, उसके समान है: हाई स्कूल में आपका स्वाद कितना खराब था।

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

[5] टेक्स्ट एडिटर और कंपाइलर को छोड़कर। हैकर्स को इन्हें डिजाइन करने के लिए सहानुभूति की आवश्यकता नहीं है, क्योंकि वे स्वयं विशिष्ट उपयोगकर्ता हैं।

[6] खैर, लगभग। उन्होंने उपलब्ध रैम को कुछ हद तक पार कर लिया, जिससे बहुत अधिक असुविधाजनक डिस्क स्वैपिंग हुई, लेकिन इसे कुछ महीनों के भीतर एक अतिरिक्त डिस्क ड्राइव खरीदकर ठीक किया जा सकता था।

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

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