レポート抜粋（６月３０日）

＜テーマ＞

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

＜LOGO言語・タートルグラフィックスについて＞

LOGO言語が大変興味深いです。小学生のときにこれを教えてもらったら、多分ものすごい勢いで図形の勉強をしたと思うんですが……図形と命令の関係性の秘密が分かったとき、きっととても嬉しくなったと思います。機会がなかったのが残念です。もし自分に子供ができたら、一つのおもちゃとしてLOGO言語を教えてあげたいです。
LOGO言語について、子どもにも理解できる言語ならば、簡単に身につくのだから、理解をすることで、楽しさが出てくるのではないかと思いました。（略）理解することで楽しさを感じるというのと、楽しいから理解度が上がるという場合のどちらにもこの言語は適していると思います。

＜GO TO文の魔力について＞

今回私がもっとも興味を持ったものは、GOTO文の魔力である。実際私は大学二年目の講義でプログラミングを学んだが、やはり構造の流れがつかめないと自らがプログラムをしていてもまったく理解できないときがあった。そのためGOTO文は初めてプログラムをする人には難敵になる。よってダイクストラの主張は正しく、GOTO文は必要ないというより使ってはいけないのではないか。GOTO文は構造化定理へたどり着くまでの過程、または模索段階として考えた方が良いと私は考える。
今日の講義で一番興味を持ったのはGOTO文です。一行ずつしか編集できない環境というのは、今の環境になじんでしまった自分からすると、考えられないくらい大変だったと思います。しかしプログラムの間に入れるだけで、処理したい場所に飛ぶ事が出来るGOTO文は、本日の講義で少し聞いただけで、簡単に理解する事が出来るほどわかりやすいものなので、プログラムを記述する段階では非常に有用な物であった事がよく分かります。しかし非常に魅力的である反面、冷静に考えてみると、何千行も書いた後で見直した時や、他の人が見た場合に、あっちこっちへ飛び回ってプログラムを見なければならない事になり、非常に見づらく、バグの補正が大変になる事も想像出来るので、正に「魔力」という言葉がピッタリの文だと思いました。その後「連接」、「分岐」、「繰り返し」を処理の順につなげるだけで処理するという、構造化定理が登場しましたが、記述する段階での分かりやすさだけを取り上げれば、やはりGOTO文にはかなわないと思うので、数十行程度のプログラムを練習する初心者にとっては今でも有用な文なのではないかと思います。
GOTO文単独でのあまりよくない例というのがとても面白いです。「書いたのに使わないの？　なぜ？　いらないなら消せばいいのに、分かりづらいし」と思ったら、消せなかったんですね……。良くないとはいえ、それなら納得です。消すのも大変な開発環境とは、現在のWindows環境に慣れた私にとって、かなり驚異でした。JBuilderが重過ぎるとか何とかという悩みは全くどうでもいいような気がしてきました。「消せないからGOTO文」というのはまるで職人の世界で、重たくてもプログラムの削除ができないよりはずっとましです。昔は本当に大変だったのですね。私たちは高速でよくできたマシンと成熟したJava言語を与えられて、とても恵まれています。

＜構造化定理について＞

ダイクストラが証明した「連接」、「分岐」、「繰り返し」の基本構造を処理の順につなげることで記述できるという考え方は、分かりやすいプログラミングを書く上で、重要なものだと感じました。この証明によって、構造化プログラミング運動が始まり、プログラミングが読みやすくなり、バグの少ないプログラミングの開発が可能になったということで、ダイクストラは非常に大きな証明をしたことになるので感心しました。こういう人達がいたからこそ、今のプログラミングがあるのだと思います。
今日の講義で印象深かったのはダイクストラの主張です。　それまで、GOTO文を使っていたスパゲッティプログラムになっていた状況を、構造化定理という『1つの入り口と1つの出口を持つようなアルゴリズムは、「連接」、「分岐」、「繰り返し」の基本構造を（処理の順に）つなげることで記述できる』という証明により打破し、プログラムの開発効率を上げたことがとてもすごいことだと思いました。　
今回最も印象に残ったのは、GO TO文と構造化定理についてです。GO TO文とはある処理の前に必要な処理をあとから付け足し、GO TOを使うことによって処理する順番を指定させるもので、いってみれば処理順番を歪曲させるというものに対し、構造化定理は現在使われているIFなどを用いて処理順番どおりに記述していくものでしたが、今思えば現在普通だと思っているものが何故当時GO TO文を使っていた人たちは気づかなかったのかと思いました。はじめからGO TO文ではなく構造化定理のほうが普及していたならばプログラミングはより発展していたのではないか（厳しく言ってしまえばGO TO文が普及していた時間は無駄だったのではないか）と思いました。

