比較プログラム言語論

比較プログラム言語論
平成１６年６月２日
森田彦
レポート（5/26）総括
＜テーマ＞
1.
2.
初めて学習するプログラミング言語としては、文法が厳密でエラーを未
然に防ぐタイプのものが良いですか、それとも、記述の自由度が高く融
通が利くタイプの方が良いと思いますか？
プログラム開発の効率を上げるためには、次のどちらの要因を（より）
重視しますか？
① 言語の文法を厳しくし、文法エラーのチェックレベルを高めることで、エラー発生
をできるだけ未然に防ぐようにする。
② プログラム開発の手法をプログラマが身につけ、結果的にエラーを減らすように
する。
＜テーマ１＞
＜テーマ２＞
テーマ１－厳密文法優先派①
Ⅰ．最初にプログラミング言語の特殊性を意識させるべき

プログラミング言語というのは今まで触れてきた
日本語・英語などといった言語よりも厳密な規則
が多々あり、違う性質・理論を持ちます。プログ
ラミングのＳＡをしていて感じることは、その厳密
さを甘く見ている学生が多いということです。最
初から文法が厳密なものであり、理論が異なる
ものであるという認識を持ってもらえば、今まで
の言語を習う姿勢とは、また違った姿勢で入って
いけるのだと思います。
テーマ１－厳密文法優先派②
Ⅱ．最初にきちんとした書き方を身につけるべき

私は初めて学習するプログラミング言語は、文法が厳
密でエラーを未然に防ぐタイプのものがいいです。なぜ
なら、自由度が高く融通が利くタイプでプログラムを学習
してしまうと、変なくせがついてしまい、無駄や粗（アラ）
が多い間違った書き方が身についてしまう(間違ってい
ても実行できるからいいや、と思ってしまう)し、そうする
と厳密な文法でプログラムを書かなければいけないとき
に苦労すると思うからです。正しい位置で打つタイピン
グ練習も、変なくせがついている人たちはとても大変そ
うでした。なので、最初の何も知らないうちから厳密なプ
ログラムを書くほうが、後々役に立つのではないかと思
います。
テーマ１－厳密文法優先派③
Ⅲ．エラー表示が厳しい方が親切で理解も深まる

私は、「文法が厳密でエラーを未然に防ぐタイプ」の物の
方が良いと思います。これはプログラミングに限ったこと
ではないと思いますが、“自分がどこをどういう風に間違
えたのかということをきちんと把握する”ことによって、理
解度が増すのではないかと考えるのでそう思いました。
（中略）、まずどこが間違えているのかということに気づ
けなければそこから先になかなか進めないですし、必ず
しも私たちが大学で初めて学んだ時のようにTAやSAに
常にわからないところを聞けるような状況であるとは限
りません。簡単なところでつまずいてしまうことによって
プログラミングすること自体が嫌になってしまうようなこと
もないとはいえないので、こちらの方が初めて学ぶ場合
にはよいと思いました。
テーマ１－自由度・融通優先派①
Ⅰ．最初のハードルを低くしてまず慣れることが先決


私が初めて学習するプログラミング言語なら、記述の自
由度が高く融通の利くタイプの方がいいです。なぜなら、
「初めて」ということなら、最初から厳密にエラーを防ぐタ
イプより、プログラミング言語になれるという方が大事だ
と思うからです。まずは、全体的なプログラミング言語の
流れを踏まえた上で、Delphiのような文法的に厳しい言
語を学んでいけばいいと思います。
記述の自由度が高く融通が利くタイプの方が私は良い
です。なぜなら、私自身があまりプログラミング言語の
操作に慣れていないため、文法が厳密だと大変になる
からです。それにパソコンは得意な人と不得意な人に
別れ、不得意な人でも簡単にできるモノのほうが初めて
学習する時ラクだからです。
テーマ１－自由度・融通優先派②
Ⅱ．エラーを体験する方が理解が深まる


私は記述の自由度が高く融通が利くタイプが良いと思い
ます。（中略）エラーを起こした部分を理解するためにプ
ログラム上で認識するよりも実際に動かしてみて、その
エラーが起こった原因を追究し判断、修正を行うほうが
知識として身に付くと思うのです。
エラーを厳密にしてしまうと、どうしてエラーになってし
まったか調べたり理解したりする機会が減ってしまうよう
な気がします。極端にいえば、数学の勉強をするのに公
式を暗記して、式の中身を理解していないのと同じこと
だと思います。やはり学習するという点で見れば、エ
ラーをみつけてどうしてエラーになったのか考える場を
与えたほうが良いと思います。
テーマ１－自由度・融通優先派③
Ⅲ．エラーを出すより、動作させる楽しさを知ることが大切


