- Gerald Sussman कहते हैं कि 1962 से IBM 7094, PDP-6, Mac Hack 6 और Maxima जैसे शुरुआती computing environments से गुजरते हुए वे प्रोग्रामिंग के अपने-आप में आनंद को लगातार पकड़े रहे
- प्रोग्रामिंग किसी specification को code में यांत्रिक रूप से बदलने वाली coding नहीं है, बल्कि अपूर्ण लक्ष्यों के तहत संभव specifications और implementation को साथ-साथ खोजने वाली abstract engineering design के ज्यादा करीब है
- Lisp की eval/apply संरचना और Maxwell equations की परस्पर क्रिया को साथ रखकर देखते हुए, वे प्रोग्रामिंग को physics, mathematics और philosophy की तरह गहरे conceptual problems से निपटने वाली creative activity मानते हैं
- bug सिर्फ failure नहीं है, बल्कि सीमित इंसान द्वारा simplified plan से समस्या हल करते समय बनने वाला learning opportunity और “लगभग सही plan को debug करने वाली problem solving” का हिस्सा है
- automatic differentiation, Scheme के generic operations का extension, और classical mechanics को executable program के रूप में व्यक्त करने के अनुभव दिखाते हैं कि प्रोग्रामिंग दूसरे disciplines को स्पष्ट बना सकती है; और वे जोर देते हैं कि free/libre software के रूप में share करने पर इसका मज़ा पूरा होता है
Coding से आगे design और exploration
- Sussman ने 1962 में high school student रहते हुए computer इस्तेमाल करना शुरू किया, और Columbia Science Honors Program में computing से परिचित हुए
- शुरुआती computers IBM 7094 series जैसी machines थीं, जिनकी कीमत कई million dollars होती थी, जो केवल 2^15 36-bit words को address कर सकती थीं, और लगभग 2 microsecond cycle पर चलती थीं
- MIT में आने के बाद उन्हें DEC PDP-6 जैसे computers मिले, और वह system 2^18 36-bit words को address कर सकता था
- बड़ी memory Maxima जैसे शुरुआती symbolic manipulation systems के लिए जरूरी थी
- MIT ने Fabritek को बड़ी memory का order दिया, उसे बनाने में 1 साल लगा, और records के अनुसार उसकी कीमत लगभग 380,000 dollars थी
- यह memory उस समय बहुत बड़ी थी, इसलिए whale के नाम पर इसे Moby कहा गया
- वे artificial intelligence, नए computer design, programming languages के आविष्कार, celestial mechanics की numerical simulation, और बड़े symbolic systems लिखने में शामिल रहे, लेकिन मूल में प्रोग्रामिंग के प्रति उनका लगाव बना रहा
- प्रोग्रामिंग well-defined specification को executable code में बदलने वाला mechanical काम नहीं है
- अच्छी specification आम तौर पर ऊपर से नहीं आती
- पहले यह explore किया जाता है कि क्या implement किया जा सकता है, फिर वास्तव में हासिल हो सकने वाली चीज़ के अनुसार specification लिखी जाती है
- इसलिए प्रोग्रामिंग partially defined goals की ओर संभव specification और implementation को साथ-साथ खोजने वाली joint exploration है
- physical engineering के उलट, प्रोग्रामिंग tolerances, cutting curvature, resistance errors जैसी physical constraints की तुलना में thoughts को organize करने की क्षमता से ज्यादा सीमित होती है
- programmer representations, algorithms और abstraction levels चुनते हुए एक विशाल virtual machine से काम करता है
Creative art के रूप में प्रोग्रामिंग
- Sussman ने प्रोग्रामिंग के एहसास को समझाने के लिए Edgar Allan Poe द्वारा 「The Raven」 लिखने की प्रक्रिया पर लिखे गए लेख को quote किया
- Poe कहते हैं कि रचना accident या intuition से नहीं, बल्कि mathematical problem की तरह step by step पूरी हुई, और वे selection, deletion, insertion और revision की जटिल process दिखाते हैं
- यह process specification को code में बदलने वाले काम की तुलना में वास्तविक प्रोग्रामिंग के एहसास के ज्यादा करीब है
- प्रोग्रामिंग architecture, music, mathematics और theoretical physics की तरह creative art के करीब है
- mathematics सुंदर theorems invent करने की activity है
- theoretical physics physical world की explanations invent करने की activity है
- प्रोग्रामिंग भी ideas और structures invent और refine करने की activity है
eval/apply और Maxwell equations ने जो structure दिखाया
- MIT first year में Lisp 1.5 और eval/apply interpreter सीखने का अनुभव Sussman के जीवन को बदलने वाला मोड़ था
- eval expression और environment लेकर operators और operands को evaluate करता है ताकि procedure और arguments बनें, और apply procedure और arguments लेकर formal parameters में arguments bind करता है और फिर body evaluation पर लौटता है
- Sussman मानते हैं कि यह structure सभी computer languages और खुद computer के operating mechanism पर भी लागू होता है
- उसी समय electromagnetism class में Maxwell equations सीखते हुए उन्हें एक और गहरा प्रभाव मिला
- Maxwell ने charge conservation और existing equations की inconsistency को हल करने के लिए displacement current term जोड़ा
- इसके परिणामस्वरूप electromagnetic wave equation निकली, और यह connection बना कि light एक electromagnetic wave है
- eval/apply की interaction और Maxwell equations में electric field और magnetic field द्वारा एक-दूसरे में बदलाव पैदा करने वाली structure के बीच गहरी समानता है
- ऐसी समानता position और momentum, energy और time जैसे dual variables के संबंध से भी जुड़ती है
- प्रोग्रामिंग रोजमर्रा में philosophical problems से मिलती है
- program के अंदर
Chicagoनाम असली शहर की ओर कैसे इशारा करता है, यह सरल नहीं है - दो objects identical हैं या नहीं, यह तब सामने आता है जब एक को बदलने पर दूसरा भी बदलता है या नहीं; और mutation identity problem से जुड़ता है
- pure functional programs में mutation नहीं होता, इसलिए identity को अलग तरह से देखना पड़ता है
- quoted expression के अंदर “same चीज़ को same चीज़ से replace किया जा सकता है” वाला principle टूट सकता है
- “सभी ravens काले होते हैं” जैसा proposition Hempel के Raven Paradox की तरह evidence के meaning को कठिन बना देता है
- program के अंदर
Bugs से निपटने का तरीका
- Sussman bug को शर्मनाक failure नहीं, बल्कि learning opportunity मानते हैं
- अच्छे tools से debugging करना adventure जैसा मज़ेदार हो सकता है, और वे कहते हैं कि bugs के नाम होने चाहिए, जैसे fencepost error या reader-writer bug
- bug powerful design strategy का परिणाम भी होता है
- इंसान सब कुछ एक साथ नहीं सोच सकते, इसलिए वे plan बनाते हैं
- plan simplification मांगता है, और simplification छूटे हुए हिस्से बनाती है
- नतीजतन bug पैदा होता है, और debugging लगभग सही plan को desired direction में सुधारते जाने की process बन जाती है
- Sussman इसे “लगभग सही plan को debug करने वाली problem solving” कहते हैं
- electric filter design का example इस strategy को दिखाता है
- 30Hz से 3kHz के बीच response वाला filter बनाने के लिए system function को factorize किया जाता है
- resistors और capacitors को combine करके जरूरी subcircuits बनाए जाते हैं
- लेकिन हर subcircuit में “current बाहर नहीं आता” वाली assumption होती है, इसलिए साथ जोड़ने पर loading bug बनता है
- amplifier patch कुछ situations में इस problem को हल कर सकता है
- सभी bugs मज़ेदार नहीं होते
- Sussman C और C++ की आलोचना करते हैं कि वे traps से भरे हैं
- वे memory management bugs के कारण नया kernel अक्सर जरूरी होने वाली स्थिति को भी C में लिखे code से जोड़ते हैं
- Python में भी वे consistency की कमी के examples देते हैं:
{}dictionary है लेकिन{1}set है, और tuple parentheses से नहीं बल्कि comma से define होता है
Automatic differentiation और executable physics
- 1992 में Sussman Caltech में Kip Thorne group के साथ रहे और general relativity सीखी; वे कहते हैं कि उन्होंने programs को knowledge store करने के medium के रूप में इस्तेमाल किया
- Hewlett-Packard के floating-point chip designer Dan के साथ function के derivative पर सोचते हुए उन्होंने forward-mode automatic differentiation को स्वतंत्र रूप से फिर खोजा
- लक्ष्य ऐसा तरीका था जो function के अंदर झांकने वाली symbolic differentiation भी न हो और numerical approximation भी न हो
- core idea chain rule था
- अगर numbers को finite part और infinitesimal part वाले differential object तक extend किया जाए, तो function composition में chain rule अपने-आप काम करता है
- Scheme इस्तेमाल करने के कारण primitive arithmetic operators को differential object के अनुसार redefine किया जा सकता था, और Sussman ने इसे “hack attack” के रूप में रातोंरात implement कर दिया
- बाद में कई लोगों ने higher-order functions के derivatives, multiple derivatives, और Scheme के primitive operations के dynamic extension को refine करने में योगदान दिया
- Abelson ने multiple derivatives की सही theory व्यवस्थित करने में मदद की
- Jeff Siskind, Barak Pearlmutter और Alexey Radul ने higher-order function derivatives के subtle bugs debug किए
- Hansen ने Scheme के primitive operations को efficiently dynamically extend करने का तरीका निकाला
- यह काम Jack Wisdom के साथ इस्तेमाल किए गए Scmutils system तक पहुंचा, और इसका इस्तेमाल classical mechanics और differential geometry पढ़ाने और research में हुआ
- Sussman और Wisdom की 『Structure and Interpretation of Classical Mechanics』 classical mechanics की समझ को computational techniques से स्पष्ट करने की किताब है
- traditional Lagrange equation notation cultural knowledge के बिना ambiguous है, और function types के viewpoint से भी problematic है
- functional notation और Scheme code में लिखने पर mathematical ideas clear और executable programs बन जाते हैं
- harmonic oscillator example में mass, spring constant और position के लिए सही equations of motion और angular frequency relationship calculate किया जाता है
Share होने पर पूरा होने वाला मज़ा
- Sussman प्रोग्रामिंग के आनंद को कई हिस्सों में summarize करते हैं
- अलग-अलग worlds के बीच गहरी समानताएं खोजने का आनंद
- philosophers ने जिन problems पर लंबे समय तक विचार किया, उन्हें वास्तविक काम में सामने पाने का आनंद
- bugs को track करने वाली hunt का आनंद
- अच्छे ideas और abstractions खोजने का आनंद
- programs से दूसरे disciplines को स्पष्ट बनाने का आनंद
- प्रोग्रामिंग का मज़ा तब पूरा होता है जब काम दूसरों के साथ share किया जाए, और वे free/libre software के use और creation की सलाह देते हैं
- Sussman इस बात पर अफसोस जताते हैं कि recording Zoom से करनी पड़ी, और कहते हैं कि वे ऐसा software चाहते हैं जिसे पढ़ा, modify किया और फिर share किया जा सके
- free software और software freedom के बारे में वे GNU की free software philosophy देखने की सलाह देते हैं, और Free Software Foundation में participation और donation का अनुरोध करते हैं
1 टिप्पणियां
Hacker News टिप्पणियां
यह हिस्सा सच में बहुत अच्छा लगा: “प्रोग्राम को किसी चीज़ को याद रखने के तरीके के रूप में लिखता हूं। मेरी याददाश्त वे प्रोग्राम हैं जो मैंने लिखे हैं। गणित, भौतिकी, जीवविज्ञान जैसी चीज़ें सीखकर उन्हें व्यक्त करने वाले प्रोग्राम लिखकर रख दूं, तो बाद में पढ़ने पर भी वे अस्पष्ट नहीं होते और समझने में आसान रहते हैं; इस तरह मैं ज्ञान को सहेजता हूं”
https://www.infoq.com/presentations/Expression-of-Ideas/
ऊपर के उद्धरण से इसका विषय बहुत करीब है, और यह बताता है कि प्रोग्रामिंग गणित·भौतिकी जैसी चीज़ों को गहराई से समझने में कैसे मदद करती है
उदाहरण के लिए दर्दनिवारक दवाएं कैसे काम करती हैं, यह keylogger या man-in-the-middle attack समझने में मदद करता है, और mitosis के दौरान DNA की “grammar check” देखने से compilation के बारे में बहुत कुछ सीखा जा सकता है
पिल्ले का दिखने वाली हर चीज़ निगल लेना मानो immune system को आसपास के environment पर पर्याप्त test data देना है, इसलिए यह machine learning से भी मिलता-जुलता है, और cybersecurity की कई अवधारणाएं भी जीवविज्ञान से समझी जा सकती हैं
मैं चित्रों में सोचता हूं, इसलिए गणित को सच में समझना मुश्किल था, लेकिन coding ने मुझे दिमाग में चित्र और संबंध बनाने दिए
बचपन में यह जान पाना मेरी किस्मत थी; इसके बिना शायद मैं भटक गया होता
समस्या, निर्णय, कारण, आधार बने तथ्य, और विचार किए गए विकल्प—ये सब ज्ञान हैं, और programming language में टाइप किया गया हर command भी एक निर्णय है—यह दृष्टिकोण है
software design इतना लंबा चल सकता है कि पुराने निर्णय और उनका context भुला दिए जाएं, और इतना लंबा भी कि लोग चले जाएं, ज्ञान गायब हो जाए, और नए लोगों में ज्ञान की कमी रह जाए
कंप्यूटर को source code समझाना कठिन हिस्सा नहीं है; ज़्यादा कठिन यह है कि दूसरे लोग समझ सकें कि क्या किया गया है और वे बेहतर व तेज़ काम कर सकें
जब सिर और याददाश्त पर्याप्त न हों, तो writing, printing, software जैसी तकनीकों की मदद से ज्ञान के बड़े गुच्छों को याद रखना और व्यवस्थित करना पड़ता है
गणित में सबसे बड़ी समस्या भी यही थी कि मैं भरोसा नहीं कर सकता था कि मुझसे गलती नहीं होगी, और यह भी नहीं कि मैं गलती पकड़ लूंगा
compiler या interpreter मुझे नोटिस करा देता है
पहले कभी NYU के basement में करीब 20 neuroscience PhD छात्रों के साथ Sussman का व्याख्यान सुना था
AI interpretability चलन में आने से बहुत पहले से वे इस विषय पर बात कर रहे थे
मैंने एक सवाल पूछा, तो उन्होंने तुरंत भांप लिया कि कमरे में कोई electrical engineering background वाला है, साइड वाले blackboard पर गए, और दिखाया कि operational amplifier कैसे काम करता है, यह first principles से निकाला जा सकता है
उनमें जबरदस्त ऊर्जा और बुद्धि थी, और उन्होंने निश्चित रूप से गहरी छाप छोड़ी
वीडियो अभी नहीं देखा है, लेकिन SICP की समर्पण-पंक्ति में Sussman और Abelson द्वारा इस्तेमाल किया गया Alan J. Perlis का उद्धरण तुरंत याद आ गया
इसका आशय है कि computer science में computing का मज़ा बचाए रखना बहुत महत्वपूर्ण है, और शुरुआती दिनों में यह सच में बहुत मज़ेदार था
ग्राहक कभी-कभी नुकसान भी उठाते थे और हमने उनकी शिकायतों को गंभीरता से लेना शुरू किया, लेकिन हमारा दृष्टिकोण यह नहीं है कि इस मशीन के सफल, त्रुटिरहित और परफेक्ट उपयोग की जिम्मेदारी हमारी है
बल्कि हमारी जिम्मेदारी मशीन को आगे धकेलने, नई दिशाओं में भेजने और मज़ा बनाए रखने की है; उम्मीद है कि computer science अपना sense of fun नहीं खोएगी, और missionary या Bible salesman जैसा व्यवहार नहीं करेगी—मुख्य बात यही है
यह महसूस न करें कि सफल computing की कुंजी केवल हमारे हाथ में है; हमारे हाथ में जो है वह बुद्धि है—यानी मशीन को पहली बार देखने की तुलना में उससे अधिक चीज़ें देख पाने और उसे बड़ा बना पाने की क्षमता
बाकी हममें से ज़्यादातर लोग जो bean-counting programs बनाते हैं, उनके लिए वेतन देने वाले की नज़र में एक भी bean न खोना इस बात से कहीं ज़्यादा महत्वपूर्ण है कि हमें कितना मज़ा आता है या हम संभावनाओं को कितना फैलाते हैं
यानी bug नहीं, बस मज़े का छोटा-सा टुकड़ा है /s
बेहतर शीर्षक शायद “academic computer science मज़ेदार है, या मज़ेदार होनी चाहिए” के करीब होगा
असल बात यह है कि analogies खोजने, दार्शनिक रूप से सोचने, debugging करने, अच्छे ideas लाने और clarity पाने जैसे काम सभी मज़ेदार हैं, लेकिन यह ज्यादातर उन professors की luxury है जिन्हें ऐसी गतिविधियों के लिए पैसे मिलते हैं; “customer को यह इस weekend तक चाहिए” वाली दुनिया में debugging की बहस-मज़े वाली खुशी के अलावा यह बहुत फिट नहीं बैठता
अधिकतर “programming” को शायद welding की तरह vocational school subject के रूप में देखना चाहिए
नई welding techniques विकसित करनी हों तो वह graduate-level research project हो सकता है, लेकिन अधिकांश welders और programmers जाने-माने tools और अपेक्षाकृत simple systems के साथ काम करते हैं
vocational school का छात्र MIT/GNU Scheme सीखकर ऐसी चीज़ पर समय बर्बाद नहीं करना चाहेगा जिसे वह professional life में फिर कभी इस्तेमाल नहीं करेगा, लेकिन academic student के लिए यह वैसे ही सार्थक हो सकता है जैसे linguistics major के लिए Linear B पढ़ना और लिखना सीखना
कोई भी काम मज़ेदार हो सकता है, लेकिन अंत में coworkers और managers की क्षमता व emotional stability, workspace का design और safety, जीने लायक compensation, और संगठन की संस्कृति कि क्या वह sloppy work को यूं ही जाने देती है—जैसी conditions ज़्यादा असर डालती हैं; industrial control systems programming जैसे दूसरे professions में भी यही बात लागू होती है
आपको पता चलेगा कि जिज्ञासु, विचारशील और सीखा हुआ व्यक्ति—चाहे self-taught हो या नहीं—हर profession में ऐसे व्यक्ति से बेहतर काम करता है जो ऐसा नहीं है
बहुत पहले जब मैंने welder के रूप में काम किया था, तब भी smart, motivated और curious लोग, केवल समय काटने वालों से बेहतर थे
इसलिए मैं मानता हूं कि programming welding जैसी है, लेकिन आपके intended meaning से अलग तरीके से
SICP ने Pascal या C में हैकिंग कर रहे साथियों के बगल में रहते हुए भी, code, abstraction और modularity के बारे में सोचने का मेरा तरीका पूरी तरह बदल दिया
Lisp/Scheme के साथ मैं समस्या का मानसिक model बना सकता था, जबकि साथियों को abstraction पहले अपने दिमाग में करनी पड़ती थी और फिर उसे ऐसी language में implement करना पड़ता था जो low-level focus मांगती थी
इसलिए SICP से जल्दी परिचय होने के लिए मैं हमेशा आभारी रहूंगा
आप किस language में programming करते हैं, इस पर निर्भर करता है कि वह ज्यादा मजेदार या ज्यादा आरामदेह हो सकती है
C++ में शायद मैं कभी पूरी तरह सहज नहीं हो पाऊंगा
SICP के लेखकों में से एक से programming पर उनका नजरिया सुनना अच्छा है, और शुरुआती कुछ मिनटों की कहानियां भी ठीक हैं
मैंने staff से कहा कि अगले दिन Sussman से मिलना है इसलिए यह किताब जरूर चाहिए, तो उसने Harvard co-op में फोन किया, और वहां एक copy stock में थी, इसलिए मैं Uber लेकर Harvard bookstore गया और SICP खरीदी
अगले दिन MIT में Sussman के office गया तो संयोग से Abelson भी वहां थे और बस निकलने ही वाले थे, इसलिए दोनों ने मेरी SICP पर sign कर दिए
Sussman ने जोड़ा, “अगर तुम 15 मिनट पहले आ जाते तो मेरी पत्नी भी sign कर देती!” और तब तक मुझे पता नहीं था कि उनकी पत्नी SICP की proofreader थीं
मेरे पास उन दो जादूगरों और अभी-अभी sign हुई मेरी purple book के साथ ली गई एक शानदार photo भी है
मैं यह video जल्दी देखना चाहता हूं
अभी SICP को ठीक से नहीं कर पाया हूं, लेकिन किताब उधार ले रखी है, और घर की मरम्मत करते हुए lectures सुन लिए थे
SICP lectures में जटिल चीजों को समझने के बारे में Sussman quote मैं architecture से जुड़े presentations में अक्सर डालता हूं, और वह slide ऐसी होती है जिसे लोग हमेशा तेजी से नोट करने लगते हैं
सच कहूं तो मैंने कई सालों तक programming से प्यार किया, और एक समय यह मेरा मुख्य hobby भी था
नई languages या software आजमाना, programming books पढ़ना, और libera/freenode जैसी कई chats में शामिल होना आम बात थी
लेकिन freelancer बनने और छोटे context में जल्दी से decent code deliver करने पर focus करने लगा, तो वह passion कम हो गया
engineer के तौर पर यह कुल मिलाकर अच्छी बात हो सकती है, लेकिन रोजमर्रा के काम से बहुत सारा मजा और सीखना गायब हो गया
freelancing और consulting आम तौर पर problem solving, बल्कि problem shooting जैसी होती है—समस्याओं को जितनी जल्दी हो सके हटाना—और elegance जरूरी नहीं होती
अगर आप tools बनाने वाले builder बनना चाहते हैं, तो freelancing में ऐसा शायद कम ही होगा; consultant role में जाना शायद इसे संभव बना सकता है
consultant को मैं थोड़ा अधिक लंबी अवधि के relationship जैसा मानता हूं, इसलिए इसे अगले कदम के तौर पर consider किया जा सकता है