- Đầu những năm 1990, các IDE dựa trên văn bản đã cung cấp những tính năng xuất sắc ngay cả trên phần cứng hạn chế
- Dòng Borland Turbo, từng là IDE tiêu biểu thời đó, có tô sáng cú pháp, tích hợp trình biên dịch, gỡ lỗi, trợ giúp và một môi trường sánh ngang IDE hiện đại
- Trên Linux, Vim và Emacs có khả năng tùy biến cao, nhưng nhược điểm là khó học và không trực quan với người mới bắt đầu
- Gần đây, TUI (giao diện văn bản) và các tính năng IDE đang dần hồi sinh nhờ các công nghệ mới như LSP, nhưng vẫn thiếu sự liền mạch như mức độ của thập niên 90
- Ưu điểm của TUI IDE là truy cập từ xa, tiêu tốn ít tài nguyên và sự tự do của mã nguồn mở; ngược lại, IDE hiện đại nổi bật với hiện tượng phình to do bổ sung tính năng
Mở đầu: Ký ức về IDE dựa trên văn bản đầu những năm 1990
- Vào cuối thập niên 1980 đến đầu thập niên 1990, tác giả đã trải nghiệm lại các môi trường phát triển cũ bằng DOSBox và thấy thú vị khi so sánh với hiện tại
- Các IDE dựa trên văn bản thời đó, dù bị giới hạn bởi phần cứng, vẫn có rất nhiều tính năng
- Sau đó, phần lớn những tính năng ấy đã biến mất trong thời gian dài cùng với sự trỗi dậy của hệ điều hành cửa sổ, và chỉ gần đây một phần mới xuất hiện trở lại
Các trình soạn thảo ban đầu và môi trường TUI
- Phần lớn chương trình DOS trong thập niên 1990 sử dụng Text User Interface (TUI) toàn màn hình, hỗ trợ cửa sổ dạng văn bản, màu sắc, bóng đổ, thậm chí cả chuột
- Mỗi chương trình có thiết kế khác nhau, nhưng nhờ cách vận hành tương tự nhau nên có thể học rất nhanh
- MS-DOS từ phiên bản 5 (1991) đã cung cấp trình soạn thảo TUI tích hợp, nhưng phải thoát khỏi trình soạn thảo để biên dịch/chạy, rồi khi mở lại phải tìm lại vị trí đang làm việc, khá bất tiện
- Cũng có những công cụ dựa trên TSR (chương trình thường trú) như SideKick Plus (1984), giúp chỉnh sửa mã và build hiệu quả trên các OS chưa có đa nhiệm
- Ngay từ giữa đến cuối thập niên 1980, các IDE đầu tiên như Turbo Pascal, QuickBASIC đã xuất hiện và mang lại trải nghiệm phát triển tích hợp
Dòng Borland Turbo: đỉnh cao của IDE tích hợp
- Borland Turbo C++, Turbo Assembler, Turbo Pascal... dành riêng cho từng ngôn ngữ cụ thể, nhưng cung cấp TUI toàn màn hình cùng các tính năng mạnh mẽ
- Các tính năng chính:
- Tô sáng cú pháp giúp tăng khả năng đọc mã
- Tích hợp trình biên dịch cùng cảnh báo/chẩn đoán
- Cung cấp hệ thống dự án/build và nhiều cửa sổ
- Trình gỡ lỗi (breakpoint, call stack, v.v.)
- Trợ giúp tích hợp/tài liệu tham khảo
- Tất cả các tính năng này tạo nên một môi trường tự chủ và trực quan ngay cả khi đầu những năm 90 chưa có Internet
So sánh với môi trường Linux thời đó
- Linux khi ấy cũng chủ yếu dùng công cụ dựa trên văn bản, nhưng TUI toàn màn hình không phổ biến
- Vim, Emacs được sách và cộng đồng khuyên dùng có thể mở rộng mạnh về mặt chức năng, nhưng với người mới thì không thân thiện và thiếu trực quan
- Ví dụ, Emacs gặp các vấn đề như cửa sổ đơn điệu, màu sắc hạn chế, hỗ trợ chuột không ổn định, cùng giao diện menu khó và lạ
- Trong khi đó, các IDE như Borland Turbo C++ cho phép tạo một chương trình “Hello World” và khám phá môi trường chỉ sau vài phút, ngay cả khi không có kiến thức nền trước đó
IDE dựa trên văn bản ngày nay
- Ngày nay, những môi trường gần với TUI IDE xưa nhất là RHIDE, Free Pascal, QB64
- RHIDE gần như giống hệt Turbo C++, nhưng chỉ dành cho DOS và đã ngừng phát triển
- Free Pascal hỗ trợ môi trường Unix, cung cấp một môi trường tích hợp mạnh mẽ với máy tính, bảng ASCII tích hợp, v.v.
- QB64 trông giống TUI nhưng thực chất là mô phỏng GUI và không thể chạy trong terminal
- Free Pascal và QB64 vẫn được phát triển cho tới gần đây, nhưng độ phổ biến với số đông thấp vì gắn với các ngôn ngữ cũ
IDE console hiện đại đúng nghĩa
- Trong các môi trường phát triển tích hợp dựa trên văn bản hiện đại, Neovim, Doom Emacs, Helix là những cái tên nổi tiếng
- Nhờ nhiều plugin đa dạng, chúng mang lại trải nghiệm ở mức IDE, nhưng vẫn thiếu sự tích hợp theo từng ngôn ngữ và tính trực quan như dòng sản phẩm Borland
- Gần đây GNU Nano cũng được chú ý như một trình soạn thảo TUI đơn giản, nhưng vì không có tính năng IDE, nó gợi cảm giác giống WordStar
- Rốt cuộc, các trình soạn thảo console ngày nay либо chưa đạt đến mức trải nghiệm của thập niên 90, либо chỉ mới vất vả khôi phục lại các tính năng của 30 năm trước
Vì sao vẫn cần TUI IDE
- Dù tính năng remote của VSCode rất mạnh, TUI IDE vẫn có lợi thế vì có thể dùng ngay sau khi SSH vào máy từ xa
- Hơn nữa, tiện ích mở rộng remote của VSCode không phải mã nguồn mở, và trên một số OS (như FreeBSD) nó không hoạt động nên vẫn có giới hạn
- TUI IDE tiêu tốn ít tài nguyên hơn và đặc biệt hữu ích trong môi trường từ xa
Hiện tượng phình to và "Bloat"
- Borland Turbo C++ bao gồm mọi tính năng nhưng khi cài đặt chỉ cần dưới 9MB và có thể chạy trong 640KB RAM
- Doom Emacs hiện nay cần hơn 500MB, còn các IDE hiện đại có thể lên tới vài GB, khiến tình trạng phình to trở nên nghiêm trọng
- VSCode ở mức 350MB là khá nhẹ, nhưng vì dựa trên Electron nên mức tiêu thụ tài nguyên hệ thống thực tế vẫn lớn
- Có những tiến bộ như tính năng và refactoring, nhưng mức độ đổi mới so với 30 năm trước vẫn còn hạn chế
- Hỗ trợ lập trình bằng AI là thay đổi gần đây, nhưng trên thực tế chủ yếu vẫn là cung cấp dịch vụ từ xa
Kết luận
- Tác giả hiện vẫn sử dụng nhiều môi trường phát triển khác nhau như Doom Emacs, Vim, VSCode, IntelliJ tùy theo hoàn cảnh
- Trải nghiệm phát triển tích hợp trọn khối và hiệu quả mà TUI IDE cách đây 30 năm mang lại tạo nên sự đối lập rõ rệt với sự phình to và phân mảnh của IDE hiện đại
- Giá trị và tiềm năng của IDE dựa trên văn bản vẫn còn nguyên, và việc chúng có tiếp tục tiến hóa, hồi sinh hay không vẫn là điều đáng để theo dõi
1 bình luận
Ý kiến trên Hacker News
Rất sốc khi nhận ra Visual Basic từng là số một trong lĩnh vực lập trình đồ họa. Ngày xưa chỉ trong một ngày là có thể phát triển rất nhanh một ứng dụng GUI mức trung bình. C# WinForms là thứ gần nhất với trải nghiệm đó, nhưng những công cụ về sau đều đáng tiếc ở chỗ không tính đến góc nhìn của lập trình viên cá nhân. Có đề xuất một mô hình phát triển mới mạnh mẽ hơn là phát triển bằng giọng nói/lời nói (SDD/VDD). Hy vọng có thể thoát khỏi nỗi khổ phải gõ quá nhiều, và việc tương tác với AI trở nên tự nhiên như trò chuyện với đồng nghiệp. Tuy vậy, để thực sự làm được điều đó thì các mô hình AI phải nhanh hơn rất nhiều
Delphi khi đó còn vượt trội hơn cả Visual Basic, và đến giờ vẫn dùng được. Lazarus cũng vẫn còn tồn tại. Thực tế thì C# WinForms là thứ gần nhất với trải nghiệm Delphi
Tôi cảm thấy Qt Creator mang lại trải nghiệm tương tự VB6. Không biết bạn đã từng dùng thử chưa
Tôi nghĩ Emacs vẫn cung cấp đầy đủ tất cả những đặc điểm này. Chỉ là điều tác giả gọi là “phi truyền thống” thực ra xuất phát từ những quy ước mà họ không quen. Emacs hoàn toàn tự tài liệu hóa và có tính tương tác. Giao diện dạng văn bản tốt nhất tôi từng dùng là Magit bên trong Emacs (https://magit.vc/). Tôi ước nhiều phần khác của Emacs cũng được như Magit. Dù IDE có khác, tôi vẫn dùng Emacs làm git client
Emacs là một công cụ có lịch sử lâu đời, tồn tại từ trước khi Apple phát triển các phím tắt cmd-z/x/c/v. Thời đó, các phím tắt kiểu Wordstar là chủ đạo trong các trình soạn thảo của lập trình viên, ví dụ như phần lớn sản phẩm của Borland. Ngày nay ít người biết rằng đã từng có những IDE xuất sắc cách đây 30~40 năm. Ví dụ, Apple MPW (1986) là một trình soạn thảo GUI trong đó mọi cửa sổ đều là Unix shell, có thể điều khiển cửa sổ và thao tác chỉnh sửa bằng shell script, đồng thời còn tích hợp cả hệ thống quản lý mã nguồn. Gõ lệnh rồi nhấn option-Return thì một cửa sổ 'Commando' dạng GUI sẽ hiện ra để chọn mọi tùy chọn. Apple Dylan (1992-1995) là một IDE mạnh mẽ theo phong cách Lisp/Smalltalk, còn THINK Pascal và C (1986), Metrowerks Codewarrior (1993), Macintosh Allegro Common Lisp cũng đều rất đột phá. Thật đáng kinh ngạc khi những IDE tinh vi như vậy lại được hiện thực trong môi trường M68000 8~40MHz với RAM 2~32MB của thập niên 80 đến đầu 90
Về ý kiến Emacs tự tài liệu hóa và có tính tương tác, thực tế là khi mới tiếp xúc tôi thậm chí còn không dễ dàng biết cách lưu tài liệu. Có thể nó vẫn tốt hơn vi, nhưng chưa đủ để người mới dùng ngay mà không cần giải thích
Magit thật sự đáng kinh ngạc. Tôi tự hỏi làm sao người ta nghĩ ra được mô hình dữ liệu như vậy. Nó cho cảm giác như đã hiện thực được thứ gì đó còn vượt quá mô hình dữ liệu của git. So với sự rời rạc của git porcelain, Magit có một cấu trúc rất bài bản
IDE kiểu Turbo-Vision chỉ cần biết vài phím như Alt, Tab, Return, Esc và phím mũi tên là có thể nắm được hầu hết chức năng, trong khi Emacs không có tính nhất quán thao tác như vậy
Tôi đã dùng Emacs hơn 25 năm nên giờ hoàn toàn quen thuộc với nó rồi
Turbo Pascal thật sự đáng kinh ngạc. Ban đầu tôi ngần ngại dùng vì đó là một bản Pascal không chuẩn, nhưng các công cụ cạnh tranh thì quá đắt và kém mạnh hơn. Sau khi trực tiếp dùng thử thì tôi hoàn toàn bị chinh phục. Tôi đã trải nghiệm một IDE nhanh và trực quan trên IBM PC. Trong số các IDE hiện đại, Intellij đã vượt trội hơn hẳn các đối thủ suốt hơn 25 năm. Tôi đã không dùng sản phẩm Microsoft từ lâu nên không có kinh nghiệm với VSCode. Eclipse thì chậm, thiếu trực quan và đầy lỗi. JetBrains là một trong số ít công ty hiếm hoi vẫn giữ đúng sứ mệnh và duy trì được sự xuất sắc. Việc họ liên tục hỗ trợ nhiều ngôn ngữ, tiêu chuẩn và công cụ mà vẫn giữ được chất lượng vượt trội thật ấn tượng
Visual Studio vẫn hỗ trợ WinForms và trình thiết kế form đồ họa, nên rất giống trải nghiệm Delphi cuối thập niên 90. WinForms vốn là bản mô phỏng VCL gần như công khai
Tuy vậy, vấn đề sử dụng tài nguyên là rất lớn. Trên desktop đám mây tôi không thể dùng neovim nên phải dùng ideavim, nhưng dù có 4 nhân CPU và 16GB RAM, chỉ cần mở vài project là đã giật lag. Có thể phần mềm bảo mật của công ty cũng ảnh hưởng, nhưng VSCode thì không vật vã đến mức đó
IDE của Turbo Pascal đi trước thời đại và trên CP/M, đặc biệt là Z-80, nó cũng tuyệt vời như phép màu. Nó vượt xa mọi thứ cùng thời
Bài viết là từ năm 2023 nên có lẽ cần cập nhật năm trong tiêu đề thành 32 năm trước mới đúng. Điều đáng tiếc nhất của TUI ngày nay là các framework bất đồng bộ thường bỏ qua thao tác nhấn phím. TUI trước năm 2000 sẽ xếp hàng thao tác phím ngay cả khi hệ thống chưa sẵn sàng. Ngược lại, các framework TUI “dựa trên web” hiện đại sẽ bỏ hẳn phím nếu bạn nhấn trước khi event listener được đăng ký. Ngoài chuyện đó ra thì TUI vẫn hoạt động rất tốt. Neovim, nhờ LSP và plugin, đang có bộ tính năng tốt nhất từ trước đến nay. Dù không phải TUI dựa trên chuột, nó vẫn rất mạnh về năng suất
Trên terminal thật thời DOS có bộ đệm nhập phím, và những người đã quen giao diện thường gõ trước nhiều phím để đi nhanh hơn cả UI. Đầu vào được xếp trong buffer rồi xuất hiện và biến mất rất nhanh trên màn hình. Cấu trúc này vẫn có thể hiện thực bằng framework hiện đại, nhưng cần làm cẩn thận
Tôi đã có trải nghiệm như vậy từ năm 1984, nên phạm vi có thể lên đến 41 năm trước. Những dự án ban đầu mới là dòng chính cho đến khi các sản phẩm GUI như Visual Studio 1.0 hay NetBeans xuất hiện. Trước vim (1991), nhưng vẫn có cảm giác muốn cửa sổ nổi thay vì ncurses
Hiện tượng bỏ qua thao tác phím kiểu này khó chịu đến phát điên. Ngày xưa có thể dùng máy tính với tốc độ cực cao bằng các tổ hợp phím tắt nhanh, còn giờ thì như đang đi trong mật đường đặc quánh
Tôi không hình dung chính xác 30 năm trước là mốc nào, vì tôi đã hy vọng sẽ có system browser của Smalltalk dạng GUI, nhưng lại chỉ thấy TUI DOS xuất hiện nên hơi thất vọng. Bù lại, việc hồi tưởng về Turbo C/Pascal, MS C 4.0 và CodeView làm tôi thấy rất vui. Những công cụ này còn dùng được cả ở chế độ 43 dòng, 50 dòng
Tôi nghĩ nếu phụ thuộc quá mức vào một IDE cụ thể thì sẽ có hại cho cả năng lực cạnh tranh của bản thân lẫn mã nguồn. Nếu nói về IDE terminal, thì GNU/Linux terminal mới là ứng dụng tốt nhất. Dùng nhiều terminal trong một tiling window manager sẽ tối đa hóa năng suất. Khả năng scaling hiện đại trên màn hình lớn cũng rất tuyệt về mặt công thái học cho lập trình viên
Tôi vẫn đang phát triển và sử dụng một trình soạn thảo/IDE dạng văn bản do chính mình tạo ra (https://github.com/alefore/edge). Gần đây tôi cũng viết lại những kết luận rút ra sau 10 năm phát triển (https://github.com/alefore/weblog/blob/master/edge/README.md)
Thời kỳ hoàng kim của DOS, ký tự được quản lý bằng một mảng byte, còn thuộc tính như màu nền, màu chữ thì bằng mảng riêng. Nếu muốn ghi 'A' vào một vị trí cụ thể thì chỉ cần ghi 0x41 vào địa chỉ bộ nhớ. Có một ít wait state, nhưng vẫn nhanh hơn rất nhiều so với việc xuất ra terminal 9600 baud bằng lệnh ANSI. Emacs có thể dùng trên terminal serial chậm hoặc terminal emulator của Sun workstation, và đó cũng là bối cảnh khiến TUI dựa trên shell biến mất
Dù bài viết này tập trung vào IDE dạng văn bản, tôi nghĩ nó cũng áp dụng cho các IDE truyền thống như Visual Basic hay Delphi. Với người mới bắt đầu, thực sự cần một IDE cho Python. Không phải dạng văn bản mà là kiểu Visual Basic, mọi thứ đều được tích hợp và dễ khám phá, điều này rất quan trọng. Sẽ tốt hơn nếu có sẵn GUI builder và debugger. Trình soạn thảo mã chỉ cần có syntax highlighting, tự động hoàn thành và khả năng điều hướng mã dễ dàng là đủ. Ví dụ, đặt một nút vào cửa sổ rồi double-click trong GUI editor để nhảy ngay đến mã xử lý của nút đó. Trước đây đã từng có người tụ tập bàn về một ý tưởng tương tự, nhưng rồi tranh cãi quá lớn về việc nên dùng framework GUI nào như Pyside, Dear PyGui hay nền web, nên cuối cùng câu chuyện chìm xuồng. Nhắc đến Free Pascal thì cũng phải nhắc Lazarus (https://www.lazarus-ide.org/), bản sao của Delphi. Nó rất xuất sắc và vẫn đang được phát triển tích cực. Tuy nhiên, Object Pascal giờ không còn được dùng nhiều nên có phần hơi cũ
Tôi hoàn toàn đồng ý rằng cần một IDE Python tích hợp cho người mới theo kiểu Visual Basic, có GUI builder và debugger tích hợp. Từng có một IDE Python tên là Boa Constructor (https://boa-constructor.sourceforge.net/) vào năm 2000, nhưng nó không trở nên phổ biến
Gần đây tôi cũng quay video làm một ứng dụng nhỏ bằng VB3 trên Windows 3.11, và tweet đó đã “viral”. Cuối cùng điều quan trọng không phải là TUI, mà là trải nghiệm sử dụng tích hợp
Với tôi, Lazarus mới là chuẩn mực của một IDE đích thực. Lazarus được viết bằng chính Lazarus, tác giả trực tiếp dùng rất nhiều sản phẩm của mình và cung cấp ví dụ lẫn hướng dẫn. Nó cũng rất tuyệt để dạy trẻ em lập trình. Giống như Microsoft Visual Studio, nó tích hợp tagging, tìm kiếm, trợ giúp, tài liệu API, ví dụ widget, thư viện... Các IDE khác không có mức độ tích hợp như vậy, còn Xcode dù tự nhận là IDE nhưng so với Lazarus thì không đáng kể. Tôi quá bướng bỉnh nên đã dành suốt 6 tháng tự làm một framework frontend UI bằng Go thay vì JS, và hy vọng một ngày nào đó cũng có thể làm được cả IDE
IDE của Borland là một niềm vui thực sự. Đến giờ tôi vẫn chưa tìm được công cụ hiện đại nào đem lại trải nghiệm tương đương. Có thể đúng là có chút hoài niệm, nhưng việc cố tình kiếm cớ dùng Free Pascal chỉ để gọi lại giao diện đó vẫn rất thú vị. Tôi cũng thích Pascal. Tôi cũng dùng Sam và Acme của Plan 9, nhưng đó là editor chứ không phải IDE. Tôi thích những công cụ giúp mình suy nghĩ mà không quấy rầy. Có rất nhiều điều cần học từ các TUI ngày xưa. Ví dụ, việc mở shell từ menu File để chạy thứ gì đó rồi quay lại vẫn hoàn toàn chấp nhận được, thậm chí còn rất ngầu. Và còn keybinding nữa! TUI ngày xưa vay mượn rất nhiều từ mẫu phím tắt của WordStar, đến mức nó đã ăn sâu vào cơ bắp của tôi, còn Emacs thì cho cảm giác như đang gõ phím với găng tay lò nướng. Tôi đã gắn bó rất lâu với joe (bí danh jstar). Giờ là lúc khởi động Dr. DOS VM, thử cả Advent of Code, và cố tình mở một bữa tiệc hoài niệm theo cách kém hiệu quả nhất
Phần mềm “chuyên nghiệp” thời DOS, như Emacs, được thiết kế để người dùng gần như sống hoàn toàn bên trong phần mềm đó. Bạn hòa làm một với cỗ máy và dùng phím tắt thành thạo như một nghệ sĩ organ. Tôi nhớ cảnh nhân viên Fry’s Electronics thao tác TUI nhanh đến mức xong việc và in kết quả ra trước cả khi màn hình kịp hiện đầy đủ
Tôi tò mò WordStar binding là gì và nó hay ở điểm nào. Tôi quan tâm đến việc nghiên cứu lịch sử của kiểu mẫu này cũng như ưu điểm của từng cách tiếp cận
Tôi đồng cảm với bài viết tuyệt vời này. Tôi cũng đang tự phát triển một trình soạn thảo mã tui kiểu Turbo Pascal trong thời gian cá nhân. Sau này tôi dự định tích hợp cả make và lldb
Tôi thích nhiều mặt của Plan 9, nhưng hoàn toàn không thể làm quen với UI thiên về chuột của Acme. Một UI đòi hỏi ngắm chuột chính xác sẽ rất bất tiện nếu dùng lâu hoặc với người có khuyết tật
Bộ đôi djgpp và vi for dos 1991 là số một
Tôi đã dùng cả Visix Vibe, một IDE Java, lẫn Delphi, và cả hai đều giúp tăng năng suất khủng khiếp. Tôi có thể dễ dàng dự đoán lịch trình cho khách hàng từ lúc phát triển UI, nối logic cho đến chuẩn bị triển khai. Điều tôi nhớ nhất là mức độ tích hợp của cả hai IDE. Kết nối cơ sở dữ liệu rồi sinh form là có thể nhập liệu và kiểm tra ngay, và chỉ trong vài ngày đã có thể phát triển thành một UI phản ánh yêu cầu dự án. Ngày nay, để UI, API và backend liên kết đúng cách thì cần thiết kế và suy nghĩ cẩn thận hơn nhiều. Tôi cảm thấy thứ cần thiết không phải chỉ là AI sinh mã UI, mà vẫn là các công cụ cho phép trực tiếp “vẽ” mã một cách trực quan và tạo chương trình như một UI. Nếu ai đó làm ra một công cụ WYSIWYG tử tế cho JUCE, tôi nghĩ thời hoàng kim sẽ quay lại
Thời DOS, người ta có một mảng byte biểu diễn ký tự và một mảng thuộc tính màu sắc, còn phần cứng sẽ trực tiếp vẽ chúng. Chỉ cần ghi giá trị vào địa chỉ bộ nhớ là nó hiện ngay lên màn hình, nên nhanh hơn rất nhiều so với terminal serial chậm hay cách dựa trên lệnh ANSI. Khi dùng Emacs trên terminal của Sun workstation thì vốn dĩ không thể nhanh được, và đó là lý do TUI biến mất