アカウント名:
パスワード:
言語的にもランタイム的にも。一緒にしたらダメだと思うのだが。
確かに、.netが出た頃に、VBでそのまま開発できるんだ、と思ってコーディングしたら、なんかすごいVBじゃない感じがありました。VB.NETでコーディングしていると「無理やりBASICを.NETに合わせている」という感じがしました。.NETはC#ありきなんでしょうか。今ではC#のほうが言語的に使いやすいと思っています。
あと、VB 6.0からVB.NETへの改修(移植)がかなりコストがかかるので、今でもVB 6.0のexeがそのまま動いているところもかなりあります。VB 6.0のソースコードを.NETに変換するツールがVisual Studio(確か2005?)に組み込まれているので簡単に移植できるだろ、と思
>大抵のお仕事は地雷案件です。言語自体が地雷なのではないかと。できることが増えて言語自体がお手軽言語から厳密な言語になったにもかかわらず、コンパイラーの警告が弱いので動かしてみてミスに気づいて修正に時間がかかるなんてこともざらだし。Visual StudioのサポートもC#と比べて弱い時期が続いたし。
中途半端にMSのサポートがあるのでユーザーが何とかしようという文化もないし。
個人的には、もはやVB.NETはBasicを名乗るべきではないと思います。
そこは「Visual Basic.NETはそれが言語名であってBasicではない」と思うべきじゃないかなそもそもで言ってしまえば.NETの前(Visual Basic)の時点で「BASICなのか」と言われたら違うと言わざるを得ない内容だった。行番号とかないし。その前身のQuick Basicが辛うじて一般的なBASICの範疇に入るかは入らないか怪しいぐらいだったように記憶している。
なので「Visual Basic」という固有名称であって「VisualなBasic」ではない、というところからスタートしてるんだと思うよ、実質的には
#ところで個人的にはVB6.0は「ちゃんと使えば」ポテンシャル高い言語なので続行して欲しかった#VBAはメンテされ続けてるんだからそっちとマージすりゃいけるんじゃねーの?と思うわけだが
.NETに移行しようとしている中でCOMのラインも残すのはマイクロソフトの社内リソースが分散されて望ましくないです。
もし、VB6.0も続けてたら、.NETがポシャって今頃目も当てられない事になってたかも。
現実問題、OfficeはCOMベースだし、OfficeにはまだVBAが残ってるしで、社内リソースは分散されてる流石にOfficeのマクロ絡みの後方互換を切り捨てるのは10年オーダーでかかるだろうから当分COMは残るし、だったら別に非.NETのVBをサポートするのもアリなんでねーの?少なくともVSTOとか中途半端に無理するよりはマシだと思うけどなあ
むしろ.Netが混乱の原因じゃないかな。特にWPFの失敗によって、デスクトップアプリケーションの開発市場が大きく縮小したのはかなり大きいと思う。最高レベルの性能と機能を発揮するのがデスクトップアプリの強みなのに、純正ツール使ってもVB6.0よりもっさりしたアプリしか開発出来ないってどう考えても商品としておかしい。おまけに今頃になってCOMベースのUWP出して来るって迷走そのものだわ。
VB6.0に足りなかったのは、構造化例外だけだと思ってます。エラー処理だけはどうにもやりにくかった。try/catch/finallyを全て on error goto で書く手間といったら…。
インターフェィスももうちょい使いやすければ良かったのにとは思いますね。ほぼ使われない機能だったんじゃないかな。でもとりあえずオブジェクト指向で作るうえで最低限の能力はありました。
LongLong型無いけど通貨型でごまかせたし、Win32APIを使いやすかったしOSとの親和性も高かったですねー…。IDEもVC6に比べたら遙かにマシだったし。
今でも、ちっちゃいアンマネージドのツール作る時は重宝してます。
関数が動的につくれない(1度なら作れるけど)のと関数が第一級オブジェクトになってほしいかな。クラスとインターフェースに不満はあるけどプロパティとイベントが便利なのでまぁそこはそういうものだと妥協するとして。あと暗黙の型変換はなくしてほしい。
というかそういう方向の進化でよかったのに、.NETでIDEの起動も時間かかるしVBのアドバンテージが損なわれちゃったよね。.NETでは名前空間隠してたりFormの継承情報もdesignerコードにあったり、そういうのが嫌でC#に完全に移行してしまいました。
# returnもほしい。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
VBとVB.NETは別物 (スコア:0)
言語的にもランタイム的にも。
一緒にしたらダメだと思うのだが。
Re: (スコア:0)
確かに、.netが出た頃に、VBでそのまま開発できるんだ、と思ってコーディングしたら、なんかすごいVBじゃない感じがありました。
VB.NETでコーディングしていると「無理やりBASICを.NETに合わせている」という感じがしました。
.NETはC#ありきなんでしょうか。
今ではC#のほうが言語的に使いやすいと思っています。
あと、VB 6.0からVB.NETへの改修(移植)がかなりコストがかかるので、今でもVB 6.0のexeがそのまま動いているところもかなりあります。
VB 6.0のソースコードを.NETに変換するツールがVisual Studio(確か2005?)に組み込まれているので簡単に移植できるだろ、と思
Re:VBとVB.NETは別物 (スコア:0)
>大抵のお仕事は地雷案件です。
言語自体が地雷なのではないかと。
できることが増えて言語自体がお手軽言語から厳密な言語になったにもかかわらず、コンパイラーの警告が弱いので動かしてみてミスに気づいて修正に時間がかかるなんてこともざらだし。
Visual StudioのサポートもC#と比べて弱い時期が続いたし。
中途半端にMSのサポートがあるのでユーザーが何とかしようという文化もないし。
個人的には、もはやVB.NETはBasicを名乗るべきではないと思います。
Re: (スコア:0)
そこは「Visual Basic.NETはそれが言語名であってBasicではない」と思うべきじゃないかな
そもそもで言ってしまえば.NETの前(Visual Basic)の時点で「BASICなのか」と言われたら違うと言わざるを得ない内容だった。行番号とかないし。
その前身のQuick Basicが辛うじて一般的なBASICの範疇に入るかは入らないか怪しいぐらいだったように記憶している。
なので「Visual Basic」という固有名称であって「VisualなBasic」ではない、というところからスタートしてるんだと思うよ、実質的には
#ところで個人的にはVB6.0は「ちゃんと使えば」ポテンシャル高い言語なので続行して欲しかった
#VBAはメンテされ続けてるんだからそっちとマージすりゃいけるんじゃねーの?と思うわけだが
Re: (スコア:0)
.NETに移行しようとしている中でCOMのラインも残すのはマイクロソフトの社内リソースが分散されて望ましくないです。
もし、VB6.0も続けてたら、.NETがポシャって今頃目も当てられない事になってたかも。
Re: (スコア:0)
現実問題、OfficeはCOMベースだし、OfficeにはまだVBAが残ってるしで、社内リソースは分散されてる
流石にOfficeのマクロ絡みの後方互換を切り捨てるのは10年オーダーでかかるだろうから当分COMは残るし、だったら別に非.NETのVBをサポートするのもアリなんでねーの?
少なくともVSTOとか中途半端に無理するよりはマシだと思うけどなあ
Re: (スコア:0)
むしろ.Netが混乱の原因じゃないかな。特にWPFの失敗によって、デスクトップアプリケーションの開発市場が大きく縮小したのはかなり大きいと思う。最高レベルの性能と機能を発揮するのがデスクトップアプリの強みなのに、純正ツール使ってもVB6.0よりもっさりしたアプリしか開発出来ないってどう考えても商品としておかしい。おまけに今頃になってCOMベースのUWP出して来るって迷走そのものだわ。
Re: (スコア:0)
VB6.0に足りなかったのは、構造化例外だけだと思ってます。
エラー処理だけはどうにもやりにくかった。
try/catch/finallyを全て on error goto で書く手間といったら…。
インターフェィスももうちょい使いやすければ良かったのにとは思いますね。
ほぼ使われない機能だったんじゃないかな。
でもとりあえずオブジェクト指向で作るうえで最低限の能力はありました。
LongLong型無いけど通貨型でごまかせたし、Win32APIを使いやすかったしOSとの親和性も高かったですねー…。
IDEもVC6に比べたら遙かにマシだったし。
今でも、ちっちゃいアンマネージドのツール作る時は重宝してます。
Re: (スコア:0)
関数が動的につくれない(1度なら作れるけど)のと関数が第一級オブジェクトになってほしいかな。
クラスとインターフェースに不満はあるけどプロパティとイベントが便利なのでまぁそこはそういうものだと妥協するとして。
あと暗黙の型変換はなくしてほしい。
というかそういう方向の進化でよかったのに、.NETでIDEの起動も時間かかるしVBのアドバンテージが損なわれちゃったよね。
.NETでは名前空間隠してたりFormの継承情報もdesignerコードにあったり、そういうのが嫌でC#に完全に移行してしまいました。
# returnもほしい。