Ognacの雑感

木漏れ日々

目次

Blog 利用状況

書庫

ギャラリ

じゃんぬさんの【VB6 から VB.NET へ移行できない人たち 1 】のTrackBack

(トラックバックが張れてない?)

 http://blogs.wankuma.com/jeanne/archive/2006/08/02/34597.aspx

みなさんの議論は大いに賛成するんですが, 槍玉に上がっているVBプログラマーを,
われわれ職人的人種と同列に扱って,非難するだけ,いいのだろうかと,最近考えます。

エレガントな形を追いかけて行く習性を持っていると,必然的にObject/クラスの実装方法が身に着くと思います。
 しかし,世のプログラマの何割かは, 追求することを放棄しています。

プログラマ人種は二種類あると思う。
  1.自己研鑽型(職人型/追求型). : 仕事以上に,自分の知識の増加に喜びを感じる。
  2.仕事のみのプログラマ       : 仕事だから仕方なしにやっている。(知識の習得は苦痛と感じるようだ)

みなさんや,ognacは当然 1の範疇でしょう。(2の範疇の人はこのBlogは見ないでしょう。)

 情報業界の人々からみると, 2の存在は,どうにかしたい,鬱陶しい対象であるのです。

しかし,企業の電算室勤務のSE/Programerさんからみると,そうではないようなのです。
(もちろん,当てはまらない,まともな電算室のほうがおおいのですが)

彼らに果たされた命題は,所属会社の業務の実現で,業務仕様が満たされることが,第一義で,実装技術は二の次なのです。
管理者もそのように教育/指導してます。所詮数年で配置換えだという腰掛気分もあって,自己研鑽の意識は失われます。
企業の電算室の役割としては,それで丸く収まっているので,不満は出ない訳です。

 困ることは, その人たちが,我々の業界に入ってきた時に困るわけです。ognacは積極的には関わらないようにしています。

(ognacの知る少ない例ですが)企業の電算室の実体は,とてつもなく,旧態依然としている箇所があります。
COBOL言語はまだ大手を振って存在し, COBOL的発想のシステム作りが脈々と続いています。
 (代表的な例としては)  COBOL言語は,広域変数しかないので, ローカル変数の概念がわからない。
     サブルーチンは Perform( 旧Basicの gosub的なもの ) しかなく,関数化という発想も乏しい。
     決定的なのは,自社のノウハウが, 標準テンプレートという形でとして,蓄積されていて,それをコピペで持って来て,仕上げる訳です。
   白紙の状態で1から作れないプログラマが少なからず存在します。

 OPen系/PC系の人々からは想像がつかないでしょうが,  汎用機のプログラマのうち,何割かは.OSを知らないのです。知らなくても業務遂行ができるのです。

   SQL文もSUM関数を使わずに,対象データ全件,1件ずつ読み込み,足し込んで集計したりしてます。
   これは,RDB以前は, ISAM/SAM しかなかった時のCobolのソースがテンプレートして存在し,
   RDBのアクセスも, キーを与えて,該当行を取得というサンプルをつくるから,そうなる訳です。

 上記と重複しますが, こんなんでも,会社の業務システムは満足?に動いているのです。

 無垢な新人がそこに配属されたらどうなります? 不幸の一言です。
 本人の意識が,【仕事だけのプログラム】な人がいるのも事実です。

 この業界は,好きでないと勤まりません。しかし,好きでも,最初の配属が,不幸な環境だったら,間違った習性が身に着いてしまいます。
一度は正しい道を示してあげないと,いけないのかな? と思うのですが,冷たくアシラッテしまいます。(反省)

 結論のない文でした。

 

 

投稿日時 : 2006年8月3日 0:53

Feedback

# re: じゃんぬさんの【VB6 から VB.NET へ移行できない人たち 1 】のTrackBack 2006/08/03 9:31 じゃんぬ

> われわれ職人的人種と同列に扱って,非難するだけ,いいのだろうかと,最近考えます。

そりゃ、仕事でなければ別にどうこう言う筋合いはないと思います。
私は仕事でしか関わり合いがないため、技術者 (職人) としての視点で書いています。

また、

> 2.仕事のみのプログラマ:仕事だから仕方なしにやっている。(知識の習得は苦痛と感じるようだ)

も、別に非難するつもりで書いたわけではありません。
というより、私も 2 寄りな人間です。(本とか読むの嫌いですし)

