30年前に私たちが持っていて、いまは失ってしまったIDEたち

 (blogsystem5.substack.com)
4 ポイント 投稿者 GN⁺ 2025-10-19 | 1件のコメント | WhatsAppで共有
  • 1990年代初頭のテキストベースIDEは、制約の多いハードウェア上でも優れた機能を提供していた
  • 当時を代表するIDEだったBorland Turboシリーズは、構文ハイライト、コンパイラ統合、デバッグ、ヘルプなど、現代のIDEに匹敵する環境を備えていた
  • LinuxのVimとEmacsはカスタマイズ可能だったが、学習が難しく、初心者には直感的ではないという限界があった
  • 最近はTUI（テキストUI）やIDE機能が、LSPなどの新技術の登場によって徐々に復活しつつあるが、それでも90年代レベルの一体感にはまだ及ばない
  • TUI IDEの利点は、リモート接続、軽いリソース消費、オープンソースの自由さなどにあり、一方で現代のIDEは機能追加に伴う肥大化が目立つ

序論: 1990年代初頭のテキストベースIDEの記憶

  • 1980年代後半から1990年代初頭にかけて、筆者はDOSBoxで昔の開発環境を再体験し、現代と比較する楽しさを感じた
  • 当時のテキストベースIDEは、ハードウェア上の制約にもかかわらず、多くの機能を備えていた
  • その後、大半の機能はウィンドウ型OSの台頭とともに長いあいだ姿を消し、最近になってようやく一部が再登場している

初期エディタとTUI環境

  • 1990年代の大半のDOSプログラムは、**フルスクリーンのText User Interface（TUI）**を使い、テキストベースのウィンドウ、カラー、影、さらにはマウスまでサポートしていた
  • 各プログラムでデザインは異なっていたが、似た操作体系のおかげですぐに習得できた
  • MS-DOSはバージョン5（1991）から内蔵TUIエディタを提供したが、コンパイルや実行のためにエディタを終了しなければならず、再び開くと作業位置を探し直す不便さがあった
  • SideKick Plus（1984）のような**TSR（常駐プログラム）**ベースのツールもあり、これはマルチタスクができなかったOS上で効率的なコード編集とビルドを可能にしていた
  • すでに1980年代中後半には、Turbo Pascal、QuickBASICなど初期のIDEが登場し、統合開発体験を提供していた

Borland Turboシリーズ: 統合IDEの頂点

  • Borland Turbo C++、Turbo Assembler、Turbo Pascalなどは特定言語専用だったが、フルスクリーンTUIと強力な機能を提供していた
  • 主な機能:
    • 構文ハイライトによるコード可読性の向上
    • コンパイラ統合と警告/診断
    • プロジェクト/ビルドシステムの提供とマルチウィンドウ
    • デバッガ（ブレークポイント、コールスタックなど）
    • 内蔵ヘルプ/リファレンスマニュアル
  • これらすべての機能は、90年代初頭のインターネットなしの時代でも、自己完結的で直感的な環境を提供していた

当時のLinux環境との比較

  • Linuxでもテキストベースのツールが主流だったが、フルスクリーンTUIは一般的ではなかった
  • 書籍やコミュニティで勧められていたVim、Emacsは、機能的には拡張可能だったものの、初心者の立場では不親切で直感性に欠けていた
  • たとえばEmacsには、飾り気のない画面、限られた色使い、不安定なマウス対応、難しく見慣れないメニューインターフェースなどの問題があった
  • Borland Turbo C++などのIDEは、事前知識がまったくなくても数分で「Hello World」プログラムを作り、環境を探検できた

今日のテキストベースIDE

  • 現代では、過去のTUI IDEに最も近い環境としてRHIDE、Free Pascal、QB64などがある
    • RHIDEはTurbo C++とほぼ同じだが、DOS専用で開発が停止している
    • Free PascalはUnix環境をサポートし、内蔵電卓、ASCIIテーブルなどを備えた強力な統合環境を提供する
    • QB64はTUIのように見えるが、実際にはGUIシミュレーションであり、ターミナル上では実行できない
  • Free PascalとQB64はいずれも最近まで開発が続いているが、古い言語が前面に出ているため大衆的人気は弱い

真の現代的コンソールIDE

  • 最新のテキストベース統合開発環境としては、Neovim、Doom Emacs、Helixなどが有名だ
  • これらは多様なプラグインのおかげでIDE級の体験を提供するが、Borland製品群のような言語別の統合性や直感性には欠ける
  • 最近はGNU NanoなどもシンプルなTUIエディタとして注目されているが、IDE機能がないためWordStarに近い感覚だ
  • 結局のところ、今日のコンソールエディタは90年代の体験レベルに及ばないか、30年前の機能をようやく取り戻している段階にある

