プログラミング教育

昨日まで3日間、Androidの自動化アプリ “Automate” を使った「夏向きアプリ」について書いた。
これも、一種のプログラムである。

昨年あたりから、学校での「プログラミング教育」というのが話題になっている。
Scratch_programming_sample.png 前に「子供達にプログラミングを教えよう」というTEDのプレゼンテーションを紹介したことがある。このプレゼンテーションで紹介されていたのは “Scratch” というプログラミング言語(ツール?)で、私はこれについてはまったく知識はないのだけれど、プログラミング画面を見る限り、用意されたブロックを組合せて簡単に書けるようになっているのではないだろうか。

私がコンピュータ・プログラミングを覚えたのは学生時代だけれど、1行1行プログラムを書くのは結構面倒だった。


プログラミングがそのように面倒だった三十数年も前のこと、会社の研修に「コンピュータ・プログラミング」というのがあった。

前述のように、この頃は、学校でもプログラミングを教えようということになっているが、当時は(今でも?)プログラミングは特殊な技能で、ほとんどの人は無関係だった。会社の研修も、業務上必要な技能としてではなく、コンピューターとはどんなものなのか、教養として習得するというような位置づけだったと思う。受講者には、一部、仕事で使おうという人もいたが、習得の動機が「興味本位」という人が大半だった。

私は、その社内研修で、COBOL研修の助手を1度、FORTRAN研修の講師を3度やらされたことがある。
こういう講師の経験はまったくないし、ナマケモノの私は講師の参考になるような図書も読まず、全くの我流でカリキュラムを組んだ覚えがある。

研修は、2~3時間を1コマとして、10回ぐらいだったように思う。この間に、少なくとも1つはプログラムを書いて、実際に大型計算機で動かしてもらう。

私は学生のときにFORTRANを覚えたけれど、FORTRANの授業自体はせいぜい3,4回だったのではないだろうか(多分、全部は出席していない)。
テキストはJISの文法書のみ。講師は、何か薄っぺらくて安い入門書をテキトーに選んで覚えたらよろしい、というので、私もそうした。

そういう教育を受けてきたものだから、私もそういうやりかたをしようと思ったのだけれど、さすがに学生相手ではないから研修所から叱られそうなので、例題に合わせて必要な文法事項のみを抜き書きしたようなプリントを作った覚えがある。

しかし、講師を経験してみると、いろいろ気がつくことがあるもの。
私は3回も講師をしたのだけれど、1回目は全く要領を得ず、授業の流れ、カリキュラムの流れ、共にぎごちないものだったと思う。2回目のときは、前回の経験があるから、きちんと準備してカリキュラムの組み立てもできたし、授業でのしゃべくりも、自分でも納得できるものになったと思っている。そして3回目になると、悪慣れしてしまった。4回目は無いなと思った。

FORTRANlecture.jpg どの年も、最初の授業では、誰でもプログラムは簡単に書けます、と言って、
      STOP
      END
というのを板書した。

で、講師をしていてこれで良いのかと思っていたのが、FORTRANで使われている英語を日本語にしているだけじゃないのか、という疑問。

GO TO 10 というのは、10という番号がついているところへ行くことです。

何の説明にもなっていない。(というか、説明の必要すらないと、私は思う。)
これは後に、海外研修生(会社の友好事業)相手にプログラミングの手ほどきを頼まれたときに、おもいっきり気づかされることになった。
英語でFORTRANを教えるときに、こんなやりかたはできっこないでしょう。
で、巷にあるFORTRAN入門というようなテキストを見ると、やっぱりそういう日本語訳をつけて済ませているようなものが結構ある。

中国からの研修生も受け入れたことがあるが、文革の影響で英語教育を受けていないということで、それはそれで大変。「GO TO」は「」です、とやっていた。


所詮、コンピュータ言語の文法などというものは覚えるもので、アルゴリズム的な思考法、記述法が先にできてなければプログラミングなどできるわけではない。

断っておくが、文法そのものにはさまざまな知恵が詰まっている。その知恵を鑑賞できる技量がある人はコンピュータ・プログラミングなど既に習得済みのはずである。


