比較プログラム言語論 平成１６年６月３０日 森田 彦 レポート（6/23）総括 ＜ テーマ ＞ 本日の講義で、あなたが最も興味を持った点はどのような点で すか？講義の全体的な感想と共に、できる限り具体的に、200 字～400字程度で記述して下さい。 ＜項目＞ 一ヶ月の討論を終えて・・・ 討論の到達点について 理解が先か？楽しさが先か？ LOGO言語・タートルグラフィックスについて FORTRANの型宣言について FORTRANのサブルーチンについて FORTRANの制御構造の発展について 一ヶ月の討論を終えて・・・① 都合のいいプログラミング言語が欲しい迷える厳密文法派です。 たくさん意見をもらえて嬉しかったです。どうもありがとうございます。 実はないと分かっていつつ「両方のいいところを取った都合のいいプ ログラミング言語」が欲しいと言ったのですが（あれこれ求めた結果、 多くの言語があるという答えが初めに出ましたから……ないものねだ りです）、無責任に出したこの問いかけが、今回の議論における結論 のひとつを導いた、きっかけの一端になれたようで幸いです。 （略）今回自由文法として取り上げられていたBASICは学校教育で 使われた言語でしたが、厳密文法のDelphiも同じように学校教育で 用いられていたと記憶しています。これはつまり、教育現場でも自由 であるべきか厳密であるべきか結論が出ないということで、・・・（略） ただ、都合のいいプログラミング言語の出現を諦めたわけではあり ません（笑）。オブジェクト指向は人間の認識や思考によりマッチした 考え方だと言われていますが、この「人間にマッチした」を突き詰めて いくといずれ、人間の適度な自由さと厳密さを兼ね備えるようになる のではないかと思います。どれだけ時間がかかるのか分かりません が、プログラミング言語の発展に注目していたいです。 一ヶ月の討論を終えて・・・② いろんな人のレポートを見て、こんな考え方や方法もあるのか、と毎 回驚いています。みんな考えていることが違うことが分かって、とても 面白いと思いました。 自由文法派と厳密派の討論もそうですが、一 人で悩んでいても、ある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の問題がなくなった のです。 質問 1. 2. 3. まず、「WRITE(6,100)」という処理で、WRITEはわかるの ですが、次にある6,100というのは何をやっているのでしょ うか？ また、IF文によって「GO TO」というのが削除された のはわかったのですが、IF文代替前の「GO TO」はどうい う処理なのでしょうか？ FORTRANの整数型の変数が、ｉ～ｎまで、全部で６つまで しか使えないのでは変数が増えていって６以上の変数が 必要になった場合困るのではないかと思いました。 「LOGO」の特徴の「コンピュータとの対話形式でプログラミ ングできる」というのはどういったものなのかもすごく気にな りました。 構造化プログラミングとは？ 提唱の背景－GOTO文の魔力 ダイクストラの主張 構造化のメリット 言語仕様への影響 プログラムのモジュール化へ GOTO文の魔力 ２．処理Bの前にCが必要に →処理Cを挿入 １．処理A,Bの実行 処理A 処理A GOTO文を用いると･･･ 処理A 当時の編集 環境では手 間がかかる。 処理C 処理B 処理B ３．完成 処理C 処理B 処理A 処理B 作成時の順番を維持できる→（当 時としては）開発効率が上がる。 しかし、読みにくい。→ミスを誘発する。 処理C 処理の順番通りに記述した方が読みや すい。 ダイクストラの主張 構造化定理:1つの入り口と1つの出口を持つよう なアルゴリズムは、「連接」、「分岐」、「繰り返し」 の基本構造を（処理の順に）つなげることで記述 できる。→ダイクストラが証明 あらゆる処理（アルゴリズム）はGOTO文は必要 ない。 → 1968年 Dijkstraが主張。→構造化プログラミ ング（運動）の始まり。 分かりやすいプログラムを書こう！ 構造化プログラミングのメリット 処理の順番に記述されるので、プログラムが読 みやすい。 フローチャートによるプログラム設計が可能 バグの少ないプログラムの開発が可能 構造化により、無駄な処理が少なくなる。 プログラム開発の効率が向上する。 言語仕様への影響 プログラミング言語は、連接、分岐、繰り返しを表現する機能がなけ ればならない。 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字程度で記述して下さい。 なお、上の記述を行った上で、（いつも通り）講義の感想 や質問等を付加しても結構です。 提出先：[email protected] 件名：「学籍番号（半角）+半角空白＋氏名」を記入し て下さい。 例） s02xxx 学院太郎 HPに自由掲示板を開設（6/24） 各自活用して下さい。 FORTRANの発展② 副プログラムの導入 1958年FORTRANⅡ発表→副プログラム（サブ ルーチン）の導入 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 SUBROUTINE HEIKIN(A,B,C) C=(A+B)/2 RETURN 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文について 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:整数型の出力 分岐処理の記述の発展① 分岐処理の表現(初期) テストの得点を入力し、５０点以上な ら「合格」、５０点未満なら「不合格」と 表示するプログラム 始め Tenの入力 Ten≧50 No Yes ‘合格’と表示 終り ‘不合格’と表示 ＩＦ と 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 ‘合格’と表示 終り ‘不合格’と表示 ＩＦ THEN～ ELSE～ END IF 文 の導入 INTEGER TEN READ(5,*) TEN IF(TEN.GE.50) THEN WRITE(6,*) ‘合格’ ELSE WRITE(6,*) ‘不合格’ END IF STOP END 無駄な文番号を排除→ GO TO文を排除 参考 GO TO文単独での使用例 原則はIF文との併用 ＜あまりよくない例＞ A=1.5 A=1.5 例）２数の四則演算 B=2.3 B=2.3 結果の表示 WA=A+B GO TO 10 WA=A+B SA=A-B 和だけにすると・・・ SA=A-B GO TO文で不要 部分を排除 SEKI=A*B SEKI=A*B SHO=A/B SHO=A/B WRITE(6,*) A,B,WA,SA,SEKI,SHO WRITE(6,*) A,B,WA,SA,SEKI,SHO STOP END 10 WRITE(6,*) A,B,WA STOP END タートルグラフィックス FORWARD 100 RIGHT 90 FORWARD 100 RIGHT 90 FORWARD 100 RIGHT 90 FORWARD 100 RIGHT 90 正方形完成！ REPEAT 4 [FORWARD 100 RIGHT 90] ＜一度に正方形を描ける＞ プログラム（アルゴリズム）の基本構造 連接 処理A 処理B 処理C 処理A,B,Cを 順に処理 分岐 条件 繰り返し No 条件 Yes 処理A 処理B 条件が成立すれば処 理A、そうでなければ 処理Bを実行 No Yes 処理A 条件が成立している間は、 処理Aを繰り返し実行 モジュールの再利用（問題点） 問題 学生のテスト成績を読み込み成績順に表示する。 テストの得点だけではなく、学生の氏名も読み込むように拡 張すると・・・。 修正に手間がかかる。 Integer Tokuten(200) 既存部分はいじらず、新たに必要になっ た部分のみを加えるような修正はできない か→差分プログラムの徹底 Character Shimei(200) CALL ReadData(Tokuten,Shimei) CALL SORT(Tokuten,Shimei) CALL Display(Tokuten,Shimei) サブルーチンの書き直しが 必要 サブルーチン内部の理解 が必要
© Copyright 2024 ExpyDoc