"理想を押し付けている" わけではなく、
"最低限のレベルを守りましょうよ" という意味なのです。
前者と後者では大きく意味が異なります。
(後者は守らないと他者に迷惑がかかります)

VB プログラマが何故槍玉にあがっているか?
それは「ビジネス」という視点で考えるとわかると思います。

C しかできない方、Java しかできない方と、VB しかできない方、いろんな方と関わってきました。
言語問わず「実際、それすらできているのか?」と疑うレベルも多いのは事実です。
これは VB に限った話ではないです。

これらの言語での火消しを私はいろんなプロジェクトで幾度となく体験しています。
(この年で何を言っているんだ、と思われる可能性が高いですが)

C も Java も VB も、構造化言語以上なので、書いた人のセンスくらいわかります。
なぜならば、別の言語でも同じように書ける / 書いてしまうからです。

何度もこれらの言語の火消しをして実感しました。
反則がしやすい (つまり、レベルの低いソースを書きやすい) と感じるのは、間違いなく VB です。

VB は、C や Java に比べ、動作させることができる閾値がかなり低いのだと思います。
(たとえば、Form の暗黙のインスタンス化はそのひとつです。
だから、標準モジュールからセンスゼロの Form をどうこうするソースを迷いなく書く人が多く存在する。
この機能自体が悪いというのは尚早で、使う側が理解していないのが悪いと感じる)

ちなみに、VB.NET での火消しは、C#、Java での火消しに相当します。

# re: じゃんぬさんの【VB6 から VB.NET へ移行できない人たち 1 】のTrackBack 2006/08/03 12:04 ognac

じゃんぬさんのところに書きます。

# re: じゃんぬさんの【VB6 から VB.NET へ移行できない人たち 1 】のTrackBack 2006/09/15 19:49 よっしー

VB6からVB.NETへの移行について彷徨っていたらここに辿り着きましたので、記念カキコさせていただきます

まぁ自分は淘汰されていく方なので別にいいのですが
COBOLについて自分の考えをちょっと・・・

ご存知のようにCOBOLは、はっきりいって古いです
でも環境を選びません
汎用機、UNIX、LINUX、PC...
どこでもソースレベルで互換があります
汎用機で使用したソースをそのままPCでコンパイルしても動きます(当然物によりますが)
OSを意識する必要がないというのも利点になると思います

移植性は抜群だから、過去の資産がそのまま再利用できます
つまり開発期間が短縮でき、成果物のレベルは人によって左右されることが少ないです
1からコーディングされると品質に差が出すぎてメンテの工数がかかりすぎます

名前の示す通り数値の処理に強いです
数千万件の数値データを処理するのに適しています

SQLですがプリコンパイラを使用すれば使えないSQLスクリプトはありません
当然SUMだって使えます
## INSERT,UPDATE,DELETE なんて当たり前ですよね

因みに最新のCOBOLでしたらクラスも使えます
当然オブジェクト、メソッドもあります
変数はローカル変数・・・

クラス化は自分では拡張のやり過ぎだろと思いますが・・・

