比較プログラム言語論 平成１６年６月３０日 森田　彦

レポート（6/23）総括 　＜　テーマ　＞　 本日の講義で、あなたが最も興味を持った点はどのような点ですか？講義の全体的な感想と共に、できる限り具体的に、200字～400字程度で記述して下さい。 ＜項目＞ 　一ヶ月の討論を終えて・・・ 　討論の到達点について 　理解が先か？楽しさが先か？ 　LOGO言語・タートルグラフィックスについて 　FORTRANの型宣言について 　FORTRANのサブルーチンについて 　FORTRANの制御構造の発展について

一ヶ月の討論を終えて・・・① 都合のいいプログラミング言語が欲しい迷える厳密文法派です。 たくさん意見をもらえて嬉しかったです。どうもありがとうございます。実はないと分かっていつつ「両方のいいところを取った都合のいいプログラミング言語」が欲しいと言ったのですが（あれこれ求めた結果、多くの言語があるという答えが初めに出ましたから……ないものねだりです）、無責任に出したこの問いかけが、今回の議論における結論のひとつを導いた、きっかけの一端になれたようで幸いです。　 　（略）今回自由文法として取り上げられていたBASICは学校教育で使われた言語でしたが、厳密文法のDelphiも同じように学校教育で用いられていたと記憶しています。これはつまり、教育現場でも自由であるべきか厳密であるべきか結論が出ないということで、・・・（略）　 　ただ、都合のいいプログラミング言語の出現を諦めたわけではありません（笑）。オブジェクト指向は人間の認識や思考によりマッチした考え方だと言われていますが、この「人間にマッチした」を突き詰めていくといずれ、人間の適度な自由さと厳密さを兼ね備えるようになるのではないかと思います。どれだけ時間がかかるのか分かりませんが、プログラミング言語の発展に注目していたいです。

一ヶ月の討論を終えて・・・② 6/16時点： 厳密文法派44.4% 自由文法派55.6% いろんな人のレポートを見て、こんな考え方や方法もあるのか、と毎回驚いています。みんな考えていることが違うことが分かって、とても面白いと思いました。 自由文法派と厳密派の討論もそうですが、一人で悩んでいても、ある1つの考えに執着してしまって、なかなか前に進まなかっただろうと思いました。 いろんなレポートに影響されて、自分の考えも変わったりしました。 数回の講義にわたった厳密文法vs自由度・融通の論争はなかなか白熱して、楽しかったです。双方の意見数がちょうどぴったり二等分されていた所から始まり、講義が進むごとに深い見解になってくる所など、非常に興味深かったです。私も最初は厳密文法派だったのが、途中自由度・文法派に傾きかけたり、結局は厳密派に戻ったりしました。 結局最終的にはどちらの意見が多かったのでしょう?　私は自由度派の方が多いだろうと思っていますが、『楽しさが先か、理解が先か?』では予想に反して理解派が圧倒的に多かったようです。 6/16時点：　厳密文法派44.4%　　自由文法派55.6%

討論の到達点について① 今年度のクラスは、教育に関して関心が高かった。 今までの討論の到達点に深い感銘を覚えました。このまま討論を続けていても出口が無いことは目に見えて解っていました。しかし、「両者のメリットを理解した上で、欠点に陥らないように教育すること」は思いついておりませんでした。今まで『どちらの言語を使うか』ということだけを注視しすぎて、支持する言語の欠点を補う方法まで考えが向かえませんでした。逆に反対意見の言語の欠点は指摘できてもその欠点の改善策を考えるなんて想像しませんでした。大事なことは仮に自分が支持する言語で教育する立場に立った時に、相手が困らない教え方をすることなのだと気付きました。自分の知識をひけらかすのではなく、興味を持って楽しく理解してもらおうとする姿勢が大事なのだと感じました。…個人的に一部の教授にこの言葉を渾身の思いで伝えたいです…。 今年度のクラスは、教育に関して関心が高かった。

