सॉफ़्टवेयर संकट

• 1968 की NATO Software Engineering conference में सामने आया “software crisis” अब कम इस्तेमाल होने वाला शब्द बन गया है, लेकिन software complexity और abstraction ने जो बोझ बनाया था वह अब भी बना हुआ है
• Edsger Dijkstra ने 1972 के Turing Award व्याख्यान में कहा कि hardware performance और complexity तेज़ी से बढ़े, लेकिन उन्हें संभालने के लिए संगठित तरीके साथ नहीं बढ़ सके
• personal computing के commercialisation और तेज़ release cycle ने users को tools अच्छी तरह सीखने से पहले ही अधिक capacity चाहने की ओर धकेला, और “abstract it away” एक default प्रतिक्रिया बन गया
• nested abstraction layers performance cost और विकृत mental models पैदा करती हैं, और graphics·sound जैसी machine की बुनियादी क्षमताओं तक पहुँचना मुश्किल बनाती हैं
• समाधान अतीत के सीमित platforms पर लौटना नहीं, बल्कि abstraction layers को कम करना और layers के बीच information को संरक्षित रखते हुए tool users को फिर से पहल देना है

---

1968 की समस्या-चेतना अभी खत्म नहीं हुई है

• 1968 की पहली NATO Software Engineering conference में “software crisis” शब्द गढ़ा गया
  • ये conferences automatic computing machine programming practices को व्यवस्थित और प्रणालीबद्ध करने के शुरुआती प्रयासों में से एक थीं
  • 16 जुलाई 1969 को Apollo 11 mission launch हुआ, और उसी साल अक्टूबर में आख़िरी NATO Software Engineering conference आयोजित हुई
• Edsger Dijkstra ने 1972 के Turing Award व्याख्यान में संकट का कारण ज़्यादा शक्तिशाली हो चुकी machines और उन्हें संभालने के लिए संगठित तरीकों की कमी में देखा
  • उन्होंने आशयतः कहा कि “जब machine नहीं थीं तब programming कोई समस्या नहीं थी, कुछ कमज़ोर computers थे तब यह हल्की समस्या थी, और जैसे ही विशाल computers आए, programming भी एक विशाल समस्या बन गई”
• आज programming practice में “software crisis” अभिव्यक्ति बहुत कम दिखाई देती है
  • नई languages और संगठित तरीकों के विकास, और पुराने मुद्दों से समयगत दूरी के कारण industry में यह राहत बनी कि समस्या कुछ हद तक सुलझ गई है
  • लेकिन यह राहत असली सहजता से ज़्यादा हार मान लेने और स्वीकार कर लेने की स्थिति के क़रीब है

abstraction users की पहल को दूर कर देती है

• शुरुआती computing और उससे जुड़े क्षेत्रों का विकास ऐसे machines और environments में हुआ जहाँ abstraction tower खड़ा करने की सीधी लागत चुकानी पड़ती थी
  • जब constraints को bypass नहीं किया जा सकता था, तब growth cycle hardware upgrade के साथ चलती थी
  • व्यवहार में, लोग मौजूदा constraints को पर्याप्त समझने से पहले ही अधिक capacity चाहने लगते थे
• personal computing के commercialisation के बाद devices बेचने वाली companies users के product को पूरी तरह सीखने तक इंतज़ार नहीं करती थीं, और growth cycle लगातार तेज़ होती गई
  • तेज़ hardware release cycle के साथ “abstract it away” default mindset बन गया
  • जो details पसंद नहीं आतीं उन्हें किसी controllable structure के भीतर धकेल देने से कुछ हद तक independence मिलती है, लेकिन इसकी performance cost चुकानी पड़ती है
• abstraction की कई layers और information hiding software बनाने की समस्या को और ऊपरी स्तरों पर खिसका देते हैं
  • ये layers computer use के लिए ज़रूरी software और जीवन को चलाने वाले software, दोनों में एकीकृत हो जाती हैं
  • व्यापक software industry ने release cycle और capital के प्रभाव को और तेज़ किया, और individual developers के लिए आसानी से पहुँचने योग्य गुंजाइश कमज़ोर पड़ती गई
• software crisis सिर्फ developers की समस्या नहीं, बल्कि software users तक भी फैली हुई है
  • users के पास author द्वारा दी गई functionality के बाहर लगभग कोई control नहीं होता
  • software बनाना और उसका उपयोग करना, दोनों ही मानवीय गतिविधियाँ हैं—यह बात धुंधली पड़ जाती है

लौटने की जगह अतीत नहीं, बल्कि उथली layers हैं

• प्रस्तावित समाधान अधिक सीमित platforms पर लौटना नहीं है
  • अनुमत abstraction layers की संख्या सीमित की जानी चाहिए
  • layers के बीच information preservation ज़रूरी है
  • programming models, user interfaces, और underlying hardware उथले और composable होने चाहिए
  • Handmade, Permacomputing, और retrocomputing community जैसी movements software crisis के प्रति जागरूकता बढ़ाने वाली धारा से जुड़ती हैं

[GN⁺]

Hacker News की राय