TUI IDEの必要性

  • VSCodeのリモート機能が優れていても、TUI IDEはリモートマシンにSSH接続した直後にそのまま使えるという点で有利だ
  • しかもVSCodeのリモート拡張機能はオープンソースではなく、一部のOS（FreeBSDなど）では動作しないため制約がある
  • TUI IDEはリソース消費が少なく、リモート環境でより有用である

肥大化と「Bloat」現象

  • Borland Turbo C++は全機能を含めても、インストール時に9MB未満、640KB RAMで動作可能だった
  • 現行のDoom Emacsは500MB以上で、現代のIDEは数GBに達するものもあり、肥大化が深刻になっている
  • VSCodeは350MBでかなり軽量だが、Electronベースのため実際のシステムリソース消費は大きい
  • 機能やリファクタリングなど一部の進歩はあるものの、30年前と比べて革新は限定的だ
  • AIコード補完などは最近の変化だが、実態としてはリモートサービス提供が主流である

結論

  • 筆者は状況に応じて、Doom Emacs、Vim、VSCode、IntelliJなどさまざまな開発環境を活用している
  • 30年前のTUI IDEが提供していた一体型の開発体験と効率性は、現代IDEの肥大化と断片化と鮮明な対比をなしている
  • テキストベースIDEが持つ価値と潜在力は今なお有効であり、その進化と復活の行方は今後も見守る必要がある

関連記事

