«前の日記(2008-02-05) 最新 次の日記(2008-02-07)» 編集

Matzにっき


2008-02-06 [長年日記]

_ 思わずうっかりついポロリ!これがエンジニアの失言だ/Tech総研

はてなブックマークで私の日記のエントリを見ると、 この記事への宣伝リンクが入るのだが、 それは「お前のPHP関連のエントリは失言だ」と、 はてなに認定されている、と。

そういうことでいいのか(笑)。

_ [Ruby] Ruby Waves: Home

新しいWebアプリケーションフレームワークRuby Waves。

Waves is feature-rich, compact, and extensible. Waves is thread-safe, hot-patchable, and supports easy clustering. Waves relies on best-of-breed Ruby libraries, including Rack, Mongrel, Sequel, Markaby, and Erubis, among others. And it uses just-in-time class and module creation to minimize the code you have to write.

MerbといいWavesといい、ポストRailsを狙っている(?)フレームワークが登場することは 大変健全なことだと思う。競争のないところに発展はない。

複数選択肢があるということはマーケティング的には善し悪しなんだけどね。

_ [言語] Static Languages: Rationalizations and Myths :: Steve Vinoski’s Blog

「動的言語批判」への批判。一読あれ。

ちょっと読んでみるとわかるけど、 この批判って単なる「静的言語が優れている」という意見への批判を越えていて、 実は批判の対象は「単一の言語しか知らないユーザの思い込み」ではないかと。

単一言語脳の恐怖

というか、なんというか。

ひとつしか言語・環境を知らないと、 それがすべてであり最良であるとしばしば思い込む。 そりゃひとつしか知らなけりゃ、それが最良だよね。 で、知りもしないくせに他の言語・環境に噛みつく、と。

ぜひ、プログラマ諸氏には、複数の言語・環境を経験していただきたい。 たとえ仕事に直接使えなくても。とくに両極端な選択がいいな。

「CとRuby」とか、「JavaとLisp」とか、「EclipseとEmacs」とか。 「ForthとScheme」とか。「HaskellとC++」とか、「APLとPerl」とか。

_ バランスボール

目の前の席の同僚(特に名を秘す)がイスをバランスボールに置き換えた。

ま、それはそれでよいのだが、 スクリーンの向こうで彼の背中が上下にゆらゆらと揺れると 普段のイメージとのギャップもあいまって なごんでしまって、しょうがない。

あ、なごむんだから、いいのか。

本日のツッコミ(全26件) [ツッコミを入れる]
_ tohi (2008-02-06 19:30)

うちの会社でもはやっています。

_ popn.ja (2008-02-06 20:58)

ひとつしか言語を知らないプログラマさんはどの程度いるものなのでしょうか?<br>自分は子供の頃にBASICがあって、高校生でX68kのアセンブラ以降色々な言語をその時々に応じて使ってきたので、ひとつしか知らないっていうのがいまいちピンとこないです。

_ じょりちょこ (2008-02-06 21:20)

僕は、50代になってVBしかできないという人を何人も知っています...<br><br>それはそれとして、僕は完全に動的言語派です。Common Lispのようにオプションで型宣言することで最適化を促すのは好きですが、静的型付けによって早期にバグを発見するというやり方にはあまり馴染みません。<br>型推論とgenericがあればブックキーピングを最小に抑えた上で型安全を実現できるというのはわかります。わかるのですが、型のことまで考えて「何が本質的か」ということを見抜く力が僕には不足しているようで、ちょっと複雑なプログラムになると頭がパンクします。<br>といって型推論とgenericを避けて明示的に型宣言をする言語になると、ブックキーピングが繁雑過ぎてダルいとしか言いようがありません。<br>たぶん、静的言語が好きだという人は、コンパイラに型矛盾を指摘してもらって思わぬエラーを発見できた体験があるのでしょうね。僕は、どうもあまりそういう体験がありません。ボトムアップに書くからでしょうか、短いコードブロックの中では型矛盾はほとんど起こらず、しかし、ボトムアップに書いているとき、トップレベルから見たときの型の名前を見通していることって全然ないんですよね。型aのためのユーティリティを書いている、としか言いようがないんですよね(その型aの型が決まるのは、すごく後の方なんです)。

