パスワードを忘れた? アカウント作成
1164 story

プロジェクトを失敗に導くプログラミング言語 83

ストーリー by kazekiri
C#を使うと必ずあなたのプロジェクトは失敗する 部門より
プロジェクトを失敗に導くプログラミング言語という文書が 公開されている。 この文書では、各プログラミング言語に対して、 freshmeatでアナウンスされたプロジェクトの数を sourceforgeに登録されているプロジェクトの数 で割った値をフリーソフトウェア開発プロジェクトの成功率としてみなし、 その一覧を公開している。意外にTcl, Rubyの値が高い気もするが、C, PHP あたりは妥当なところか。かなりad-hocな指標だが、 それなりに考えさせられる。 「C#を使うと必ずあなたのプロジェクトは失敗する」の一言は実にいいね。
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • Re:C# (スコア:3, 参考になる)

    by rug (55) on 2001年09月22日 21時53分 (#24324) 日記
    > 規定打数に達してないデータは統計から外す、と。

    どのくらいに設定すればいいんだろう? 10くらいかな? ここを見ると、C#なProjectってRubyやSmalltalkより多いんだよね。まあでも、APLは明らかに外すべきだろうな。:-)

    > ちなみに、C#はTurboPascal、Delphi、J++の開発に加わっていたAnders Hejlsberg氏もからんでますし

    JavaとDelphiをmixしたような言語とはよく言われていますな。:-)

    > まだVSのベータ版が出てるだけだから、C#はまだルーキー以前でしょう。

    そうですね。だから、どうせ「C#はprojectを失敗に導く」といいたいなら、その未成熟さを根拠にすればいいのにね。件の文書はjokeとして見ても出来が悪すぎ。
  • Re:C# (スコア:3, 興味深い)

    by zeissmania (3689) on 2001年09月22日 22時37分 (#24334)
    >C#はTurboPascal、Delphi、J++の開発に加わっていたAnders Hejlsberg氏もからんでます
    ので、発表された時の仕様書を読んで、言語仕様だけは素晴らしいと思いました。
    #実装がどうなるかは、また別の話だから。
    まじに、Javaに導入してほしい言語仕様が満載なんですよねぇ~。JDK1.4辺りで追加してくれんだろうか?
  • OOPによる「死の行進」 (スコア:3, すばらしい洞察)

    by SteppingWind (2654) on 2001年09月23日 2時34分 (#24356)

    まあ, フリーソフトに限らずOOPを開発言語に選んだプロジェクトが失敗ないしは完成しても赤を出すなんてことは良く聞く話です.

    原因は簡単なことで, システムの分析・設計段階がOOじゃないからです. 実際のところOOP言語が使えるプログラマを100人程度そろえるのは大した苦労じゃないのですが, OO分析・設計ができるSEを5人そろえるなんてのは, よほどのBigプロジェクトでなければ半分以上運まかせに近い状態です. 又, OO分析・設計は見た目とは逆にRADになじまないというのも, RAD上がりのプログラマが上流フェーズで使い物になりにくい原因だとおもわれます.

    逆に言えばOOP言語を使っても再利用可能なClass・設計の蓄積が無い分, 従来の言語と生産性は変わらず, むしろ不慣れな分だけ生産性が落ちるというのが現実です. しかも悪いことにOOP言語ではClassの再利用で生産性が上がるという一般論を, 前提を無視して盲信している人が多いのも現場にいる人間には困りものです.

    OOPを使ったことによる「死の行進」の実例として有名なものにはIBMがSmalltalkを使って構築しようとした九州大学医学部のシステムが有りますが, 近年のJavaのブームによって, 潜在的な「死の行進」はさらに増えているのではないかと予想されます.

    ちなみに私自身がうまくいったOOシステムの開発にかかわったのは1回しかありません.

  • これですな (スコア:3, 参考になる)

    by fluffy_nns (4030) on 2001年09月23日 7時26分 (#24383) ホームページ
    >OOPを使ったことによる「死の行進」の実例として有名なものには
    >IBMがSmalltalkを使って構築しようとした九州大学医学部の
    >システムが有りますが, 近年のJavaのブームによって, 潜在的な
    >「死の行進」はさらに増えているのではないかと予想されます.

    http://www3.nikkeibp.co.jp/WAT2/970516/970516trein01.html

    これが……

    http://www3.nikkeibp.co.jp/WAT2/971212/971212trein01.html

    ……こうなっちゃったわけですね。┐(´ヘ`;)┌

    ……いや、嗤わない方がいいか。

  • by kt (4556) on 2001年09月23日 10時27分 (#24393)

    MonodotGNU のようなプロジェクトもあって、オープンソースの C# というのは近い将来の成長分野かもしれないですね。

    それをいきなり「100パーセント潰れる」というのは、開発途上のプロジェクトに水をかけるようで、あんまり感じ良くないと思います。

  • Re:JavaとPerl (スコア:2, すばらしい洞察)

    by oku (4610) on 2001年09月22日 20時04分 (#24310) 日記
    単に hacker の language of choice としては、まだ Java が普及していないだけではないでしょうか。
    C は誰でも知っていて、それだけ contrib 可能性が高いという事だと推察します。
    でも、 http://www.gyve.org/~jet/lang2.txt に関しては、出来れば「率」だけでなく「数」も掲示いただけると信頼度とかも読み取れてよりありがたかったのですが。
  • 言語で比較するのは手っ取り早そうですねぇ。

    プロジェクトの規模とか、プラットフォームとか、
    参加者の数とか、その辺での比較の方が興味あります。

    失敗したプロジェクトは、言語を使う以前に
    なくなったかも知れませんし(笑)
  • by rug (55) on 2001年09月22日 20時35分 (#24314) 日記
    > 「C#を使うと必ずあなたのプロジェクトは失敗する」の一言は実にいいね。

    OpenGL & SDL for C#NUnit などはfreshmeatにproject pageがあるから、実際には0じゃないんだよね。

    それに開発言語にC#を選択しているケースっていうのは.NET frameworkに乗っかるというか、UNIXをtargetとして考えていないでしょ? そういうsoftwareのほとんどは(有名どころでも)freshmeatにannounceされていないのが現状だと思うが。というか、そもそもfreshmeatってUNIX文化の住人以外にはよく知られていないのでは?
  • by Anonymous Coward on 2001年09月22日 20時39分 (#24315)
    確かにプログラム言語やアルゴリズムだけに興味のある人はハローワールドやwindowやダイヤログを
    出しただけでプログラムを作った気になっている人が多い気がする。
    そういう人のプロジェクトは大抵興味だけで推進されるので結果的に完遂しないことが多い。

    何か明確な目標があって(例えばゲーム作りたいとか)、
    そのために言語を学んだ人はそのプログラムは稚拙だが、
    ちゃんとプロジェクトを完遂することが多い気がする。

    前者ほどOOP寄りの言語を使い、後者ほどOOPでない言語
    で間に合っている場合が多いことは色々考えさせられる
    問題な気がする。
  • C# (スコア:2, 興味深い)

    by shikine (296) on 2001年09月22日 20時59分 (#24317) ホームページ 日記
    単なる確率なら、一つしかないプロジェクトが潰れても、「100パーセント潰れる」って言えるわけだし・・・。今、野球のナイターみてるんだけど、バッターの打率と同じで、規定打数に達してないデータは統計から外す、と。

    ちなみに、C#はTurboPascal、Delphi、J++の開発に加わっていたAnders Hejlsberg氏もからんでますし、MSの製品だから、「これから」だと思いますね。まだVSのベータ版が出てるだけだから、C#はまだルーキー以前でしょう。

    と、知らない言語について大言を吐くこの頃であった。

    --
    他力本願。
  • 過去の記事プログラミング言語バイトルロイヤルと比べると、やっぱりC言語のポイントは高いですね。
    これと比べると、言語のパフォーマンスと、プロジェクト成功率の関係が見えておもしろいです。
    パフォーマンスが低い言語のほうが簡単で、プロジェクト成功率も高いと思いますが、CとC++は両方とも結構いいポジションにいますね。

    ともかく自分自身C++が一番好きなので、プロジェクト成功率ももっと上がるといいなぁと思います。
  • by zeissmania (3689) on 2001年09月22日 22時33分 (#24331)
    JavaはC++からの移行が簡単なだけに、C++と同じようなつもりでコーディングする人が多数だからでしょう。
    実際はC++とは全く考え方の異なるクラス設計やコーディングが必要なんだけどね。
    私の周りでも、その辺を判ってなくて失敗する人が結構います。
    私個人に限って言えば、C++よりJavaを選びます。ま、Javaライブラリの一部に問題があることも事実ですが。
  • by crouton (9) on 2001年09月22日 23時32分 (#24340)
    じゃ、商品としても成功したってことで、Wizardry。
    --
    "Quidquid latine dictum sit, altum videtur."
  • これって、あくまでリリースができたかどうかが観点で、そのプロジェクトが続いているかどうかはまた別の問題じゃないでしょうか。

  • 多少なりとも言語作りに関心のある者としては nmuraoka さんの結論は看過できません。

    もし相関がゼロなら、それを過激に言い換えると

    • 「プロジェクトの成功には言語の選択は全く寄与 しない」
    • 「良い言語を作ろう、という言語屋の努力は、 現実のプロジェクトには全く役に立っていない」、
    • 「言語の良し悪し以外の要素(例えば、その言語を 習得している人が多いか少ないか)も関係ない」
    って意味になると思います。でも、さすがに その結論は極論過ぎるかも。

    もっとも、nmuraoka さん自身も

    > たとえば、オブジェクト指向言語は、長期に亘って
    > 開発・保守を繰り返すようなプロジェクトにのみ向く

    と言っておられるので、相関が有ることは分かって おられるとは思うんですが。

    私としては、プロジェクトの分野と規模、 自分(達)の「問題理解度」を にらんで、適切な道具を使い分けるべきだと考えて います。自分の理解度・経験が不足している領域に、 型付きの OOP 系コンパイラ言語でトップダウン設計で 一発勝負を挑んだ場合、少なからず悲惨な結果が 待っている、そう思っています。

    理解が不足しているなら簡易言語で何度も プロトタイプを作っては捨て、理解を深めてから 設計を練り直し、厳密な言語で一気に書き上げる、 そういう流れが実践主義者向きで、私は好きです。 (汚くても動くプロトタイプが有れば、 仕事を前に進められるし)

    また場合によっては、新たな言語を 覚えることになっても良いでしょう。例えば私の 得意は perl と C++ ですが、シリアルポート経由で 他のマシンを操作するプログラムを書く必要が 生じたので、そのために expect を覚えたりもしました。同じ問題を perl で書くのは 大分大変だったろうと今でも思います。(expect 自体には大変ストレスを感じましたが… use strict や bless, @ISA が無いのは辛い…)

  • by fluffy_nns (4030) on 2001年09月23日 7時13分 (#24381) ホームページ
    Java陣営の訴えるJavaを使う利点って、
    レトリック臭いなぁってかんじるのは
    俺だけなのかなぁ?

    そういうところが敬遠されてるとか?

    #悪く言うと宗教 :-p
  • Re:Delphi…… (スコア:2, すばらしい洞察)

    by nmuraoka (5310) on 2001年09月23日 7時42分 (#24384)
    今回公開されたこのデータはオープンソース系のフリーソ
    フトのプロジェクトの言語別成就率であって、言語の使い
    やすさ、将来性、成熟度などとは関係がなさそうですね。

    テキスト中心のソースが容易にやり取りできる言語が上位
    をたまたま占めているだけで、悲観することは全然ないで
    しょう。所謂、エス・スラッシュ・プログラミングという
    やつで、他のプロジェクトの産物を「ちょっと直し」で自
    分のプロジェクトで使うため、プロジェクトの絶対数は
    多いという結果です。

    親子関係にあるCとC++のプロジェクトの絶対数の上で、C
    がまだまだ優位にあるのは、オープンソース系が保守的な
    プロジェクトが多いか、小さなプロジェクトの集合でしか
    ないことを物語っています。
  • Re:JavaとPerl (スコア:2, 参考になる)

    by G7 (3009) on 2001年09月23日 13時09分 (#24407)
    >hacker の language of choice としては

    そうそう。母集団の問題だよなコレは単に。
    OldType主導の世界で計測すれば、そりゃそうだろ。

    個人的趣味としては、これはOOP言語に対する煽りつーかFUDだと認定します(笑)。
    単に「お前らが」使えてねーだけなんだろ、という。

    逆にいうとあれかな。
    「あなたがプロジェクトを始めるときには」、
    このサンプルに該当するOldTypeな人々の中から
    「プロジェクト参加者を選びなさい」という示唆なのか?

    だとしたらなかなか捻くれて売りこみだな。
    OldTypeに就職の機会を与えようという腹か?(笑)

    勿論OOP言語でドキュンなコード書かれたら困りますが、
    OOPじゃない言語でだってドキュンなの書かれたら同じことです。
    実際そんなコードしか書かない奴は、今回の集計のScopeの「外」には一杯いるはず。

    よだん:
    選択するなら、PerlよりRubyっしょ。

    C#については、どっかの誰かがFREEなC#実装を作ってませんでしたっけ?
    それが出れば、言語としての筋自体は悪くないと思うんで、OKかなと。

    JavaだってKaffeとか使えばいいんだしさ。
  • Re:C# (スコア:2, 興味深い)

    by G7 (3009) on 2001年09月23日 13時29分 (#24409)
    >Javaに導入してほしい言語仕様が満載なんですよねぇ~。JDK1.4辺りで追加してくれんだろうか?

    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をターゲットとする環境)にも、
    果たして当てはまる(上記日本語頁にはそう書いてますが)んだろうか?
  • by G7 (3009) on 2001年09月23日 13時46分 (#24412)
    確かに耳が痛い面もあるんだけどさ、
    ここでいう「完遂」って、なに?
    という疑問が有るっす。

    かつて(だよね)ruby方面では、ライブラリ作る人ばっかりでアプリが出ないねえ、と嘆かれたことが有ったけど、
    あーいうライブラリ作りってのは「完遂」に入るの入らないの?
    ライブラリはアプリとしては出来てないから、エンドユーザー(笑)には使えない状態なのだけどさ。

    で。OOPだと、ライブラリは(も)、同じ人がやっても混乱せずに(つまり比較的良質な)成果物を作れる、と
    俺は思う(感じる)んだけど、どう?

    ああ。「使う」って言葉の問題も有るよね。
    RADのComponentばっかり「使う」しか能が無い人だと
    確かにちとアレだってことも有るけども。
    でも(クラス)ライブラリの作者も、言語を「使って」いるわけで、さ。

    大昔、ダチがさ、
    「メインを作るよりサブを作るほうにこそ、高いスキルを持った人が必要である」
    ってなことを言っていたんだけど、
    というわけで少なくとも「アプリを」完遂したかどうか?だけで
    人を測るのは、どうも落ちつけないわけよ俺は。
  • Re:これですな (スコア:2, すばらしい洞察)

    by G7 (3009) on 2001年09月23日 13時55分 (#24414)
    >>システムが有りますが, 近年のJavaのブームによって, 潜在的な
    >>「死の行進」はさらに増えているのではないかと予想されます.

    >……こうなっちゃったわけですね。┐(´ヘ`;)┌

    ああ。あれか。
    単に、「Cを知らなければUnixをいじれない」ってのと同じ意味で、
    「Smalltalkを知らなければProject某をいじれない」
    というだけの問題だと思うのだが。

    Java使わなくたって、そういうプロジェクトは死の後進(ナイス誤変換)になることが
    十分多いと思うけどな。

    Cにしといたら後進せずに済んだであろう、とでも思うの?>思ってる人
    俺にはそっちこそが笑止に思えるのだが。

    え?俺?「Pro*C」で死にましたともよ。あの糞言語め(T_T)
    JDBCとかのほうがなんぼ良かった(=楽に同じ目的を果たせた)ことか!
    #でも俺のは一応動いたけどさ

    より洗練されたパラダイムを、使いこなせる人材が居たかどうか、という問題でしょ単に?

    #洗練:新しいかどうかは別。Smalltalkだって十分古いし。
  • by optimized (4229) on 2001年09月23日 16時03分 (#24431)
     基本的に同意いたします.
     ただ,C++(もしくはJava)で,他人との協業で何かしら作ろうとした場合,オブジェクト指向の解釈にギャップ(というか無知)がありすぎてお話にならない場合があり過ぎて困ることってありません?
     オブジェクト指向を志すとき,まずは言語を無視してまずは「概念」を徹底的に叩き込まないと,ちょっと辛いような気がします.というのは,実際にコーディングしつつオブジェクト指向を学ぼうとすると,どうやら「クラスを作ることこそオブジェクト指向」みたいに,言語仕様とオブジェクト指向概念を混同してしまって切り分けが出来ない人が多いように思います.
     そういう人が書くと,とりあえず最上階層のクラスのアクセスメソッドは打ち合わせ通りでも,その下位に位置する実際のコーディングはオブジェクト指向を全く無視した,よっぽどCで書いた方が効率が良いと思えてしまうものが圧倒的多数のような気がします.
     「関数f(x1,x2,...,xn)」という取り扱い単位は,やはり高校の数学でも出てきたとおり理解しやすいのでしょうが,「クラスとインスタンス In(f1(x1,x2,...xn),f2(x1,x2,...xn),...,fn(x1,x2,...xn))」という考え方は,いわば多くの関数をひとつの大きな関数として扱い,その大きな関数をいくらでも生成して扱う,という考え方ですから,概念的にも高次元で,馴染みにくいのではないでしょうか.分かってしまえばこれほど理にかなったものもないのですが.
     最低でもこの本を一度読んでからC++に入ることをお勧めしたいですね.この本は,概念と実装の解説のバランス,章立てのバランス,読者に情報を流し込む量とタイミングのバランスなどの観点から,卓越した名著のひとつだと思います.
    --
    optimized for /.
  • by Head_Syndicate (5551) on 2001年09月23日 16時10分 (#24432)
    勇み足だと思いますが、「人を測っている」わけではないのでは?

    あくまで、Open source系のプロジェクトの「完遂」度を開発言語で分類したら
    こういう結果になりましたよ、ってなそのまんまの余談ネタで、誰もこれを使っ
    て人種差別するようなことはない…と思います。もっとも、言語を測っている
    としても、開発言語と人間が1対1で対応することを前提にした上で差別的言辞
    を弄する人も多いから、どこぞの厨房ひしめくエリアではどうなるかわかりま
    せんが。

    確かにライブラリを作ろう、ってプロジェクトはどうなんだ?とか、プロジェ
    クトの絶対数は?とか、そのプロジェクトの規模は?とか、そんなデータは
    入ってないわけで、まあそれだけのもんでしょう。

    強いて逆に見ると、これプロジェクトの無謀度を表していると思えるんですが、
    まあ無謀なプロジェクトが多い言語ってのも魅力あるように思います。
    なんか変な褒め方ですが。
    --
    -- We have to move on.
  • by brake-handle (5065) on 2001年09月23日 16時52分 (#24441)

    Object-orientedの問題として、「インタフェースさえ決めてしまえば自由に要素間の相互接続ができる」という迷信を世に広めてしまったことがあります(真実でないのは重々承知だけど、現場で手を動かさないヤツらは知ったこっちゃない)。その結果として、インタフェースの数が要素数の2乗のオーダで増えてしまい、かつそれらを全てdefineするはめになっています。きちんと解くべき問題の全体像を見ればなんとか木に近いところまで単純化できるでしょうが、大量のインタフェースから主要なものを見つけるのは時間がかかります(2乗を線形に落さなければならない)。

    それから、インタフェースと内部実装の区別をつけないで話が進むことがあるのも問題です。インタフェースが同じであっても、内部実装は問題によって変えるべきかも知れません。これを無視して、実装ベタベタなインタフェースを作ってしまう失敗もよくあります。典型的な例はメモリアロケータです。メモリアロケータは外から見れば、メモリの確保と解放しかしません。しかし、kernelが用いるべきメモリアロケータでは、

    • 高速でなければならない。
    • フットプリントが小さくなければならない。
    • ページ管理機構との相互作用が必要。
    • サイズの小さなメモリを頻繁に確保したい。

    などの要求や制約があります。それらに答えるのが、例えばzone allocatorであり、slab allocatorであるわけです。しかし、user process向けのアロケータではむしろ潤沢なアドレス空間を活用することが必要です。このため、一般にkernel用のアロケータとは別のやり方を使います。

    これを避けるには、内部実装を複数通り試す必要があるでしょう。物事の本質を見る時によく使う手ですね。ただ、時間に追われている人たちにそんな余裕があるかどうか...

    最後に、最近のObject-orientedなやり方では(昔からそうかも?)インタフェースのdefinitionが経時変化に対して非常に弱いという問題があります。Unixのkernelをいじっていて気がつきました。25年間もシステムを生き残らせるとなるとインタフェースを最初にガチガチに固めてしまうのは悪い結果しか出ません。逆にいえばブレイクスルーが最も狙えそうなところですが。

  • by zeissmania (3689) on 2001年09月23日 17時57分 (#24457)
    >「forkできない」っての(を問題だと見なすの)は、どうよ?
    JavaならThreadすればいいじゃん。
  • brake-handle さんの意見に賛成です。 良いインターフェースを一発で策定し、未来永劫変えなくて済む、 なんて事は滅多にないだろうと思います。また、インターフェース量の 増大がそれ自体問題になるという指摘にも賛成です。教科書・ 演習レベルでは問題にならないことが、現場では問題になる、という 好例だと思います。

    では如何にすべきか?やはり実践主義・現場主義を復権させるしかない のではないかと思います。もちろん、開発スケジュールに影響力を持つ 全ての人(=ビジネスの人を含む)に、です。そうすることで、

      > 物事の本質を見る時によく使う手ですね。ただ、時間に追われて
      > いる人たちにそんな余裕があるかどうか...
    難しい問題には試作の時間を確保できるように、仕事の流れの外枠を 変えていく、しかないかと思います。

    私も、大学にいた頃はまだ設計重視派でしたが、フリーで仕事を請ける ようになってから半年もせずに「検証至上主義」に転向しました。 これが名のある一般企業であればもう少し長く設計重視派だったかも 知れませんが。やはり目の前に顧客がいる状況では、設計変更の リスクにいかにして対処するかがもっとも重要だと実感しました。 私が現在自分に課している規約は、

    • 単体検査を通過していない部品は信用しない
    • 頭の中だけで作ったライブラリAPIは信用しない。 実際に長期間複数のプログラムに使って便利だと思えるまで、 APIは確定させない。
    • 顧客に試作品を触ってもらうまで、過剰な作り込みはしない。
    です。多分、米国ではこういう問題の認識がもっと早く知れ渡り、 それが Extreme Programming(XP)リファクタリングへと結実したのでしょう。でも、それが 日本に広まるにはまだ大分かかるんではないかとも思います。 何故なら、大分偏見が入ってますが、私の私見では
    1. 実践主義は理論指向のアカデミズムと相反する。よって、 一部の情熱ある例外を除き、大学は実践主義を教えない、 教えられない。
    2. 現場には、APIの変更を設計失敗の証拠と捉え、 過度にネガティブに捉える傾向がある。恥の文化の国民性から (あるいは、工学を知らない現場に有りがちな根性主義・才能主義から) バグを出した人間を糾弾するチームとか、有りがちです。 QC 的視点(人は必ず過ちを犯す。糾弾しようが、 根性を出そうが。)が日本のソフトウェア開発の現場に浸透する 予兆は、今のところ見いだせない。

    最後に、インターフェースの経時変化に対しては、 なるべく構造体(への参照) 引数を用い、随伴情報の追加を容易にするのが私の好みですが、 何せクラスが更に増えて全体を複雑化してしまうので、 これも万能ではないですね。

  • by zeissmania (3689) on 2001年09月24日 2時41分 (#24567)
    >DELEGATES(メソッド参照)って、J++事件のときに、Sunはそれを一蹴しましたよね
    メソッド参照はあれば便利ですけど、ないと困るというほどでもないからじゃないかと思いますけどね。たぶん、VMの実装上の問題が出るんじゃないかと。
    それよりunsignedが8bitにしかないとか、unionがないとかの方が困るんだけどなぁ。画像処理の時のbit操作が大変で。
    後、OOP言語で「読み出しは誰でもOK」なメンバ変数がないのが、ちょっとやだな。
    で、これがC#にはあるんだよなぁ。

    >この特許って、JBuilderにも、果たして当てはまるんだろうか?
    開発ツールに関する特許で、プログラム言語でのメソッド参照には関係しないと思いますけど?
  • by zeissmania (3689) on 2001年09月24日 13時40分 (#24624)
    >fork相当のものは…
    java.Runtime.exec() じゃ代わりにならんのかな?
  • by zeissmania (3689) on 2001年09月24日 13時53分 (#24629)
    >と同じ程度の負担しか無いような気がしますけど
    うーん私もVMの構造はよく理解してないので、気がする程度のものです (^^;;;
    単純に考えれば、コンパイル時に呼び出し先を決められるC++なんかと、実行時に呼び出し先を探しに行くJavaでは、この辺の実装はかなり構造的に違ってくるんでないかと推測してるんですが。
    #Templete相当の機能が最初から実装されなかったのも、その辺が理由かなぁ?と。

    >Delphiには有りますね
    Effelにもあります。つーか、DelphiはEffelを参考にしたと思います。純なOOPならあって当然だと思うんですが、Javaは純になりきれてない準なOOP言語ですね。

    >特許文面はメソッド参照云々って書いてるし
    うーん、文面は読んでないですが、言語の文法は特許の対象にならないはずです。
  • by zeissmania (3689) on 2001年09月24日 20時53分 (#24685)
    >動くかといえば動くんでしょうけど、「意味」無いっす
    forkがない~~!つって叫ぶ連中に「あるよ」と答えるためには意味があるかと(爆)
    forkじゃご指摘のような問題があるからthreadが生まれたんで、threadがあればforkの意味ってないですけどね。
    #threadだとjavaの世界で閉じているというのが問題かもしれないけど。
  • JavaとPerl (スコア:1, 興味深い)

    by Anonymous Coward on 2001年09月22日 19時26分 (#24308)
    JavaがCよりもぜんぜん完成に結びつかないのは、
    Java環境に問題があるのか、
    Javaで始めようとする人に厨房が多いのか。

    そして我らが偉大なるPerlは成功率5割。素晴らしい。
  • by Nowake (5100) on 2001年09月22日 20時08分 (#24311)
    うううう
    >Delphi 0.042
    我が愛しのDelphiがこんなところに……

    (同じRAD系の)VisualBasicより上だから少しはましですけどね.
  • うみゅ…耳が痛いです。

    Javaでプログラムを作ると無駄にサブクラスを増やしてしまう私…

    2年前からやってるはずのプロジェクト(趣味のね)は STEP1 達成後、1年以上進歩してないし…

    …言語のせいだけでは無いのはたしかです…

  • by rug (55) on 2001年09月22日 21時59分 (#24327) 日記
    > (同じRAD系の)VisualBasicより上だから

    おそらくDelphiの場合はKylixも含まれているので、それが有利に働いているのだと思います。
  • <オフトピ>
    細かい実装を忘れても何とかなる&部品部品の独立性を高くできるのは,いろいろと忘れっぽい私にとってはとても助かります.


    そのうち,動作の目的だけを記述すれば良い(メソッド/データの実装だけではなくて,その動作も気にする必要が無い)ようなのが出てくるといいなぁ.
    #エージェント?
    </オフトピ>
  • 言語そのものが開発目的と関係ある場合を除いて、プロジ
    ェクトの成功・失敗に言語の選択は関係ないと思います。
    たとえば、オブジェクト指向言語は、長期に亘って開発・
    保守を繰り返すようなプロジェクトにのみ向くのであって、
    「この言語だとこう書くだけで済む」というような考えで
    言語を選択すべきではないと思います。

    たとえ言語の選択を間違ったと思われても、まともなプロ
    ジェクトであれば、最初のリリースぐらいは漕ぎ着けるは
    ずです。UNIXだって、最初からCで書かれたわけではない
    のですから。
  • by nackey (3237) on 2001年09月22日 23時24分 (#24339)
    Pascalだって、Wirth御大は教育用と銘打っていたはずですね。
    それでも、TeXのような偉大なソフトウェアだってできるし、「…失敗に…」の中でも0.11の成功率を示しています。ま、この数値はそれなりに低いものとは言えなくもないですが(笑)。

    「TeXはプロジェクトじゃない」(Knuthの個人的成果?)といわれそうなのがこの論の欠点か(爆)。
  • by hokrin (slashdot) (1312) on 2001年09月23日 1時18分 (#24350) 日記
    >おそらくDelphiの場合はKylixも含まれているので、それが有利に働いているのだと思います。

    ぎゃくにいうと…。

    APL や Prolog が上位で、しかも Delphi や V B が下位である
    原因の多くは、開発環境全体を見渡さないと理解できない
    種類のものなのかも知れない、と思うんです。

    すなわち、下位にランクされた言語にたいする責任は、
    多くはM$が負うべきではないか、と。
  • なるほど。 >システムの分析・設計段階がOOじゃないからです ここのところを詳しく教えてください。
  • by Nowake (5100) on 2001年09月23日 3時44分 (#24365)
    >しかも悪いことにOOP言語ではClassの再利用で生産性が上がるという一般論を, 前提を無視して盲信している人が多いのも現場にいる人間には困りものです.

    へえ,そうなんですか?現場だとそんな感じなんですか……
    OOPの利点って,機能単位に独立したクラス/コンポーネントによる,部品間の依存/結合性の最小化だと,私なんかは思うんですけどね
    #……って,OOPじゃ無くても出来ますね.OOPの方が楽なだけで.

    #まあ,サンデープログラマーのヨタです.聞き流してください.
  • >そもそもfreshmeatってUNIX文化の住人以外 にはよく知られていないのでは?

    そうだろうけどそれはSourceforgeも同じでない?

    いずれにせよ、これらのサイトの情報から C#について断を下すのは不可能って事には変わりない んですけどね。

  • しかも悪いことにOOP言語ではClassの再利用で生産性が上がるという一般論を, 前提を無視して盲信している人が多いのも現場にいる人間には困りものです.
    納得できないなぁ。

    オブジェクト指向を採用するのは、再利用性を向上することではなくて、生産性を向上することなんです。

    例えば、インターフェースなどを切って境界面をはっきりさせて複数のグループで共通の分散して開発を進めたりすることに意義があるような気がします。

    そのあたりの意識が薄いからプロジェクトが失敗しているのだと思うけど...。

  • 自己フォロー。

    インターフェースなどを切って境界面をはっきりさせて複数のグループで共通の分散して開発を進めたりすることに意義がある
    は、
    インターフェースを切って問題領域の境界面をはっきりさせ、複数のグループで共通の意識をもちつつ分散して開発を進めたりすることに意義がある
    と言いたかったのです。失礼しました。

  • > そうだろうけどそれはSourceforgeも同じでない?

    そうとも言い切れないような気がします。少なくとも Windows方面での認知度はそれなりにあると思います。例えば、 ここ とか見ると、POSIXが11654 projectsで断トツの一位ですけど、 Microsoftも5166 projectsありますし。 ダウンロード数 を見ても、Back Orifice 2000, VirtualDub, MiKTeX, Gnewtella, Gnucleus などが上位にあります。
  • by G7 (3009) on 2001年09月23日 13時14分 (#24408)
    こないだのBSDマガジンの、焼肉のところ(笑)を読んで、
    膝カックン食らった気分になったんだけどさ、

    「forkできない」っての(を問題だと見なすの)は、どうよ?

    Javaでも似たような話があったと思うけど、
    forkに頼りすぎたら、たとえばOOP言語とか、たとえば「環境」を提供する言語とか、たとえば(以下色々)と、
    相性が悪いのは当然じゃん。

    俺としてはforkはOldTypeに分類しています(笑)。
    つーか、ということはProcessモデル、ひいてはunixを(笑)、Oldと見なすってことだけどさ。

    で今回。母集団がアレっしょ?
    うーん…
  • というよりも、

    >もし相関がゼロなら、それを過激に言い換えると

    相関がゼロだってのは間違いであり、かつ、

    >> たとえば、オブジェクト指向言語は、長期に亘って
    >> 開発・保守を繰り返すようなプロジェクトにのみ向く

    という解釈もまた間違っているんじゃないかと、
    希望的観測(^^;を述べておきます。

    ほんの数行だってOOPのほうがいいよぉ。

    つまり、相関がないんじゃなくて、相関がなんじゃないの?と
    俺は主張(ええ。あくまで主張ですとも。悪ぅございましたね)しときたいです。

    ただ、その逆であるはずの相関を反映できてない母集団を、観察してしまった、と(笑)。
  • 完成に結びつかないって…
    母集団はあくまで Open Source 系ですよね。

    一般の企業向けウェブサイト構築用言語としては
    Java は標準言語として確立しているし
    (しているように見えるんだが、うちの近所だけ?)、
    Java に問題があるように思えないんですが…。

    ところって、Perl って、そんなに偉大?
    いや、スクリプト言語としては王者だと思いますけど。
    入門書の多さからすると、厨房が手を出しても
    なんとかなりやすい環境にあるから、
    失敗率が少なくても当然っぽい気がするし、
    言語仕様的にも(特にOOPという観点からすると)
    もはや偉大ではなくなりつつあるような。

  • 「ほんの数行」なら私は FORTRAN か BASIC か awk を選びます。
    (未来永劫「数行」で済むという仮定の下で、ですが)
    # 「数行」で書けない某言語もありますが。

    月並みですが、何にでも OOP が向くと言う事はないでしょう...と、言われるのを承知で投稿されたとは思いますが念の為。
  • インターフェース策定の難易度は、
    1. その問題領域に対する、自分(達)の経験・理解の深さ
    2. 問題の規模
    3. クラス「群」の設計に関する「落とし穴」と対処法を知っているか否か。
    で大きく変化すると思います。OOP を導入するだけでなく、 この点を強く意識しておかないと「死の行進」に至る、そう思います。

    他人の作ったクラス群を使っているだけで済む場合は関係ないですが、 「プロジェクトで使うクラス群(フレームワーク)」を構築する場合には 特に重要だと思います。

    1. 自分(達)がよく知っている、あるいは教科書等で広く解法が 知られている領域なら、インターフェース設計から入っても良いと 思います。ですが、自分達の問題理解が不足している時に、 試作をすっ飛ばして設計を始めた場合、「かゆいところに手の届かない」 「観念だけで作ったような」インターフェースになってしまいがちだ、 と思います。 
    2. 人間の論理的思考能力およびイメージ想像能力には限界が有ります。(個人差はありますが。) 自分の限界以内の規模なら、悪影響に気づかないような「落とし穴」 でも、プロジェクト規模が3倍になったら、もう無視できない可能性が 出てくると思います。
    3. そんな時、「落とし穴」(典型的には「クラス同士の循環依存」 の問題)に気づいているかどうかが、生死を分ける、ように思います。 (循環依存があるクラスは単体検査が不可能。単体検査の済んでいない 部品を組み合わせて大規模システムを構築することは、自殺行為。) この辺りの件に関しては Taming C++, 大規模C++ソフトウェアデザイン辺りが良い著作だと思います。
  • 自己フォローですが…サブジェクトは
      でもインターフェース策定の難しさに無頓着だと「死の行進」に至る、と思う
    のつもりでした。

    何か、プレビューよりもサブジェクトが短くなる気がする。気のせい?

typodupeerror

身近な人の偉大さは半減する -- あるアレゲ人

読み込み中...