और ज़्यादा "बेकार" सॉफ़्टवेयर लिखें

 (ntietz.com)
3 पॉइंट द्वारा GN⁺ 2023-10-19 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • बेकार सॉफ़्टवेयर व्यावहारिक नतीजे देने के दबाव से बाहर निकलकर computing की खुशी फिर से पाने का एक खेल है, और Hurl भी एक “मज़ाक” से शुरू हुआ प्रयोग था
  • तकनीकी काम करने वाले लोग अक्सर ऐसे माहौल में लंबे समय तक रहते हैं जहाँ उपयोगी नतीजे बनाना ज़रूरी होता है, इसलिए programming शुरू कराने वाली मज़े की चिंगारी कमजोर पड़ सकती है
  • खेल-खेल में किए गए projects में आप खुद तय कर सकते हैं कि tests चाहिए या नहीं, issue tracker चाहिए या नहीं, completion criteria क्या होगा, और जब पर्याप्त सीख लिया हो या मज़ा खत्म हो जाए तो कभी भी रुक सकते हैं
  • chess engine, Redis API के कुछ हिस्से लागू करने वाला key-value store, Wake-on-LAN utility, chess visualization, और chess database, GUI·system·network·DB internals सीखने के लिए किए गए प्रयोग थे
  • कंप्यूटर को थोड़ा कम गंभीरता से लेना और “बेकार दिखने वाली” चीज़ें बनाना, सीखने और मज़े दोनों पाने का एक व्यावहारिक तरीका है

“बेकारपन” से मिलने वाली आज़ादी

  • Hurl के बारे में पूछा गया, “इसे क्यों बनाया?” और छोटा जवाब था: मज़ाक के लिए
  • लंबा जवाब यह है कि बेकार सॉफ़्टवेयर computing की खुशी और खोजबीन का अनुभव कराता है
  • तकनीकी काम करने वाले लोग आम तौर पर उपयोगी चीज़ें बनाने के काम से बंधे रहते हैं
    • software engineers ऐसा code लिखते हैं जो असली समस्याएँ हल करता है
    • computer scientists नई और व्यावहारिक उपलब्धियाँ लाने के लिए समस्याओं का अध्ययन करते हैं
    • technical writers वास्तविक तकनीक और documentation पर काम करते हैं
  • programming शुरू करने वाले बहुत से लोगों ने किसी न किसी रूप में उस काम में मज़ा महसूस किया था, और career चुनने में भी उस एहसास की कुछ भूमिका रही होगी
  • अगर पूरे दिन उपयोगी काम ही करना पड़े, तो दिलचस्पी कमजोर पड़ना आसान है
    • जो काम करना ही है, उसके साथ ज़िम्मेदारियाँ और दबाव जुड़ जाते हैं
    • हर गतिविधि काम से ही जुड़ जाती है
    • इस प्रक्रिया में खेल का तत्व खोना आसान होता है
  • बेकार सॉफ़्टवेयर इन ज़िम्मेदारियों से बाहर निकलने का एक तरीका है
    • project से क्या पाना है, यह आप खुद तय कर सकते हैं
    • आप कभी भी रुक सकते हैं
    • अगर tests लिखने का मन नहीं है, तो उन्हें छोड़ सकते हैं
    • अगर issue tracker नहीं चाहिए, तो उसे हटा सकते हैं
    • जो सीखना था वह सीख लिया हो और मज़ा खत्म हो गया हो, तो project समाप्त कर सकते हैं

