सादा टेक्स्ट दशकों से मौजूद है और आगे भी रहेगा

• monospace सादा टेक्स्ट आधारित डायग्राम·UI डिज़ाइन टूल फिर से इस्तेमाल हो रहे हैं, और टेक्स्ट एडिटिंग इंटरफ़ेस की परिचितता तथा फ़ाइल फ़ॉर्मैट की पोर्टेबिलिटी इन्हें लंबे समय तक टिके रहने की ताकत देती है
• Mockdown, Wiretext, Monodraw जैसे टूल सीमित विज़ुअल विकल्पों को बनाए रखते हुए लो-इंटेंसिटी डायग्राम बनाने के लिए अच्छे हैं, और सोर्स कोड के भीतर शामिल करने के उपयोग के लिए भी उपयुक्त हैं
• Mockdown वेब और मोबाइल पर तुरंत इस्तेमाल किया जा सकता है, Wiretext वेब पर चलता है लेकिन केवल डेस्कटॉप के लिए है, और Monodraw Mac ऐप के रूप में उपलब्ध है
• 1970~1980 के दशक में शिखर पर पहुँचा यह तरीका Turbo Vision जैसे TUI परिवार की याद दिलाने वाले रूप में लौट रहा है, जिसमें आधुनिक संवेदना, परफ़ॉर्मेंस, वेब एक्सेसिबिलिटी, और माउस·ट्रैकपैड संचालन क्षमता जुड़ गई है
• जैसे-जैसे कंप्यूटर परफ़ॉर्मेंस बढ़ती है, स्वयं पर बंधन लगाकर काम करने की शैली और उपयोगी होती जाती है, और ऐसे सादा टेक्स्ट टूल धीरे-धीरे gen AI एंट्री पॉइंट के रूप में भी इस्तेमाल हो रहे हैं

---

सादा टेक्स्ट टूल्स की स्थायित्व

• सादा टेक्स्ट या “ASCII” आधारित डायग्राम·UI डिज़ाइन टूल के रूप में Mockdown, Wiretext, Monodraw का उल्लेख किया गया है
  • Mockdown वेब पर सीधे चलता है और मोबाइल को भी सपोर्ट करता है
  • Wiretext वेब पर चलता है, लेकिन केवल डेस्कटॉप पर इस्तेमाल किया जा सकता है
  • Monodraw एक Mac ऐप के रूप में उपलब्ध है
• ऐसे टूल तब उपयोगी होते हैं जब जानबूझकर सीमित विज़ुअल विकल्प पसंद किए जाते हों, जब सोर्स कोड में डालने के लिए लो-इंटेंसिटी डायग्राम बनाने हों, और अब बढ़ते हुए gen AI एंट्री पॉइंट के रूप में भी
• 1970~1980 के दशक में चरम पर पहुँचा यह तरीका आधुनिक रूप में फिर जीवित हो रहा है
  • यह Turbo Vision जैसे TUI परिवार की याद दिलाता है
  • इसमें आधुनिक संवेदना, परफ़ॉर्मेंस, वेब एक्सेसिबिलिटी, और माउस व ट्रैकपैड संचालन क्षमता जुड़ गई है
• बंधन के साथ काम करने की शैली स्वयं में महत्वपूर्ण होती जा रही है
  • जैसे-जैसे कंप्यूटर परफ़ॉर्मेंस बढ़ती है, काम को आसान बनाने के लिए खुद पर बंधन लगाना पहले से ही उपयोगी है
  • AI के प्रसार के साथ आत्म-बंधन उस दिशा में भी महत्वपूर्ण हो जाता है जहाँ काम को और कठिन बनाया जाता है
• monospace सादा टेक्स्ट के पास लंबे समय तक टिके रहने की ताकत सिर्फ फ़ाइल फ़ॉर्मैट की पोर्टेबिलिटी में नहीं, बल्कि इस बात में भी है कि इंटरफ़ेस के रूप में टेक्स्ट एडिटिंग व्यापक रूप से जानी-पहचानी और शक्तिशाली है
  • potent
• Mockdown का ASCII spray विशेष रूप से एक मज़ेदार तत्व माना गया है
• यहाँ “ASCII” शब्द का इस्तेमाल सख़्त तकनीकी अर्थ में नहीं, बल्कि उस बोलचाल की अभिव्यक्ति के करीब है जिसमें रिपीटिंग ऐनिमेशन को सामूहिक रूप से “GIF” कहा जाता है

[GN⁺]

Hacker News की राय

