IDE ที่เราเคยมีเมื่อ 30 ปีก่อน และตอนนี้ได้สูญหายไปแล้ว

 (blogsystem5.substack.com)
4 คะแนน โดย GN⁺ 2025-10-19 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ต้นทศวรรษ 1990 IDE แบบข้อความสามารถมอบความสามารถที่ยอดเยี่ยมได้แม้บน ฮาร์ดแวร์ที่มีข้อจำกัด
  • Borland Turbo series ซึ่งเป็น IDE ตัวแทนในยุคนั้น มีทั้งการเน้นไวยากรณ์ การรวมคอมไพเลอร์ การดีบัก และระบบช่วยเหลือ จนมีสภาพแวดล้อมที่ทัดเทียม IDE สมัยใหม่
  • บนลินุกซ์ Vim และ Emacs ปรับแต่งได้สูง แต่มีข้อจำกัดตรงที่เรียนรู้ยากและไม่เป็นมิตรกับผู้เริ่มต้น
  • ช่วงหลังมานี้ TUI (Text UI) และฟีเจอร์แบบ IDE กำลังค่อย ๆ ฟื้นกลับมาจากการเกิดขึ้นของ เทคโนโลยีใหม่อย่าง LSP แต่ก็ยังขาดความกลมกลืนแบบยุค 90 อยู่มาก
  • ข้อดีของ TUI IDE คือการเข้าถึงจากระยะไกล การใช้ทรัพยากรต่ำ และเสรีภาพแบบโอเพนซอร์ส ขณะที่ IDE สมัยใหม่กลับมีปัญหา ขยายตัวจนเทอะทะ จากการเพิ่มฟีเจอร์

บทนำ: ความทรงจำของ IDE แบบข้อความในช่วงต้นทศวรรษ 1990

  • ช่วงปลายทศวรรษ 1980 ถึงต้นทศวรรษ 1990 ผู้เขียนได้ย้อนกลับไปสัมผัสสภาพแวดล้อมการพัฒนาแบบเก่าผ่าน DOSBox และสนุกกับการ เปรียบเทียบกับยุคปัจจุบัน
  • ในเวลานั้น IDE แบบข้อความ มีฟังก์ชันมากมายแม้อยู่ภายใต้ข้อจำกัดของฮาร์ดแวร์
  • หลังจากนั้น ฟีเจอร์ส่วนใหญ่ได้ หายไปเป็นเวลานาน พร้อมกับการเติบโตของระบบปฏิบัติการแบบหน้าต่าง และเพิ่งเริ่มกลับมาบางส่วนในช่วงหลัง

เอดิเตอร์ยุคแรกและสภาพแวดล้อม TUI

  • โปรแกรม DOS ส่วนใหญ่ในยุค 1990 ใช้ Text User Interface (TUI) แบบเต็มหน้าจอ รองรับหน้าต่างข้อความ สี เงา และแม้แต่เมาส์
  • แม้แต่ละโปรแกรมจะมีดีไซน์ต่างกัน แต่ก็เรียนรู้ได้ไวเพราะมี รูปแบบการใช้งานคล้ายกัน
  • MS-DOS เริ่มมีเอดิเตอร์ TUI ในตัวตั้งแต่เวอร์ชัน 5 (1991) แต่จำเป็นต้อง ปิดเอดิเตอร์เพื่อคอมไพล์หรือรัน และเมื่อเปิดกลับมาก็ต้องหาตำแหน่งงานค้างใหม่ ซึ่งไม่สะดวก
  • ยังมีเครื่องมือแบบ TSR (โปรแกรมพำนักในหน่วยความจำ) อย่าง SideKick Plus (1984) ที่ช่วยให้แก้ไขโค้ดและบิลด์ได้อย่างมีประสิทธิภาพบน OS ที่ยังไม่รองรับมัลติทาสกิง
  • ตั้งแต่ช่วงกลางถึงปลายทศวรรษ 1980 ก็มี IDE ยุคแรกอย่าง Turbo Pascal, QuickBASIC ปรากฏขึ้นแล้ว และมอบประสบการณ์พัฒนาแบบรวมศูนย์