自分は上記の理由でCOBOLが無くなることはないと思っています(増えることも無いです!!!)
ただ、扱える人が減ってきているので、大規模開発の時にCOBOL技術者を集めるのに苦慮しています
クライアント側はVBでもDelphiでもいいので技術者は簡単に集められますが、COBOLは年寄りしかいません(w

まぁCOBOLの需要が減ったから供給がないのは当たり前と言ったら当たり前ですがね

ちと、思ったことを長々と書きまして失礼しました

# re: じゃんぬさんの【VB6 から VB.NET へ移行できない人たち 1 】のTrackBack 2006/09/16 0:04 ognac

よっしー さん、コメントありがとうございます。
  最近のCobolの状況を知り、古い知識だけで、記載したことを先ずお詫びします。

>SQLですがプリコンパイラを使用すれば使えないSQLスクリプトはありません
>当然SUMだって使えます

SQL文を外部プログラムCallの形で記述するのかな?

>因みに最新のCOBOLでしたらクラスも使えます
>当然オブジェクト、メソッドもあります
>変数はローカル変数・・・

ognacが Cobolをコーディングしていた時代(80年代前半)からは, これはちょっと想像しにくいです.
(関数がなくPerform文( gosubみたいな文)でコーディングした経験がないので....Class化がどのような形でコーディングされるのかはわかりません)

言語としてのCobol進歩は喜ばしい限りです. ただ,現役のコボラーは付いて行っているのでしょうか。元同僚だったコボラーを見る限りでは疑問に思えてなりません。
いずれにしても,Classが可能になったことは素晴らしいことなので, object志向まで至らずとも,クラス化志向で製造できるコボラーの増加に期待します。

# re: じゃんぬさんの【VB6 から VB.NET へ移行できない人たち 1 】のTrackBack 2006/09/19 12:48 よっしー

レスを頂きありがとうございます

僕も10年ぶりくらいにCOBOLを使用するプロジェクトに配属されたので浦島太郎状態でした(w

コーディングは簡単に書くと

■カーソルの定義

MOVE 'AAAA' TO CUST_ID OF WK-TBL.
EXEC SQL
DECLARE CUR01 CURSOR FOR
SELECT * FROM TBL1
WHERE CUST_ID >= :WK-TBL.CUST_ID
ORDER BY CUST_ID
FOR UPDATE
END-EXEC.

■カーソルのオープン
EXEC SQL
OPEN CUR01
END-EXEC.
IF SQLCODE NOT = ZERO
DISPLAY 'カーソルオープンエラー'
END-IF.

■カーソルの読み込み
EXEC SQL
FETCH CUR01 INTO :WK-TBL1
END-EXEC.

■追加
EXEC SQL
INSERT INTO TBL1 VALUES(:WK-TBL.CUST_ID,・・・)
END-EXEC.

■更新
EXEC SQL
UPDATE TBL1
SET CUST_ID = :WK-TBL.CUST_ID,
・・・
WHERE CURRENT OF CUR01
END-EXEC.

■削除
EXEC SQL
DELETE TBL1 WHERE CURRENT OF CUR01
END-EXEC.

■カーソルのクローズ
EXEC SQL
CLOSE CUR01
END-EXEC.

■コミット
EXEC SQL
COMMIT
END-EXEC.

SQLCODEでDBからエラーコードを取得できます

こんな感じです。
EXEC SQL から END-EXECの間をプリコンパイラが事前にコンパイルを行い、COBOLコンパイラが認識できる形式に変更します。

もちろんカーソルを使用せずに単発のSELECTやUPDATEも勿論OKです。

オブジェクト指向に関しては現場では使う人はいません(w
年寄りばっかりですから・・・(w
webプログラムもCOBOLで作れますが、所詮はできるよという認識ぐらいで、JAVAでやる方が正論ですわな

COBOLのランタイムも高いし(w

コボラーは絶滅危惧種であることは間違いないです

# re: じゃんぬさんの【VB6 から VB.NET へ移行できない人たち 1 】のTrackBack 2006/09/20 0:44 ognac

cobolも SQL対応は必然だったんですね.
文型からの類推ですが,外部Sub.exeのCallの形ですね.
それをWorking Sectionに結果を戻しているみたい.
これからの姿は......言及できかねます..

# re: じゃんぬさんの【VB6 から VB.NET へ移行できない人たち 1 】のTrackBack 2006/12/08 13:32 じゃんぬねっと

私も Windows プログラマになる前は、COBOLer していた時期がありましたよ。
けっして、COBOL は馬鹿にするために引き合いに出したわけではないと思います。

よその畑で違うタネをまくなという意味で、「COBOL みたいだ」という表現になっているのだと思います。

# re: じゃんぬさんの【VB6 から VB.NET へ移行できない人たち 1 】のTrackBack 2006/12/08 23:08 Oganc

じゃんぬねっと さん。ありがとうございます。
違う文化を非難するのは悪弊であると自覚しているものの、文脈からそのように誤解される事もありますね。戒めにします。

# The coût durante diamants reste plus indécis, mais il est important de aussi rajouter le tarif des ressources. 2017/06/27 2:37 The coût durante diamants reste plus indé

The coût durante diamants reste plus indécis, mais il est important
de aussi rajouter le tarif des ressources.

# Sobre milliers by way of joueurs ont déjà téléchargé le inhabituel outil em virtude de hack et prennent afin de l'avance relacionada tout le présent monde. 2017/08/07 6:39 Sobre milliers by way of joueurs ont déjà

Sobre milliers by way of joueurs ont déjà téléchargé le inhabituel outil em virtude de hack et prennent afin de l'avance relacionada tout le présent monde.

# En pour conclure, les diamants sont nos ressources do not vous necesitez pour dépasser la conflit. 2017/08/22 15:00 En pour conclure, les diamants sont nos ressources

En pour conclure, les diamants sont nos ressources do not vous necesitez pour dépasser la conflit.

タイトル  
名前  
Url
コメント