レポート抜粋（6/29）

＜テーマ＞

本日の講義で、あなたが最も興味を持った点はどのような点ですか？講義の全体的な感想と共に、できる限り具体的に、200字～400字程度で記述して下さい。

Ⅰ．構造化プログラミングについて

Ａ．GO TO文の魔力

今回の講義で感じたことは、GOTO文の魅力は物凄いということです。一行ずつしか編集できないというのは、今の環境からすると、考えられないくらい大変だったと思います。しかし、プログラムの間に入れるだけで、処理したい場所に飛ぶ事が出来るGOTO文は、簡単に理解する事が出来るほどわかりやすいものなので、プログラムを記述する段階では非常に有効な物であったと思います。しかしその反面、バグの修正が大変になる事も想像出来るので、正に先生が、おっしゃっていたように魔力という言葉が当てはまると思いました。
今日の授業では、GO TO文はとても魅力があるものだと思いました。GOTO文を使うとどんなプログラムも記述できて、便利だけれども後からは読みにくいということでした。ですがこの文の良さを生かすとすれば、プログラムを書く人のメモのようなものになるのではと思いました。短いプログラムを思うままGOTOで書いておいてプログラムとして使うときには構造化する。GOTO文でも実行してみることはできるから、とりあえずやってみるといった時には便利なのではないか。さほど学習しなくても書けることが自分には適していると思いました。
私が今回の講義で興味を持ったのは、構造化プログラミングの中のGOTO文の魔力です。私は、プログラミングは絶対に順番どおりに作成しないといけないものだと思っていました。しかし、作成している途中で処理を入れ忘れた！！という事があっても、後から付け足せばその中間の処理も行えるのだと驚きました。
今回の講義で興味を持ったのが、ＧＯＴＯ文の魔力についてです。処理Ａ，Ｂの実行の前に処理Ｃを挿入しなければいけない時に、当時の編集環境の中では手間がかかっていたが、ＧＯＴＯを用いれば作成時の順番を維持することができ、なおかつ開発効率が上がると知り、当時としては画期的だと思った。これがあれば、いちいち手間をかける時間も短縮できると思った。
　しかしとても読みにくいことが分かった。２つ、３つぐらいの処理ならＧＯＴＯ文を使ってもいいと思うが、処理が多ければ多いほどミスを誘発しやすいと思うし、処理の順番通りに記述した方が後から見たときでも読みやすい。やはり処理は順序通りにするのが、一番見やすい方法だと感じた。

Ｂ．構造化プログラミングが出てくる背景（必然性）について

構造化プログラミング（運動）が始まるに至るまでの流れに興味を持ちました。ＧＯＴＯ文は作成時の順番を維持でき、後で修正を加える際とても容易にできることが魅力ですが、しかし読みにくく混乱招いてしまいかねない危険性があると感じました。確かにもとの形にそのまま付け加えて修正できたらとても楽だとは思いますが、今後使い続けるものとしては難しいものがあります。それに、自分の中で処理するならまだ整理整頓されていなくても何とかなりますが、（他の）人が見たら処理の順番どおりに記述していないと、なにがなんだかわかりませんし、わかったとしてもとても時間がかかるでしょう。ですから、処理の順番どおりに基本構造をしっかりと立てるということはとても大切なことなんだなと実感しました。
構造化プログラミングの開発までにいろいろな難点が出ていたことが今回のことでわかりました。当時の編集作業では編集するところを見つけてから、そこに新たなプログラムを入れる作業をしていたが、GOTO文を利用すれば、いままで編集しづらかったところに入れる必要がなくなったことによるプログラム開発の効率アップ、しかし、それに伴う読みにくい点でミスが多発すること、それを補うために構造化プログラミングが出てきたこと、私はいままでそういうところを気づかずにプログラミングをしていましたが、実際にそういう作業をしなければならない環境だった場合、プログラミングは難しいものと思っていたかも知れません。

Ｃ．ダイクストラの主張・構造化定理