こういう経験をしたからかもしれない、「わかりやすい表現をしましょう」と言って、漢字をひらがなにしているだけ、というような事例を見ることがある。
それって、全然、わかりやすくなってない!

前にも書いたような気がするが、大手ITメーカーのSEは、プログラムを書かないようだ。
ちょっと手の込んだ要求をすると、「それをするにはプログラムを書かなければいけません」などと平気で言う人がいる。
私などは、なんだプログラムを書いたらできるじゃないか、なのだけれど。
もう一回、小学校から行き直したらどうだ。

スポンサーサイト

Galleryの改修

先日、本ブログのサイドバーにGalleryを導入した。
小さい画面でスライドショーを、それをクリックして大きな画像を出すというものだったけれど、その後、既にお気づきのかたもかたもいると思うが、大画像のウィンドウ(タブ)側もスライドショーになるようにしてみた。

なかなかうまく動作せずに、ああでもない、こうでもないと苦労したのだけれど、なんのことはない、スクリプト中の論理式で、"=="とすべきところが、"="になっていただけだった。しばらく書いていないとこういう勘違いをしがちである。

※記事中にJavascriptが書けることがわかったので、以下に上記改修と同様のスクリプトを入れてみた。

記事中にJavascriptを書いてみた

先日、サイドバーにGalleryを置いたけれど、そのため、今さらではあるが、ブログの動作についてあらためて調べることになったのだけれど、どうやら記事中にjavascriptが書けるようだ。

ネットの情報では、記事にjavascriptを書いても動作しないのは、投稿時にブログ側が解釈をすることがあるからで、その代表が自動改行のようである。

投稿フォーム中に改行があると、ブログ側は"<br>"を補うようだ。このため、scriptコードとしては不適当なものが生成される。

試しに、前の投稿で紹介したものだが、楽音と周波数の相互変換を行うjavascriptを記事中に埋め込んでみた。
また、formもちゃんと動作することがわかった。

fc2ブログにはいろんなプラグインがあって、私もGalleryで使わせてもらっているが、ブログ全体の動作がもう一つわかっていないと、何ができるのか、どこをいじれば良いのかなど、なかなか掴めない。記事にそのままscriptがかけたら便利かもしれないなどと考えていたわけ。

もっとも、ブログというものの性格上、scriptを書き散らすようなことはしないと思うけど。

楽音と周波数   基準 A4 = Hz


※どれかのフィールドに数値or音名を書き入れて、上ボタンのクリックで他のフィールドに計算結果を表示

SaveAsIcalを発行するVBscript

前に、Outlook予定表とGoogleカレンダーの同期ができなくなったので、そして、Outlookの予定表をiCalender形式で出力し、それをGoogleカレンダーでインポートすることにし、そのための簡単なVBscriptを作って利用していると書いた。

そうしたら、通りすがりの方から、"ECOというソフトを使って、グーグルの連絡帳とカレンダーを同期できる"というコメントをいただいた。ブログで文句を言うと答えてくれる人がいる、感謝々々である。
もっとも、今のところ職場のポリシーの関係もあって、前に書いたように、未だ手作業同期を続けている。
で、私が使っているスクリプトも、どなたかのご参考になるかと思って、以下に示しておく。
なお、筆者はこのスクリプトを "SaveAsIcal.vbs"という名前でデスクトップに置いて使っている(従ってicsファイルはデスクトップに出力される)。
'■SaveAsIcalメソッドによる、OutlookカレンダーのiCalender形式での出力
' 起動後、出力対象日付入力(デフォルトは本日から31日間)
' 出力先は本スクリプトのあるフォルダ内に "@outlook.ics" として

Dim objWS
Set objWS = WScript.CreateObject("WScript.Shell")

Const olFolderCalendar = 9
Const olFullDetails = 2
Const olFreeBusyAndSubject = 1 'こちらは使わない

Dim OlApp 'Outlook.Application
Dim OlNmSp 'Outlook.NameSpace
Dim OlEx 'CalendarSharing
Dim objF

Dim DSTR

SD = Date
ED = DateAdd("d", 31, SD)
SED = InputBox("SaveAsICal", "StartDate-EndDate", SD & "-" & ED)
DSTR = Split(SED, "-")