_ コアラ似のおじさん (2008-02-06 21:43)

うちの関連会社さんには、<br>Cしか知らない人や<br>VBしか知らないプロのプログラマーさんがたくさんいます。

_ (2008-02-06 22:43)

SchemeとForthってわりと似てる気がするんですが、両極端ですかね?<br><br>ちなみにわたしの隣では、バリバリのHaskellerが泣きながらC++でプログラミングしてます(笑)。

_ 単一言語脳 (2008-02-06 23:28)

多くの言語を知ることが常に良い結果をもたらすとは思えない。人の能力には大きく幅がある。数多くの言語を学んでもその多くが人並み以上にできる人ならばいい。そうでない人はむしろ一つに集中しなければ十分に習得できないのではないか。多くの言語を学んだとてそのいずれも中途半端なら何も知らないのと等価だ。

_ まつもと (2008-02-06 23:35)

単一言語脳さん、<br>あなたご自身が複数の言語を学んだがその知識は役に立たず、何も知らないのと同じだった、という実際の経験をお持ちでしたら貴重な例として拝聴します。<br>実際にはひとつしか言語を知らないが、複数の言語を学んでも役に立つ「気がしない」というのであれば、それはまさに名乗り通りの「単一言語脳」の一症例でしょう。

_ popn.ja (2008-02-07 00:00)

相反する言語を2つほど習得するだけでも、プログラミングに対する考え方(と言えばいいのかな?)に幅が出てきていいと個人的には思います。

_ ハードウェア即身仏 (2008-02-07 00:04)

Matzさん、是非とも貴殿の言語コレクションに、極め付きの静的言語であるVerilogかVHDLを加えてください。見た目はC言語風だったり、Pascal風だったりしますが、対象が対象なのでかなりキテマス。Rubyで書いていても、「あの機能があれば..」と思う機能が幾つか見つかると思います。<br>最近はFreeなコンパイラやシミュレータも有るようですし...

_ 元職業プログラマ (2008-02-07 00:25)

単一言語脳さん<br>「多くの言語を知ることが常に良い結果をもたらすとは思えない。」→(多くの言語を知ることがたまには良い結果をもたらす。)∴「多くの言語を学んだとてそのいずれも中途半端なら何も知らないのと等価だ。」というのは、少し矛盾していませんでしょうか?<br><br>Well, Python は、the attributes of classes and instances の capsuling は、Yet 出来ないのでしょうか?

_ ららら (2008-02-07 01:14)

どっぷりとプログラミング言語の世界に浸るにはPOPLやPLDIの最新の論文を読むのがいいです。

_ (ぱ) (2008-02-07 03:57)

CとC++とJavaとC#知ってます、というのでは、「単一言語脳の恐怖」から逃れたことにはならないのですよね。きっと。<br>私は、「言語ひとつ習得するには、仕事でフルタイムで使って半年かかる」と思っています。CあがりのプログラマがJavaを使って、全部staticメソッドで書いていたら意味ないですし。

_ Chiharu (2008-02-07 08:30)

両極端な言語ですか…。Postscriptも言語のうちでしょうか。<br>最近仕事で触れる機会が多いです。スタック言語というようですが、インタプリタ書きやすそうなのと、遅延評価が容易なあたりが、C/C++に慣れていた自分には新鮮です。…ただ、どちらが扱いやすいかは…、好みもあるんでしょうが、PSは常用したくないなぁと思います…。

_ とおりすがり (2008-02-07 09:28)

http://itpro.nikkeibp.co.jp/article/OPINION/20080206/293139/<br>今回の件に触発されたんでしょうか?<br>日経ソフトウェアの記者さんがPHPに一言書いています。内容は「あーでもあるが、こーでもある」という感じのものですけど。<br>特集で「初心者におすすめ」を声高に叫んだことを少し気にしたのかなぁ?真意はわかりませン。(笑)

_ 単一言語脳 (2008-02-07 11:29)

前者。憧れで名乗ったが実際は無言語脳だ。複数の言語を習得できた人はgiftedである。その経験は同じgifted同士でしか共有できないことを認識するべきだ。

_ まつもと (2008-02-07 11:42)

