アカウント名:
パスワード:
言語的にもランタイム的にも。一緒にしたらダメだと思うのだが。
確かに、.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?)に組み込まれているので簡単に移植できるだろ、と思っているユーザーに.NETへの改修費を正直に見積もりしたら「高すぎる!」と切れられました。
VB 6.0のまま安い改修を続けていて、そろそろ開発者が作りなおしたほうが良いといっていたのに、そんな感じです。そしてメインの担当者が去って、誰も面倒を見たくなくなる、という……。
個人的にはVB 6.0はすごくとっつきやすく好きだったのですが、今はもう正直触りたくないです。大抵のお仕事は地雷案件です。
>大抵のお仕事は地雷案件です。言語自体が地雷なのではないかと。できることが増えて言語自体がお手軽言語から厳密な言語になったにもかかわらず、コンパイラーの警告が弱いので動かしてみてミスに気づいて修正に時間がかかるなんてこともざらだし。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もほしい。
VBでWinAPI使えなかった・VCでしか使えなかったのをVBでも使えるようにしたのが.NETという認識。別物というほど別物?「本来こうあるべきだよねー」な感じはするけど。
あれ?VBAでWindowsAPIは叩けましたよね。そういうことではなく?
VarPtr とか StrPtr という隠し関数ありますよね。Win32API叩く以外に用途が無いやつ。VarPtr は使わざるを得ないケースがあったような覚えがある。
Win32API叩きやすくて、作りもWindowsネイティブだし、けっこう素直な言語という印象がある>VB6
VB2.0の頃から制限付きで使えてましたよ
VB.NETはVBランタイムじゃなくて.NET Framworkで動くBasicC#と同じランタイム、同じライブラリを使うようになって、言語を横断してコンポーネントを使いまわせる.NETに対応させるにあたって、ライブラリだけでなく構文等も(当時の)モダンになった。(だから、断裂が起きた)言語機能では.NETをフル活用するC#に対して遅れ気味だったが、現在ではほぼ同レベルになってる。
これがVBによって作られた糞プログラマか。どう動いているのかも興味持てなかったってどういうことよ。
自分以外は糞、っていう人生って辛くないですか?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家
VBとVB.NETは別物 (スコア:0)
言語的にもランタイム的にも。
一緒にしたらダメだと思うのだが。
Re:VBとVB.NETは別物 (スコア: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?)に組み込まれているので簡単に移植できるだろ、と思っているユーザーに
.NETへの改修費を正直に見積もりしたら「高すぎる!」と切れられました。
VB 6.0のまま安い改修を続けていて、そろそろ開発者が作りなおしたほうが良いといっていたのに、そんな感じです。
そしてメインの担当者が去って、誰も面倒を見たくなくなる、という……。
個人的にはVB 6.0はすごくとっつきやすく好きだったのですが、今はもう正直触りたくないです。
大抵のお仕事は地雷案件です。
Re: (スコア: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もほしい。
Re: (スコア:0)
VBでWinAPI使えなかった・VCでしか使えなかったのを
VBでも使えるようにしたのが.NETという認識。
別物というほど別物?「本来こうあるべきだよねー」な感じはするけど。
Re:VBとVB.NETは別物 (スコア:1)
あれ?VBAでWindowsAPIは叩けましたよね。
そういうことではなく?
Re: (スコア:0)
VarPtr とか StrPtr という隠し関数ありますよね。Win32API叩く以外に用途が無いやつ。
VarPtr は使わざるを得ないケースがあったような覚えがある。
Win32API叩きやすくて、作りもWindowsネイティブだし、けっこう素直な言語という印象がある>VB6
Re: (スコア:0)
VB2.0の頃から制限付きで使えてましたよ
Re: (スコア:0)
VB.NETはVBランタイムじゃなくて.NET Framworkで動くBasic
C#と同じランタイム、同じライブラリを使うようになって、言語を横断してコンポーネントを使いまわせる
.NETに対応させるにあたって、ライブラリだけでなく構文等も(当時の)モダンになった。(だから、断裂が起きた)
言語機能では.NETをフル活用するC#に対して遅れ気味だったが、現在ではほぼ同レベルになってる。
Re: (スコア:0)
これがVBによって作られた糞プログラマか。
どう動いているのかも興味持てなかったってどういうことよ。
Re: (スコア:0)
自分以外は糞、っていう人生って辛くないですか?