हैकर्स और पेंटर्स

मई 2003

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

और इस माध्यम को इतना आगे बढ़ाया कि उसके बाद से हर नाटककार को उसकी छाया में रहना पड़ा। अल्ब्रेक्ट ड्यूरर ने उत्कीर्णन के साथ और जेन ऑस्टेन ने उपन्यास के साथ यही काम किया।

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

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

नोट्स

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

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

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

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

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

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

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

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