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

Presentation on theme: "比較プログラム言語論 平成１６年６月２日 森田　彦."— Presentation transcript:

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

2 レポート（5/26）総括 　＜　テーマ　＞　 初めて学習するプログラミング言語としては、文法が厳密でエラーを未然に防ぐタイプのものが良いですか、それとも、記述の自由度が高く融通が利くタイプの方が良いと思いますか？ プログラム開発の効率を上げるためには、次のどちらの要因を（より）重視しますか？ ①　言語の文法を厳しくし、文法エラーのチェックレベルを高めることで、エラー発生をできるだけ未然に防ぐようにする。 ②　プログラム開発の手法をプログラマが身につけ、結果的にエラーを減らすようにする。 ＜テーマ１＞ ＜テーマ２＞

3 テーマ１－厳密文法優先派①　 Ⅰ．最初にプログラミング言語の特殊性を意識させるべき プログラミング言語というのは今まで触れてきた日本語・英語などといった言語よりも厳密な規則が多々あり、違う性質・理論を持ちます。プログラミングのＳＡをしていて感じることは、その厳密さを甘く見ている学生が多いということです。最初から文法が厳密なものであり、理論が異なるものであるという認識を持ってもらえば、今までの言語を習う姿勢とは、また違った姿勢で入っていけるのだと思います。

4 テーマ１－厳密文法優先派②　 Ⅱ．最初にきちんとした書き方を身につけるべき 私は初めて学習するプログラミング言語は、文法が厳密でエラーを未然に防ぐタイプのものがいいです。なぜなら、自由度が高く融通が利くタイプでプログラムを学習してしまうと、変なくせがついてしまい、無駄や粗（アラ）が多い間違った書き方が身についてしまう(間違っていても実行できるからいいや、と思ってしまう)し、そうすると厳密な文法でプログラムを書かなければいけないときに苦労すると思うからです。正しい位置で打つタイピング練習も、変なくせがついている人たちはとても大変そうでした。なので、最初の何も知らないうちから厳密なプログラムを書くほうが、後々役に立つのではないかと思います。

5 テーマ１－厳密文法優先派③　 Ⅲ．エラー表示が厳しい方が親切で理解も深まる 私は、「文法が厳密でエラーを未然に防ぐタイプ」の物の方が良いと思います。これはプログラミングに限ったことではないと思いますが、“自分がどこをどういう風に間違えたのかということをきちんと把握する”ことによって、理解度が増すのではないかと考えるのでそう思いました。（中略）、まずどこが間違えているのかということに気づけなければそこから先になかなか進めないですし、必ずしも私たちが大学で初めて学んだ時のようにTAやSAに常にわからないところを聞けるような状況であるとは限りません。簡単なところでつまずいてしまうことによってプログラミングすること自体が嫌になってしまうようなこともないとはいえないので、こちらの方が初めて学ぶ場合にはよいと思いました。

6 テーマ１－自由度・融通優先派①　 Ⅰ．最初のハードルを低くしてまず慣れることが先決 私が初めて学習するプログラミング言語なら、記述の自由度が高く融通の利くタイプの方がいいです。なぜなら、「初めて」ということなら、最初から厳密にエラーを防ぐタイプより、プログラミング言語になれるという方が大事だと思うからです。まずは、全体的なプログラミング言語の流れを踏まえた上で、Delphiのような文法的に厳しい言語を学んでいけばいいと思います。 記述の自由度が高く融通が利くタイプの方が私は良いです。なぜなら、私自身があまりプログラミング言語の操作に慣れていないため、文法が厳密だと大変になるからです。 それにパソコンは得意な人と不得意な人に別れ、不得意な人でも簡単にできるモノのほうが初めて学習する時ラクだからです。

7 テーマ１－自由度・融通優先派②　 Ⅱ．エラーを体験する方が理解が深まる 私は記述の自由度が高く融通が利くタイプが良いと思います。（中略）エラーを起こした部分を理解するためにプログラム上で認識するよりも実際に動かしてみて、そのエラーが起こった原因を追究し判断、修正を行うほうが知識として身に付くと思うのです。 エラーを厳密にしてしまうと、どうしてエラーになってしまったか調べたり理解したりする機会が減ってしまうような気がします。極端にいえば、数学の勉強をするのに公式を暗記して、式の中身を理解していないのと同じことだと思います。やはり学習するという点で見れば、エラーをみつけてどうしてエラーになったのか考える場を与えたほうが良いと思います。

