パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Visual Basicが25周年を迎える」記事へのコメント

  • Visual Basicの最大の問題点は、
    どう考えても、こんな奴にプログラムやらせたらダメだろレベルにでも
    プログラムができるようにしたこと。おかげで尻拭いが大変。
    --
    clausemitz
    • >Visual Basicの最大の問題点は、

      VBの問題じゃないよね… と思ったけど、今はそうなの?

      #私は永遠の素人

      親コメント
      • by Anonymous Coward

        一見初心者にも簡単そうでいて簡単に泥沼を作り出せる言語仕様はVBの問題だろう。

        • by Anonymous Coward

          簡単に泥沼を作り出せる言語なんていくらでもある

          初心者に簡単に見えることの問題は、その初心者が自分の実力を正しく把握していないことに非があるだけで、それを言語仕様のせいにするのはお門違い

          MT車のドライバーよりAT車のドライバーのほうが事故率が高いのは統計で有意に出てるが、操縦が簡単なAT車の設計思想の責任ではないだろ?

      • by Anonymous Coward

        VBの問題ではないですよね。
        PHPの問題あwせdrftgyふじこlp;

    • by Anonymous Coward

      市場及び雇用が開拓されたのですね

    • いやいや、素人から玄人まで分け隔てなくアプリケーション開発をできるようにした
      VisualStudioなどのツールを手がけたマイクロソフトはすごいとおもう。

      >>おかげで尻拭いが大変。
      これよく上から目線で勘違いしている人がいるけど
      結局そういったソースなどの管理以上にプロジェクト
      管理ができない人や部署、会社がいうせりふなんだ。

      きつい言葉でいうと管理ができない無能なんです

      • by Anonymous Coward

        VC++の面倒くさい前処理後処理イベント処理のコードを見えないようにして誰でも簡単にWindowプログラムを作れるようにしたのは本当に素晴らしいと思います。

        VBぐらいのシンプルな言語・動作環境があれば業務の7割ぐらいはそれで回せるので、VB* [microsoft.com]はとても期待しています。

        • by Anonymous Coward on 2016年05月22日 14時46分 (#3016928)

          そうそう
          で、フック必要な仕様がボコボコ着いててあれ?となる。
          特に多かったのはEnterキーで項目移動。

          なにせ基礎となるOSの仕様完全無視の、汎用機/コボラー源流のクソ仕様。
          そして今はブラウザアプリがその犠牲者。

          親コメント
          • by Anonymous Coward on 2016年05月22日 15時30分 (#3016940)

            作らされる立場だとそう思うんですけど、現場の熟練オペレータさんたちの作業を見ると結構見方が変わるもので
            やっぱり Enter キー遷移は必要なんだなあ、と。

            あの人たち、画面も手元も見ないでひたすら脇の伝票をめくりながら信じがたい速度で入力していくのですよ。
            左手は伝票をめくるので入力は右手だけで、テンキーの数字と Enter しか押さない。
            Enter キー遷移なしで同じ作業を同じ効率でやってみてね、と言われたら正直ごめんなさいとしか言えません。

            手書きの紙の伝票だの帳票だの申請書だの FAX だのといったやつらを絶滅させるか、
            画像認識・OCR の技術が飛躍的に進まない限り、Enter キー遷移はなくせないでしょう。

            # というか、むしろそういった高スループットの作業にブラウザアプリは適していないので
            # そういう作業用にレガシーな入力端末を残すシステム設計をするほうが良いのではないかと。

            親コメント
      • by Anonymous Coward

        管理以前に、素人を素人のままプロジェクトに参加させたことが問題だと思う
        素人も苦労とも同じ管理工数で管理できるのなら問題にはならないでしょうね

        • 「ある業務」を「プログラム化する」ことを考えた場合、通常、「その業務の専門家で、プログラミングの素人」と「その業務の素人で、プログラミングの専門家」が組むことになります。
          従来の方法というか今でも「プログラミングの専門家が、業務の専門家に聞き取り調査を行い、仕様策定し開発する」というのが一般的な開発工程ですけど、その方法だと「業務として必要なものを過不足無くプログラム化」するのが非常に難しいんですよね。
          #いわゆる「顧客が本当に必要だったもの」

          それよりも、「業務の専門家が、直接プログラミング」した方が、ちゃんと「顧客が本当に必要だった物」が出来ます。
          「できあがったプログラムがクソコードになる」かもしれませんが、それよりも「正しい要望通りのプログラムになる」方が非常に重要。
          #業務側が「当たり前だと思って言及していない」ことを、プログラム側が「言及されていないので実装しない」というのが非常にありがち。

          そういう「プログラミングの素人な、業務の専門家が、自前でプログラムを作ることができる」という点で、VBなどのRADツールは非常に強力というかエポックメイキングなプロダクトだったんですよ。
          「業務の素人で、プログラミングの専門家」なハズのソフトメーカー側でだけ見るとクソコード量産機というデメリットしかない代物になっちゃうわけですが…

          親コメント
          • by Anonymous Coward

            それよりも、「業務の専門家が、直接プログラミング」した方が、ちゃんと「顧客が本当に必要だった物」が出来ます。
            「できあがったプログラムがクソコードになる」かもしれませんが、それよりも「正しい要望通りのプログラムになる」方が非常に重要。

            これに関してはVBよりVBAがいいんだよなぁ。どっちもVBじゃんと言えばそうだが、ソフトとしては一応別物だし。

            「業務の素人で、プログラミングの専門家」なハズのソフトメーカー側でだけ見るとクソコード量産機というデメリットしかない代物になっちゃうわけですが…

            実際には「ソフトメーカー側のプログラマ(肩書き)」でもクソコード量産してたのは結構居るので、結局は「エンジニアの能力を見極めることなく人月とか書いたステップ数だけで評価してたクソな管理職」の責任に帰結するんじゃないかなあと思うのです。

    • by Anonymous Coward

      体感的には、問題はVBをメンテさせられる事よりもVBで作らされる事にシフトしている。
      くそコードのメンテは、実際に爆弾を抱えさせられた一部以外は、被害者の絶対数は少ないのではないか。
      VB.NETであればC#で書けばいいし、VBA/VBSなら他の解決法を採用するのが長期的には良いのだが、
      往々にしてそれを良しとしない人/環境がある。

      VB.NETは今やハードルの低い言語では無いと思うが、今敢えて採用するメリットはどのようなものがあるだろうか。

    • by Anonymous Coward

      VBがなかったとしても、たとえばポインタが分からないレベルの人がCでプログラムを組んだら尻ぬぐいが必要になりそうですよね。

      どんな言語についても、それぞれの言語の難易度のレベルに応じて、わかってる人と全然できない人の間に、なんとかできるように見えるけど実はわかってなくて尻ぬぐいが必要な人、というのは必ずいるんじゃないかな。

      • 居るか居ないかで言えばどの言語でも必ず居る。
        居ない確率が低いとか居てもキズが浅いとかで収まるかどうかが言語仕様の差。

        親コメント
      • by Anonymous Coward

        つーかVBだと余程変な関数使わない限り問題はおきないけど、C(C++)でタコいのがプログラム組むとメモリリークとか、最悪ブルースクリーンを引き起こすことを考えれば、言語として問題点が大きいのはむしろそっちなんだよな

        馬鹿でも使えちゃうのが問題というならそうなのかもしれないけど、それはむしろVBよりWindowsに起因する問題だ
        特に最近のWindowsほどそうなってるあたりが皮肉だが

        • by Anonymous Coward

          VBやCがダメならPascalを使えば良い 
          コンパイル時のスタティックな構文チェックのおかげで開発効率が抜群に向上する
          ただし単純な数値計算以外のことをやろうとすると、Pascalの標準的なライブラリでは何も出来ないし、Pascalを拡張した言語・処理系は拡張部分であれやこれやの問題が生ずるのでいかんともしがたい
          ということでこの問題に解は無い

          • by Anonymous Coward on 2016年05月22日 16時29分 (#3016962)

            おそらく、ことの本質は、Windowsプログラミング(もしくはもっと根源的にGUIプログラミング)は問題が起きやすいということなんだろうと思う。
            その問題が起きやすい部分をどのように隠蔽・自動化・簡略化するかが、各処理系の個性なんだと思う。
            そもそもが複雑なので、それをいくら隠蔽しても、複雑な内部構造に対する洞察がなければ思わぬところで落とし穴に陥ってしまう。

            GUIプログラミングをサポートしない処理系なら、問題が起きにくいのは当然のこと。

            親コメント
    • by Anonymous Coward

      ダメだろレベルでもプログラムできるのはそれは正しい。プログラムを単純労働的にするという点で。

      問題は少々間違っても動いてしまうことだが、
      別にソース上は正確でも仕様通りできてないとかテストしてないといったプログラムはどんな言語でも出来るので、
      VBがなければ尻拭いが減ったとは思えん。

      むしろ単純労働であれば「管理」が重要なのに、エンジニアだから管理は適当でいいよね、が現状を産んだと。

    • by Anonymous Coward

      PHPっていう超大物がいるからあまり・・・
      あっちは使う側だけでなく作った側にも文句言いたくなる

「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常

処理中...