今時は、CUIもGUIも同じ調子でプログラミングしてしまうが、
前世期後半のコンピューティングの中で、UIが対話型のCUIから、ビデオゲーム型のGUIに変わった時に大きな変遷を遂げた。
その当時の対話型CUIの代表的なものはshellスクリプトで、ダイアグラムで図式化された通りにコードされ、ソースのあちこちで入力待ちする個所にecho とreadが散らばっていた。マルチウインドウっぽいcursesライブラリィを使ったものもあったが、大方はジャーナルリストの下に長いエントリーフィールドが１つあるだけのレイアウトばかり、と云うのもシリアル接続の端末をエスケープシーケンスでカーソル位置などを制御しているのに、朴念仁のカーネルやドライバーがログ（ディスクの空きは残り１ブロック！）を吐き出したり、同僚からのメッセージ「飯！」が飛んでくるだけで、viの画面ですら意味不な文字の羅列に成り果てるので、マルチユーザなUNIXの環境は実は地雷原同然のギスギスな環境でもあったのだ。
また当時の端末は８０行２５列のキャクター表示にブリンクや下線などの文字属性を少し付く程度の機能なので、小規模集積ICとメモリチップを並べて作られおり非常に高価であり、またその機能を考えると「個人で買う気になれるモノ」ではなかった。当時マイクロコントローラとビデオコントローラーの安価な組合せセットが出始めたので、これで端末を作れば安く作れるかもしれない。そう思った人が、自分用にビットマップ表示の端末を作ったのだ。マイクロコントローラのプログラムは自分で組み込むものなので、ワークステーション側でカーネルのログをバッファし、viの通信とは分けて、マルチウインドウ形式で端末に表示する様にハックしたのだろう。
同僚からのメッセージ「飯！」が飛んでくるだけで、viの画面が壊れるのにウンザリしていた人間は意外と多かったらしく、画面が壊れないと云うだけでもこのビットマップ表示の端末は注目されるに値するものだったが、マルチウインドウを操作するために３ボタンのマウスというデバイスも取り入れられ、従来のread文だけでは、プログラム同士の入力の奪い合いが始まってしまい、うまく切り分けできなかったので、誰かがまとめ役（WindowManager）になってもらい、座標入力と文字入力を切り分け、該当するウインドウの持ち主に配布してもらうことになった。これがX-Window ver1.0である。
当時ダブルフォルトぐらいしか使い道のないlongjmpのみがプログラミングとは非同期で処理分岐する方法であり、異なるプロセスであるWindowManagerから安定して入力メッセージを受信するには、受信ルーチンを１か所にした方が無難であり、GUIではプログラミング・スタイルが大きく変わることになった。
無理をすれば割り込みロジックを使い、疑似マルチスレッド化も可能だが、マルチスレッド対応のライブラリィなんてなかったし、仮にうまくいった様に見えても不定期にprintfの処理中に割り込まれているのかも？と気が付くまで、原因不明のハングアップに悩まされ続けることになっただろう。
C＋＋が生まれるのは２０年ぐらい先の未来なので、イベントハンドラはイベント分岐判定の巨大なswitch文としてハードコードされた。それは初期のWindowsも同じ。なぜイベント分岐判定をサブルーチンにしなかったのかと云えば、主メモリが数Mバイトと少ない上に、ちゃんとしたMMUが実装されていなかったので、スタックには数Kバイト程度しか割り振れず、イベント分岐判定を画面のメニュー構成に合わせ綺麗にサブルーチン化し、肝心の処理をサブルーチン・コールする時にはスタックの大半を消費していたりする間抜けが多かったからだ。その辺は同系列のCPUを使うUNIXのワークステーションも同じであった。
一方、menuプログラムがforkとexecを連打しバッチ処理を呼び出すCUIのままのプログラムも、メニューだけGUI化して生き残った。
しかし、やがてメニューとバッチ処理を一体化させるのに十分なメモリ容量が確保できたものの、HDDアクセスのオーバーヘッドが解消されない状態が続くと、一体化されたアプリと比較して、先のバッチ処理を呼び出す方式は何かボタンを押す度にHDDのアクセスランプが長く明滅する非常に応答性の悪いシロモノに成り果てることになるのだが、恐ろしいことにWindows Serverの時代になってもその子孫は生き延びるのであった。
という感じで当初のGUIはハードウェアの性能が貧弱だったこともあり、ボタンを押した後延々と待たされることになり・・・
とりあえず、カーソルを砂時計にして処理中をアピールしたり、処理時間を推定してプログレスバーを表示したりするようになる。
しかし、待機時間が長いという事実に変わりなかったのが、前世期後半のコンピューティングであった。
その反動で、今世紀のコンピューティングは、スループット（応答性の良さ）が第一の目的となった。
第一にインターネットの普及でサーバーの同時接続数が急激に増加し、まずはサーバーのスループット（応答性の良さ）をあげないと、
どんなに素晴らしいサービスを構築しても、否、素晴らしければ素晴らしい程に、容易にサーバーが陥落してしまうという現実に直面してしまうのある。
ところが、C++やSTLなどのオブジェクト志向プログラミングは遍在性分が多く、数多くのバックヤードのライブラリィを暗黙の内に必要としており、プログラムの起動時間が恐ろしいほどに長くなってしまった。
しかし、それではスループットをあげられないので、プログラムソースにimport などでライブラリィを指名することで、利用するライブラリィを厳選する以外に、ロード時間を大幅に短縮する方法がなかったのだ。こうして、一義的な解釈しかできないオブジェクト志向プログラミングが主流になった。
退行してしまったオブジェクト志向と云えば、その通りなのだが、一義的な解釈しかできないので、読み間違うことも少なく、プログラマの能力差によるバクの発生が減ったのは云うまでもない。
また、イベント分岐判定など遍在性分が多いコードは、読み慣れない普通のプログラマが修正を加えると悪い結果しか出ないのはミエミエなので、
ワークフレームと名を変え、一般のプログラマからコードを隠ぺいするのが普通になった。
こうして、今となっては、システム全体がどうなっているのか、実は誰一人知る者はいないので、
セキュリティホールがあるのかどうかは、ワークフレームをちゃんと読める人にしか判らない状況に陥るのでした。