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

मई 2003

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

सोर्स कोड को भी खुद को समझाना चाहिए। अगर मैं लोगों को प्रोग्रामिंग के बारे में सिर्फ एक उद्धरण याद रखने के लिए कह सकता हूं, तो वह होगा Structure and Interpretation of Computer Programs. की शुरुआत में वाला।

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

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

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

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

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

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

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

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

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

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

नोट्स

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

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

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

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

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

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

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

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