• नमस्ते, मैं इस लेख का लेखक हूँ। मुझे लगा कि इस लेख के बारे में बार-बार होने वाली गलतफहमियों को साफ कर देना ज़रूरी है, इसलिए यह लिख रहा हूँ। मैं abstraction अपने-आप में के खिलाफ नहीं हूँ, बल्कि उसके बिना सीमा लगाए इस्तेमाल के खिलाफ हूँ
  समाधान यह भी नहीं है कि हम ज्यादा restrictive platforms पर लौट जाएँ, और न ही यह दावा है कि users “सहन करें और ज्यादा technical बनें।” software crisis को समझने की कुंजी “platform proficiency” और “growth/release cycle” की curves हैं। पिछले 40 से ज्यादा वर्षों में, कुछ क्षेत्रों को छोड़कर, ये curves अलग होती गई हैं; जब वे करीब थीं तब हमने इसे हल नहीं किया, लेकिन दूसरा सबसे अच्छा समय अभी है
  कुछ प्रतिक्रियाएँ इसे clickbait कहती हैं, लेकिन यह मेरे log की पहली पोस्ट है और एक developer के तौर पर मेरी स्थिति पर विचार है। मिलती-जुलती भावना कई communities में, खासकर कुछ counterculture-आधारित communities में, अलग-अलग रूपों में दिखती है। मैं समस्या-समाधान का एक हिस्सा दिखाना चाहता हूँ, इसलिए “कैसे करते हैं, दिखाऊँगा” जैसी एक follow-up पोस्ट भी लिखने का सोच रहा हूँ। यह काम मैं अकेले कर रहा हूँ, इसलिए कृपया थोड़ा समय और धैर्य दें

  • व्यक्तिगत तौर पर मुझे साफ नहीं है कि दावा क्या किया जा रहा है। मैं मानता हूँ कि खराब abstractions बहुत हैं या समस्याओं को जरूरत से ज्यादा abstract किया जा सकता है, लेकिन मुझे नहीं लगता कि यह कोई विवादास्पद बात है
    जब software बनाने वाले लोग लाखों में हैं, तो इस समस्या को पूरी तरह ठीक नहीं किया जा सकता। उनमें से कुछ से असहमति होना तय है, और हर कोई लेखक जितना दक्ष भी नहीं हो सकता। इसलिए यह लेख अंततः इस दावे जैसा पढ़ा जाता है कि “acceptable abstraction” का स्तर आज से ज्यादा ऊँचा होना चाहिए
    बड़े-बड़े दावे करना आसान है, लेकिन जब आप किसी खास क्षेत्र को देखते हैं जिसे “बहुत ज्यादा abstracted” माना जाता है, तो विनम्र होने की संभावना ज्यादा होती है। ऐसी “over-abstraction” के पीछे आम तौर पर काफी अच्छे कारण होते हैं, और उस क्षेत्र के engineers भी महसूस करते हैं कि abstraction की स्थिति messy है, लेकिन उसे जरूरी या ठीक करना अव्यावहारिक मानते हैं
    उदाहरण के लिए, बहुत सा software व्यापक रूप से इस्तेमाल होने वाली intermediate abstraction के ऊपर अच्छी abstractions रखकर बनाया जाता है। जैसे Kubernetes Linux, container runtime, और traditional control plane/configuration layer/data plane structure के ऊपर चलता है। इस सारी logic को सीधे किसी नए operating system में भी implement किया जा सकता है, लेकिन तब users के compatibility issues पैदा होंगे। आप बना तो सकते हैं, पर users न भी मिलें, और तब जिन खराब abstractions से बचना चाहते थे, उन्हें फिर से implement करना पड़ेगा। इसके अलावा, ऐसा समाधान implement करना कहीं ज्यादा मुश्किल है। मुझे Kubernetes design पसंद नहीं है और मैं इस समस्या को हल करना चाहता हूँ, लेकिन मुझे लगता है कि “सही तरीके” से करना इतना मुश्किल या महँगा हो जाता है कि उसकी कीमत नहीं रह जाती
  • Clarke के तीन नियम याद करने चाहिए
    1. जब कोई प्रतिष्ठित लेकिन बुज़ुर्ग वैज्ञानिक कहता है कि कोई चीज़ संभव है, तो वह लगभग निश्चित रूप से सही होता है; और जब वह कहता है कि असंभव है, तो उसके गलत होने की संभावना आम तौर पर ज्यादा होती है
    2. संभावना की सीमाएँ जानने का एकमात्र तरीका है असंभव लगने वाले क्षेत्र से थोड़ा आगे जाना
    3. पर्याप्त रूप से विकसित technology, जादू से अलग नहीं पहचानी जा सकती
       आप इस क्षेत्र में कब और किस background से आए, इसके आधार पर, पिछली पीढ़ी की abstractions पहले ही accepted practice में शामिल हो चुकी होंगी—इसकी संभावना काफी है। उदाहरण के लिए, कभी किसी general-purpose file system वाले operating system का इस्तेमाल करना स्वाभाविक पूर्वधारणा बन गया था
       मुझे लगता है कि अभी जिस समस्या की बात हो रही है, वह इस field में प्रवेश करते समय आने वाली कठिनाई के करीब है। अगर यह मान लिया जाए कि योगदान करने के लिए इस्तेमाल होने वाली हर abstraction को विस्तार से समझना जरूरी है, तो required prior knowledge काफी ज्यादा है। यह overwhelming हो सकता है, लेकिन जब तक आप और गहराई से समझ न सकें, abstractions को स्वीकार करने का रास्ता भी है
       0 - https://en.wikipedia.org/wiki/Clarke's_three_laws
  • मुझे अच्छा लगा कि यह दिखाया गया कि समस्या इतिहास में लगातार बनी रही है। “software crisis” अभिव्यक्ति भी उपयुक्त है, क्योंकि यह उस बिंदु का संदर्भ देती है जहाँ इस स्थिति को पहली बार स्पष्ट रूप से व्यक्त किया गया था
    हालांकि मुझे लगता है कि यह स्थिति इसलिए नहीं बदलती क्योंकि कारण साफ तौर पर आर्थिक हैं। मेरा मतलब यह नहीं कि खराब software सस्ता होता है। लेकिन corners cut करने से व्यक्ति या संगठन अभी लागत बचा सकते हैं, और बड़ी लागत बाद में वही संगठन, ग्राहक और पूरा समाज उठाता है, इसलिए सस्ती और खराब practices के लिए मजबूत incentive है। ऊपर से software पर अन्य engineering disciplines के standards लागू करना मुश्किल है, इसलिए किसी खास standard या quality का software मांगने वाले contracts या regulations बनाना भी कठिन है
    कल्पना योग्य एकमात्र समाधान शायद ऐसी technological revolution होगी जो उसी technology से सस्ता और बेहतर software बनाना संभव करे, और साथ ही सस्ता और खराब software बनाना असंभव बना दे
  • मुझे यह software crisis से ज्यादा software excess जैसा लगता है
    बहुत सारे platforms पर बहुत ज्यादा software है, और landscape इतना fragmented है कि generalizations करना मुश्किल है। कुछ projects डगमगाकर गिरते हैं, जबकि कुछ projects अच्छी तरह चलते हैं
    user-hostile software भी है, लेकिन वह design intent है। उसके पीछे cynicism और greed है। इसलिए नहीं कि programmers को पता नहीं कि वे क्या कर रहे हैं, बल्कि इसलिए कि वे वही कर रहे हैं जो उनसे कहा गया है
    users खुद भी इसे बढ़ावा देते हैं। आप अच्छा software बना दें तो भी उन्हें परवाह नहीं होती, और users अच्छे software की बजाय कुछ और मांगते हैं। अच्छा software चाहने वाला एक user, ऐसे पचास users का शिकार बन जाता है जो ऐसा नहीं चाहते। mass-market software अब mass culture है
  • Windows 3.1 और Word 40MB hard disk में आराम से आ जाते थे और जगह बचती भी थी। Word 2MB RAM और single-core 16MHz 80386 पर भी चलता था, और modern microcontrollers इससे कहीं आगे हैं
    उस समय का Word आज के version की तुलना में इतना कमतर भी नहीं था। लेकिन आज Windows और Office को सिर्फ चलने के लिए ही 50–100GB disk चाहिए। 1000 गुना बढ़ाकर हमें आखिर मिला क्या
    यह पूरी तरह पागलपन है, लेकिन हम इसे यूँ ही जाने देते हैं। modern systems में disk, RAM और CPU लगभग 5000–10000 गुना बढ़ गए हैं, और home internet शुरुआती modems से सचमुच दस लाख गुना तेज़ है

