プログラマの方に質問です。

　見えている、の意味を量りかねるけど、わかっている・考えている、みたいな意味だとすると・・・

　HPCをやっていた頃は、CPUを考えて開発していましたね。

　例えば、論理的に同じ処理を実装するときに、1行で書ける命令を使うとCPU内部では28クロックかかるけど、命令を分割すると8+10+4クロックで処理できるであるとか、パイプラインの都合で命令順序を入れ替えて実行すると数クロック早く終了するなどありますね。

　あとは、条件判断でTRUEに書くよりもFALSEに書いた方が高速なことがあって、条件を反転するなど。

　コンパイラレベルの話でも、深い呼び出しをすると、オプティマイザが効きにくくなるので、浅い構造にするなどはパフォーマンスチューンでやりましたね(関数にまとめれば保守などは楽ですが、呼び出しコストがかかるので、速度重視では毎回コピペしたりします)

「深遠」かどうかはわからないけれど、アセンブラでやってると、＃１の方と同じように、機械語のビット構成まで考えますね。たとえば、１命令中、８ビットで自分のアドレスから１２７まで先には直接飛べるとき、そっちに飛んでから分岐した方がよいか、直接ダブルワードで分岐先アドレスをとったほうがよいか、など。

（すみません、nonプログラマの方にはわかりにくいかもしれませんが。。。）

胸を張って「深遠な世界」まで見えています、という自信があるわけではないですが、nonプログラマな人に体験できないことを体験できたと思っています。

プログラム言語：

それなりに使われているプログラム言語は「その言語での世界観」というものがあると感じます。それは時に言語の設計者が意図していないものであったりすると感じています。

プログラムを実装する方法は１つではないため、プログラマはなんらかの観点でもっとも良いと思われる実装方法を選択する必要があるわけですが、そこで「自分の選択」と「言語の世界観」が「溶け合っている」と感じたとき、生産性も品質も良く、メンテナンス性も高いという「すばらしいプログラム」ができたりします。そんなときには、自分がコードを書いたという感覚ではなく、ディスプレイの向こうから「こう書いてくれ」という声が聞こえるような気がします。

アーキテクチャ：

プログラム単体でなく、システム全体を通してミドルウェアとアプリケーションがどのように切り分かれ、またそれぞれの内部でも、どのような構造で各処理がなされるのがもっとも妥当であるかを検討し決定するのがソフトウェアアーキテクトの役割だと思っています。

システム全体についてそのような役割を担ったことはありませんが、システムの一部について、そのようなポジションで仕事をした経験があります。うまくいったシステムで、発生する様々なイベントがあたかも「ピタゴラスイッチ」の仕掛けのように、時にはさらりと、時にはゆったりと、しかし全て意図したとおりにフローを流れてゆき、あるべき処理を行ってゆくのを見るときの感動はなんともいえないものがあります。

まあ、プログラミング等に限らずとも、そういうことはある程度あるとは思いますが、とりあえず私感を書かせていただきました。