1件のコメント

 
GN⁺ 2025-10-19
Hacker Newsのコメント

  • Visual Basicがグラフィックプログラミング分野では最高だったことに大きな衝撃を受けた。昔は1日あれば中程度のGUIアプリケーションを非常に素早く開発できた。C# WinFormsがそれに最も近かったが、その後のツールはいずれも個人開発者の立場を考慮していないのが残念だ。新しい強力な開発パラダイムとして、音声／スピーチベースの開発（SDD/VDD）を提案したい。大量のタイピングの苦痛から解放され、AIとのやり取りが同僚との会話のように自然になってほしい。ただし、これをきちんと実現するにはAIモデルがもっとずっと高速になる必要がある

    • Delphiは当時でもVisual Basicより優れていたし、今でも使える。Lazarusもまだ存続している。実際、C# WinFormsがDelphi体験に最も近い

    • Qt CreatorがVB6に近い体験を提供していると感じた。使ったことがあるのか気になる

  • Emacsは今でもこうした特徴をすべて備えていると思う。ただし、著者が「非伝統的」だと主張する点は、自分が慣れていない慣習だからというだけだ。Emacsは完全に自己文書化されていて、対話的でもある。私がこれまで使った中で最高のテキストベースのインターフェースは、Emacs内のMagitだ（https://magit.vc/）。Emacsのもっと多くの部分がMagitのよ…

    • EmacsはAppleがcmd-z/x/c/vショートカットを開発する以前から存在していた歴史あるツールだ。当時、プログラマ向けエディタのショートカットとしてはWordStar系（例: ほとんどのBorland製品）のキーバインドが主流だった。今ではあまり知られていないが、30〜40年前には優れたIDEがあった。たとえばApple MPW（1986）は、すべてのウィンドウがUnixシェルになるGUIエディタで、シェルスクリプトでウィンドウや編集作業を制御でき、ソースコード管理システムも内蔵していた。コマンドを入力してOption-Returnを押すと、GUIベースの「Commando」ウィンドウが開き、すべてのオプションを選べた。Apple Dylan（1992-1995）はLisp/Smalltalkスタイルの強力なIDEで、THINK PascalおよびC（1986）、Metrowerks Codewarrior（1993）、Macintosh Allegro Common Lispなども革新的だった。80年代〜90年代初頭の8〜40MHz M68000、2〜32MB RAM環境で、これほど洗練されたIDEが実現されていたことに驚かされる

    • Emacsが自己文書化されていて対話的だという意見については、実際には最初に触れたとき、文書をどう保存するかすら簡単には分からなかった。viよりはましだろうが、初心者が説明なしでそのまま使うには不十分だ

    • Magitは本当に驚異的だ。どうやってこんなデータモデルを思いついたのか気になる。gitのデータモデルをさらに超えるものを実装したように感じる。git porcelainの崩壊ぶりに比べて、Magitは体系的な構造を持っている

    • Turbo-VisionスタイルのIDEはAlt、Tab、Return、Esc、方向キーなど、いくつか知っていれば大半の機能を把握できるのに対し、Emacsにはそうした統一的な操作性がない

    • 25年以上Emacsを使ってきたので、もう完全に体に染みついている

  • Turbo Pascalは本当に驚くべきものだった。最初は非標準のPascal実装なので使うのをためらったが、競合ツールはあまりに高価で、しかも非力だった。実際に使ってみて完全に魅了された。IBM PCで高速かつ直感的なIDEを体験した。モダンIDEではIntellijが25年以上にわたって競合よりはるかに優れている。Microsoft製品はずっと使っていないのでVSCodeの経験はない。Eclipseも遅く、直感的でなく、バグも多かった。JetBrainsは使命を守りつつ卓越性を維持している稀有な会社だ。多様な言語、標準、ツールを絶えずサポートしながらも、卓越した品質を保っているのが印象的だ

    • Visual Studioは今でもWinFormsとグラフィカルなフォームデザイナをサポートしており、90年代後半のDelphi体験と非常によく似ている。WinFormsがVCLを露骨に模倣したからだ

    • ただし、リソース使用量の問題は大きい。クラウドデスクトップでneovimが使えずideavimを使うことになったが、4コア、RAM 16GBでも複数プロジェクトを開くだけでもたつく。会社のセキュリティソフトの影響もあるだろうが、VSCodeはそこまでつらくない

  • Turbo Pascal IDEは時代を先取りしていたし、CP/M（特にZ-80）でも魔法のように優れていた。当時の何よりも優れていた

  • 記事は2023年のものなので、タイトルの年数を32年前に更新するのが正しそうだ。最近のTUIで最も残念なのは、非同期フレームワークがキー入力をしばしば無視してしまうことだ。2000年以前のTUIでは、システムの準備ができていなくてもキー入力を待機させていた。一方、最新の「Webベース」TUIフレームワークでは、イベントリスナーが登録される前にキーを押すと完全に無視される。ほかの問題を除けば、TUIは今でも十分うまく機能している。NeovimはLSPとプラグインのおかげで史上最高クラスの機能を誇る。マウスベースのTUIではないが、生産性の面では非常に優れている

    • DOS時代の実際の端末にはキー入力バッファがあり、インターフェースに慣れた人は複数のキーを先に入力してUIより先行していた。入力はバッファに積まれ、画面に一瞬で現れて消えるという体験があった。現代のフレームワークでもこの構造は実装可能だが、慎重に取り組む必要がある

    • 1984年にもこうした体験があったのだから、41年前まで含まれることになる。Visual Studio 1.0やNetBeansのようなGUI製品が出るまでは、初期のプロジェクト群が主流だった。vim（1991）以前だが、ncursesの代わりにフローティングウィンドウを求める感覚だった

    • こういうキー入力の無視は気が狂いそうなほど不便だ。昔は高速なショートカットの組み合わせでコンピュータをとてつもない速さで扱えたのに、今ではまるで粘つく糖蜜の中を歩いている気分だ

    • 30年前が具体的にいつなのか感覚がつかめなかったが、GUI Smalltalkのシステムブラウザが出てくることを期待していたところにDOS TUIが登場して残念だった。その代わりTurbo C/Pascal、MS C 4.0、そしてCodeViewを思い出して楽しくなった。これらのツールは43行、50行モードでも使えた

    • 特定のIDEに過度に依存すると、自分の競争力やコードにも悪影響があると思う。端末IDEの話をするなら、GNU/Linux端末こそ最高のアプリだ。タイル型ウィンドウマネージャで複数の端末を開いて使えば、生産性は最大化される。大画面での現代的なスケーリングは、開発者の人間工学の面でも優れている

  • 今でも自作のテキストベースのエディタ／IDE（https://github.com/alefore/…

  • DOS全盛期には、文字をバイト配列として、属性（背景、前景色など）も別の配列として管理していた。特定の位置に'A'を書きたければ、そのメモリアドレスに0x41を書くだけでよかった。wait stateは多少あったが、9600 baud端末でANSIコマンドを使って出力するよりはるかに速かった。Emacsは低速なシリアル端末やSunワークステーションの端末エミュレータでも使えたが、それがシェルベースTUIが消えた背景でもある

    • 昔の方式のほうがむしろ優れているように見える。画面サイズを変更するときにどう処理していたのか気になる

  • この記事はテキストベースIDEに焦点を当てているが、Visual BasicやDelphiのような伝統的IDEにも当てはまると思う。初心者にはPython向けIDEが本当に必要だと思う。テキストベースではなくVisual Basicスタイルで、すべてが統合され、発見しやすい構造であること（重要）。GUIビルダーとデバッガも内蔵されているとよい。コードエディタは構文ハイライト、自動補完、そして簡単なコード探索機能があれば十分だろう。たとえば、ウィンドウにボタンを置いてGUIエディタでダブルクリックすると、そのボタンのハンドラコードへすぐ移動できるような方式だ。以前、似たアイデアで人が集まって議論したことがあるが、どのGUIフレームワークを使うか（Pyside、Dear PyGui、Webベースなど）で意見が大きく割れて、議論は立ち消えになった。Free Pascalの話が出たので、Delphiを複製したLazarus（https://lazarus-ide.org/）にも触れるべきだ。非常に優れ… Pascalは今ではあまり使われておらず、やや古びた印象はある

    • 初心者向けのPython統合IDEとして、Visual Basicスタイル、GUIビルダー、内蔵デバッガが必要だという点には全面的に同意する。Boa Constructor（https://boa-constructor.sourceforge.net/）というPython IDEが2000年にあったが、普及はしなかった

    • 私も最近、Windows 3.11でVB3を使ってトイアプリを作る過程を動画に撮り、そのツイートが「バズった」。結局重要なのはTUIではなく、統合された使用体験なのだ

    • 私にとってLazarusこそ真のIDEの基準だ。LazarusはLazarus自身で作られており、作者たちが自分たちの製品を熱心に使い、サンプルやチュートリアルも提供している。子どもたちにプログラミングを教えるのにも優れている。Microsoft Visual Studioのように、タグ付け、検索、ヘルプ、APIドキュメント、ウィジェットのサンプル、ライブラリなどが統合されている。他のIDEにはこうした統合性がなく、XcodeもIDEとは言うもののLazarusに比べれば大したことはない。私は頑固すぎて、6か月もJSの代わりにGoでUIフロントエンドフレームワークを自作しているが、いつかIDEも作れたらと思っている

  • BorlandのIDEは本当に喜びそのものだった。いまだにあのレベルの体験を与えてくれる現代ツールは見つかっていない。もちろん多少のノスタルジーはあるだろうが、Free Pascalを使う口実をわざわざ作ってでも、あのインターフェースを呼び出すのが楽しい。Pascalも好きだ。Plan 9のSamやAcmeも使うが、これはIDEではなくエディタだ。私は自分の邪魔をせず、考えることを助けてくれる道具を好む。昔のTUIから学ぶべき点は多い。たとえば、Fileメニューからシェルを開いて何か実行し、それから戻ってくるというのも十分許容されるし、英雄的ですらあった。そしてキーバインドだ。昔のTUIはWordStarのショートカットパターンを多く取り入れていたが、あまりにも体に馴染んでいて、Emacsはオーブンミトンをはめてタイピングしているように感じる。長い間joe（jstarエイリアス）を愛用していた。さて、Dr. DOS VMを起動して、Advent of Codeにも挑戦し、わざと非効率にノスタルジーを楽しむ時間だ

    • DOS時代の「プロフェッショナル」ソフトウェア（Emacsなど）は、ユーザーがそのソフトウェアの中で完全に生活するよう設計されていた。機械と一体化し、オルガン奏者のようにショートカットを自在に操れた。Fry’s Electronicsの店員たちがTUIをあまりに速く扱い、画面が表示される前に仕事を終え、印刷物が出てくるのを見ていた記憶がある

    • WordStarバインディングとは何か、何が良いのか気になる。こうしたパターンの歴史や各方式の利点を研究することに興味がある

    • すばらしい文章に共感する。私も個人の時間でTurbo Pascalスタイルのtuiコードエディタを開発中だ。将来的にはmakeとlldbも内蔵する予定だ

    • Plan 9のいろいろな面は好きだが、Acmeのマウス中心UIにはどうしても慣れない。精密なマウス操作を要求するUIは、長時間使う場合や障害がある場合には非常に不便だったはずだ

    • djgppとvi for dos 1991の組み合わせが最高だった

  • Visix VibeというJava IDEとDelphiの両方を使ったことがあるが、どちらも生産性を大きく引き上げてくれた。顧客向けのUI開発、ロジックの接続、配布準備まで、容易にスケジュール予測ができた。特に恋しいのは、両IDEの統合性だ。データベースを接続してフォームを作成すれば、すぐに入力や検証が可能で、数日あればプロジェクト要件を反映したUIへと発展させられた。今ではUIとAPI、バックエンドがきちんと連携するかどうかについて、もっと綿密な設計と検討が必要になっている。AIがUIコードを生成するというレベルではなく、今なお視覚的にコードを直接描いてUIでプログラムを作る方式のツールが必要だと感じる。誰かがJUCE向けにまともなWYSIWYGツールを出せば、黄金期が戻ってくると思う

    • 笑うかもしれないが、今ではhtmlフォームをこういう形で使っている。シンプルで効果的だ

  • DOS時代には、文字を表すバイト配列と色属性の配列があり、ハードウェアがそれを直接描画していた。メモリアドレスに値を書けばそのまま画面に表示される仕組みだったので、低速なシリアル端末やANSIコマンドベースよりはるかに速かった。EmacsをSunワークステーションの端末で使うと、どうしても遅くならざるを得なかったため、TUIが廃れていったのだ

    • 当時の構造のほうがむしろ快適だった気がする。画面サイズを柔軟に変える方法が気になる