討論の到達点について② 今回の講義で前回までのレポートの討論での結果が非常に面白い形になったと感じました。 どちらか一方が良いというのではなく、厳密文法、自由度の高い文法、どちらにも長所・短所があって、それぞれの長所を理解した上で短所を回避しながら教育するということは、教育を受けた者の中に将来、欠点をどんどん少なくし、長所を伸ばして、現存するプログラム言語よりも扱いやすいプログラム言語を作成する人物が出てくる可能性が高くなるのではないかと考えたからです。よりよい教育を受け、楽しく理解しながらプログラミングを学ぶとプログラミング言語の発達もより良いものになっていくと感じました。 今回は数回に及んだ、今までのレポートの討論における「１つの到達点」を確認することができました。（略）・・・結果的にどちらか一方という答えが出るものではないと理解していますが、少しは答えを出そうと無理に考えていくことで、それぞれのメリット・デメリットに気づき、有効的な利用方法を見つけ出すことができるのではないでしょうか？

理解が先か？楽しさが先か？① 今回、興味をひいたのは、 全体の約三分の二が、「学習において始めに、必要なことは理解である」 という結果を出したことである。（略） そこで『プログラミング』の講義に使う教科書を、作るにあたって先生はどのようなことを重視したのか、それをまず聴いてみたいとおもう。そのことで現在の教育の考え方を読めるからだ。できればこの講義で面白い結論がでたならば、その意見を使用（採用）した教科書を考えていきたい。 6/16のレポートではプログラミング言語について理解が先か、楽しさが先かという討論があり、2/3の人が「理解が先」という意見でした。しかし抜粋レポートなどを見てみると単純に、プログラミングの授業なのだからまずは理解をしなければならないという義務的な意見ばかりではなく、理解＝楽しさのような意見もあり、改めて理解と楽しさの関係性の難しさと学習効率に与える影響を考えさせられました。 別に教職を取ろうとしている訳ではありませんが、この問題はプログラムにだけでは無く、将来就職して誰かに物事を教えなければならない状況に立った時にも考えなければならない重要な事だと思うので、これからも考え続けて行きたいと思います。

理解が先か？楽しさが先か？② 私は強いて言うなら“理解が先”派なのですが、「理解が先」派が2/3を占めていて驚きました。私の予想では楽しさが先の意見が多いと思っていたからです。　そして、P17（理解度と楽しさの関係）はとても説得力がありました。　これをみると理解の前に成功体験による楽しさが重要なのでは？…すると楽しさと理解のループのきっかけとなるのは楽しさでは？と意見を変えざるをえない心境になりました。　いえ、でも(Javaなどでの)成功体験(実行させる)以前の紙面上での理解も十分楽しさを生むきっかけとなり得る(この場合理解が先)と思うので…難しいと思いました。 自分はこのアンケートの結果も「自由度か？厳密か？」と同じように結果が半々になると思っていたのですが理解するという事が楽しさにつながると考える方が多いようで驚きました。 「理解度と楽しさの関係」でかかれていますが収束点としてですが成功体験が楽しさにつながるようです。　自分は「楽しさが理解度を良くする」とこの前書いたのですが、今回の結果や「理解度と楽しさの関係」の事を聞いてもう一度考え直したのですが混乱してしまいました。「卵が先かニワトリか」みたいに思えてきました。・・・　（略）

LOGO言語・タートルグラフィックスについて 教育で解決するしかないということに到達したのだけれど、プログラム言語を習いたいという人は大勢いると思う。その中で私たちのように先生がいて分からなかったらいつでも先生に聞いて分かるまで教えてもらえる環境にいる人は少ないと思う。（略）サポート無しで取り掛かるというのは難しいと思う。そこで深くプログラムを考えずに済み、楽しくできそうなタートルグラフィックスというのはいいと思った。これなら楽しくできそうでなかなかいいと思う。 今回私は児童教育用言語LOGOについて興味を持ちました。その理由は、現在私はプログラミング、アルゴリズム論、CG論、比較プログラム言語論といった講義を履修しており、プログラムを作ることの難しさを知っているので、小さな子供でもこれらを作ることができるということに非常に驚いたからです。私は楽しいから理解度が上がるという意見に賛成なので最初はこのような簡単な言語から徐々になれていくほうが良いと思います。