खेल-खेल में बनाए गए projects

  • भयानक chess engine और UI में बहुत bugs थे, लेकिन इससे GUI programming, game programming, और chess engine कैसे काम करता है, यह गहराई से समझने का मौका मिला
  • key-value store ने Redis API के कुछ हिस्से लागू करते हुए system programming और ज़्यादा efficient code लिखना सीखने में मदद की
  • Wake-on-LAN utility WOL कैसे काम करता है और Rust network programming सीखने के लिए बनाया गया project था
  • chess game visualization ने code से कला बनाने और पसंदीदा game को visualize करने के तरीकों पर प्रयोग करने का मौका दिया
  • chess database में bitmap और database internals के बारे में बहुत कुछ सीखा
  • commands क्या करते हैं, यह “mansplain” करने वाला LLM-आधारित tool भी बनाया गया
  • POP3 server-side protocol implementation अधूरी है, लेकिन protocol सीखने और यह सोचने में मज़ा आया कि POP3-आधारित app कैसा दिख सकता है
  • “Crafting Interpreters” को Rust में follow करते हुए interpreter और compiler के बारे में बहुत कुछ सीखा, और लक्ष्य पूरा करना नहीं बल्कि उसका आनंद लेना था
  • “Mazes for Programmers” को Rust में लगभग आधा किया, लेकिन वह काम जैसा लगने लगा, इसलिए रोक दिया गया, और आगे बढ़ाने की इच्छा नहीं रही
  • छोटे scripts भी ideas और concepts के साथ खेलने और प्रयोग करने के लिए लिखे गए
  • Hurl भी इसी तरह के खेल का एक रूप है, और भले ही वह उपयोगी न हो, कुछ सीखने और कुछ बनाने की प्रक्रिया में मज़ा मिल सकता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-10-19