やはり初めから文法的に厳しくしてしまうとプログラミングの楽しさを
知る前に嫌いになり挫折してしまうと思うからです。ある程度融通が
利いたほうが自分の組み立てたプログラムが動くという楽しさを味わ
え、のめり込んでいける気がします。そして、その楽しさを知った後か
らなら文法の厳しいほうでも自ら言語を学びプログラムをしていけると
思います。それくらい、物事の始めの印象は大事です。文法を初めか
らきちんと覚えることも大切だとは思いますがプログラミングが楽しい
と思えることが第一歩だと思います
プログラムを入力している際に「エラーが出る可能性がある」と警告さ
れ、せっかくプログラムを打ち込んでいても、その後の「やる気」に繋
がると思います。初めて触った言語で、そこまで挫折してしまってプロ
グラムから離れてしまってはどうにもならないと思います。なので、ま
ずは「自由度が高いタイプ」の言語を利用し、プログラミングの楽しさ
を覚えてから、細かい知識や深い部分に触れた方が初心者にとって
は良いのではないかと思いました。
テーマ１－整理
厳密文法優先派
自由度・融通優先派
言語の特殊性を意識させ最初のハードルを低くしてま
るべき
ず慣れることが先決
最初にきちんとした書き方エラーを出すより、動作させ
を身につけるべき
る楽しさを知ることが大切
エラー表示が厳しい方が
親切で理解も深まる
エラーを体験する方が理解
が深まる
DelphiとJavaを用いて、記述の自由度を比較してみましょう。
＜参考資料＞
Delphi vs Java
記述の自由度が、実際のプログラミング言語でどの程度異なるのか、
を上の両言語の比較で見てみる。
＜内容＞




基本ルール
型宣言について
演算子
不等号記号
１．基本ルール
１．大文字と小文字の区別
Delphi：区別しない。
Java：区別する。
＜理由＞
言語開発者の”思想”ではなく、歴史的経
緯から･･･
区別すると、変数等の表現が豊富になる。→ Testとtestは異なる変数
一方、うっかりミスも多くなる。
２．文の開始と終了
＜理由＞
Delphi： begin～end → できる限り意味明瞭に記述する。
Java： { ～ }
→ 記述の手間をできる限り減らす。
２．型宣言について
＜Delphi＞
var
＜Java＞
int a;
//整数型
a:Integer; //整数型
double b; //実数型
b:Real;
//実数型
String c;
c:String;
//文字列型
//文字列型
変数宣言部を明示的に示すため
にvarを明記し、文頭に置く。
変数宣言は、プログラム中のどこ
で行っても良い。
使用する変数を、文頭で一望できる。
思いついた時点で変数を宣言できる。
記述が面倒。
変数リストが把握しにくくなる。
変数の初期化も同時に行える。
int a=0;
便利
３.演算子①
3-1．四則演算子ー同等
3-2．代入演算子
Delphi
演算子 :=
a:=5;
例
＜Delphi＞
Java
=
a=5;
演算子使用例
+=
a += b
式の意味
a=a+b
-=
a -= b
a=a-b
*=
a *= b
a=a*b
/=
a /= b
a=a/b
代入と同等（比較）の違いが明瞭に
記述が少し面倒
＜Java＞ C++から引き継ぐ特
殊な代入演算子あり
慣れると便利→記述が簡潔に
プログラムが読みにくくなる。
初心者には不向き
３.演算子②
3-3．増減演算子
演算子
++
＜Java＞
使用例
a++あるいは++a
式の意味
a=a+1
--
a--あるいは--a
a=a-1
演算子
Inc()
＜Delphi＞
使用例
Inc(a)
式の意味
a=a+1
Dec()
Dec(a)
a=a-1
頻繁に使用される。
繰り返し処理の記述に便利
順序で値が異なる場合あり
それほど多用されない。
３．演算子③
3-4．除算演算子
＜Delphi＞
商を求める演算子「div」と除算演算子「/」を区別
演算の区別が明瞭 → ミスが少ない
記述が面倒
＜Java＞
除算演算子「/」のみ
記述が容易。
整数/整数のとき、ミスが生じやすい。
３．演算子④
3-4．論理演算子
<Delphi>
演算
演算記号
論理否定 not
<Java>
例
演算
演算記号
not A
論理否定 !
例
! A
論理積
and
A and B
論理積
&&
A && B
論理和
or
A or B
論理和
||
A || B
※ A、Bは論理式（trueかfalseかの値をとる式）
意味が分かりやすい。
記述が簡潔。
記述量は若干増える。
意味は分かりにくい。
４．不等号記号
＝と≠の表記が異なる。他は同じ。
数学記
号
a>b
意味
意味
Delphi
表記
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
aはbより小さい a<b
a<b
aはbより小さい a<b
a≠b
ａはｂに等しくな a<>b
い
a≠b
ａはｂに等しくな a!=b
い
a>=b
テーマ１－初めて学習するのにふさわしいプログラミング
言語は？
厳密文法派
自由度・融通派
言語の特殊性を意識させるべき
最初のハードルを低くしてまず慣れる
ことが先決
最初にきちんとした書き方を身に
つけるべき
エラーを出すより、動作させる楽しさを
知ることが大切
エラー表示が厳しい方が親切で理エラーを体験する方が理解が深まる
解も深まる
あなたは、どちらの説を支持しますか？
テーマ２

