idea0001 のバックアップ(No.4)

バックアップ一覧
差分を表示
現在との差分を表示
ソースを表示
idea0001 へ行く。
- 1 (2019-03-04 (月) 19:21:59)
- 2 (2019-03-04 (月) 20:01:35)
- 3 (2019-03-06 (水) 12:08:03)
- 4 (2019-03-07 (木) 13:36:45)
- 5 (2019-03-13 (水) 11:26:46)
- 6 (2019-03-13 (水) 22:53:09)
- 7 (2019-03-17 (日) 09:36:01)

川合のプログラミング言語自作のためのアイデア#0001

(by K, 2019.03.04)

↑

(1) はじめに

「プログラミング言語を作っていいですよ」と言っても、「現状で特に不満を感じてはいないので、何を作ったらいいのかわかりません」と答える人は少なくありません。・・・欲がないですねえ（笑）。
ここではそんな人のために、例えばこんな風に考えたらどうかな？というヒントをいくつか書きたいと思います。
「なんだー、こんな身近なことでいいのかー」と思ってもらえたらうれしいです。気が楽になるといろいろと思い付きやすくなるのではないかと思います。

↑

(2) テーマ#1: 配列の自動拡張機能を付けるべきかどうか？

仮に int a[10]; みたいな配列変数があったとして、a[9] = 3; は全く問題ないけど、 a[10] = 1; は本来はエラーにするべきだと思います。
それで、これを見つけた時に、「エラーになって止まる」のがいい言語なのか、それとも「止まらないで無視して（＝だから何もしないで）先に進んでくれる」のがいい言語なのか、それとも「aを自動で拡張してa[10]も使えるようにしてくれる」のがいい言語なのか、そしてその時に黙ってやるのがいいのかそれとも警告くらいは出したほうがいいのか、あなたはどう思うでしょうか？
まあ一番まずいのは「エラーも何も出さず、配列の境界を越えてアクセスして他の変数の値を1で上書きして続行してしまう」なのは私にもわかります！

エラーで止まるのはもちろんいい言語です。ユーザは宣言時のサイズが十分ではなかったことに気付くからです。
しかし一方で、もし後からでもサイズが変更できる言語だったら、そんなのいちいち報告しないで、自動で拡張して続けてくれたらいいのに・・・という考え方もできます。もしこれが実現したら、宣言時にサイズを深刻に考える必要はなくなり、気軽にプログラムが書けるようになるでしょう。それはとてもいいことです。心配しなければいけないことが減るのは、他のことに集中する余裕にもつながります。

黙って続行するというのは、一見するとひどいと思うかもしれません。自分のミスに気付けないじゃないかと。・・・しかしもし、この手のエラーがあった時に、「どこでエラーがあったのか」や、そのエラーの番号を何か特別な変数に記録してくれて、それを後から参照できるとしたらどうでしょうか？・・・それを前提にした「黙って続行する」です。

一般にエラー処理はこんな感じでおこなれています。

err = 処理1(...); if (err != 0) { エラー処理 }
err = 処理2(...); if (err != 0) { エラー処理 }
err = 処理3(...); if (err != 0) { エラー処理 }

それとか、例えばポインタを使ってアクセスしたいときはこんな風に書くかもしれません。
```
if (p != 0) { a = *p; }
```
これはつまり、ポインタが正常だったらポインタを使ってアクセスする、と書いているわけです。
さてこれらを見てどう思いますか？何をするにもif文で、うっとうしいと思わないでしょうか。私は思います。正常な場合よりも、エラーのチェックの記述の方が多くなる可能性すらあります。
・・・おいおい、こいつは今さら何を言っているんだ、エラー処理を書くことこそプログラミングの主たる作業じゃないか、正常系だけ書けばいいとか思っているんだとしたら、それは初心者か、おバカさんのどちらかだ、という人もいそうですが、でもできればエラー処理なんかあまり書きたくないですよね。本来やりたい正常系をビシバシと書いていきたいはずです。
そう考えた時、エラーがあってもとりあえず止まらないで無視して前に進んでくれる言語だったらどんなにいいでしょう。エラーなんて最後にちょっと確認すればいいじゃないですか。あー、ここまでに来る途中のどこかで失敗していたのか、そうかそうか、それは残念だったね。じゃあエラー表示しておこう。・・・これでいいじゃないですか。

↑

(3) テーマ#2: 自動でエラー処理してくれたらいいかも？

私はコンソールアプリを書いているときに、ファイルのオープンに失敗したら「fopen error」と表示してexit(1);するのが定番になっています。
またmallocしてNULLを返されてしまったら、「out of memory」と表示してexit(1);するのが定番になっています。
あらかじめ大きなバッファを用意しておいて、ファイル全体を読み込ませようとして、それでメモリに乗りきらなかったときは、「too large file」と表示してexit(1);するのが定番になっています。
このように定番のエラー処理があると思うのですが、それを毎回書くのはけっこうめんどくさいです。かといってエラー処理を省略してしまったら、当然ながら誤動作する危険性がありますし、エラーに気付けません。