8 テーマ１－自由度・融通優先派③ Ⅲ．エラーを出すより、動作させる楽しさを知ることが大切
テーマ１－自由度・融通優先派③　 Ⅲ．エラーを出すより、動作させる楽しさを知ることが大切 やはり初めから文法的に厳しくしてしまうとプログラミングの楽しさを知る前に嫌いになり挫折してしまうと思うからです。ある程度融通が利いたほうが自分の組み立てたプログラムが動くという楽しさを味わえ、のめり込んでいける気がします。そして、その楽しさを知った後からなら文法の厳しいほうでも自ら言語を学びプログラムをしていけると思います。それくらい、物事の始めの印象は大事です。文法を初めからきちんと覚えることも大切だとは思いますがプログラミングが楽しいと思えることが第一歩だと思います プログラムを入力している際に「エラーが出る可能性がある」と警告され、せっかくプログラムを打ち込んでいても、その後の「やる気」に繋がると思います。初めて触った言語で、そこまで挫折してしまってプログラムから離れてしまってはどうにもならないと思います。なので、まずは「自由度が高いタイプ」の言語を利用し、プログラミングの楽しさを覚えてから、細かい知識や深い部分に触れた方が初心者にとっては良いのではないかと思いました。

9 テーマ１－整理 厳密文法優先派 自由度・融通優先派 言語の特殊性を意識させるべき 最初のハードルを低くしてまず慣れることが先決
最初にきちんとした書き方を身につけるべき エラーを出すより、動作させる楽しさを知ることが大切 エラー表示が厳しい方が親切で理解も深まる エラーを体験する方が理解が深まる DelphiとJavaを用いて、記述の自由度を比較してみましょう。

10 Delphi vs Java ＜参考資料＞ ＜内容＞ 基本ルール 型宣言について 演算子 不等号記号
記述の自由度が、実際のプログラミング言語でどの程度異なるのか、を上の両言語の比較で見てみる。 ＜内容＞ 基本ルール 型宣言について 演算子 不等号記号

11 １．基本ルール １．大文字と小文字の区別 ２．文の開始と終了 Delphi：区別しない。 Java：区別する。
＜理由＞ 言語開発者の”思想”ではなく、歴史的経緯から･･･ Delphi：区別しない。 Java：区別する。 区別すると、変数等の表現が豊富になる。→　Testとtestは異なる変数 一方、うっかりミスも多くなる。 ２．文の開始と終了 　Delphi：　begin～end　 　Java：　{　～ } ＜理由＞ →　できる限り意味明瞭に記述する。 →　記述の手間をできる限り減らす。

12 ２．型宣言について ＜Delphi＞ ＜Java＞ var a:Integer; //整数型 b:Real; //実数型
c:String; //文字列型 int a; //整数型 double b; //実数型 String c; //文字列型 変数宣言部を明示的に示すためにvarを明記し、文頭に置く。 変数宣言は、プログラム中のどこで行っても良い。 思いついた時点で変数を宣言できる。 変数リストが把握しにくくなる。 使用する変数を、文頭で一望できる。 記述が面倒。 変数の初期化も同時に行える。 int a=0; 便利

13 ３.演算子① 3-1．四則演算子 ー 同等 3-2．代入演算子 ＜Delphi＞ Delphi Java 演算子 := = 例 a:=5;
3-1．四則演算子　ー　同等 3-2．代入演算子 ＜Delphi＞ Delphi Java 演算子 := = 例 a:=5; a=5; 代入と同等（比較）の違いが明瞭に 記述が少し面倒 ＜Java＞　C++から引き継ぐ特殊な代入演算子あり 演算子 使用例 式の意味 += a += b a=a+b -= a -= b a=a-b *= a *= b a=a*b /= a /= b a=a/b 慣れると便利→記述が簡潔に プログラムが読みにくくなる。 初心者には不向き

14 ３.演算子② 3-3．増減演算子 ＜Java＞ 演算子 使用例 式の意味 ++ a++あるいは++a a=a+1 -- a--あるいは--a
頻繁に使用される。 繰り返し処理の記述に便利 順序で値が異なる場合あり ＜Delphi＞ 演算子 使用例 式の意味 Inc() Inc(a) a=a+1 Dec() Dec(a) a=a-1 それほど多用されない。

15 ３．演算子③ 3-4．除算演算子 ＜Delphi＞ ＜Java＞ 商を求める演算子「div」と除算演算子「/」を区別
演算の区別が明瞭　→　ミスが少ない 記述が面倒 ＜Java＞ 除算演算子「/」のみ 記述が容易。 整数/整数のとき、ミスが生じやすい。

