- AI एजेंट की वजह से अब कुछ ही घंटों में पर्सनल native app बनाए जा सकते हैं, और सॉफ़्टवेयर Emacs-स्टाइल customization के क्षेत्र की ओर बढ़ रहा है
- MDV.app, macOS के लिए एक Markdown viewer है, जिसमें search, SQLite FTS indexing, bookmarks, table of contents, और position memory जैसी सुविधाएँ कुछ ही घंटों में लागू की गईं
- हर Electron app के साथ उसकी अपनी Chromium copy आने की समस्या और native UI development की कठिनाई बड़ी थी, लेकिन Claude ने SwiftUI को बहुत दक्षता से संभाला
- Emacs संस्कृति की तरह, अपनी-अपनी असुविधा दूर करने वाले अत्यधिक-विशिष्ट tools बढ़ रहे हैं, और तैयार उत्पादों से ज़्यादा ideas, observations, और prompts की value बढ़ रही है
- एजेंट coding side projects और terminal tools पर उपयोगी UI जोड़ना आसान बनाती है, और native UI बनाना एक मज़ेदार काम में बदल देती है
Markdown viewer खुद बनाने की वजह
- सॉफ़्टवेयर development में Markdown LLM से पहले ही एक shared language की तरह इस्तेमाल होता था, और agents के बाद TUI tools फिर बढ़ने लगे, जिससे terminal में Markdown को लगातार scroll करके पढ़ने का अनुभव और असहनीय हो गया
- TUI Markdown viewers में Charm का glow और Josh का Markless हैं; Markless table of contents navigation भी support करता है, लेकिन terminal आम तौर पर monospace font पर चलता है, इसलिए लंबे समय तक पढ़ना थकाऊ होता है
- macOS में Obsidian, Typora, Bear जैसे graphical UI Markdown editors हैं और पढ़ने में अच्छे हैं, लेकिन ये सब editors हैं, इसलिए
.md फ़ाइल खोलते ही मौजूदा editing environment और window layout बिगड़ जाता है
- App Store के Markdown viewers शुरुआत में ठीक लगते हैं, लेकिन असली उपयोग में पता चलता है कि search नहीं है, in-app purchase है, या चुने गए text को clipboard में copy नहीं किया जा सकता
- 2026 में ठीक-ठाक viewer ढूँढते रहने के बजाय, मनचाहा Markdown viewer AI एजेंट से generate किया जा सकता है — इस सोच के साथ दिशा बदल दी गई
Claude से बना MDV.app
- MDV.app App Store में मिले dedicated Markdown viewers से बेहतर स्तर तक कुछ ही घंटों में बना, और असली interaction time लगभग 30 मिनट था
- एक पुराने MacBook पर Xcode और git सेट किया गया, Claude environment तैयार किया गया, और Swift व macOS design से जुड़ी मदद खोजकर रखने जैसी तैयारी कुछ हफ़्ते पहले से चल रही थी
- MDV macOS का सर्वश्रेष्ठ application या कोई असाधारण रूप से सक्षम software नहीं है, लेकिन dedicated macOS Markdown viewer के रूप में यह काफ़ी बेहतर है और जीवन की गुणवत्ता में बड़ा सुधार लाता है
- MDV के मुख्य features हैं text selection और copy, fixed-string search, editable history में मौजूद सभी Markdown files के लिए SQLite FTS indexing, shortcut bookmarks, और table of contents navigation
- यह documents के बीच आने-जाने पर position याद रखता है, restart के बाद भी वहीं से जारी रहता है, और color themes तथा पढ़ने-लायक typography देता है, ताकि
.md फ़ाइल पर क्लिक करते ही मनचाहा reading environment तुरंत खुल जाए
Electron की सीमाएँ और native UI का बदलाव
- Signal message आते ही स्क्रीन झिलमिलाती थी, और Signal app को explicitly hide करने तक यह रुकती नहीं थी, जिससे यह सूक्ष्म flicker लगभग migraine शुरू होने जैसा महसूस होता था
- यह समस्या इसलिए थी क्योंकि Signal एक Electron app है; ऊपर से यह native macOS app जैसा दिखता है, लेकिन वास्तव में यह Chromium की एक copy से कोई गुप्त web page render कर रहा होता है
- पिछले 10 सालों में आई लगभग हर UI app मानो अपनी-अपनी Chromium copy साथ लेकर चल रही हो, और Electron अच्छा न होते हुए भी पर्याप्त रूप से स्वीकार्य विकल्प बना रहा
- असली native UI बनाना ऐतिहासिक रूप से कठिन काम रहा है, और यह काम सौंपने लायक औसत स्तर के लोग भी मिलना मुश्किल थे; सक्षम macOS native UI developers बहुत कम थे
- Claude सिर्फ औसत SwiftUI developer की जगह लेने भर तक सीमित नहीं है, बल्कि उसे वास्तव में SwiftUI में दक्ष developer माना जा सकता है
Emacs संस्कृति का पूरे सॉफ़्टवेयर में फैलना
- MDV ऐसा polished product कम है जिसे install करके इस्तेमाल करने की सिफारिश की जाए; इसे उस तरह देखना ज़्यादा सही है जैसे Emacs user किसी चमकदार
.emacs config को देखकर ideas लेकर उससे बेहतर कुछ बना ले
- Emacs संस्कृति में लंबे समय से उपयोगकर्ता elisp से अपने text editing से शुरू हुए निजी असुविधाओं को हल करने वाले applications बनाते रहे हैं, और वे tools text editor की तर्कसंगत सीमा से काफ़ी आगे तक फैल जाते हैं
- /r/emacs, Product Hunt-शैली की product promotion से ज़्यादा show-and-tell culture के करीब है; कुछ widely used elisp packages ज़रूर हैं, लेकिन Magit को छोड़ दें तो लोग अक्सर उन्हें और चमकदार रूप में फिर से बना लेते हैं
- Emacs संस्कृति की कमजोरी यह थी कि Magit को छोड़कर ज़्यादातर packages बदसूरत, धीमे, और ऐसे खराब user experience वाले थे जिन्हें लंबे समय तक elisp झेलने के बाद ही पहचाना जा सकता था
- AI एजेंट ने इस संस्कृति को Emacs के बाहर धकेल दिया है; अब अगर screen और input तक access हो, तो native UI को विश्वसनीय ढंग से बनाया जा सकता है, और native UI professionally packaged programs के क्षेत्र से निकलकर personal customization के क्षेत्र में जा रहा है
पर्सनल native tools की संभावनाएँ
- Emacsified software ज़्यादातर ऐसा personal software होगा जो सिर्फ उसके निर्माता के लिए उपयोगी है, और
.emacs में पड़े पुराने elisp programs की तरह बहुत से tools भुला दिए जाएँगे
- कभी-कभी ऐसे programs इतने उपयोगी हो सकते हैं कि कई लोग उन्हें install करें, लेकिन तब भी सबसे महत्वपूर्ण चीज़ वितरित artifact या source code नहीं भी हो सकती
- अगर एजेंट ने सारा SwiftUI code लिखा है, तो source code को बारीकी से पढ़ने से ज़्यादा महत्वपूर्ण यह idea और observation हो जाता है कि “ऐसी चीज़ भी बनाई जा सकती है, और यह अच्छे से काम करती है”
- इस तरह के software में source code से ज़्यादा prompt की value हो सकती है, और जो लोग software को सीधे चलाकर बनाना सीख चुके हैं, उनके लिए सब कुछ सिर्फ तकनीकी रूप से ही नहीं बल्कि व्यावहारिक रूप से भी programmable हो जाता है
- एजेंट से बने software को “build” कहना शायद उसमें लगे प्रयास को ज़्यादा बढ़ा-चढ़ाकर बताना होगा; असली अनुभव अचानक कहीं ज़्यादा configurable हो चुके platform पर configuring करने जैसा है
- AI का उपयोग करने वाले developers कई सालों से जमा पड़े random side projects को आखिरकार पूरा कर रहे हैं
- अब ऐसे अत्यधिक-विशिष्ट tools सिर्फ पूरे ही नहीं हो रहे, बल्कि उनके पास उपयोगी UI भी हो सकता है; इससे Emacs के भद्दे UI को सहने की पुरानी वजहों का कुछ हिस्सा कमज़ोर पड़ता है
- terminal apps को बहुत आसानी से बेहतर बनाने की संभावना बढ़ गई है, और
iostat, कई hosts पर फैले iostat, या bpftrace जैसे tools को भी कहीं ज़्यादा समझने योग्य रूप में बदला जा सकता है
bpftrace terminal visualization के लिए Brendan Gregg को जो जटिलता झेलनी पड़ती थी, अब उसे वैसे ही सहते रहने की ज़रूरत नहीं है, और इसका खुद बनाया गया उदाहरण भी मौजूद है- vulnerability researcher के नाते 2026 की पहली छमाही में एजेंट coding आधारित exploit development की प्रगति दिलचस्प थी, लेकिन ज़्यादातर लोगों के लिए वह डर पैदा करने वाला बदलाव था; इसके मुकाबले native UI बनाना मज़ेदार हो जाना लगभग शुद्ध रूप से अच्छी ख़बर है
- अपने काम की समस्या के हिसाब से ज़रूरत से ज़्यादा विशिष्ट tools बनाइए, थोड़ी देर उनका आनंद लीजिए, फिर उन्हें साझा कीजिए — या उससे भी बेहतर, उनके screenshots और इस्तेमाल किए गए prompts साझा कीजिए
1 टिप्पणियां
Hacker News की राय
मेरा मानना है कि जिन क्षेत्रों में अब ज़्यादातर पहले से पैकेज किए गए specialized software का राज है, उन्हें nerds फिर से अपने हाथ में ले सकते हैं: podcast apps, music listening apps, feed readers, Bluesky clients, note apps, desktop bookmark/read-later apps, chat और messenger, time trackers, recipe managers जैसी चीज़ें
Claude के साथ आप आसानी से ऐसे नतीजे पा सकते हैं जो alternatives से बेहतर हों। हो सकता है वे सबसे बेहतरीन या विश्व-स्तरीय competitive apps न हों, लेकिन वे आपकी अपनी अजीब-सी workflow के लिए कहीं ज़्यादा उपयुक्त apps हो सकते हैं
Music.app इस्तेमाल करने में तकलीफ़देह है, लेकिन Apple ने core functionality को बहुत पहले ही MusicKit में अलग कर दिया था। अब असली product तो MusicKit है, इसलिए समझ नहीं आता कि हम अब भी Music.app क्यों इस्तेमाल कर रहे हैं; यही नया बदलाव है
इस दिशा में एक प्रयोग https://github.com/dharmatech/9social है
पहला client plan9 के लिए लिखा गया था, और ऐसा करने से design ईमानदार बना रहता है। अगर यह plan9/rc/acme पर चलता है, तो इसका मतलब बनता है
video demo https://youtu.be/q6qVnlCjcAI है, और मौजूदा implementation 3000 lines of code से कम है
Emacs की बात करें तो 9social को Emacs project Org Social से काफ़ी प्रेरणा मिली है: https://github.com/tanrax/org-social
यह time entry के लिए spreadsheet-आधारित अधूरा interface है। इसे consulting के लिए बनाया था, लेकिन data storage तक नहीं पहुँचा। इसमें एक प्यारा-सा algorithm है जो उन लगभग सभी प्राकृतिक तरीकों को संभाल सकता है जिनसे लोग समय दर्ज करते हैं; मैंने इसे इसलिए बनाया क्योंकि मुझे existing time trackers का structured input थोपना पसंद नहीं था: https://stackoverflow.com/a/49185071/59087
recipe manager: https://repo.autonoma.ca/repo/recipe-fiddle
LLM युग में ingredients को classify करना और PDF publishing के लिए TeX में format करना बहुत आसान हो जाएगा। इस project का idea यह था कि web recipes या handwritten scans को लगभग copy/paste करते ही वे अपने-आप format हो जाएँ
F-Droid में ऐसा कोई app नहीं था जो ये सारी शर्तें पूरी करे, इसलिए मैंने बस खुद APK बना लिया
LLM युग की वजह से software बनाना इतना आसान हो गया है कि अब सब कुछ .emacs file जैसा हो गया है। यानी हर व्यक्ति के पास अपना पूरी तरह निजी और अंतहीन रूप से customizable software cocoon होगा
OP के शब्दों में कहें तो, अब मौजूदा चीज़ें install या सीखने से ज़्यादा आसान अपना solution बनाना हो गया है
Lisp भी एक अच्छा रूपक है। Lisp macros पर पुरानी आलोचना यह थी कि हर programmer चीज़ों को अपनी private language में बदल देता है, जिससे बाकी लोग उसे पढ़ नहीं पाते
Mark Tarver का 2007 का लेख "The Bipolar Lisp Programmer" भी याद आता है: https://hn.algolia.com/?query=comments%3E0%20The%20Bipolar%20Lisp%20Programmer&type=story&dateRange=all&sort=byDate&storyText=none&prefix
उन्होंने "brilliant bipolar mind" की बात की थी, जो दिलचस्प ढंग से आजकल अक्सर सुनाई देने वाले AI psychosis से—चाहे विडंबना में या गंभीरता से—कहीं जुड़ती हुई लगती है
Tarver के लेख https://www.marktarver.com/bipolar.html में कहा गया है कि Lisp community का "throw-away design" BBM के लिए बिल्कुल उपयुक्त है। Lisp में कुछ भी फेंककर बना देना इतना आसान है कि हर कोई अपना solution बनाता है, और जब वह उसके अपने काम आ जाए तो वही काफ़ी माना जाता है
इसके उलट C/C++ में कुछ सार्थक बनाना इतना कठिन है कि वह achievement बन जाता है, और documentation व collaboration की प्रेरणा देता है। employer के नज़रिए से, 10 लोग जो communicate, document और साथ काम कर सकें, एक ऐसे Lisp hacker से ज़्यादा आकर्षक हैं जिसे बदलना मुश्किल हो
जब production आसान हो जाता है तो consumption bottleneck बन जाता है, और sharing कठिन हो जाती है। .emacs file उँगलियों के निशान जितनी व्यक्तिगत होती है; आप उसके टुकड़े ले सकते हैं, लेकिन किसी और की पूरी चीज़ ज्यों की त्यों इस्तेमाल नहीं करना चाहेंगे
जैसे-जैसे ये cocoons और ज़्यादा customized होते जाते हैं, वैसे-वैसे किसी और के लिए उन्हें समझना या इस्तेमाल करना और मुश्किल हो जाता है। cognitive cost भी बड़ा है, और यह किसी दूसरे के कपड़े पहनने जैसा अटपटा लगता है। इसे AI psychosis की बजाय शायद AI solipsism कहना बेहतर होगा
software में configuration management कठिन हिस्सा बनता जा रहा है। source को कैसे share और version-control किया जाए? source है क्या? prompt? OP भी अंत में code से ज़्यादा screenshots और prompts share करने की तरफ़ जाता है
Show HN में भी यह probe balloon छोड़ा गया था कि generated code अब source नहीं रहा, इसलिए prompts share किए जाएँ; लेकिन जानकार लोगों से काफ़ी backlash मिला: https://news.ycombinator.com/item?id=47213630
GitHub पर पड़ रहा दबाव भी शायद इसी प्रवाह की वजह से है। उसका successor कैसा दिखेगा यह साफ़ नहीं, लेकिन अंततः उसकी ज़रूरत पड़ेगी। अभी यह horseless carriage stage जैसा लगता है
उससे भी अहम बात teamwork है। अगर सब BBM बन जाएँ, या हममें से हर एक के पास 24x7 सिर्फ़ अपने लिए generate करने वाली पागल BBM सेना हो, तो हम साथ कैसे काम करेंगे? ये cocoons एक-दूसरे से कैसे बात करेंगे और interoperable कैसे होंगे? AI solipsists की team अपने-आप में विरोधाभास लगती है
AI-driven, agentic development की frontier पर काम कर रही teams और startups शायद अभी सच में इस समस्या से जूझ रही होंगी। जैसे मेरे generated code और तुम्हारे generated code को कैसे compose किया जाए। इस friction की वजह से generated code के productivity gains का कुछ हिस्सा वापस चला जाने की पूरी संभावना है
अफ़सोस यह है कि अभी सार्वजनिक रूप से इस पर ज़्यादा बात नहीं हो रही। कोई भी अनिवार्य standing ovation में सबसे पहले बैठना नहीं चाहता, लेकिन अगर इसे बिना किसी downside के free lunch बताकर पेश किया जाएगा तो चर्चा उबाऊ हो जाएगी और evolution भी धीमी पड़ेगी
अगर नए tools के साथ सबसे गंभीर और अग्रणी काम करने वाले लोग downsides की बात नहीं करेंगे, तो software development में AI को बेकार मानने वाले cynical पक्ष के पास ही downside की सारी चर्चा बची रह जाएगी। मानव-विनाश की बात करने से ज़्यादा मुश्किल माहौल bugs बढ़ने या productivity ठहरने की बात करने का है
मैं जानना चाहता हूँ कि वास्तव में क्या हो रहा है, लोग कैसे प्रतिक्रिया दे रहे हैं, और समय के साथ यह कैसे बदल रहा है। लगता है शायद meetups में जाना पड़ेगा
संबंधित paper का शीर्षक भी यही था: "Easier to Write, Harder to Read": https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6726702
फिर मैं LLM के साथ हुई किसी खास बातचीत के output को क्यों पढ़ूँ? अगर मुझे topic पता है, तो मैं खुद उससे बेहतर बातचीत कर सकता हूँ
ऐसे software में भी कुछ ऐसा ही है। थोड़ा taste हो सकता है, लेकिन ज़्यादातर मामलों में ideas और recipes ज़्यादा मायने रखते हैं
एक monthly "Vibe HN" thread होना अच्छा रहेगा
मैं जानना चाहूँगा कि क्या कोई उससे भी कम समय में custom WhatsApp बनाकर दिखाने वाला video share कर सकता है। और यह तो उस समस्या की शुरुआत भी नहीं है कि लोगों को आपके improvised messenger पर कैसे लाया जाए
अब यह बन गया है: "मैं यह ticket Claude में डालता हूँ, तुम Copilot से करके देखो और results compare करते हैं" या "मैं अपने rough output से PR बनाऊँगा, तुम अपने tool से review कर लेना"। सच कहूँ तो यह लगभग निरर्थक लगता है और pair programming पूरी तरह मर चुकी है
कौन कई agents चलाकर, अलग-अलग work trees में bugs fix करके, और agents.md की inconsistencies ठीक करते हुए देखना चाहेगा
मैं self-operating fully autonomous cloud pipeline बनाने के लिए push कर रहा हूँ, लेकिन management शायद चुपचाप इसे दबाकर रखना चाहती है। लगता है उन्हें सीधी-सी समझ है कि जिस क्षण साबित हो गया कि यह सच में उड़ सकता है, कुछ लोगों की आरामदेह सीटें चली जाएँगी
UNIX कोई product नहीं था, बल्कि tools बनाने और वास्तविक समस्याएँ हल करने के लिए optimized environment था, और tools C में लिखे जाते थे। उस दौरान BBM लोग शायद Boston में Lisp में व्यस्त रहे होंगे
C++ पूरी तरह अलग कहानी है, और वहाँ IDE की ज़रूरत पड़ती है
Emacs में यह गुण इसलिए है क्योंकि वह Lisp इस्तेमाल करता है। programmers के हर चीज़ खुद बनाने लग जाने की सामान्य प्रवृत्ति Lisp में देखी गई थी, और इसे The Lisp Curse कहा गया
इसे curse इसलिए कहा गया क्योंकि programmers सहयोग करना बंद कर देते हैं। हर कोई अपने tower में बंद wizard बन जाता है, कुल प्रगति रुक जाती है, और अंधकार युग आ जाता है
LLM युग की वजह से personal software बनना सच है
लेकिन ईमानदारी से कहूँ तो Emacs इस्तेमाल करने में बिताया गया समय मुझे personal software बनाना नहीं सिखा सका। मेरी Emacs config बहुत नाज़ुक थी, और उसे Windows व macOS पर साथ इस्तेमाल करने की कोशिश तो दुःस्वप्न थी
मेरा university project org-mode और किसी workflow के अजीब मिश्रण से सुंदर LaTeX files बनाता था, लेकिन आज मैं यह समझा नहीं सकता कि उसे फिर से compile कैसे किया जाए। अगर कोशिश करूँ भी, तो शायद मैं LLM से उसे सीधे LaTeX में translate करवा दूँ
मैं चाहता हूँ कि मेरी ज़िंदगी में maintenance जितना कम हो सके उतना कम हो, और हर चीज़ खुद बनाना हमेशा उस लक्ष्य के अनुकूल नहीं होता
हाँ, मैंने एक NETFX application को Rust में फिर से लिखा था। वजह बस यह थी कि install होने में 20 मिनट लगते थे और वह बहुत खलता था: https://github.com/bevan-philip/wlan-optimizer
एक programmer का रोज़मर्रा का काम ही local, remote, cloud, embedded आदि computer systems के behavior को बदलना है। requirements बदलती रहती हैं, scope डगमगाता रहता है, problem space evolve होता है, और sedimentation से बचा नहीं जा सकता
आपको language stacks, data types, formats, CLI और web tools, protocols, paradigms, open-source और proprietary apps के बीच लगातार चलना पड़ता है
इसलिए आपको लगातार adapt करना ही होगा, और आपकी control plane को भी बदलाव के हिसाब से ढलना होगा। कुंजी है automation। हर छोटी परेशानी को automate किया जा सकता है और किया जाना चाहिए। यह workflow को लगातार reshape करने का काम है, यानी tools की ongoing maintenance, लेकिन वह पीड़ादायक reactive maintenance नहीं है
अगर आप programmer हैं और फिर भी अपने लिए लगातार software नहीं बनाना चाहते, तो यह भ्रम है। यह वैसा है जैसे कोई chef रेस्तराँ में आग जलाए लेकिन घर पर चाकू तक न छुए
Emacs उस chef का घर का kitchen है। maintenance में एक reactive maintenance होती है—जैसे टूट-फूट सुधारना और changes को track करना—और दूसरी generative maintenance, जिसमें आप अपनी evolving understanding के हिसाब से tools गढ़ते हैं। programmers को पहली से नफ़रत होनी चाहिए और दूसरी की ओर आकर्षित होना चाहिए
Emacs generative maintenance के लिए लगभग अद्वितीय रूप से उपयुक्त है, क्योंकि उसके tools और काम का स्वभाव एक जैसा है
Emacs के बारे में यह शिकायत कि "config पर बहुत काम करना पड़ता है" आम है, लेकिन इसका मतलब अक्सर बस यह होता है कि "value मिलने से पहले मैं निवेश नहीं करना चाहता"। लंबी अवधि में यह कोई समझदारी भरी strategy नहीं है। Emacs को career और पूरे जीवन में कुल maintenance burden घटाने वाले universal tool की तरह देखना ज़्यादा सही है
Emacs या VIM configs सिर्फ़ साधारण text files होती हैं, जिन्हें किसी भी सामान्य editor में खोलकर अपनी ज़रूरत के हिसाब से बदला जा सकता है, और आपको पता होता है कि क्या कहाँ है। मेरी VIM config 20 साल पुरानी है, और 1~2 साल पहले मैंने बस manual package management छोड़कर plugin manager इस्तेमाल करना शुरू किया
यहाँ gatekeepers भी नहीं हैं, dependencies भी नहीं हैं
इसके उलट आज का तरीका यह है कि या तो किसी third-party company को 20~200 dollars दें, या local run के लिए काफ़ी ताक़तवर GPU चाहिए, फिर text file में instructions डालें और जब तक मनमाफ़िक न हो तब तक उसे tweak करते रहें
आप खुद dependencies जोड़ रहे होते हैं, और अगर चीज़ें इतनी उलझ जाएँ कि इंसान के लिए review करना मुश्किल हो जाए, तो वह dependency एक बहुत भारी dependency बन जाएगी। चाहे वह महँगा GPU हो या आपका data ऐसी company को भेजना हो जिसे shareholders को खुश रखना है—बात एक ही है
हमें यह पहचानना होगा कि इन दोनों में फर्क क्या है, और हम वास्तव में कौन-सी कीमत चुका रहे हैं
personal software, यानी अपने लिए programs लिखने का विचार, 1960s के home computing की मूल vision था
PC की ठीक-ठीक भविष्यवाणी नहीं की गई थी, लेकिन यह कल्पना थी कि हर किसी के घर में computer terminal होगा और लोग अपनी ज़रूरत के काम के लिए programs लिखेंगे। सोचा गया था कि programming इतनी आसान हो जाएगी कि हर कोई इसे सीख सकेगा
हम अभी वहाँ तक नहीं पहुँचे हैं, लेकिन LLM की वजह से करीब पहुँच रहे हैं
यानी non-experts भी ऐसी authoring environments में दिलचस्प software बना सकें जिनमें अच्छी तरह designed components हों और समझने में आसान metaphors हों। accidental या overengineered complexity की परतें हटा दी गई हों
इस vision में भी software के लिए सावधान logical thinking चाहिए, लेकिन उस सोच को executable code में बदलने की झंझट बहुत कम हो जाती है। toolchains और build system के दुःस्वप्न भी नहीं होते
इसकी जगह हमने बहुत शक्तिशाली models बना लिए हैं जो हमारे लिए जटिल मंत्र दोहराते और recombine करते हैं। लेकिन complexity अब भी वहीं है, और non-experts के लिए अब भी opaque है
फिर भी LLM इस complexity का कुछ हिस्सा हटाने में मदद कर सकते हैं। वह दिशा अभी भी संभव है जहाँ LLM-generated software को व्यक्ति आसानी से समझ सके और खुद संशोधित कर सके, और यह LLM दुनिया के साथ अच्छी तरह पूरक भी हो सकती है
यह संभव है या नहीं का सवाल नहीं है; सवाल सिर्फ़ timing का है—ज़्यादा से ज़्यादा 10 साल, शायद उससे भी बहुत पहले। मेरे ऐसे रिश्तेदार जो coding नहीं जानते, वे अभी से ऐसे काम कर रहे हैं
computing का यह भविष्य सचमुच प्यारा है, और बेहद empowering दिशा है
मौजूदा Swift app 15,000 lines का है, जिनमें 5000 lines tests हैं और 10,000 implementation। अब वह लगभग पूरा है और जो चाहिए वह करता है। इसमें 20 घंटे लगे
मैंने पहले कभी Swift नहीं किया, इसलिए अगर खुद बनाता तो शायद मुझे व्यक्तिगत रूप से 500 घंटे लगते
शायद ऐसा इतना दूर नहीं जाएगा क्योंकि हममें से ज़्यादातर लोग आलसी हैं, लेकिन यह चिंता वाजिब है
application का विचार ही कहीं ज़्यादा fluid हो जाएगा
अगर app किसी dynamic language में बना है, तो फिर उपयोगकर्ता खुद code rewrite करे और पूरी तरह नई features जोड़े—इसे रोकने का कोई कारण नहीं है
यह article के main text से सीधे जुड़ा नहीं है, लेकिन terminal लगभग हमेशा monospace होता है इसलिए उस पर लंबा लेख पढ़ना थकाने वाला होता है—इस बात से मैं सहमत नहीं हूँ। व्यक्तिगत रूप से मुझे monospace font में लंबे लेख पढ़ना कहीं अधिक आरामदायक लगता है
लेखक ने एक दिलचस्प बिंदु पकड़ा है। काम करने वाले variables हैं: tool बनाने की कठिनाई, publish करने की कठिनाई, दूसरों के लिए उसकी उपयोगिता, publish करने पर मिलने वाला social reward, और dependency जोड़ने का negative incentive
किसी existing solution को ढूँढना कितना कठिन होगा, यह इस बात पर निर्भर करता है कि किसी को उसे बनाना कितना महँगा पड़ता है और किसी को उसे publish करना सीखना कितना महँगा पड़ता है। इसके उलट, अगर वह community के लिए उपयोगी है तो लोग उसे बताएँगे, इसलिए उसे ढूँढना आसान होता है
अगर बनाना और publish करना—इन दोनों की कठिनाई बहुत अलग है, ख़ासकर जब बनाना बहुत महँगा हो, तो लोग अक्सर चीज़ खुद बनाकर भूल जाते हैं। अगर publish करना सस्ता हो तो solutions और कम हो जाते हैं
अगर दोनों सस्ते हों, और दूसरों के लिए उपयोगिता व social reward dependency cost से अधिक हों, तो leftpad जैसी स्थिति पैदा होती है। NPM के बहुत-से packages में high utility और reward, तथा low dependency cost का यही संयोजन होता है
Emacs Lisp में पहले बनाना कठिन था, अब आसान है; और learning curve पार करने के बाद publish करना भी आसान है। utility, reward और dependency cost भी किसी दिशा में बहुत ऊँचे नहीं हैं
तब एक ऐसा scenario बनता है जहाँ tool मौजूद है या नहीं यह खोजने से पहले ही आप खुद बना लेते हैं। VSCode या पुराने Eclipse में publish करना कठिन था, इसलिए तस्वीर अलग थी
मुझसे कम उम्र का कोई व्यक्ति शायद इसे दुनिया के सामने paper topic के रूप में रखेगा
यह लेख LLM coding से आने वाले एक ऐसे बदलाव की ओर इशारा करता है जो अभी पूरी तरह हुआ नहीं है। अब क्या हम Electron/React Native छोड़कर, LLM से Figma, wireframes और behavior specs को हर platform की असली native app में बदलवा सकते हैं?
अगर CRUD app हो, तो API specs, UI mockups, यहाँ तक कि किसी पहले से implemented platform के screenshots भर से भी काफ़ी आगे जाया जा सकता है। ऐसी well-defined tasks वही प्रकार हैं जिनमें LLM अच्छा होता है। equivalence testing का बड़ा हिस्सा भी automate किया जा सकना चाहिए
क्या "शायद कभी Android भी जोड़ेंगे" या "Mac/Linux users काफ़ी नहीं हैं" जैसी बहानेबाज़ी अब भी बची रहेगी? क्या iOS app में password reset जैसे कम इस्तेमाल होने वाले flow को implement न करके कोई random WebView खोल देना अब भी justify किया जा सकेगा?
जिन apps में device पर non-trivial logic है, वहाँ भी LLM ने उन्हें Go या Rust जैसी cross-compilation-friendly languages में rewrite करने में काफ़ी संभावना दिखाई है
और उकसाने वाले अंदाज़ में कहूँ तो, इस बिंदु पर SwiftUI क्यों सीखें? ज़्यादातर कामों के लिए SwiftUI expertise की category कुछ वैसी है जैसे "Microsoft Word को बहुत गहराई से सीखना"
जो लोग उस पर समय लगाते हैं, मैं उनका सम्मान करता हूँ, लेकिन करें या न करें, final result में फ़र्क़ लगभग मिलीमीटर के स्तर का है
मैं programming के पूरे क्षेत्र के बारे में ऐसा नहीं कह रहा। बस अब कुछ languages में specialize करने की वजहें कहीं अधिक जटिल हो गई हैं