• यह लेख इस पूर्वधारणा पर आधारित है कि software crisis सचमुच मौजूद है या कोई गंभीर समस्या है। संकट के तत्वों के तौर पर budget overrun, schedule overrun, अक्षमता, कम quality, requirements पूरा न होना, manage न हो सकने वाले project, maintain करना मुश्किल code, delivery न होना आदि बताए गए हैं
  लेकिन अगर यहां से “software” शब्द हटा दें, तो ऐसी कितनी मानवीय गतिविधियां हैं जिनमें इन समस्याओं में से एक या अधिक न आती होंगी? उल्टा, वास्तव में काफी शानदार software भी बहुत है। हम सिर्फ failure और defects देखना चाहते हैं, और success लगातार बेहतर हो रही हो तब भी उसे obvious baseline मानकर नजरअंदाज कर देते हैं
  कंप्यूटर का power button दबाकर desktop तक पहुंचने के दौरान हम पहले ही सैकड़ों abstractions से गुजर जाते हैं। वह desktop ही उन machines में सबसे जटिल चीज है जिनसे हम दिन भर interact करेंगे। यह चीज़ पूरी दुनिया में रोज़ अरबों बार होती है, और आम तौर पर बिना समस्या के हो जाती है। यह भी सिर्फ एक बहुत छोटा उदाहरण है

  • लेख यह ठीक से नहीं समझाता कि असली crisis क्या है। complexity अपने-आप में समस्या नहीं है, लेकिन ऊपर गिनाई गई समस्याएं असली समस्याएं हैं
    हालांकि मुझे लगता है कि ऐसे लेखों की असली प्रेरणा वे items नहीं, बल्कि यह एहसास है कि सब कुछ संभाल से बाहर लग रहा है। अनुभवी programmers को उस भारीपन को किए जाने वाले काम के साथ balance करना होता है। यहां तक आने में समय लगा, लेकिन मैं मानता हूं कि यह महत्वपूर्ण है। सब कुछ कभी पूरी तरह व्यवस्थित नहीं होगा, और इस तथ्य को स्वीकार करना होगा
  • software के अनोखा होने की वजह यह है कि quality पर natural forcing function या filter की तरह काम करने वाली physical constraints नहीं होतीं। पुल को किसी स्तर पर structural integrity या material quality के minimum standards पूरे करने ही पड़ते हैं, वरना वह अपने ही वजन से गिर जाएगा। खाना भी ingredients की quality और cooking skill के minimum standards पार करे, तभी खाने लायक होता है
    software में performance और memory constraints के अलावा ऐसी limits लगभग नहीं हैं। लेकिन दोनों ही अक्सर इतनी abundant होती हैं कि कचरा अंतहीन तरीके से जोड़ते हुए काम चलाया जा सकता है। हम सबके जीवन में वह पल आया है जब हमने सोचा या कहा, “यह आखिर चल कैसे रहा है?” जब तक user कोई गलत boundary condition नहीं छूता, तब तक पता नहीं चलता कि नीचे का code कितना नाजुक है
    “क्या आपने इसे बंद करके फिर चालू किया?” इसका सबूत है। software systems अक्सर इतने subtle और अज्ञात खराब state में पहुंच जाते हैं कि हर चीज़ मिटाकर शुरू से फिर उठाने के अलावा कोई समाधान नहीं बचता। जैसे call लेने के बाद भी अगली call या message आने तक phone का vibrate करते रहना, web app में कुछ हिस्सा 100% load न होने से options गायब हो जाना, या Bluetooth pairing का अनिश्चित तरीके से काम करना
  • गिनाई गई ज्यादातर, शायद सारी समस्याओं की जड़ दो बुनियादी concepts तक जाती है: communication और understanding
    communication, understanding को फैलाने और उसकी कमी को ठीक करने का तरीका है, और understanding किसी भी काम की सफलता की बुनियाद है। understanding न हो तो ऊपर बताए गए symptoms में से एक या अधिक दिखाई देते हैं। understanding हो तब भी वे आ सकते हैं, लेकिन कम से कम success की ओर जाने वाला रास्ता बनता है
    मेरे अनुभव में software engineering industry की ज्यादातर समस्याएं people problems हैं। technology नहीं, technology itself नहीं, process भी नहीं। इसलिए communication और understanding सफलता के लिए अनिवार्य हैं
  • “कितनी मानवीय गतिविधियां ऐसी हैं जिनमें इनमें से एक या अधिक समस्याएं आती हैं” के बारे में, क्या आप यह binary जवाब चाहते हैं कि कुछ क्षेत्रों में ऐसा कभी नहीं होता? ज्यादातर projects में इनमें से 1–2 भी हो जाएं तो उसे खराब माना जाता है, लेकिन software में अगर इनमें से सिर्फ 2 से भी बच जाएं तो जीत घोषित कर दी जाती है
  • “काफी शानदार” software का standard क्या है, यह जानना चाहूंगा। बेशक यह subjective है, लेकिन ज्यादातर लोग जो software वास्तव में इस्तेमाल करते हैं उसे देखकर उसे शानदार नहीं कहेंगे
  • यह बात सही है कि desktop उन machines में सबसे जटिल है जिनसे आप दिन में interact करेंगे, लेकिन उस कंप्यूटर को operate करने, signals ग्रहण करने और reasoning करने वाला brain इसका अपवाद है