Set OlApp = CreateObject("Outlook.Application")

Set OlNmSp = OlApp.Session
Set objF = OlNmSp.GetDefaultFolder(olFolderCalendar)
Set OlEx = objF.GetCalendarExporter

With OlEx
.CalendarDetail = olFullDetails '全詳細情報
.IncludeWholeCalendar = False '日付指定に従う
.RestrictToWorkingHours = False '勤務時間に限らない
.IncludeAttachments = True '添付あり(但し、Google側は受けられない)
.IncludePrivateDetails = True 'プライベート情報含む
End With

OlEx.StartDate = DSTR(0)
OlEx.EndDate = DSTR(1)

'このスクリプトがあるフォルダにiCalender形式で出力する
OlEx.SaveAsIcal (objWS.CurrentDirectory & "\@outlook.ics")

'OlApp.Quit    'Outlookを終了させる場合
OlApp = Null

MsgBox "SaveAsICal finished" & vbCrLf & SED

'Firefoxを起動してGoogleカレンダーの設定画面を開く。他ブラウザならプログラム名を変更
objWS.Run """c:\Program Files\Mozilla Firefox\firefox.exe"" -new-tab https://www.google.com/calendar/render#i"

本ページのソース部分をコピー/ペーストするか、下記リンクからダウンロード。(但し、動作保証はいたしません)

SaveAsIcal.vbs ファイルはこちら

情報の真贋

テレビを見ていたら、「大型動物は体を支えるために大きな獲物を獲る必要があります」という解説を聞いた。
何の番組で、何についてのことだったか思い出せないのだけれど、この一言を聞いて反射的に「それは違うやろ」と思った。

言うまでもなく、大型動物はだいたいが草食だし、草食ではないが地球上最大のシロナガスクジラが食べるのはオキアミなどのプランクトン。最大のサメであるジンベエザメもそうである。

HuntingLion.jpgおそらく、いわゆる狩をする大型肉食動物、ライオンやトラ、そういう動物を念頭においていたのだろう、ライオンがアリを食べるとか、ネズミをとらえるという話は聞かないから、そういうイメージからすればこの解説は当たっているとも言える。

しかし、反例でわかるように論理的には成り立たない。逆はある程度成り立つと考えて良い、すなわち大きな獲物を捕えるのは大型動物である、これはだいたい正しい(アリの大群が牛を襲うというような話もあるし、食べるというのとは違うけれど、ウィルスが大型動物を倒すのもあるけれど、1対1の狩ではない)。

これだから理屈っぽい奴はイヤなんだ、と言われそうだけれど、おかしいものはおかしい。思うに、メディアで流される解説には、この手の一見もっともらしいが、良く考えてみると反例がいっぱいあるというものは結構あるのではないだろうか。
ネット社会で、ちょっと検索すればいろんな情報が得られるようになったが、その情報の真贋を見極める力が必要となっている。

すごくイヤラシイ話に聞こえると思うが、他人の企画案や業者の見積りを査定するとき、その内容について全く素人の場合、企画案の論理に矛盾や飛躍がないか、これを相手から説明を受ける中で嗅ぎわけるというのが査定側の常套手段である。

有能な査定者は「ここをこうしたらやりたいことがもっとうまくできませんか」と水を向けたりする。(ただし、予算制約がきつくて、どんな素晴らしい企画でも通さないという場合もあるだろうが。)

大袈裟な言い訳だが、論理的破綻の指摘と解決策の示唆、案外、某大哲学者の方法に通ずるのではないだろうか。

正確な情報

次の情報のどちらが正確と言えるか。
 a. 24時間以内に高さ3m以上の津波が来る
 b. 24時間以内に高さ5m以上の津波が来る

いささか古めかしい話だが、最近読んだ本(坂井修一「ITが守る、ITを守る」(NHKブックス))に東日本大震災のことが書かれていた。

keihou.jpg同書では、このときの津波警報に触れ、「・・・本震が続いている最中に津波警報を出さなければならない。これでは地震の規模がわからないために、予想される津波の高さは過小なものとならざるをえないのである。ところがこの過小な値をそのまま信じると、高さ10mの堤防があるから大丈夫だと判断したり、非難するべき場所が低いところでよいと考えたりすることになる。」

このことは震災直後から指摘されていたことで、同書では気象庁が「津波警報の発表基準等と情報文のあり方に関する提言」を公表したことも説明されている。著者要約をさらに要約すると、

・「簡潔な表現」「行動に結びつく表現」・・・
・防災対応とリンクしていない表現を改める
・規模推定の不確定性が大きい巨大地震の場合、M8超では「高い」「巨大」と表現


妥当な結論だと思う。著者も、「3m以上といわれて10mの津波が来ても、論理的に間違いとは言えないが、心理的には認めがたい情報伝達ではなかったか。」と続ける。
論理的に正しい、とか、正確な情報と言う場合、気をつけなければならないことがある。

「3m以上の津波」と「5m以上の津波」という2つの情報を比べると、常に前者が「正確」である。
情報の正確性を、その情報が正しい蓋然性が高いことと定義すれば、そういうことになる。
もっとも正確なのは「津波が来るかもしれないし来ないかもしれません」という情報。これは100%正確である。
津波警報を出す者が、情報の「正確性」にこだわれば、いわば情報の「安全サイド」である「3m以上」を採用することになる。
informationvolume.png
情報量という考え方がある。「びっくりする度合い」を表すという。
情報理論の入門書などでは、次のような例で説明される。

 a. 年に1日しか雨が降らない砂漠の天気予報で、明日は雨が降るでしょう
 b. 年に366日雨が降るといわれる屋久島の天気予報で、明日は雨が降るでしょう


aの情報量は log(365)≒8.5(bit)、bの情報量は log(1)=0(bit) というわけである(対数の底は2。以下同じ)。

津波に即して言うとすれば、200年に1度の大津波が24時間以内に到来するということであれば、log(200×365)≒16.2(bit) と計算されるわけだし、1時間以内に到来するということなら log(200×365×24)≒20.7(bit)。
しかし、16bitなどというのは、日常感覚からはハズレすぎでイメージが持てないだろう。なにせ、16bitってたった2バイト(文字)相当というわけで、パスワードの情報量よりはるかに少ない。(だいたいbitという単位は8bitで1byte、音楽データ(mp3 128kbps)なら1分で1MBにも満たない)

2by2table.jpg正確性に関連する概念として、感度と特異度というものもある。
検査の有効性判断などで良くみかける表で、疾患の有無と、検査の陽性反応をクロスした2×2の表があるが、感度が高いとは、偽陰性が少ないことを意味し、特異度が高いとは、偽陽性が少ないことを意味する。

日常用語では、感度ばかりが使われるようだが、見落としをしないことを至上命令とすると特異度の低い検査をしがちになって、いらぬ不安を与える。

大昔の聞き覚えで申し訳ないが、胃がんの集団検診(X線検査)では、10%程度が要精検となり、精検受診者の1%程度ががんと判定されるそうだが、要精検率は検査機関によってかなりばらつきがあるそうで、30%もの要精検を出すところもあるらしい。見落とし(を批判されること)が怖いといって、X線写真で紛うことなき綺麗な写真以外を全部要精検に回したら、それこそ半分以上の人は精密検査送りだろう。(この頃はX線での集団検診でなく、いきなり内視鏡で検査をしてもらう人が多くなっていると聞く)


日常用語の「正確」とか「高感度」と、科学用語の「正確」「高感度」とはこういうズレのある概念である。
どちらが良い・悪いではない。
専門家は、自分たちの世界ではそれで良いかもしれないが、外の人に情報を伝えるときは、その意味まで伝えなければならないと思う。
そのときに考えるべきは津波警報の例でわかるように「行動に結びつく」実効性だと思う。

「子供達にプログラミングを教えよう」

コンピュータ・プログラミングを学ぶことは、けっして人生のムダではない。
(数学を教えるより、プログラミングを教えるほうが多分、実用的だろう)
実際にプログラムを書くことが(COBOLで書くのは除く)、システム・センスを磨くもっとも確実な方法だと思う。そしてシステム・センスは、何度も言ってるが、あらゆる対象を理解し、言語化する普遍的に必要な資質である。

誰もがプログラミングを仕事にするわけでは勿論ないが、プログラムを書かないということと、プログラムを書けないということには大きな隔たりがある。そして、直接仕事に結びつかない技量を身に付けることができるのは、やっぱり学校で、無理やりにでも子供たちに覚えさせるというやり方だろう。(それでも多くの子供達はプログラミングに興味を持つことになると思う。特に、自分が書いたプログラムがすぐその場で動くという、他の教科ではなかなか味わいにくい体験ができるのだから)

タイトルの「子供達にプログラミングを教えよう」というのは、NHKの「スーパープレゼンテーション」という番組(既に終了)で放送された、TED(Technology Entertainment Design)のプレゼンテーションのタイトル。
MitchResnick.jpg

日本語訳がついた解説サイト(デジタルキャスト->TED日本語)もある。

Scratchというプログラミング言語(環境)を中心にした講演で、子供達がプログラミングを楽しんでいることが語られる。
また、講師レズニック氏の83際の母親が、Scratchを学び、息子のためにバースデーカードをプログラムして送ってくれたということも語られる。

ある大学の工学部の情報系学科の先生(プログラミング論)と話す機会があって、「この頃の学生はプログラム書きますか?」と聞いたら、手を横に振っておられた。

プログラマーとSE

前に本物のシステム・エンジニアがどういうものか書いたが、やはりそういう理解は世間の理解とはズレている。今日は世間的理解のSEについて、プログラマーとSEの関係について考えてみる。
se_kaisou.jpg
以前、プログラマー⇒システム・エンジニア⇒プロジェクト・リーダー(システム・インテグレーター)というようなキャリア・パスが説明されていたのだけど、私の感覚では、役に立つ順はこの逆である。

某民間企業の新採社員と名刺交換したとき、肩書にシステム・インテグレーターとあった。つまり、設計ができず、プログラムが書けない人のことを言うらしい。
実際に開発にかかわるSEに、ここをこうしたらすっきりするのではと提案すると、それにはプログラムを書かなければならないと言う。
結局、役にたつのはプログラマーということになる。

このごろのSEはプログラムを書かないらしい。想像するにこれには技術的理由と開発体制に起因する理由があるようだ。
技術的理由というのは、かつてのメインフレーム・コンピュータ時代は、その技術で統一的かつ斉一にシステムを開発していたが、今は多くのサーバーを組合せ、各種のミドルソフトを使って開発しているので、多様な技術が求められ、プログラムができればシステムがわかるという時代ではないということ。
開発体制に起因する理由というのは、プログラムを書くことが必要でも、それは海外の業者に委託することが多くなっていて、ユーザーサイドのSEがプログラムを書くことが想定されていない、また、その変更は海外への委託内容の変更あるいは追加発注となる。(絶対手戻りが発生すると忠告しているにもかかわらずウォーターフォール開発をやめようとしない)

LISP礼賛

COBOL批判、FORTRAN贔屓ときたが、今日はLISPをとりあげる。
私が一番好きなプログラミング言語はLISPである。LISPでシステムを開発したこともある。
パソコンで、各種の生活習慣や身体データから余命を計算し、煙草をやめると何年寿命が伸びるかなどの生活改善指導情報を与えるもの。もちろん疑似的なGUIも持っている。

開発言語にLISPを選んだ理由だが、この仕事は、既存の計算手法をプログラミングするのではなく、的確な計算ロジックを開発・テストすることが目的なので、作りながら考えるインクリメンタルなアプローチが必要で、開発している「世界」(=LISP空間)に、機能・データを次々に導入・拡張できるLISP処理系が最も適していると考えたからである。(しかもその拡張すらマクロを使って自動化=プログラムの自動生成すらできてしまう。)
プログラムを書くというより、世界を創るという感じがうれしい。
LISP世界

LISPのエレガントさは後にして、実用上で強力だと思うのは、前述のように世界を拡張できることであり、それを支えている特徴が、関数型言語であり、かつ関数の戻り値がリスト(なんでもあり)であるということ、シンボルにいろんな属性をくっつけておけることなどがある。

LISPを知らない人(いくつかのプログラム言語を知っていても、LISPは知らない人が多いと思う)のために、例えば宛名を印字するプログラム(宛名印刷 住所 名前)を考えよう。このときプログラムは住所、名前は印字すべき文字列として記述されるわけだが、住所録が別に存在していてこれを参照するとしたらプログラムの呼び出しは(宛名印刷 (住所録住所 キー) (住所録名前 キー))というように記述できる。
あるいは、効率の観点から住所と名前をリストで扱いたいとしたら、それを返す関数(住所録参照 キー)を作って、(apply ‘宛名印刷 (住所録参照 キー))とすることもできる。夫婦など宛名を連名にする必要があれば、もちろんプログラム宛名印刷は名前がリストの場合、リスト要素を並べて印字するように改造し、住所録名前関数が、必要なときは連名のリストを返すというようにしてやれば良い。MAP関数群を使えばループ構文など使わずにループと同様の動作をさせることができる。

LISPのエレガントさといえば文法がない(括弧のバランスが唯一のルール)ことだろうが、LISPに惚れるのはやはり再帰プログラミングだと思う。LISPを勉強しはじめたとき、再帰をうまく使う発想がなかなかできなかったが、LISPを通じて再帰プログラミングに慣れるということは、新しい思考パターンが自分に加わる快感を覚える。インタープリター系言語だと再帰呼び出しは普通に行えるが、それを使う人はおそらく稀だと思う。
LISP入門者が最初にやるだろう階乗を計算する関数の再帰的な定義
(defun factorial (n) (if (<= n 1) 1 (* n (factorial (- n 1)))))

LISPの世界をのぞいてみたいという気になった人は次の本がおすすめ(著者は本書の中で「LISPは学ぶに値する言語」と書いている)。
WinstonLISP.jpg

FORTRAN贔屓

昨日COBOL批判をしたが、今日はFORTRANのここが好き、ということで。
私がFORTRANを覚えたのは大学の3年のとき。講義は、たしか「計算法」という授業のなかで数時間だけ、教材はJISの文法書だけ。それだけでプログラムが書けるようになるわけではないので、講師は、できるだけ安くて、薄っぺらい本を読んでください、という素晴らしいアドバイスをしてくれた。
続けて「計算法演習」という授業があって、はじめて実際に電卓以外のコンピュータに触れた。まさに「触れた」。大学にはいくつか利用できるコンピュータがあったが、演習では数学教室のコンピュータを使った。紙テープを作って読ませていた。当時でも紙カードが普及していて大型機などはカードだった。
コンピュータにやらせるのは主に微分方程式の数値解法、オセロ・ゲームなども遊びで作った。

FORTRANの良いところというと、覚えることが少なく、すぐに使い慣れた道具になるということだと思う。新しい言語のように理論的に良く考えられたものでもなく、特にとりたてて言うことはないだろう。
実はFORTRANの真価はコンパイラをはじめとする処理系にある。私は本格的な科学技術計算にはあまり縁がないが、FORTRANコンパイラはプログラマが書いたものに徹底的な最適化(同じ演算は二度やらないとか、ループでのパイプライン制御や、ベクトル・プロセッサ付処理系ではベクトル演算にするなど)を行う。

FORTRAN文法はシンプルで、データにも構造というものがないからこうしたことがしやすい。さらにこれは、デバッグのしやすさにも貢献する。
たとえば、私が使っていたFORTRANコンパイラは、次のような警告メッセージを出してくれていた。
・演算の型が不一致(整数+実数などは本来許されない。コンパイラは整数を実数化して演算する措置をとる)
・値があたえられずに演算に使用されている
・宣言された変数が一度も使用されていない

こういう警告が何故ありがたいかというと、変数のスペルミスなどを冒すとそれはこのようなエラーとして検出されるからだ。構造体をあつかうCOBOLなどでは変数が使われているかどうかなどは原理的に判定のしようもなく、マネできない。C言語でもある程度FORTRANのようなエラー検出はできそうだが、アドレスを直接操作したりするところはどうしようもないだろう。(Cは書き間違いをしても動いてしまうようなところがある。)

FORTRANはCOBOLと違って文書性などどうでも良いわけだが、それではプログラマ自身が困る。私はFORTRANプログラムでは必ず最初に一通りのコメントを置くことにしていた―モジュール名、機能、引数(サブプログラムの場合)、入出力ファイル、外部参照、特記事項など。プログラム途中でも適宜コメントを入れたり、見易さのために空白行を置いていた。1つのプログラムは最長でもコメントを入れて2ページ(100行)以内にしていた。なお、FORTRANで処理すると面倒とか効率を落としそうなケース(10進演算とか)はアセンブラでサブルーチンを書いてリンクしていた。
こうした言語やコンパイラの特性をプログラマが理解し、自分の書法を確立していれば、FORTRANでのプログラム開発効率はとても高いと思う。
FORTRANプログラムの私流冒頭コメント
CMODULE NAME:test
CDESCRIPTIVE:覚えやすい説明を1行で記入
C NOTE:モジュールの機能詳細
C
CCALLING SEQUENCE: test(arg1,arg2,arg3)
C ARGUMENTS:
C arg1: I*4:out:結果
C arg2: R*4:i/o:呼び出し元作業域
C arg3: C*8:i :○○の文字列
CEXTERNAL DATASETS:
C
CEXTERNAL REFFERENCE:
C
C CREATED:
C UPDATED:
C--------------------------------------------
SUBROUTINE test(arg1,arg2,arg3)
INTEGER*4 arg1
REAL*4 arg2
CHARACTER*8 arg3
C
 ※先頭のCはFORTRANでコメントを示す

昔、コンピュータ関係の雑誌に「○○年後のプログラム言語がどのようなものかはわからない。わかっているのはその名前だけである――FORTRAN」というヨタ話が載っていたが、歴史上最初の高級言語は、きっといつまでも使われることになるだろう。

COBOL批判

昨日稿の最後に「COBOLで育った技術者は大抵、システム・センスが悪いと感じたものだ」と書いたのでその理由を書こうと思う。
それでCOBOLのプログラム例とかのネタを探そうとググったら、WikipediaのCOBOLの項目に次の記述があった。
構造化プログラミングを提唱した計算機科学者エドガー・ダイクストラは、各種言語の欠点を挙げた中でCOBOLについて
COBOLを使っていると人は無能になってしまう。COBOLの教育は犯罪とみなすべきである。」と述べた。
まさに私が感じていたことそのままである。この言葉の出所や内容は知らないので、ダイクストラ先生が何をもってこれほど辛辣な評価をしたのかは想像するしかないが、多く見られるCOBOL批判としては次のようなものがある。
・無理に英語的表現を取り入れたために冗長
・論理制御機能が貧弱
・そもそもID、ENVIRONMENTのDIVISIONがムダ
・局所変数がなく、一時的変数も無駄にDATA DIVISIONに記述が必要

いずれももっともである。で、私がCOBOLの最悪の欠点と考えているのは、モジュールを書きにくいという点である。そしてモジュールを書きにくいということは、それだけでデバッグを困難にし、さらにシステム設計の基本であるモジュール分割のセンスが鍛えられないという結果につながる。
モジュール(サブプログラム)が書けないわけではない。しかし、モジュールを書くには、ID、ENVIRONMENT DIVISIONの決まりきった記述に十数行を当てなければならず、それだけでソースリストの1ページの半分が埋まってしまう。そして、続くのがDATA DIVISIONで、ここに局所変数も何もかも書かなければならない。それも1変数1行!、これだけ書かされるとなるとモジュール分割などしようという気にならない。
COBOLにもサブルーチン的なものはある、SECTION単位に実行するというもの。しかしこれはモジュールではない。なぜならSECTION単位でのデータ(局所変数)ができないからだ。

FORTRANプログラムの場合、何かややこしい計算が必要になったら、プログラマーは次のように書く:
      CALL nanika(kotae,youso1,...,youson)
COBOLプログラムの場合は、そこでややこしい計算をコーディングしようとし、DATA DIVISIONと行ったり来たりして書いていく。

COBOLの良いところとして、データの構造体が書けると弁護する声がある。しかし、FORTRANユーザーから見ると、これがさらに状況を悪くする原因にもなる。構造体は真の意味で構造を表しているわけではなく、単に連続するメモリー領域の部分部分に名前を付けるだけだからだ。機能的には何も便利な拡張が行えるものではない。誤解を起こすもとになるのではないか。

「文書性」を良くしようとして、良くできたコメントを書けば済むところを、文法にしてしまったところがCOBOLの悲劇だと思う。

いらないことをたくさん書かなければならないCOBOL

IDENTIFICATION DIVISION.
PROGRAM-ID sample.

ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER xxxxx.
OBJECT-COMPUTER xxxxx.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT fff ASSIGN TO dddd.

DATA DIVISION.
FILE SECTION.
FD fff BLOCK CONTAINS n RECORDS.
01 rec.


WORKING-STORAGE SECTION.
77 workarea1 PIC 9(8).

01 area.


LINKAGE SECTION.
77 parm1 PIC 9(8).
77 parm2 PIC 9(8).

PROCEDURE DIVISION USING parm1 parm2.
main SECTION.


sub1 SECTION.


素人プログラマーは「動いた・動かなかった」、プロは?

今まで、javascriptのサンプルをいくつかアップしたけれど、javascriptもプログラム言語の一つではある。これらのプログラムを書くときは、ネットで同様の機能の使用例を調べて、見よう見まねで書いている。素人プログラマーというわけである。
一般に、プログラム言語そのものは単純なもので、何か一つの言語を習得していれば、他の言語の使用は類推でどうにかなる(手続型でないLISPはちょっと違うけど)。

難しいのは、言語そのものでなくその環境。javascriptを使う場所はHTMLなわけで、HTMLの仕様(DOM=Document object modelや、audioタグなどの機能)を理解していないと凝ったものは書けない。そして、そういう知識が絶対的に不足している私は、ネットで事例を集めて、試行錯誤を繰り返し、動いた・動かなかったと一喜一憂するわけである。
とても効率的とは言えないが、プログラミングを仕事にしているわけではないし、そもそも実現したいニーズがたくさんあるわけではないから、きちんと系統的に知識を得る努力をしていないわけである。

DOM.gif

昔、IBM370アーキテクチャーの上でFORTRANを使っていた頃は、そうではなかった。
プログラムというのは決定論的に動くもので、動いた・動かなかった、という感覚ではなく、正しい・間違っている、だった。FORTRAN言語に内装されていないもの―たとえばディスプレイやプロッターなどのコントロールは、ライブラリーとして提供されていて、そのインターフェイスは極めてクリアだった。私でも完璧にコントロールしているという自信があったものだ。

それに比べ、昨今は、私の不勉強は暫く措くとして、なんだか「動いた・動かなかった」の結果論が横行しているように思える。
プログラムをドライブする側が分散し、非同期的に動いているようで、これがそう感じる原因になっているかもしれない。昔から非同期プログラムを書く方法は存在しているのだが、その場合は、並行処理しているモジュールの完了を、積極的にチェックしたり、OSに依頼してソフトウェア割り込みを起こしてもらうという方法を、「意識的に」プログラムしたものだ。

素人プログラマーは動いた・動かなかったで一喜一憂していても害はないが、現在、プロと言われる人達は、どこまで意識してプログラムを書いているのだろうか。プロが作るものは動作保証が必要で、外部要因で不具合が出るなら、その責任の所在を特定しなければならないと思うのだが。(そこまでの品質を求めたら高くなると言われるかもしれないが、求めないなら素人に頼む値段で十分では)
Gallery
検索フォーム

⇒記事一覧

プロフィール

六二郎。六二郎。


定年退職
苦しい家計の足しに再就職
=いつクビになってもええねん
 言うたもん勝ちや!のブログ
リンク
最新記事
最新コメント
最新トラックバック
アーカイブ
カテゴリ
タグ

ITガジェット 書評 マイナンバー Audio/Visual 

リンク
現在の閲覧者数
聞いたもん