今回興味を持ったのはダイグストラの主張と構造化プログラミングです。一つの入り口と一つの出口しか持たないアルゴリズムは、「連接」、「分岐」、「繰り返し」の基本構造をつなげることで記述できるが、このように定理化できたダイグストラはすごい。 GOTO文と違い、作る分にも見る分にもわかりやすく、またその利点があるが故に「プログラムが読みやすい」、フローチャートによる設計が可能」「ミスが少なくなる」等の新たな利点を生み出したことからも、構造化プログラミングはそれからの主流となるのには十分だったと思う。
今日の講義で興味を持ったのは、構造化定理についてです。
　いろんな言語を使ってきましたが、どちらかというと「構造化プログラミング」のほうがやってる時間が長く「構造化」しているものが普通だと思っていましたが、改めて考えてみると、非常に効率のよいモノだと思った。
　構造化によって無駄な処理が無くなれば、見やすくなるし再利用もしやすい。また、メインルーチンとサブルーチンを分けることでやっていることを明確にでき、一つのルーチンだけではやりづらかったことがやりやすくなる。膨大な量の処理のときだけ、「連接」「分岐」「繰り返し」が分かりやすいと思っていたが、簡便な処理のとき時も見やすく使いやすくなって良いものだと思った。
　ただ、やはりサブルーチンを作ると常にサブルーチンの状態が把握できていなければならず、把握し切れてないばかりにエラーが出てしまったりして初心者にはつらい部分もあるのかもしれないと思った。
今回の講義を受け、もっとも興味が持てたのは、構造化プログラミングです。その起源となる主張をした「ダイクストラの主張」に惹かれました。構造化定理をダイクストラが主張したことで、プログラミングがより理解しやすくなったのだから、以前学んだプログラミングを少しだけだが理解できたのは、ダイクストラのおかげであると思いました。時代とともに物事が発展していくのは当然であるという発想があるが、起源は当然あり、（誰かが）始めなければ始まらないが、ダイクストラの主張が以前までのプログラミングに変化を起こした。変化をつけることができる人物は偉大であると改めて思い知らされました。今後もより簡単なプログラミングを目指していると思うと終わりのないことであると感じます。
今日の講義を聞いて私は「ダイクストラの主張」に興味を持ちました。確かにGＯＴＯ文は当時の編集環境からみれば大変便利なものに思えますが、読みにくかったりミスを誘発するようでは作業効率がよくても意味がないと思います。ダイクストラのGOTO文は必要ないという主張により構造化プログラミング運動が始まり無駄な処理が少なくなってプログラミング開発の効率が上がったことに対しダイクストラはプログラミング開発の「救世主」といえると思いました。
今回の講義で自分が一番興味を持った点は、構造化定理に関してです。「1つの入り口と1つの出口を持つようなアルゴリズムは、「連接」、「分岐」、「繰り返し」の基本構造を（処理の順に）つなげることで記述できる」ということをダイクストラが証明したことにより、より簡潔で見やすいものにしてくれたということ。それにより現在パソコンを使ってプログラミングを学習している私たちはダイクストラのような過去の偉人たちの功績から多大な恩恵を受けているという背景が実感できました。

Ｄ．構造化プログラミングのメリット

僕が今回の講義でもっとも興味を持ったのは、構造化プログラミングのメリットです。プログラミングにおいて一番といって良いほど重要だと思うのはプログラムが読みやすいという点だと思います。プログラムにエラーがあっても分かりづらかったらエラーを解決しづらいという点もあるし、バグの少ないプログラムの開発が可能というのが魅力的です。
　１９６８年にダイクストラが構造化定理を証明したのがすごいと思いました。このころからわかりやすいプログラミングを考えるという意識のおかげで、現在のようにパーソナル・コンピュータが発展したのだと思います。
今回の講義で興味をもったところは、構造化プログラミングの所でGOTO文ではわかりづらかった処理の順番を基本構造だけでつないでも記述できわかりやすいプログラムを書くことができるという部分です。GOTO文では作成の順番は維持できるが処理の順番がバラバラなので読みにくいという欠点があったが、構造化によりバグの少ないプログラムの開発が可能になったり、フローチャートによるプログラム設計が可能なるなどプログラミング開発の向上の原因になったことはとてもすごいことだと思います。そしてモジュール化もプログラミングがわかりやすくなった要因で、FORTRAN、C言語、Javaなど色々な言語で用いられていることにも驚きました。