• इंजीनियरिंग कंपनियों या ऑटोमोबाइल कंपनियों के leadership का इतिहास देखें, तो पार्ट्स, components, product design या production facilities चलाने में धीरे-धीरे बड़ी जिम्मेदारियां संभालने के चरण दिखते हैं। CEO भी अब भी technical knowledge पर जोर देते हैं, और non-technical लोग भी कम से कम ऐसा दिखावा तो करते हैं
  इसके उलट Agile software development में technical capability आम तौर पर सबसे निचली परत पर ही खत्म हो जाती है। Scrum team में software बनाने वाले लोग होते हैं, बस इतना ही। Scrum master और कई business analysts ने शायद ज्यादा coding कभी नहीं की होती, और hierarchy में पहला असली boss अक्सर secretary/administrative कामों में लगा होता है, इसलिए code लगभग देखता ही नहीं
  मुद्दा सिर्फ यह नहीं है कि software development ticket-size units में होता है, इसलिए यह सोच पाना मुश्किल हो जाता है कि आप abstraction की कितनी परतें बना और maintain कर रहे हैं। Software developers के पास decision-making table पर जगह तक नहीं होती। Scrum master उनकी देखभाल करता है, code review में वे समझौता करते हैं, tickets से बाहर सोचने से रोकने का दबाव होता है, और technical capability को leadership तक ले जाने वाला promotion path भी आम तौर पर नहीं होता
  इसलिए “software crisis” की चेतावनी देने की कोशिशें, लेख के अंत की अभिव्यक्ति की तरह, Handmade, Permacomputing, retro computing जैसे hobby क्षेत्रों तक सीमित रहने की संभावना ज्यादा लगती है। Hollywood भी कुछ हद तक जिम्मेदार है: वह software/IT लोगों को लगातार अपमानजनक ढंग से दिखाता है, जबकि doctors और lawyers को लगातार मुख्य भूमिकाएं देता है और जटिल jargon को दिलचस्प कहानियों में पिरो देता है। क्या हमारी तरफ यह सचमुच असंभव है? शायद जल्द ही script-writing AI कुछ कर दिखाए

  • Doctors और lawyers लोगों और रोजमर्रा की समस्याओं से dealing करते हैं, इसलिए उन्हें दिलचस्प कहानियों में बदलना आसान है। Contract lawyer या radiologist को protagonist बनाने वाले works बहुत नहीं हैं; आम तौर पर ER doctors और criminal law lawyers आते हैं
    Software development पूरे दिन computer से सटीक तरीके से बातचीत करने का काम है। इसमें या तो पहले से हल हो चुके मामूली काम को किसी नए application में सुलझाया जाता है, या ऐसे problems से निपटा जाता है जिन्हें technical background के बिना समझना भी मुश्किल है। मैं 20 साल से ज्यादा समय से मजे के लिए programming करता आया developer हूं, फिर भी ज्यादातर काम उबाऊपन की हद पार कर जाते हैं। Non-developers को समझाने की कोशिश भी नहीं करता। यह accounting जितना ही boring है, और शायद बहुत से लोग किसी दूसरी कहानी से ज्यादा उपयोगी जानकारी हासिल करेंगे
  • यह तर्क समझ में आता है। अगर मैं Agile era का junior होता, तो शायद आज जैसा तेज और दूर तक grow नहीं कर पाता
    जिस कंपनी में मैंने काम किया और जो Agile में सबसे ज्यादा डूबी हुई थी, वह juniors और seniors को interchangeable gears की तरह treat करती थी। फर्क बस इतना था कि seniors को प्रति sprint ज्यादा points handle करने होते थे। Ticket scope के बाहर सोचने से सक्रिय रूप से रोका जाता था, और माहौल ऐसा था कि सिर झुकाए रखो और मुंह बंद रखो
  • Big Tech में काफी ऊंचे level तक technical managers काफी होते हैं
    लेकिन दो समस्याएं हैं। वे detailed implementation में गहराई तक नहीं जा सकते, और complexity पैदा करने पर reward मिलने वाले विकृत incentives से भी बंधे होते हैं। बेशक ऐसे लोग भी हैं जो इसके खिलाफ खड़े होते हैं, लेकिन उनके promote होने की संभावना कम होती है। अपने नीचे लोगों की संख्या घटाने या अपना role खत्म करने के लिए reward नहीं मिलता
  • जिस दुख का वर्णन किया गया है, वह काफी हद तक खुद पैदा किया हुआ लगता है। मेरे “नीचे” के कई developers customer needs से पूरी तरह कट गए और सिर्फ “interesting” development problems पर focus करने लगे
    Developers actual requirements में से सिर्फ ticket-size units ही क्यों handle करते हैं, इसका छोटा जवाब है: क्योंकि वे बहुत मूर्ख हैं। वे पूरे को अपने दिमाग में नहीं रख पाते, समझ नहीं पाते। यह सुनकर चिढ़ होती है? हां। सचमुच समझना मुश्किल है। माफ कीजिए
  • प्रतिवाद: Boeing

