1 पॉइंट द्वारा GN⁺ 2025-12-13 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • व्यक्तिगत उपयोग के लिए बने कोड एडिटर Boo के लेखक ने परियोजना को कुछ समय के लिए रोककर नई प्रोग्रामिंग भाषा बनाने के कारण समझाए
  • Boo एक Rust-आधारित एडिटर है जिसमें मानव-केंद्रित कीबोर्ड नेविगेशन और LSP विकल्प प्रणाली है, और इसका मकसद वाणिज्यीकरण से ज़्यादा निजी उपयोग है
  • उन्होंने कहा कि दोहराव भरा विकास रचनात्मकता को गिरा देता है, इसलिए वे लोगों को प्रेरित करने वाला सॉफ्टवेयर बनाने के आनंद पर जोर देते हैं
  • उन्होंने LEGO ब्लॉक निर्माण और The Legend of Zelda: Breath of the Wild का उदाहरण देकर यादगार रचना की अहमियत पर बल दिया
  • सफलता का फ़ॉर्मूला अपनाने के बजाय वे अपनी रुचि और सीखने-केंद्रित डेवलपमेंट फिलॉसफ़ी को बनाए रखते हुए भविष्य में Boo को अपनी बनाई भाषा में फिर से लिखने की योजना बता रहे हैं

Boo परियोजना और विकास की प्रेरणा

  • Boo लेखक का अपना-कोड एडिटर प्रोजेक्ट है, जिसका लक्ष्य जनसामान्य में लोकप्रियता नहीं बल्कि निजी उपयोगिता है
    • इसमें मानव-कीबोर्ड नेविगेशन है और LSP (Language Server Protocol) की जगह एक तेज़ व कम OS लोड लेने वाला सिस्टम उपयोग होता है
    • यह वर्तमान में दैनिक काम के लिए पर्याप्त रूप से चलता है, लेकिन इसे ओपन सोर्स के रूप में रिलीज़ करने की कोई योजना नहीं है
  • Boo और Rio Terminal दोनों Rust में लिखे गए हैं और उनकी संरचना व रिलीज़ प्रक्रिया भी मिलती-जुलती है
    • यही समानता इन्हें बार-बार वही काम करने जैसा महसूस कराती है और निर्माण का मज़ा कम कर देती है

रचना और प्रेरणा का रिश्ता

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

यादगार सॉफ्टवेयर के उदाहरण

  • The Legend of Zelda: Breath of the Wild का उदाहरण देते हुए उन्होंने बताया कि इस गेम ने ऐसे लोगों को भी कंसोल खरीदने पर प्रेरित किया जो इसे नहीं खेलते थे
    • यह दिखाता है कि कोई रचना खेलने के बाद भी लंबे समय तक याद रह जाने वाला अनुभव दे सकती है
  • उन्होंने कहा कि इसी स्तर की बारीक़ी से बनाई चीज़ें लोगों पर भावनात्मक छाप छोड़ती हैं

Boo का विराम और नई भाषा का निर्माण

  • Boo कोई बिजनेस-ड्रिवन प्रोजेक्ट नहीं, बल्कि एक शौकिया परियोजना है, इसलिए इसमें न मुनाफ़ा लक्ष्य है न डेडलाइन का दबाव
    • VS Code जैसे बड़े प्रोजेक्ट बनाने की कोई मंशा नहीं है, और न ही इसे मजबूरी में आगे बढ़ाया जा रहा है
  • प्रेरणा लौटने पर फिर से शुरू करने के लिए लेखक ने Boo को अस्थायी रूप से रोक दिया है और अभी अपनी खुद की प्रोग्रामिंग भाषा विकसित कर रहे हैं
    • लंबी अवधि में Boo को इसी भाषा में दोबारा लिखने की योजना है

विकास दर्शन और रवैया

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