＜構造化プログラミングの分かりやすさについて＞

構造化プログラミングのフローチャートは、GOTO文のフローチャートに比べてなんと読みやすいことか。去年プログラミング言語の最初のほうでアルゴリズムのフローチャートの見方を習ったときも、無駄の無い作りだなあと感心していましたが、構造化の前はこんなに読みにくかったんですね。GOTO文は思いつくまま書いて後で処理を繋げるもので、行き当たりばったりな感じです。対して構造化プログラミングは、実際にコンピュータに記述する前から、ある程度全体の流れを決めなければいけないものです。効率的です。読みやすいです。でも、設計段階からはっきりとした最終目標を持っていないと作れません。
正直GO TO文ちょっといいなと思いましたが、後に重大な欠点があることも思いしらされました。作るときには「楽」なのかもしれませんが、後の拡張や再利用性を損ない「使い捨てプログラム」になってしまう危険があることと「見易さ」の大切さを知りました。以前はＴＡＢキーで文をそろえることが面倒だと思っていましたが後につながる重要なことだなと考えを改めました。

＜プログラム開発効率の向上について＞

今日の講義で最も興味を持った点は、構造化プログラミングによるプログラム開発効率の向上です。バグの少ないプログラムの開発が可能で、無駄な処理が少なくなるのですから、すごいことだと思いました。これからも、より効率の良いプログラム開発形態が開発されると思います。しかし、そのときに、自分たちが学んだプログラミングの知識や技術が使い物にならなくなってしまうのではないかとも思います。また、いつかは専門的な知識がいらないプログラミングも開発されるような気がしました。
構造化プログラミングというものをはじめて知りました。その概要を知ったことで、この構造化プログラミングがソフトウェアの生産向上につながったというのは、よく理解できました。(略)構造化することでプログラミング作成の際の可能性が広がるように思いました。メインルーチン、サブルーチン・・・のように、まず全体を把握し、それを細かく書き表していく。プログラムを書くにはこのような全体の把握や、わかりやすくしようとする思い、構造化・単純化していくことが必要ではないかと思います。しかしここまで聞いた後に「再利用性について十分な向上が得られなかった」と、聞かされてしまいましたので・・・本当に心から「すばらしいプログラム」と称されるものは現在ないのだなぁ、いつ誰が開発するのか、それとも今後出ることはないのか・・・などしんみり考えてしまいました。

＜プログラムのモジュール化について＞

私はプログラムのモジュール化までの経緯に興味を持ちました。このモジュール化は構造化プログラミングの根底にある考え方であり、プログラムを利用していく上で基本となる考え方なので、それが出来上がるまでの経緯を知ることはプログラミングの始まりを理解することに繋がると感じたからです。モジュール化が進むにつれてより高度で無駄の無い処理が可能になり、プログラム開発効率が向上=プログラム技術が向上した。最初はGO TOのみで行われていた処理が「連結」「分岐」「繰り返し」の基本構造の定義の登場によりその姿を失い、今度はその基本構造を処理順に並び替えるモジュールが発生した。最初は単純だったプログラムも進化につれてよりコンパクトで高度なものとなり現在もその繰り返しを続けている…この進化は果ての無いもののように感じます。
今日の講義で興味を持ったところは、プログラムのモジュール化のところです。プログラムはモジュールの組み合わせによって表現できるということ。プログラムの基本構造は、モジュールを処理の順番につなげて表現し、個々の処理の詳細はモジュール内部で記述するということで、プログラムの基本構造が分かりやすくなるとあったからです。複雑なものは見やすくないと思うので、見やすくなるということは良いと思いました。

