- PR -

開発ツール過去最高の売り上げのVS .NET

投稿者投稿内容
hitoko
ぬし
会議室デビュー日: 2002/05/12
投稿数: 505
投稿日時: 2002-05-21 20:49
引用:

autumnさんの書き込み (2002-05-21 13:58) より:
 必要なのは、最先端を追いかけることではなく、新しい技術のメリット、デメリットを正しく把握して、必要があれば利用することだと思います。
 たとえば、DOS時代のBASIC(MS-DOS版N88-BASIC? QB? VB for DOS?)と比較すれば、VB.NETは非常に生産性が高いと思いますから、勉強する時間や、新しい開発環境を買うお金を差し引いても、大きなメリットが引き出せると思います。
 でも、まさにDOSで動かすことに意味があるのなら、VB.NETを使うことに意味はありませんね。



autumさんまさに正論ですね。VB.NETは、勉強しそして大枚をはたいでも購入する価値があるくらい生産性が高いのですね。私もがんばって最先端技術について行きたいと思います。
autumn
大ベテラン
会議室デビュー日: 2001/07/27
投稿数: 215
投稿日時: 2002-05-22 17:49
引用:

私もがんばって最先端技術について行きたいと思います。


 余談ですが、頑張りすぎると、なかなか続かないと思います。
 頑張るのは今だけ。山を越えれば、以前より楽になると思わねば続きません。
 横着のためにどんな努力もいとわない、横着至上主義者は、コンピュータを進歩させる原動力です
hitoko
ぬし
会議室デビュー日: 2002/05/12
投稿数: 505
投稿日時: 2002-05-23 07:39
 横着のためにどんな努力もいとわない、横着至上主義者は、コンピュータを進歩させる原動力です
[/quote]
私も文化は、みんなが楽をしたいから進歩するものだと考えています。
VB.netは、VB6.0より生産性において楽ができる、すなわち横着できるということですね!!!!!!!!
かえる
ぬし
会議室デビュー日: 2002/01/07
投稿数: 459
投稿日時: 2002-05-23 10:30
確かに、あるレベル以上で無い場合、
マイクロソフトは現状でも強いし、
上へ上がろうと、エンタープライズに対する挑戦をいろいろ
試行錯誤しながら、あっちこっちへと、挑戦してるし、
逆に上から見ると、HP、サンマイクロ、その他、下への挑戦、
マイクロソフトの得意だった分野への挑戦が見られると思いますが、
一つだけ、VS.NETや、VisualStudio関係を使い続けて、
感じることがあります。
すでに、UNIXも、本来の開発された当時とは違う使い方がメインになっていますが。。。
マイクロソフト製品は、技術のみでなく、社風や、企業が計画をたて、
利益追求を最初から目的にいろいろな物を提供していること。
UNIXやLinuxも、現在は、同様ですが、
出発点は、全く相容れない違う文化で創れた物だけあって、
時々、それを実感します。
現役のプログラマやエンジニアが自分たちの、為に、営利を求めずに
最初は作られた。。。自分たちが使いやすいように、自分たちが使うために。。。
いわゆる、エンジニアの純粋なる研究開発として、生まれて現在に至った物、
マイクロソフトのは、BASICやMS-DOSの、最初の出発点で、
利益追求を目的に企業として上へ上へと目指して作られた。。。
結果、今回は違いますが、ベータの英語版が最初に出荷された段階では、
それが、どうなるか、読めない。
中止になることもあるし、そのまま進む場合もあるし、
UNIX系も現在では同じになっていますが。。。
開発言語環境としては、デファクトスタンダードはやはり、マイクロソフト製品の
方が多い。
スタンダードは、UNIX系列の方が多い、
あと、実験的な物は、UNIXやLinuxでは提供されるが、
マイクロソフト系列では、あまり提供されない。。。
などなど、使い道をその場その場で、最適なのはどれか?
ある、仕事、課題を与えられた時、考えなければならないと思います。
VB.netも同じ。。。
技術面で、細かい詳細やOSのサービスや、ハードの制御などへ降りて行くには
不向き。。。と感じてます。
このレベルでは、現状及び、今後しばらく、やはり、高級言語から順に並べると
Java、C++、C、アセンブラに、現在でもなると思います。
VB.Netはプロトタイプを作ったり、ハードの性能がいいものを使えば、
基幹業務のクライアントとしてすごく、便利だと思います。
過去に、古すぎますが、VMSをサーバーにミドルウェアを間にはさんで、
クライアントにVBを使ったことがありますが、
これには、欠点がありました。
お客さんの上の方の方、かなり、規模の大きな会社なんですが。。。
その本社の、部長だったかな?当時、が、パソコンマニア的な要素があり、
契約書に盛り込まなかったのも原因の一つでそれは、開発側の落ち度でも
ありますが、ソースを提供することになる。
ゆえに、いじることが出来る。
で、勝手にいじられて、動かないと、連絡が、
で、直して注意しても、また、いじる。
この繰り返しの経験があるので、
相手の要求する技術的な要求仕様だけでなく、知識、興味、その他
そういう物も把握したりして、
本当に、一部であっても、ソースが見える形で提供していいのかどうか?
純粋にバイナリー以外、提供してはまずいのではないか?
こういう観点からも、開発言語は、見る必要があると思います。
なので、VB.netを使うか?C#を使うか?C++を使うか?
などなど、言語の選択には、技術以外の情報も含めた判断が実務では
必要と思われます。
ここのスレッドのタイトルと、一部重なり、一部はずれた、内容になってしまいましたが
新しさと便利さと、生産性など、技術面のみで語られて居たので、
いろいろな方向から見る必要があると実務では思い、
このような書き込みをさせて頂きました。
VB.Netに対する、評価は私も同じく、横着できて、生産性が高まり
すばらしいと、思います。
VB6.0と比べるとなおさら。。。
ただ、実際にはそれだけで、実務で選択するのは危険もあると思います。
観点がずれてる部分もあり申し訳ありませんが、
よろしくお願いします。
Muse
常連さん
会議室デビュー日: 2002/03/08
投稿数: 34
投稿日時: 2002-05-23 19:22
引用:

