今思ふ　　今の時代言語は何でも言いと・・・

昔はパソコン自体が遅かったからCじゃないと処理が遅かったけど
今の時代言語は何でもいいような気がする。
遅くてもめちゃはやいパソコンがカバーしてくれるもんな・・・
今のパソコンまじでうらやましいよ

そうかもね。
ただ最近思うのは、どうせプログラムなんて
出来るやつにやらせておけばそれでいいやってこと。
何か他のことに興味が出てきた今日この頃。

きっと何年かしたらプログラムも必要なくなるんだろうね

そうかもね。
でもマイコンとかはそうもいかない・・・

いまどきマイコンなんてあるんすか？＞4

>>5
アホ発見。
視野狭窄末期症状。ご臨終。

ﾏｲｺﾝBASIC

マイコンなんて今医らねーよ

>>5
>>8
家電製品使用禁止の刑に処す。

マイコンって何の言語使ってるの？

そらアセンブリ言語やらC言語やらC++やらさね。

うわ　めんどくせぇ＞１１
つーかアセンブリって何だよアッセンブラだろ　プ
まぁおまえは時代遅れなCでもやってブリでも食ってろってこった＞11

>>12
恥ずかしい。。。

まあ、こういう反応が帰ってくるだろうとなぜか確信してたけどね。

>>12
ほんと恥ずかしい.
＃ 何故恥ずかしいか？
＃ だれか応えてあげて

っていうかいまからＣを覚えるメリットってないでしょ。
マイコンのプログラムなんて書きたくないし

みんなもすきだねー、こんなクソすれに反応しちゃうなんて

宿題：「アセンブリ」と「アセンブラ」と「アセンブル」の意味を調べてくること。

あんたが使っているキーボードにだって
マイコンはいってるぞ.

「アセカキスギ」と「デブ」も調べておけ。
あと過去の遺物　マイコンも調べておけ。

入ってねぇよ　ネタ小僧＞19

USBきーぼーどほしい

マイコンの出荷数のほうがパソコンなんかより断然多いことを知らんのか。

好きなCPUメーカーを３つ挙げよ。

昔、私の周りでは、Cが好きで組んでた人は少なかったよ。
メモリ消費量とか、動作速度の要求からしかたなくC使ってた。

メモリもCPUも潤沢になった今になって、Cでの開発が高く
評価されているのは ちょっと不思議。

プログラマと違うのが混ざってないか?

ん？
＞メモリ消費量とか、動作速度の要求からしかたなくC使ってた。
それならアセンブラになるんじゃないの？
本当は何で組みたかったと？

>>27
HSP

て何？

>>27
>>25 のケースとは違うかもしれんけど、BASICかもね。
Z80のシングルボードマイコンにBASIC-ROMを載せたものもあったし、
8051マイクロコンピュータにBASICが最初から搭載された 8052BASIC
というものあったよ。

>>27 >>30
事務系ならdBase�V。（遅いしよくファイルが壊れたけど）
あと、Basic系（F-BASICとか F9450のBASIC）

本当に組みたかったのはAda。
でもコンパイラが高くて（PC用でも80万円）自分では買えず
派遣先での開発で一回使っただけ。
美しかったよ。

アセンブリ言語をアセンブルするのがアセンブラだ。

アセンブラ五段活用、きっちり覚えておけよ。

>>32
Ｃ／Ｃ＋＋言語をコンパイルできるのがＶＣだ

Ｃ／Ｃ＋＋＝アセンブリ
コンパイル＝アセンブル
ＶＣ＝アセンブラ

>>30-31
なるほど。
そんな時代があったんですね。

>>33
（ﾈﾀと知りつつ）
＞コンパイルできる
んだからコンパイラやんけ！

>>24
TI, Zailog, Panafacom

Ｃなんて過去の異物

ハゲとくか

どの言語でもいいが、知識プールの量はＣが最大だと思う

　　　 　　(⌒Y⌒Y⌒)
　　　　　　＼＿＿／__
　　　　　　／　 　　　＼＼
　　　　 ／ ⌒　　　⌒ ＼ ＼ふぅ〜
　 　　 ｜　(･)　　(･)　　　＼　⌒ ）
　　　　｜　　⊂　　　Ｕ　　9）　　　） ／￣￣￣￣￣￣￣￣￣
　　　　｜　 ＿＿＿ 　　｜　） 　＜　　ｼﾞｻｸｼﾞｴﾝも、
　　　　 ＼　＼＿／　　 /　　　　　＼　つかれるぜ・・・・。
　　　　　／＼＿＿＿_／＼ζ 　　　 　＼＿＿＿＿＿＿＿＿＿
　　　　｜　　　　　.／￣￣￣￣＼
　　　　｜ 　 　　./　　　　　　　　　＼
　　　　｜ 　 　　./＼ 　　⌒　　⌒　 ｜
　　　　｜ 　 　　.|||／⌒つ(･)　　(･) ｜
　　　　｜　 　(6／　／し--◯⌒つ ｜
　　　　｜　 ..／　／　　　＿||||||||| .｜
　　　　 ＼＿＿／＼　／　＼＿/ ／)
　　　　　　｜　 　　...＼＿＿＿_／￣
　　　　　　｜　　　　　　　｜

