May 22, 2007
僕が最初に入った会社では、産業用の生産装置の電気設計のエンジニアをやっていました。
新入社員で現場から入って溶接したり板金したり制御板作ったり、一からモノ作りを学んで、エンジニアとしての原点は今でもそこにあります。
生産装置ってで何が一番大事かと言えば、装置を利用されるお客様の製品を安定して生産すること、ただ一点です。
装置が壊れたときに、遠方、時には海外（日本）にいるエンジニアが一々出張しないと直らないという装置は業務上のリスクに繋がります。だから、部品は簡単に交換できるように作るし、ソフトウエアもある程度であれば、その会社の保全のエンジニアがいじれるように作らなくてはいけません。
そういう中で、装置はそのままで、制御に使っているコンピューターを、その会社の標準仕様に合わせることが求められることがあります。
単純に企業の系列的な都合もあるし、保全のエンジニアがいじれるメーカーにあわせて作ることが求められます。
Ｗｅｂアプリケーションであれば、Perlで書いたプログラムを、うちは標準がPHPだからJavaだからって書き直すようなものです。（88用に書いたプログラムをX1やFM-7に移植する、とかに近いけど）
コンピューターの業務用アプリでも、WindowsとUnix間とか、汎用機となんとかの間で移植をすることはあると思います。
その善し悪しはさておき、エンジニアたるモノ、状況に併せて適切な技術で仕事をせねばならないといけないと思っているし、僕はそういうメンタリティを持ってして自分はエンジニアであるという肩書きを使います。
そんな長い前置きの元、下記の記事がひっかかった。
必ずしも、プログラマーは僕が思うエンジニアとは違う、のかなと。
geekの人を見ていて、冗談か本気かわからないのですが、言語選択とか周辺ツールの有無が、本当にモチベーションの一つになってるのが結構不思議だったりします。
Dan KogaiさんがPerlというプログラミング言語そのものにコミットしている人だから、そこが技術として重要なのはよくわかります。
が、言語利用者としてのプロのエンジニア論としては、言語の善し悪しなどに捕らわれて欲しくないと強く思うわけです。
言語にコミットしている人以外の「言語利用者」としてのエンジニアに重要なのは、
・「アウトプットが適切に動き、アプリケーションの目的を果たすこと」
・「アウトプット」＝「やりたいこと」が実現できること。
・その「アウトプット」自体にどれだけの技術が宿っているか？・・・が言語利用者が実現すべき「技術」なのではないか？
・で、自分の周りを見渡し、チームが安定して目的を果たし続け、かつ継続的に人材が確保できること。
言語利用者にとってのプログラム言語自体は、ただの手段でしかありません。
まさに目的と手段を間違えないようにして欲しいです。
（このエントリーのターゲットは、各社のエースであるgeekの人たちではありません。geekの人たちを注目している、はてブなどのユーザーであり、今後、一緒に働くかもしれない人に向けて、です。）
もちろん、これから作るものに対する言語選択は重要な技術選択の一要素ですから、上記のエントリーで言われているPHPの弱点は同意な部分もあり、それを嫌ってPHPを使わないというのも一つの選択ですが、僕の持つPHPへのイメージは、多数、むかつくことはあるけど、別にLLがやれる範囲であれば問題が解決できないわけじゃないし、他のLLに比べて、生産性や企業利益に対してネガティブ要素はないと思ってるし、むしろ周りのリソースも踏まえて、何かを解決する解法を得やすい言語です。
（ぶっちゃけて言うと、僕の手元にはPHPの弱点を補うフレームワークが２つあって、そのどちらでも、Dan Kogaiさんが言われている弱点の結構な部分が解決されてるからってのは確かにある。でも、それはRubyに対するRuby on RailsとかPerlに対するCPANと変わらないような気がするんだが・・・。）
で、気になったところ。
＞Webアプリ以外作る気にならない
＞「でもCLIがあるじゃん」と言った方。なんでただのshell script書くのに
＞囲まなきゃならないのか。CLIを使う人にそんな勤勉さを期待されても困るというもの。
CLIでバッチ回して、お客様からお金をいただくアプリケーションを回していますが何か？
ただ、Webアプリを作るために特化してる言語なんだから、そんなの当たり前じゃないか、という気がしてきた。
まぁ、統一されたシンタックスとライブラリで、バッチも全然行けるよってところがポイントということで。
なお<?php ?> がつくことについては、$を変数名につけなきゃいけない言語に未だに慣れてない僕からすると #!/usr/bin/perlと同じです。
＞MVCのVしか出来ない
好きなところで、printしたら画面に文字が出力されちゃう言語はみんなVだと思いますが。
ちなみに余談ですが、PHPのフレームワークというのは、大体どれも最終的に如何にSmartyにパラメータを渡すか？という構造ですよね。
Webアプリってリクエストに対して直線的にレスポンスを返すのが、ほとんどの流れなので、MVCを強く意識するよりも、Logic + Model（DB） + Smartyを意識したフレームワークの方がWebアプリを作るのはやりやすいです。
（ただし、これこそWebアプリ限定になりがちですが。）
なお、最初に書いた制御コントローラーは、PLCという分野のもので、コントロールするためにラダー言語と言う機械業界では安定性と使いやすさに定評のある言語で動作していました。
ラダー言語自体は、遠方の営業マンに電話で指示してプログラムの修正ができるという、制御のエンジニアにとって非常に素敵な言語でした。産業装置は、お客様が世界中にいるので、いろんなスキルレベルの人が（ときにはお客様が）プログラムを修正できるシンプルさは、ものすごく素敵な技術と言えましょう。
PLCは性能を求めて拡張され、割り込み、間接参照（ポインタみたいなもの）などで、誰でも使えるコントローラーという製品の位置づけにしては高度なプログラミングができるものが登場していました。
僕が開発していた装置も、割り込みなどの高度な機能が使えなければ、装置の慣性に勝てなかったので、割り込みがあって本当に助かったものです。
が、、、いかんせん、プログラミングはアセンブラライクな表示か、機械屋さんでもいじれる趣旨のビジュアライズされた言語表示という両極端のインターフェース上でプログラミングしていかなくてはいけなくて、本当にスパゲッティなコードになってしまい、基本的にコードの視認性は最悪です。
そんなのに比べたら、人間が構造を読めるように書かれた、いわゆる「プログラミング言語」は、どれもこれもが幸せなので、CPANなどのソーシャルコミュニティやインターネットという存在を除けばLLの言語間の善し悪しなんて無きに等しいです。どの言語も、こんな簡単に目的を達成できて、非常にありがたいこってす。
ーーーーとりあえず、このエントリ終わり。
しかし、ですね、
最近のWebアプリはRuby on Railsを使ったと言えば、そこがニュースで取り上げてもらえるわけですよ。つまりbuzzワードって奴です。なんでWebアプリケーションのプレスリリースに裏で動いているプログラムやフレームワークの名前が出てくる必要がある？
つまるところ最終的には、プログラマー人材確保の重要な材料になのは間違いないらしいので、言語選択は企業戦略として重要（なのかな・・・。わからん。）
でも、ここで書いたエンジニア論からすると納得はいってないです。
キャリアパスとして重要と認識されてればこそなので尊重はしますが、技術選択のレベルで好き嫌いが出てしまうとしたら、そんなメンタリティで良い物が作れるのかはエンジニアとして甚だ疑問であります。
と言うか、手段である技術選択に好き嫌いは不要です。
すべては客観性を持ってして総合的に最適な手段を選ぶべきだと思います。
（これDanさんへの批判ではないですよ。読み間違えないでね。）
・・・という人がPHPを使ってる人には多いかもしれないと、ふと某社のCTOの方の話を思い出した。