• यह लेख abstraction को बुराई की तरह दिखाता है, लेकिन किसी निश्चित स्तर से ऊपर की क्षमता वाला human-made software बनाने के लिए यह एक अपरिहार्य tool है
  Rich Hickey ने कभी कुछ इस आशय की बात कही थी कि “एक beginner juggler दो-तीन balls संभाल सकता है, लेकिन दुनिया का सबसे अच्छा juggler भी शायद नौ के आसपास ही रुक जाएगा। इंसानी क्षमता में orders of magnitude का फर्क नहीं होता और ceiling जल्दी आ जाती है।” उस सीमा से आगे जाने के लिए abstraction के अलावा रास्ता नहीं है
  बेशक कुछ specific cases में खराब abstraction या बहुत ज्यादा abstraction हो सकती है, और लेखक की नाराजगी भी मुझे उसी तरफ लगती है। लेकिन वह फर्क महत्वपूर्ण है
  “अब software बनाना आसान नहीं रहा, और कुछ भी manual के साथ नहीं आता” वाला हिस्सा साफ तौर पर गलत है। Software बनाना पहले से कहीं ज्यादा आसान हो गया है और documentation भी बेहतर है

  • उस lecture में मुख्य रूप से जो प्रस्तावित किया गया था, वह abstraction से ज्यादा simplicity, यानी decomposition था
    किसी complex whole को समझने के लिए indirection अनिवार्य नहीं है। Complexity से निपटने के लिए उलझी चीजों को खोलकर हर हिस्से को स्वतंत्र रूप से समझ सकना जरूरी है। Indirection से complexity छिपाने पर, जिस चीज के बारे में हमें reasoning करनी है और हमारे बीच दूरी पैदा हो जाती है
    Abstraction users के लिए अच्छा है। Developer हों या नहीं, उन्हें details की चिंता नहीं करनी पड़ती। लेकिन इसे बनाना हमारे लिए आसान नहीं होता