プログラム開発の効率を上げるためには、次
のどちらの要因を（より）重視しますか？
① 言語の文法を厳しくし、文法エラーのチェッ
クレベルを高めることで、エラー発生をできるだ
け未然に防ぐようにする。
② プログラム開発の手法をプログラマが身に
つけ、結果的にエラーを減らすようにする。
テーマ２－エラーチェックレベル重視派①
Ⅰ．人為的ミスはなくならない。そしてエラーを探すのは大変


私はプログラム開発の効率を上げるためには言語の文法を厳しくし文法
エラーのチェックレベルを高め、エラー発生をできるだけ未然に防ぐよう
にすることをより重視すべきだと思います。それは、プログラムの開発を
行うのは人間であり、どんなに人間が能力を高めたとしても完璧にできる
ようにはならず、必ずどこかでミスが出てしまうと思うからです。簡単なプ
ログラムの中からそのミスを探すなら大丈夫だと思うのですが、それがも
し膨大なプログラムを開発している中でミスをしてしまい、探すことになっ
たら大変だと思うからです。
（前略）なぜなら、プログラムの開発の効率を上げるには、エラーを「減ら
す」のではなく、「なくす」ようにする必要があると思うからです。プログラマ
の実力主義では、いざ、何かエラーが起こりプログラムが実行されないと
きに、「どこが間違っているのか分からない」という問題が発生すると思い
ます。そしてプログラムが長くなればなるほど、人間の目でエラーを探す
のは難しくなっていくと思います。ですから、多少融通がきかなくても、文
法エラーのチェックレベルが高いほうがいいです。
テーマ２－エラーチェックレベル重視派②
Ⅱ．未然にエラーを防げれば効率が上がる


エラーの発生を出来るだけ未然に防ぐということ
は、それだけ、エラーチェックに時間をかけない
で済むと思ったのでこちらの方を選びました。
エラーが発生すればその段階で気づきその場で
直せるし、そこでどうしてエラーが出たかを考え
られる。エラーがでなければどこが間違っている
かわからないし、時間もかかるから、文法のエ
ラーチェックレベル高めるほうがいいと思う。
テーマ２－開発手法重視派①
Ⅰ．プログラマの成長が最優先

プログラム開発の効率を上げるためには、②の
ようにプログラム開発の手法をプログラマが身に
つけ、結果的にエラーを減らすという方法のほう
がよい気がします。理由は、最初は効率がいい
とは言えなくても、エラーの発生を未然に防ぐよ
りもプログラマが自分で考えて力をつけることに
よって、プログラマの成長に役立って、結果的に
効率が上がる気がするからです。また、自由度
が高いことで、応用性も効く気がするので、②の
ほうがいいと思います。
テーマ２－開発手法重視派②
Ⅱ．まず動作させて結果を見ながら改良を、という方が効率的

プログラムの開発効率をあげるなら自由度の高
い言語を使ったほうがいいと思います、それは
すばやくプログラムを組んでいく過程でつまらな
いエラーで足止めを食うよりも自由度の高い言
語で細かい事を気にせずに大まかでも動いて形
となるプログラムを先に作りそれを後からどんど
んバージョンアップさせて行ったら（良いと思うか
ら）。厳密なプログラムを使うよりも自由度の高
いプログラムで数を沢山作り、それを改良して行
く方がプログラム開発の効率が上がると思うから
です。
テーマ２－開発手法重視派③
Ⅲ．エラーが逐一出るとむしろ効率が下がる