• उदाहरण के तौर पर plain text accounting का आना अच्छा लगा
  मैंने QuickBooks से Beancount+Fava पर अपने one-person business की बहीखाता प्रणाली शिफ्ट की, और इससे मैं कहीं ज़्यादा संतुष्ट हूँ। मैंने text-based invoice system और vehicle mileage tracking भी जोड़ लिया है, और tax status वाले खर्चों के लिए supporting documents अनिवार्य रूप से जुड़े रहें, इसके लिए validator भी लगा रखा है
  यह QuickBooks से बहुत तेज़ है, इस्तेमाल में आसान है, ads देखने की ज़रूरत नहीं पड़ती, और git तथा RFC3161 commit proof जोड़कर यह साबित किया जा सकता है कि कौन-सी एंट्री कब जोड़ी गई। लापरवाही से text edit होने पर रिकॉर्ड गायब हो जाने की संभावना भी कम हो गई है, और हर item कब बना था, यह देखना भी आसान है
  मूल बात यह है कि सब कुछ plain text है, लेकिन चाहें तो browser में संभालने के लिए Fava extension भी जोड़ रखा है। अगर graph वाला TUI Fava होता तो और अच्छा होता, लेकिन web UI भी काफ़ी अच्छा है
  अब बस यही देखना बाकी है कि accountant इसे कैसे देखेगा

  • मुझे Beancount के बारे में पहली बार पता चला, और यह काफ़ी आकर्षक लग रहा है
    मैं अमेरिकी हूँ, लेकिन दूसरे देश में काम करता हूँ, इसलिए हमेशा 2 currencies संभालनी पड़ती हैं। Gnucash में multi-currency को संतोषजनक ढंग से संभालना संभव नहीं हुआ, इसलिए मैं और मेरी पत्नी अब तक text files में रिकॉर्ड रखते आए हैं
    हमने format काफ़ी consistently इस्तेमाल किया है, इसलिए Beancount में migrate करते समय conversion script या LLM की मदद से शायद 95% काम automate हो सकता है। जो entries parse न हों, उनके लिए warning दिखा दी जाए तो काफ़ी होगा
    मेरे भी Beancount + Fava की तरफ़ जाने की पूरी संभावना है
  • यह मेरे plain text accounting projects के लिए सच में बहुत अच्छी प्रेरणा है
    खास तौर पर मैं यह ज़्यादा विस्तार से जानना चाहता हूँ कि RFC3161 commit proof का इस्तेमाल कैसे किया जाता है
    commit author खुद वही व्यक्ति है, यह दिखाने के लिए GPG signing का अंदाज़ा तो है, लेकिन मैं जानना चाहता हूँ कि इसमें external timestamp service और external CA का उपयोग होता है या अपनी trust chain बनाई जाती है
    अगर accounting auditor ledger commits की authenticity माँगे, तो असल में कौन-सा material और कौन-सी प्रक्रिया से यह साबित किया जाता है, यह भी जानना चाहूँगा
  • यह तरीका सच में बहुत अच्छा है
    जब मैं खुद कोई simple file format बनाता हूँ, तब भी मैं हमेशा सोचकर रखता हूँ कि ज़रूरत पड़ने पर इसे ज़्यादा common format में कैसे convert किया जाएगा
    सिर्फ़ यह जानकर ही मन को सुकून मिलता है कि ज़रूरत पड़ने पर किसी और को देने के लिए एक exit path मौजूद है
    इस मामले में तो शायद accountant के लिए स्वीकार्य CSV में बदलना भी आसान होगा

• इसका स्वर्णकाल 1970~80 के दशक में रहा हो सकता है, लेकिन 1990 के शुरुआती DOS दौर में भी बहुत शानदार TUI मौजूद थे
  वह समय Windows के पूरी तरह हावी होने से पहले का था, और आम तौर पर VGA-compatible graphics cards और monitors होते थे, इसलिए high-resolution, crisp, और adjustable-font text mode इस्तेमाल किया जा सकता था। कई बार mouse भी होता था
  बड़े होते हुए मैं ऐसे ही माहौल में QBASIC और EDIT.COM का आदी हुआ
  उस समय के कुछ apps में तो proper mouse cursor तक implement किया गया था, और Bisqwit का यह वीडियो उसे अच्छे से दिखाता है: https://www.youtube.com/watch?v=7nlNQcKsj74

  • उस दौर का Borland code editor मुझे बहुत पसंद था
    वही editor जो Turbo-C, Turbo-Pascal वगैरह में आता था; उसे IDE कहना भी गलत नहीं होगा
    text-mode WordPerfect, WordStar, और Lotus 1-2-3 भी काफ़ी बेहतरीन थे
  • मेरे हिसाब से TUI की चोटी के सबसे क़रीब Norton Commander या Midnight Commander आते हैं
  • बल्कि मैं तो मानता हूँ कि TUI का स्वर्णकाल अभी है
    terminal और config files पर चलने वाला operating system Omarchy देखें तो वह लगभग स्वर्ग जैसा लगता है
    अगर भविष्य में मशीनों के साथ मुख्य interface text-based conversation बन जाता है, तो यह रुझान कितना आगे जाएगा, यह देखने के लिए मैं उत्साहित हूँ
    यहाँ AI की बात करना कुछ लोगों को पसंद न आए, लेकिन मैं उस भविष्य को लेकर सच में उत्साहित हूँ