16 ３．演算子④ 3-4．論理演算子 <Delphi> <Java> 演算 演算記号 例 論理否定 not not A
論理積 and A and B 論理和 or A or B 演算 演算記号 例 論理否定 ! !　A 論理積 && A && B 論理和 || A || B ※　A、Bは論理式（trueかfalseかの値をとる式） 意味が分かりやすい。 記述量は若干増える。 記述が簡潔。 意味は分かりにくい。

17 ４．不等号記号 ＝と≠の表記が異なる。他は同じ。 数学記号 意味 Delphi表記 a>b ａはｂより大きい a≧b ａはｂ以上
ａはｂに等しい a≦b ａはｂ以下 a<=b a<b aはbより小さい a≠b ａはｂに等しくない a<>b 数学記号 意味 Java表記 a>b ａはｂより大きい a≧b ａはｂ以上 a>=b a=b ａはｂに等しい a==b a≦b ａはｂ以下 a<=b a<b aはbより小さい a≠b ａはｂに等しくない a!=b

18 テーマ１－初めて学習するのにふさわしいプログラミング言語は？
厳密文法派 自由度・融通派 言語の特殊性を意識させるべき 最初のハードルを低くしてまず慣れることが先決 最初にきちんとした書き方を身につけるべき エラーを出すより、動作させる楽しさを知ることが大切 エラー表示が厳しい方が親切で理解も深まる エラーを体験する方が理解が深まる あなたは、どちらの説を支持しますか？

19 テーマ２ プログラム開発の効率を上げるためには、次のどちらの要因を（より）重視しますか？
　　①　言語の文法を厳しくし、文法エラーのチェックレベルを高めることで、エラー発生をできるだけ未然に防ぐようにする。 　　②　プログラム開発の手法をプログラマが身につけ、結果的にエラーを減らすようにする。

20 テーマ２－エラーチェックレベル重視派① Ⅰ．人為的ミスはなくならない。そしてエラーを探すのは大変
私はプログラム開発の効率を上げるためには言語の文法を厳しくし文法エラーのチェックレベルを高め、エラー発生をできるだけ未然に防ぐようにすることをより重視すべきだと思います。それは、プログラムの開発を行うのは人間であり、どんなに人間が能力を高めたとしても完璧にできるようにはならず、必ずどこかでミスが出てしまうと思うからです。簡単なプログラムの中からそのミスを探すなら大丈夫だと思うのですが、それがもし膨大なプログラムを開発している中でミスをしてしまい、探すことになったら大変だと思うからです。 （前略）なぜなら、プログラムの開発の効率を上げるには、エラーを「減らす」のではなく、「なくす」ようにする必要があると思うからです。プログラマの実力主義では、いざ、何かエラーが起こりプログラムが実行されないときに、「どこが間違っているのか分からない」という問題が発生すると思います。そしてプログラムが長くなればなるほど、人間の目でエラーを探すのは難しくなっていくと思います。ですから、多少融通がきかなくても、文法エラーのチェックレベルが高いほうがいいです。

21 テーマ２－エラーチェックレベル重視派② Ⅱ．未然にエラーを防げれば効率が上がる エラーの発生を出来るだけ未然に防ぐということは、それだけ、エラーチェックに時間をかけないで済むと思ったのでこちらの方を選びました。 エラーが発生すればその段階で気づきその場で直せるし、そこでどうしてエラーが出たかを考えられる。エラーがでなければどこが間違っているかわからないし、時間もかかるから、文法のエラーチェックレベル高めるほうがいいと思う。

22 テーマ２－開発手法重視派① Ⅰ．プログラマの成長が最優先 プログラム開発の効率を上げるためには、②のようにプログラム開発の手法をプログラマが身につけ、結果的にエラーを減らすという方法のほうがよい気がします。理由は、最初は効率がいいとは言えなくても、エラーの発生を未然に防ぐよりもプログラマが自分で考えて力をつけることによって、プログラマの成長に役立って、結果的に効率が上がる気がするからです。また、自由度が高いことで、応用性も効く気がするので、②のほうがいいと思います。

23 テーマ２－開発手法重視派② Ⅱ．まず動作させて結果を見ながら改良を、という方が効率的 プログラムの開発効率をあげるなら自由度の高い言語を使ったほうがいいと思います、それはすばやくプログラムを組んでいく過程でつまらないエラーで足止めを食うよりも自由度の高い言語で細かい事を気にせずに大まかでも動いて形となるプログラムを先に作りそれを後からどんどんバージョンアップさせて行ったら（良いと思うから）。厳密なプログラムを使うよりも自由度の高いプログラムで数を沢山作り、それを改良して行く方がプログラム開発の効率が上がると思うからです。

