2006/07/21
VBA機能無さ杉
時代に逆行して、ここ1週間以上ボランティアのためにExcel VBAを触っている。
その前の週はRubyとか触ってみているのに、ここで6年以上も前の言語に触れるのは苦痛すぎる。
どの変が苦痛かというと
機能的な不足のいくつかは、上位製品(VB6とか)だったら解決できる問題であったりするので、変な商売っ気が透けて見えて、さらにやる気ダウン。
6年っていう月日は、やはり言語を進化させるのに十分な時間みたい。と思ったのと、言語とアプリケーションが別だったら問題もある程度緩和されるのにとも思った。
せっかくExcel本体をコンポートネント化して他所から呼び出しやすいように作っているのに、今のアプリケーションと言語を一体化させている形だと、言語だけバージョンアップさせたりとかができない。サポートの問題とか動作保証の問題とかいろいろあると思うけれど、Rubyはどんどん進化しているのに、Excel 2000についているVBAは次のバージョンを買うまで昔のままというのは、最近の流れからすると合っていない気が個人的にはする。
その前の週はRubyとか触ってみているのに、ここで6年以上も前の言語に触れるのは苦痛すぎる。
どの変が苦痛かというと
- オブジェクト指向言語と自称しつつ、継承ができなかったり
- VB6だったらある機能(コントロール配列?とか)が同じVBという名前なのに削られていたり
- 関数とサブルーチンで定義が分かれいたり(引数を返す関数かそうでないかで関数の定義が違う)
- GCがランタイムに含まれているような感じはあるけれど、ActiveXの部品を呼び出すと自分でリリースしないといけなかったり
機能的な不足のいくつかは、上位製品(VB6とか)だったら解決できる問題であったりするので、変な商売っ気が透けて見えて、さらにやる気ダウン。
6年っていう月日は、やはり言語を進化させるのに十分な時間みたい。と思ったのと、言語とアプリケーションが別だったら問題もある程度緩和されるのにとも思った。
せっかくExcel本体をコンポートネント化して他所から呼び出しやすいように作っているのに、今のアプリケーションと言語を一体化させている形だと、言語だけバージョンアップさせたりとかができない。サポートの問題とか動作保証の問題とかいろいろあると思うけれど、Rubyはどんどん進化しているのに、Excel 2000についているVBAは次のバージョンを買うまで昔のままというのは、最近の流れからすると合っていない気が個人的にはする。