• “अब software बनाना आसान नहीं रहा” वाली बात के उलट, अगर आपको सही काम के लिए सही tool पता हो, तो यह बहुत आसान है। बस ऐसे tools के बारे में जानकारी दबा दी जाती है, इसलिए उनके बारे में लगभग सुनने को नहीं मिलता
  ज़्यादातर लोग जिस technology tools ecosystem की कल्पना करते हैं, वास्तविकता उससे बहुत अलग है। जिन tools को हम जानते हैं, उनमें से अधिकांश बेहद खराब हैं। वे खुद को universal solution जैसा दिखाने की कोशिश करते हैं, लेकिन असल में किसी भी काम के लिए खास अच्छे नहीं हैं। फिर भी वे सबसे लोकप्रिय tools हैं। जैसा कि लेख इशारा करता है, मुझे लगता है इसकी वजह पूंजी का प्रभाव है
  उदाहरण के लिए, अभी जिस tool का इस्तेमाल कर रहा हूं उससे मैंने एक वीडियो रिकॉर्ड किया, जिसमें login, access control, schema validation और complex filter views वाला एक अपेक्षाकृत जटिल marketplace app सिर्फ browser में, कोई software download किए बिना, serverless तरीके से 3 घंटे में scratch से बनाया। पूरा app 700 lines से कम HTML markup और 12 lines JavaScript का है। Views करीब 10 थे

  • सुधार करूं तो यह “अभी इस्तेमाल किया जा रहा tool” नहीं, बल्कि वह tool है जिसे आपने खुद बनाया है और जिसे आप अभी काफी कम खुलकर promote करने की कोशिश कर रहे हैं। 18 dollar monthly subscription fee, कोई user नहीं, और जाहिर है वादों और hype के सहारे टिकी cryptocurrency भी साथ में है
    conspiracy theory वाले twist के उलट, modern tools पहले से कहीं ज्यादा flexible और इस्तेमाल में आसान हैं। उनमें कमियां हैं, लेकिन दशकों पहले developers को जो झेलना पड़ता था, उसकी तुलना में यह कुछ भी नहीं है। आपके tool को दबाने की कोई बड़ी साजिश नहीं है
  • Web3 या mainstream cryptocurrency मेरा क्षेत्र नहीं है। हालांकि मुझे math पसंद है, इसलिए unpopular cryptography technologies पसंद हैं। वीडियो 3 घंटे का है, इसलिए मैं उसे अंत तक नहीं देखूंगा। मुझे पहले ही लग रहा है कि यह मुझे ऐसा कुछ नहीं देगा जिसे मैं आज, अगले हफ्ते या इस महीने इस्तेमाल कर सकूं। नीचा दिखाने का इरादा नहीं है, बस 3 घंटे लंबा समय है
    मैं no-code/low-code और कहीं भी चल सकने वाले tools में बहुत विश्वास करता हूं। हालांकि मेरा मतलब शायद आपके सोचने से अलग हो सकता है। जो भी हो, आपने बनाया है, यह बात मानता हूं
    वीडियो देखना शुरू करते समय मेरे मन में पहला सवाल यह आया। Codespaces क्या है? Security कैसी है? Final app कहां चलेगा? क्या मैं इसे अपने hardware पर चला सकता हूं? क्या यह cloud access के बिना चल सकता है? कौन सा cloud? क्या यह अगले हफ्ते, अगले महीने, अगले साल, 10 साल बाद भी रहेगा? बेशक, एक sample पर ज्यादा ध्यान मत दीजिए
    no-code/low-code वाली स्थिति की तुलना desktop publishing से की जा सकती है। DTP में CI/CD pipeline नहीं होती। Print दबाना होता है। यह पूरी तरह integrated environment है। दूसरी ओर, शाब्दिक अर्थ में हर “continuous integration” environment इतनी जोर से चिल्लाने की कोशिश में खुद को ही खा जाता हुआ लगता है। कहीं न कहीं color separation, margin settings, fonts import करने, PostScript header libraries या LaTeX generation के लिए tools होंगे, लेकिन ज्यादातर लोग उन्हें देखते या इस्तेमाल नहीं करते। कहीं न कहीं कोई CMYK से कहीं ज्यादा विविध pigments के साथ ऐसी multi-plate printing करता होगा जो सिर्फ natural light में साफ दिखती है, लेकिन ज्यादातर लोग तो phone के खराब snapshots ही देखते हैं, इसलिए उन्हें उसका मतलब महसूस नहीं होता
    यह सिर्फ creators की समस्या नहीं है। Consumers नहीं जानते कि क्या संभव है, और उनके पास संभावनाओं की पूरी range दिखाने वाले devices भी नहीं हैं। Consumer devices कई closed ecosystem कारणों और साधारण लापरवाही व अज्ञानता के चलते उस range को सक्रिय रूप से नुकसान पहुंचाते हैं
    कुछ साल पहले rental car में मुझे Cadillac मिली थी, और मैं modern Cadillac कभी नहीं खरीदूंगा, और हो सके तो चलाने से भी बचूंगा। मैं wipers control नहीं कर पा रहा था, और console screen ने कई बार सबसे ज्यादा ध्यान खींचने वाली चेतावनी दिखाई कि मैं road नहीं देख रहा हूं। शायद उसे समझ नहीं आया कि मैंने glasses पहन रखे हैं। अनजान road पर तेज traffic में होने के कारण मैंने सच में screen नहीं देखी, और साथ बैठे व्यक्ति से पूछा, “वह blink करती screen आखिर कह क्या रही है?” शाबाश, Cadillac
  • Link दीजिए!

