- Jonathan Blow की यह चिंता कि “abstraction आवश्यक software maintenance क्षमता को कमजोर करती है” ज्ञान के हस्तांतरण के संदर्भ में वैध है, लेकिन इसके समर्थन में दिए गए कई उदाहरण इतिहास और संदर्भ को गलत तरीके से प्रस्तुत करते हैं
- “five nines”, robust software, तकनीकी प्रगति में ठहराव, और productivity में गिरावट पर बहस अक्सर consumer devices और high-availability systems के बीच फर्क नहीं करती या चुनिंदा उदाहरणों पर निर्भर रहती है
- low-level ज्ञान के खोने की चिंता कुछ हद तक उचित है, लेकिन C·assembly·Rust·operating system porting·compiler शिक्षा·open source गतिविधियाँ अब भी system capability को बनाए रखने के रास्ते हैं
- operating system, file system, network, multitasking, framework जैसी abstractions जटिलता बढ़ाती हैं, लेकिन hardware बदलाव और user expectations को संभालते हुए portability·productivity·creative accessibility भी बढ़ाती हैं
- abstraction से भी बड़ा खतरा लगातार churn, locked platforms, ads·trackers·telemetry, और privacy व freedom के कमजोर होने से है, जबकि महत्वपूर्ण systems को बनाए रखने वाली तकनीकी नींव को सुरक्षित रखना ज़रूरी है
Blow के दावों पर मूल रुख
- Jonathan Blow का व्याख्यान इस तर्क पर आधारित है कि software abstraction low-level programming knowledge के क्षरण का कारण बनती है, और अंततः आवश्यक software को maintain न कर पाने की स्थिति सभ्यता के पतन तक ले जा सकती है
- ज्ञान के हस्तांतरण के महत्व से सहमति है, लेकिन ऐसे दावों को सही ठहराने के लिए उदाहरण और ऐतिहासिक संदर्भ सटीक होने चाहिए
- मुख्य आपत्ति यह है कि Blow के कई उदाहरण गलतफहमी, चुनिंदा मामलों और किस्सों पर आधारित हैं, और वे computer history के कुछ हिस्सों को नज़रअंदाज़ करते हैं
“five nines” और robustness पर बहस
- Blow का दावा है कि पहले computer systems की बिक्री में “five nines”, यानी 99.999% uptime, को quality rhetoric की तरह इस्तेमाल किया जाता था, लेकिन आज के laptop इस स्तर तक नहीं पहुँचते
- यह सही है कि five nines का मतलब साल भर में लगभग 5 मिनट downtime होता है, लेकिन यह दावा गलत माना गया है कि इस metric का इस्तेमाल consumer laptop या word processor बेचने में होता था
- five nines आमतौर पर 911 जैसे emergency response switchboards, hospital systems, और financial transaction processing जैसे क्षेत्रों में लागू होता है
- इसे अक्सर लंबे contracts के साथ इस्तेमाल किया जाता है जिनमें विस्तार से बताया जाता है कि कौन-सी स्थितियाँ downtime में नहीं गिनी जाएँगी
- IBM और Amazon जैसी कंपनियाँ आज भी ऐसे systems और services बेचती हैं
- यह दावा भी कि दशकों से robust software नहीं बना, प्रतिवादों से घिरा है
- iPhone कई हफ्तों या महीनों तक reboot के बिना चल सकता है
- Novell file·printer server के 16 साल uptime का उदाहरण मौजूद है
- Unix, Windows, VMS machines, और IBM i जैसे turnkey systems भी लंबे availability उदाहरणों में आते हैं
तकनीकी प्रगति और productivity पर प्रतिवाद
- “tech companies अब technology को आगे नहीं बढ़ातीं” इस बात से आंशिक सहमति है, लेकिन पैसे को technology से ऊपर रखने वाली कंपनियाँ पहले भी थीं
- file system, web server, database, और programming language जैसे “boring” माने जाने वाले क्षेत्रों में भी लगातार development और improvement हो रहा है
- Blow जिन abstraction, virtualization, और containerization layers को नापसंद करते हैं, वे भी बहुत प्रयास से बेहतर बनाई जा रही हैं; केवल नापसंद होने से वे तकनीकी प्रगति नहीं रह जातीं ऐसा नहीं है
- Facebook कर्मचारियों की productivity लगभग शून्य होने का दावा इस धारणा पर टिका है कि Facebook के products को सिर्फ social platform features के रूप में देखा जाए
- Facebook कंपनी के कर्मचारियों में legal, accounting, graphic design, system administration, research, HR, और middle management जैसी कई भूमिकाएँ शामिल हैं
- Instagram, WhatsApp, और Oculus VR जैसे अन्य व्यवसाय भी हैं
- Facebook का वास्तविक product एक ad delivery platform है, और personal व private data इकट्ठा कर उसे targeted advertising में बदलना, भले user-facing feature न लगे, revenue में दिखाई देता है
low-level ज्ञान और abstraction के दो पहलू
- यह माना गया है कि कई programmer ऐसे environment को पसंद करते हैं जहाँ उन्हें memory allocation और pointers से सीधे नहीं जूझना पड़ता
- अनावश्यक JavaScript framework से simple blog render करना, या bundled browser के अंदर धीमे चलने वाले desktop apps जैसी अत्यधिक abstraction समस्याजनक मानी गई है
- लेकिन आज C संभाल सकने वाले लोगों की संख्या और C·assembly code की मात्रा अतीत से अधिक भी हो सकती है
- Linux और NetBSD को CPU जैसे दिखने वाले अनेक targets पर लगातार port किया जा रहा है
- Rust robustness पर ध्यान देते हुए भी pointers और memory management उपलब्ध कराता है
- Harvard CS50 memory layout, pointers,
malloc(),free()जैसी चीज़ें खुले lectures में पढ़ाता है
- garbage collection और functional programming नई abstractions नहीं हैं
- Lisp ने 1950 के दशक के उत्तरार्ध में दोनों उपलब्ध करा दिए थे
- Lisp का इस्तेमाल NASA Jet Propulsion Lab जैसे “hardcore” environments में भी हुआ है
- COBOL Blow के व्याख्यान में नहीं था, लेकिन यह एक high-level language है जो banking और financial infrastructure की नींव बनाकर आज की सभ्यता-स्तरीय व्यवस्था में अहम भूमिका निभाती है
Ken Thompson का “3-week Unix” उदाहरण
- Ken Thompson ने 3 हफ्तों में assembler, editor, और basic kernel बनाया, इसे असाधारण उपलब्धि माना गया है
- लेकिन उस समय के software की robustness, user-friendliness, और functionality कितनी थी, यह स्पष्ट नहीं है
- उस दौर की working conditions और आज के developers की conditions में बड़ा अंतर है
- documentation, code review, daily standup, backlog grooming, user stories, unit test, customer requirements, A/B test, commit messages, और corporate coding standards जैसी चीज़ें आज development के साथ जुड़ी रहती हैं
- open office में बाधित होने वाला माहौल और Bell Labs जैसी व्यक्तिगत कार्य-परिस्थिति भी अलग हो सकती है
- Thompson का एक उदाहरण यह साबित नहीं करता कि अतीत के सभी programmers अधिक productive थे
- Thompson ने delays के लिए कुख्यात Multics पर भी काम किया था
- IBM OS/360 जैसे बड़े projects भी लंबे समय तक delayed रहे, और Frederick P. Brooks ने इसी अनुभव के आधार पर 1975 में 『The Mythical Man-month』 लिखा
software प्रगति और user expectations
- कुल मिलाकर computers दशकों पहले की तुलना में अधिक robust हुए हैं, और programmers भी कम से कम पहले जितने productive माने जा सकते हैं
- हाँ, कुछ मामलों में शुरुआत करना अधिक जटिल हो गया है, जिससे शुरुआती productivity घट सकती है
- आधुनिक users simple arithmetic के लिए RPN सीखना या flyers बनाने के लिए troff directives लिखना नहीं चाहते
- convenient interfaces और advanced features abstraction से अलग भी complexity और development time बढ़ाते हैं
- पुराने Amiga OS में file copy के दौरान crash होकर hard drive partition खराब होने का उदाहरण दिखाता है कि पुराने systems ज़रूरी नहीं अधिक stable थे
- आधुनिक home computer OS में memory protection और journaling file systems होते हैं, इसलिए वही समस्या बहुत कम होती है
- Windows 10 Home में कमियाँ हैं, लेकिन इसमें ये प्रगतियाँ शामिल हैं
“पहले बस कर सकते थे” वाले दावे
-
program copy करके चलाना
- एक computer से दूसरे पर program copy करके चलाना आज भी संभव है, यदि target architecture और compile conditions समान हों
- Go से build किया गया
slack-termका statically linked binary Raspberry Pi devices पर चलने का उदाहरण दिया गया है - लेकिन standalone programs के सामान्य होने का दौर C64 या PC/XT युग तक पीछे जाता है, और Amiga का Deluxe Paint IV भी कई auxiliary files और third-party function libraries पर निर्भर था
- कुछ Amiga games file system को bypass करने वाली track-loaded floppy का उपयोग करते थे, जो एक तरह के उस समय के container जैसे थे, लेकिन इससे hard disk install और multitasking रुक जाती थी
-
सिर्फ CPU समान हो तो code चल जाएगा
- सिद्धांततः, यदि machine code को memory में लोड कर program counter उस पर सेट कर दिया जाए तो execution हो सकता है
- लेकिन graphics output, sound playback, input handling, और disk writing जैसे वास्तविक कामों में hardware differences बड़ी समस्या बनते हैं
- पुराने Z80-based home computers में CPU समान होने के बावजूद peripheral hardware अलग था, इसलिए वास्तविक portability कठिन थी
- उलटे, Basic जैसे higher abstraction level वाले programs कई machines के बीच अधिक आसानी से port हो सकते थे
- Apple के ARM-based desktop line लाने के बाद, metal के बहुत पास रहने की तुलना में abstraction पर निर्भर approach नए CPU पर porting का बोझ कम कर सकती है
-
operating system और hardware access
- operating system केवल CPU की क्षमता छीनता नहीं, बल्कि file system, networking, और multitasking जैसी क्षमताएँ जोड़ता है
- Twitch streamer जैसे users, जिन्हें game के साथ दूसरे programs भी चलाने होते हैं, resource sharing के managed और predictable multitasking की ज़रूरत रखते हैं
- Amiga और Atari के कुछ software निर्माता द्वारा दी गई specs और abstractions का पालन न करके hardware·memory को सीधे access करते थे, इसलिए memory या hard disk जैसे छोटे upgrades से भी वे टूट जाते थे
- specs और abstractions के अनुसार लिखा software hardware changes के बाद भी बिकता रह सकता था
-
graphics, unsigned programs, और LSP
- screen पर pixels draw करना आज भी कई languages में संभव है, और Mode 13h तक पहुँच भी VGA BIOS नाम की शुरुआती hardware abstraction layer के जरिए होती थी
- खास VGA hardware पर निर्भर code portable नहीं था, लेकिन Windows abstractions का उपयोग करने वाले graphics programs Hercules से true-color XGA तक अलग-अलग environments में चल सकते थे
- unsigned programs चलाना भी संभव है, और WordGrinder को खुद compile करके इस्तेमाल करने का उदाहरण है
- Blow की कुछ शिकायतें abstraction से कम, और hardware·software vendors द्वारा systems को lock करने तथा users की power घटाने की समस्या से अधिक जुड़ी हैं
- Language Server Protocol पर लेखक काफी हद तक Blow से सहमत है, लेकिन LSP “method पर click करके definition तक जाना” से कहीं अधिक समस्याएँ हल करता है
games, performance, और multitasking
- आधुनिक productivity apps में performance गिरावट और गंभीर input lag के कई उदाहरण मिलते हैं
- इसका कुछ कारण abstraction है, लेकिन बड़ा कारण खराब code और काम के लिए गलत tools का चयन है
- एक ही platform और UI toolkit इस्तेमाल करने वाले programs के बीच भी उसी machine पर महसूस होने वाला performance बहुत अलग हो सकता है
- Blow द्वारा दिया गया game में Alt-Tab के बाद resolution restore न होने का उदाहरण खराब अनुभव है और इसे सुधारा जाना चाहिए
- लेकिन पुराने DOS games सरल इसलिए थे क्योंकि उन्हें दूसरे processes की चिंता नहीं करनी पड़ती थी
- Windows 3.1 में Doom खेलने के लिए काम save करना, program बंद करना, Windows से बाहर निकलना, और फिर game शुरू करना पड़ता था
- Amiga games भी अक्सर floppy से boot होकर पूरी machine पर कब्ज़ा कर लेते थे और OS में साफ़-सुथरे तरीके से वापस नहीं लौटते थे
- आज game multitasking भले परिपूर्ण न हो, पर इसे अतीत से बेहतर माना गया है
ज्ञान का क्षरण और बदलाव की गति
- Blow का मानना है कि Unity की sprite management जैसी जानकारी, गहरी समझ के बजाय trivia में बदल जाती है
- यह बात स्वीकार की गई है कि आधुनिक software और hardware में बदलाव की गति अक्सर इतनी तेज़ होती है कि अर्थपूर्ण रूप से उसका पीछा करना कठिन हो जाता है
- लेकिन यह abstraction की समस्या से ज़्यादा समय के साथ consistency और software distribution model की समस्या है
- हर 4 हफ्ते में कुछ नया ship करने का चक्र users के लिए stable experience पाना कठिन बना सकता है
- UI बार-बार बदलने से users वास्तविक काम के बजाय लगातार बदलते interface की details से लड़ते रहते हैं
complexity इंसानों द्वारा बनाई गई समस्या है
- Blow का कहना है कि अगर complexity घटाने का निर्णय लिया जाए तो इसे घटाया जा सकता है, और हम abstraction जोड़कर समय बचाने का भ्रम पाल लेते हैं
- सही framework को सही उपयोग में लाया जाए तो यह web developers के लिए बहुत मददगार हो सकता है
- साथ ही, browser से word processing से लेकर games तक सब कुछ करने की कोशिश, या हर नया framework आते ही तुरंत migrate कर जाना, संदेहास्पद रवैया माना गया है
- software complexity सिर्फ programmers की समस्या नहीं; market और organizational environment भी इसे बनाते हैं
- office politics, बेकार meetings, उलझाने वाला time-reporting software, बाहर से तय deadlines, कठिन customer demands, अजीब management decisions, abstract requirements के लिए schedule estimation, और legacy code debugging जैसी चीज़ें developers की पसंद को प्रभावित करती हैं
- complexity इंसानों द्वारा बनाई गई समस्या है, और workplace complexity कम करने से लंबे समय में software complexity भी कम हो सकती है
युवा developers और engine बनाने की क्षमता
- Blow का यह दावा कि युवा game developers ने खुद engine नहीं लिखे हैं और जल्द ही यह क्षमता सामूहिक रूप से भुला दी जाएगी, slippery slope logic के काफ़ी करीब है
- C64, Amiga, या 286 PC रखने वाले अधिकांश लोग low-level developer नहीं बने थे, और बहुत से programmer भी नहीं बने
- abstraction और पहले से बने game engines low-level memory management, pointers, और algorithms सीखे बिना भी creation संभव बनाते हैं
- आज के बच्चे store से खरीदे जाने वाले AAA games जैसे अनुभव बनाना चाहते हैं, और modern games से expectations C64 या Amiga युग से कहीं अधिक हैं
- low-level skills सीखने के रास्ते आज भी मौजूद हैं
- Linux open source community के ज़रिए युवा developers को आकर्षित करता है और Rust, C, C++ जैसी system languages में रुचि जगाता है
- dwm एक window manager है जिसकी settings C source code बदलकर की जाती हैं
- C और Z80 assembly इस्तेमाल करने वाले युवा developers, scratch से Linux distribution बनाने वाले लोग, खुद hardware बनाने वाले लोग, और modern hardware पर research OS चलाने वाले C developers मौजूद हैं
- computer science और electrical engineering courses अब भी C, assembly, और compiler design जैसी बुनियादें पढ़ाते हैं
- programming tools, literature, educational videos, और MIT OpenCourseWare जैसी सामग्री तक पहुँच अतीत की तुलना में सस्ती और बेहतर है
अंतिम निष्कर्ष: abstraction से बड़े मुद्दे
- Blow का निष्कर्ष तकनीक पर लागू survivalism के करीब है, और blackout के समय आग जलाना जानने वाले व्यक्ति की ज़रूरत वाली उपमा से सहानुभूति है
- समाज कुछ programs को लगभग लगातार चलाने की क्षमता पर निर्भर करता है
- failure होने पर global economic collapse या national health system failure जैसे गंभीर परिणाम संभव हैं
- चूँकि ऐतिहासिक और आधुनिक records बढ़ते हुए digital रूप में संग्रहीत हो रहे हैं, इसलिए भविष्य में भी वे सुलभ रहने चाहिए
- complexity नाज़ुक है और abstraction हानिकारक अज्ञान पैदा कर सकती है; simple blog render करने के लिए shadow DOM की ज़रूरत नहीं, और images वाले IRC client के लिए browser shell की भी नहीं
- लेकिन कृत्रिम और लगातार churn भी नाज़ुकता का बड़ा कारण है
- “Agile” development का उद्देश्य अधूरा और untested software ship होने से रोकना था, लेकिन व्यवहार में अधूरे releases लगातार आते रहते हैं
- ads, trackers, और telemetry systems व्यवहार में design-by-backdoor की तरह काम करते हैं और vulnerability व असुरक्षा बढ़ाते हैं
- digital दुनिया की बड़ी समस्या privacy और freedom है
- hardware के साथ सीधे interface न कर पाने की वजह abstraction चुनना नहीं, बल्कि ऐसे platforms का बचना भी हो सकता है जो लगातार अधिक locked और remotely controlled होते जा रहे हैं
1 टिप्पणियां
Hacker News की राय
Montana State में मैं ट्रांजिस्टर से लेकर वास्तविक computing systems तक कवर करने वाली systems class पढ़ाता हूँ, और क्लास शुरू होने पर कुछ छात्रों को ठीक से यह भी नहीं पता होता कि file system क्या है
Blow कुछ details में गलत है, लेकिन मुझे लगता है कि tech students के लिए high school से ही NAND-to-Tetris जैसी शिक्षा पर गंभीरता से सोचना चाहिए
हम Little Man Computer या साधारण visual MIPS emulator जैसे “पुराने” models इस्तेमाल करते हैं; वे realistic नहीं हैं, लेकिन आम लोग समझ सकें इतनी complexity में यह एहसास देते हैं कि हम कहाँ से आए हैं
आजकल recommend की जाने वाली 64-bit architecture textbooks देखकर बस हँसी आती है, और technology को उसकी जड़ों तक जोड़ना एक कठिन समस्या है
समस्या यह है कि mobile operating systems और software companies user data को जितना हो सके apps के अंदर walled garden बनाना चाहती हैं
भले ही आप पहले से files पर काम कर रहे हों, वे आपको मौजूदा data को अपने storage में “import” करवाती हैं, और modified version को नई copy के रूप में खुद “export” या “share” करना पड़ता है
मैं Montana State में industrial engineering में master's कर रहा हूँ, और रोज़ ऐसे PhD students से पाला पड़ता है जो सरल partial derivatives भी नहीं कर पाते
पिछले semester की 400-level math class में एक student था जिसे दो matrices जोड़ना भी नहीं आता था
computer science senior को file system न पता होना भी अजीब है, लेकिन यहाँ जो absurd चीज़ें देखी हैं, उनके मुकाबले यह तो काफ़ी मामूली लगता है
2000s में जब पहली बार college गया था, तब की तुलना में माहौल बहुत अलग है और यह depressing है, लेकिन अगले spring के job market को लेकर उल्टा confidence बढ़ता है
नाम के उलट, computer science कंप्यूटर खुद के बारे में अध्ययन नहीं है; computer ज़रूरी tool ज़रूर है, लेकिन असली केंद्र domain abstraction और language modeling, और उनका application है
जैसे astronomer को telescope उतना ही चलाना आना चाहिए जितनी जरूरत हो, वैसे ही computer scientist को computer उतना ही चलाना आना चाहिए जितनी जरूरत हो
computer को ब्रह्मांड के केंद्र में रखकर computer science का शुरुआती बिंदु बनाना बड़ी गलती है, और ऐतिहासिक रूप से भी बहुत भ्रम का स्रोत रहा है
“low-level” programming भी आखिरकार abstraction और language ही है; बस चर्चा के target domain की abstraction को simulate करने के लिए computing device की language इस्तेमाल की जाती है
खाली समय में मैं MIPS assembly decompile करता हूँ, और छोटे functions को बिना किसी दूसरे tool के हाथ से equivalent C code में वापस बदल सकता हूँ
लेकिन यह dilute नहीं होती। क्योंकि teaching होती है और books व computers हैं, इसलिए teachers को bard कहने की जरूरत नहीं पड़ती
आखिरकार यह एक blog post के बारे में एक और blog post है, और वे bloggers कितने “important” हैं, पता नहीं, लेकिन इसमें blog के लिए blog जैसी बू आती है
अगर कोई उम्रदराज web developer abstraction की आलोचना करता है, तो निशाना React developers होते हैं; अगर Python developer आलोचना करता है, तो निशाना उम्रदराज web developers होते हैं; और अगर C++ application developer आलोचना करता है, तो निशाना Python developers होते हैं
firmware developers application developers को निशाना बनाते हैं, और electrical engineers firmware developers को
अपने knowledge level को आधार बनाकर over-abstraction की रेखा खींचना और उसके बाद की हर चीज़ को “सभ्यता को मारने वाला” कहना काफ़ी कमाल का attitude है
कई अच्छी बातें हैं, और मैंने वह talk देखी है, इसलिए मुझे लगता है criticism महत्वपूर्ण है
लेकिन Blow ने जब कहा कि “आप बस screen पर pixels नहीं draw कर सकते”, तो वह सही था
मैं एक mid-sized game company में game engine programmer के रूप में काम करता हूँ, और graphics code पर काम करने के लिए लोगों को hire करना बहुत मुश्किल होता जा रहा है
DX12 जैसी generation के APIs ने पिछली generation DX11 की तुलना में programmers से अपेक्षित स्तर बहुत बढ़ा दिया है, और इस API से कुछ भी करना अपने-आप में बड़ा काम है
Microsoft ने भी कभी माना था कि पुराने graphics API experience के बिना DX12 सीखना बेहद कठिन है, लेकिन अब docs में वह quote नहीं मिल रहा
“ये APIs उन developers के लिए हैं जो graphics card की limits push करना और बहुत low-level optimization करना चाहते हैं” — यह counterargument कुछ हद तक सही है, लेकिन अब यह industry standard बन चुका है और जिनके पास पिछला experience नहीं है, उन्हें यह लगभग सिखाने लायक नहीं रह गया है
अगर कुछ नहीं बदला, तो hire करने लायक talent pool लगातार सिकुड़ता रहेगा
software application बनाते समय screen पर एक button draw करना भी इतना कठिन हो गया है कि ज्यादातर लोग बस progressive web app इस्तेमाल कर लेते हैं, जो possible performance से 100 गुना धीमा होता है
2025 में GUI application के लिए सचमुच सबसे अच्छा विकल्प Java Swing और Qt ही हैं क्या?
कुछ बड़े concepts हैं जो पूरी चीज़ को जोड़ते हैं, लेकिन docs में उनका लगभग संकेत भी नहीं मिलता; उन्हें सीखने के लिए training sessions में जाना पड़ता है या किसी ऐसे व्यक्ति से बात करनी पड़ती है जो पहले से जानता हो
मेरा मानना है कि server-side JavaScript और React जैसी चीज़ों ने, वे असल में जो काम करती हैं उसकी तुलना में, web software development को सचमुच गड़बड़ बना दिया है
आजकल कुछ बच्चों को तो यह भी नहीं पता कि browser में render होने वाली चीज़ HTML होती है। वे सोचते हैं कि browser खुद React को render करता है
ऊपर से Vercel के CEO ने यह बिल्कुल बेवकूफाना बात कही कि React development का Linux kernel है
https://news.ycombinator.com/item?id=42824720
मैं vanilla js, jQuery, Knockout, Angular 1 के दिनों को याद करने जितना पुराना हूं, लेकिन तब भी बुनियादी भ्रम हमेशा मौजूद था
React, और कभी-कभी सिर्फ JSX भी, समझदारी से इस्तेमाल किया जा सकता है
बल्कि मैं Vercel, Next, Apollo, Prisma जैसे venture-funded tools और web development influencers को दोष देता हूं, जो पैसे लेकर web को कचरे से भरते हैं
सोचें तो Notion boards से लेकर संदिग्ध database choices तक, software बनाने की हर चीज़ फूली हुई हो गई है
लेकिन एक ऐसे व्यक्ति के तौर पर जो libraries के बिना भी ठीक से काम कर सकता है, मैं यह जोड़ना चाहूंगा कि DOM मानवता द्वारा आविष्कृत सबसे खराब APIs में से एक है और “reactive programming” पुराने तरीके से बेहतर model है
NextJS ने कई वर्षों की tooling improvements को पीछे धकेल दिया है और यह Vite से कहीं धीमा है
statically built NextJS में कोई interaction न रखने वाला page भी कुछ न करने के लिए 100KB JavaScript download करता है
Facebook उस काम को React के लिए “compiler” से हल करने की कोशिश कर रहा है, जिसे बस default रूप से बेकार में components re-render न करने वाला बनाकर किया जा सकता था
लगभग drop-in replacement Preact की तुलना में React बहुत बड़ा है, और यह दिखाता है कि Facebook को कितनी कम परवाह है
HTML एक serialization format है, और browser इसका उपयोग करके memory में DOM बनाता है
React कुछ भी HTML में serialize नहीं करता और सीधे DOM में render करता है
इसके गलत होने के बावजूद इसे इतने upvotes मिलना साफ दिखाता है कि यह thread “बादलों पर मुक्का मारते बूढ़े आदमी” जैसा है
मेरी समझ में HTML browser का input है, और browser इसे DOM में बदलता है, जिसके बाद screen drawing और input handling वगैरह होता है
यह फर्क महत्वपूर्ण है, क्योंकि React या virtual DOM परिवार की JavaScript libraries HTML नहीं बनातीं, बल्कि JavaScript में बने DOM manipulation commands बनाती हैं
Blow की आलोचना में बहुत अच्छी बातें हैं, लेकिन मुझे लगता है कि वे यह नज़रअंदाज़ करते हैं कि बहुत-सा पीछे जाना पीढ़ियों के बहाव या information entropy से नहीं, बल्कि फैसले लेने वालों की खुली बदनीयती से आता है
Blow development के बारे में कई बार सचमुच बेहतरीन बातें पकड़ते हैं, और कई बार पूरी तरह चूक जाते हैं
उनकी उपलब्धियां बड़ी हैं और सुनने लायक ideas भी हैं, लेकिन उनके साथ अलग न पहचाने जा सकने वाला बहुत-सा बकवास भी पेश होता है
civilization collapse वाली बात मुझे उसी बकवास में से एक बहुत जोरदार लगी, और मैंने उसे दो बार सुना लेकिन ज्यादातर नज़रअंदाज़ किया
मूल लेख ने ज्यादा principled rebuttal दिया, इसके लिए आभारी हूं
मुझे लगता है Casey Muratori, Blow की नकल करते हैं लेकिन अच्छे हिस्से भी ठीक से नहीं कर पाते
Muratori 10 साल पहले शुरू किया हुआ game भी खत्म नहीं कर पाए
दूसरी ओर modern game engines, यहां तक कि Raylib जैसी चीज़ों को मिलाकर, weekend game jam में भी काफी ठीक-ठाक results बनाए जा सकते हैं, और Blow के Sokoban game जैसा कुछ तो खासकर करीब 10 लोगों की team हो तो लगभग 6 महीनों में बनाया जा सकता है
मैंने उनका कुछ content देखा है, और वे जिन topics को जानते हैं उनके बारे में विनम्र लेकिन स्पष्ट राय रखने वाले लगे, और मुझे लगता है Handmade Hero भी उन्होंने शानदार किया
Jira को एक ticket दिखाने में लगने वाला समय, Slack को chat room switch करने में लगने वाला समय, VSCode का सामान्य typing speed के साथ न चल पाना — यह सचमुच पागलपन है
वे बस व्यापक आलोचनात्मक बयान फेंकते हैं और फिर कुछ न करने के लिए गायब हो जाते हैं
यह कहना भी मुश्किल है कि उन्होंने कोई महान उपलब्धि हासिल की है; मुझे लगता है उन्होंने ठीक-ठाक काम किया है
उन्होंने सिर्फ दो games release किए हैं, और वे game से ज्यादा puzzles जैसे हैं। एक बार पूरा कर लेने के बाद उन्हें दोबारा खेलने की जरूरत लगभग नहीं रहती
Braid ठीक है, और The Witness बस Flow जैसा है
उसके बाद से वे 10 साल से programming language बना रहे हैं, लेकिन “अभी पूरी नहीं हुई” के कारण उसे public नहीं करते
लगता है किस्मत से पैसे कमाने के बाद वे खुद को असलियत से कहीं ज्यादा talented समझने लगे हैं
modern software environment में निश्चित रूप से बहुत समस्याएं हैं, और मुझे लगता है over-abstraction भी एक समस्या है
लेकिन उलटा चरम भी बुरा है, और अतीत को जरूरत से ज्यादा romanticize करने की प्रवृत्ति भी है
crashes और reboots भी समस्या थे, Amiga जैसे systems में hardware versions के बीच compatibility issues थे, और compatibility को प्राथमिकता देने वाले systems भी incompatibility से मुक्त नहीं थे
सबसे unstable modern system Windows 11 पर भी मेरा computer 2010 से पहले इस्तेमाल किए किसी भी computer की तुलना में कहीं ज्यादा stable है, और Windows 95 का software भी चला सकता है
रोजमर्रा में इस्तेमाल किया जा सकने वाला computer उस computer से बेहतर है जिसे इस्तेमाल न किया जा सके
हर सरलीकरण abstraction नहीं होता, और हर abstraction सरलीकरण भी नहीं होती
लेकिन सरलीकरण की कोशिश में अक्सर abstraction बन जाती है
मुझे नहीं लगता कि abstraction software या सभ्यता को मारती है, लेकिन अल्पकालिक सरलीकरण के नाम पर बनाई गई खराब abstraction लचीलापन, agility और accessibility घटा देती है
लगभग हर भाषा के syntax sugar को देखें तो एक बिंदु आता है जहां किसी खास nuance से मिलने वाला स्थानीय सरलीकरण पूरे tool की बढ़ी हुई जटिलता को सही नहीं ठहरा पाता
ज्यादा syntax वाली भाषाओं में लोग किसी एक खास तत्व की वजह से गलती नहीं करते, बल्कि इसलिए करते हैं क्योंकि जटिल समस्याओं को ठीक से हल करने के लिए tool का इस्तेमाल करना ही मुश्किल हो जाता है
Kotlin में async और coroutines “thread जैसी” code को संभालते समय मेरे अनुभव में जो जटिलता जोड़ते हैं, वह Elixir/Erlang में उसी तरह की समस्या से निपटने के तरीके से बिल्कुल अलग है
दोनों parallel और asynchronous computation की पुरानी समस्या के लिए abstraction और सरलीकरण देते हैं, लेकिन पहला कई परतों में simplicity को गुणा करके फिर से कुछ जटिल बना देता है, जबकि दूसरा बस काम करने वाली सचमुच सरल abstraction के करीब है
लेखक लगता है कि युवा पीढ़ी से है, इसलिए शायद Blow की बात समझे बिना ही चूक गया
विडंबना यह है कि वह लेख खुद Blow जिस तरह के उदाहरण की बात कर रहा था, वैसा ही दिखता है
यह कुछ ऐसा है जैसे आप कहें कि Figma अपने ही खराब UX, UI और product management तरीके को सामान्य बनाकर design दुनिया को अभूतपूर्व पैमाने पर खराब कर रहा है, और जवाब में युवा designers हैरान होकर कहें कि सब ठीक तो है
वह ज्ञान इसलिए है क्योंकि कोई उस माहौल में बड़ा हुआ है; वे नहीं हुए, और culture व experience से जुड़ी चीजें सीखना भी आसान नहीं होता
ऐसी ad hominem बात बातचीत में कुछ नहीं जोड़ती
“software आगे बढ़ रहा है, यह दावा स्पष्ट रूप से झूठा है” इस बात के उलट, मैं आज भी अपने प्रिय Amiga computers अक्सर इस्तेमाल करता हूं
कुछ हफ्ते पहले Amiga hard drive पर files copy करते समय computer अचानक crash हो गया, और यह इसलिए नहीं था कि मैंने कुछ गलत किया था, बल्कि इसलिए था कि पुराने home computer operating systems बहुत स्थिर नहीं थे
नतीजतन hard drive partition corrupt हो गया, operating system file system को revalidate नहीं कर पाया, और आखिर में partition को फिर से format करने के अलावा कोई रास्ता नहीं बचा
मुझे design की ज्यादा समझ नहीं है, लेकिन Figma के बारे में दावा Blow के दावे की तरह पूरी तरह गलत है, इतना समझ सकता हूं
यह nostalgia बोल रहा है। user interfaces में हमेशा बहुत गड़बड़ियां रही हैं, और software व बाकी सब में भी यही था
अतीत के top examples की खूबियां ही याद रह जाती हैं, और कचरा चीजें तथा अच्छी तरह design की गई चीजों की नाकामियां भी भूल जाती हैं
समस्या वे abstractions हैं जिन पर गहराई से विचार नहीं किया गया
कई abstractions साफ तौर पर first draft या first attempt जैसी लगती हैं, फिर भी tech industry की speed worship और अहंकार के कारण उन्हें कई बार refine करने से पहले ही release कर दिया जाता है
जब ऐसी abstraction किसी popular project का हिस्सा बन जाती है, तो दूसरे लोग “best practice” के धुंधले झंडे के नीचे herd mentality में उसे copy कर लेते हैं
इस प्रक्रिया को 10–20 साल दोहराएं तो एक विशाल mess बन जाता है
इससे भी बुरा यह है कि technology की वजह से paradoxically over-socialized समाज में, “fraud” पकड़े जाने से बचने की social consensus अधपके solutions को फैलाता रहता है
मुझे Jonathan Blow की वह presentation पसंद है और मैं उसे साल में कम से कम एक बार फिर देखता हूं। मुझे लगता है कि वह कोई विवादास्पद बात नहीं कह रहे; बल्कि कई developers अंदर से जानते हैं कि वे न तो अपना सर्वश्रेष्ठ देकर release करते हैं, न ही युवा पीढ़ी को ठीक से guide करते हैं, इसलिए वे गुस्सा होते हैं या चुभन महसूस करते हैं
हम ऐसी culture तक पहुंच गए हैं जहां novelty-seeking रोजमर्रा की चीज है और कभी-कभी उसकी प्रशंसा भी होती है
पहले पर्याप्त रूप से review किए गए solutions cultural standard हुआ करते थे, लेकिन अब कोई चीज सच में अच्छी है या नहीं, इससे अलग, नया होना ही standard बन गया है
Blow की दलील की बारीकियों को अंतहीन खोदा जा सकता है, लेकिन evidence हर जगह सामने ही दिख रहा है
और काफी लंबे time horizon पर यह civilizational collapse तक ले जा सकता है; दुनिया में टूटी हुई चीजों की मात्रा देखें तो यह कहा जा सकता है कि ऐसा पहले से हो रहा है
दुख की बात है कि एक flawed thesis को इतनी detail में तोड़कर समझाना पड़ रहा है
शुद्ध empiricist भी शुद्ध theorist जितना ही reality से कटा होता है, और Blow अपने experience से मेल खाने के कारण arguments गढ़ता है, अपनी complaints से मेल खाने वाले examples ही चुनता है और exceptions को rules की तरह पेश करता है