Borland Turbo series: จุดสูงสุดของ IDE แบบรวมศูนย์

  • Borland Turbo C++, Turbo Assembler, Turbo Pascal ฯลฯ แม้จะเป็นเครื่องมือ เฉพาะภาษา แต่ก็มาพร้อม TUI แบบเต็มหน้าจอและความสามารถทรงพลัง
  • ฟีเจอร์หลัก:
    • การเน้นไวยากรณ์ ช่วยให้อ่านโค้ดได้ง่ายขึ้น
    • การรวมคอมไพเลอร์และระบบเตือน/วินิจฉัยข้อผิดพลาด
    • ระบบโปรเจกต์/บิลด์และหน้าต่างหลายบาน
    • ดีบักเกอร์ (breakpoint, call stack ฯลฯ)
    • ระบบช่วยเหลือ/คู่มืออ้างอิงในตัว
  • ทุกอย่างนี้มอบสภาพแวดล้อมที่ครบถ้วนและใช้งานเข้าใจง่ายได้ด้วยตัวเอง แม้ไม่มีอินเทอร์เน็ตในยุคต้น 90

เปรียบเทียบกับสภาพแวดล้อมลินุกซ์ในเวลานั้น

  • ฝั่งลินุกซ์เองก็มีเครื่องมือแบบข้อความเป็นหลักเช่นกัน แต่ TUI แบบเต็มหน้าจอยังไม่แพร่หลาย
  • Vim และ Emacs ที่หนังสือและชุมชนแนะนำ แม้จะขยายความสามารถได้มาก แต่สำหรับมือใหม่ถือว่า ไม่เป็นมิตรและขาดความเป็นธรรมชาติในการใช้งาน
  • เช่น Emacs มีปัญหาอย่างหน้าตาที่เรียบเกินไป สีที่จำกัด การรองรับเมาส์ที่ไม่เสถียร และเมนูที่เข้าใจยากและไม่คุ้นเคย
  • ขณะที่ IDE อย่าง Borland Turbo C++ สามารถให้ผู้ใช้สร้างโปรแกรม “Hello World” และสำรวจสภาพแวดล้อมได้ภายในไม่กี่นาที โดยแทบไม่ต้องมีความรู้ล่วงหน้า

IDE แบบข้อความในปัจจุบัน

  • ปัจจุบันสภาพแวดล้อมที่ใกล้เคียง TUI IDE ในอดีตมากที่สุด ได้แก่ RHIDE, Free Pascal, QB64
    • RHIDE แทบจะเหมือน Turbo C++ ทุกประการ แต่เป็น DOS เท่านั้น และหยุดพัฒนาแล้ว
    • Free Pascal รองรับสภาพแวดล้อมยูนิกซ์ และมีสภาพแวดล้อมรวมที่ทรงพลังพร้อม เครื่องคิดเลขในตัว ตาราง ASCII ฯลฯ
    • QB64 ดูเหมือน TUI แต่ จริง ๆ เป็นการจำลอง GUI และไม่สามารถรันบนเทอร์มินัลได้
  • ทั้ง Free Pascal และ QB64 ยังมีการพัฒนาจนถึงช่วงหลัง แต่ เพราะผูกกับภาษาที่ดูเก่า จึงไม่ค่อยได้รับความนิยมในวงกว้าง

คอนโซล IDE สมัยใหม่อย่างแท้จริง

  • ในบรรดาสภาพแวดล้อมพัฒนาแบบข้อความยุคใหม่ Neovim, Doom Emacs, Helix เป็นชื่อที่รู้จักกันดี
  • ด้วย ปลั๊กอินจำนวนมาก พวกมันสามารถมอบประสบการณ์ระดับ IDE ได้ แต่ยังขาด ความกลมกลืนและความเป็นธรรมชาติแบบผสานตามภาษา เหมือนผลิตภัณฑ์ตระกูล Borland
  • ช่วงหลัง GNU Nano และตัวอื่น ๆ เริ่มได้รับความสนใจในฐานะเอดิเตอร์ TUI แบบเรียบง่าย แต่เพราะ ไม่มีฟีเจอร์แบบ IDE จึงให้ความรู้สึกคล้าย WordStar มากกว่า
  • สุดท้ายแล้ว เอดิเตอร์คอนโซลในทุกวันนี้ยังตามไม่ทันระดับประสบการณ์ของยุค 90 หรือไม่ก็เพิ่งจะไล่ตามฟีเจอร์เมื่อ 30 ปีก่อนกลับมาได้เท่านั้น