• उथला और composable ढांचा कुछ ऐसा है जिसे UNIX tools इस्तेमाल करते समय हर कोई अनुभव करता है
  GUI यहीं बिखर जाता है। GUI सचमुच अलग-अलग द्वीप हैं, जो आपस में composable तरीके से communicate नहीं करते
  GUI और shell pipeline के idea को मिलाने का एक प्रयोग मैं guish नाम के tool से कर रहा हूँ
  https://github.com/williamcotton/guish
  जानना चाहूँगा कि क्या किसी को ऐसे मिलते-जुलते tools या composable GUI approaches के बारे में पता है

  • इसी क्षेत्र के कुछ projects हैं
    https://hisham.hm/userland/
    https://arcan-fe.com/2021/04/12/introducing-pipeworld/
    http://conal.net/papers/Eros/
  • composable GUI का जवाब मेरे हिसाब से emacs architecture है। emacs न सिर्फ CLI है, न सिर्फ GUI। यह दोनों का एक शानदार लेकिन पुराना, seamlessly integrated संयोजन है
    मैं भी इससे जुड़े ideas पर काम कर रहा हूँ, और ऊपर से देखने पर यह आपके काम जैसा भी लगता है। हालांकि मैं सलाह दूँगा कि emacs में यह कैसे काम करता है, उसे देखें। मैंने बहुत गहराई से नहीं देखा, लेकिन आपका approach मुझे उतना “composable” नहीं लगता
    अगर आपको पता न हो तो यह भी inspiration दे सकता है: https://gtoolkit.com/ यह Smalltalk environment है, जहाँ emacs की तरह literally सब कुछ programmable है, लेकिन लगभग उल्टी दिशा में। GUI commands का result नहीं, बल्कि language itself है
  • सही है। यह उथला, विस्तृत और composable होना चाहिए। हमारी abstractions भी ऐसी ही होनी चाहिए
    लेकिन बड़ा issue GUI नहीं है। GUI भी issue है, लेकिन वह abstraction stack के सबसे ऊपर ही होगा, इसलिए समस्या आगे जाकर composable तरीके से जुड़ती नहीं। दिलचस्प बात यह है कि समस्या इतनी बड़ी है कि एक तरह से अब वह समस्या नहीं रह जाती
    आज का विशाल हाथी distributed systems हैं
  • “Sunday drive” जैसी pipelines—यानी ऐसे काम जिन्हें कुछ दिन या लगभग एक हफ्ता intensively इस्तेमाल करके महीनों तक छोड़ दिया जाता है—के लिए मुझे KNIME(https://www.knime.com/) पसंद है। Code layer के तौर पर Python/Pandas इस्तेमाल करता हूँ
  • यह काफी शानदार दिखता है। मैं सहमत हूँ कि Unix पसंद आने और productive महसूस होने की एक बड़ी वजह भी इसका “उथला और composable” होना है
    हालांकि GUI बहुत पहले से एक कमजोर कड़ी रहा है। शायद इसलिए कि UI अच्छा है या नहीं, इसमें कई “global” considerations होते हैं, और यह कोई modular property नहीं है
    निजी तौर पर मैं चाहता हूँ कि UI और हो, लेकिन automation बनी रहे। यानी shell में type की गई चीज को file में save करके बाद में फिर चला सकना, edit करके दोबारा चला सकना, और command copy करके किसी दोस्त को email कर सकना—यही property
    context के लिए, मैं कई सालों से scratch से shell बना रहा हूँ और GUI के लिए एक headless mode है। दूसरे लोगों द्वारा बनाए गए real demos भी हैं, लेकिन अभी कोई इस पर काम नहीं कर रहा
    Screenshots:
    https://www.oilshell.org/blog/2023/12/screencasts.html#headl...
    https://www.oilshell.org/blog/tags.html?tag=headless#headles...
    और links यहाँ हैं - https://github.com/oilshell/oil/wiki/Interactive-Shell - Xiki जैसे interesting inactive projects भी हैं
    अगर आपको terminal से अलग कोई compatible shell या ऐसा कोई नया shell चाहिए, तो email या https://oilshell.zulipchat.com पर बताइए
    मूल रूप से हमें ऐसे लोगों की जरूरत है जो headless protocol test करें और सुधार बताएं। मेरा मानना है कि हमें ऐसा shell GUI बनाना चाहिए जो terminal को “रखे”, लेकिन terminal “खुद न हो”। यह आपके बनाए जा रहे काम से भी संबंधित लगता है
    अभी मैं मुख्य रूप से नई YSH language पर काम कर रहा हूँ, लेकिन GUI work को भी फिर से revive करना चाहता हूँ। मेरे पास UI programmer का ज्यादा experience नहीं है, इसलिए दूसरा perspective मिलना अच्छा रहेगा
    और ggplot पसंद होने के कारण उसे शामिल किया गया देखकर खुशी हुई। सच कहूँ तो ggplot ही वह जगह है जहाँ shell में graphics होते तो अच्छा होता, ऐसा अफसोस होता है

• आखिर की पंक्ति “यह और बेहतर हो सकता है। मैं दिखाऊँगा कैसे” बस clickbait के लिए लिखी intro line जैसी लगती है

  • clickbait का मुख्य criterion यह है कि क्या वह sensational, deceptive, या जानबूझकर misleading है। यह मुझे इनमें से कोई भी नहीं लगता। यह बस blog post की आखिरी line है
  • यह उस site का पहला और इकलौता blog post है: https://wryl.tech/log/index.html
  • क्या यह personal attack है? या सिर्फ fact की तरह कह रहे हैं और argument की validity पर सवाल नहीं पूछ रहे?

• “ये models वास्तविकता को बहुत कम ही reflect करते हैं। अगर कर दें तो अच्छा संयोग है, नहीं तो आपदा है” — यह बात मेरे अनुभव से मेल नहीं खाती
  आम तौर पर बाज़ार में मौजूद ज़्यादातर software घातक नहीं होता। कई फूले हुए, बेकार web apps दिन भर बेवजह बहुत सारे resources चूसते रह सकते हैं, इधर-उधर अनियमित bugs दिखाते हुए भी users की अपेक्षित चीज़ को बहुत खराब तरीके से कर सकते हैं। यह सब सही है
  लेकिन वे pacemaker या space rocket संभालने वाले software जितने घातक नहीं होते। ज़्यादातर software खराब हो तो भी चल जाता है। क्योंकि ज़्यादातर projects इंसानी सनक से जुड़े होते हैं, और quality की कमी का सबसे बुरा नतीजा भी थोड़ी झुंझलाहट होता है, तबाही या मौत नहीं
  ऊपर से, ज़्यादातर software developers शायद Silicon Valley-शैली के पैसे वाले motivation में काम नहीं करते, और न ही उन projects से रोज़ी कमाते हैं जिन्हें वे passion से बनाना चाहते हैं। बाज़ार में आने वाला ज़्यादातर software बाहरी तौर पर थोपे गए घटिया reward structures के जरिए बनता है। ऐसी प्रक्रिया के product से कचरे के अलावा और क्या उम्मीद करेंगे

  • मैं मानता हूँ कि risk level मेल नहीं खाता लगता, लेकिन मैं सभी software की बात कर रहा हूँ, और यह भी ध्यान में रखता हूँ कि ऐसी झुंझलाहटें बहुत ज़्यादा हैं। सीढ़ियों में कुछ छोटी दरारें हों तो अलग बात है, लेकिन औसतन हालत ऐसी है कि आधी सीढ़ियाँ ही गायब हैं
    मुझे missing steps सचमुच नापसंद हैं
    हम अपने बनाए software के वास्तविक उपयोग से बहुत दूर हैं, और development process को guide करने वाले छोटे-छोटे executable signals ही अनुभव करते हैं। जब तक हम किसी नए user के साथ शरीर नहीं बदल सकते, इस “हज़ार कटों से मौत” का असली दर्द ठीक से महसूस करना मुश्किल है
    मैं programming को एक पेशेवर कौशल मानता हूँ, और मुझे लगता है कि software quality को नियंत्रित करने की ताकत हमारे पास है। बस financial हों या न हों, ऐसे incentives हैं जो हमें नज़रअंदाज़ करने पर मजबूर करते हैं

• मुझे नहीं लगता कि कोई software crisis है। दुनिया भर के लाखों programmers कुछ हद तक उपयोगी programs बना रहे हैं, और toaster तक सहित लगभग हर चीज़ काफी सफलतापूर्वक software चलाती है। community ने ऐसे programs भी बनाए हैं जिन्हें 5 साल के बच्चे से लेकर दादा-दादी तक सभी access कर सकते हैं। इसमें crisis कहाँ है
  लेकिन project management crisis ज़रूर है। यह सिर्फ software तक सीमित नहीं है; समस्या यह है कि planning करने वाले और deliver करने वाले लोग दूर हो गए हैं। और लगता है कि हम उस gap को भर नहीं पा रहे। Agile, Scrum वगैरह इस gap के indicators हैं, जहाँ “gurus” हम सबको मूर्ख समझते हैं, और हम भी इससे बेहतर कुछ बना नहीं पा रहे
  software development का commoditization भी इस अव्यवस्था में योगदान देता है। field में entry आसान होने की वजह से हर level के लोग अलग-अलग success rates के साथ हिस्सा ले सकते हैं। यह अच्छा या बुरा होने का सवाल नहीं, बल्कि इस phenomenon की प्रकृति है। food industry में Michelin-star restaurants और MacDonalds दोनों हैं, और दोनों के consumers हैं—यह उससे बहुत अलग नहीं। फिर भी हम इसे restaurant crisis नहीं कहते

  • toaster वाला उदाहरण तो उल्टा एक वास्तविक और ठोस software crisis का मामला है। toaster खराब code चलाता है। resilience या security को ध्यान में रखे बिना लिखा खराब code internet से connect होता है
    इससे toaster की उम्र घट जाती है। पहले शायद 10 साल चलने वाला toaster होता था। अब खराब software और शायद forced WiFi या Bluetooth connection की वजह से, supplier update बंद कर दे तो 2 साल बाद वह कचरा बन जाता है। हो सकता है updates कभी मिले ही न हों। crisis हमेशा नज़र नहीं आता, बस इसलिए कि वह सीधे दिखाई नहीं देता, या आज की overconsumption और लगातार नए products खरीदने की आदत में छिप जाता है
    toaster 2 साल बाद बंद हो जाए तो हम उसे ठीक मान लेते हैं, और क्यों हुआ इसकी परवाह नहीं करते या जानते नहीं। लेकिन वह Mirai botnet का हिस्सा रहा हो सकता है https://www.cloudflare.com/learning/ddos/glossary/mirai-botn...
    toaster शायद simpler chip इस्तेमाल करता होगा, इसलिए शायद नहीं, लेकिन कौन जानता है
  • “toaster तक software चलाता है” — क्या यह उल्टा लेखक के इस दावे को support नहीं करता कि software बहुत ज़्यादा है
    वैसे, मेरा Dualit toaster software नहीं चलाता
  • क्या आजकल entry सचमुच आसान है? modern software development में आना अभी बहुत मुश्किल लगता है। ज़रूरी knowledge बहुत ज़्यादा है

• “हमने nested abstraction layers जमा कीं और कई levels पर information छिपाने के तरीके विकसित किए। software बनाने की समस्या को ऊँची-ऊँची layers में बदल दिया” — यह हिस्सा leaky abstraction और Tower of Babel की याद दिलाता है
  https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
  https://en.wikipedia.org/wiki/Tower_of_Babel
  https://en.wikipedia.org/wiki/Hierarchy
  https://en.wikipedia.org/wiki/Abstraction
  https://en.wikipedia.org/wiki/Abstraction_(computer_science)
  आपस में तुलना करने लायक हैं