プログラムについてのどーこー

hao_yaoiの人(※)が、プログラミングなことについて述べていたので
あー、そういえば...と最近思ってることを書きます。
※就職おめでとうございます

投稿の主題を拡大解釈・脳内補完・整理してみると
「プログラマってのは、単にコード化するだけでなく
　その仕組が動く全体を把握して、要求される内容を十分に満たすことはもちろん
　発生する問題点を見抜き、フォローしていくことや
　さらにこちらから提案していくことが大事なんじゃないか」
ということを、彼の人が書いているんだと理解しております。
このあたりは、２年目くらいからポツポツと求められてくるようなレベルで
この壁を乗り越えられるかどうかで、「むむ、使えないやつ」と思われるかどうかの分かれ道になったり。
なんかこのへんになってくると、SEなんでないっすかミタイナ。

さて、今回、何が気になったかというと、この主題以前の部分

"一応今の肩書きは「プログラマ」なんだけど、
　昔に制定されたプロトコルに従って作りたいものを実装してるだけであって、
　習熟はしてるのかどうかよくわからない。
　もちろん言語仕様とかはそれなりに踏まえてる。"

この部分が妙にひっかかった。
と言っても、イライラするんだようとかじゃなくて
ちょいと前から思ってることに妙にかぶるからでした。

実際のところ、今のコード書きは、
１つの言語だけできればいーやってわけにはいきません。
　　 というか、１つ言語ができれば、あとはリファレンス片手に
　　そこそこ書けたりする。
　　これは、プログラムが動く仕組がわかってたり
　　機能から名前を類推できるようになったり
　　 なんかそのへんの共通するようなことが把握できてるからで。
なので、「習熟はしてるのかどうかよくわからない」という不安を覚えるのは当然だったりします。

で、私がちょいと前から思ってることっていうのが
「各言語仕様をどこまで理解することが必要なのか」なんてことです。

太古、１つの言語に対して完全に理解してる人というのはゴロゴロしてて
もう、自分でその言語を再現できますよみたいな感じ。
なので、その言語の癖にあわせて、最適な書き方をできるのは当然
これは、省メモリだったり、最速だったり。
「こんな仕様をこんなにコンパクトに!?」
これはDOS時代には、必須な技能でした。
コンパクトにできなかった場合は、メモリの切り替え(※)が必要で
「おっそ！」と非難轟々。
　※正式な名前は忘れてしまったんだけど
　　マシンのメモリに収まりきらないので
　　実行中に、この処理の時はこの機能は使わないので
　　必要なものをそのメモリ空間に上書きして実行みたいなやつ
　　なんかエクステンダとかもあったなぁ

LSLなんかでは16k(64k)に収めるために
i++と++iのどっちを使うかとか
同じ機能でも意識的に書き方を変えたりしています。
これは「リファレンスペラペラ」レベルにしか知らない言語ではムリな感じです。

「ムリ」とかちょっと否定的に書いているわけなんですが
今の時代は、ソレはソレでいいのかなぁというのが
気になるところなのです。

私は言語仕様とか読むのがわりと好き(※1)なので
ヒマとお金と体力(※2)があれば、言語仕様本とか買ってパラパラ読んだり(※3)しています。
でも、今のコンパイラの性能とか、マシンで使えるメモリやCPUを考えると
コード化時点で、そこまでの理解は不要なのかもしれないと。
　※1：言語の理解というよりは、その実装の思想とか背景とかを知るのが好きです
　　その副産物として、仕様の理解というものがついてくる感じ
　※2：高くてデカいんだよ、持ち歩いて読みやすいサイズにしてくれ...
　※3：がっつり読み込むというよりは、
　　気になる部分だけ点として読んで、それが重なっていつのまにか
　　全体を知るという読み方

いや、実際には「不要かもしれない」なんてことは思ってませんよ。
　※「UNIXという考え方―その設計思想と哲学」という本は、一読の価値ありだと思ってます。
　　一読どころか、何度も何度も読んでます。

いくらメモリを大量に積んでいて、CPUのスペックも上がり
ハードディスクの速度があがっても、
サーバで実行されるプログラムの数は増える一方なのです。
１つ１つのプログラムをコンパクトかつハイパワーにすることは
大きな意味があります。

なんだか妙に長いので次回に続きます