ความจำเป็นของ TUI IDE

  • ถึงแม้ฟีเจอร์ remote ของ VSCode จะยอดเยี่ยม แต่ TUI IDE ก็ยังได้เปรียบตรงที่สามารถ SSH เข้าเครื่องระยะไกลแล้วใช้งานได้ทันที
  • ยิ่งไปกว่านั้น ส่วนขยาย remote ของ VSCode ไม่ใช่โอเพนซอร์ส และยังมีข้อจำกัดที่ใช้งานไม่ได้บนบาง OS (เช่น FreeBSD)
  • TUI IDE ยัง ใช้ทรัพยากรต่ำ และมีประโยชน์มากเป็นพิเศษในสภาพแวดล้อมระยะไกล

การขยายตัวจนเทอะทะและปรากฏการณ์ "Bloat"

  • Borland Turbo C++ รวมทุกฟีเจอร์ไว้ครบ และตอนติดตั้งใช้พื้นที่ ไม่ถึง 9MB พร้อมทำงานได้ใน RAM 640KB
  • Doom Emacs รุ่นปัจจุบันมีขนาด เกิน 500MB และ IDE สมัยใหม่หลายตัวก็แตะระดับหลาย GB ทำให้ปัญหา ความเทอะทะ รุนแรงขึ้น
  • VSCode แม้จะเบาพอสมควรที่ 350MB แต่เพราะสร้างบน Electron จึงยังใช้ทรัพยากรระบบจริงค่อนข้างมาก
  • แม้จะมีพัฒนาการด้านฟีเจอร์หรือรีแฟกเตอร์บางส่วน แต่เมื่อเทียบกับ 30 ปีก่อน นวัตกรรมกลับมีอยู่อย่างจำกัด
  • ผู้ช่วยเขียนโค้ดด้วย AI เป็นความเปลี่ยนแปลงใหม่ในช่วงหลัง แต่ในทางปฏิบัติส่วนใหญ่ก็ยังเป็นบริการจากระยะไกล

