美しくなくても十分に機能するコードで良い？ 244
ストーリー by Oliver
デバッグできず機能しなくなる 部門より
デバッグできず機能しなくなる 部門より
Anonymous Coward曰く、"ZDNet Etnerprise に載せられていた Microsoft の Visual Studio .Net 擁護論。「Javaを忠実に真似する？ Visual Studio .Netのビジョン」。
Visual Studio .Net が次バージョンで装備すると発表されているモバイル向けの統合機能が Java と比べられている。他にも Common Language Runtime（CLR）を SQL Server に組み込むことによって，Visual Basic でストアドプロシージャを書けるようになるとの話題も。
興味深く思ったのは「もしマイクロソフトがそのコード用にセキュアで管理された環境をきちんと維持してくれるのであれば、コードがすっきりしているかどうかなどは、どうでもよくなるはずだ。」との一文。
美しくても難しい解決より，美しくなくても十分に機能する解決であれば OK なのか？
「Java は難しい」という筆者による記事で，「Java派の人々の反撃をお待ちしている」とのことだが，みなさんの意見はどうだろうか？"
Oliver氏に一票 (スコア:3, すばらしい洞察)
完璧にsecureな計算機環境とはプログラムを動かさない環境である。
# その意味では完璧かもしれんが
Re:Oliver氏に一票？ (スコア:1)
Oliverの何に一票といいたいの？＞ねこぽん
Re:Oliver氏に一票？ (スコア:1)
部門名: デバッグできず機能しなくなる
Re:Oliver氏に一票？ (スコア:1)
どの言語でも (スコア:3, 参考になる)
ある程度汚く読みにくくなるのは、
仕方がないと思われますが。
うちの仕事ものんびりした仕事は少ないので、
とりあえず動くものということだと、
金余分に貰ってそれをOSとDBにつぎ込んで
VBできる人を集めて、ASPで作っちゃいます。
Javaの「使える」エンジニアは常に不足気味ですから、
なかなか現場の要求に迅速に対応できないんですよね。
SunとJava陣営はそこんとこなんとかしないとね。
.netによって、これまでの大量のVBプログラマが
VB.Net経由でC#に徐々に慣れてくれれば、
あとでJavaに移植しやすくなるので
ありがたいと思うんですけど。
Re:どの言語でも (スコア:5, 参考になる)
> パフォーマンスを重視すると、
> ある程度汚く読みにくくなるのは、
> 仕方がないと思われますが。
これって昔から言われることですが, 本当にこれが当てはまるケースって今ではごく稀になっているのではないかと. おそらくは
程度か, その類似の場合だけで, 多くの場合はむしろコンパイラが最適化しやすいように明瞭なプログラムの流れにした方が良いでしょう. それに手による最適化が必要な局面って, プログラム全体の高々数%未満ですから, 最適化を理由に汚いコードを書く人は, 単にきれいなコードを書くスキルが無いと思った方が良いでしょう. 経験的には, スキルの有る人が汚いコードを書かざるを得ない場合には, なぜそのようになったかがコメントに明記されているので, 十分に分かりやすくなっています.
で, いわゆる自称VBプログラマが問題になるのは, 実際のプログラミングに入る前段階での実装設計能力に欠けているからです. これは言語環境にはほとんど依存しませんから, RAD技法で対応可能な規模を超える物件では, どれだけプログラマが増えようと保種困難なクズプログラムが増えるだけで, 保守を前提としない使い捨てプログラムにしか適応不可能です.
Re:どの言語でも (スコア:2, 興味深い)
ソフトウェアの開発も十二分に大きな市場ですから、優秀な人材を探したり育成したりすることに投資するよりも、優秀とはいえない人材をいかに活用するかへ金が流れるようになるのでしょう。
とくにWeb系に関しては、開発スパンがweek単位～長くて1年ですから、満足な設計すらもままならないことになり、プログラマにその辺のしわ寄せがやってくるケースが多々あるのではないでしょうか。
それに加えて、サーバサイドアプリケーションの場合は成果物を配布しませんから、設計や仕様変更に関して柔軟に対応できる分、コードのクォリティが必然的に低下していきます。
ある意味で、顧客満足度を高めるために、コードが犠牲になっているとも言えますが・・・
Re:どの言語でも (スコア:2, 参考になる)
> 設計や仕様変更に関して柔軟に対応する必要があるのなら、読みやすく、
> メンテナンスしやすいコードほど、修正が短時間で行えるのだから、
> コードのクオリティを高める必要が出てくるのでは？
柔軟に対応する必要があるというよりは、
柔軟に対応を迫られる、
という表現が近いのでしょうね。
で、修正を短時間で行えるのは理想なのですが、設計と実装も短時間で行わなければなりませんから・・・なかなか理想的には行きません。
先日も、あるJava信仰者のSEの人が保守性を主張しまくって、大変な目にあいました。
保守性に固執しすぎてコーディングのアップが遅れると、テストのスケジュールを圧迫し、それによって成果物のクォリティが低下するという悲惨な結果を招く場合もあります。
大切なのはバランスだと思いますが、それがなかなか難しいんですよね。
Re:どの言語でも (スコア:1)
そういう人と一緒に仕事がしたいっっっっ。
＃そんなこと言う前に自分がそういう人になる事が先決＞俺
Re:どの言語でも (スコア:1)
そうかな？コンパイラによる最適化が効くような、
抽象度の低い層の話だけでもないだろう。
外部には公開していない、
オブジェクト内部でだけ保持しているような中間状態を利用して
高速化を行うことって多いんでないかな。特に OOP だと。
もちろん、そういう書き方をすると「公開用インターフェース」と
「内部向けインターフェース」の２つが混在するから、
「公開用インターフェース」のみに絞った場合に比べて
読みにくくなる。
後半の部分については同意。
# mishimaは本田透先生を熱烈に応援しています
Re:どの言語でも (スコア:1)
（って言うか、ちょっとしたのならやっちゃうし。
public:はキレイキレイに書くんだけどなぁ。
愚痴
コメントレスなソースとか時々見かけたりして
ソース見ただけで判るからコメント要らないなんて言ってる人とは
一緒に仕事したくありません(タダの愚痴だよ (/_;)
Re:どの言語でも (スコア:2, おもしろおかしい)
一瞬、「使い捨てプログラマ」って読んでしまいそうになった（笑）。
いや、笑い事じゃないな…。
Re:どの言語でも (スコア:1)
>VB.Net経由でC#に徐々に慣れてくれれば、
私の知っているVBプログラマって、たいていは
VB“しかできない”プログラマ
だったりするので、彼らに限って言えば無理っすね。
Re:どの言語でも (スコア:3, すばらしい洞察)
私の知っているVBプログラマって、大抵はVBもできないプログラマだったりします。
で、そいつらの書いたコードと思しきものをメンテすることになる罠。
DB開発者不足の解決？ (スコア:3, 参考になる)
> つまり、Visual Basicでデータベースクエリを行えるようになるのだ。
>
（中略）
>まず第1に、データベース開発者は不足気味であり、データベースを開発環境に統合するというのは、この問題に対する部分的な解決策として注目される。
って、あるけど、データベース開発のキモは「どういうデータベースにするか」という設計のところにあって、
どの言語を使うのか、ってのは機能やコストを勘案して決めるわけでしょ？
なので、VBでクエリーができる、ってのは選択肢が一つ増えただけで、開発者不足の解決には全然なってないと思うんだけど。
ただ単に、「SQLわかんなくてもVBわかればオッケーだよ」ってだけだよね？
MSは、筆者の理解とは違う考えで実装しようとしてるんだと思うのだが。
＃DBには詳しくないので、詳しい人からの突っ込みキボンヌ。
なんか、全体的に的を外れた批判と思われ。
.Netを擁護するのは別にいいが、MSの意図するところからはずれてるんじゃあ…
Java派な人、ってほどではないけど (スコア:3, 参考になる)
Java の J2ME に関して言えば、まだ成功してるとは言いがたい状況ではないかと。 主力の J2ME MIDP では機能がプリミティブ過ぎて、ケイタイは独自拡張の道、資源に余裕のある PDA の主流は PersonalJava (Personal Profile) に向かっていますが、それぞれのパイが小さすぎる状況かと。 あ、ケイタイのパイはそれなりに大きいけど、実行環境へのアプリの配布が制限されすぎていて。。
要は Write once, run anywhere じゃない。 で、個人的な期待は Palm が JCP で進めている PDA Profile。 とりあえずパイが大きそうだし。
しかし MS は JCP とか通さなくても、Windows CE 系の PDA と自由に組み合わせられるから。 VBのスキルを生かせるとすると、これから更に期待される業務用PDAの勢力図が大幅に変わる可能性がある、かな？それが MS の狙いだと思うし、Palm ファンとしては怖い。
ちなみに個人的には言語にそれほど思い入れは無くて「.net は Java を大いにパクってもかまわないので、それなりに成功している Java のオブジェクトモデルを尊重し、更に洗練されたものにして欲しい」と思っています。 デザインパターンのような基本、そして基本的なオブジェクトデザインは、Java とか C# とか言語の壁を越えて、真に発展して欲しいと考えていたり。
# とりとめが無くなってしまったが、真面目に書いたので !AC
翻訳の問題 (スコア:3, 参考になる)
総じて、不正確な翻訳ではないのですが、原文のもつユーモア めいたものがそぎ落されているため、著者が大真面目で 「Visual Basicで誰でも手軽にDBアプリが書けるんだぜ」 と言っているように受け取られかねないかな、と。 原文から得た印象では、「MicroSoftはそのへんの技術障壁を 下げるのに努力してて、それには良いこともあるんじゃない?」 という控え目な主張に思えました。
私はどちらかというと著者のいう"purist"陣営なんで 言いたいこともいろいろありますが、それは既に議論されているので置いときます。
懲りない仕様 (スコア:2, おもしろおかしい)
ウィルスを？
Re:懲りない仕様 (スコア:1)
Java で言う Java Web Start ですな。
ただセキュリティモデルが全然違うので、怖いことに変わりはない。.Net2 でセキュリティモデルを大幅に変更するらしいけど、どの程度安全になるのかはまだ見えて来ないですな。誰か情報知ってたら教えて。
個人的には、ダウンロードして、署名チェックして、ウィルスチェッカ通して unsafe コードを直実行してしまうに一票。
まとめと ありそうなつっこみを (スコア:2, すばらしい洞察)
前提：
・Javaは難しい→Java言語による専門的な開発者が少ない
・VBはやさしい→開発者も多い
・Javaはきれい ←→ VBはきたない
仮定：
・.Netの新版で VBでも JDBC相当のことができそう。
結論：
・VBで難しいことができれば きたなくても 開発者が多いことだし
恩恵が多くて ハッピーだ。
。。。という 論旨でしょうか。
-----
典型的なつっこみかたとしては
・「Javaは難しいことができるので 難しいのではないか？」
→ VBで難しいことをすれば それは VBが難しくなると言うこと。
結果、専門的な開発者が少なくなる。
・「VBは きたないのではなくて きれいに書くのが難しい、
ということにすぎないのではないか？」
→ VBできたないコードを書く人を専門的な開発者と言っていいのか。
専門的でない開発者の書いたコードが品質を保てるのか？
・「で きたないコードで 保守はどうするのか？」
→この記事を鵜呑みにすれば、
「難しいこと」が きたないコード で書かれた きたないプログラムが
できあがるわけだが、誰があとでそれを読むことができるのだろう？
こんなもんでしょか。
.Net 側としても
こんな擁護のされ方は さすがに不本意だと思う。
----
おかゆさん (C#はじめました)
つっこめ、言うたかて君… (スコア:2, 参考になる)
無理してつっこみを入れようとすると、相手の言いたいことをこっちが推測して、
その推測した内容に対してつっこみを入れるという、つっこむ人が丸損の状況の上に、
論点が噛み合わないという危険性も出てきます。
元記事の意見が明確でない理由として、
----
・前提条件である（と思われる）、JAVAが難しいという根拠が述べられていない。そのため
JAVAが難しい、という前提条件の説得力が欠けている。
→ 理由を述べない理由として、筆者は「技術に詳しくない」って、それやったら
難しいかどうかも分からんとちゃうんか？分からんことを分かってるように書くな！
・結論がきちんと述べられていない。何となく「.NETはJAVAよりもヨサゲ」ということが
言いたいんやろうなーという程度。
→ 結論を述べていないんやったら、反論のしようが無いやないけ！
・一つ一つの意見（らしきもの）の、繋がりが無い。また、あちこちで論理が飛躍している。
→ だから、全体として何を言ってるのか理解できない。
----
という点が挙げられるでしょうか。
という訳で、無理してつっこまずに怪訝そうな顔で無視するのが上策かと。もし、無理して
つっこむのなら、私なら、こんな風なつっこみを入れます。
『「Java派の人々の反撃をお待ちしている。」って言うんやったら、自分が何を言いたいのかを
まず、はっきり書け！せやないと反論のしようが無い。あと、意見を述べるんやったら理由を
添えとけ。でないと、客観的な意見やなくて、妄想としか思えんから説得力が無い。とりあえ
ず、論文の書き方と日本語勉強しなおして、出直して来い！』
という塩梅でしょうか。だって、技術的な点で、つっこみを入れる以前の問題だもの。
＃こんな記事でも給料貰ってんだろうなぁ。いいなぁ…
Re:まとめと ありそうなつっこみを (スコア:1)
なにもVBだけの話でないのでは？
VB で書ける程度の内容ならVBで、より複雑なら C# で、
という自由度がある、って話でしょ。
DB を扱うプログラムがみな複雑とも思えないしな。
前提
Java: 初期投資が高い、複雑なアルゴリズムもOK
VB: 初期投資が安い、複雑な内容になると手に負えない
仮定
DBのストアドプロシジャには単純なものも多い
結論
なにも Java じゃなくても VB でいいじゃん。
複雑な内容だったら C# にすればいいし。
// 個人的には PL/SQL に比べれば VB の方がましだろうと思う。
# mishimaは本田透先生を熱烈に応援しています
「美しい」とは？ (スコア:2, 参考になる)
必要なのは「読みやすいコード」だと思うし、Visual Studio .Netでも
「読みやすいコード」を書くことはできると思うが、どうかな？
＃Javaは難しい、とは思わないけど。
＃あんまり深く突っ込んだところまでは知らんが。
技術に詳しくないのに (スコア:2, すばらしい洞察)
は読んでみたけど、何が言いたいんだか、よくわかりません。
それよりも“技術に詳しくない”人がなんで
>Javaは難しいということ、
がわかるのかなー。
これの反対で“技術に詳しくない”人が「Javaは簡単だ」とか
ぬかしているのを聞いて、つっこんだことがありますがね。
C++の仕事で苦しみぬいたプログラマーが言うならともかく。
だからこそ (スコア:2, 興味深い)
>有り余るプロセッシングパワーは、美しいコードと美しくはないが
>十分に機能するコードとの間の実用面での差を次第に消滅させていくだろう。
言ってるコトが逆じゃないかなぁ。
有り余るプロセッシングパワーがあるからこそ、機能はするが汚いコードよりも
メンテナンスのしやすい美しいコードが必要になってくるんじゃないだろうか？
# 筆者の「美しいコード」の定義は
# >平均的なVisual Studioプログラマーが作成したコードは、形式の整ったJavaコードと
# >比べると醜悪に見えるだろうか？
# という文章から自明。
This cookie has a scrap of paper inside. It reads:
If you can't learn to do it well, learn to enjoy.
うーん (スコア:1)
となると、そこにJavaの出番はほとんどないのですが・・・
VBとVC++とDelphiの独壇場だったところに、.netでC#が参入したところですか。
逆にサーバ側だと、いつもプロセッサパワーは不足気味ですが・・・
Javaの場合でも、不安なところはservletに書き直したりもするし。
「万年初心者」という言葉を聞いたことがありましたが (スコア:2, 参考になる)
記事の内容がどうこうというより基本的にはキャッチセールスと 同じような話でしょう。 実際の製品の評価とこの記事の内容は必ずしも一致しないんじゃ ないかな?
-- 哀れな日本人専用(sorry Japanese only) --
Re:「万年初心者」という言葉を聞いたことがありまし (スコア:2, おもしろおかしい)
という誤解の連鎖を引き起こすための催眠記事かと思いました。
Re:「万年初心者」という言葉を聞いたことがありまし (スコア:3, おもしろおかしい)
Java屋の一言 (スコア:2, すばらしい洞察)
オブジェクト指向の理解があればこそこ書ける言語仕様。そういったモノであれば個人的に何でもいいです。読めるコードを書くのがプロの仕事（またコードを読むのもプロの仕事）。
余談ながら読めないコードを書く人は、文法の理解だけでオブジェクト指向的な考えがない人だと思います。「オブジェクト指向の真髄は再利用性にあり」と個人的に考えておりますので。
コードより設計じゃないの？ (スコア:2, 興味深い)
「汚い設計」で読めるコードを書くのは難しいと思いますし、Java/C++でも汚い設計をする自称プロは大勢います。
VBでも「美しい設計」であれば、読めるコードは簡単に書けると思います。
まあ、オブジェクト指向的で美しい設計が出来る人は少ないと思いますが…
問題なのは「美しい設計」であっても読めないコードを書く人です。
ある程度賢くて腕力の強い人はそうなりがちです。どう教えたら良いのやら…
開発者によりけり (スコア:2, 興味深い)
汚いコード：設計不十分・統一性のない場当たり的なコード、またはその集合体。
綺麗なコード：十分に設計され、統一されたプロセスを用いて記述されたコード、またはその集合体。
汚いコードを書く人間は、どの言語を用いても汚いコードしか書けないですね。それにもかかわらず言語によって綺麗さの優劣が出るのは、単に敷居の高低、または汚いコードを許容できる言語仕様になっているか否かなだけでしょう。
別にJava使ったって汚いコードはいくらでも書けるし、VBで綺麗なコードを書くことも全く問題ない。どれだけ大規模になろうと、VBで書けないものはない。
問題になるのは、「VBを書けるプログラマ」の平均技量だけでしょう。汚いコードしか書けない人々が、自分が思うような場当たりを許してくれないという「敷居が比較的高い」Javaを敬遠し、VBで生きながらえようとするから、このようなことになっているだけなのでは？
MSはその点を考えて、互換性を微妙に捨てて敷居を微妙に上げ、自分たちの言語を使ってくれるユーザ層のレベルを上げさせようとしているにすぎないと思います。
早い話が、自分を含めてVBという敷居の低い言語によって大量生産された、「なんちゃってプログラマ」を実用レベルに底上げさせるための涙ぐましい努力の一つなんですよ。
別にMS擁護ではないが、奇しくもこの業界の平均実力が低レベルであることを自己肯定してしまった罠。
そろそろ。。。 (スコア:2, 興味深い)
Re:そろそろ。。。 (スコア:2, 興味深い)
で、お次は、高級言語に対する半自動ソリューションが登場するというわけですな。
そう考えれば、今回とて歴史が繰り返されていることになる。
結局、「コード」の概念がどんどん高レベルになるだけの話で、いつまでもある種の汚さはついて回ると思うんだけど・・・
# そしてまたブラックボックスが増え、エンジニアが低レベル化。
基礎学力の低下を招き、技術のドーナツ化現象が云々...
根本的な問題を提起するが…… (スコア:2, すばらしい洞察)
言語系は（狭義の）技術。そりゃあ「超特急でウルトラ修羅場、入って即徹夜」っつープロジェクトならともかく、通常の進行ならばそんな技術はOJTで身に付く。付かないよーならそもそも人月いくらにしかならん専業PGなんだから、綺麗なソースが書けるコーディング規約を作らなかったSEの責任。
＃勿論、最低限の基本は日常の情報収集で身に付けておくことは大前提だが(^^;
ソースの綺麗／汚いは思想の問題。そりゃあ勿論、方向性に違いはある。だが、思想を持ってる人間が書いたコードは論理性がある。自分と違う方向性を持っていたとしても、その思想さえ理解できれば、その瞬間からそのコードは「綺麗」になる。
開発環境は「技術」を補完してはくれる。エラーの出る可能性を低くするという意味では役に立つだろう。しかし、「思想」を補完する技術は無い。使えない人間が書いたコードは汚く、一回限りの使い捨てコードでなければ結局は高コストとなる。
_ to boldly go where no man has gone before!
ごめんなさい (スコア:1)
環境がセキュアで管理されていると、美しくないコードの保守や拡張が楽になるというのでしょうか？
「美しい」の意味が私の思っているのと違うのでしょうか？
あぁ、「ン」が消えてるんですよ。「ビーフン・カレー」ね。
「美しい」の意味 (スコア:2, 興味深い)
何をもって美しいというかだけど、 「正しい」ということなら、 「常に正しいわけではなくてもある条件下では動けば良い」 というのは俺も思う。
美しさが「読みやすい」ということならば読みやすさは俺には最重要なので 「読みやすくなくてよい」などというのには絶対に賛成できない。
自分独自の言語や文字を作ったことがある人ならわかると思うけど 人工言語って、書くのより読むのが断然難しいんだよね。 プログラムって読みにくく書くのは簡単だけど、 だからこそ読みやすく書くことを啓蒙してってほしいなあ、 ああいう技術紹介記事を書く人は。
Re:「美しい」の意味 (スコア:1)
華だったような気が・・・・
なんかWindowsが興隆しだしたあたりから、コンピュータサイエンスが
つまらなくなった気がするのは気のせいでしょうか？
-----------------
#そんなワタシはOS/2ユーザー:-)
Re:「美しい」の意味 (スコア:1)
文字まで作ったやつは Ken Iverson と J.R.R.Tolkien くらいしか知らないなぁ。
# ここで松本善之助を出すのは焦げそうなのでやめとく
Re:「美しい」の意味 (スコア:1)
うーん。「文字を作った」だけなら掃いて捨てるほどいるんだけどねぇ。
コードが「美しい」つったらアルゴリズムとか (スコア:2, 参考になる)
これが即座に「美しい」＝「コードの可読性」になっているのは
これはもう時代のせいなのかな。でもEric Knorr氏が元投稿のなかで
「すっきりしたコード」と言っているのも、
書くのは難しいが堅くて短く効率の良いコードという意味で
「読み易いコード」という意味ではないと思う。
私もちょっとJavaの技術に詳しくないので例を引けないのだけれど
たとえばcであればループを含んだ処理とかで、特に実行に問題はないが
回りくどく特に工夫も無く書かれている２０行位のありきたりのコードを
同じ動きをする３行位のコードに書き換える事が出来たりする。
その方がコンパイル後のコードサイズ的に小さく済むし、
処理速度的にも早くメモリ効率も必然的に良かったりするので
そういう物が必要な場合にはそう出来る。
アルゴリズムの習熟や同じ事を複数の文法で処理できる言語仕様の幅の
広さがそうさせている訳だけれども、同様にＪａｖａも言語仕様の毛並みの良さから
同様な事が出来るだろうし実際Ｊａｖａ開発者の層の特色からして
そういう事をあたりまえにするだろう、つってるのではないかな。
ところがVisual Studio特にＶＢとかであれば言語仕様的にも
そんなに多様な書き方が出来る訳でもないしたとえばマクロや
インライン展開関数とかの有れば効率必須が求められるような物も無いし
何より圧倒的な普及率から推測できる開発者層の特色とかからしても
あんまりそういう工夫はしそうにない。
結果として出来るこういう何の芸も無いコードは特に上で書いた種類のＪａｖａ開発者
の層から見たら「美しくない」と取られるかもしれないけれど
そうした書くのが難しい美しく効率もよく堅いコードの利点は、
>有り余るプロセッシングパワーは、美しいコードと美しくはないが
>十分に機能するコードとの間の実用面での差を次第に消滅させていくだろう。
という風になっていくだろうし、MicrosoftがJavaの物真似に走って
出来上がる物がこうした芸のないコードの大量生産を生む開発環境だとしても、
Javaの模倣を志向する事で今より少しはましな物に近づくのが期待できたら
それは良い事なんじゃないの？つってるのではないかな。
まあそれでも何を言ってもマイクロソフトの話だから
>マイクロソフトがそのコード用にセキュアで管理された環境を
>きちんと維持してくれるのであれば
という但し書きを最初につけずには置けないけどね、という(笑)。
まずそれが確保されているかどうかの話の前では
>コードがすっきりしているかどうかなどは、どうでもよくなるはずだ という話
だと。
異論はないなあ。特に最後の但し書きがね(笑)
コードがスパゲティでも (スコア:1)
.NETにして、バグなくちゃんと動いてくれるプログラムが、簡単に作れるのかどうかは知りませんが。
Re:コードがスパゲティでも (スコア:1)
適切な(セキュアな)実行結果を得るためにコードを書くのであって、美しいコードを書く事だけを目的にしてはいけません。
そりゃあ汚いより美しい方が(一部の、ソースを読む技術者には)嬉しいけどさ、それを利用する大多数のユーザには内部がスパゲティかなんて問題じゃ無いよ。
＃苦労するのはユーザではなく技術者だけで充分だ。(・・・とプロジェクトえっくすで言ってたです。^^;)
（オフトピ）/. に聞け！Java の開発環境 (スコア:1)
NetBeans [netbeans.org] 使ってますが、 NetBeans そのものが Java で書かれているらしく、トロいトロい。
CVS とかにもつながってくれるし、コード補完もできて、オープンソースなので、機能的には文句は無いのですが、反応の遅さに嫌気がさします。233MHz とか 350MHz のちょっと古いマシンを使ってる人だと、起動するだけで、数分かかるし、クリックしてから、ちょっと待たないとメニューが出てこなかったり。
一応、マルチプラットフォームって点は Java 良いけど、反応の悪さってのは仮想マシンで走る Java の呪縛なんですかね？
.NET も少しでかいソフト作るとダメダメになっちゃうのかな？
マルチプラットフォームで 3D なソフトを作らなきゃならんので、 Java 使おうと思ってます。識者の方アドバイスお願いします。 ちなみに、メンバー全員 win機です。
Re:たしかに (スコア:1)
李 露星
Re:たしかに (スコア:2, おもしろおかしい)
アーサー・ブロック=著 倉骨彰=訳 マーフィーの法則(アスキー出版局) p.117より。
--S0R5
Re:仕事でしか (スコア:1)
一度できあがったら、きれいに書き直すこともほとんどないし。
Re:仕事でしか (スコア:1)
Re:仕事でしか (スコア:1)
Re:仕事でしか (スコア:1)