単一言語脳さん、<br>プログラミングに興味が持てない人、言語を習得できない人、やる気を持てない人などがいることは認識しています。<br>が、そういう人たちの存在を認識していたとしても、その人たちは今回の話のスコープ外です。万人を救済する方法なんて思いつきませんもの。<br>その方面に才能や希望を見いだせない人は、他の業界に転身するのがよいのかもしれません。<br>プログラミングだけがすべてではないのですし。

_ 元職業プログラマ (2008-02-07 23:05)

びさん<br>>ちなみにわたしの隣では、バリバリのHaskellerが泣きながらC++でプログラミングしてます(笑)。<br>抽象化はもちろんの事、Boost C++ライブラリ or STLを使っても泣かなければいけないのでしょうか?<br><br>それと、Rubyのソースは結構greatですね。特にeval.c and parse.cが。

_ 石蕗 (2008-02-07 23:26)

XMLは学ぶ気になれません

_ 元職業プログラマ (2008-02-09 16:08)

>XMLは学ぶ気になれません<br>XMLは、学ぶというほど難しいものなのでしょうか?<br>尚、私は、XMLは冗長過ぎるので、地球環境の事を考えると、あまり使いたくありません。(さすがに、HTMLまでは否定しませんが。)<br>因みに私は、モヒカン&バイナリ族に属していますので、Rubyのpack、unpackメソッドは、たまに重宝します。

_ じょりちょこ (2008-02-09 19:06)

XMLそのものは簡単だけど、周辺技術が...

_ 元職業プログラマ (2008-02-09 22:41)

じょりちょこさん<br>>XMLそのものは簡単だけど、周辺技術が...<br>XMLそのものについての周辺技術の、どの辺がそんなに複雑なのでしょうか?

_ Lyiase (2008-02-10 04:40)

>> じょりちょこさん<br>>XMLそのものは簡単だけど、周辺技術が<br>それには同意しますね。<br>XML自身が柔軟すぎて、勉強しにくいというより、疑問を持ってしまうってことは結構ありますね。<br>多分、これはLLな言語でもかなり型を気にしてしまう性分なんでしょうが。<br><br>>> まつもとさん<br>>単一言語脳の恐怖<br>確かに両極端の複数言語をやるって重要ですね。<br>特に動的言語と静的言語を経験しないと分からないことは結構あると思います。<br>以前のPHPの一件でまつもとさんが仰ったように、一つのプログラミング言語だけ見てると盲目になりがちですよね。<br>ただ、それは両極端というより、理念が異なる言語が良いと思います。例えば、PerlとRuby。両方ともLLな言語ですが、理念は全く持って違いますよね。<br>そういえば、単一言語脳と言えば、ちょっと前はC++かCだったような気がしますが、今はPHPとかJavaなんですかねぇ。<br><br>>で、知りもしないくせに他の言語・環境に噛みつく、と。<br>ああ、耳が痛い(笑)

_ じょりちょこ (2008-02-10 12:11)

XMLを使い始めると、XMLを利用する各種テクノロジーと接点が出てきます。XMLが糊の役割に徹してくれていると良いのですが、往々にしてXMLを介して接した向こう側も習得せざるを得ません。XMLを利用するテクノロジーは非常に多く、かつ、仕様が枯れていないので、いつまでたっても過渡期が終わらないという印象です。

_ 元職業プログラマ (2008-02-10 15:13)

じょりちょこさん <br>>往々にしてXMLを介して接した向こう側も習得せざるを得ません。<br>XMLは、ある意味では、この様なことを防止するために仕組みだと理解しているですが、XMLデータを交換するに当たって、「XMLを介して接した向こう側の」、どこの習得がそんなに大変なのでしょうか?<br>具体例を教えていただけませんでしょうか?

_ じょりちょこ (2008-02-10 22:13)

たとえばXSLTをおぼえないといけなかったりしますよね。

_ 元職業プログラマ (2008-02-11 10:09)

>たとえばXSLTをおぼえないといけなかったりしますよね。<br>ご教示有難うございました。

お名前:
E-mail:
コメント:
[]

«前の日記(2008-02-05) 最新 次の日記(2008-02-07)» 編集

track feed Matzにっき Creative Commons License This work is licensed under a Creative Commons License.