FORTRANの型宣言について 今日の講義で私が興味を惹かれたのはFORTRANの発展③型宣言の導入のところのFORTRANⅣで型宣言が導入されたのに暗黙のルールとして型宣言しなくても整数型と実数型を使い分けられるというところです。確かに型宣言をしたほうがプログラムとして見やすいですしわかりやすいです。ですが、以前から使っている人たちにとっては面倒なだけですからそれを暗黙のルールとして使えるところがなんかとてもいい感じがして気に入りました。 FORTRANに、はじめは型宣言が導入されていなかったと言う事に驚いた。プログラミング言語はJAVAしか使った事がないので、型宣言もはじめからあるものだと思っていたが、良く考えれば、JAVAは色々な言語があったからこそ進化して出来たプログラミング言語だから、ある程度完成されたものであって当然だ。

FORTRANのサブルーチンについて 今回の授業で最も印象に残ったのは、FORTRANについて、特にサブルーチンについてのことです。現在専門ゼミでクラスの作成についてのプログラミングをしているのですが、このサブルーチンを見てまさにクラスの原点ではないかと思いました。本筋のプログラムとは別のところに記述し最後にRETURNで返すところなんかはクラスそのものだと思いました。このサブルーチンが導入されたのは１９５８年のＦＯＲＴＲＵＮⅡからであると知り、５０年近くにわたりそれが使われ続けられてきたということに驚きました。

FORTRANの制御構造の発展について 今回の講義で最も興味を持ったのは、分岐処理の表現です。以前は“GO　TO”などと、現在と比べるとかなり複雑で難しいことになっていたと思いました。そして見通しを良くするために“GO　TO”文を削除して、“END、ELSE、IF”などを導入して、発展していったのは凄いと思いました。“GO　TO”文を削除して実行内容量は増えたようだが、プログラム全体はより見易く良くなったのではないかと思います。 BASICをプログラム学習の最初にさわった人間として、このタイプの記述方式には随分と慣れていますが、分岐・繰り返しにおける記述の変化は、見ていて面白いです。一応同じFORTRANがベースでしょうから、暗黙に過去のスタイルが引き継がれるところはあるのでしょうが、構造化プログラミングの影響ですか？　これらの部分の変化は興味深い点です。

感想 FORTRANのしくみを初めて知ることができました。科学技術計算を行う人たちに支持されている言語ですが、その使い勝手の点から見てみても普及しているのもうなずけます。しかし、Java言語の登場によってその影も多少薄れてきたのではないかと思います。実際に基本情報技術者試験の問題でもFORTRANは問題の対象になっていましたが、Java言語も登場や、その利用性の高さから見て、FORTRANの問題がなくなったのです。

質問 まず、「WRITE(6,100)」という処理で、WRITEはわかるのですが、次にある6,100というのは何をやっているのでしょうか？ また、IF文によって「GO TO」というのが削除されたのはわかったのですが、IF文代替前の「GO TO」はどういう処理なのでしょうか？ FORTRANの整数型の変数が、ｉ～ｎまで、全部で６つまでしか使えないのでは変数が増えていって６以上の変数が必要になった場合困るのではないかと思いました。 「LOGO」の特徴の「コンピュータとの対話形式でプログラミングできる」というのはどういったものなのかもすごく気になりました。

構造化プログラミングとは？ 提唱の背景－GOTO文の魔力 ダイクストラの主張 構造化のメリット 言語仕様への影響 プログラムのモジュール化へ

GOTO文の魔力 ２．処理Bの前にCが必要に→処理Cを挿入 ３．完成 １．処理A,Bの実行 処理A 処理B 処理C 処理A 処理B 処理A 当時の編集環境では手間がかかる。 GOTO文を用いると･･･ 処理A 処理B 処理C 作成時の順番を維持できる→（当時としては）開発効率が上がる。 しかし、読みにくい。→ミスを誘発する。 処理の順番通りに記述した方が読みやすい。

ダイクストラの主張 分かりやすいプログラムを書こう！ 構造化定理:1つの入り口と1つの出口を持つようなアルゴリズムは、「連接」、「分岐」、「繰り返し」の基本構造を（処理の順に）つなげることで記述できる。→ダイクストラが証明 あらゆる処理（アルゴリズム）はGOTO文は必要ない。　 →　1968年　Dijkstraが主張。→構造化プログラミング（運動）の始まり。 分かりやすいプログラムを書こう！

