アカウント名:
パスワード:
>Visual Basicの最大の問題点は、
VBの問題じゃないよね… と思ったけど、今はそうなの？
＃私は永遠の素人
一見初心者にも簡単そうでいて簡単に泥沼を作り出せる言語仕様はVBの問題だろう。
簡単に泥沼を作り出せる言語なんていくらでもある
初心者に簡単に見えることの問題は、その初心者が自分の実力を正しく把握していないことに非があるだけで、それを言語仕様のせいにするのはお門違い
ＭＴ車のドライバーよりＡＴ車のドライバーのほうが事故率が高いのは統計で有意に出てるが、操縦が簡単なＡＴ車の設計思想の責任ではないだろ？
VBの問題ではないですよね。PHPの問題あｗせｄｒｆｔｇｙふじこｌｐ；
市場及び雇用が開拓されたのですね
一方ビャーネ・ストロヴストルップ氏は雇用を守るためにC++をお作りになった。
http://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html [rim.or.jp]
## mozcで変換候補に出てきたんだけど氏の名前はこれで良いのだろうか...。
Bjarne Stroustrup 本人による発音 [stroustrup.com]を再生したところ、だいたいそう聞えたからよいのではないだろうか?
一時期のWikipedia日本語版には「本人による発音は『びょーん・すっぽすっぽ』に近い」とか書いてあって吹いた記憶が。いつの間にか修正されちゃったけど（当然か）
https://ja.wikipedia.org/w/index.php?title=%E3%83%93%E3%83%A3%E3%83%BC... [wikipedia.org]
なるほど。
いやいや、素人から玄人まで分け隔てなくアプリケーション開発をできるようにしたVisualStudioなどのツールを手がけたマイクロソフトはすごいとおもう。
>>おかげで尻拭いが大変。これよく上から目線で勘違いしている人がいるけど結局そういったソースなどの管理以上にプロジェクト管理ができない人や部署、会社がいうせりふなんだ。
きつい言葉でいうと管理ができない無能なんです
VC++の面倒くさい前処理後処理イベント処理のコードを見えないようにして誰でも簡単にWindowプログラムを作れるようにしたのは本当に素晴らしいと思います。
VBぐらいのシンプルな言語・動作環境があれば業務の7割ぐらいはそれで回せるので、VB* [microsoft.com]はとても期待しています。
そうそうで、フック必要な仕様がボコボコ着いててあれ？となる。特に多かったのはEnterキーで項目移動。
なにせ基礎となるOSの仕様完全無視の、汎用機／コボラー源流のクソ仕様。そして今はブラウザアプリがその犠牲者。
作らされる立場だとそう思うんですけど、現場の熟練オペレータさんたちの作業を見ると結構見方が変わるものでやっぱり Enter キー遷移は必要なんだなあ、と。
あの人たち、画面も手元も見ないでひたすら脇の伝票をめくりながら信じがたい速度で入力していくのですよ。左手は伝票をめくるので入力は右手だけで、テンキーの数字と Enter しか押さない。Enter キー遷移なしで同じ作業を同じ効率でやってみてね、と言われたら正直ごめんなさいとしか言えません。
手書きの紙の伝票だの帳票だの申請書だの FAX だのといったやつらを絶滅させるか、画像認識・OCR の技術が飛躍的に進まない限り、Enter キー遷移はなくせないでしょう。
# というか、むしろそういった高スループットの作業にブラウザアプリは適していないので# そういう作業用にレガシーな入力端末を残すシステム設計をするほうが良いのではないかと。
管理以前に、素人を素人のままプロジェクトに参加させたことが問題だと思う素人も苦労とも同じ管理工数で管理できるのなら問題にはならないでしょうね
「ある業務」を「プログラム化する」ことを考えた場合、通常、「その業務の専門家で、プログラミングの素人」と「その業務の素人で、プログラミングの専門家」が組むことになります。従来の方法というか今でも「プログラミングの専門家が、業務の専門家に聞き取り調査を行い、仕様策定し開発する」というのが一般的な開発工程ですけど、その方法だと「業務として必要なものを過不足無くプログラム化」するのが非常に難しいんですよね。#いわゆる「顧客が本当に必要だったもの」
それよりも、「業務の専門家が、直接プログラミング」した方が、ちゃんと「顧客が本当に必要だった物」が出来ます。「できあがったプログラムがクソコードになる」かもしれませんが、それよりも「正しい要望通りのプログラムになる」方が非常に重要。#業務側が「当たり前だと思って言及していない」ことを、プログラム側が「言及されていないので実装しない」というのが非常にありがち。
そういう「プログラミングの素人な、業務の専門家が、自前でプログラムを作ることができる」という点で、VBなどのRADツールは非常に強力というかエポックメイキングなプロダクトだったんですよ。「業務の素人で、プログラミングの専門家」なハズのソフトメーカー側でだけ見るとクソコード量産機というデメリットしかない代物になっちゃうわけですが…
それよりも、「業務の専門家が、直接プログラミング」した方が、ちゃんと「顧客が本当に必要だった物」が出来ます。「できあがったプログラムがクソコードになる」かもしれませんが、それよりも「正しい要望通りのプログラムになる」方が非常に重要。
これに関してはVBよりVBAがいいんだよなぁ。どっちもVBじゃんと言えばそうだが、ソフトとしては一応別物だし。
「業務の素人で、プログラミングの専門家」なハズのソフトメーカー側でだけ見るとクソコード量産機というデメリットしかない代物になっちゃうわけですが…
実際には「ソフトメーカー側のプログラマ（肩書き）」でもクソコード量産してたのは結構居るので、結局は「エンジニアの能力を見極めることなく人月とか書いたステップ数だけで評価してたクソな管理職」の責任に帰結するんじゃないかなあと思うのです。
体感的には、問題はVBをメンテさせられる事よりもVBで作らされる事にシフトしている。くそコードのメンテは、実際に爆弾を抱えさせられた一部以外は、被害者の絶対数は少ないのではないか。VB.NETであればC#で書けばいいし、VBA/VBSなら他の解決法を採用するのが長期的には良いのだが、往々にしてそれを良しとしない人/環境がある。
VB.NETは今やハードルの低い言語では無いと思うが、今敢えて採用するメリットはどのようなものがあるだろうか。
VBがなかったとしても、たとえばポインタが分からないレベルの人がCでプログラムを組んだら尻ぬぐいが必要になりそうですよね。
どんな言語についても、それぞれの言語の難易度のレベルに応じて、わかってる人と全然できない人の間に、なんとかできるように見えるけど実はわかってなくて尻ぬぐいが必要な人、というのは必ずいるんじゃないかな。
居るか居ないかで言えばどの言語でも必ず居る。居ない確率が低いとか居てもキズが浅いとかで収まるかどうかが言語仕様の差。
つーかVBだと余程変な関数使わない限り問題はおきないけど、C（C++）でタコいのがプログラム組むとメモリリークとか、最悪ブルースクリーンを引き起こすことを考えれば、言語として問題点が大きいのはむしろそっちなんだよな
馬鹿でも使えちゃうのが問題というならそうなのかもしれないけど、それはむしろVBよりWindowsに起因する問題だ特に最近のWindowsほどそうなってるあたりが皮肉だが
VBやCがダメならPascalを使えば良い コンパイル時のスタティックな構文チェックのおかげで開発効率が抜群に向上するただし単純な数値計算以外のことをやろうとすると、Pascalの標準的なライブラリでは何も出来ないし、Pascalを拡張した言語・処理系は拡張部分であれやこれやの問題が生ずるのでいかんともしがたいということでこの問題に解は無い
おそらく、ことの本質は、Windowsプログラミング（もしくはもっと根源的にGUIプログラミング）は問題が起きやすいということなんだろうと思う。その問題が起きやすい部分をどのように隠蔽・自動化・簡略化するかが、各処理系の個性なんだと思う。そもそもが複雑なので、それをいくら隠蔽しても、複雑な内部構造に対する洞察がなければ思わぬところで落とし穴に陥ってしまう。
GUIプログラミングをサポートしない処理系なら、問題が起きにくいのは当然のこと。
ダメだろレベルでもプログラムできるのはそれは正しい。プログラムを単純労働的にするという点で。
問題は少々間違っても動いてしまうことだが、別にソース上は正確でも仕様通りできてないとかテストしてないといったプログラムはどんな言語でも出来るので、VBがなければ尻拭いが減ったとは思えん。
むしろ単純労働であれば「管理」が重要なのに、エンジニアだから管理は適当でいいよね、が現状を産んだと。
PHPっていう超大物がいるからあまり・・・あっちは使う側だけでなく作った側にも文句言いたくなる
> 異業種に転職してますが何か？ そりゃよかった。おめでとうございます。なら何でそんなにカチンと来てるのかちょっと不思議だけど。
別ACだけど一度でも低能の尻拭いしたらなぜか分かるよ。
どこの業界に行っても尻拭いの仕事はある罠
どこの業界に行っても尻拭いしか回ってこない
＃まわるまわるよカルマはまわるorz
尻拭い以外をやらせると、その尻拭いをさせられますから。
尻ぬぐいのウロボロスみたいですねｗ
まあ過去の発言見る限り、対案出さずに愚痴るの好きみたいだから。
まあ最近はSIerに「尻ぬぐいが大変なコードもある」ことを認識してる人もそれなりに出てきたので保守や移植案件で「元のコードが酷くて保守の難易度高いのでステップ数あたりの単価上げますね」って言えるようになってきたからいいかな
アレだ、老人介護の仕事みたいなモノだと思えば悪くないよ、給料に見合ってるうちは
# 移植案件のためにVB6で作られたソースを解析してるのでAC
そりゃ嫌だと思ったやつは転職すりゃいいが、結局誰かが尻拭いさせられることには変わらんだろVBの免罪にはならんよ
VBの免罪にはならんよ
そもそもVBの罪じゃねーよ、まともなプログラマ雇用したり教育できなかった会社側の問題だVB6でもきちんとメンテしやすいように作られたコードはある以上、それができないのはプログラマ側の問題であって言語側の問題じゃない
お前さんがIT業界の人間かどうか知らないけど、一度言ってみるといいよ、「自分の能力じゃなく言語が悪くて品質の低いソースコードができました」ってそれで許容されるなら「VBの免罪」とか言っちゃってもいいだろうけどね、実際にはそんなの通るわけないし
クソコードが限りなく書きやすい言語やその言語を取り巻く文化がある。その逆もある。VBは前者であることは間違いない。つまり間違いなく言語側の問題。お前は間違いなくコードの良い悪いなんてわかってねーだろうよ。
VB6とVB.NETの話に戻すと、VB6の言語仕様はクソだけど実行速度はとても良かった。例外処理とかクソすぎたけど。VB.NETというか.NETは言語仕様はまぁまぁまともで劣化C#程度にはマシだけど、VB6からのクソコーダーの流れがあるから、ロクなコード見たこと無い。ロクでもあるコードだったとしても.NETのWindowsアプリ自体がVB6に比べてクソ遅いから始末
.NETそんなにおそいかねぇ。IDEは遅いけど。
java同様フレームワークがアンチウィルスのオンアクセススキャンとかに引っかかると重いけどさ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
Visual Basicの最大の問題点 (スコア:5, すばらしい洞察)
どう考えても、こんな奴にプログラムやらせたらダメだろレベルにでも
プログラムができるようにしたこと。おかげで尻拭いが大変。
clausemitz
Re:Visual Basicの最大の問題点 (スコア:1)
>Visual Basicの最大の問題点は、
VBの問題じゃないよね… と思ったけど、今はそうなの？
＃私は永遠の素人
Re: (スコア:0)
一見初心者にも簡単そうでいて簡単に泥沼を作り出せる言語仕様はVBの問題だろう。
Re: (スコア:0)
簡単に泥沼を作り出せる言語なんていくらでもある
初心者に簡単に見えることの問題は、その初心者が自分の実力を正しく把握していないことに非があるだけで、それを言語仕様のせいにするのはお門違い
ＭＴ車のドライバーよりＡＴ車のドライバーのほうが事故率が高いのは統計で有意に出てるが、操縦が簡単なＡＴ車の設計思想の責任ではないだろ？
Re: (スコア:0)
VBの問題ではないですよね。
PHPの問題あｗせｄｒｆｔｇｙふじこｌｐ；
Re: (スコア:0)
市場及び雇用が開拓されたのですね
Re:Visual Basicの最大の問題点 (スコア:2)
一方ビャーネ・ストロヴストルップ氏は雇用を守るためにC++をお作りになった。
http://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html [rim.or.jp]
## mozcで変換候補に出てきたんだけど氏の名前はこれで良いのだろうか...。
Re:Visual Basicの最大の問題点 (スコア:1)
Bjarne Stroustrup 本人による発音 [stroustrup.com]を再生したところ、だいたいそう聞えたからよいのではないだろうか?
Re:Visual Basicの最大の問題点 (スコア:5, おもしろおかしい)
一時期のWikipedia日本語版には「本人による発音は『びょーん・すっぽすっぽ』に近い」とか書いてあって吹いた記憶が。
いつの間にか修正されちゃったけど（当然か）
Re:Visual Basicの最大の問題点 (スコア:1)
https://ja.wikipedia.org/w/index.php?title=%E3%83%93%E3%83%A3%E3%83%BC... [wikipedia.org]
なるほど。
Re:おしりからミミズが出てきたYO (スコア:0)
いやいや、素人から玄人まで分け隔てなくアプリケーション開発をできるようにした
VisualStudioなどのツールを手がけたマイクロソフトはすごいとおもう。
>>おかげで尻拭いが大変。
これよく上から目線で勘違いしている人がいるけど
結局そういったソースなどの管理以上にプロジェクト
管理ができない人や部署、会社がいうせりふなんだ。
きつい言葉でいうと管理ができない無能なんです
Re: (スコア:0)
VC++の面倒くさい前処理後処理イベント処理のコードを見えないようにして誰でも簡単にWindowプログラムを作れるようにしたのは本当に素晴らしいと思います。
VBぐらいのシンプルな言語・動作環境があれば業務の7割ぐらいはそれで回せるので、VB* [microsoft.com]はとても期待しています。
Re:おしりからミミズが出てきたYO (スコア:1)
そうそう
で、フック必要な仕様がボコボコ着いててあれ？となる。
特に多かったのはEnterキーで項目移動。
なにせ基礎となるOSの仕様完全無視の、汎用機／コボラー源流のクソ仕様。
そして今はブラウザアプリがその犠牲者。
Re:おしりからミミズが出てきたYO (スコア:4, 参考になる)
作らされる立場だとそう思うんですけど、現場の熟練オペレータさんたちの作業を見ると結構見方が変わるもので
やっぱり Enter キー遷移は必要なんだなあ、と。
あの人たち、画面も手元も見ないでひたすら脇の伝票をめくりながら信じがたい速度で入力していくのですよ。
左手は伝票をめくるので入力は右手だけで、テンキーの数字と Enter しか押さない。
Enter キー遷移なしで同じ作業を同じ効率でやってみてね、と言われたら正直ごめんなさいとしか言えません。
手書きの紙の伝票だの帳票だの申請書だの FAX だのといったやつらを絶滅させるか、
画像認識・OCR の技術が飛躍的に進まない限り、Enter キー遷移はなくせないでしょう。
# というか、むしろそういった高スループットの作業にブラウザアプリは適していないので
# そういう作業用にレガシーな入力端末を残すシステム設計をするほうが良いのではないかと。
Re: (スコア:0)
管理以前に、素人を素人のままプロジェクトに参加させたことが問題だと思う
素人も苦労とも同じ管理工数で管理できるのなら問題にはならないでしょうね
Re:おしりからミミズが出てきたYO (スコア:1)
「ある業務」を「プログラム化する」ことを考えた場合、通常、「その業務の専門家で、プログラミングの素人」と「その業務の素人で、プログラミングの専門家」が組むことになります。
従来の方法というか今でも「プログラミングの専門家が、業務の専門家に聞き取り調査を行い、仕様策定し開発する」というのが一般的な開発工程ですけど、その方法だと「業務として必要なものを過不足無くプログラム化」するのが非常に難しいんですよね。
#いわゆる「顧客が本当に必要だったもの」
それよりも、「業務の専門家が、直接プログラミング」した方が、ちゃんと「顧客が本当に必要だった物」が出来ます。
「できあがったプログラムがクソコードになる」かもしれませんが、それよりも「正しい要望通りのプログラムになる」方が非常に重要。
#業務側が「当たり前だと思って言及していない」ことを、プログラム側が「言及されていないので実装しない」というのが非常にありがち。
そういう「プログラミングの素人な、業務の専門家が、自前でプログラムを作ることができる」という点で、VBなどのRADツールは非常に強力というかエポックメイキングなプロダクトだったんですよ。
「業務の素人で、プログラミングの専門家」なハズのソフトメーカー側でだけ見るとクソコード量産機というデメリットしかない代物になっちゃうわけですが…
Re: (スコア:0)
これに関してはVBよりVBAがいいんだよなぁ。どっちもVBじゃんと言えばそうだが、ソフトとしては一応別物だし。
実際には「ソフトメーカー側のプログラマ（肩書き）」でもクソコード量産してたのは結構居るので、結局は「エンジニアの能力を見極めることなく人月とか書いたステップ数だけで評価してたクソな管理職」の責任に帰結するんじゃないかなあと思うのです。
Re: (スコア:0)
体感的には、問題はVBをメンテさせられる事よりもVBで作らされる事にシフトしている。
くそコードのメンテは、実際に爆弾を抱えさせられた一部以外は、被害者の絶対数は少ないのではないか。
VB.NETであればC#で書けばいいし、VBA/VBSなら他の解決法を採用するのが長期的には良いのだが、
往々にしてそれを良しとしない人/環境がある。
VB.NETは今やハードルの低い言語では無いと思うが、今敢えて採用するメリットはどのようなものがあるだろうか。
Re: (スコア:0)
VBがなかったとしても、たとえばポインタが分からないレベルの人がCでプログラムを組んだら尻ぬぐいが必要になりそうですよね。
どんな言語についても、それぞれの言語の難易度のレベルに応じて、わかってる人と全然できない人の間に、なんとかできるように見えるけど実はわかってなくて尻ぬぐいが必要な人、というのは必ずいるんじゃないかな。
Re:Visual Basicの最大の問題点 (スコア:2)
居るか居ないかで言えばどの言語でも必ず居る。
居ない確率が低いとか居てもキズが浅いとかで収まるかどうかが言語仕様の差。
Re: (スコア:0)
つーかVBだと余程変な関数使わない限り問題はおきないけど、C（C++）でタコいのがプログラム組むとメモリリークとか、最悪ブルースクリーンを引き起こすことを考えれば、言語として問題点が大きいのはむしろそっちなんだよな
馬鹿でも使えちゃうのが問題というならそうなのかもしれないけど、それはむしろVBよりWindowsに起因する問題だ
特に最近のWindowsほどそうなってるあたりが皮肉だが
Re: (スコア:0)
VBやCがダメならPascalを使えば良い
コンパイル時のスタティックな構文チェックのおかげで開発効率が抜群に向上する
ただし単純な数値計算以外のことをやろうとすると、Pascalの標準的なライブラリでは何も出来ないし、Pascalを拡張した言語・処理系は拡張部分であれやこれやの問題が生ずるのでいかんともしがたい
ということでこの問題に解は無い
Re:Visual Basicの最大の問題点 (スコア:1)
おそらく、ことの本質は、Windowsプログラミング（もしくはもっと根源的にGUIプログラミング）は問題が起きやすいということなんだろうと思う。
その問題が起きやすい部分をどのように隠蔽・自動化・簡略化するかが、各処理系の個性なんだと思う。
そもそもが複雑なので、それをいくら隠蔽しても、複雑な内部構造に対する洞察がなければ思わぬところで落とし穴に陥ってしまう。
GUIプログラミングをサポートしない処理系なら、問題が起きにくいのは当然のこと。
Re: (スコア:0)
ダメだろレベルでもプログラムできるのはそれは正しい。プログラムを単純労働的にするという点で。
問題は少々間違っても動いてしまうことだが、
別にソース上は正確でも仕様通りできてないとかテストしてないといったプログラムはどんな言語でも出来るので、
VBがなければ尻拭いが減ったとは思えん。
むしろ単純労働であれば「管理」が重要なのに、エンジニアだから管理は適当でいいよね、が現状を産んだと。
Re: (スコア:0)
PHPっていう超大物がいるからあまり・・・
あっちは使う側だけでなく作った側にも文句言いたくなる
Re:Visual Basicの最大の問題点 (スコア:1)
まぁ、スラドでAnonymous Cowardで発言する人がどういう意図で書いてるかわからんけど
ひょっとして、ご自身のことを書いてるのかな？
だったら、ご自身が辞めればよろしいよ。私みたいに。
clausemitz
Re: (スコア:0)
> 異業種に転職してますが何か？
そりゃよかった。おめでとうございます。
なら何でそんなにカチンと来てるのかちょっと不思議だけど。
Re: (スコア:0)
別ACだけど一度でも低能の尻拭いしたらなぜか分かるよ。
Re: (スコア:0)
どこの業界に行っても尻拭いの仕事はある罠
Re:Visual Basicの最大の問題点 (スコア:3, おもしろおかしい)
どこの業界に行っても尻拭いしか回ってこない
＃まわるまわるよカルマはまわるorz
Re: (スコア:0)
尻拭い以外をやらせると、その尻拭いをさせられますから。
Re:Visual Basicの最大の問題点 (スコア:2)
尻ぬぐいのウロボロスみたいですねｗ
Re: (スコア:0)
まあ過去の発言見る限り、対案出さずに愚痴るの好きみたいだから。
Re:Visual Basicの最大の問題点 (スコア:1)
まあ最近はSIerに「尻ぬぐいが大変なコードもある」ことを認識してる人もそれなりに出てきたので
保守や移植案件で「元のコードが酷くて保守の難易度高いのでステップ数あたりの単価上げますね」って言えるようになってきたからいいかな
アレだ、老人介護の仕事みたいなモノだと思えば悪くないよ、給料に見合ってるうちは
# 移植案件のためにVB6で作られたソースを解析してるのでAC
Re: (スコア:0)
そりゃ嫌だと思ったやつは転職すりゃいいが、結局
誰かが尻拭いさせられることには変わらんだろ
VBの免罪にはならんよ
Re: (スコア:0)
そもそもVBの罪じゃねーよ、まともなプログラマ雇用したり教育できなかった会社側の問題だ
VB6でもきちんとメンテしやすいように作られたコードはある以上、それができないのはプログラマ側の問題であって言語側の問題じゃない
お前さんがIT業界の人間かどうか知らないけど、一度言ってみるといいよ、「自分の能力じゃなく言語が悪くて品質の低いソースコードができました」って
それで許容されるなら「VBの免罪」とか言っちゃってもいいだろうけどね、実際にはそんなの通るわけないし
Re: (スコア:0)
クソコードが限りなく書きやすい言語やその言語を取り巻く文化がある。その逆もある。
VBは前者であることは間違いない。
つまり間違いなく言語側の問題。
お前は間違いなくコードの良い悪いなんてわかってねーだろうよ。
VB6とVB.NETの話に戻すと、VB6の言語仕様はクソだけど実行速度はとても良かった。例外処理とかクソすぎたけど。
VB.NETというか.NETは言語仕様はまぁまぁまともで劣化C#程度にはマシだけど、VB6からのクソコーダーの流れがあるから、ロクなコード見たこと無い。ロクでもあるコードだったとしても.NETのWindowsアプリ自体がVB6に比べてクソ遅いから始末
Re: (スコア:0)
.NETそんなにおそいかねぇ。IDEは遅いけど。
java同様フレームワークがアンチウィルスのオンアクセススキャンとかに引っかかると重いけどさ。