บทสรุป

  • ผู้เขียนยังคงใช้สภาพแวดล้อมพัฒนาหลายแบบตามสถานการณ์ ทั้ง Doom Emacs, Vim, VSCode, IntelliJ ฯลฯ
  • ประสบการณ์การพัฒนาแบบครบวงจร และประสิทธิภาพที่ TUI IDE เมื่อ 30 ปีก่อนมอบให้นั้น ตัดกันอย่างชัดเจนกับ ความเทอะทะและความกระจัดกระจาย ของ IDE สมัยใหม่
  • คุณค่าและศักยภาพของ IDE แบบข้อความยังคงมีอยู่ และก็คงต้องติดตามกันต่อไปว่ามันจะพัฒนาและฟื้นคืนกลับมาได้มากเพียงใด

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-10-19
ความเห็นบน Hacker News

  • รู้สึกช็อกมากที่พบว่า Visual Basic เคยยอดเยี่ยมที่สุดในงานโปรแกรมแบบกราฟิก สมัยก่อนสามารถพัฒนาแอป GUI ระดับกลางได้อย่างรวดเร็วมากภายในวันเดียว อย่างมากที่สุดที่ใกล้เคียงคือ C# WinForms แต่หลังจากนั้นเครื่องมือทั้งหมดก็ดูไม่ค่อยคำนึงถึงนักพัฒนาเดี่ยวเท่าไรนัก จึงน่าเสียดาย เลยขอเสนอพาราไดม์การพัฒนาใหม่ที่ทรงพลังคือการพัฒนาแบบใช้เสียง/คำพูดเป็นฐาน (SDD/VDD) หวังว่าจะได้หลุดพ้นจากความทรมานของการพิมพ์จำนวนมาก และการโต้ตอบกับ AI จะเป็นธรรมชาติเหมือนคุยกับเพื่อนร่วมงาน เพียงแต่ถ้าจะทำให้เกิดขึ้นจริง AI model ต้องเร็วขึ้นกว่านี้มาก

    • Delphi เหนือกว่า Visual Basic ตั้งแต่ตอนนั้นแล้ว และทุกวันนี้ก็ยังใช้งานได้ Lazarus ก็ยังคงอยู่ต่อไป จริง ๆ แล้ว C# WinForms คือประสบการณ์ที่ใกล้กับ Delphi มากที่สุด

    • รู้สึกว่า Qt Creator ให้ประสบการณ์คล้าย VB6 เลย อยากรู้ว่าเคยลองใช้ไหม

  • คิดว่า Emacs ยังให้คุณสมบัติทั้งหมดนี้อยู่ เพียงแต่สิ่งที่ผู้เขียนเรียกว่า “ไม่ดั้งเดิม” นั้นเป็นเพราะไม่คุ้นกับธรรมเนียมของมัน Emacs เป็นระบบที่มีเอกสารในตัวครบถ้วนและเป็นแบบโต้ตอบ อินเทอร์เฟซแบบข้อความที่ดีที่สุดเท่าที่เคยใช้มาคือ Magit ภายใน Emacs เอง (https://magit.vc/) อยากให้ส่วนอื่น ๆ ของ Emacs เป็นแบบ Magit มากขึ้น ต่อให้ใช้ IDE อื่น ก็ยังใช้ Emacs เป็น git client

    • Emacs เป็นเครื่องมือเก่าแก่ตั้งแต่ก่อนที่ Apple จะคิดคีย์ลัด cmd-z/x/c/v ขึ้นมา ตอนนั้นคีย์ลัดของเอดิเตอร์สำหรับโปรแกรมเมอร์สาย Wordstar (เช่นในผลิตภัณฑ์ส่วนใหญ่ของ Borland) เป็นกระแสหลัก ทุกวันนี้แทบไม่มีใครรู้แล้วว่าเมื่อ 30–40 ปีก่อนมี IDE ที่ยอดเยี่ยมมากอยู่ ตัวอย่างเช่น Apple MPW (1986) เป็น GUI editor ที่ทุกหน้าต่างเป็น Unix shell ได้ และควบคุมหน้าต่างกับงานแก้ไขผ่าน shell script ได้ อีกทั้งยังมีระบบจัดการ source code ในตัว พิมพ์คำสั่งแล้วกด option-Return ก็จะมีหน้าต่าง GUI ชื่อ 'Commando' โผล่ขึ้นมาให้เลือกตัวเลือกทั้งหมดได้ Apple Dylan (1992-1995) ก็เป็น IDE ทรงพลังสไตล์ Lisp/Smalltalk และยังมี THINK Pascal และ C (1986), Metrowerks Codewarrior (1993), Macintosh Allegro Common Lisp ที่ล้ำสมัยมากเช่นกัน น่าทึ่งที่ IDE ละเอียดประณีตขนาดนี้ทำงานได้บนสภาพแวดล้อม 8~40MHz M68000 กับ RAM 2~32MB ในยุค 80 ถึงต้น 90

    • สำหรับความเห็นที่ว่า Emacs มีเอกสารในตัวและเป็นแบบโต้ตอบนั้น เอาเข้าจริงตอนเจอครั้งแรกยังไม่รู้เลยว่าจะบันทึกเอกสารอย่างไร แม้จะดีกว่า vi แต่ก็ยังไม่พอสำหรับมือใหม่ที่จะเปิดมาแล้วใช้งานได้ทันทีโดยไม่มีคำอธิบาย

    • Magit น่าทึ่งจริง ๆ สงสัยว่าเขาคิด data model แบบนี้ขึ้นมาได้อย่างไร ให้ความรู้สึกเหมือนทำได้เกินกว่า data model ของ git เสียอีก เมื่อเทียบกับความกระจัดกระจายของ git porcelain แล้ว Magit มีโครงสร้างที่เป็นระบบมาก

    • IDE สไตล์ Turbo-Vision นั้น แค่รู้ Alt, Tab, Return, Esc, ปุ่มลูกศรไม่กี่ปุ่ม ก็เข้าใจฟังก์ชันส่วนใหญ่ได้แล้ว ขณะที่ Emacs ไม่มีความสม่ำเสมอในการควบคุมแบบนี้

    • ใช้ Emacs มานานกว่า 25 ปีแล้ว ตอนนี้คุ้นมือไปหมดแล้ว

  • Turbo Pascal น่าทึ่งจริง ๆ ตอนแรกก็ลังเลเพราะมันเป็น Pascal implementation ที่ไม่เป็นมาตรฐาน แต่เครื่องมือคู่แข่งทั้งแพงกว่าและทรงพลังน้อยกว่า พอลองใช้เองแล้วก็หลงรักทันที ได้สัมผัส IDE ที่รวดเร็วและใช้งานง่ายบน IBM PC ในบรรดา IDE สมัยใหม่ Intellij เหนือกว่าคู่แข่งมาอย่างมากนานกว่า 25 ปีแล้ว ไม่ได้ใช้ผลิตภัณฑ์ Microsoft มานานจึงไม่มีประสบการณ์กับ VSCode ส่วน Eclipse ก็ทั้งช้า ไม่ค่อยใช้งานง่าย และบั๊กเยอะ JetBrains เป็นหนึ่งในไม่กี่บริษัทที่รักษาพันธกิจและความยอดเยี่ยมไว้ได้ น่าประทับใจที่ยังคงรองรับภาษา มาตรฐาน และเครื่องมือหลากหลายอย่างต่อเนื่อง พร้อมรักษาคุณภาพระดับสูงไว้ได้

    • Visual Studio ยังรองรับ WinForms และกราฟิกฟอร์มดีไซเนอร์อยู่ ซึ่งให้ประสบการณ์คล้าย Delphi ช่วงปลายยุค 90 มาก เพราะ WinForms ก็ลอก VCL มาแบบชัดเจน

    • แต่ปัญหาเรื่องการใช้ทรัพยากรหนักมาก บน cloud desktop ที่ใช้ neovim ไม่ได้เลยต้องใช้ ideavim แต่แม้มี 4 คอร์ RAM 16GB แค่เปิดหลายโปรเจกต์ก็เริ่มหน่วง อาจมีผลจากซอฟต์แวร์ความปลอดภัยของบริษัทด้วย แต่ VSCode ไม่ลำบากขนาดนั้น

  • IDE ของ Turbo Pascal ล้ำยุคมาก และบน CP/M (โดยเฉพาะ Z-80) ก็ยอดเยี่ยมราวกับเวทมนตร์ ดีกว่าสิ่งใด ๆ ในยุคนั้น

  • บทความนี้เป็นของปี 2023 ดังนั้นน่าจะต้องอัปเดตปีในชื่อเรื่องเป็น 32 ปีก่อนจึงจะถูกต้อง สิ่งที่น่าเสียดายที่สุดใน TUI ปัจจุบันคือเฟรมเวิร์กแบบ asynchronous มักจะทำคีย์อินพุตหายไปบ่อย ๆ TUI ก่อนปี 2000 จะรอคีย์อินพุตไว้แม้ระบบยังไม่พร้อม ตรงกันข้าม เฟรมเวิร์ก TUI สมัยใหม่แบบ "เว็บเบส" ถ้ากดคีย์ก่อน event listener จะลงทะเบียน ก็จะถูกมองข้ามไปเลย นอกจากปัญหานี้ TUI ก็ยังทำงานได้ดีอยู่ Neovim มีความสามารถสูงที่สุดเท่าที่เคยมีมาเพราะ LSP และปลั๊กอิน แม้จะไม่ใช่ TUI แบบใช้เมาส์ แต่ในแง่ productivity ถือว่ายอดเยี่ยมมาก

    • สมัย DOS บนเทอร์มินัลจริงจะมี key input buffer และคนที่ชำนาญอินเทอร์เฟซจะพิมพ์หลายปุ่มล่วงหน้าแซง UI ไปได้ อินพุตจะกองอยู่ในบัฟเฟอร์แล้วแสดงขึ้นมาบนจอแบบพุ่งมาแล้วหายไปในพริบตา โครงสร้างแบบนี้ยังทำได้ในเฟรมเวิร์กสมัยใหม่ แต่ต้องออกแบบอย่างระมัดระวัง

    • เคยมีประสบการณ์แบบนี้ตั้งแต่ปี 1984 งั้นก็อาจนับย้อนไปได้ถึง 41 ปีก่อน จนกว่าผลิตภัณฑ์ GUI อย่าง Visual Studio 1.0 หรือ NetBeans จะออกมา โปรเจกต์ยุคแรก ๆ เหล่านี้ก็ยังเป็นกระแสหลัก มันก่อน vim (1991) แต่ให้ความรู้สึกว่าอยากได้ floating window มากกว่า ncurses

    • อาการคีย์หายแบบนี้น่าหงุดหงิดจนแทบบ้า สมัยก่อนใช้คอมพิวเตอร์ได้เร็วมากด้วยคีย์ลัดต่อเนื่อง แต่ตอนนี้กลับเหมือนกำลังเดินอยู่ในกากน้ำตาลเหนียว ๆ

    • ตอนแรกนึกภาพไม่ออกว่า 30 ปีก่อนคือช่วงไหน ตั้งตารอ GUI Smalltalk system browser แต่ดันได้ DOS TUI มาแทนเลยแอบผิดหวัง แต่พอได้รำลึกถึง Turbo C/Pascal, MS C 4.0 และ CodeView ก็รู้สึกดีขึ้น เครื่องมือเหล่านี้ใช้งานได้แม้ในโหมด 43 บรรทัดและ 50 บรรทัด

    • คิดว่าการพึ่งพา IDE ใด IDE หนึ่งมากเกินไปอาจเป็นผลเสียต่อความสามารถในการแข่งขันของตัวเองหรือแม้แต่ต่อโค้ดของตัวเอง ถ้าพูดถึง terminal IDE แล้ว GNU/Linux terminal นี่แหละคือแอปที่ดีที่สุด การเปิดหลายเทอร์มินัลบน tiling window manager ช่วยเพิ่ม productivity ได้มาก การสเกลหน้าจอสมัยใหม่บนจอใหญ่ก็ยอดเยี่ยมมากในเชิงสรีรศาสตร์สำหรับนักพัฒนา

  • ทุกวันนี้ยังพัฒนาและใช้งาน text-based editor/IDE ที่ทำเองอยู่ (https://github.com/alefore/edge) และเพิ่งเขียนสรุปบทเรียนจากการพัฒนาตลอด 10 ปีไว้ไม่นานนี้ (https://github.com/alefore/weblog/blob/master/edge/README.md)

    • ฉันก็ทำเองเหมือนกัน ใช้เวลาพัฒนาราว 4 เดือน แต่เป็นประสบการณ์ที่สนุกมาก (https://github.com/ivanjermakov/hat)

  • ในยุครุ่งเรืองของ DOS จะจัดการตัวอักษรเป็นอาร์เรย์ของไบต์ และจัดการแอตทริบิวต์อย่างสีพื้นหลัง สีตัวอักษร ฯลฯ เป็นอีกอาร์เรย์หนึ่ง ถ้าจะเขียน 'A' ที่ตำแหน่งใด ก็แค่เขียน 0x41 ลงในตำแหน่งหน่วยความจำ แม้จะมี wait state อยู่บ้าง แต่ก็ยังเร็วกว่าแสดงผลผ่าน ANSI command บนเทอร์มินัล 9600 baud มาก Emacs ใช้ได้บน serial terminal ที่ช้าหรือ terminal emulator ของ Sun workstation แต่ก็เป็นฉากหลังที่ทำให้ shell-based TUI ค่อย ๆ หายไป

    • วิธีเก่า ๆ ดูเหมือนจะเหนือกว่าด้วยซ้ำ สงสัยว่าเวลาปรับขนาดหน้าจอเขาจัดการกันอย่างไร

  • แม้บทความนี้จะโฟกัสที่ text-based IDE แต่คิดว่าน่าจะใช้กับ IDE แบบดั้งเดิมอย่าง Visual Basic หรือ Delphi ได้ด้วย สำหรับมือใหม่ ผมคิดว่าจำเป็นต้องมี IDE สำหรับ Python จริง ๆ ที่ไม่ใช่แบบ text-based แต่เป็นสไตล์ Visual Basic ที่ทุกอย่างถูกรวมไว้ด้วยกันและค้นพบฟีเจอร์ได้ง่าย (สำคัญ!) ถ้ามี GUI builder กับ debugger ในตัวด้วยก็ดี ส่วน code editor แค่มี syntax highlighting, autocomplete และการนำทางโค้ดที่ง่ายก็พอแล้ว เช่น วางปุ่มลงในหน้าต่างแล้วดับเบิลคลิกใน GUI editor เพื่อกระโดดไปยังโค้ด handler ของปุ่มนั้นได้ทันที เคยมีคนมารวมตัวคุยกันเรื่องไอเดียคล้าย ๆ กัน แต่เถียงกันหนักว่าจะใช้ GUI framework อะไรดี (Pyside, Dear PyGui, เว็บเบส ฯลฯ) จนสุดท้ายวงแตก พอพูดถึง Free Pascal แล้วก็ควรพูดถึง Lazarus (https://www.lazarus-ide.org/) ที่เป็นการโคลน Delphi ด้วย มันยอดเยี่ยมมากและยังพัฒนาอย่างคึกคักอยู่ เพียงแต่ Object Pascal ทุกวันนี้ไม่ได้ใช้กันมากแล้ว เลยให้ความรู้สึกค่อนข้างเก่า

    • เห็นด้วยเต็มที่ว่าควรมี IDE แบบรวมศูนย์สำหรับ Python สำหรับผู้เริ่มต้นในสไตล์ Visual Basic พร้อม GUI builder และ debugger ในตัว เคยมี Python IDE ชื่อ Boa Constructor (https://boa-constructor.sourceforge.net/) ตั้งแต่ปี 2000 แต่ไม่เคยแพร่หลาย

    • ไม่นานมานี้ฉันเองก็อัดวิดีโอตอนทำ toy app ด้วย VB3 บน Windows 3.11 แล้วโพสต์ลง ซึ่งทวีตนั้นก็ “ไวรัล” ขึ้นมา สุดท้ายประเด็นสำคัญไม่ใช่ TUI แต่คือประสบการณ์ใช้งานแบบบูรณาการ

    • สำหรับฉัน Lazarus คือมาตรฐานของคำว่า IDE ที่แท้จริง Lazarus สร้างด้วย Lazarus เอง และผู้เขียนก็ใช้งานผลิตภัณฑ์ของตัวเองอย่างจริงจัง พร้อมมีตัวอย่างและบทสอนให้ครบ มันยอดเยี่ยมมากสำหรับการสอนเด็ก ๆ เขียนโปรแกรม มีทั้งแท็ก การค้นหา ความช่วยเหลือ เอกสาร API ตัวอย่างวิดเจ็ต และไลบรารีที่รวมอยู่ด้วยเหมือน Microsoft Visual Studio ส่วน IDE อื่นไม่มีความเป็นหนึ่งเดียวแบบนี้ แม้แต่ Xcode ที่เรียกตัวเองว่า IDE ก็ยังเทียบ Lazarus ไม่ได้ ฉันดื้ออยู่เหมือนกันจนตอนนี้ใช้เวลา 6 เดือนทำเฟรมเวิร์ก UI frontend เองด้วย Go แทน JS หวังว่าสักวันอาจได้ทำ IDE เองด้วย

  • IDE ของ Borland เป็นความสุขอย่างแท้จริง จนถึงตอนนี้ก็ยังหาเครื่องมือสมัยใหม่ที่ให้ประสบการณ์ระดับนั้นไม่ได้ แน่นอนว่าอาจมีแรงคิดถึงอดีตอยู่บ้าง แต่ถึงอย่างนั้นการหาเหตุผลมาใช้ Free Pascal เพื่อได้เรียกอินเทอร์เฟซนั้นกลับขึ้นมาก็ยังสนุก ฉันก็ชอบ Pascal ด้วย บางครั้งก็ใช้ Sam และ Acme ของ Plan 9 แต่พวกนั้นเป็น editor ไม่ใช่ IDE ฉันชอบเครื่องมือที่ไม่รบกวนการคิดและเปิดพื้นที่ให้คิดได้ ยังมีหลายอย่างที่ควรเรียนรู้จาก TUI ยุคก่อน ตัวอย่างเช่น การเปิด shell จากเมนู File เพื่อไปรันอะไรบางอย่างแล้วกลับมาใหม่ก็ยังถือว่ายอมรับได้และเป็นอะไรที่เท่มาก และที่สำคัญคือ keybinding! TUI สมัยก่อนมักยืมรูปแบบคีย์ลัดของ WordStar มาใช้ ซึ่งติดตัวจนทุกวันนี้ จน Emacs ให้ความรู้สึกเหมือนพิมพ์โดยใส่ถุงมือเตาอบ ฉันเคยใช้ joe (alias jstar) มานานมาก ถึงเวลาบูต Dr. DOS VM ขึ้นมา ลอง Advent of Code แล้วจัดปาร์ตี้แห่งความทรงจำแบบจงใจไร้ประสิทธิภาพเสียที

    • ซอฟต์แวร์ “มืออาชีพ” ในยุค DOS (เช่น Emacs) ถูกออกแบบให้ผู้ใช้ใช้ชีวิตอยู่ภายในซอฟต์แวร์นั้นอย่างสมบูรณ์ จนกลายเป็นหนึ่งเดียวกับเครื่องและใช้คีย์ลัดได้คล่องเหมือนนักออร์แกน ยังจำได้ว่าดูพนักงาน Fry’s Electronics ใช้งาน TUI ได้เร็วมากจนงานเสร็จและเอกสารถูกพิมพ์ออกมาก่อนที่หน้าจอจะขึ้นด้วยซ้ำ

    • อยากรู้ว่า WordStar bindings คืออะไร และมันดีอย่างไร สนใจศึกษาประวัติของรูปแบบนี้และข้อดีของแนวทางต่าง ๆ

    • เห็นด้วยกับบทความที่ยอดเยี่ยมนี้ ฉันเองก็กำลังพัฒนา tui code editor สไตล์ Turbo Pascal ในเวลาส่วนตัว และมีแผนจะฝัง make กับ lldb เข้าไปในอนาคต

    • ฉันชอบหลายอย่างของ Plan 9 แต่ปรับตัวกับ UI แบบเน้นเมาส์ของ Acme ไม่ได้จริง ๆ UI ที่ต้องเล็งเมาส์อย่างแม่นยำแบบนี้น่าจะไม่สะดวกมากหากต้องใช้เป็นเวลานานหรือมีความพิการบางอย่าง

    • ชุดผสม djgpp กับ vi for dos 1991 นั้นยอดเยี่ยมที่สุด

  • เคยใช้ทั้ง Java IDE ชื่อ Visix Vibe และ Delphi ซึ่งทั้งสองตัวช่วยเพิ่ม productivity ได้มหาศาล ทำให้สามารถคาดการณ์ตารางเวลาการพัฒนา UI การเชื่อมตรรกะ และการเตรียม deployment ให้ลูกค้าได้ง่ายมาก สิ่งที่คิดถึงที่สุดคือความเป็นหนึ่งเดียวของ IDE ทั้งสองตัว ถ้าเชื่อมฐานข้อมูลแล้วสร้างฟอร์ม ก็กรอกข้อมูลและทำ validation ได้ทันที ภายในไม่กี่วันก็พัฒนาไปเป็น UI ที่สะท้อนความต้องการของโปรเจกต์ได้แล้ว ทุกวันนี้กลับต้องใช้ความระมัดระวังในการออกแบบและคิดมากขึ้นว่า UI, API และ backend จะเชื่อมกันได้ดีจริงหรือไม่ รู้สึกว่าสิ่งที่ต้องการไม่ใช่แค่ AI มาสร้างโค้ด UI แต่ยังต้องการเครื่องมือที่ให้เราวาดโค้ดด้วยภาพและสร้างโปรแกรมผ่าน UI โดยตรงอยู่ดี ถ้าใครทำ WYSIWYG tool ดี ๆ สำหรับ JUCE ออกมาได้ ยุคทองคงกลับมาอีกครั้ง

    • ฟังดูอาจตลก แต่ทุกวันนี้เราก็ใช้ html form ในลักษณะนี้กันอยู่ มันเรียบง่ายและได้ผล

  • สมัย DOS จะมีอาร์เรย์ไบต์สำหรับแสดงตัวอักษรและอาร์เรย์แอตทริบิวต์สี และฮาร์ดแวร์จะวาดสิ่งเหล่านี้ให้โดยตรง เขียนค่าใส่ address ในหน่วยความจำก็ขึ้นจอทันที จึงเร็วกว่าเทอร์มินัล serial ที่ช้าหรือระบบที่ใช้ ANSI command มาก การที่ Emacs รันบนเทอร์มินัลของ Sun workstation ได้ก็เลยหลีกเลี่ยงไม่ได้ที่จะช้า และนี่เองคือเหตุผลที่ TUI ค่อย ๆ หายไป

    • โครงสร้างในตอนนั้นดูสะดวกกว่าด้วยซ้ำ สงสัยว่ามีวิธีปรับขนาดหน้าจอให้ยืดหยุ่นอย่างไร