構造化プログラミングのメリット プログラム開発の効率が向上する。 処理の順番に記述されるので、プログラムが読みやすい。 フローチャートによるプログラム設計が可能 バグの少ないプログラムの開発が可能 構造化により、無駄な処理が少なくなる。 プログラム開発の効率が向上する。

言語仕様への影響 これらの機能が備わって行く過程は、FORTRANの発展過程に顕著。 プログラミング言語は、連接、分岐、繰り返しを表現する機能がなければならない。 　　C:条件　S:処理　と表すと･･･ 分岐の表現 　　if C then S1 else S2 多分岐 　　case C of (C1:S1;C2:S2;･･･Cn:Sn） 繰り返しの表現 　　while C do S　（for文はカウンタ変数を用いる特殊な用途のために特別に用意。全ての処理はwhile文で記述可能）　　 これらの機能が備わって行く過程は、FORTRANの発展過程に顕著。

プログラムのモジュール化 構造化プログラミングの最終的な主張。 構造化プログラミング→プログラムを基本構造（連接・分岐・反復）を（処理の順に）つなげて表現する。 幾つかの基本構造→ひとまとまりの処理→モジュール モジュール→　サブルーチン（FORTRAN）、関数（C言語）など。 プログラムはモジュールの組み合わせで表現できる。 プログラムの基本構造は、モジュールを（処理の順に）つなげて表現できる。個々の処理の詳細はモジュール内部で記述。 構造化プログラミングの最終的な主張。

プログラムのモジュール化 例 問題 学生のテスト成績を読み込み成績順に表示する。 ＜プログラムの構造＞ データの読み込み データのソート プログラムのモジュール化　例 問題　学生のテスト成績を読み込み成績順に表示する。 ＜プログラムの構造＞ データの読み込み データのソート データの表示 Integer Tokuten(200) CALL ReadData(Tokuten) CALL SORT(Tokuten) CALL Display(Tokuten) ＜メインルーチン＞ プログラムの基本構造はメインルーチンで記述 処理の詳細はモジュール（サブルーチン）で記述 ＜ポイント＞ プログラムの基本構造が分かりやすくなる。→見通しが良くなる。

ソフトウェア危機 構造化プログラミング→ソフトウェアの生産性向上 しかし、既存のソフトウェアの再利用性については十分な向上が得られなかった。 ソフトウェアの需要増に、ソフトウェアの生産が追いつかない→ソフトウェア危機 特に、GUI環境の普及に伴って、その傾向が顕著に！　「使う方は天国、作る方は地獄」 より効率の良い、プログラム開発形態は？→オブジェクト志向プログラミングが注目される。 プログラムの拡張の容易さ、あるいは再利用性の向上がキーポイント！ オブジェクト指向言語でどのように改善されるか？

第１１回目レポート 本日の講義で、あなたが最も興味を持った点はどのような点ですか？講義の全体的な感想と共に、できる限り具体的に、200字～400字程度で記述して下さい。 なお、上の記述を行った上で、（いつも通り）講義の感想や質問等を付加しても結構です。 提出先：hiko@edu.sgu.ac.jp　 件名：「学籍番号（半角）+半角空白＋氏名」を記入して下さい。 　　　例）　s02xxx 学院太郎 HPに自由掲示板を開設（6/24）　各自活用して下さい。

FORTRANの発展② 副プログラムの導入 SUBROUTINE HEIKIN(A,B,C) C=(A+B)/2 RETURN END 1234567890 ---------------------------------------------- A=3.5 B=1.5 CALL HEIKIN(A,B,C) WRITE(6,100) A,B,C 100 FORMAT(2F4.1,F5.2) STOP END 1234567890123 -------------------------- 3. 5 1. 5 2. 5 ＜実行結果＞ プログラムの見通しが良くなる。

FORTRANの発展③ 型宣言の導入 1962年、FORTRANⅣ発表→型宣言を導入 ＜暗黙の型宣言＞ 1234567890 -------------------------------------------- REAL A,B INTEGER J A=3.5 B=1.5 J=(A+B)/2 WRITE(6,100) A,B,J 100 FORMAT(2F4.1,I3) STOP END 1234567890 ------------------------------------------ A=3.5　　　これもOK B=1.5 J=(A+B)/2 WRITE(6,100) A,B,J 100 FORMAT(2F4.1,I3) STOP END I,J,K,･･･,Nで始まる変数：整数型 それ以外　　　　　　　　　 ：実数型 ＜暗黙の型宣言＞

補足 FORMAT文について ＜実行結果＞ F4.1 ４は出力桁数 １は小数点以下の桁数 I3 ３は出力桁数 1234567890 -------------------------------------------------- A=3.5 B=1.5 J=(A+B)/2 WRITE(6,100) A,B,J 100 FORMAT(2F4.1,I3) STOP END 12345678901 -------------------------- 3. 5 1. 5 2 ＜実行結果＞ F4.1　４は出力桁数　１は小数点以下の桁数 I3　　　３は出力桁数 　６：装置番号（標準出力）→プリンタやCRT画面 　100：100のFORMAT文に従って出力するという意味 　FORMAT文：出力の書式を指定する文 　F：実数型の出力　I:整数型の出力

分岐処理の記述の発展① ＩＦ と GO TO の世界 分岐処理の表現(初期) プログラムの見通しが良くない！ テストの得点を入力し、５０点以上なら「合格」、５０点未満なら「不合格」と表示するプログラム ＩＦ と GO TO の世界 INTEGER TEN READ(5,*) TEN IF(TEN.GE.50) GO TO 10 WRITE(6,*) ‘不合格’ GO TO 20 10 WRITE(6,*) ‘合格’ 20 STOP END 始め Tenの入力 Ten≧50 No Yes ‘合格’と表示 ‘不合格’と表示 終り プログラムの見通しが良くない！

分岐処理の記述の発展② 分岐処理の表現(改良) 無駄な文番号を排除→ GO TO文を排除 テストの得点を入力し、５０点以上なら「合格」、５０点未満なら「不合格」と表示するプログラム ＩＦ THEN～ ELSE～ END IF 文の導入 INTEGER TEN READ(5,*) TEN IF(TEN.GE.50) THEN WRITE(6,*) ‘合格’ ELSE WRITE(6,*) ‘不合格’ END IF STOP END 始め Tenの入力 Ten≧50 No Yes ‘合格’と表示 ‘不合格’と表示 終り 無駄な文番号を排除→　GO TO文を排除

参考 GO TO文単独での使用例 原則はIF文との併用 ＜あまりよくない例＞ 例）２数の四則演算結果の表示 和だけにすると・・・ A=1.5 B=2.3 WA=A+B GO TO 10 SA=A-B SEKI=A*B SHO=A/B WRITE(6,*) A,B,WA,SA,SEKI,SHO 10 WRITE(6,*) A,B,WA STOP END A=1.5 B=2.3 WA=A+B SA=A-B SEKI=A*B SHO=A/B WRITE(6,*) A,B,WA,SA,SEKI,SHO STOP END 例）２数の四則演算結果の表示 和だけにすると・・・ GO TO文で不要部分を排除

タートルグラフィックス 正方形完成！ FORWARD 100 RIGHT 90 FORWARD 100 RIGHT 90 REPEAT 4 [FORWARD 100 RIGHT 90] ＜一度に正方形を描ける＞

プログラム（アルゴリズム）の基本構造 連接 分岐 繰り返し 条件が成立すれば処理A、そうでなければ処理Bを実行 Yes No 処理A 処理B 処理C 条件 処理A Yes No 条件が成立すれば処理A、そうでなければ処理Bを実行 条件が成立している間は、処理Aを繰り返し実行 処理A,B,Cを順に処理

モジュールの再利用（問題点） 問題 学生のテスト成績を読み込み成績順に表示する。 問題　学生のテスト成績を読み込み成績順に表示する。 テストの得点だけではなく、学生の氏名も読み込むように拡張すると・・・。 　修正に手間がかかる。 　既存部分はいじらず、新たに必要になった部分のみを加えるような修正はできないか→差分プログラムの徹底 Integer Tokuten(200) Character Shimei(200) CALL ReadData(Tokuten,Shimei) CALL SORT(Tokuten,Shimei) CALL Display(Tokuten,Shimei) サブルーチンの書き直しが必要 サブルーチン内部の理解が必要