Ｅ．モジュール化

この講義で最も興味を持ったことはプログラムのモジュール化です。メインルーチンとサブルーチン二つに分けて書く。よく構造化されていると思う。メインルーチンで基本構造、サブルーチンでいろいろ詳細をまたつけたしを。プログラムの基本構造がわかりやすくなり見やすくなっている。実際プログラミングというものを知らないころ、アクティブパールで作られたプログラムを見たことがあるがどこがどの処理かということを知識が無くてもなんとなく理解することができました。
今回の講義で最も興味を持ったのは、プログラムの構造化です。特にその構造化プログラミングの最終的な主張であるプログラムのモジュール化に興味を持ちました。プログラムの基本構造はメインルーチンで記述し、ひとまとまりの処理の内容はモジュール（サブルーチン）で記述することによって、プログラムの基本構造がわかりやすくなります。基本構造と処理の詳細を分けて記述するということでプログラム全体の見通しがよくなり、バグや改変の時にわかりやすくなると思います。モジュール化しておくことは開発効率の向上につながるのでとても重要なことだと感じました。
今回興味を持ったのは、構造化プログラミングとモジュールについてです。連接・分岐・繰り返しを処理の順どおりに繋げて表現することは、プログラミングの見通しを良くするだけでなく、プログラミングの初心者にとっても処理を論理的に理解しやすいという点で非常に重要なことだと思いました。またモジュールは、たくさんあるファイルを一つのフォルダにまとめた形で（メインルーチンに）表示したようで、とてもわかりやすい仕組みだと思いました。

Ｆ．ソフトウェア危機

今回興味を持ったのは、ソフトウェアの危機についてである。構造化プログラミングが進み、ソフトウェアの生産が伸びたのは良いことだが、既存のソフトウェアの再利用性については著しく伸び悩んだ。それに伴い、需要がグングン伸び、生産が追いつかないということもあり、ソフトウェアの危機とも言われた。一時期は、かなりの製作者を必要とするくらいのものだという。ここでは、使う方は天国・作る方は地獄といわれていたというのが、内容を聞くことにより理解できた。
確かに、今まではソフトウェアを利用する方（使う方）だったので、何も感じずすんなりと進めることが出来ていた。作る方になると膨大な制作時間と力が必要となる。大学に入り、作るということをやってきたからこそ、その大変さも身にしみるくらいに感じる。やはりこれから注目しなければいけない点としては、再利用性に関しての点だろう。
私が最も興味を持ったのは、ソフトウェア危機についてです。 GUI環境のせいで使う方は楽になっても、作る側は地獄を見るというのがわかるような気がしました。プログラミングを習いましたが、ちょっとしたプログラムを作るだけでそれなりの時間と労力を必要とするのに、大掛かりなプログラミングを行うとすればとんでもない時間と労力を必要とするのがよくわかります。一つのプログラムを作るのにどれだけの人数が必要なのかは知りませんが、きっと非常に過酷な状況で作っているのではないかと思いました。
私が興味を持ったのはソフトウェア危機です。ソフトウェアの需要が増すことはとても大切なことだと思います。ソフトウェアの生産がおいつかないということも、生産側にしてもこれはいいことだと感じました。今のやり方よりもっと効率の良い（生産の早い）方法を考えるという事を思いました。これはソフトウェアの向上になると思います。
今回の講義で私が最も興味を持ったのは、ソフトウェア危機についてです。この言葉は聞いたことがありましたが、実際にどのような状況のことをいうのかよく理解していませんでした。ソフトウェアの需要が増えそれにソフトウェアの生産が追いつかないということでしたが、言い換えると、生産が追いつかないほどにどんどん普及し、コンピュータ社会が確実に拡がっているということの現れではないのでしょうか。このような状況は確かにソフトウェアを生産する側にとっては大変な状況でしょうが、注目されることによって、より効率の良い開発形態はどういうものか？ということに目をつけ、さらに技術が発展していくのであれば、それは結果的に良いことになるのではないでしょうか。

Ｇ．その後の展開に関心

