仕事で、VB.NETに触れることになりました。
やってみると、C#での当たり前が通じず、なかなか苦労します。
触れてみて思うのは Visual Basicはどうなっていくのだろうと思い、「VB.NET future」などとGoogle検索をしてみたりもしてしました。
C#とVB.NETという.NETファミリーは？
F#は関数型言語という独自の立ち位置がありますが、C#とVB.NETについては似て非なるもので、立ち位置が曖昧です。
二つの言語を保守し続けることはマイクロソフトにとってどうなのかと思ったりします。
2009年の記事ですが、VB.NETとC#は特徴の異なる言語だ。だが、ユーザーは互いの言語の機能を必要とする、と
特徴の異なる言語というのは確かです。私は一つの言語仕様とC#ライクにVBライクに表現できるように互いの言語が実装されていると最近まで勝手に思ってました。
完全にまでとは言わないもののVB.NETをC#に変換するようなツールもあれば、サイトによってはVB.NETで書いた時とC#で書いた時の両方が掲載されています。
ですが、特徴の異なる言語なので、C#の感覚でVB.NETを書いたところで、細かい点ではそうも行かないのです。
The .NET Language Strategy | .NET Blog
上記のサイトはMSDNでのC#とVB.NETとF#の言語のスタンスが語られています。ただ、スローガンのような精神性を語っており、ここからは言語の特徴を見出すのは難しいです。
上記のサイトではIndeedなどの求人サイトでの言語ごとの案件数の比較をしています。VB.NETはC#の1/5程度といったところでしょうか。
C#erからすれば、C#に一本化したらいいんじゃないの？ なんて極論も思い浮かんで来ます。
なくならない
社内システムの保守・不具合対応をしていた頃は、職場の制約があり自由にソフトウェアはダウンロードは出来ませんでした。
Visual Studioなど持ってのほかで、何かしらのツールを作ろうならば、Notesで作るか、Excel VBAを駆使して作るかです。
Excel VBAで差分表示ツールを作成している方がおり、これにはびっくりしました。
Excel VBAはVisual Basicです。そういったシーンのVisual Basicもなくてはならないものです。
そう、「なくならない」と言うこと。
マイクロソフトのイベントにて質問に答える井上章さんが
VB6動きますよね？
と言っていたのを思い出します。
システムというのは人が考える以上に使い続ける。それだけに、そのメンテナンスを行う人が必要になる。
COBOLのような言語もそうだと思います。
古い仕組みを使い続けないで、新しく作り変えろよということなのですが、これもなかなか難しいです。
よって、システム開発については「技術的負債」は常につきまとう問題であり、いかに解消するかも常に考えなければならないテーマなのだと思います。
噂の域を出ませんが、とある会社は、安く受注して、延々と保守費で稼ぐという笑えない商売をしているも聞いたことがあります。
いざ作り変えるにも仕様書は存在しないか古すぎて使い物にならず、ソースが仕様状態。
古いソースを見ながら、進めるしかありません。
そういうバッドケースにならないようにするには、古くなってしまう前に一部でも良い状態に持っていく継続的な解消が必要なのかなと思います。