Hacker News टिप्पणियाँ

  • मुझे बेकार सॉफ्टवेयर बनाना पसंद है। सिर्फ इस साल बनाए गए कामों में https://lines.potato.horse का uncolouring book, https://meat-gpt.sonnet.io का MeatGPT, https://tidings.potato.horse का Medieval Content Farm, https://butter.sonnet.io का You deserve butter, https://mrr.sonnet.io का Mrr, और https://mrrr.sonnet.io का भौतिक रूप से सटीक Mrr शामिल हैं
    उनमें से कुछ असल में बारीकी से बनाए गए ब्लॉग पोस्ट जैसे हैं, और असली समस्या हल करने की तुलना में कोड के साथ खेलते हुए खुद को व्यक्त करना मेरे लिए आसान था, इसलिए वे कुछ ज़्यादा ही बना दिए गए। लंबी सूची https://sonnet.io./projects पर है

    • मेरी पसंदीदा बेकार चीज़ https://sc.rollc.at है। लगता है आखिरकार infinite scroll को जायज़ ठहराने वाला उपयोग मिल गया
    • https://meat-gpt.sonnet.io लंबे समय बाद इंटरनेट पर देखी सबसे मज़ेदार चीज़ों में से एक था। बिल्कुल सोने की खान
    • इन प्रोजेक्ट्स और लेख के दूसरे links से प्रेरित होकर मैंने Scratch account बनाया और एक analog clock बनाने की कोशिश की: https://scratch.mit.edu/projects/910890145
      मेरा 8 साल का बच्चा रोज़ Scratch करता है और जब उसके सवाल होते हैं तो मैं अक्सर मदद करता हूँ, लेकिन सिर्फ मज़े के लिए बेकार animations तक डालकर एक अजीब-सा प्रोजेक्ट बनाना काफी मज़ेदार था। इसकी वजह से अब घर में “Hurry to love! Hurry to love!” catchphrase बन गया है
    • लेख से प्रेरित होकर मैंने अपनी खुद की सूची बनाई: https://untested.sonnet.io/Here's+a+List+of+Toys
      सच कहूँ तो उनमें से काफी कुछ मैं भूल चुका था
    • वैसे, triple-r mrrr link लगता है काम नहीं कर रहा

  • पूरी तरह सहमत। हाल ही में मैं clown school गया था, और मुझे एहसास हुआ कि मैं projects को “सही तरीके से” या “अच्छी तरह” करने पर बहुत ज़्यादा अटका हुआ था
    जीवन जीने के लिए है, और software को बहुत “सही” तरीके से करने की कोशिश मज़ा निचोड़ देती है। इसलिए आजकल मैं code लिखने को ज़्यादा मज़ेदार बनाने की कोशिश कर रहा हूँ, और इससे मैं बहुत ज़्यादा code लिखने लगा हूँ और वह ज़्यादा आसानी से बहता है। हाल ही में schema evolution के ideas आज़माने के लिए मैंने protobuf-style binary serialization library खुद बनाई, और अब मैं CRDT-based local-first database बना रहा हूँ। कल पहली data sync हो गई और मैं सच में बहुत उत्साहित था। कई सालों में मैंने Serious Problems हल करने के लिए भी बहुत code लिखा है और impulse में बनाया code भी बहुत लिखा है, लेकिन विडंबना यह है कि जिस code पर मुझे सबसे ज़्यादा गर्व है, वह मज़े के लिए बनाया गया code है। मज़ेदार projects पर मैं बार-बार लौटकर उन्हें maintain और improve करता रहता हूँ, जबकि serious projects अक्सर मेरे हटते ही मुरझाकर खत्म हो जाते थे

    • लगता है games का min/maxing concept जीवन के दूसरे क्षेत्रों पर भी लागू होता है
      games में flow में आने और process पर भरोसा करने के बजाय लोग सबसे ताकतवर character बनाने की guides पढ़ने लगते हैं, stats को maximize करते हैं और 100% completion को target बनाते हैं। अंत में exploration और accidental encounters का वह मज़ा गायब हो जाता है जो game को अच्छा बनाता था, और समय random dice roll की तरह stats maximize करने में चला जाता है। दूसरी activities भी ऐसी ही हैं: चाहे wealth हो या code quality, किसी चीज़ को maximize करते-करते wonder और “बस करके देखते हैं” वाला भाव गायब हो जाता है
    • पहले मुझे physics में मज़ा आता था। मज़ा इसलिए आता था क्योंकि मैं physics के साथ खेलता था। यह nuclear physics की प्रगति के लिए कितना महत्वपूर्ण है, इससे ज़्यादा मैं वही करता था जो मेरे खेलने के लिए दिलचस्प और मज़ेदार लगता था
      https://www.asc.ohio-state.edu/kilcup.1/262/feynman.html
    • Princeton में admission के लिए बधाई
    • Factorio खेलते समय मुझे भी यही महसूस हुआ। शुरुआत में मैं एक दोस्त के साथ spaghetti factory बना रहा था और requirements बदलने पर बार-बार refactor कर रहा था; वह सच में बहुत मज़ेदार था
      फिर जैसे ही optimization में फँसा, अचानक game ऐसा हो गया जिसमें बस एक ही सही जवाब था, और एक ही रात में सारा मज़ा निकल गया। अहंकार और मनमर्जी में खराब तरीके से बनाते हुए अक्सर ज़्यादा सीख मिलती है। “कितना मुश्किल हो सकता है?” वाली सोच ने मुझे कई बार ऐसी गहराइयों में पहुँचा दिया जिन्हें संभालना मुश्किल था, लेकिन बाहर निकलने की प्रक्रिया में हमेशा बहुत कुछ सीखा और मज़ा भी मिला
    • “clown school” phrase को लेकर सबका यह मान लेना कि यह या तो सचमुच clown school है या Ivy League universities में से एक, बहुत कुछ बताता है

  • किसी भी craft में कुछ बातें intuition के उलट होती हैं। बस ज़्यादा करते रहो, आम तौर पर अंततः skill बेहतर हो जाती है। खराब short stories लिखो, बदसूरत pottery बनाओ, टेढ़े-मेढ़े landscapes paint करो
    practice का असर तो होगा ही, लेकिन हमारी यह tendency भी बड़ी है कि अगर अपेक्षित finished product दिमाग में पूरी तरह साफ़ नहीं दिखता, तो हम idea खुद ही छोड़ देते हैं। खासकर analytical लोगों को यह wasted time कम करने वाला smart decision लगता है, लेकिन साथ ही यह कुछ भी न बनाने का पक्का तरीका भी है। “बेकार” software projects में से कई अंत तक बेकार ही रहे, लेकिन कुछ में बनाने की प्रक्रिया के दौरान बड़ी utility मिल गई। आखिर में बात “जो shot लेते ही नहीं, वे 100% miss होते हैं” जैसे cliché तक पहुँचती है, लेकिन मतलब समझ रहे होंगे

    • “मैं हमेशा वह कर रहा हूँ जो मुझे अभी करना नहीं आता। ताकि मैं उसे करना सीख सकूँ।” — Van Gogh
    • शुरुआती teenage years में skateboarding करते समय, मैं सोचता था कि “लगातार कोशिश करना” किसी दिन मुझे ollie सीखने में मदद करेगा या मुझे बस ollie में fail होने में बहुत माहिर बना देगा

  • यह सिर्फ “बेकार” software लिखने की बात नहीं है, बल्कि छोटे projects में तथाकथित best practices से बचने की दलील भी बन जाती है
    मैंने item catalog के लिए एक static site generator बनाया था; catalog सरल है और अक्सर बदलता नहीं है। कौन-सा database इस्तेमाल करूं, इस पर सोचते-सोचते आखिर मैंने सब कुछ codebase के अंदर एक static array में डालने का फैसला किया। सोचने लायक एक dependency कम हो गई, और मेरे उद्देश्य के लिए यह बिल्कुल ठीक बैठता है

    • मुझे यह काफ़ी जल्दी समझ आ गया था। 1998 के आसपास एक project था जिसमें content repository के लिए Oracle का इस्तेमाल “क्योंकि वह उपलब्ध था” किया जा रहा था, और performance review करते हुए हम इस निष्कर्ष पर पहुंचे कि “हम data बदलने से ज़्यादा बार नया software deploy करते हैं, इसलिए उसे सीधे product में compile कर देना चाहिए था”
      असल में ऐसा बदलाव हुआ या नहीं, मुझे नहीं पता, लेकिन उसके बाद जब भी कोई कहता है “database चाहिए”, तो यही पहला सवाल बन गया जो मैं हमेशा पूछता हूं
    • “best practices” से ज़्यादा उपयुक्त practices हमेशा जीतती हैं
    • “database न इस्तेमाल करना” मुझे best practice नहीं लगता। best practice तो बल्कि काम के लिए सबसे अच्छा tool इस्तेमाल करने के करीब है। आपने जो तरीका बताया है, वह इसी उदाहरण में अच्छी तरह फिट बैठता है
    • hobby project में मैंने भी वही फैसला लिया। मौजूदा version असल में dataset को सिर्फ query करता है, create/delete/modify नहीं करता
      वैसे भी graph algorithms चलाने के लिए मुझे सारा data memory में लाना पड़ता है, तो read-only data को database में store करने का लगभग कोई मतलब नहीं है, यह समझ आया। SQL में Bellman-Ford implement करने का मेरा बिल्कुल इरादा नहीं है
    • मेरा एक दोस्त जो कुछ भी सीखता है, उसे अपने open source project में शामिल कर देता है। शुरुआत में वे best practices दिखाने का showcase थे, और अब वे projects काफी लोकप्रिय हो गए हैं

  • एक दोस्त के साथ coding करते हुए मैंने यह सीखा, जिसे मैं बहुत खराब coder समझता था
    हमारी अच्छी बनती थी, इसलिए हमने साथ में कई मजेदार projects किए, लेकिन वह सच में ऐसा लगता था जैसे उसे पता ही नहीं कि वह क्या कर रहा है। जगह-जगह copy/paste, architecture नहीं, design नहीं, खराब naming, और आधे समय तो उसे खुद भी यकीन नहीं होता था कि code असल में कर क्या रहा है। लेकिन वह चलता था। आखिर मुझे एहसास हुआ कि उसने मुझसे ज़्यादा चीज़ें बना ली थीं। वह छोटी-छोटी बातों में नहीं अटकता था, और कहीं ज़्यादा काम करता था। unit tests नहीं लिखता था, लेकिन output के साथ बच्चे की तरह खेलते हुए लगातार manual testing करता था। अंत में मैंने उस सोच को अपना लिया। मुझे जिस तरह का contact software चाहिए था वैसा नहीं मिला, तो खुद बनाने की सोची, लेकिन polished UI बनाने की कोशिश नहीं की और django-admin इस्तेमाल करके काम खत्म कर दिया। मैं 10 साल से उन भयानक forms के ढेर का इस्तेमाल कर रहा हूं और वे काम कर देते हैं। जब TOTP के लिए CLI नहीं था, तो मैंने Python में बना लिया और seeds को plain-text TOML में dump कर दिया। encryption जोड़ने में 5 साल लग गए, क्योंकि Veracrypt container से file को symbolic link करना काफी था और काम कम था। दो महीने पहले मुझे एक timer चाहिए था जिसमें exercise करने पर time budget भरता और video game खेलने पर खर्च होता, तो मैंने बना लिया (https://substackcdn.com/image/fetch/w_1456,c_limit,f_webp,q_...). ChatGPT ने जो Tailwind का ढेर उगला था, उसे HTMX से नियंत्रित करके जोड़ दिया, और वह काफी था। दोस्तों को दिखाया तो 4 लोगों ने account मांगे, और एक ने addiction program के लिए doctor-use trial मांगा। signup form भी नहीं था, इसलिए hardcode कर दिया। मैं अपने युवा version से कहना चाहूंगा कि काम को “सही” तरीके से करने या सिर्फ महत्वपूर्ण समस्याओं पर काम करने की जिद छोड़ दो। वैसे भी जिंदगी में कभी “सहीपन” तक पहुंचा ही नहीं

    • कुछ साल पहले मुझे समझ आया कि project name जैसी चीज़ों को शुरू से सही करने की कोशिश आम तौर पर असफल होती है
      जब तक project दिलचस्प साबित न हो जाए, IDE द्वारा दिया गया नाम ही रहने देना शुरू किया, तो लगता है सफलता दर बढ़ गई। यह उसी मूल सिद्धांत से जुड़ा लगता है
    • software को पहले हथौड़े से ठोक-पीटकर जैसा-तैसा जोड़कर बना लो, और जब पता चल जाए कि क्या चाहिए और क्या जरूरी है, तब बाद में साफ-सफाई कर लो
      खासकर दूसरों के code को साफ करते समय इसमें एक अजीब logic होता है। आप गाली देते हुए कहते हैं “आखिर सोच क्या रहे थे?”, लेकिन साथ ही यह भी सच है कि उस व्यक्ति ने चीज़ को कम-से-कम शुरू तो कर दिया था
    • पहले एक व्यक्ति था जिसने मुझे प्रेरित किया था; उसका स्वभाव बिल्कुल खराब था और बाद में जो code देखा वह भयानक था
      लेकिन वह कम वेतन वाले देश में 100 dollar प्रति घंटे कमाता था। वह domains और content खरीदता, software को फिर से बनाता, search engine optimization जैसी चीज़ें करता, और 3 महीनों में खरीदी कीमत के 10 गुना पर बेच देता। 3 महीने के काम से करीब 7000 dollar profit बुरा नहीं है, और संभव है कि वह full-time भी नहीं कर रहा था
    • मेरा अनुभव मिलता-जुलता था, लेकिन निष्कर्ष बिल्कुल अलग निकला। मैंने ऐसे लोगों के साथ काम किया है जो चीज़ें यूं ही फेंक-फांककर जोड़ देते हैं, और अक्सर देखा है कि वे सच में दीवार से चिपक भी जाती हैं
      लेकिन मेरा निष्कर्ष यह था। पहला, जितनी बार सफलता मिलती है उतनी ही बार असफलता भी मिलती है, यह पहले से predict करना असंभव होता है कि कौन-सा होगा, और बाद में सुधारना शुरुआत में वैसा न करने से कठिन होता है, इसलिए यह negative expected value वाले जुए जैसा लगता है। दूसरा, व्यक्तिगत रूप से मुझे उस तरह काम करना पसंद नहीं है। तीसरा, इसलिए मैं अपना समय ऐसे कामों में नहीं लगाना चाहता जहां वह तरीका plausibly फिट बैठ सकता हो। इसी अनुभव ने मुझे छोटी-छोटी मामूली चीज़ों की श्रृंखला के बजाय गहरे और बड़े projects तलाशने की ओर धकेला। बदले में अब मैं यह कहीं अधिक सहजता से स्वीकार करता हूं कि दूसरे लोगों की preferences मुझसे अलग हो सकती हैं। software बनाने के सही तरीके से ज़्यादा, मैं इस बारे में सोचने लगा हूं कि मेरे लिए कौन-सा तरीका सही है
    • मैं अभी बिल्कुल यही कर रहा हूं। जिस technology को ठीक से नहीं जानता, उससे एक मजेदार “बेकार” app बना रहा हूं, और सबसे बेवकूफाना, maintain न हो सकने वाला कचरा code लिख रहा हूं
      फिर भी वह चलता है। मेहनत लगती है, लेकिन productive है, और इस प्रक्रिया में मैं बहुत कुछ सीख रहा हूं। बाद में साफ करना, polish करना, maintainable और scalable बनाना मुझे आता है, इसलिए वह तब करूंगा जब सच में चलने वाली कोई चीज़ बन जाएगी। खासकर कुछ नया आज़माते समय यह approach पहले भी काफी productive रही है, इसलिए मैं इसका पूरा समर्थन करता हूं

  • Apple ने कभी मेरे ऐप को बेकार बताकर reject कर दिया था। ऐप review टीम ने खुद फोन करके कहा था कि यह ऐप बेकार है और Mac App Store में approve नहीं होगा
    करीब 12 साल बाद, उस छोटे-से बेकार ऐप KeyboardCleanTool को हजारों लोगों ने इस्तेमाल किया। यह एक बहुत छोटा free ऐप है जो keyboard और Touch Bar, दोनों के input को block कर देता है, और लोगों ने इसे ऐसे-ऐसे तरीकों से इस्तेमाल किया जिनकी कल्पना भी नहीं की थी। जैसे किसी toddler को keyboard पर मन भर के थपथपाने देना, या बिल्ली को laptop पर सोने देना। क्या उपयोगी है, यह सच में बहुत subjective है

    • मुझे MacBook का keyboard साफ करना ही था, इसलिए मैं MacBook keyboard साफ करने का तरीका खोज रहा था और वह ऐप बार-बार सामने आ रहा था। पहले तो मैंने हंसकर टाल दिया: “कोई ऐप keyboard कैसे साफ करेगा, क्या यह नकली तरीके से उसे हिलाकर साफ कर देगा?”
      करीब दस और searches के बाद, keyboard साफ करने के अच्छे तरीकों पर एक लेख में देखा कि keyboard lock कर सकने की वजह से उस ऐप की सिफारिश की गई थी, तब जाकर बात समझ आई। आखिरकार मैंने इसे download किया, और “बेकार” ऐप के हिसाब से यह काफी useful निकला
    • मैं उस ऐप को जानता हूं। यह काफी शानदार लगता है
      बचपन में मेरी मां ने सफाई करते समय गलती से हमारा Mac IIsi चालू कर दिया था, और मैंने उसी बहाने उन्हें मना लिया था कि हमें After Dark screen saver चाहिए। जल्द ही screen पर उड़ते हुए toaster दिखने लगे। nostalgia महसूस होता है
    • मैं कई सालों से KeyboardCleanTool इस्तेमाल कर रहा हूं, और इसी से प्रेरित होकर Lunar ऐप में Cleaning Mode नाम का वैसा ही feature जोड़ा: https://lunar.fyi/shortcuts#cleaning-mode
      सफाई करते समय scratches डाल सकने वाली धूल दिखे, इसके लिए MacBook screen और monitor पूरी तरह काले होने चाहिए थे, और trackpad भी disabled होना चाहिए था। Cleaning mode बंद करने वाला key combination ऐसा चाहिए था जिसे गलती से दबाना मुश्किल हो और याद रखना आसान हो, इसलिए Command key को कम-से-कम 8 बार लगातार दबाने का तरीका चुना। Apple की app review practices हमेशा परेशान करती हैं। समझ नहीं आता कि वे users की तरफ से यह तय करने की कोशिश क्यों करते हैं कि क्या useful है। यह अलग बात है कि review pass कर चुके scam apps App Store में महीनों तक बने रहते हैं
    • जब भी कोई Apple के walled garden का बचाव करे, मैं यह comment save करके रखना चाहूंगा

  • expressive और मजेदार software इस्तेमाल करना मुझे पसंद है। यह सीखने और explore करने के लिए है, इसी ने मुझे programming की ओर खींचा और अब भी जोड़े रखा है
    अफसोस, जरूरत बीच में आ जाती है। भूख के खतरे के नीचे productive होना पड़ता है। जिन लोगों के साथ मिलकर उत्पादन करता हूं, उनकी परवाह है, और produce न कर पाने पर guilt महसूस होता है। यही चीज personal time की motivation तक खींच लेती है। यह हैरान करने वाला है कि इतने लोगों के पास खुद को express करने की stability और freedom है। जो लोग Recurse Center जा सकते हैं, जिनके पास कई personal projects और adventures से भरे अनगिनत blog posts हैं, उनसे ईर्ष्या भी होती है और खुशी भी। शायद उनमें से ज्यादातर ने ऐसी जिंदगी बना पाने की स्थिति में आने के लिए बहुत मेहनत की होगी। मैं भी ऐसा करना चाहता हूं। लेकिन ऐसा करने के लिए लगता है कि जिंदगी का और बड़ा हिस्सा productivity में झोंकना पड़ेगा। अगर काफी साल sacrifice में जला दिए, तो शायद किस्मत जिंदगी का आनंद लेने का अधिकार दे दे। अजीब बात है। फिर शायद बेकार software का और ज्यादा आनंद आएगा

    • जिंदगी की कई चीजों की तरह, अगर इसे “जब afford कर पाऊंगा तब” तक टालते रहे, तो शायद यह कभी मिलेगा ही नहीं

  • पहले मुझे लगता था कि useful software बनाना एक सक्षम software developer की निशानी है, और जिस काम की स्पष्ट utility आसान तरीके से समझाई न जा सके, उस पर समय नहीं लगाता था
    यह software को chore बना देने का बहुत अच्छा तरीका है। अब मैं बेकार चीजें बनाने में सहज हूं, और यह मजेदार है। पहले से मौजूद ideas को भी नए तरीके से फिर बनाता हूं, और यह परवाह नहीं करता कि किसी ने पहले किया है या नहीं। अगर सिर्फ मजे के लिए है, तो किसी और के गाने का cover करने की तरह वही काम अपने तरीके से किया जा सकता है। सीखना, आनंद लेना—इनकी अपनी value है। कभी-कभी सुधार का तरीका भी मिल जाता है। यह मैंने firmware लिखना शुरू करते समय सीखा। हमेशा useful होना चाहिए—यह दबाव बहुत ज्यादा था, और ego को कम करके किनारे रखना पड़ा। मुझे पता चला कि बेवकूफी भरे काम करने वाला sloppy code लिखना जबरदस्त मजेदार है, और low pressure में खुशी से सीखने और ideas को experience करने का शानदार तरीका बन गया। ऊपर से, बेकार चीजें आश्चर्यजनक रूप से useful भी हो जाती हैं। पिछले कुछ वर्षों में बनाई मेरी सभी बेकार चीजें आखिरकार unexpected useful code, insights या knowledge तक पहुंचीं

  • बहुत पहले मैंने Houston Recreational Computer Programming Group नाम की एक meetup चलाया था। यह लगभग पूरी तरह बेकार और मजेदार software projects दिखाने वाली meetup थी, और बहुत मजा आता था
    अब मैं दूसरे शहर में आ गया हूं, और नहीं जानता कि जहां अब रहता हूं वह शहर ऐसी meetup बनाने लायक बड़ा है या नहीं, और मुझमें फिर से उसे चलाने की energy है या नहीं। निजी तौर पर अच्छी बात यह थी कि महीने में एक बार, अगर कोई कुछ लेकर न आए, तो दिखाने के लिए मुझे एक छोटा project बनाना पड़ता था। करीब 2 साल में ऐसा सिर्फ कुछ ही बार हुआ, लेकिन उनमें से एक[1] काफी अच्छा निकला और मुझे उस पर गर्व है। वह पूरी तरह बेकार भी नहीं है। [1] https://github.com/smcameron/gaseous-giganticus

    • TX/RX labs की culture बनाने में योगदान देने के कारण वह जगह बाद में सचमुच अच्छी तरह बढ़ी

  • मैंने अभी कुछ ही मिनट पहले एक बेकार software पूरा किया, इसलिए यह post बहुत सही समय पर आई है
    CFR Brackets: https://susam.net/cfr.html
    Demo: https://susam.net/cfr.html#3
    Source: https://github.com/susam/cfr
    यह एक बहुत छोटी drawing language है, जो सिर्फ 5 commands support करती है: C (रंग बदलना), F (आगे बढ़ना), R (घुमाना), [ (block शुरू), ] (block repeat)। Commands थोड़ी-सी Logo programming language से प्रेरित हैं, और minimalism P′′ से प्रेरित है। हालांकि उन दोनों के विपरीत, यह Turing-complete नहीं है। इसका कोई practical use इरादतन नहीं रखा गया; इसे मजे के लिए बनाया है। input code को जितना हो सके छोटा रखते हुए interesting shapes draw करने के लिए इसके साथ और खेलना चाहता हूं। “मुझे लगता है कि computer science में computing का मजा बनाए रखना बेहद महत्वपूर्ण है।” — Alan J. Perlis