1 टिप्पणियां

 
GN⁺ 2025-12-13
Hacker News की राय
  • यह पढ़कर कि वह आज उठा, कॉफी पी, और परिवार सो गया इसलिए उसकी दोपहर खाली थी, मुझे सच में यह जिज्ञासा हुई कि आखिर उसके परिवार का time zone उससे अलग कैसे है। मैंने यह भी कल्पना की कि शायद उसका परिवार दोपहर में सोता है, या शाम को उठकर दिन शुरू करता है

    • मज़ाक में सोचा कि कहीं उसका दूसरा शौक anesthesia तो नहीं। हो सकता है घर में कोई बच्चा दोपहर की नींद लेता हो, लेकिन तब भी लगता है कि खाली समय मुश्किल से दो घंटे का होगा
    • परिवार के साथ समय न बिताने को एंजॉय करने जैसा जो रवैया है, वह थोड़ा अजीब लगा। यह कोई ऐसी बात नहीं लगती जिसे सेलिब्रेट किया जाए
    • “Breath of the Wild” जैसा उदाहरण देखकर लगा जैसे मैं किसी दूसरे आयाम की ब्लॉग पोस्ट पढ़ रहा हूँ
    • शायद वह Spain में हो। उनकी मशहूर siesta की वजह से
  • “यह editor मुझे खुश करने के लिए मौजूद है” — यह बात ताज़गी भरी लगी। आजकल हर side project पर open source या SaaS में बदलने का दबाव होता है, और कई बार वही रचनात्मकता को मार देता है। Boo या Rio जैसे प्रयोगात्मक projects शायद इसी आज़ादी से निकलते हैं

    • open source अच्छा है, लेकिन patch requests स्वीकार किए बिना सिर्फ code public कर देना भी ठीक है, ऐसा मुझे लगता है
    • आजकल open source या SaaS से भी आगे बढ़कर, हर चीज़ को enterprise-grade scale तक ले जाने का माहौल ज़्यादा गंभीर समस्या लगता है। छोटी languages, experiments, self-hosting, और DIY spirit अब जैसे counterculture बन गए हैं
    • “मुझे खुश करने के लिए मौजूद है” — इस बात से सहमत हूँ। (Emacs)
  • “मैंने इसे अपने लिए बनाया” — यह कई कलाकारों का तरीका रहा है। Tolkien ने भी ऐसा ही किया, और ज़्यादातर लोग पहले अपने लिए बनाते हैं, बाद में दुनिया को दिखाते हैं। लेकिन आम तौर पर किसी को फ़र्क नहीं पड़ता, या फिर मौत के बाद ध्यान मिलता है। फिर भी कोई बात नहीं। अहम बात है कल्पना को बाहर व्यक्त करने की मानवीय प्रवृत्ति

    • मैंने भी अपनी canvas library इसी भावना से बनाई थी। मैं कविता को वेबसाइट पर नए तरीके से व्यक्त करना चाहता था, और देखते-देखते वह 10 साल से ज़्यादा समय से मेरे leisure time का हिस्सा बनी हुई है। नतीजा इस कविता पेज में है
    • कभी गुस्से में लिखी एक email, एक दोस्त के सुझाव पर, स्थानीय अख़बार में op-ed के रूप में छपी थी। यह जानकर अच्छा लगा कि किसी ने मेरी लिखी बात की परवाह की
    • अगर आप सच में अपने लिए बना रहे हैं, तो दूसरों की नज़र की परवाह नहीं करनी चाहिए। मैं भी पहले सोचता था, “दूसरे लोग क्या सोचेंगे”, लेकिन जब मैंने सच में अपने लिए बनाना शुरू किया तो अहसास पूरी तरह बदल गया
    • पहले कलाकार को अपनी vision पर चलने के लिए patron की ज़रूरत होती थी। अब patronage लोकतांत्रिक हो गई है, लेकिन उसकी जगह clicks ने रोज़ी-रोटी तय करनी शुरू कर दी है। अमीर patrons की जगह crypto या AI में पैसा बहना थोड़ा अफ़सोसजनक लगता है
    • “ऐसा कलाकार जिसे मौत के बाद पहचान मिली” सुनते ही एक कान वाले Dutch painter की याद आती है
  • जब programming दोहराव वाली हो जाती है, तो ‘wow’ factor कम हो जाता है। लेकिन yt-dlp जैसा project, जो अलग-अलग sites को support करता है, अपवाद है। ढेर सारे data parsers बनाना उबाऊ हो सकता है, लेकिन आख़िर में वह “हर जगह काम करता है” वाला एहसास देता है

  • मैं ऐसा software बनाता हूँ जो लोगों में emotions जगाता है — ज़्यादातर गुस्सा। आख़िर में software दो ही तरह का होता है: जिसे लोग नज़रअंदाज़ कर दें, या जिसे लोग इतना इस्तेमाल करें कि शिकायत करने लगें

    • उदाहरण के लिए Microsoft Teams या Office 365 साफ़ तौर पर भावनाएँ जगाते हैं, लेकिन खुशी नहीं
    • DRM software भी वैसा ही है। ख़ासकर Sony BMG rootkit scandal जैसा मामला तो दंतकथा जैसा है
    • मैंने भी पाया है कि रोज़ाना टकराने वाली समस्याओं को हल करने के लिए बनाए गए tools ने ही सबसे अच्छी quality दी। अगर बहुत जल्दी generalize करने लगो, तो चीज़ें उल्टा धीमी हो जाती हैं और quality गिर जाती है
  • Emacs और Emacspeak मुझे बेहद गहरी भावनाएँ देते हैं। पूरा सिस्टम जैसे एक ही manual हो, और सिर्फ C-h m दबाते ही सारे commands सामने आ जाएँ। कुछ भी छिपा हुआ नहीं, HTML docs में खोदने की ज़रूरत नहीं। अगर कुछ नहीं चलता, तो Codex से ठीक करवाकर भी मैं उसे अपनी इच्छा के मुताबिक चला लेता हूँ

  • आदर्श स्थिति में, software development को craft की तरह देखा जाना चाहिए। जैसे woodworking उपयोगी भी हो सकती है और कला भी। लेकिन बहुत से projects में developers के साथ factory workers जैसा व्यवहार होता है। समस्या है quality से ज़्यादा quantity को महत्व देने वाली संस्कृति।
    साथ ही software को सिर्फ कला मानना भी व्यावहारिक नहीं है। Code का मकसद सराहना पाना नहीं, चलना है। फिर भी यह थोड़ा अफ़सोस की बात है कि “craftsmanship से बना software” वाक्य अटपटा लगता है

    • woodworking में भी आख़िरकार बैठने के लिए कुर्सी ही बनाई जाती है, देखने के लिए नहीं। फिर software को craftsmanship के नज़रिये से क्यों नहीं देखा जाता, यह समझ नहीं आता
  • Meta, Google जैसी FAANG कंपनियाँ भी पहले ही लोगों में भावनाएँ जगाने वाला software बना चुकी हैं — गुस्सा, उदासी, कभी-कभी खुशी भी। लेकिन यह भी दिखाता है कि अच्छी नीयत से शुरू हुई technology कैसे विकृत हो सकती है। जैसे कहा जाता है, “नरक का रास्ता अच्छी नीयत से पाटा जाता है”; अच्छाई की तलाश में भी बुराई पैदा हो सकती है।
    Knuth को उद्धृत करें तो, “हज़ारों computer scientists को आज़ादी से वह करने दो जो वे करना चाहते हैं” — यही प्रगति की ताकत है। Bell Labs की तरह, खोज की आज़ादी बहुत महत्वपूर्ण है।
    आजकल हम optimization के पीछे पड़े रहते हैं, लेकिन गणितीय रूप से उतने सक्षम नहीं, और नतीजतन खोज बंद कर चुके समाज बन गए हैं। मुझे लगता है इसी वजह से प्रगति धीमी पड़ गई है

    • मेरी एक कहावत है: “अगर तुम्हें बिल्लियों को हाँकना है, तो खुद बिल्ली बनना होगा।” जीनियस लोगों को लीड करना है, तो उनके जैसा बनना पड़ेगा। कई बार अकेले ही कई भूमिकाएँ निभानी पड़ती हैं
  • Casey Muratori और Jonathan Blow से सीखी एक आदत है: मुझे भी अपनी छोटी-सी दुनिया बनाना पसंद है। ऐसे projects जहाँ मैं ही अकेला user हूँ और मैं ही target audience हूँ। वहाँ कोई deadline नहीं, कोई requests नहीं, कोई runtime नहीं — बस शुद्ध आनंद की जगह

    • किसी ने पूछा कि “अपनी दुनिया बनाई” से क्या किसी काल्पनिक भौगोलिक दुनिया की बात हो रही है। Tolkien और Stevenson ने भी शायद ऐसे ही शुरू किया था
    • लेकिन Blow और Casey लंबे समय तक कोई नतीजा नहीं दे पाते
  • आजकल ज़्यादातर software मुझमें तेज़ भावनाएँ जगाता है

    • ख़ासकर node_modules को देखकर गुस्सा आता है। Electron आधारित apps को देखकर लगता है, “हमसे कहाँ ग़लती हो गई?” desktop पर mobile UI चढ़ा देना भी मुझे पसंद नहीं