24 テーマ２－開発手法重視派③ Ⅲ．エラーが逐一出るとむしろ効率が下がる 開発の効率を上げるのであれば、プログラマが手法を身につけエラーを減らしたほうが良いと思います。ここでエラーを厳密にしてしまうと次から次へとエラーがでて、作業が遅くなってしまいます。それにプログラマも成長しないまま次のシステム開発でもまた同じように時間がかかってしまいます。それならプログラマの能力を向上させて成長させて効率の良い手法を身につけさせたほうが良いと思います。

25 テーマ２ についてのコメント 両者の主張はもっとも。ただ想定している状況が異なるだけ。 そこで、システム開発現場に場面を設定すると・・・
テーマ２　についてのコメント 両者の主張はもっとも。ただ想定している状況が異なるだけ。 そこで、システム開発現場に場面を設定すると・・・ プログラマが開発手法を身につける必要があるのは当然。 しかし、これまでのシステム開発の歴史が物語ることは・・・ いくら熟練してもエラーはなくならない。 大規模システム開発現場では、できる限りコンパイラのチェックでエラーを処理できることを望んでいる。 Java言語開発の過程で、文法エラーチェックのレベルはC++より高められている。

26 C++ vs Java① if文中の比較 Javaでは文法エラーになる。 次のプログラムはC++ではコンパイルエラーにはなりません。
int a=0; if(a=0) { Edit1->Text=“値は０です。”; else { Edit1->Text=“値は０以外です。”; } 実行すると・・・ 「値は０以外です」が表示される。 C++では、条件式に整数を用いた場合、 　　0以外の整数→true 　　0　　　　　　　 →false として扱うから。 なぜか？・・・ C言語の“落とし穴”の一つ Javaでは文法エラーになる。

27 C++ vs Java② 精度落ちの禁止 次のプログラムは、C++では、エラーは出ません。 double a=5.0; int b;
b=a/2; ｂの値は２になります。 しかし、Javaでは、”精度が落ちている可能性があります”というエラーメッセージが出ます。 これは、実数値を整数型変数にうっかり代入することで、精度が消失するという危険性を排除するため。

28 C++ vs Java③ 未定義変数参照の禁止
int a=Integer.parseInt(jTextField1.getText()); String Message; switch (a) { case 1: Message="Case1です。"; break; case 2: Message="Case2です。"; } jTextField2.setText(Message); C++ではエラーは出ない！ 初期化されていない可能性があります。 これは、aに１か２以外の数値を入力した場合、変数Messageの値が初期化されないという意味です。

29 本日のテーマ－初めて学習するのにふさわしいプログラミング言語は？
厳密文法派 自由度・融通派 言語の特殊性を意識させるべき 最初のハードルを低くしてまず慣れることが先決 最初にきちんとした書き方を身につけるべき エラーを出すより、動作させる楽しさを知ることが大切 エラー表示が厳しい方が親切で理解も深まる エラーを体験する方が理解が深まる あなたは、どちらの説を支持しますか？

30 第７回目レポート あなたはどちらの説を支持しますか？その回答と、そう支持する理由を、できる限りHPに掲載している意見を参照（引用）する形で説明して下さい。分量は200字程度で結構です。 なお、上の記述を行った上で,（いつも通り）講義の感想や質問等を付加しても結構です。 件名：「学籍番号（半角）+半角空白＋氏名」を記入して下さい。 　　　例）　s02xxx 学院太郎

31 Delphiのプログラム例 var a:Integer; b:Real; begin a:=5; b:=a / 2; end; 変数宣言部
プログラム本体

32 ++あるいは--演算子使用上の注意 ++aの場合 a++の場合 本来の記述 結果 int a=1,b; b=++a; int a=1,b;
ｂの値：２ a++の場合 本来の記述 結果 int a=1,b; b=a++; int a=1,b; b=a; a=a+1; aの値：２ ｂの値：1

33 除算 Delphi 商を求める演算子 除算演算子 var a,b:Integer; begin a:=5; b:=a div 2; end;
a:Integer; b:Real; begin a:=5; b:=a / 2; end; bの値:2 bの値:　2.5 演算の区別が明瞭　→　ミスが少ない 記述が面倒

34 除算 Java 商を求める場合 実数除算の場合 int a,b; a=5; b=a/2; int a; double b; a=5;
整数/整数の値は整数に b=a/2.0　とする必要がある。 記述が容易。 整数/整数のとき、ミスが生じやすい。 →　落とし穴の一つ