あなたはこの手続きを関数として表現できるでしょうか。...できませんよね?何故ならば、各ステップの"間に"、マシンのロボアームの位置や動きを調整する処理が必要だからです。これをオブジェクト指向でやろうとすると、各ステップの副作用として、それらの処理を行うことになります。すると、マシンが二機に増えた時などの変更量は、絶望的なものになります。関数として表現するのを諦め、手順全体をDSLで記述できるようにします。このアプローチは関数型プログラミング的です。関数型プログラミングをサポートした言語の助けなしでは、そのDSLを記述するために沢山のユーティリティーコードを書かなくてはならないでしょう。オブジェクト指向的アプローチでこの問題をエレガントに解こうとすると、クラス化の粒度を上げる事になります。野菜クラス、フライパンクラス、ボイルクラス、フライクラス、焼き加減クラス、アームクラス、野菜の大きさクラス、切り方クラス、焼き方クラス、"焦げたよ"クラス、etc...こうすると早晩レシピはプログラムのコード上から消え去ることになります。上記のたった5行は、依存性注入のオブジェクトグラフを構築するコードに取って代わることになります。そこには沢山の挙動の制御がオプションとして付記されているのです。カレーなど、ある種のレシピに限定することで、見た目の理解しやすさを得ることができますが、一方それは表現力を損なうことを意味します。C言語などではマクロを使うこともできますが、それは結局、関数型プログラミング的アプローチの意味するところと同じになります。補助のために沢山のコードを書くことになるでしょう。GUIiOSのAppstoreアプリは、"無料"と書かれたボタンを押すと、それが"インストール"ボタンに変わり、それをもう一度押すと、ダウンロードの進捗を表すインジケータに変わり、それを押すとダウンロードをキャンセルできます。このように、位置は同じなのに、ステートに依って見た目と機能が変わるボタンは複雑です。同じボタンが三つの異なる機能を持つかという下らない問題にぶつかります。関数型では、"機能"、"見た目"、"状態"、を独立に扱って、それらを合成してボタンを作るので、迷うことはありません。「同じ位置にあるUIオブジェクトは、コード上で(インスタンスとして)独立して、他から干渉を受けない」この条件が満たされているうちは、オブジェクト指向でGUIを実現することに無理はありません。携帯端末のような小さい画面で、多くの機能を達成するためには、UI要素はコンテキスト依存的に複雑になりがちです。近年、PCのディスプレイの大きさは、頭打ちになってきました。画素数は増えているのですが、MacにおけるRetinaのように、複数ピクセルでひとつのドットを表すようになってきています。これは、ひとつの画面に置かれるボタンなどのUI要素の数は、これから先の未来で増えることはない、ということを意味します。関数型プログラミングの力を頼るしか無いでしょう。