プロジェクトを失敗に導くプログラミング言語 83
ストーリー by kazekiri
C#を使うと必ずあなたのプロジェクトは失敗する 部門より
C#を使うと必ずあなたのプロジェクトは失敗する 部門より
プロジェクトを失敗に導くプログラミング言語という文書が
公開されている。
この文書では、各プログラミング言語に対して、
freshmeatでアナウンスされたプロジェクトの数を
sourceforgeに登録されているプロジェクトの数
で割った値をフリーソフトウェア開発プロジェクトの成功率としてみなし、
その一覧を公開している。意外にTcl, Rubyの値が高い気もするが、C, PHP
あたりは妥当なところか。かなりad-hocな指標だが、
それなりに考えさせられる。
「C#を使うと必ずあなたのプロジェクトは失敗する」の一言は実にいいね。
Re:C# (スコア:3, 参考になる)
どのくらいに設定すればいいんだろう? 10くらいかな? ここを見ると、C#なProjectってRubyやSmalltalkより多いんだよね。まあでも、APLは明らかに外すべきだろうな。:-)
> ちなみに、C#はTurboPascal、Delphi、J++の開発に加わっていたAnders Hejlsberg氏もからんでますし
JavaとDelphiをmixしたような言語とはよく言われていますな。:-)
> まだVSのベータ版が出てるだけだから、C#はまだルーキー以前でしょう。
そうですね。だから、どうせ「C#はprojectを失敗に導く」といいたいなら、その未成熟さを根拠にすればいいのにね。件の文書はjokeとして見ても出来が悪すぎ。
Re:C# (スコア:3, 興味深い)
ので、発表された時の仕様書を読んで、言語仕様だけは素晴らしいと思いました。
＃実装がどうなるかは、また別の話だから。
まじに、Javaに導入してほしい言語仕様が満載なんですよねぇ～。JDK1.4辺りで追加してくれんだろうか？
OOPによる「死の行進」 (スコア:3, すばらしい洞察)
まあ, フリーソフトに限らずOOPを開発言語に選んだプロジェクトが失敗ないしは完成しても赤を出すなんてことは良く聞く話です.
原因は簡単なことで, システムの分析・設計段階がOOじゃないからです. 実際のところOOP言語が使えるプログラマを100人程度そろえるのは大した苦労じゃないのですが, OO分析・設計ができるSEを5人そろえるなんてのは, よほどのBigプロジェクトでなければ半分以上運まかせに近い状態です. 又, OO分析・設計は見た目とは逆にRADになじまないというのも, RAD上がりのプログラマが上流フェーズで使い物になりにくい原因だとおもわれます.
逆に言えばOOP言語を使っても再利用可能なClass・設計の蓄積が無い分, 従来の言語と生産性は変わらず, むしろ不慣れな分だけ生産性が落ちるというのが現実です. しかも悪いことにOOP言語ではClassの再利用で生産性が上がるという一般論を, 前提を無視して盲信している人が多いのも現場にいる人間には困りものです.
OOPを使ったことによる「死の行進」の実例として有名なものにはIBMがSmalltalkを使って構築しようとした九州大学医学部のシステムが有りますが, 近年のJavaのブームによって, 潜在的な「死の行進」はさらに増えているのではないかと予想されます.
ちなみに私自身がうまくいったOOシステムの開発にかかわったのは1回しかありません.
これですな (スコア:3, 参考になる)
オープンソースのC#はこれから (スコア:3, 興味深い)
Mono や dotGNU のようなプロジェクトもあって、オープンソースの C# というのは近い将来の成長分野かもしれないですね。
それをいきなり「100パーセント潰れる」というのは、開発途上のプロジェクトに水をかけるようで、あんまり感じ良くないと思います。
Re:JavaとPerl (スコア:2, すばらしい洞察)
C は誰でも知っていて、それだけ contrib 可能性が高いという事だと推察します。
でも、 http://www.gyve.org/~jet/lang2.txt に関しては、出来れば「率」だけでなく「数」も掲示いただけると信頼度とかも読み取れてよりありがたかったのですが。
手っ取り早いけど・・・ (スコア:2)
プロジェクトの規模とか、プラットフォームとか、
参加者の数とか、その辺での比較の方が興味あります。
失敗したプロジェクトは、言語を使う以前に
なくなったかも知れませんし（笑）
無理ありすぎというか面白くない (スコア:2, 興味深い)
OpenGL & SDL for C#やNUnit などはfreshmeatにproject pageがあるから、実際には0じゃないんだよね。
それに開発言語にC#を選択しているケースっていうのは.NET frameworkに乗っかるというか、UNIXをtargetとして考えていないでしょ? そういうsoftwareのほとんどは(有名どころでも)freshmeatにannounceされていないのが現状だと思うが。というか、そもそもfreshmeatってUNIX文化の住人以外にはよく知られていないのでは?
プログラム言語やアルゴリズムだけに興味のある人は (スコア:2, 興味深い)
出しただけでプログラムを作った気になっている人が多い気がする。
そういう人のプロジェクトは大抵興味だけで推進されるので結果的に完遂しないことが多い。
何か明確な目標があって（例えばゲーム作りたいとか）、
そのために言語を学んだ人はそのプログラムは稚拙だが、
ちゃんとプロジェクトを完遂することが多い気がする。
前者ほどOOP寄りの言語を使い、後者ほどOOPでない言語
で間に合っている場合が多いことは色々考えさせられる
問題な気がする。
C# (スコア:2, 興味深い)
ちなみに、C#はTurboPascal、Delphi、J++の開発に加わっていたAnders Hejlsberg氏もからんでますし、MSの製品だから、「これから」だと思いますね。まだVSのベータ版が出てるだけだから、C#はまだルーキー以前でしょう。
と、知らない言語について大言を吐くこの頃であった。
他力本願。
「バトル・ロワイアル」と今回の記事で・・・ (スコア:2, すばらしい洞察)
これと比べると、言語のパフォーマンスと、プロジェクト成功率の関係が見えておもしろいです。
パフォーマンスが低い言語のほうが簡単で、プロジェクト成功率も高いと思いますが、CとC++は両方とも結構いいポジションにいますね。
ともかく自分自身C++が一番好きなので、プロジェクト成功率ももっと上がるといいなぁと思います。
Re:JavaとPerl (スコア:2)
実際はC++とは全く考え方の異なるクラス設計やコーディングが必要なんだけどね。
私の周りでも、その辺を判ってなくて失敗する人が結構います。
私個人に限って言えば、C++よりJavaを選びます。ま、Javaライブラリの一部に問題があることも事実ですが。
Re:Logo? (スコア:2)
"Quidquid latine dictum sit, altum videtur."
リリースされればいいというわけでも... (スコア:2)
これって、あくまでリリースができたかどうかが観点で、そのプロジェクトが続いているかどうかはまた別の問題じゃないでしょうか。
いや、やはり相関はゼロではないと思います (スコア:2, 参考になる)
もし相関がゼロなら、それを過激に言い換えると
- 「プロジェクトの成功には言語の選択は全く寄与
しない」
- 「良い言語を作ろう、という言語屋の努力は、
現実のプロジェクトには全く役に立っていない」、
- 「言語の良し悪し以外の要素(例えば、その言語を
習得している人が多いか少ないか)も関係ない」
って意味になると思います。でも、さすがに その結論は極論過ぎるかも。もっとも、nmuraoka さん自身も
> たとえば、オブジェクト指向言語は、長期に亘って
> 開発・保守を繰り返すようなプロジェクトにのみ向く
と言っておられるので、相関が有ることは分かって おられるとは思うんですが。
私としては、プロジェクトの分野と規模、 自分(達)の「問題理解度」を にらんで、適切な道具を使い分けるべきだと考えて います。自分の理解度・経験が不足している領域に、 型付きの OOP 系コンパイラ言語でトップダウン設計で 一発勝負を挑んだ場合、少なからず悲惨な結果が 待っている、そう思っています。
理解が不足しているなら簡易言語で何度も プロトタイプを作っては捨て、理解を深めてから 設計を練り直し、厳密な言語で一気に書き上げる、 そういう流れが実践主義者向きで、私は好きです。 (汚くても動くプロトタイプが有れば、 仕事を前に進められるし)
また場合によっては、新たな言語を 覚えることになっても良いでしょう。例えば私の 得意は perl と C++ ですが、シリアルポート経由で 他のマシンを操作するプログラムを書く必要が 生じたので、そのために expect を覚えたりもしました。同じ問題を perl で書くのは 大分大変だったろうと今でも思います。(expect 自体には大変ストレスを感じましたが… use strict や bless, @ISA が無いのは辛い…)
なんというか (スコア:2, 興味深い)
レトリック臭いなぁってかんじるのは
俺だけなのかなぁ？
そういうところが敬遠されてるとか？
＃悪く言うと宗教 :-p
Re:Delphi…… (スコア:2, すばらしい洞察)
フトのプロジェクトの言語別成就率であって、言語の使い
やすさ、将来性、成熟度などとは関係がなさそうですね。
テキスト中心のソースが容易にやり取りできる言語が上位
をたまたま占めているだけで、悲観することは全然ないで
しょう。所謂、エス・スラッシュ・プログラミングという
やつで、他のプロジェクトの産物を「ちょっと直し」で自
分のプロジェクトで使うため、プロジェクトの絶対数は
多いという結果です。
親子関係にあるＣとC++のプロジェクトの絶対数の上で、Ｃ
がまだまだ優位にあるのは、オープンソース系が保守的な
プロジェクトが多いか、小さなプロジェクトの集合でしか
ないことを物語っています。
Re:JavaとPerl (スコア:2, 参考になる)
そうそう。母集団の問題だよなコレは単に。
OldType主導の世界で計測すれば、そりゃそうだろ。
個人的趣味としては、これはOOP言語に対する煽りつーかFUDだと認定します(笑)。
単に「お前らが」使えてねーだけなんだろ、という。
逆にいうとあれかな。
「あなたがプロジェクトを始めるときには」、
このサンプルに該当するOldTypeな人々の中から
「プロジェクト参加者を選びなさい」という示唆なのか？
だとしたらなかなか捻くれて売りこみだな。
OldTypeに就職の機会を与えようという腹か？(笑)
勿論OOP言語でドキュンなコード書かれたら困りますが、
OOPじゃない言語でだってドキュンなの書かれたら同じことです。
実際そんなコードしか書かない奴は、今回の集計のScopeの「外」には一杯いるはず。
よだん：
選択するなら、PerlよりRubyっしょ。
C#については、どっかの誰かがFREEなC#実装を作ってませんでしたっけ？
それが出れば、言語としての筋自体は悪くないと思うんで、OKかなと。
JavaだってKaffeとか使えばいいんだしさ。
Re:C# (スコア:2, 興味深い)
DELEGATES(メソッド参照)って、J++事件のときに、Sunはそれを一蹴しましたよね。
Delphiでも使われてるアレ(ってことはHeji氏の手になるんだろうけど)
興味深いししばしば有用な技術だと、思うんだがなあ…
DEGEGATESといえば、Borlandにこんな特許が有るそうですが
http://www.borland.co.jp/news/patent.html
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=/netahtml/search-bool.html&r=1&f=G&l=50&co1=AND&d=ft00&s1=Hejlsberg&s2='6,185,728'&OS=Hejlsberg+AND+"6,185,728"&RS=Hejlsberg+AND+"6,185,728"
色々嫌な気分になるし、疑問も感じます。
この特許って、JBuilder(SunのPureJavaをターゲットとする環境)にも、
果たして当てはまる(上記日本語頁にはそう書いてますが)んだろうか？
完遂ってなんじゃらほい？ (スコア:2, 参考になる)
ここでいう「完遂」って、なに？
という疑問が有るっす。
かつて(だよね)ruby方面では、ライブラリ作る人ばっかりでアプリが出ないねえ、と嘆かれたことが有ったけど、
あーいうライブラリ作りってのは「完遂」に入るの入らないの？
ライブラリはアプリとしては出来てないから、エンドユーザー(笑)には使えない状態なのだけどさ。
で。OOPだと、ライブラリは(も)、同じ人がやっても混乱せずに(つまり比較的良質な)成果物を作れる、と
俺は思う(感じる)んだけど、どう？
ああ。「使う」って言葉の問題も有るよね。
RADのComponentばっかり「使う」しか能が無い人だと
確かにちとアレだってことも有るけども。
でも(クラス)ライブラリの作者も、言語を「使って」いるわけで、さ。
大昔、ダチがさ、
「メインを作るよりサブを作るほうにこそ、高いスキルを持った人が必要である」
ってなことを言っていたんだけど、
というわけで少なくとも「アプリを」完遂したかどうか？だけで
人を測るのは、どうも落ちつけないわけよ俺は。
Re:これですな (スコア:2, すばらしい洞察)
>>「死の行進」はさらに増えているのではないかと予想されます.
>……こうなっちゃったわけですね。┐(´ヘ`;)┌
ああ。あれか。
単に、「Cを知らなければUnixをいじれない」ってのと同じ意味で、
「Smalltalkを知らなければProject某をいじれない」
というだけの問題だと思うのだが。
Java使わなくたって、そういうプロジェクトは死の後進(ナイス誤変換)になることが
十分多いと思うけどな。
Cにしといたら後進せずに済んだであろう、とでも思うの？＞思ってる人
俺にはそっちこそが笑止に思えるのだが。
え？俺？「Pro*C」で死にましたともよ。あの糞言語め(T_T)
JDBCとかのほうがなんぼ良かった(=楽に同じ目的を果たせた)ことか！
#でも俺のは一応動いたけどさ
より洗練されたパラダイムを、使いこなせる人材が居たかどうか、という問題でしょ単に？
#洗練：新しいかどうかは別。Smalltalkだって十分古いし。
オブジェクト指向 (スコア:2, 参考になる)
ただ，C++（もしくはJava）で，他人との協業で何かしら作ろうとした場合，オブジェクト指向の解釈にギャップ（というか無知）がありすぎてお話にならない場合があり過ぎて困ることってありません？
オブジェクト指向を志すとき，まずは言語を無視してまずは「概念」を徹底的に叩き込まないと，ちょっと辛いような気がします．というのは，実際にコーディングしつつオブジェクト指向を学ぼうとすると，どうやら「クラスを作ることこそオブジェクト指向」みたいに，言語仕様とオブジェクト指向概念を混同してしまって切り分けが出来ない人が多いように思います．
そういう人が書くと，とりあえず最上階層のクラスのアクセスメソッドは打ち合わせ通りでも，その下位に位置する実際のコーディングはオブジェクト指向を全く無視した，よっぽどCで書いた方が効率が良いと思えてしまうものが圧倒的多数のような気がします．
「関数f(x1,x2,...,xn)」という取り扱い単位は，やはり高校の数学でも出てきたとおり理解しやすいのでしょうが，「クラスとインスタンス In(f1(x1,x2,...xn),f2(x1,x2,...xn),...,fn(x1,x2,...xn))」という考え方は，いわば多くの関数をひとつの大きな関数として扱い，その大きな関数をいくらでも生成して扱う，という考え方ですから，概念的にも高次元で，馴染みにくいのではないでしょうか．分かってしまえばこれほど理にかなったものもないのですが．
最低でもこの本を一度読んでからC++に入ることをお勧めしたいですね．この本は，概念と実装の解説のバランス，章立てのバランス，読者に情報を流し込む量とタイミングのバランスなどの観点から，卓越した名著のひとつだと思います．
optimized for /.
Re:完遂ってなんじゃらほい？ (スコア:2, すばらしい洞察)
あくまで、Open source系のプロジェクトの「完遂」度を開発言語で分類したら
こういう結果になりましたよ、ってなそのまんまの余談ネタで、誰もこれを使っ
て人種差別するようなことはない…と思います。もっとも、言語を測っている
としても、開発言語と人間が1対1で対応することを前提にした上で差別的言辞
を弄する人も多いから、どこぞの厨房ひしめくエリアではどうなるかわかりま
せんが。
確かにライブラリを作ろう、ってプロジェクトはどうなんだ？とか、プロジェ
クトの絶対数は？とか、そのプロジェクトの規模は？とか、そんなデータは
入ってないわけで、まあそれだけのもんでしょう。
強いて逆に見ると、これプロジェクトの無謀度を表していると思えるんですが、
まあ無謀なプロジェクトが多い言語ってのも魅力あるように思います。
なんか変な褒め方ですが。
-- We have to move on.
現在のインタフェース主義の問題 (スコア:2, 参考になる)
Object-orientedの問題として、「インタフェースさえ決めてしまえば自由に要素間の相互接続ができる」という迷信を世に広めてしまったことがあります(真実でないのは重々承知だけど、現場で手を動かさないヤツらは知ったこっちゃない)。その結果として、インタフェースの数が要素数の2乗のオーダで増えてしまい、かつそれらを全てdefineするはめになっています。きちんと解くべき問題の全体像を見ればなんとか木に近いところまで単純化できるでしょうが、大量のインタフェースから主要なものを見つけるのは時間がかかります(2乗を線形に落さなければならない)。
それから、インタフェースと内部実装の区別をつけないで話が進むことがあるのも問題です。インタフェースが同じであっても、内部実装は問題によって変えるべきかも知れません。これを無視して、実装ベタベタなインタフェースを作ってしまう失敗もよくあります。典型的な例はメモリアロケータです。メモリアロケータは外から見れば、メモリの確保と解放しかしません。しかし、kernelが用いるべきメモリアロケータでは、
などの要求や制約があります。それらに答えるのが、例えばzone allocatorであり、slab allocatorであるわけです。しかし、user process向けのアロケータではむしろ潤沢なアドレス空間を活用することが必要です。このため、一般にkernel用のアロケータとは別のやり方を使います。
これを避けるには、内部実装を複数通り試す必要があるでしょう。物事の本質を見る時によく使う手ですね。ただ、時間に追われている人たちにそんな余裕があるかどうか...
最後に、最近のObject-orientedなやり方では(昔からそうかも?)インタフェースのdefinitionが経時変化に対して非常に弱いという問題があります。Unixのkernelをいじっていて気がつきました。25年間もシステムを生き残らせるとなるとインタフェースを最初にガチガチに固めてしまうのは悪い結果しか出ません。逆にいえばブレイクスルーが最も狙えそうなところですが。
Re:OldTypeといえば (スコア:2)
JavaならThreadすればいいじゃん。
実践主義・現場主義復権のためには何をするべきか… (スコア:2, すばらしい洞察)
では如何にすべきか?やはり実践主義・現場主義を復権させるしかない のではないかと思います。もちろん、開発スケジュールに影響力を持つ 全ての人（=ビジネスの人を含む)に、です。そうすることで、
> 物事の本質を見る時によく使う手ですね。ただ、時間に追われて
難しい問題には試作の時間を確保できるように、仕事の流れの外枠を 変えていく、しかないかと思います。> いる人たちにそんな余裕があるかどうか...
私も、大学にいた頃はまだ設計重視派でしたが、フリーで仕事を請ける ようになってから半年もせずに「検証至上主義」に転向しました。 これが名のある一般企業であればもう少し長く設計重視派だったかも 知れませんが。やはり目の前に顧客がいる状況では、設計変更の リスクにいかにして対処するかがもっとも重要だと実感しました。 私が現在自分に課している規約は、
- 単体検査を通過していない部品は信用しない
- 頭の中だけで作ったライブラリAPIは信用しない。
実際に長期間複数のプログラムに使って便利だと思えるまで、
APIは確定させない。
- 顧客に試作品を触ってもらうまで、過剰な作り込みはしない。
です。多分、米国ではこういう問題の認識がもっと早く知れ渡り、 それが Extreme Programming(XP)やリファクタリングへと結実したのでしょう。でも、それが 日本に広まるにはまだ大分かかるんではないかとも思います。 何故なら、大分偏見が入ってますが、私の私見では最後に、インターフェースの経時変化に対しては、 なるべく構造体(への参照) 引数を用い、随伴情報の追加を容易にするのが私の好みですが、 何せクラスが更に増えて全体を複雑化してしまうので、 これも万能ではないですね。
Re:C# (スコア:2)
メソッド参照はあれば便利ですけど、ないと困るというほどでもないからじゃないかと思いますけどね。たぶん、ＶＭの実装上の問題が出るんじゃないかと。
それよりunsignedが8bitにしかないとか、unionがないとかの方が困るんだけどなぁ。画像処理の時のbit操作が大変で。
後、ＯＯＰ言語で「読み出しは誰でもＯＫ｣なメンバ変数がないのが、ちょっとやだな。
で、これがＣ＃にはあるんだよなぁ。
＞この特許って、JBuilderにも、果たして当てはまるんだろうか？
開発ツールに関する特許で、プログラム言語でのメソッド参照には関係しないと思いますけど？
Re:OldTypeといえば (スコア:2)
java.Runtime.exec() じゃ代わりにならんのかな？
Re:C# (スコア:2)
うーん私もＶＭの構造はよく理解してないので、気がする程度のものです (^^;;;
単純に考えれば、コンパイル時に呼び出し先を決められるＣ＋＋なんかと、実行時に呼び出し先を探しに行くＪａｖａでは、この辺の実装はかなり構造的に違ってくるんでないかと推測してるんですが。
＃Templete相当の機能が最初から実装されなかったのも、その辺が理由かなぁ？と。
＞Delphiには有りますね
Effelにもあります。つーか、DelphiはEffelを参考にしたと思います。純なOOPならあって当然だと思うんですが、Javaは純になりきれてない準なOOP言語ですね。
＞特許文面はメソッド参照云々って書いてるし
うーん、文面は読んでないですが、言語の文法は特許の対象にならないはずです。
Re:OldTypeといえば (スコア:2)
forkがない～～！つって叫ぶ連中に「あるよ｣と答えるためには意味があるかと(爆)
forkじゃご指摘のような問題があるからthreadが生まれたんで、threadがあればforkの意味ってないですけどね。
＃threadだとjavaの世界で閉じているというのが問題かもしれないけど。
JavaとPerl (スコア:1, 興味深い)
Java環境に問題があるのか、
Javaで始めようとする人に厨房が多いのか。
そして我らが偉大なるPerlは成功率5割。素晴らしい。
Delphi…… (スコア:1)
＞Delphi 0.042
我が愛しのDelphiがこんなところに……
(同じRAD系の)VisualBasicより上だから少しはましですけどね．
Re:プログラム言語やアルゴリズムだけに興味のある人 (スコア:1)
Javaでプログラムを作ると無駄にサブクラスを増やしてしまう私…
２年前からやってるはずのプロジェクト(趣味のね)は STEP1 達成後、１年以上進歩してないし…
…言語のせいだけでは無いのはたしかです…
Re:Delphi…… (スコア:1)
おそらくDelphiの場合はKylixも含まれているので、それが有利に働いているのだと思います。
でも，やっぱりOOPは楽だなぁ (スコア:1)
細かい実装を忘れても何とかなる＆部品部品の独立性を高くできるのは，いろいろと忘れっぽい私にとってはとても助かります．
そのうち，動作の目的だけを記述すれば良い（メソッド／データの実装だけではなくて，その動作も気にする必要が無い）ようなのが出てくるといいなぁ．
＃エージェント？
＜／オフトピ＞
言語の選択をプロジェクトの失敗の理由にするのは (スコア:1)
ェクトの成功・失敗に言語の選択は関係ないと思います。
たとえば、オブジェクト指向言語は、長期に亘って開発・
保守を繰り返すようなプロジェクトにのみ向くのであって、
「この言語だとこう書くだけで済む」というような考えで
言語を選択すべきではないと思います。
たとえ言語の選択を間違ったと思われても、まともなプロ
ジェクトであれば、最初のリリースぐらいは漕ぎ着けるは
ずです。UNIXだって、最初からＣで書かれたわけではない
のですから。
Re:Logo? (スコア:1)
それでも、TeXのような偉大なソフトウェアだってできるし、「…失敗に…」の中でも0.11の成功率を示しています。ま、この数値はそれなりに低いものとは言えなくもないですが(笑)。
「TeXはプロジェクトじゃない」(Knuthの個人的成果?)といわれそうなのがこの論の欠点か(爆)。
Re:Delphi…… (スコア:1)
ぎゃくにいうと…。
APL や Prolog が上位で、しかも Delphi や V B が下位である
原因の多くは、開発環境全体を見渡さないと理解できない
種類のものなのかも知れない、と思うんです。
すなわち、下位にランクされた言語にたいする責任は、
多くはＭ＄が負うべきではないか、と。
Re:OOPによる「死の行進」---詳しく教えて。 (スコア:1)
OOPの利点は？ (スコア:1)
へえ，そうなんですか？現場だとそんな感じなんですか……
OOPの利点って，機能単位に独立したクラス／コンポーネントによる，部品間の依存／結合性の最小化だと，私なんかは思うんですけどね
＃……って，OOPじゃ無くても出来ますね．OOPの方が楽なだけで．
＃まあ，サンデープログラマーのヨタです．聞き流してください．
Re:無理ありすぎというか面白くない (スコア:1)
>そもそもfreshmeatってUNIX文化の住人以外 にはよく知られていないのでは?
そうだろうけどそれはSourceforgeも同じでない?
いずれにせよ、これらのサイトの情報から C#について断を下すのは不可能って事には変わりない んですけどね。
Re:OOPによる「死の行進」 (スコア:1)
納得できないなぁ。オブジェクト指向を採用するのは、再利用性を向上することではなくて、生産性を向上することなんです。
例えば、インターフェースなどを切って境界面をはっきりさせて複数のグループで共通の分散して開発を進めたりすることに意義があるような気がします。
そのあたりの意識が薄いからプロジェクトが失敗しているのだと思うけど...。
Re:OOPによる「死の行進」 (スコア:1)
自己フォロー。
は、 と言いたかったのです。失礼しました。Re:無理ありすぎというか面白くない (スコア:1)
そうとも言い切れないような気がします。少なくとも Windows方面での認知度はそれなりにあると思います。例えば、 ここ とか見ると、POSIXが11654 projectsで断トツの一位ですけど、 Microsoftも5166 projectsありますし。 ダウンロード数 を見ても、Back Orifice 2000, VirtualDub, MiKTeX, Gnewtella, Gnucleus などが上位にあります。
OldTypeといえば (スコア:1)
膝カックン食らった気分になったんだけどさ、
「forkできない」っての(を問題だと見なすの)は、どうよ？
Javaでも似たような話があったと思うけど、
forkに頼りすぎたら、たとえばOOP言語とか、たとえば「環境」を提供する言語とか、たとえば(以下色々)と、
相性が悪いのは当然じゃん。
俺としてはforkはOldTypeに分類しています(笑)。
つーか、ということはProcessモデル、ひいてはunixを(笑)、Oldと見なすってことだけどさ。
で今回。母集団がアレっしょ？
うーん…
Re:いや、やはり相関はゼロではないと思います (スコア:1)
>もし相関がゼロなら、それを過激に言い換えると
相関がゼロだってのは間違いであり、かつ、
>> たとえば、オブジェクト指向言語は、長期に亘って
>> 開発・保守を繰り返すようなプロジェクトにのみ向く
という解釈もまた間違っているんじゃないかと、
希望的観測(^^;を述べておきます。
ほんの数行だってOOPのほうがいいよぉ。
つまり、相関がないんじゃなくて、相関が逆なんじゃないの？と
俺は主張(ええ。あくまで主張ですとも。悪ぅございましたね)しときたいです。
ただ、その逆であるはずの相関を反映できてない母集団を、観察してしまった、と(笑)。
Re:JavaとPerl (スコア:1)
母集団はあくまで Open Source 系ですよね。
一般の企業向けウェブサイト構築用言語としては
Java は標準言語として確立しているし
(しているように見えるんだが、うちの近所だけ？)、
Java に問題があるように思えないんですが…。
ところって、Perl って、そんなに偉大？
いや、スクリプト言語としては王者だと思いますけど。
入門書の多さからすると、厨房が手を出しても
なんとかなりやすい環境にあるから、
失敗率が少なくても当然っぽい気がするし、
言語仕様的にも(特にOOPという観点からすると)
もはや偉大ではなくなりつつあるような。
Re:いや、やはり相関はゼロではないと思います (スコア:1)
(未来永劫「数行」で済むという仮定の下で、ですが)
# 「数行」で書けない某言語もありますが。
月並みですが、何にでも OOP が向くと言う事はないでしょう...と、言われるのを承知で投稿されたとは思いますが念の為。
でもインターフェース策定の難しさに無頓着だと「死の (スコア:1)
- その問題領域に対する、自分(達)の経験・理解の深さ
- 問題の規模
- クラス「群」の設計に関する「落とし穴」と対処法を知っているか否か。
で大きく変化すると思います。OOP を導入するだけでなく、 この点を強く意識しておかないと「死の行進」に至る、そう思います。他人の作ったクラス群を使っているだけで済む場合は関係ないですが、 「プロジェクトで使うクラス群(フレームワーク)」を構築する場合には 特に重要だと思います。
サブジェクトが切れる～(Re:でもインターフェース策定 (スコア:1)
でもインターフェース策定の難しさに無頓着だと「死の行進」に至る、と思う
のつもりでした。何か、プレビューよりもサブジェクトが短くなる気がする。気のせい？