• शीर्षक देखकर मैं लेख के मूल विषय से थोड़ा अलग दिशा में चला गया, लेकिन अगर आप मानते हैं कि plain text simple और robust computing की बुनियाद है, तो Dylan Beattie का There's no such thing as plain text प्रस्तुतीकरण देखने लायक है
  https://www.slideshare.net/slideshow/theres-no-such-thing-as-plain-text-dylan-beattie/249952971
  इसके कई conference videos भी आसानी से मिल जाएंगे

  • मैंने अभी तक वीडियो नहीं देखा, लेकिन slides देखकर लगता है कि मुख्य बिंदुओं में से एक encoding का मुद्दा है
    UTF-16LE और UTF-16BE जैसे उदाहरण भी हैं
    अच्छी बात यह है कि अब UTF-8 लगभग default बन चुका है, इसलिए किसी खास वजह के बिना ज़्यादातर documents को UTF-8 मान लेना ठीक है
    जब कोई text file मिले और उसकी encoding न पता हो, तब भी मेरे हिसाब से उसके UTF-8 होने की संभावना 99.7% के आसपास है। इसलिए अब फिर से यह कहना ठीक लगता है कि plain text जैसी कोई चीज़ है
  • सिर्फ़ slideshow देखकर तर्क ठीक से समझ नहीं आता
    अगर बात यह है कि code page या UTF-16 जैसी चीज़ें भी plain text हैं, लेकिन वास्तव में नहीं हैं, तो 2026 के हिसाब से यह दावा काफ़ी पुराना लगता है
    अब तो UTF-8 लगभग हर जगह है
  • मैं यह अभिव्यक्ति पहले से इस्तेमाल करता आया हूँ, लेकिन बस एक धुँधला-सा अंदाज़ा था कि इस पर कोई proper talk पहले से मौजूद होगी
    ऐसा material वास्तव में मौजूद है, यह देखकर अच्छा लगा
  • मैं उस दावे से मज़बूती से असहमत हूँ
    Unicode जैसा complex और अजीब system plain नहीं कहा जा सकता, और आज भी बहुत से apps में Unicode से जुड़ी समस्याएँ अक्सर आती रहती हैं
    मेरे हिसाब से सच में हर जगह ठीक से काम करने वाली text system अब भी सिर्फ़ ASCII है, और plain text कहलाने के लिए कम-से-कम उतना simple होना चाहिए
    इसका मतलब है कि वह English-centric होकर सीमित रह जाती है, लेकिन कई environments में वही अधिक natural है। मैं भी native English speaker नहीं हूँ, फिर भी इस स्थिति का समर्थन कर सकता हूँ

• Plain text सच में शानदार है
  मैं अपने 20 साल से ज़्यादा पुराने notes को https://github.com/nickjj/notes से manage कर रहा हूँ
  invoices भी लगभग 7 साल से https://github.com/nickjj/invoice के जरिए plain text तरीके से संभाल रहा हूँ
  income-expense tracking के लिए https://github.com/nickjj/plutus भी है, और मैं इससे बहुत संतुष्ट हूँ
  अब मैं बस bank CSV export करता हूँ, उसे Plutus में डालता हूँ, और कुछ मिनट categories मिलाने में लगते हैं, बस ledger तैयार हो जाता है
  इसी तरीके से मैं 2 साल से tax filing भी कर रहा हूँ

• text Lindy है
  उसने समय की कसौटी पर खुद को साबित किया है, और SQL या TCP/IP जितना ही व्यापक है
  Graydon Hoare का पुराना लेख Always bet on text भी याद आता है
  [1]: https://news.ycombinator.com/item?id=8451271
  [2]: https://graydon2.dreamwidth.org/193447.html