構造化プログラミングにより、ソフトウェアの生産性が向上したのに、実際のソフトウェアの需要増には追いつけない欠陥が出てきてしまった。この点を、オブジェクト指向言語はどのように改善しているのか、とても興味があります。
「使う方は天国、作る方は地獄」という言葉に感心し、（その状況が）オブジェクト指向によってどのように解決していったのか、気になり来週の講義が楽しみです。
（プログラムのモジュール化によって開発効率が上がった。）しかし、モジュールの問題もあってソフトウェア生産が追いつかなくない状態になってしまったので、さらに効率のいいプログラム開発として、その後のオブジェクト指向プログラミングのどのような点がモジュール化に比べて効率的なのかも興味を持った。

Ⅱ．その他

Ａ．変数の型の必要性

今日は変数の型の必要性に興味を持ちました。僕は変数はあまり必要ないように思っていました。一回データを格納しなくてもそのままでいいと思っていました。しかし、読みやすさというものが大事なんだと思いました。ただ実行できても見る側が分かりやすいプログラミングをするのは大事であることが分かりました。プログラミングをやったとき変数の理解が正直難しかったのですが、これで変数の型の必要性が分かりました。
今回の講義で、各変数型の使い方によって、ただの足し算でも全く違った結果がでることが分かった。文字列型と整数型の例では、整数型はちゃんと計算をしてくれるのに対し、文字数型では数字を文字として置き換えられてしまうので、数字の後に数字が足されてしまう結果になってしまう。型がどれだけ重要なのかが分かったような気がします。

Ｂ．C言語とJava言語の違い

私の興味の持ったものは、C言語のif文中の比較です。Javaだけやっていたのなら、”0”の区別でif文の分岐処理をするとは、予想がつかなかったからです。if文を使うときに論理型変数を用いずに、分岐処理を行うことは、プログラミング初心者にとってはわかりやすいと思いますが、ある程度javaのプログラミングを学んだものにとっては、記述方法はわかりにくいと思いました。JavaがC言語より多く使われているのは、互換性の問題だけだと思っていたのですが、記述方法にも大きな差があることがわかり、やはりjavaの方が、よりわかり作った人以外の人が見ても、わかりやすいプログラムの記述方法だと思いました。
今日の講義では複数の文法について取り上げられていましたが、それぞれの文章の問題点、応用点についての説明に興味を持ちました。c++ではIf（a＝０）（前後省略）を実行すると０以外の整数がtrue、０はfalseとして扱われるためコンパイルエラーにはならず、やはりここは論理型と整数型を厳密に区別することで回避できるが、逆にこれを利用して論理型変数を用いなくても処理することができるプログラムもあるというのを知った。

Ｃ．（初心者用プログラミング言語）ドリトル

今回の講義でドリトルに最も興味を持ったので調べてみました。ドリトルとは、やることが少ない(簡単にプログラムを書ける)という意味で付けられた名前でした。そのとおりで記述方法は簡単で、初心者でも簡単に使いこなせるものでした。グラフィックスの作成や音楽演奏などもできます。一番の魅力は日本語でソースを作れるというところだと思います。これならミス入力も見つけやすいのではないかと思いました。変数・関数を使う数式は小学生は習っていないはずなので使えないと思ったけど、それ以外なら小学生からでも楽しんで学べるものだと思いました。
私は、「LOGOは初学者でも遊び感覚で学べるからいい」と先週のレポートで書いたのですが、他の人のレポートを見てみてLOGOが児童教育用言語であるということを忘れていました。考えてみると、いくら簡単なLOGOとはいえ英語で記述するわけで、日本人の子どもには難しい気もします。それを解決してくれたドリトルの存在を明らかにした人に感動しました。ドリトルについてもう少し詳しく学んでみたいと思いました。
僕は一橋大学の兼宗先生のドリトルに興味を持ちました。中学生・高校生にプログラミングを教えるということは、なんとなくですが解りますが、小学生にプログラミングを教えられるくらい簡単なものなのか不思議に思います。パソコンは進化してることは確かですが、僕の考えはプログラミングは小学生に教えられるくらい簡単なものではない様な気がします。ましてや、学校教育として強制的に教えるものではなく、興味を持ったものが勉強するものだと思っているからです。

