«前の日記(2006年11月14日) 最新 次の日記(2006年11月16日)» 編集

Matzにっき


2006年11月15日 [長年日記]

_ [原稿] オープンソースマガジン

「ライセンス診断」完結。楽勝、とまでは言えないが予想よりは楽だった。 むしろ削るのに苦労した。

_ Servoy - smart technology for smart clients

どこかで見つけたAdSenseリンク。いわく、

From plain browser-only apps to enterprise web-applications with Servoy

Are you tired of the complex syntax and the limited capability of Ruby on Rails? Servoy enables you to code even faster than with Ruby, yet offers you so much more functionality! With Servoy's strong feature set, you can code complex web applications with integrated business rules in very little time; and then deploy these applications as both a Servoy Smart Client and Servoy Web Client -- using the same code-base.

要するにJavaのアプリケーションフレームワークで、Rubyとはなんにも関係ないようなのだが、 「Ruby(とRails)の複雑な文法と制限された能力に嫌気がさしたら」というのは、 面白い宣伝文句だ。普通は逆方向の流れなのだが。

こういうのが出てくるというのは、個人的に「Railsはホンモノ」という印象を与える。

_ [言語] How Does a Programming Language Stagnate?

Perl5が言語として停滞するということはあるのか、という話。

言語の停滞(あるいは衰退)というのは、 言語設計者である私にとって重要なテーマである。

プログラミング言語の衰退はユーザがいなくなることによって起きる。 それはその言語の生態系が弱体化することである。 もはや、その言語で新しいプログラムが書かれなくなると、 言語はメンテナンスモードになる。ユーザは少しずつ減り、 長い時間をかけてその言語は次第に忘れ去られていく。

現在、COBOLがそのモードである。 確かにまだまだCOBOLは使われている(我が社は その証人でもある)。 しかし、そんな我々でも、今からCOBOLの新しいプログラムを書く人が少数派であることは否定できない。

FORTRANもかなり近い。これも分野限定では現役のようだが。

しかし、衰退の前に停滞が来るのだ。

それは言語が進歩を止めることである。 あるいは仮に進歩が起きてもユーザの手に届かなくなることである。

たとえば、Cはかなり停滞が進んでいる。最後の規格はC99だが、 実際問題C99をばりばり使う人はそんなに多くない。

だからこそ、ほとんどの人が1.8に満足していても、1.9や2.0の話を続けなければいけないのだ。 Rubyを前に進めるための燃料として。

とはいえ、1.8と1.9があまりに分離しても、停滞は起きうるんだよなあ。 悩ましい。


«前の日記(2006年11月14日) 最新 次の日記(2006年11月16日)» 編集