開発の効率を上げるのであれば、プログラマが
手法を身につけエラーを減らしたほうが良いと思
います。ここでエラーを厳密にしてしまうと次から
次へとエラーがでて、作業が遅くなってしまいま
す。それにプログラマも成長しないまま次のシス
テム開発でもまた同じように時間がかかってしま
います。それならプログラマの能力を向上させて
成長させて効率の良い手法を身につけさせたほ
うが良いと思います。
テーマ２についてのコメント






両者の主張はもっとも。ただ想定している状況が異なる
だけ。
そこで、システム開発現場に場面を設定すると・・・
プログラマが開発手法を身につける必要があるのは当
然。
しかし、これまでのシステム開発の歴史が物語ること
は・・・
いくら熟練してもエラーはなくならない。
大規模システム開発現場では、できる限りコンパイラの
チェックでエラーを処理できることを望んでいる。
Java言語開発の過程で、文法エラーチェックのレベルはC++
より高められている。
C++ vs Java① if文中の比較
次のプログラムはC++ではコンパイルエラーにはなりません。
int a=0;
if(a=0) {
Edit1->Text=“値は０です。”;
else {
Edit1->Text=“値は０以外です。”;
}
なぜか？・・・
実行すると・・・
「値は０以外です」が表
示される。
C++では、条件式に整数を用いた場合、
0以外の整数→true
0
→false
として扱うから。
C言語の“落とし穴”の一つ
Javaでは文法エラーになる。
C++ vs Java② 精度落ちの禁止
次のプログラムは、C++では、エラーは出ません。
double a=5.0;
int b;
b=a/2;
ｂの値は２になります。
しかし、Javaでは、”精度が落ちている可能性があ
ります”というエラーメッセージが出ます。
これは、実数値を整数型変数にうっかり代入するこ
とで、精度が消失するという危険性を排除するため。
C++ vs Java③ 未定義変数参照の禁止
次のプログラムはJavaでは下線部でエラーが出ます。
int a=Integer.parseInt(jTextField1.getText());
String Message;
switch (a) {
case 1:
Message="Case1です。";
C++ではエラーは出ない！
break;
case 2:
Message="Case2です。";
初期化されていない可能性が
break;
あります。
}
jTextField2.setText(Message);
これは、aに１か２以外の数値を入力した場合、変数Message
の値が初期化されないという意味です。
本日のテーマ－初めて学習するのにふさわしいプログ
ラミング言語は？
厳密文法派
自由度・融通派
言語の特殊性を意識させるべき
最初のハードルを低くしてまず慣れる
ことが先決
最初にきちんとした書き方を身に
つけるべき
エラーを出すより、動作させる楽しさを
知ることが大切
エラー表示が厳しい方が親切で理エラーを体験する方が理解が深まる
解も深まる
あなたは、どちらの説を支持しますか？
第７回目レポート




あなたはどちらの説を支持しますか？その回答と、そう
支持する理由を、できる限りHPに掲載している意見を
参照（引用）する形で説明して下さい。分量は200字程
度で結構です。
なお、上の記述を行った上で,（いつも通り）講義の感想
や質問等を付加しても結構です。
提出先：[email protected]
件名：「学籍番号（半角）+半角空白＋氏名」を記入し
て下さい。
例） s02xxx 学院太郎
Delphiのプログラム例
var
a:Integer;
b:Real;
変数宣言部
begin
a:=5;
b:=a / 2;
end;
プログラム本体
++あるいは--演算子使用上の注意
++aの場合
int a=1,b;
本来の記述
int a=1,b;
結果
aの値：２
b=++a;
a=a+1;
ｂの値：２
b=a;
a++の場合
int a=1,b;
本来の記述
int a=1,b;
結果
aの値：２
b=a++;
b=a;
ｂの値：1
a=a+1;
除算 Delphi
商を求める演算子
var
除算演算子
var
a,b:Integer;
begin
a:Integer;
begin
a:=5;
a:=5;
b:=a div 2;
b:=a / 2;
end;
b:Real;
end;
bの値:2
演算の区別が明瞭 → ミスが少ない
記述が面倒
bの値: 2.5
除算 Java
商を求める場合
int
a,b;
実数除算の場合
int a;
double b;
a=5;
a=5;
b=a/2;
b=a / 2;
bの値:2
bの値: 2
整数/整数の値は整数に
b=a/2.0 とする必要がある。
記述が容易。
整数/整数のとき、ミスが生じやすい。 → 落とし穴の一つ

Download Report