autumnさんの書き込み (2002-05-22 17:49) より:

 横着のためにどんな努力もいとわない、横着至上主義者は、コンピュータを進歩させる原動力です


まったくその通り!
ラフィン
ぬし
会議室デビュー日: 2002/05/23
投稿数: 809
お住まい・勤務地: 外野
投稿日時: 2002-05-24 23:38
引用:

hitokoさんの書き込み (2002-05-21 20:49) より:
VB.NETは、勉強しそして大枚をはたいでも購入する価値があるくらい生産性が高いのですね。私もがんばって最先端技術について行きたいと思います。


買えばOKというものでは...
オブジェクト指向は「指向するだけで結局は人」と言われます。
「VisualBasicよりVisualC++の方が生産性がいい」と言えるひとにとって.Netは無条件に生産性がいいツールなのでしょうが、そうでない人にとっては使い方一つだと思います。
object
ぬし
会議室デビュー日: 2002/03/20
投稿数: 338
お住まい・勤務地: 香川県高松市
投稿日時: 2002-05-25 12:16
引用:

ラフィンさんの書き込み (2002-05-24 23:38) より:

買えばOKというものでは...
オブジェクト指向は「指向するだけで結局は人」と言われます。
「VisualBasicよりVisualC++の方が生産性がいい」と言えるひとにとって.Netは無条件に生産性がいいツールなのでしょうが、そうでない人にとっては使い方一つだと思います。



私は、先ずは買って、使ってみるべきだと思います。

「VisualBasicよりVisualC++の方が生産性がいい」と言えるひと

私は、そういう人もいると思います。
コンポーネントベースのRADというメリット以上に、VisualBasicには表記上の異様さがあると私は思います。
(だから、VisualBasic悪いというのではありません。これは文化の違いだと思います。)

それに、VisualBasicはコンポーネントベースではありますが、オブジェクト指向ではないと思います。

それでは、VisualC++はどうでしょう?
確かに、オブジェクト指向ではあります。
でも、VisualC++は言うならばクラス指向です。
これでは、いつまで経っても、効率が上がる事は無いと思います。

そこで、C#です!
C#は、コンポーネント指向です!
現在のコンポーネントは、設計時インターフェース(対人)に、先ず特徴があると思います。
クラス指向では、実行時インターフェースしかありません。
コンポーネントを作成する場合、設計時インターフェースを実装する必要がある訳です。
でも、この設計時インターフェースがあるおかげで、コンポーネントのユーザーはコンポーネントのインスタンスを設計時にかなり制御管理出来ます。
コンポーネント指向のメリットは、現在の所、この設計時の制御管理が、実行時に有効に作用しているという形で現れていると、私は思います。

私は、コンポーネントを考える上で、
1)プロパティ
2)メソッド
3)イベント
4)設計時インターフェース
5)実行時インターフェース
が重要であると思っています。
これらの要素の重要性を、実体験する意味でも、先ず買ってみるべきだと私は思います。

(因みに、私はこれらに対する体験を、「Delphi」でさせて頂きました。言語がパスカルという特殊性はありますが、コンポーネント指向を言語レベルでサポートした、本当に最初の言語ではないかと私は思っています。未だに感謝しています。)
かえる
ぬし
会議室デビュー日: 2002/01/07
投稿数: 459
投稿日時: 2002-05-25 12:32
こう言ってしまえば、終わりかもしれませんが、
目的しだいです。
どれを使おうが、どれを選ぼうが、
目的にあった物を選ぶ。
たとえば、現在では昔と違い、極端な例になるかもしれませんが、
特殊な科学的なまたは、応用数学のような分野で計算させるのだけが
目的なら、FORTRANでも、ある程度カバーできるし、
VisualStudio6.0で、使えるものもあるし、
純粋に、事務処理のみ、で、COBOLを過去に長く使っていたなら
COBOLでもいいし、
ある意味、重要なのは最終的に作る物で、
手段は、それに最も似合ったものを選ぶ。
または、あと、自分自身の過去の経験から選ぶ。
などなど、極端な事を言ってしまえば、Officeなどと同じく、
言語も、道具の1つだと思います。
こう言い切ってしまうと、後が無いかもしれませんが。
でも、重要なのは、どれだけ速く、どれだけ、目的にあった物を
どれだけ、バグがなく、完成させるか?です。
そう、私は思いますが?

スキルアップ/キャリアアップ(JOB@IT)