＜ソフトウェア危機について＞

今日の講義の中で一番興味が持てたのは、「ソフトウエア危機」についての話です。「使う方は天国、作る方は地獄」とありましたが、実際に私達のように「使う方」はあまり気付かないし、気にしないことだと感じましたが、「作る方」にとっては相当な要求をされているように思いました。今日のプログラマーに掛かる負担というものは、「使う方」が考えているよりかなり大きいものだと思います。プログラミング言語の今後の発展としては、やはり講義であったような拡張の容易さや再利用性が問われているのだと感じました。
スライドの「ソフトウェア危機」の部分で「使う方は天国、作る方は地獄」とありましたが、全くその通りだと思いました。私がよくプレイするゲームの公式ホームページで製作スタッフの日記があるのですが、これがまた酷くて一週間寝ないとかずっと自分の家に帰らないとかが普通のようです。このような現状を見ると、初心者の人がこのような事を知るとやる気が落ちてしまうのではないかとも思いました。
自分が今回の講義で興味を持ったものは、ソフトウェア危機についてです。ソフトウェア危機の概要の中にGUI環境の普及に伴って「使用する方は天国、作る方は地獄」という記述がありますが、自分はこれだけでは理由がわかりませんでしたが、理由としてソフトウェアの再利用について理解していくとわかりました。モジュールの再利用の際に初めからあるプログラムに対して、その後機能を改良（修正）する上で部分的ではなく改良する中身の項目を書き直さなきゃならないという点で修正する際に手間がかかるという理由で再生利用性の向上において作る方は確かに地獄だと感じました。

＜言語の進化について＞

今日の授業で関心があったことは、先生が言った「今の言語はもう完成されているかのようにみえる（思われている）」というようなことを言っていたことです。私は、最初からすでに完成されてる言語を習っているのだとずっと思っていました。というより、そういうこともあまり考えないで、ただ数学の公式のように「この場合は、この文法」というように、決められた型の通り、プログラミングを作成していたし、この文法しか使えないと思っていました。でも歴史を振り返ってみると、以前にはGOTO文というのがあり、それが進化して分岐や繰り返し文などがでてきて、よりいっそうプログラミングがしやすくなって、今のIF文などの文法が出てきたんだなと思いました。つまり、言語や文法は進化し続けていて、そのプログラミングの効率を上げるために、いろいろな考え方や試行錯誤の結果から今、私たちが習っている、文法にたどりついたんだなと、あらためて実感しました。きっと今の文法も新たな文法や言語に開発され直されると思います。だから今の文法や言語は完成形ではなく、まだまだ通過点に過ぎないんだなと思いました。

＜人間の探求心・欲求について＞

モジュールの話について、思ったのは、プログラミング言語はこういう不満点の改善であれこれ進化したり分派したりしていくのだなということです。面倒くさかったり分かりづらかったりすることを直していこうとする、人間の意欲はすごいなと思いました。
構造化プログラミングの存在により、分かりやすい、また効率の良いものになったと確実にいえます。モジュールの組み合わせやその構造、言語の中身等を理解できやすくなった背景には、それを発見・改善した人がいて、現在につなげている人がいるからこそなのだと改めて実感しました。
もう１つ印象深かったのがソフトウェアの危機です。構造化プログラミングによってソフトウェアの生産性が向上したことによりソフトウェアの生産性をさらに引き上げなくてはならない状況になっているので人間の欲は無限だなぁと思いました。

＜差分プログラムについて＞

自分は差分プログラムに興味を持ちました。どのように既存部分をいじらないで修正するのか知りたいです。
差分プログラムという点についてもっと知りたいです。
１つ気になったのは、モジュール再利用の問題点、差分プログラムの徹底という下りです。つまりこれは、すべて書き換えるとメジャーアップデートになると思っていいのでしょうか。

＜感想・意見＞

Ⅰ．講義全体の感想