• मुझे जिज्ञासा है कि यहाँ HN को भी plaintext माना जाएगा या नहीं
  साइट स्पष्ट रूप से HTML और hyperlinks से बनी है, लेकिन वास्तविक उपयोग का अनुभव clickable text interface के क़रीब है
  cryptographic नज़रिए से देखें तो HTML भी ascii/utf-8 में encode होता है, इसलिए उसे plaintext कहा जा सकता है, लेकिन MIME type में text/plain और text/html document structure और style information में फर्क करते हैं
  terminal को भी अक्सर plaintext माना जाता है, जबकि वास्तव में वह ऐसे escape sequences के ज़रिए metadata रखता है जिन्हें इंसान सीधे पढ़ना मुश्किल पाता है
  दूसरी तरफ़ social media पर कुछ lines वाले images बहुत हैं, और हाल के mobile platforms image के भीतर text पहचानकर उसे select भी करने देते हैं
  तो फिर सवाल उठता है: क्या दूसरे तत्वों के बिना सिर्फ़ text वाली image plaintext है?
  अंततः मैं यही पूछना चाहता हूँ कि शुरुआती implementation के दशकों बाद आज plaintext की सीमा कहाँ खींची जानी चाहिए

  • HN तो बस सामान्य HTML है, इसलिए उसे plaintext कहना कोई बड़ी बात नहीं होगी

• यह मूल लेख से थोड़ा अलग विषय है, लेकिन text character-based statistical charts याद आ गए
  बहुत पहले मैंने DOS के लिए educational edition MINITAB इस्तेमाल किया था, जो text characters से scatter diagram, dotplot, और box-and-whisker plot बनाता था
  जहाँ तक याद है, pure text, ASCII, या DOS line-drawing characters को option के रूप में इस्तेमाल किया जा सकता था
  मकसद यह था कि proper statistical tests पर जाने से पहले data को explore कराया जाए
  जानना चाहूँगा कि क्या आज भी कोई program है जो terminal में इस तरह का proper dotplot बना सके

  • इस Stack Overflow thread में terminal plotting tools काफ़ी अच्छे से संकलित हैं
    https://stackoverflow.com/questions/123378/command-line-unix-ascii-based-charting-plotting-tool
    इसमें gnuplot, feedgnuplot, eplot, asciichart, bashplotlib, ervy, ttyplot, youplot, visidata का ज़िक्र है
    और AWK की किताब में एक शानदार ASCII plot उदाहरण भी है: https://dn790008.ca.archive.org/0/items/pdfy-MgN0H1joIoDVoIC7/The_AWK_Programming_Language.pdf#page=148
  • शायद gnuplot dumb terminal mode काम आ जाए

• ऊपर की सूची और भी लंबी हो सकती है
  https://asciiflow.com/
  https://asciidraw.github.io/
  जानना चाहूँगा कि और कौन-कौन से tools हैं

  • D2 ने पिछले साल ASCII & Unicode output के लिए beta support जोड़ा था
    https://d2lang.com/
  • https://github.com/TheoKVA/ascii-box-editor
    नाम के उलट यह ASCII नहीं, बल्कि UTF-8 BOX DRAWING characters इस्तेमाल करने वाला visual editor है
    इसमें server या installation की ज़रूरत नहीं, यह सिर्फ़ browser में चलने वाला Javascript तरीका है
  • https://xosh.org/text-to-diagram पर बहुत से tools सूचीबद्ध हैं
  • https://monosketch.io

• M-x artist-mode भी है, जिसे Emacs में सीधे इस्तेमाल किया जा सकता है

• plain text निश्चित रूप से अच्छा है, लेकिन जैसे ही structured data की ज़रूरत पड़ती है, हर file के साथ फिर से शून्य से शुरुआत करनी पड़ती है
  पुराने Unix tools को ad-hoc तरीके से जोड़कर plain text process करने के approach के प्रति लोगों में nostalgia ज़रूर है, लेकिन ऐसा तरीका अस्थायी हालात में तो ठीक है, well-specified formats का विकल्प नहीं बन सकता

  • XML, JSON, YAML, RDF, EDN, LaTeX, OrgMode, Markdown जैसे structured plaintext formats पहले से बहुत हैं
    इन्हें line-based plain text की तरह process भी किया जा सकता है, structured data transformation भी संभव है, और इन्हें WYSIWYG की तरह render करने वाले clients या readers भी पहले से उपलब्ध हैं