　　　 　　　 (⌒Y⌒Y⌒)
　　　　　　／＼＿＿／ ＼从/　ﾊｯ
　　　　　/　 ／　　　　＼
　　　　 / ／ ＼　　　／ ＼
　　（⌒ /　　　(･)　　(･)　｜
　（　　(6　　　　　　つ　　｜　　 ／￣￣￣￣￣￣￣￣￣
　　（　｜　　　　＿＿＿ ｜ 　＜　　なに見てんだ、
　　　　 ＼　　　＼＿/　 /　　　　＼　ｺﾞﾙｱ！
　　　　　／＼＿＿＿_／＼ζ 　　　 　＼＿＿＿＿＿＿＿＿＿
　　　　｜　　　　　.／￣￣￣￣＼
　　　　｜ 　 　　./　　　　　　　　　＼
　　　　｜ 　 　　./＼ 　　⌒　　⌒　 ｜
　　　　｜ 　 　　.|||／⌒つ(･)　　(･) ｜
　　　　｜　 　(6／　／し--◯⌒つ ｜
　　　　｜　 ..／　／　　　＿||||||||| .｜
　　　　 ＼＿＿／＼　／　＼＿/ ／)
　　　　　　｜　 　　...＼＿＿＿_／￣
　　　　　　｜　　　　　　　｜

Fortranでは？

恥ずかしいレス一覧
>>5
>>8
>>12
>>16
組み込みという言葉を知らない中学生だと思われる（藁
こういう口の利き方する後輩がいたら、いじめてやるのになあー

そういや、10年ぐらい前だと思うけど、天文の中野主一氏が「計算にCを
使うなんて信じられない。Fortranに限る」って何かに書いてたよ。
おれ、組み込み系なんで Fortran触ったことないのだけど、そういう
ものなのね？

組み込み＝ＤＱＮ業界

システム、パッケージ、ゲーム業界＞＞＞＞＞＞＞＞＞＞＞＞＞＞組み込み

>>21
>入ってねぇよ　ネタ小僧＞19

AT互換機とかPC9801のキーボードだとマイコン内蔵だったけど、最近はそうでも
ないの？ それとも別の機種？
あとAT互換機のシリアルマウスもPS/2マウスもUSBマウスもマイコン内蔵なはず
だけど、ちがったっけ。あの通信をハードのロジックだけでやろうとすると、
かなしコストがかかりそうな気がするのだけど...

>>38
そこそこ同意。
見方を変えると、新しい言語ってC言語ぐらいに資産が貯まる前に廃れていくような気がする。

>>44
>>21は、知ったか厨房. 逝ってよし.

>>44
>>46
http://www-6.ibm.com/jp/event/museum/shikumi/keyboard.html
これで、>>21 は、知ったか厨房と認定されました.

VBは糞ですか？会社でこれオンリーなので・・・。

>>48
ＶＢを極めなさい。（ｗ

マジな話、ＶＢ技術者ってのは腐るほどいるが、きちんとＶＢを使いこなせてる「技術者」
は１０人に１人いるかどうか・・・

>42 CよりFortranの方が速い。
ポインタがない分最適化が効くしFortranの方がCよりコンパイラが成熟してる。
あと、浮動小数点演算の細かい振る舞いが厳密な数値演算に向いているという理由もあったはず。

　　　 　　(⌒Y⌒Y⌒)
　　　　　　＼＿＿／__
　　　　　　／　 　　　＼＼
　　　　 ／ ⌒　　　⌒ ＼ ＼ふぅ〜
　 　　 ｜　(･)　　(･)　　　＼　⌒ ）
　　　　｜　　⊂　　　Ｕ　　9）　　　） ／￣￣￣￣￣￣￣￣￣
　　　　｜　 ＿＿＿ 　　｜　） 　＜　　ｼﾞｻｸｼﾞｴﾝも、
　　　　 ＼　＼＿／　　 /　　　　　＼　つかれるぜ・・・・。
　　　　　／＼＿＿＿_／＼ζ 　　　 　＼＿＿＿＿＿＿＿＿＿
　　　　｜　　　　　.／￣￣￣￣＼
　　　　｜ 　 　　./　　　　　　　　　＼
　　　　｜ 　 　　./＼ 　　⌒　　⌒　 ｜
　　　　｜ 　 　　.|||／⌒つ(･)　　(･) ｜
　　　　｜　 　(6／　／し--◯⌒つ ｜
　　　　｜　 ..／　／　　　＿||||||||| .｜
　　　　 ＼＿＿／＼　／　＼＿/ ／)
　　　　　　｜　 　　...＼＿＿＿_／￣
　　　　　　｜　　　　　　　｜

　　　 　　　 (⌒Y⌒Y⌒)
　　　　　　／＼＿＿／ ＼从/　ﾊｯ
　　　　　/　 ／　　　　＼
　　　　 / ／ ＼　　　／ ＼
　　（⌒ /　　　(･)　　(･)　｜
　（　　(6　　　　　　つ　　｜　　 ／￣￣￣￣￣￣￣￣￣
　　（　｜　　　　＿＿＿ ｜ 　＜　　なに見てんだ、
　　　　 ＼　　　＼＿/　 /　　　　＼　ｺﾞﾙｱ！
　　　　　／＼＿＿＿_／＼ζ 　　　 　＼＿＿＿＿＿＿＿＿＿
　　　　｜　　　　　.／￣￣￣￣＼
　　　　｜ 　 　　./　　　　　　　　　＼
　　　　｜ 　 　　./＼ 　　⌒　　⌒　 ｜
　　　　｜ 　 　　.|||／⌒つ(･)　　(･) ｜
　　　　｜　 　(6／　／し--◯⌒つ ｜
　　　　｜　 ..／　／　　　＿||||||||| .｜
　　　　 ＼＿＿／＼　／　＼＿/ ／)
　　　　　　｜　 　　...＼＿＿＿_／￣
　　　　　　｜　　　　　　　｜

きちんと売上が確保できるならなんでもヨイ

世の中、銭や！

なんでもＣっていうアホが居てたまらん。
分かるけど、納期とか諸経費の問題もあるんだよ。
コスト意識の無い奴は使えない。技術的は尊敬するけどな。

かと言って、ＶＢＡしか知らないのにＡＰＩなどという言葉を振りかざして
営業や管理部門に能書き垂れるのも頂けない。見てて見苦しい。

かといって漏れはＶＣしかできん。

実装における効率も大事だしパフォーマンスも大事だけれど、引き継ぎ等の事を考えて、
例えば協力会社から技術者を雇いやすいとかの理由も大事＞言語の選択

実装における効率やパフォーマンスが良いけど
協力会社から技術者を雇いにくい言語って、例えば何？
おもしろそうじゃん。

>>56
おれはPerlで簡単にやりたかったんだがCでやることになった、てのがあたよ。

>>57
なるほど。
ただ、オレは Perl awk sed の類はちょっと苦手だった。（個人的でゴメン）

Fortranなんて最近使ってるところマジで少なくなったな

Perlもあと何年持つか・・・

sedやawkでさえこんなに長持ちしてんだから結構いけそう

PerlはC++やJavaで開発してても
たまにカユイところに手が届くから、しばらく生き残るっしょ。

所詮使い捨て周辺ツールだろ。＞ Perl

それでいいのだ。

1=ブビ坊（C経験無し）

ってーか、今時、ｺﾞﾘｺﾞﾘにｺｰﾄﾞ書きたがる輩がいるからｺﾏﾀﾖ...
（´ε｀）

>56
Delphiじゃないの？

VBと比べて利点は何よ？
Pascal系でしょ。
ちょっとだけ興味あるけど、触ったこと無い。

Perlはすぐなくなると思うよ。

デルはつかえねーな

ここでも、ruby って言ったら、基地外みたいに
叩かれるかな？

>>71
71だが、名前：15じゃないよ、漏れ
15サンごめんよ〜

Delphi、コンパイル爆速。これにはビビッた

組み込みなんてドサ周り連中でしょ？
Cでもブラでも一生やっててって感じ　(笑
OO理解出来ない石器人には丁度いいんじゃないかな　(^∀^)ﾀﾞｻｰ　ｹﾞﾗｹﾞﾗ

>OO理解出来ない石器人には丁度いいんじゃないかな　(^∀^)ﾀﾞｻｰ　ｹﾞﾗｹﾞﾗ

随分レベルの低い話をしてるな。アホは逝ってよし

>>73
元はTurbo Pascalだからな。Turbo Pascal 5.5はよかった。
高速なコンパイル、よく出来たオンラインヘルプ、強力な
デバッガ。あれこそ最強の開発環境であった。

>>73 >>76
いまはCPUが速いので、インタープリタで十分。
よって、コンパイルが速いのは意味が無い。
というのが、このスレ的答えだと思うが。

ちょっとずれてることかもしれないですが、
クライアント側でPentium133以下のマシンが、
リース資産の関係で多数現役として残っているため、
「その程度のマシンでもある程度快適に動作すること」
っていうのが要求仕様に含まれてるって事ってない？

>>78
今思いっきりその状況です。
Win95で動くこと、とかHDDやメモリの制限とか。
一番困るのはこっちに検証できる機材が無いこと。

>>76
Turboの時代は、コンパイルは早くても最適化が、どうしようも
ないくらい、ダメだった。
Delはコンパイル早くて、最適かもかなりいい。（⌒∇⌒）/

Radツールも良いが、ＶＣの方が楽しいかな…。
何かＶＢの標準のボタンって嫌い（コントロールの…）

質問、ＶＢのボタンはＡｃｔｉｖｅＸコントロールなの？
それとも、普通のボタン（Windows標準の）？

>>81
そんなの、SPY++ で見てみろ.

処理の奇抜さや実行速度を誇る喜びと（C,アセンブラ）
速く作って生産性を自慢する喜びと（VB,ACCESS）
オレは後の方だね。

ＶＢ生産性高くないです。
ＶＢを含めて複数の言語が使える人は、たいていそう言います。

VB,ACCESSの生産性が高いとは思えませんがなにか？

かぶった(鬱

ＤＢつつきにいくならやっぱＶＢ、ＡＣＣＥＳＳ

Pascal懐かしいな。
いまとなってはゴミ

まあお前らド素人は、n88BASICでも使ってなさいってこった。

ファミリーベーシックの方が更に良いと思われ

>>77
>いまはCPUが速いので、インタープリタで十分。
>よって、コンパイルが速いのは意味が無い。

意味不明。

結構、最近の人って、マイコンに対する偏見があるんだな。

そういう人は、CPUもVerilogと言う言語で設計可能できるとは
夢にも思っていないだろう。

>>92
＞語で設計可能できるとは

開発言語の前に日本語学んだほうが良いと思われ

>>92
今、思いっきり反論しようと思ったが、私が間違っておりました。

↓修正
そういう人は、CPUもVerilogと言う言語で設計可能とは
夢にも思っていないだろう。

>>91
インタープリタは、ソースを一行ずつ解釈しながら実行するので実行速度が遅かったのです。
実際 昔のBASICは、いまソースのどこを実行しているか見当がつくくらい遅かったです。

それで、実行速度重視のプログラムは、CやFORTRANなどのコンパイラ言語を使っていました。
但し、ソースをコンパイルする必要があるため、開発はちょっと面倒でした。

ここから >>77 へ

いまSchemeを趣味でやってるんですが、

ものの本に、
このやり方ではとても時間がかかるが、
このやり方では圧倒的に速い。

とか書かれていても1GHzマシンでは全然変わりませんでした｡

age

cobolとVBだけはいや。

ってゆーか、COBOLとVBを使おうとする奴がイヤなんだな。

ｖＢもａＣＣＥＳＳも１Ｇになった今でさえ重いのはＳＰに錘が仕込まれているのでしょうか？

>>99
はぁ？

プログラミング言語も定量的アプローチが必要だと思う今日このごろ

CPUがいくら早くなったって言ってもさ、Javaで1秒間に200000万個以上
流れるパケットをリアルタイムに処理できるかっていったらできないだろ？

今のマシンで、どんな処理でも最新の言語でできるようになりゃそりゃ
幸せさ。

あと、JavaとかPerlとかから入ってきたやつが、適切なデータ構造
を選択できないとか、それゆえにクラスの設計＆実装がダメダメとか
そういった弊害もある。Javaだから、VBだからアルゴリズムの勉強
しなくていい、ってわけじゃないんだけどな。

ダメプログラマがどんどん増殖するのがたえられん。

>>103
激しく同意。抱いて

>>103
それは、「JavaとかPerlとかから入ってきた」からじゃなくて、
元々ダメな奴なんだよ。ダメな奴は何やらせてもダメ。

>>104
俺も同意。３Ｐしよう。

>>104
禿らしく同意。
君はぼくちゃんだけのもの。誰にも渡さない！！

>>103
200000万?
20億?

バスが２ギガＨＺで８ギガのＣＰＵなら可能だろうか・・・。

8ギガのCPUねぇ。あと２，３年ってところかな？

性能がよくなれば
Javaもはやくなるかしら。

メモリ積めば今でも早いですが、何か？

>>111
そのころには、JAVA ねーよ。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　＿＿ ＿＿
　　　丿───ヽヽ　　　.│ 　　　　　　　　　　　　│　/│　/
　　　　　　/　　　ヽヽ/　 .│＼　　─┼　─┼ 　 │/　│/
　　　　　/　　　　　/　　　│　　　 　/│　 /│ 　 Ο　　Ο
￣￣￣￣￣￣￣￣￣￣￣￣￣＼／￣￣￣￣￣￣￣￣￣￣￣￣￣￣

　　　　　　　　
　　　　　　　　　　　　　/＼　　　/＼　　　　　　　　　　　　　　　　　　　　）
　　　　　　　　　　　　/　　＼　/　　＼　　　　　　　　　　　　　　　　　　　ﾉ
　　　　　　　　　　　/　　　　　/　　　　＼　　　　　　　　　　　　　　　　　ﾉ
　　　 ＿＿＿　 ／○　　＿_　　○　　　 ＿＿＿　,-‐'~￣￣~`‐-､　へ　､＿＿＿＿ 　　　　　　　　　　　　　　　（
　　r'~　　　　　/　　　　　|　 |　　　　　r'~　　　　　　　　　　　　　　　　　　　　　　　　 ヽ　　￣￣￣　￣￣￣ 　´
　 ｛　　　　　　|　　　　　 |　 .|　　　　 ｛　　　　　　　　　　　　　　　　　　　　　　　　　　 ｝　 ＿＿＿　＿＿＿ (
　　ヽ､＿＿＿ヽ　　　　 ﾉ　　|　　　　 .ヽ､＿＿＿　　　　　　　　　　　　　　　　　　　　/ 　　　　　　　　　　　　 （
　　　　　　　　　 ＼　　｛―‐.｛　　　　　　　　　　　　　　　　　　　　　　　　　　　　＿／　　　＿＿＿　＿＿＿
　　　　　　　　　　　　　　　　　　　　　　　　　　　￣￣￣￣￣￣￣￣￣￣￣　　　　　　　　　　　　　　　　　　　（

　　　　　　　　　　　＿＿〃 十十〃
　　　　　　　　　　　　　/　　││　　､＿＿　､＿＿　､＿＿　､＿＿
　　　　　　　　　　　_／＼_　　ノ　　　　　　　　　　　　　　　　　　　　　ツ

言語に固執する時代は終わったと思うのですが、
この状況に適応できない人たち（オールドタイプとでも言えばいいのかな）が
つまらない理由、そのほとんどが自分の利益の確保なんですけど、
でいがみ合いやその果てに宗教戦争をおっぱじめるんですよね。

大抵115のような事を言う奴は
言語の特性を理解してないだけだったりするんだよな（ｗ

まず、理解してから物を言え、とφ(．． )ﾒﾓﾒﾓ

>>116
オールドタイプ発見！！得意げに何が「言語の特性」だ。
お前、本当に言語の特性なんて理解できてるのかよ。単に
「言語の特性」って言ってみたいだけだろ？

>>117
君は「言ってみたいだけだろ？」と言ってみたいだけなんちゃうんか？
と小一時間問いつめたい。

>>118
そうだよ。だから何？116がオールドタイプであるという
事実は動かせないぞ。

お前、何切れてるの・・・（ｗ

っていうか、言語特性うんぬんよりも
それ以前に言語仕様が貧弱な言語が
多く出まわっている気もしますがねぇ
で、そういった言語だけを習得した人達が
このスレを荒していると（ｗ

>>121
> それ以前に言語仕様が貧弱な言語が
> 多く出まわっている気もしますがねぇ
正直 ColdFusion とか VBScript で書かれたプログラムのレビュー／リライトは、もう疲れた。

>>115
ひまわりでもHSPでも好きなだけやればぁ？
一人でニュータイプやってろ

>>115=117かいな？
　言語の特性なんか詳しくは知らんが、3DCGとかの重いソフト使うと、いくらC++で作ってあっても重い。
もしVBやJAVAだと使いもんにならん程遅いだろうな。
　何かの雑誌にJBuilder(Javaで作られてるらしい)の起動にPen3-500,64MB-RAMくらいのPCで起動に2分くらいかかると書いてたな。
だから俺は言語は何でもいいとは思わんな。まぁ、趣味レベルの小さなプログラムだったら何でもいいと思うが。

>>115
　VS6.0の「Enterprise APガイド」に、「何かの言語を既に習得している人が多いなら、
その経験を生かせるように計画すべき。新しいのを覚えるのは時間の無駄」と書いてる。
俺もそう思う。ただ言語に固執してるんじゃなくて、自分のスキルが活かせるようにしてるだけだと思うが。
それを古いと馬鹿にするのは何だかな。

大学のレベルが下がってDQNでも大学いけるようになったように、簡単な言語が出来たのでDQNでもプログラミング出来るようになった
のかいな。
よく若いやつは自分のことを棚に上げて年配の人を馬鹿にするが、情けねーなぁ。

言語の特性(あるいは特性というものの存在)に縛られてるのがオールドタイプ。

「〜(言語名/製品名/カテゴリ)というのはこれこれこういうモノだから、
　こう使うのが正しい」
のような的外れなことを言い始める人って、始末に終えない。

最近読み始めたんだけど、いつもこんな不毛な議論（というか罵りあい）
やってんの？飽きない？

>>125
HSP厨ですか？

>>126　２ｃｈ初心者？
不毛じゃないよ。決着はついてる。

HTML言語は結構速い方じゃ無いか?

>>128
決着が付いている、または、決着が付きそうもない議論を不毛な
議論と言うのだと思うけどなぁ・・・・・。
なんとなくあなたの言う決着はバイアスかかってそうだけどね。

プロジェクト全体を見渡して判断できる人間が、
その分野での必要十分なスキルをもちあわせていれば、
そもそも問題が起こらないと思う。

でも、それって難しくないかなあ。

適材適所だろ。

>>126
日本語が変だよ。
あんたの言う決着は相手を黙らせたら、かな（笑

>>124
目が節穴というのは恥ずかしいな。

JBuilderは最低128、推奨256で動かせよ
体感速度が全くちがうから。

>(Javaで作られてるらしい)
らしいってのは藁えるな。

>VS6.0の「Enterprise APガイド」に、「何かの言語を既に習得している人が多いなら、
>その経験を生かせるように計画すべき。新しいのを覚えるのは時間の無駄」

じゃあなぜMSはC#つくるの？
Window開発者は全員使い捨てにするため？(藁
全員に時間の無駄をさせるわけだ。

>>133
そうかなぁ？
議論というのは相手をへこませるためにやるんじゃないのにここじゃいつま
でも俺はこんなのできるんだぜ！だからお前はだめじゃん。
ていやつのリピートじゃない？だからあなたのいう決着も俺はえらい！
っていう決着なんじゃないかなぁ？と思ったんだけどね。

＞JBuilderは最低128、推奨256で動かせよ
何故、命令口調？
そりゃそれだけメモリ上げりゃ違うだろうよ（藁

>>135 お前もな。そう思うなら無視するか、まともなネタを振るのが良い。
ごちゃごちゃ言わないように。

＞じゃあなぜMSはC#つくるの？
ビジネスだよ。
だいたいMSが一枚岩とでも思ってるのか？笑える奴だ。

>>126
一種のレクみたいなもんじゃないの？
まぁ本人達は真剣なんだろうけどさ。
嵐に巻き込まれてズタズタにされるもヨシ、
遠くから眺めているのもまたヨシ。

>135
お前プログラマじゃないだろ。
内容がわからないなら、何故口を出す。
他でもこんな場違いなバカを演じてるのか？

>>136
今どき256Mなんて2千円だぞ（ｗ
おまえの時給でも１日分より安いだろ。
さっさと買ってきなさい。

>>140
プログラマーだし内容も理解しているけど何故自分は他の人よりできると
いうのを誇示したがるのか、普通の人の感性なら理解できないよ。

議論というのは相手をへこますゲームだ。
それによって何かが得られたらラッキーと言う程度。
その何かは目的じゃない。おまけ。

>>143
医者逝け。マジで。

>>143
ここは議論版じゃない。プログラマー版だ。

>>142
具体的にそういうレスを指して言え。

>>143
嫌われ者…

>>144
差別主義者発見
>>145
そうだな。で？

>>148
議論は禁止だそうです（ﾜﾗ

相手をへこますことが目的の議論はうざいからやめてくれ。
ま、ただのお願いだけどね。

>相手をへこますことが目的の議論はうざいからやめてくれ。
何故、命令口調？

>ま、ただのお願いだけどね。
お願いしますと言え。

お願いしますやめてください

論理的じゃないな。スレの主旨に関したことなら誰が何の目的で議論しようが人の勝手。
お願いするのも勝手。かな。
でもこれこそ主旨から反れて、本当の意味で荒れを呼ぶよね。

じゃ、やめます。(藁


自分が知っている事で知らない人をへこまそうとか
見下すというのは人間の本質だから
仕方ないと思うよ。

>普通の人の感性なら理解できないよ
普通の人でも同じでしょう。

見下される方は、怒らずに謙虚に
相手が知っている知識を吸収するのがいい。
難しいけどね。

ム板のコピペしておこう。

http://www.shiro.dreamhost.com/scheme/trans/beating-the-averages-j.html
「ほげ言語」のパラドックス

ほげ言語より上をみることができるかどうかが
その人の技術的成長を促す(ソクスｗ)

互いにハッパかけあうのって大事だと思うね。
比較されて見下されたくないとか言う、ぬるい奴が居て良い業種じゃないだろう。
俺プロじゃないけど。

第二言語は英語これ真実

sage

Σ(￣ﾛ￣|||)ｶﾞｰﾝ

>>154
本質なの？ ねぇ、人間の本質なの？

言語なんてなんでもよいＹＯ　>>1
要はいかにきれいな角度でプルグラム掻けるかだ

http://pc.2ch.net/test/read.cgi?bbs=prog&key=1004173990

>>158　ｹﾞﾗｹﾞﾗ

>>158
だからバカを相手にするなって。
毒電波に犯されるぞ。
くわばらくわばら。

バカはバカを相手にするものさ。

>>162
それはモナーの AA つきで突っ込みを入れて欲しい、という意思表示でしょうか？

すべての言葉はモナーを内包してるのだ

115が書いていることはかなり昔から真理だと思う。

いくらパソコンのCPUが速くなっても、組み込み用のマイコンのCPUが速くなっても
ゴリゴリに速く動かしたいという要求も存在するしアセンブリやCの需要はなくなら
ない。しかし、そうかといって何でもかんでもアセンブリ、Cというのも時代錯誤。
VBやPerlでササッと済ませられる所はそれで済ませるのもカッコいい。
普段はWindowsでVC++やDelphiしていても、新しいマイコンのプログラムをいじ
らなけりゃならないときには、全然違うアーキテクチャのCPUのアセンブリ言語も
使いこなす。あるいはテキスト処理が必要になったりCGIを書かなけりゃならなく
なったときにはPerlもやる。…というのが「言語に固執しない態度」であると思う。

まさかVBだけを使うVBのエキスパートが、VBが使えないマイコン環境を糞呼ばわり
しているのではあるまいな。

>>165
逆も真だということにそろそろ気づこうよ。

>>164
それが理解できる人と理解できない人がいるのだよ。
だから、オールドタイプは殲滅するのだ。

>>165 のまちがい。

>>115
要は、一つの言語が使えるようにはなったけれども、これ以上
勉強するのがいやなような奴が、「今の時代はCPUが早いんだから
Cやアセンブラなぞ勉強する必要なし」と騒いでるだけ。

プログラマなら主要な言語はすべて使えるようになれや。

出たよオールドタイプ厨・・・・・
くさっ

>>170
ﾈﾀﾆﾏｼﾞﾚｽｶｺﾜﾙｲ
ｱﾀﾏﾓﾜﾙｲ

>>169
っつーかよ、普通のエンジニアなら一つか二つ知ってりゃ、
あとはそれの応用ですぐ習得できると思うぞ。

つかさ、OSがCやアセンブラでかかれている限り、Cもアセンブラも
なくならないと思うぞ。

OSがJavaでかかれていてCPUがJavaのバイトコード直接解釈
できるようになれば、Javaの世界がくるかもな。

>>172
そりゃそのとおりなんだけど、ではなんでこんなに騒いでる奴が
多いんだ？

>>172
古い話で悪いけど、昔、プロセッサって雑誌の連載のエッセイで
「優れたエンジニアは、普段から新しいCPUの資料を集めたり、言語の勉強
なんかしないものだ。必要になればすぐに習得できるからだ。それができな
いようであれば先行きは暗い」
というようなものを読んだ。オレにはとても手の届かないレベルだと昔も今
も思う。

>>175
優れた？そんなの普通だと思うがな。

あと、金にならない言語まで勉強する必要はなし。
だもんで、Fortran, Ruby, Pascalなぞは勉強しても意味がない。

あとDelphiも。

>>176 は優れていると思う。絶賛するぞ。

>>167
わははは。
シリアスネタだけにリンクミスはつらいねぇ。
スマンけどﾜﾗﾀ。

>>177
177の勤務先の事情(または視野の範囲)を如実に語る事実が暴露されていると思う。

>>178
つかさ、いいかえると
「普通のエンジニアは、普段から新しいCPUの資料を集めたり、言語の
勉強なんかしないものだ。時間がないからだ。しかし、必要になれば
すぐに習得できなければならない。それができないようでは、食えなく
なってしまう。」
の間違いではないか？

しかし、言語の知識があって、データ構造とアルゴリズムの知識がある
やつで、どんな言語が習得困難なんだ？3日とはいわんが、1週間あれば
使えるようになるだろ。

>>179
確かに179→167→164とリンクを辿ったらむちゃむちゃ面白い。
あげ足取りになってすまん >167

>>181
レスありがとう。
一応仕事で組み込みもWindowsアプリもやってるけど、Lispは頭がスパークしては理解
しきれんかったよ。そのテの仕事が来ても多分使いものにはならんな。おれ。
あと、VHDLは仕事として使えるようになるのに1か月ぐらいかかった。泣きそうだった。

何をもって習得と言いますか？

>>184
とりあえずの習得レベルは「これこれこういうことをこの言語で
実現したい」といった要求が頭の中に浮かんだときに、正当な
解決策が頭に浮かんで、リファレンスとかは参照するかもしれない
が正しく書き上げることができること。

フラグ立てゲームじゃないんだから、何をしたら習得なんてないよ。

ちょろいな。

>>186
同意。

そういうちょろい基準で習得と言う言葉を弄んでいるわけだ。
さすがプロだね。

はあ。できないやつに限ってほえるんだよな。

＊正当な＊解決策をおまえらが選択できるのかよ。

>>190
> ＊正当な＊解決策をおまえらが選択できるのかよ。
一週間だと、俺には無理だなぁ。

やっつけ仕事でとりあえず動きゃ良いって話なら、未知の言語でも一週間でどうにかなるが（Java
の最初の仕事は、こんな感じだった）、ほんとに言語の背景を理解して正しい解決策を選択できる
ようになるには、はるかに長い時間が必要。

それに未知の言語というのも C++ 経験者が Java とか VB ならともかく、Lisp とか Prolog と言われ
たら無理だ。Hello World やら 8 queen を解く程度のプログラムは組めるが、仕事だと「ごめんなさい」
して断らせてもらうよ。

>>191
>ほんとに言語の背景を理解して正しい解決策を選択できる
>ようになるには、はるかに長い時間が必要。

同意。とりあえず使えるのと仕事で使えるのはチョト違う。

プロ�c技術板よりレベルが高い会話がされている。

ある言語をマスターしたと言えるのは
「あの処理を実現するのはこの言語では難しいな」
と分かるようになったとき。

>>193
実は知らないライブラリがあったりして。

>>194
だとしたらその言語を完全マスターしたとは
言えないだろうね。

>>195
じゃ勘違いクンが>>193のような判断を下したとすれば、
それは言語をマスターしたと言えるの？

>>134の
＞JBuilderは最低128、推奨256で動かせよ
visualJ++持ってるから、そんなのｲﾗﾈｰﾖ。関係ないけど俺のは512MB

＞らしいってのは藁えるな。
どっかの大学教授のHPに書いてた。ちゃんとJBuilder見て確かめてないので、不正確な情報だから「らしい」。
起動に2分かかるってのは雑誌に書いてた。不正確な情報なので、勝手に断言してはいけないだろ。

＞じゃあなぜMSはC#つくるの？
C#はC++開発者がターゲットではないだろ。Javaから始める初心者が増えてるから、
そのユーザー層を獲得するためじゃないかな？
C++に慣れているなら、特に理由がなければC++から派生したjavaやC#をあえて覚えないだろ。
仮想マシン上で動くからどうしても遅くなるしな。

俺は個人によって必要性が違うから、この言語は勉強しても無駄とかバカにするのは何だと思うな。

ある言語を完全マスターしたと思ったら、もうそれ以上その言語を勉強しなくなるのかな。
俺はプログラムの勉強に終わりはないと思う。

>>197
> C++に慣れているなら、特に理由がなければC++から派生したjavaやC#をあえて覚えないだろ。
C# 勉強中の VC++ プログラマですが、何か？

>>198
197も「特に理由がなければ」と条件をつけているわけだしヨイのでは。
C#はそのうち仕事で必要になりそうな気もする。
今のところ移植性は期待できないけど。

>>191
> 一週間だと、俺には無理だなぁ。

だからさぁ、一週間程度でもきちんと習得できるように
なるのが素養って奴なわけよ。無理とか言ってる奴ってのは、
そういう素養が足りないわけ。

そんなあなたにここはどうでしょう？
http://www.guninski.com/bsod1.html

>>200
妄想は sage でな。

>>200
大リーグ行っていきなり首位打者になるのなんか俺には無理とか言ってる奴ってのは
そういう素養が足りないわけ。

って言っているのと同じだね。

>>202 >>203
素養の足りない奴ら発見！！

> 大リーグ行っていきなり首位打者

そんなレベルの話じゃねえだろ。ヴァカか？

>>204
すさんだ言葉遣いは不要。もう少し穏やかに語られたし。

VBをいくら使いこなしても、
ウィンドウとメッセージとかマルチスレッドとか理解できんと思う。
まあ、理解してんでも仕事は出来るけど、
どうせプログラマーとして働くなら、そういうことも
分かるようになりたいものよ。
関数をコールするとスタックがどのように使われるか
分かってるとなおよし。

あと、継承の使えん言語で、多態の利点を理解するのは大変だし、
使っている言語の特質によって、
そのプログラマが考えつくアルゴリズムも決定される
というのは真実だと思ふ。

だから言語なんてなんでも同じだって。
アセンブリ言語があれば他の言語はいらないって。

>>206
VBは、ウィンドウとメッセージとかマルチスレッドとかを隠蔽して、処理ロジックに
専念できるように作られているのだと思います。

人間の能力には限界があるので、どこかで手を抜く必要があるのでしょう。
CPUの設計から冷却の熱力学・公認会計士なみの業務知識まで、全て知っていることが
望ましいですが、必須ではないでしょう。

勉強の為の勉強ではなく、ひとりひとりが興味が持てる得意分野を伸ばしていけば
いいんじゃないかと思います。

関係ないけど、前もって何かを習得しなきゃって発送がそもそも
派遣的でやだな。すきなことなら自然と学んでしまう、これなら
文句はないんだけど。おれも必要もないのにC++勉強したりしていろ。
派遣的なのかもしれない。

>>209
言いたいことはわかるが誰でも自分の好きなことを生業としているわけじゃない。
必要もないことを勉強しなきゃならない事なんて世間に出れば山ほどある。
それがなぜ派遣的という言葉で表されるのかよく分からない。むしろプロパーの
ほうが好きじゃないことを勉強させられる事が多いと思うけど。

>>206
VC++でも同じようなもんでしょ。
要するにWindows使ってる限り同じようなもんでしょ。
まぁ金になるのはWindows＆高水準言語なんだけどね。

>>211
> 要するにWindows使ってる限り同じようなもんでしょ。

ヴァカ？（ｗ

いや、211の言ってる事はまんざらハズレではない

VCから入った奴って本当に使えんわな。
VCだけしか知らないと応用が利かないことこのうえない。
ああいった奴にプログラマ３５才説が当てはまるのだろう。

「応用が利く」かどうかは、VCではなく個人の問題だと思う。

>>214
それはVCだけじゃねえよ。Cしか知らない、COBOLしか知らない、
Javaしか知らない。そういう奴らがクソなだけ。

CもCOBOLもJAVAも知ってるけど糞ですがなにか？

>>214
VB厨発見。

>>218
もしかして214は「VCしか知らん = APIプログラミングを知らん」の意味では?

>>217
笑いましたがなにか？

言語そのものの効率性も気になりますが、ＯＣＸ、ＤＬＬ、ＣＬＡＳＳ、pm
なんでもいいんですが、ライブラリの充実度が一番のものって
なんなんでしょうね？
最強はＡｃｔｉｖｅＸ、ＤＬＬ、Ｊａｖａとのネイティブインターフェイスも
いけるＶＣ＋＋でしょうか？

そりゃ、ウィンドウズだけの話。
ん、でも、ウィンドウズだけ知ってりゃいいか。

普通はVC++ SQL出来れば他はいらん。

>>223
× 普通はVC++ SQL出来れば他はいらん。
○ 自分の仕事では VC++ SQL出来れば他はいらん。

お客さんにしてみればちゃんと期待通りに動いてメンテナンスしてくれる
んなら言語なんて何でもいいわけだ

>>225
言語を指定してくることない?

下請けの俺の経験では、顧客が言語を指定してくることはあまりない。
元請会社の、技術に疎い営業部長あたりが適当な言語で提案する場合が多かった。
だからたまに、販売管理をCで開発したり、市販のデータベースを使わずに一から
データベースも作るという、とんでもない開発があった。

あっごめん。おれは225じゃないよ。通りすがりです。

言語指定はＳＥの仕事ですな、ふつー

>>229
普通はそうだが、顧客が言語を指定することはあるかと言えば、ある。

俺も指定された経験が何度かある。
一番ヒドかったのは、「ExcelのVBAで」という指定。
ま、言われたとおりにしたけど。

オレは「Excel」と「Access」を組み合わせて作れといわれた。
理由は、営業がお客さんに両方買ってもらったからだという。
思いっきりへこんだよ。

へたれでも議論に参加できそうなスレタイトルだと、確実に駄スレ化するな。
本当に技術的なことが議論されてればへたれは入って来れないのに。

場合によってはExcelVBAという指定は
正しいことだってあるがな。

もともと大量にあるExcelデータを加工して
レポートに出力するためにVC使えって指定されたら
それが適切だとでもいうのか？

でも、Excelの中に「大量」のデータがある状態では、ExcelVBAは使えないような気がする。んなときは、Excelから元データをCSV出力して、C言語で集計などして、PS出力とか。

失礼だが、もうちょっと考えた方がいい。
＞Excelから元データをCSV出力して、C言語で集計などして、PS出力とか。
じゃ、CSVで出力できないデータ
(書式とか、ヒント表示とか)も読み取る必要がある
仕様変更が入ったときどうするつもりよ。

ExcelVBAっつーか、実際はVBだけど
セルを直接コントロールできなくては話にならんって。

C言語が全てとか思っていると穴にはまるよ。

>>235
同意。よく似た状況に出くわしたことあるよ。

まあ、1はN88BASICでもやってなさいってこった。

>>233
どうせ COM 使って Excel を操作するから、言語は VC, VB, VBA 何でも構わんよ。VC++ なら
#import の魔法にお任せで、インターフェース取り込めるし。

さすがに素の C で書けといわれたら、やだけど。

>>238
やったことあるの？COMつかってExcel操作。

Delphiでやろうとしたら、OLEの実装がヘボなのかなんなのか。
Excelが落ちまくるんですけど。

VCでインターフェース取り込むと
VBと同等かそれ以上にExcelと親和性高いというなら
見せてもらいたいものです。

>>239
> やったことあるの？COMつかってExcel操作。
Web アプリケーションで、データを Excel のファイルでダウンロードしたいと言われたので、VBScript
から呼び出す COM を書いたことがあります。

> VCでインターフェース取り込むと
> VBと同等かそれ以上にExcelと親和性高いというなら
> 見せてもらいたいものです。
なんで喧嘩腰なの？　いや、べつに良いけど。

>>240
つーか、それって、CreateObjectしただけなんでしょ。

客があとでイジるような場合、VBAを指定してくることがあるよ。
メーカーの研究所系だと一から作るのは下請けに依頼するけど、「ちょっと変更」
は自分達でやりたいっていうのはよくあるみたい。

ソース渡しかあ、下手なソースは書けねえな。
それって内部仕様のドキュメントも添えて？
客はマクロウィルスの危険性熟知してるんだろうか？

下手なソース書くなよ
>>243はソースを隠したがる典型的なダメプログラマか？

>>243
普通、受託開発の場合は、ソースも納品が普通。
もちろん、著作権も譲り渡す。

特定顧客(親会社)からの受注のみを行なっている会社でシコシコ働いていますが、
うちは最近まで顧客からCOBOL指定される事多かった。
つーのは顧客がソース読んで仕様変更しちゃうんで、
汎用機に慣れてる顧客がカスタマイズしやすいように
してたんだわ。ついでに、会社も元々汎用機メイン人間
ばっかりだったので、必然的に開発はCOBOLだった。
しかも、ＤＢはなんとBTRIEVE（藁
でも、今はよっぽどの事がない限りVB＋BTRIEVEだな。
基幹業務なんてよっぽどの事ない限りＣとか使う必要ないし、
むしろネットワーク設計＆ＤＢ設計の方が重要でわないでしょうか。
現在の不満点はなかなかBTRIEVEを脱出できない事。
新しいＤＢを試すような時間がまったくない。
(再来年まですでに仕事の予定ができている)
基幹業務はなかなか新しい技術が導入されなくてなんだかなあ、って
感じもするが、人間のやっている業務なんて20年以上前から大して
変わらないので、別段新しい技術は必要としない。
個人的にはもっとアグレッシブに行きたいと思ってるんだが．．．

一度、キャリア相談に相談してみて
自分の市場価値を判断してもらってみては？

アグレッシブにならなきゃいけないと気が付く動機付けになるかもよ。

COBOLとVB+BTRIEVE(って何？)
って、どうなんだろ。

Windowsの場合、普通はVB+OracleかDelphi+Oracleとかでしょ。
BTRIEVEってもう過去の遺物だね。(大体DBと呼ぶのもおこがましい)
NetWareの頃は最速だったんだがね。
結局そのときに培ったノウハウが捨てきれないのと
導入実績が効いてまだ使ってる。
基幹業務は目先の機能よりも安定性と実績なんで
どうしてもこの悪循環から逃れられない。
ミドルウエアなんてバージョン変わったら別物なんだけどねえ。
で結局汎用機に逆戻りしてたりするのが現実。
アプライアンスなんて、ある意味汎用機と概念なんにも変わらんもんね。

>>248
Delphiは多くはないでしょ。
Delphi好きなプログラマはいるけど、客先に採用してもらうのが
難しいみたい。
MS-ACCESSは、わりと見るよ

Btrieve使っとります。DOS+NetWareです。
さすがに新規開発は、VB+MSSQLですが、保守は行ってます。

>>245
VB+Btrieveはやばくないですか?

FileSpec構造体などを受け渡すときに、
32bitアライメンとでうまくそろえられず、
byteを使って無理矢理復元しなきゃならないと思うのです。
さらに、受け取ったデータもフィールド区切りがあるわけではないので、
構造体を使って区切ってやろうとしても、String型は2バイトなので、
うまく受け取れないと思います。

どう処理してます?
うちは処理できずにAccess→MSSQLにうつりました。

>>250
すべてバイトで型宣言しています。もちろん、構造体もです。
ソース中の処理ではStrconv(〜〜,vbUnicode) or Strconv(〜〜,vbFromUnicode)の
オンパレードです。ファイルアクセスハンドラ書くのだるいっす。
ついでにうちの社のファイル構造仕様書がまるっきりCOBOLで、
「レベル」とか「集合項目」とかいう文言が出てきます。鬱だ．．．

>>251
VBでそこまでしてBtrieveにこだわるとは凄い。
過去のシステムがすばらしすぎたのかな。
普通は、DBを変更しちゃったほうが手っ取り早いと思います。
実は過去にシステムを作成した優秀な人たちは辞めちゃってたりして。
(それはうちの会社。他人の作ったバグに苦しめられる日々)

ところで、データを直接メンテナンスしたいときにはどうしてます?
運用中のデータをメンテナンスできるツールがなくて不便してます。

お互いがんばりましょ。

>>252
昔、Windowsの MS-ACCESS から Btrieve のファイルをアタッチして
使ってました。
今でも使えるなら、メンテナンス用としては最適だと思いますよ。

×アタッチ
○アッタチ
昔なら。

>>252
メンテはうちはもっぱら付属のFunctionExecutor(Windows版)ですね。
しかも16bit版(藁
32bit版は作らないと昨年米国本社が決定したそうです。逝ってくれ、Pervasive。
今はBtrieveはPervasiveSQLという名前に変わってDDF作ればODBC使えるんで
Accessあたりでアタッチしてもいいんですが．．．
基本的にODBC不信者なのと、DDF作るSQLDataManagerが逝ってるので使えません。
VBからでもADOやRDOとして扱う事ができるのですが、コーディングが大して
簡単にならない上に劇遅なので使えません。
結局メンテナンスツールをDelphiで自分で作ったりしてます(しかもバグ付き)。はあ。
そうそう、先に挙げたStrConvを使わなくてもBtrieveにはきちんと読み書きできます。
けど、Unicodeのまんまになってしまうので、FunctionExecutorで読めない(Ascii表示のみ)し、
レコード長が２倍になってしまってDBが膨れ上がったりしてしまいます。
>>普通は、DBを変更しちゃったほうが手っ取り早いと思います。
まったくもってその通りですね。だから私が開発する場合、排他のない
スタンドアロンのシステムなんかはMDBをADOで使ったりしてます。
>>お互いがんばりましょ。
ありがとうございます。がんばりましょう。環境の改善も．．．

0x100 get!!

今だ！0x100番ゲットォォｫｫ！！
￣￣￣￣￣∨￣￣￣　　　　　　　(´´
　　　　 ∧∧　　　）　　　　　　(´⌒(´
　　⊂（ﾟДﾟ⊂⌒｀つ≡≡≡(´⌒;;;≡≡≡
　　　　　　 ￣￣　 (´⌒(´⌒;;
　　　　　　ｽﾞｻﾞｰｰｰｰｰｯ

VBもできますよ　　　　−　普通
VBしか出来ません　　−　ﾄﾞｷｭｿ

FunctionExecutorなっつかしい。。。
バイナリーエディター部分にオペレーションの16進コードを
書き込んで実行するとバイナリーエディターに結果が返って
くるってやつでしたね。。。（極悪に使いにくい）
あんなもんVBから使い物になるんですかねぇ。。。

>>259
Windows版でしょ。VBから使うって発想がよくわからんけど、
結局メンテナンスツールだからね。使いやすいとはいえないけど
それなりのデバッグのお供＆メンテナンスには使えるよ。

捨て

pushd

>>1
世の中にはVBでFFT書いてるやつもいるしねぇ。
（しかもなんかみょうちくりんに速いし）
そう考えると、特定言語の優位ってだんだんかすんでくるね。
まあそれでも、最良のコードはC++＆ASMから生じるけど。

汎用機の世界でハフマン圧縮をCOBOLで書いていた人が居たが、
それは間違いだと思った。>>263

.NETでVBはコンバートされるんだよね。
無くなる言語は使わないのが良い。

飽きもせずVB叩きか・・・。
「無くなる言語」ねぇ。
何年先かもわからんし、VB.NETがどうなるかもまだはっきりは
わからんし、そんなに早急に結論出すのが賢いとは思わないが。

>>264
それは極端すぎる（ｗ。つーか、オモロ！

>何年先かもわからんし、VB.NETがどうなるかもまだはっきりは
次バージョンでないのは、はっきり。
VB.NETがどうなるかもはっきりしないならコンバートしてもダメってことじゃん。

>>268
ていうか、出たらすぐ前のバージョン使わなくなる、っていうわけに
いかないのは経験上わかってるだろう？
VB.NETが出ました、VBとはまったく違います、はいVB6はもう
使えません、ってことになるかい？

なりますぅ。>>269
だって、VBってOSのバージョンが上がると動かないんだもん。

今の時代言語はVB以外なら何でも言いと・・・

>>270
んなこたぁない。
ヘンなコード書いてなければな。

コードによるバージョン互換の話じゃないよ>>272
OSのバージョンが変わって無くてもVBインストーラ失敗する．．．マジ

>>273
まあ確かに、いつでもすんなり、というわけにいかんことは確かだ。
それはわかる。

だが問題があっても対処はできるぞ。めんどくさいけどね。

手で対処すんの？
コンピュータ使ってんでしょ。そんなもん使うなや。

>>275
なわけないでしょ。（苦笑）

ま、意識して避けるべきものだね不安定なものは。

>>277
不安定でないものを教えてください。

前提として不安定で無いものが無いから、安定したものを取捨選択すべきってことね。
組み合わせや相性の安定性も考えないといけないし。
Windows-VBはサイアク。Windows上ではVC++やDelの方が安定してる。

人はなんでも簡単な方に流れていくな。
ある国立大学の情報科では、hot soup processorを研究で使うと。
やめてくれー！

まぁ、簡単なソフトを作るならVBの方が手軽と思うが、
大きなソフトはやはりC++とかで作るべきです。

VBのコード生成もそのうち洗練されてC++レベルの速さに．．．なるのかな。
Visual C++には、アセンブラに匹敵する速さと書いてるが。

まぁ、数値演算などはどんな言語使おうが余り変わらんような気がするが。

>>280
大きさだけで判断しますか？それはPGとしてはそれでいいかもだけど、
SEの判断力としてはかなり問題ありですぞ。

それぞれの要求にもっとも適したものを選ぶ、というのが基本であり
ましょう。

あと、速度速度といってもよほど単純な繰り返しをするのでない限り、
通常の動作でさほど問題になるほどでもないと思うが。
んでもって日本人はせっかちというか、５秒で終わるものを１秒で
終わらせろという要求がけっこう多いが、そこまでせんでも、という
のが正直な感想だな。
まあ、客の要望ならある程度までは仕方ないけどさ。

>>77
>いまはCPUが速いので、インタープリタで十分。
>よって、コンパイルが速いのは意味が無い。
>というのが、このスレ的答えだと思うが。
VBでコンパイルすると数分かかって使えネーヨ。
このスレの前にあるDelだとVBのインタープリタ実行より高速だし。
やっぱVB使うようになると、嘘ついてでもVBやれって言うようになるんだね。

>>282
> VBでコンパイルすると数分かかって使えネーヨ。
MSWordなみの巨大プログラムを Pentium 50MHz くらいのマシンで
コンパイルしてますか？

実行速度に問題あって、安定性に問題あって、コンパイルに時間かかって、
廃棄される言語ですが、なんでこれを使いますか？

>>284
ラクだからに決まってるッショ。

「ラク＝悪」ってのは日本人固有の特徴じゃないかナ。

>>283
いや、たぶんコードの再利用がわからないので同じようなコードを
あちこちに複数使って巨大になってしまっているのだと思われ。

ラクだから、ってのは今まで出てないですが。>>285

ＲＡＤ的にWindowsの標準コントロールサポート出来てないし、
コード大きくなるし、何がラクですか？

インストール成功するものの方がラクじゃないですか。

苦労＝働いた、っていう日本人固有の考えですね。>>285
でもその苦労はコピペの苦労、
OCXだけでは機能不足でWinAPIをコールしないといけない苦労、
OCXが壊れる苦労ですよ。

>>284
>なんでこれを使いますか？
安く早く作れるからね〜
PG側の理論なんて考えて無いしね〜

>>287
うーん、ちょっと大げさでないかい？
そうでなかったら、よっぽどひどいコード書いてめちゃくちゃな不具合出し
まくってる、VB初心者の言うことのように聞こえるぞ。

「普通に」作るぶんにはそれほどひどい苦労させられることはないけど、
自分の経験上。
むしろCで書いてページ違反起こしたりフリーズさせてしまったりする
ほうが苦労だし、VC++でも「お決まり」のことをいちいち最初から全部
こっちで作ってやらなきゃいけないのも苦労だし。
まあそのぶん、自由にできる範囲が広いのはわかるけどね、それほど
「自由」を渇望するような状況には滅多に陥らないし、そういうときは
そういうときで部分的にCで書いたDll作って使うなり、VBの裏技的な
対処なり、いろいろ方法論はあるから、経験さえあればさほど「苦労」
には感じないわけさ。

C言語とVBしか出来ない人みたいですね>>290
だから、今の時代の正しい選択できないみたい。

>そういうときで部分的にCで書いたDll作って使うなり、VBの裏技的な
>対処なり、いろいろ方法論はあるから、経験さえあればさほど「苦労」
>には感じないわけさ。

「ラク＝悪」ってのは日本人固有の特徴じゃないかナ。
という言葉がぴったりな一世代前の方ですね。

>>292
？？？>>290は「苦労しない」と言ってるのでは？？？

>>291
（苦笑）そうとは限らんだろ。

そういや、なんとなくＯＳに全部付属しちゃって、ＯＳ以外はプログラム
いらなくなる日が近いんじゃないの？よう知らんが・・

アクセスとか便利だもんな。プログラマじゃなくてもＤＢ作れる。

そうだな　ユーザによるカスタマイズ可能な範囲が広くなってくると
プログラミングというより、インストール支援者みたいなもんになるんだろな

プログラミングは組込系だけ残って、しかし単価の安い外国に仕事は行くと

ターゲットによってCなどを使わざるを得ない環境のあることをわかって
いらっしゃらない方がいるようです。
>>165さんとだぶりますが、1万台生産する家電品とかあってその単価がメモリ増加やCPUの
アップグレードなどで1000円上がったとします。
これだけでハードの原価が1000万円違ってきます。CPUやメモリの制限が強く、
アセンブラの代用品であるCを使わざるを得ないわけです。
一方、windowsなどでは各ユーザにメモリなどの条件をしめしておくだけで、
勝手にユーザがメモリの増設とかしてくれるので、そんな心配はないんで、
Cとか使わなくていいわけです。

C言語とVBしか出来ないバカのせいで議論がずれちゃってるよ。
WindowsとC言語は相性が悪いんだよ。
WinAPIが膨大で呼び出し順序を制限するため、一連の処理を閉じ込めれる言語＝OOPがベスト。

従って、ＶＢは実行速度に問題あって、安定性に問題あって、コンパイルに時間かかって、
ＲＡＤにしては標準コントロール分も無い、OOP出来ない冗長コード、
廃棄される言語ですが、なんでこれを使いますか？楽の反対。

でも楽ちんだよ。

苦労が楽ちんなんですね>>300
こういう人はプログラミング向いてない。

>>299
ん？俺の意見は無視か？
逆にさぁ
＞従って、ＶＢは実行速度に問題あって、安定性に問題あって、コンパイルに時間かかって、
＞ＲＡＤにしては標準コントロール分も無い、OOP出来ない冗長コード、
＞廃棄される言語ですが、なんでこれを使いますか？楽の反対。
なんでこんな糞言語がgoogleで検索するとｲﾊﾟｰｲ引っかかると思う？
なんでこんな糞言語が本屋行けば大量に参考書が売られていると思う？
ちょっと考えて見ないか？

>>302
もういいじゃん。そろそろ平行線になってきたと思わないか？
ほっときゃいいよ。あぁいえば系の人間にはさ。

>ん？俺の意見は無視か？
無視じゃなくて間違ってるじゃん。

>ちょっと考えて見ないか？
考えてみないかじゃなくて、理由を書け。
廃棄されるということは欠陥品、リコール。
コンピュータの世界で廃棄されるというのは最大の問題、
一般論として使っちゃイカンということ。

>廃棄されるということは欠陥品、リコール
客に納入される前に廃棄されたって事か？
そんなことあるんか？

>無視じゃなくて間違ってるじゃん。
どこが間違っているんだ？指摘してくれ。

>考えてみないかじゃなくて、理由を書け。
まず、俺は業務系アプリ開発についてはVBは有効だと思っている。
それ以外の事については知らん。例えばゲーム系においてVBは使えない
というのならばそれについては俺は経験が無いんで何も語れない。
それで良いなら理由書くけどよい？>>304

>>廃棄されるということは欠陥品、リコール
>客に納入される前に廃棄されたって事か？
>そんなことあるんか？

マイクロソフトが現行VBを廃棄する。

>どこが間違っているんだ？指摘してくれ。
廃棄される言語が業務系アプリに有効？間違いです。

>それで良いなら理由書くけどよい？>>304
これについての回答はないの？
議論するきないか。
（304と306が別人だったらスマソ）

>議論するきないか。
議論しても良いがもう夜だよ。
先ず、先行して書いておくね。
ペタペタコントロールを貼ることが出来ない言語は無いよ、C++でもDelでも。
そのコントロールが最も少ないのがVB。
コントロールが普通OOPでクラスになるときAPIの機能以上にメソッドが足されてる。
けど、ActiveXはWinAPIよりプロパティ少ない。
ActiveXを拡張することは出来ないが、OOP言語の振る舞いは派生で変更出来る。

そのペタペタ貼れるコントロールはActiveXだと限界があるんだよね。
無駄に動作が遅いし細部を派生で変えることが出来ないから生産性悪い。
C++やDel用に用意されてる無料のクラスだと
インタープリタからGISライブラリから高性能なものが貼るだけ。
それが、VBだとグラフィックやフック程度でActiveX買わなきゃならんのでしょ。
クラスライブラリ利用だと数行で終るものが。

> ペタペタコントロールを貼ることが出来ない言語は無いよ
山田く〜ん！
>>308 の生爪はいで！

>>308
もう寝ちゃったかな？
>>308で書いている事は正解だと思うよ。でもね、そのような言語仕様の問題は
システム開発においては一つのファクターでしかないのよ。

システム開発において重要なのは所謂「人、物、金」をどうするかって事が問題で、
例えばフロントエンドのGUI作成等の比較的どーでもいい部分にはあまりお金をかけ
たくない訳ですわ。んで、そういう部分には人件費が安く人材が集まり易いVBが有効
な訳。そして、そこで浮いたお金をどーしても止まっちゃいけない部分に使う。

もちろん、>>308で書いてあるような事はあると思う。でも、そんなに極限まで
機能を使う部分で使用しないんで、VBでも不都合はあまり発生しないんだよね。
パフォーマンスが悪いっていうのならHWの増強をしたほうが最近はトータルの
コストが安いし。

別にVBでもええやん、という態度がムカつくんだろうね。
何で俺の言ってることが分からないんだろう、ってイライラするんだね。
俺の言ってることが分からない奴なんか消えてなくなっちゃばいいんだ、って思うんだね。

でも、VBでやっていけてるならそれでええやん。
もし、やっていけなくなったときには、そのときに別のものに乗り換えるから、それでええやん。
…っていうのはダメ?

>>312
いいんじゃない。というかほとんどみんなそう思ってるよ。
PCで動くアプリなんて一度動いたらしばーらくそのまんまだし
移行するときはクラッシュ＆ビルドなんだからそのときに一番
効率が良いモノを選ぶのがあたりまえっしょ。

言いたいことは分かるんだけど意地はってもしょうがないのにね。

↓DQNプログラマの言語遍歴
COBOL->VB->JAVA

なんで「COBOL->VB->JAVA」の遍歴がDQNなのかな〜。 別にええや〜ん。

>システム開発において重要なのは所謂「人、物、金」をどうするかって事が問題で、
>もし、やっていけなくなったときには、そのときに別のものに乗り換えるから、それでええやん。
そうか、ブビ厨集めて作らせれば良いんだ。VB6の次のバージョンアップが無いのは確定だから、
次の言語に作り直されば良いんだ、デスマーチで。自分はやらなくて良いから"楽"だね。

ってなると思ってんのかよ。結局自分に跳ね返ってくるやん。
人海戦術とデスマーチが楽ですか。それは奴隷を使う苦労を楽って言ってるだけじゃん。
VBしか出来ない人ってウソついてまでVBは楽って言うんだね。

中途半端にかじってるからこういうこと言うんだろうなぁ。

アメリカであれだけVBで組んだアプリがぼこぼこ使われてる状況で
いきなり「はい、WinXPからはVBはサポートしません」とか「次期OS
ではVBは使えません」なんてこと、MSがするとでも思っているのか。
そんなの自殺行為だっちゅうに。

NECだって98シリーズのソフトウェア資産に未練があって、かなり
最近までDOS/Vとは違う独自仕様を保ち続けてきたくらいだぜ。

情報が中途半端ですね>>317
VB6のサポートとまるから、VB.NETの仕様でM$とユーザが折衝してるんだヨ。
ぶつかって、VB止めるって表明してるところさえ出てる。
ブビ厨の考えや持ってる情報なんて、ちゅーとはんぱで誰も相手にしないサ。

>>318
だから、自殺行為なんだろ。
MS、Windowsじたいがダメ、ってことだろ。
そこまで考える余裕ないか？

仕事で開発用ツールを作ることがよくある。
自分はたいていVBで作る。
以前、たまたま似たようなツールを自分と同僚のふたりが作ったことが
あったが、自分はVBで半日で作り、同僚はVC++で３〜４日かかって
作ってた。ちなみにそいつはVC++経験５年以上、当時の自分はVB経験
３年弱だ。
しかも機能は自分作のほうが上、同僚のはほんとに基本的な機能だけ
で、細かい部分はエディタなどで手作業でやらねばならん、ほとんど
生産性向上に貢献してない駄作だった。
そのうえバグがかなりあって、ちょっと特殊な操作をするとページ違反が
起きたり、動作がおかしくなったり。
結局、バグ取りを延々と１ヶ月以上もやってて、かえってプロジェクト
そのものの足を引っ張った。

まあ、それぞれに向き不向きがあるんじゃないか、というのがオレの見方
だけど。
とはいえDelphiのほうがさらに「ラク」だというのは認める。
たまたま環境を持ってないから使ってないだけで。

意味不明。論理的に書いてね。>>319
Windowsのカーネルはダメじゃないよ。
その上で動くサービス同士を、戦略上組み合わせたために破綻。
その破綻を破棄するためにVB捨てるんでしょ。

今の時代は言語を選ばないといけないということだね>>320
汎用機時代はCOBOLなんかで良かったんだろうが。

こんな話しがある　心理学者の実験で　２つのグループに同じ単純作業まあ１時間くらいのをさせた
　違いは報酬がAグループには１００円　Bグループには千円だった事

その後、その作業は面白かったかを聞いたら・・・・・・

>>322
Aグループが「おもしろかった」
Bグループが「つまんなかった」

と答えた。　この事から VB とVCについての・・・・

言語だけで報酬が決まるわけじゃなかろうに（苦笑）

内容はＯＫ>>323
だけど、VCじゃ曖昧。C++とした方が。
Windows-C言語って結構地獄だよ。

>320　そうだね　まかない作る時は３〜４日でどれだけ作れるかが勝負だよね

俺はDelphiだな　自分用にTEditorとかコンポのライセンス買ってやってる

まかない料理か・・・たしかに言語は何でもOK　味こそ全ての世界だな

まかない１本勝負、制限時間２日　とやったら

経験年数２年限定、
１ delphi使い
2 VB使い
3 Java使い
4 C++使い
かな、経験年数10年ならどうだろう？

経験年数１０年でも逆転しないように思う。

それより〆切１ヶ月のちょっと難題になるとどうかなを論じたい

どっちにしても、経験年数限定勝負で特殊な条件が無ければDelphiの一人勝ちだろ

まあ経験者揃えるのが大変とか、
SDKがVC++だからとか色んな要素があって現状なんだからさ

>>318
一応308だと思ってレスを書くよ。
>そうか、ブビ厨集めて作らせれば良いんだ。VB6の次のバージョンアップが無いのは確定だから、
>次の言語に作り直されば良いんだ、デスマーチで。自分はやらなくて良いから"楽"だね。
オレの脳味噌が足らんのかも知れないけど、言っている意味が良くわからん。
VBが新しくなった時点で何故システムを作りけなきゃいけないんだ？
新規要件が発生した時に、その時点でのベストな言語は何かを考えれば良いわけだろ？
んで、現状ではフロントエンドのGUI作成等の比較的どーでもいい部分の開発において、コスト、
開発工数、人員の確保等を考えるとVBがベストと言っているんだけどなぁ。

後さ、VBを使う=デスマーチ、人海戦術になると思っている？
その原因として>>308-309で挙げた事（もちろんそれだけではないだろうけど）が起因すると考え
ている？

う〜ん、オレの経験不足かも知れないけど、そういう事は今まで経験してないなぁ。
>>311でも書いたけど、VBを使う部分というのは全体の一部でしかも致命傷を与える部分じゃない
からねぇ。もうちょっというとデスマーチになる原因というのは別の所にあると思うんだけどなぁ。


例えばさ軽自動車ってスポーツカーに比べれば相当性能は悪いじゃない。
でもさ、性能が悪いからって無くならないよね？
それは軽自動車にもそれなりの利用価値があるからだろ？
上にもレスをつけている人がいるけど、要は適材適所なんじゃないのかな。

がいしゅつの内容だから放置>>332
VBの不安定性のところで、ターゲットバージョンでも不安定、
バージョン変わると動かんという話は終わってるよ。

289って前提条件否定されても自分の結論は正しい、って言いはるね。
プログラミング向いてないかも。（大きなお世話かな）

>ターゲットバージョンでも不安定、
だからさ、不安定になるような機能まで使わないんだって。
仮に不安定になったとしても問題無い部分でしか使わないの。
んで、なんでそこまでして使うかというと、
「コスト、開発工数、人員の確保等を考えるとVBがベスト」
って事が言いたいんだけどなぁ。
この辺の話しをあえて避けてる？

ブビ厨はウソまでつくが289がその例だな。
>仮に不安定になったとしても問題無い部分でしか使わないの。
そんなんないよ。VB付属のインストーラ（6はついてないかも）でも、
インストールシールドで作っても失敗する。何で？って感じ。

>「コスト、開発工数、人員の確保等を考えるとVBがベスト」
VBの生産性の悪さはｲﾊﾟｰｲ書いたが一つも反論してないよね。
システム開発で生産性が悪いものはデスマーチ。

書き漏らしたが、VBで通常の処理しか行わないアプリでもインストール失敗する。

いや、俺はVBは使わないけど
　業務系のアプリってのは基本的に、そのパソコンでそのソフトしか使わない
　って感じの事が多いんだ

　だから、他のパソコンで動かないとかOSのバージョンアップとか、そんな議
　論は基本的に無意味なんだよ

　もちろん別の世界もある訳で、　少し上にある「まかない」的な内部ツールなん
かは出来るだけ多くの環境で動いた方がいい。　だからわざわざ Win16
アプリで作ったりするしね。

まあ、お互いに自分の価値観を述べ合うのはいいけど、それには正誤や
優劣はない話しでさ、

　技術屋の判断基準は客がどれだけ満足したかって所にあるべきで、

ってまあいいか・・・・どうせ俺がこんな事書いたってクソ議論は続くんだろうしな

>>336
VB6にはインストーラついてるよ。ていうか使ったことないのね、あなた。
>>337
んなこたぁない。それは極論。ていうかあなたのやり方が悪い、たぶん。

289じゃないよー、ちょっとつっこんでみたかっただけ。

289と同じくらい頭悪いですね>>338

>　だから、他のパソコンで動かないとかOSのバージョンアップとか、そんな議
>　論は基本的に無意味なんだよ
すでに、このスレの前提条件とあってない。
このスレの１の文章からいくとパソコンやOSがカバー出来ない範囲は×です。

で、その　まかない話しで、やっぱりDelphiが一番ってのは誰も異論が無いわけ？

そんなにDelphiっていいの？

>>337
Hello World でインストール失敗する？
純粋な質問。

>>342
VB6は大丈夫かもしれないが、下位バージョンだとランタイム初期化失敗する。
（VB5は大丈夫かも。VB6を入れるとVB5のJetエンジン初期化は失敗してた。）

>>340　ふーん　そんな所に噛み付くか・・・クワバラクワバラ
　　　　　なんか子犬が尻尾踏まれて自分の尻尾に噛み付いてるような
　　　　　そんな光景にほほえむ今日このごろ

>>341 タマに使うけど、Delphiはいいよ。これだけで仕事出来るなら一番だろうね

>>343
Hello World で Jet 使わないだろ、というツッコミはいいとして、

Jet3.6 と 3.5 の問題はMSにドキュメントがあって、古いMDACを
インストールするようにすれば解決するんじゃなかったかな。

>>345
いや、だから「VB5は大丈夫かも」、の後にJetのこと書いてるヨ。

その解決方って．．．（略）

>>340
あ、なるほど、そういう意味だったのか。どうもかみ合わないと思ったら
「パソコンやOSがカバー出来ない範囲は×です」
という前提条件をつけていたのね。（前提条件否定って言われてなんの
ことか分からんかった）そうだなぁ、そういう意味じゃ間違っているかもなぁ。
つうか始めからレス読んでなかったオレが悪かったスマソ。

ただ、>>338が書いた事は業務アプリに関しては正しいことなのよ。
そういう世界もあると言う事を覚えておいて損はないと思うよ。

では　このスレの結論は　やっぱりDelphiが一番というオチで

なんか判らんが　そういうことで　善哉　甘いなおいしいなっと


　しゅ・・・しゅ・・・・

>>348 えー、なんで？

Delphiはいいと思うけど、仕事で使わせてくれないところ、俺の周囲は多いからなぁ。
Windows以外のプラットフォームに移植できねーのが理由。
作ったものはWindows（CE含む）、Linux、果ては組み込みまで移植の範囲が広がる
ところだから。

もちろん、俺は大概何でも（ひとまずWindowsベースならC++,VB,Java,Delphi,x86asm）
使うから「今の時代、言語は何でもいい」けどな。

ここで、特定の言語しか使えないことの言い訳にしてるやつは、ちょっとつまんないね。

Delphiで開発したいけど、お客がVB4を指定してくる・・・

そういうバヤイはC++が良いの？　STLはどんな感じ？>>350

>>350
VBもWindows以外のプラットフォームに移植できないよね？

もし俺が無知なんだったらスマソ・・・。

>>351
ＶＢ４？Win95orNT3.51固定かよ！

こらこら>>350 終了しとらんじゃないか

このスレの１の文章からいくと　組み込みやCEを持ち出すのは×です

>>355
それはそうなんだけど、Linuxや組み込みまで広げといた方が自分の首を締めない、
ということはあるヨ。
自分は今まで組み込みやって来なかったことを後悔してる。

>>354
今のところ、動作環境のOSにはWin95/98/Me/2000があります(泣)
インストーラこけるのに、無理やり動かさないでくれ・・・

去年、就職活動した時に、意外な程DelphiやPython使ってる会社が
あったなぁ。

C++が無難。>>352
STLは俺的には可だけど、
小回りの利く汎用ライブラリはもうすでに手元にあるので使ってない。
やぱし保守を考えてしまうので。

で、アルゴリズミックな部分はやぱしC++が一番いいと思う。
移植性のあるライブラリと、OS依存のライブラリを分離しておくのが基本。

あと、C++で作ったもので、できるものはCOMにしとく。
VBは製品作るときは使わん。モジュールテスト用＆急場しのぎ。
VBはWin以外のプラットフォーム不可だと思ったけど、俺も詳しくは知らないです。

C++で行くとこまで行っちゃってるので、他の需要はあまり感じてないっす。
だからDelphiは面白半分です。よくできてると思います。
でももしもこれ使う仕事が来たら、
C++で作ったCOMのモジュールやDLLはがしがし使うと思う。
同じレベルのものDelphiで作るの億劫だし（ｗ

てなことで〜。

>去年、就職活動した時に、意外な程DelphiやPython使ってる会社が
Pythonの利用はLinuxで？それともZopeとかいうWebアプリ？

>>350
状況は良く判るよ。でも、既存のソース資産が云々言ってると、いつの間にか時代の流れに
取り残されてしまう場合もあるからなあ・・・そんな会社沢山見たよ

　大事なのはソースじゃなくて、ノウハウなんだよね　でプログラマの世界じゃノウハウはすぐ
に陳腐化してしまう　１の言うとおり、サイズや速度は無視出来るという前提で書いてない
時のライブラリは、やっぱり今からみたら違うんだよね。

俺も10年選手でC/C++のソース大量にあったけど思い切って新プロジェクトDelphiでやったら
移植含めて同じ程度の時間で出来ちゃったよ

てな経験から、C#が出たら評価によってはWeb回りは一挙に移動するつもりだよ
　もちろん組込用にはC使うし、WinアプリはDelphi使うだろうけどね


でもまあそれを選ぶのは上や客のやる事だって面もあるけど、それを言わせてるのは
結局プログラマって事もあるからさ