ข้อความล้วนอยู่มาหลายทศวรรษ และจะยังคงอยู่ต่อไป
(unsung.aresluna.org)- เครื่องมือออกแบบไดอะแกรม·UI ที่อิงกับ ข้อความล้วนแบบโมโนสเปซ กำลังกลับมาถูกใช้อีกครั้ง และความคุ้นเคยของอินเทอร์เฟซการแก้ไขข้อความกับ ความสามารถในการพกพาของ รูปแบบไฟล์ ก็เป็นพลังที่ทำให้แนวทางนี้อยู่ได้ยาวนาน
- เครื่องมืออย่าง Mockdown, Wiretext, และ Monodraw เหมาะกับการสร้าง ไดอะแกรมแบบความเข้มต่ำ โดยยังคงตัวเลือกด้านภาพที่จำกัดไว้ และยังเหมาะกับการนำไปใส่ในซอร์สโค้ดด้วย
- Mockdown ใช้งานได้ทันทีทั้งบนเว็บและมือถือ, Wiretext ทำงานบนเว็บแต่ ใช้ได้เฉพาะเดสก์ท็อป, ส่วน Monodraw มีให้ใช้งานเป็น แอป Mac
- แนวทางที่เคยพีคในช่วงทศวรรษ 1970~1980 กำลังกลับมาในรูปแบบที่ชวนให้นึกถึงสาย TUI อย่าง Turbo Vision พร้อมเสริมด้วยความร่วมสมัย ประสิทธิภาพ การเข้าถึงบนเว็บ และการใช้งานด้วยเมาส์·แทร็กแพด
- ยิ่งคอมพิวเตอร์มีประสิทธิภาพสูงขึ้น วิธีทำงานแบบ ตั้งข้อจำกัดให้ตัวเอง ก็ยิ่งมีประโยชน์มากขึ้น และเครื่องมือข้อความล้วนเหล่านี้ยังถูกใช้เป็น จุดเริ่มต้นสำหรับ gen AI มากขึ้นเรื่อย ๆ
ความยืนยาวของเครื่องมือข้อความล้วน
- มีการพูดถึงเครื่องมือออกแบบไดอะแกรม·UI แบบ ข้อความล้วน หรือ “ASCII” อย่าง Mockdown, Wiretext, Monodraw
- Mockdown ทำงานได้ทันทีบนเว็บและรองรับมือถือ
- Wiretext ทำงานบนเว็บ แต่ใช้งานได้เฉพาะบนเดสก์ท็อป
- Monodraw มีให้ในรูปแบบแอป Mac
- เครื่องมือเหล่านี้เหมาะเมื่ออยากได้ ตัวเลือกภาพที่ถูกจำกัดอย่างตั้งใจ, เมื่อต้องการสร้างไดอะแกรมแบบความเข้มต่ำสำหรับใส่ในซอร์สโค้ด และยังถูกใช้เป็น จุดเริ่มต้นสำหรับ gen AI มากขึ้นเรื่อย ๆ
- แนวทางที่เคยถึงจุดสูงสุดในช่วงทศวรรษ 1970~1980 กำลังฟื้นกลับมาในรูปแบบสมัยใหม่
- ชวนให้นึกถึงสาย TUI อย่าง Turbo Vision
- พร้อมเติมความร่วมสมัย ประสิทธิภาพ การเข้าถึงบนเว็บ และการใช้งานด้วยเมาส์และแทร็กแพด
- วิธีทำงานแบบมีข้อจำกัดกำลังมีความสำคัญมากขึ้น
- ยิ่งคอมพิวเตอร์มีสมรรถนะสูงขึ้น การกำหนดข้อจำกัดให้ตัวเองเพื่อทำให้งานง่ายขึ้นก็ยิ่งมีประโยชน์อยู่แล้ว
- เมื่อ AI แพร่หลายมากขึ้น การจำกัดตัวเองก็ยิ่งสำคัญแม้ในแง่ที่อาจทำให้งานยากขึ้นด้วย
- ข้อความล้วนแบบโมโนสเปซ มีพลังที่จะคงอยู่ยาวนาน ไม่ใช่แค่เพราะรูปแบบไฟล์พกพาได้ แต่ยังเพราะการแก้ไขข้อความในฐานะอินเทอร์เฟซเป็นสิ่งที่แพร่หลายและทรงพลัง
- ASCII spray ของ Mockdown ถูกยกให้เป็นองค์ประกอบที่สนุกเป็นพิเศษ
- คำว่า “ASCII” ที่ใช้ในที่นี้ ไม่ได้เป็นคำศัพท์เชิงเทคนิคอย่างเคร่งครัด แต่ใกล้เคียงกับสำนวนภาษาพูดแบบเดียวกับที่เรียกแอนิเมชันวนซ้ำทั้งหมดว่า “GIF” มากกว่า
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
ดีใจที่เห็นยกตัวอย่าง การทำบัญชีแบบ plain text
ผมย้ายบัญชีของธุรกิจคนเดียวจาก QuickBooks ไปเป็น Beancount+Fava แล้วพอใจกว่ามาก แถมยังผูกเข้ากับระบบใบแจ้งหนี้แบบ text-based และระบบติดตามระยะทางรถยนต์ด้วย รวมถึงใส่ validator บังคับให้รายจ่ายที่มีสถานะภาษีต้องแนบเอกสารหลักฐานเสมอ
มันเร็วกว่า ใช้ง่ายกว่า QuickBooks มาก ไม่ต้องทนดูโฆษณา และยังผูกกับ git พร้อมหลักฐานการประทับเวลา commit แบบ RFC3161 เพื่อพิสูจน์ได้ว่าเพิ่มอะไรเมื่อไร อีกทั้งยังลดโอกาสที่บันทึกจะหายไปจากการแก้ข้อความแบบไม่ระวัง และตรวจสอบได้ง่ายว่าแต่ละรายการถูกสร้างเมื่อไร
แก่นหลักคือทั้งหมดเป็น plain text แต่ถ้าต้องการก็เพิ่มส่วนขยาย Fava ให้จัดการผ่านเบราว์เซอร์ได้ด้วย ถ้ามี TUI Fava ที่ทำกราฟได้ด้วยก็คงยิ่งดี แต่เว็บ UI ที่มีอยู่ตอนนี้ก็ดีพอแล้ว
ตอนนี้เหลือแค่ว่านักบัญชีของผมจะดูสิ่งนี้อย่างไร
แม้ผมจะเป็นคนอเมริกัน แต่ทำงานอยู่ต่างประเทศเลยต้องจัดการ 2 สกุลเงิน ตลอด ซึ่ง Gnucash จัดการหลายสกุลเงินได้ไม่ค่อยน่าพอใจ ทำให้ผมกับคู่สมรสบันทึกกันมาเป็นไฟล์ข้อความจนถึงตอนนี้
เราใช้ฟอร์แมตค่อนข้างสม่ำเสมออยู่แล้ว ดังนั้นตอนย้ายไป Beancount ก็น่าจะใช้สคริปต์แปลงหรือให้ LLM ช่วยได้ จนงานราว 95% เป็นอัตโนมัติ เหลือแค่แจ้งเตือนรายการที่ parse ไม่ได้ก็น่าจะพอ
ผมก็น่าจะไปทาง Beancount + Fava เหมือนกัน
โดยเฉพาะอยากรู้รายละเอียดมากขึ้นว่าใช้ หลักฐาน commit แบบ RFC3161 อย่างไร
ผมเดาว่ามีการเซ็นด้วย GPG เพื่อแสดงว่าผู้เขียน commit เป็นเจ้าตัวจริง แต่อยากรู้ว่าใช้บริการประทับเวลาภายนอกกับ CA ภายนอกด้วยหรือไม่ หรือสร้างสายโซ่ความเชื่อถือขึ้นมาเอง
และถ้าผู้ตรวจสอบบัญชีต้องการพิสูจน์ความแท้จริงของ commit ในสมุดบัญชีจริง ๆ จะต้องใช้เอกสารและขั้นตอนอะไรบ้าง
เวลาเราสร้างฟอร์แมตไฟล์ง่าย ๆ ใช้เอง ผมจะคิดไว้เสมอว่าถ้าจำเป็นจะจะแปลงไปเป็น ฟอร์แมตที่ใช้กันทั่วไปมากกว่า ได้อย่างไร
แค่รู้ว่ามี ทางหนีทีไล่ สำหรับส่งต่อให้คนอื่นได้เมื่อต้องการ ก็สบายใจขึ้นมากแล้ว
ในกรณีนี้ก็น่าจะแปลงเป็น CSV ที่นักบัญชียอมรับได้ไม่ยาก
แม้ยุคทองอาจอยู่ช่วงทศวรรษ 1970-80 แต่ในยุค DOS ต้นทศวรรษ 1990 ก็ยังมี TUI ที่ยอดเยี่ยมมากมาย
ตอนนั้น Windows ยังไม่ได้ครองโลกเต็มตัว และส่วนใหญ่มักมีการ์ดจอ/จอภาพที่รองรับ VGA ทำให้ใช้ text mode ที่ความละเอียดสูง ภาพคม และปรับฟอนต์ได้ แถมหลายเครื่องก็มีเมาส์แล้วด้วย
สิ่งที่ผมคุ้นเคยตอนโตมาก็คือ QBASIC และ EDIT.COM ในสภาพแวดล้อมแบบนั้น
แม้แต่แอปบางตัวในยุคนั้นก็ยังมีเคอร์เซอร์เมาส์ที่ทำได้อย่างเหมาะสม วิดีโอของ Bisqwit แสดงเรื่องนี้ไว้ชัดเจน: https://www.youtube.com/watch?v=7nlNQcKsj74
มันคือเอดิเตอร์ที่มากับ Turbo-C, Turbo-Pascal ฯลฯ ถึงขั้นเรียกว่าเป็น IDE ก็ยังได้
WordPerfect, WordStar, Lotus 1-2-3 แบบ text mode ก็ยอดเยี่ยมมากเหมือนกัน
ดูอย่าง Omarchy ที่ขับเคลื่อนด้วยเทอร์มินัลและไฟล์คอนฟิกเป็นหลัก มันเกือบจะเป็นสวรรค์แล้ว
ถ้าโลกกำลังไปสู่อนาคตที่อินเทอร์เฟซหลักกับเครื่องจักรเป็นบทสนทนาแบบข้อความ กระแสนี้จะไปได้ไกลแค่ไหนก็น่าตื่นเต้นมาก
ที่นี่หลายคนอาจไม่ชอบให้พูดถึง AI แต่ผมเฝ้ารออนาคตนั้นอย่างจริงจัง
พอเห็นชื่อเรื่องแล้วผมกลับเผลอคิดไปอีกทางที่ต่างจากเนื้อหาหน่อย แต่ถ้าคุณเชื่อว่า plain text คือรากฐานของคอมพิวเตอร์ที่เรียบง่ายและทนทาน ก็ควรดูงานพูดของ 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
หาวิดีโอบรรยายจากหลายงานประชุมได้ไม่ยาก
มีตัวอย่างอย่าง UTF-16LE และ UTF-16BE ด้วย
โชคดีที่ตอนนี้ UTF-8 กลายเป็นค่าปริยายโดยพฤตินัยไปแล้ว ดังนั้นถ้าไม่มีเหตุผลพิเศษ ส่วนใหญ่ก็สมมติได้ว่าเอกสารเป็น UTF-8
แม้เวลาผมได้รับไฟล์ข้อความที่ไม่รู้ encoding ผมก็ยังคิดว่ามีโอกาส 99.7% ที่จะเป็น UTF-8 เลยรู้สึกว่าตอนนี้เราพูดได้อีกครั้งว่า plain text มีอยู่จริง
ถ้าจะเถียงว่า code page หรือ UTF-16 ก็เป็น plain text ทั้งนั้น แต่จริง ๆ ไม่ใช่ แบบนั้นในปี 2026 ก็ให้ความรู้สึกว่า ตกยุค พอสมควร
ตอนนี้ UTF-8 มีอยู่แทบทุกที่แล้ว
ดีที่ได้เห็นว่ามีแหล่งข้อมูลแบบนี้อยู่จริง
ระบบที่ซับซ้อนและประหลาดอย่าง Unicode จะเรียกว่า plain ได้อย่างไร ทุกวันนี้แอปจำนวนมากก็ยังมีปัญหาเกี่ยวกับ Unicode โผล่บ่อย ๆ
ถ้าจะพูดถึงระบบข้อความที่ใช้งานได้จริงในทุกที่ ผมยังมองว่ามีแค่ ASCII เท่านั้น และต้องเรียบง่ายระดับนั้นจึงจะเรียกว่า plain text ได้
มันก็จริงที่จำกัดอยู่กับภาษาอังกฤษเป็นหลัก แต่ในหลายบริบทนั่นกลับเป็นเรื่องธรรมชาติ และแม้ผมจะไม่ใช่เจ้าของภาษาอังกฤษก็ยังพร้อมสนับสนุนมุมมองนี้
Plain text นี่ยอดเยี่ยมจริง ๆ
ผมจัดการโน้ตกว่า 20 ปีของตัวเองด้วย https://github.com/nickjj/notes
ใบแจ้งหนี้ก็จัดการแบบ plain text ด้วย https://github.com/nickjj/invoice มาได้ราว 7 ปีแล้ว
สำหรับติดตามรายรับรายจ่ายก็มี https://github.com/nickjj/plutus และผมพอใจมาก
ตอนนี้แค่ export CSV จากธนาคารแล้วใส่เข้า Plutus จากนั้นใช้เวลาไม่กี่นาทีจัดหมวดหมู่นิดหน่อย สมุดบัญชีก็เสร็จแล้ว
ผมก็ทำภาษีด้วยวิธีนี้มาเป็นปีที่ 2 แล้ว
ข้อความนี่ 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 และมีไฮเปอร์ลิงก์ แต่ประสบการณ์ใช้งานจริงกลับใกล้เคียงอินเทอร์เฟซข้อความที่คลิกได้
ในเชิงคริปโตกราฟี HTML ก็เข้ารหัสเป็น ascii/utf-8 ได้ จึงอาจเรียกว่า plaintext ได้ แต่ใน MIME type นั้น text/plain กับ text/html แยกเอกสารข้อความธรรมดาออกจากเอกสารที่มีโครงสร้างและสไตล์
เทอร์มินัลก็มักถูกมองว่าเป็น plaintext แต่จริง ๆ แล้วมี escape sequence ที่มนุษย์อ่านตรง ๆ ได้ยาก ใช้เก็บเมตาดาตาอยู่
ในทางกลับกัน โซเชียลมีเดียก็มีรูปภาพจำนวนมากที่มีข้อความอยู่ไม่กี่บรรทัด และแพลตฟอร์มมือถือสมัยใหม่ก็รู้จำข้อความในภาพและให้เลือกได้ด้วย
ถ้าอย่างนั้นภาพที่มีแต่ข้อความโดยไม่มีองค์ประกอบอื่นเลยจะถือเป็น plaintext หรือไม่ ก็ชวนให้สงสัย
สุดท้ายสิ่งที่ผมอยากถามคือ ทุกวันนี้หลังผ่านมาหลายสิบปีนับจากการทำ implementation แรก ๆ เราควรขีด เส้นแบ่งของ plaintext ไว้ตรงไหน
นี่อาจจะคุยนอกเรื่องจากบทความหน่อย แต่ทำให้นึกถึง กราฟสถิติแบบอักขระข้อความ
นานมากแล้วผมเคยใช้ MINITAB รุ่นเพื่อการศึกษาบน DOS ซึ่งวาด scatter diagram, dotplot และ box-and-whisker plot ด้วยตัวอักษรข้อความ
เท่าที่จำได้ มันมีตัวเลือกทั้งข้อความล้วน ASCII หรืออักขระเส้นกรอบของ DOS
จุดประสงค์คือให้สำรวจข้อมูลก่อนจะเข้าสู่การทดสอบทางสถิติแบบเป็นทางการ
เลยสงสัยว่าทุกวันนี้ยังมีโปรแกรมที่วาด dotplot บนเทอร์มินัลได้ดี ๆ แบบนี้อยู่ไหม
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
รายการด้านบนยังเพิ่มได้อีกเยอะ
https://asciiflow.com/
https://asciidraw.github.io/
อยากรู้ว่ามีเครื่องมืออื่นที่คนรู้จักอีกไหม
https://d2lang.com/
แม้ชื่อจะบอกว่า ASCII แต่จริง ๆ เป็น visual editor ที่ใช้อักขระ UTF-8 BOX DRAWING
ไม่ต้องมีเซิร์ฟเวอร์ ไม่ต้องติดตั้ง และทำงานในเบราว์เซอร์ด้วย Javascript ล้วน
ยังมี M-x artist-mode ด้วย ใช้ได้ตรงใน Emacs
plain text นั้นดีแน่ แต่พอถึงจุดที่ต้องการ โครงสร้าง เราก็มักต้องเริ่มปูพื้นกันใหม่ทีละไฟล์
มีคนจำนวนมากที่โหยหาวิธีเอาเครื่องมือ Unix เก่า ๆ มาต่อกันแบบเฉพาะกิจเพื่อจัดการ plain text แต่แนวทางนั้นเหมาะกับงานชั่วคราวเท่านั้น และ ไม่อาจแทนฟอร์แมตที่มีสเปกชัดเจน ได้
จะประมวลผลแบบข้อความทั่วไปทีละบรรทัดก็ได้ จะแปลงเป็นข้อมูลแบบมีโครงสร้างก็ได้ และก็มีไคลเอนต์หรือรีดเดอร์ที่เรนเดอร์ออกมาแบบ WYSIWYG ได้อยู่แล้ว