Ｄ．FORTRANの多分岐・繰り返し処理記述の発展

私が今日の講義で一番関心を持った点は多分岐処理の記述・発展のところです。やはり原型のGO TO文では所定の文番号に移動するので見通しが良くないし、パッと見あまりよくわかりません。しかし、発展のCASE文では細かい指定ができるし、簡略化されていて見やすいので、もし私が使うならCASE文を使うと思います。あと参考の「CASE文には文字列も使える」ということは、これなら多様なケースに使えて、何を作ろうかという楽しみも増えるのですごくおもしろいと思いました。
今回の講義で興味を持ったところは前回と変わりませんがFORTRANが進化し続けているという点です。GO TO文の記述の原型はとても面倒なものでしたが、CASEを使うことにより、とても見易くて扱いやすくなった。そしてDO WHILE文の導入。FORTRAN90の時点で以前より大幅に使いやすくなったように感じました。スライドでJava言語のwhile文と同等と書いておりソースを見てみると、去年自分もこんなの使ったなぁと思いながら講義を受けていました。

Ｅ．質問

ソフトウエアの需要が生産を超えていると言うことは、もしかしたら色々な人が新しいソフトウエアを開発していく時代になるのではないでしょうか？
現在学んでいるjava言語は、構造化プログラミングの再利用性の悪さという欠点を踏まえて作られているのだと知った。普段何気なくクラスを作ってプログラムの拡張をしていたりするが、その当時は見通しのよさという点に焦点を当てて改善をしていたが、同時に差分プログラムでプログラムを拡張するという考え方がなかったのだろうかと思った。
GUI環境について、なぜ「作る方は地獄」なのか、それまでのプログラミングとどれくらい作業に違いがあるのか、もっと詳しく知りたいので、ぜひ講義で取り上げて欲しいです。

全般的な感想

今回の講義で、前回のレポートの解説が今回はとてもわかりやすく、自分とは違う意見の人のレポートのこともくわしく知れたので良かったです。
前回のレポートを読んでですが、論争を振り返っての意見で、このような形で論争を行えたのはとても良かったという意見がありますが、私もそう思います。実際に理解が先か楽しさが先かで意見がわかれ、お互いを主張して、そして指摘しあう。とても良い意見交換が行えていたと思います。今後もこういう論争があれば良いなと思っています。
今日の講義の感想というか、最近の講義には４月の講義開始当初よりも参加している生徒が少ないと思います。単位取得をあきらめた人も中にはいるかもしれませんが、家などで講義スライドをみて小レポートを提出している人もいるようです。いくらメールで出席代わりの小レポートを出すとはいえ、学校にこないで出席扱いになるなら、きちんと講義を聴いている自分たちに不公平ではないかと思います。何かしらの対策をしてもらいたいのですが・・・。

前回のレポートへのコメント

FORTRANの発展③（6/22レポート抜粋『Ⅰ．FORTRANの発展－Ｅ．型宣言の導入時の経緯について－「厳密文法 vs 自由文法」論争のポイント!?』１）の「慣れてしまうと他の言語に移行しがたくしてしまう原因が潜んでいる」　という文に感銘をいだきました。慣れ親しんだ言語があると、他の言語が使いにくいという声を聞いたことがあるので、「確かにそうだな」と思えました。
LOGOについて感想を書かれている文章（6/22レポート抜粋『Ⅱ．LOGOについて－F．疑問１』）を読み、感じたことがあります。彼は言語が日本語になればもっとよくなると主張していますが、私はそうは思いません。確かに、言語が日本語ならば日本人にとってはわかりやすいし、理解も今の数倍以上になるかもしれません。しかし、英語はローマ字であり、日本語はひらがなやカタカナ、漢字といったたくさんの表記方法があります。これによって、ソフトが重くなってしまったりして、CPUの負担が大きくなってしまうので、私は彼とは逆の考え方をしました。
LOGOについての感想は、レポートを読み、私も思ったことですが、「アメリカや英語圏の子供たちなら良いですが、日本の子供には小さい頃から英語を使ってやるというのは少し厳しい。LOGOを日本語で打てるようになればいい。」という意見に共感をもてました。