それなら最初からこの定番処理付きのライブラリ関数を用意したらどうでしょうか。・・・そうですね、エラーの場合は関数から戻ってこなくて、戻ってきたらエラーはなかったと決めつけて構わないので、NoErrを略した_neを末尾につけてみましょうか。

// 普通の書き方.
a = malloc(n);
if (a == NULL) {
    fprintf(stderr, "out of memory\n");
    exit(EXIT_FAILURE);
}
fp = fopen(argv[1], "rt");
if (fp == NULL) {
    fprintf(stderr, "fopen error : %s\n", argv[1]);
    exit(EXIT_FAILURE);
}

// 便利な関数がある場合の書き方.   
a = malloc_ne(n);
fp = fopen_ne(argv[1], "rt");

ということで、10行が2行になるわけです。これはすごく見通しがよくなると思いませんか？

↑

(4) とにかく人間は間違うことがある、ということを前提にすべき

いくつかの言語（特にC言語やC++言語）は、とにかく人間が間違わないことを前提にしているというか、間違えたらどうなっても知らないよ、みたいな強気な仕様が多い気がします。
でも実際は人間はときどき間違えるのです。だから間違えているかもしれないという可能性を常に配慮してほしいです。
そして間違えたときに間違いに気付けるきっかけがあると最高です。

↑

(5) 最適化は果たしてユーザのためになっているのだろうか？

多くのC言語やC++言語では、高度な最適化を売りにしています。これは素晴らしいことではあるのですが、でも弊害もあります。
最近の最適化はかなり優秀で、こちらが高速化してやろうと思って書き方を工夫しても全く速さが変わらないことがたまにあります。それどころか、遅くなってしまうこともあります。・・・この遅くなってしまうケースというのは、素直ではない書き方を見たコンパイラが「このパターンは知らないぞ」と自前の最適化の適用をあきらめてしまったせいで、元の書き方よりも遅くなってしまうという現象です。
こんなことをされるとどうなるかというと、初心者が最適化手法を学ぶ機会がなくなるのです。・・・何もしなくても速いし、良かれと思ってあれこれ努力するとかえって遅くなるのです。こんな経験をしたら、そりゃあ普通は自前で最適化しようとする気はなくなってしまうでしょう。

何の変哲もない素直なプログラムが、超絶にがんばったプログラムと同じ速さで動くなんて、それはもう相当にかっこいいです。コンパイラ作者はさぞかしいい気分でしょう。でも、そのせいで犠牲になっているものもあるということです。

↑

(6) テーマ#3: やりたいことを素直に書けるべき

Windowsでなんか適当にウィンドウを出してそこに線を引いたり丸を描いたりしたいと思った時、win32-APIを使ってやろうとすると、すごくやるせない気持ちになります。・・・なぜかというと、こちらはただウィンドウを出して線を引きたいだけなのに、ウィンドウメッセージに応対するためのコールバック関数を用意させられて、しかもいろんなメッセージにどう対応するか自分で考えないといけない。まあデフォルトで構わないものは全部デフォルトに投げられるのが救いではあるのだけど、でもなんでこんなに何行も書かないといけないの？とは思います。私が小学生や中学生の時にやっていたBASICならLINE命令やCIRCLE命令を使えばそれだけで線でも円でもすぐに描けたのに。
結局、私はWindowsから、ほしくもないのにパラダイムを押し付けられているのです。私は絵が描きたかったのであって、Windowsの仕組みを知りたかったわけではないのです。やりたいことをやりたいようにできないというのはダメです。私はアプリが作りたいのであって、ドライバを書きたいわけじゃないのです。ドライバならOS側の都合を押し付けられるのは構いません。OSの下請けとして頑張るのがドライバの仕事なので。でもアプリはそうじゃないと思うのです。これじゃあ見通しが悪くなって、アプリ開発がうまく行かなくなるリスクだけを上げていると私は思います。

↑

(7) 物事を複雑にするべきではない

言語やライブラリを使っていると、なんでこれはこんな仕様なんだろう？って思うことはないですか？単純にこうすればいいだけなんじゃないかな？とか。
世間の多くのソフトウェアは、複雑な問題を複雑に解決しており、それは全然うまくありません。中には単純な問題を複雑にしてしまっているという例もあります。
プログラマの腕の見せ所は、複雑そうな問題を単純なやり方で見事に解決するところにあるはずです。私はそう信じています。複雑な問題から逃げずひるまずに複雑なまま解決することが技術力だと思っている人もいるみたいですが、そんなのは他の誰かでもできることです。・・・もちろんいつもうまいやり方を思いつけるとは限りませんが、しかしもし運よくうまいやり方に気付いたら、そのときは是非それを試してみましょう！それができるようになればあなたも一流の仲間入りになるはずです！！

↑

次回に続く

次回：

↑

こめんと欄

コメント	お名前	NameLink