徒然に書いてみました。徒然に書いてみました。一気に書き下ろした状態なので、あまり一貫性や論理性は無いかも知れません。後日ふりかえって添削するかも知れません。保守運用をおこなわない場合とがあります。いずれに該当するのかを抜きに望ましいソフトウェア構造を論じることは出来ません。作りっぱなしシステムなのであれば、作る工程そのものの生産性が目標の中心になります。様々な仕組みや支援ツールが求められることでしょう。目標の中心とはなりません。保守に耐えうるシステム基盤であるのかどうか、などが目標の中心となります。異なる種類のOSや異なるバージョンのOSの上で動くことなど要素についても重要です。一致しない場合とがあります。プログラム開発者とプログラム保守運用者が一致するかどうかによって、コンピュータシステムの望ましいソフトウェア構造は変わります。この前提条件抜きに望ましいデザインは論じるべきではありません。ほとんど問題ないことでしょう。長い年月の間、他人の開発したコンピュータシステムをプログラム保守運用し続けるという条件があるのであれば、プログラム開発者は好みのソフトウェア構造を設計して製造してはなりません。想定される平均的なプログラム保守運用担当者に適したものを作らなくてはなりません。しても自らの好みのデザインを実装したいのであれば、プログラム保守運用も自分で担当することを申し出るべきです。その責任と決意が無いのであれば、想定される平均的なプログラム保守運用担当者に適したデザインを採用すべきです。多くの人が集められて開発をすることになります。(※ここで論じている大きいシステム規模とは、ステップ数が多いということを意味しています。それら開発をした人のほとんどは去ってしまいます。世の大規模基幹系システムというのは、ここに相当します。ソフトウェア開発生産性などを論じる上でソフトウェア開発生産性などを論じる上で、今まで挙げたような前提条件を抜きにして論じるべきではありません。どの前提条件のうえで話題を進めているのかについて、私達は明確に示す必要があります。部分的な効率を述べてしまっていることが多いのです。明示していないのか、あるいは書き手が本当に知らないので明示していないのか、これは私にはわかりません。理解できないものですコンピュータシステム開発という狭いジャンルにおいてすら、ここで挙げたような立場や状況における差があります。これらの一方しか経験の無い人にとっては、他方の立場による状況というものを、なかなか理解できないものです。具合の悪い状況が重なっているので、自分と異なる立場や状況というものがどういうものなのかについて、なかなか理解できないなんていうレベルどころか、全くもって理解できないというシロモノになっているようにも思われます。これは非常に憂うべき状況です。いずれの立場で関わっているのかについても、前提条件として論じる必要がでてくる時代が来るかも知れません。アマチュアの立場であれば、自分の好きなことにだけ没頭できます。職業(プロ)という立場だと、自分の好きなものは作れないことが多いです。そのかわり労働の対価を得ることができます。アマチュアとして参加するのは、自分が好きなものを作ることが出来ない不満を解消するためにおこなっているように思えます。自分の好きなものを仕事で作るようになるとオープンソース活動に割く時間は減ってしまうかも知れませんね...。好きなオープンソース活動に従事できることです。一部の恵まれた人たちは、そのような立場で活動しているように聞き及びます。プログラミング言語や開発環境について思うことここからは、プログラミング言語や開発環境についてのことです。優れた最適なプログラミング言語なのでしょう。非常に多く利用されています。C言語が背負っている業にも似たものを感じます。JavaはCOBOLと同等の地位になったんだ、と感じるのかも知れません。素晴らしい仮想マシンのひとつです。Java仮想マシン環境という実行形態についてです。長きにわたり保守運用された実績を持ち、そしてオープンソース化が予約されているので、将来に渡っても安定した実行環境を得ることが出来る期待を持てます。Java言語なのですが、相対的に弱い面があります。画面デザイナ系の機能で定番となるものが無いという点です。(と私は考えています)。Microsoft社です。秀逸な画面デザイナを提供し続けてきました。高みのポジションにいます。Monoについても追認する姿勢を出し始めています。デザイナ向けのデザイン系ツールまで提供し始めています。方が好適なのではないのか、なんて最近思い始めています。そこらあたりで心が揺れているという状況です。要チェックになるのではないかな、と予想しています。Javaランタイムを利用できません。レンタルWebサーバの多くでは実行することが出来ません。Java言語のウィークポイントですよね。規模の大きなアプリケーションを得意としています。コンパイラが実施してくれるからです。生産性・保守性に非常に大きなメリットとなります。かなりのデメリットとなりえるのです。開発したものを、クラス名、メソッド名、型などの妥当性を自動テストで担保することは事実上不可能です。そんなに規模が大きくないものだったのですが、ダメでした。言語処理系のチェック機能に依存するところが大きいのです。確固たる地位を得ています。これは衆目の一致するところなんだと私は勝手に思っています。SQL言語は集合を扱うのが得意なプログラミング言語です。ある意味決定的に異なるポジションにいます。その特長など、興味深いヒントが数多く隠されていると思っています。なんでも良いのですよね...エンドユーザ観点において、究極的にはプログラミング言語なんて、なんでも良いんです。プログラミング言語のためのランタイムライブラリを取得して、そして実行したら良いだけなのですから、、、。それとも動かないのか、ということだけのはずです。動作することでしょう。動作しないのでしょう。2用のソフトウェアは動作しないことでしょう。何言語で開発されているのかについては、ほとんどのエンドユーザには興味のないことなのです。(開発者の単なるエゴなのですけれども、生産性は無視できないから、どれを選ぶのかについては重要なのですけれどもね...)このように、私たちがプログラミング言語を論じるときには、エンドユーザ観点を失っていないかどうかを自分に問いかけることも重要なのです。XXX言語のバージョン、そういう所にも関係あるのですよねぇ。:-Pそういう気持ちを、オープンソース開発に充てているのだと思います。当個人的見解に一切責任を持ちません。