GO TO文の魅力は物凄い。無限に付箋をつけるような物だから、使いやすいが判りにくいのは見たままである。この魅力から離れたことは英断と感じる。しかし、これで生産性が向上したと、いいことだけで終わらないのが面白い。構造化プログラミングにしても、今度はソフトウェア危機に直面した。まるでプログラミングの更なる発展を、強く促しているようで本当に面白い。未来のプログラミングはどうなるのか。問題が起これば放棄しない限り、それを乗り越えようと発展するが、プログラミングはまだ向上できるのだろうか。そう考えるとまだまだ世の中は面白い。ソフトウェア危機をオブジェクト指向で、どう乗り越えたかが非常に気になりました。良い所で次習に続いたので来週が楽しみです。
構造化プログラミングによりソフトウェアの生産性が向上しているが既存のソフトウェアの再利用性については十分な向上が得られなく、ソフトウェアの需要増に、ソフトウェアの生産が追いつかないといったソフトウェアが危機に陥っていることを知った。そんな中で、オブジェクト指向プログラムが注目されている。これからどのようにしてソフトウェア危機を改善していくのか楽しみです。
言語をパワーアップさせているのはいかに便利に使いやすく、見やすく、幅広いユーザーに使ってもらえるかを追求した結果であり、必要は発明の母というように必要に応じて進化していった結果なんだな～と改めて思いました。なんにせよ、Javaは最終形態の言語ではないなと思います。どんな必要がJavaに突きつけられたとき、どんな言語に進化するのか・・・楽しみに思いました。
去年の「データ構造とアルゴリズム論」の時、フローチャートがたくさん出てきて慣れるまで結構わかりにくいように感じていたのですが、今GOTO文で書かれていたものを見てから改めて考えてみると、フローチャートによるプログラミング設計が可能な構造化プログラミングというのは見やすくするための工夫がなされていてすごくわかりやすくなっているんだなぁと思いました。

Ⅱ．人に教えるということについて

教育は確かに教師にならなくても誰でもいつかはやるものであると思います。今日の教育について述べているところで『興味を持って楽しく理解してもらおうとする姿勢が大事』ということに共感しました。教えるほうがそう思わなければ、楽しく理解してもらうことが困難なことと思ったからです。
自分たちが将来教わるのではなく、教える立場になった時、今まで習ってきたことや、経験が生かせれば、もっと効率よく理解できて、早く楽しさを伝えることができるかもしれないと思いました。こういう場合は、こっちの方が適している、とか、このプログラムは少し難しいけれど、使えると便利になるなどと、実際に経験したことのある人間が言うと説得力もあるのではないでしょうか。
どちらかの言語と決められない部分を、教育で補うというのに具体的にどんな方向に教育の仕方を変えていくのかということに疑問は残りますが、言語が発展していくようにそれに対する教育の仕方も変わっていく必要があるのだなと感じました。それは、プログラミングに限らず、自分がこれから人に何かを教える立場になったときにも考えなければならないことだと思いました。

Ⅲ．小レポートを通じた討論について

一ヶ月の討論を終えて…②にも書いてありましたが、「みんな考えていることが違う」というのは当たり前のことかもしれないけど、プログラミングに関する考え方がこんなにもたくさんあるということはすごいことだと思います。みんなそれぞれ考えを持っていて、この講義を通じて、まったく新しい考えに出会うこともたくさんありました。自分もいろんな人の意見や考え方を聞いているうちに、自分の考えが変わったこともありました。そういった面で、この講義を履修して良かったと思いました。
前回までの授業のような討論形式の授業は、面白いと思う。大学の授業では、一方通行の授業が多い中で意見を言い合うというのは、すごく新鮮な感じがした。
全体の感想としては、先々週までの討論でこの講義を受けている人の考えが少しずつ変わっていったり、新たな事を学んだという人も居たという点で決して無駄ではなくとても有意義なものだったのだと改めて感じました。
今までの討論のまとめだけではなくレポートをみていつも驚いています。色々な意見があり、考え直したりしています。とても有意義な事だと思います。