【まだ書きかえます。どこをいつ書きかえたかを必ずしも明示しません。】
- 1 -
プログラム言語について、ネット上で会話したのをきっかけに、自分の考えをまとめておこうと思ったのだが、わたしの考えは、まえに書いたつぎのふたつの記事から、かわっていない。ただし、そのふたつの記事は、1993年に当時つとめていた大学の教材として書いたもので、その後、2002年ごろまで部分的に改訂しているが、30年まえから20年まえまでのわたしの認識にもとづいたものだ。
- 1X -
上のひとつめの記事では、プログラム言語として Pascal, Fortran, C をなるべく対等にとりあげようとした。
わたしがそのころ研究でつかっていたのは Fortran、ただし Fortran 77 だった。気象の専門にすすむ人にかぎっては、Fortran をやれというのが適切な指導だった。しかし、ほかの専門にすすむならば、研究でも、就職してからのしごとでも、いちばん役にたちそうなのは、C 言語だった。わたしは Ｃ言語をつかいこなしていなかったけれど、教科書を読んで Fortran と対応づけて理解できた範囲のことを教材にふくめた。
Pascal をいれたのは、1990年代前半当時、プログラミング入門のための言語としては定番だったからだ。わたしは1993年に1学期だけ情報処理入門の科目を担当したが、その実習部分の実行環境は MS-DOS 上の Turbo Pascal だった。 Pascal 言語が制御構造をまなぶのに適していたのにくわえて、Turbo Pascal というソフトウェアは、軽いエディタとコンパイラの連動がうまくできていたし、パソコンの画面に図を出すグラフィックス機能もよかった。当時ならばわたしがえらんでもそれになったと思う。(しかしつぎの更新で Mac がえらばれてしまったので、わたしは入門担当からはずれたのだった。) 上級の科目の実行環境である Unix ワークステーション教室にも、Pascal のコンパイラははいっていた。
ところが、1990年代後半には事情がかわってしまった。Microsoft 社が DOS にかわる OS として Windows 95 をだしてきた。Turbo Pascal をだしていた Borland 社は Delphi という Pascal コンパイラをだした。ところが Delphi の グラフィックス機能は、Windows 上の graphic user interface をつくることをねらったからだと思うが、わたしが教材にしてきた Turbo Pascal のグラフィックス機能とまったくにていなかった。わたしは Delphi を買ったもののそれに慣れる時間がとれなかった。また、わたしは 2001 年から別の大学で授業を担当したので、自分の情報処理の教材を移植しようとしたら、そこの教育用の Unix系 OS のシステムには Pascal コンパイラがはいっていなかった。
- 2 -
ちかごろわたしは、同僚にならって、Python (パイソン) という言語で教材を整備している。
Python は、オブジェクト指向の要素もあるが、基本的には、手順立て型 (これはわたしの表現で、プログラム言語の教科書の用語は「命令型」または「手続き型」) の言語だと思う。そのうちでは、制御構造をあらわす構文はわりあい発達している。
そして、 わたしの2番めの記事の表現をつかえば、Python は「手軽な言語」にふくまれると思う。
わたしが意識する「スクリプト言語」の系列には、まず Awk がある。これは、いわゆるフィルター型処理、 つまり、テキストファイルで表現された縦横の表のデータを 1行ずつ読んで加工結果を書きだすという処理に特化したプログラム言語だ。「BEGIN部」をつかえばフィルター型でない手順立てもできるが、それは邪道というべきだろう (といいながら、わたしはつぎのように使ってきたが) 。
それから Perl ができた。これは、Awk でできるようなフィルター型処理もできるが、ほかの手順立てもできる。少ない字数でかなり高度なことができる反面、人が読み書きする言語としてはわかりやすくなかった。
そこで、Perl でできることができて、人にとって読み書きしやすい言語として、Ruby と Python ができた、というふうにわたしは認識している。
わたしは、Ruby のほうが、言語のスタイルがこのみにあっているし、日本語圏の同業者がつかっていたのでそのまねをしようと思ったこともある (2010年ごろ)。しかし、気象学のための道具は世界共通のほうがよいことが多いので、「長いものにまかれる」思いで Python をつかっている (2021年から)。(Ruby をつかわなくなったのには、わたしは R をつかうこともあり、Ruby と R は文法の形式がよくにているが同じではないのでまちがえやすい、という事情もある。)
Python は多様なユーザーがいるので、いろいろなパッケージが提供されている。(そのうちには Fortran とか C++ で書かれてコンパイルされたものもあると思うが。) 便利になった。
その反面、わたしが 1993年のふたつめの記事で Basic 言語 (とくに当時パソコンに付属していたマイクロソフト Basic インタプリタ) について心配していたのと同じ問題があると思う。Python は、長いプログラムむきの言語ではないのに、長いプログラムをかくこともできてしまう、ということだ。
- 3 -
おおがかりなプログラムをくむためには、Python よりも、もっとしっかりした言語をつかうべきなのだと思う。しかし残念ながら、わたしは、それに適した言語をおしえることができない。
気象のシミュレーションならば、いまでも Fortran だろう。ただし、Fortran 2003 以後の標準 (2003, 2008, 2018 がある [この部分 2022-05-08 修正]) にしたがうべきだろう。ところが、わたしはそれをおしえることができない。わたしの知識は、Fortran 77 にいくらかの制御構造の構文を追加したものでとまっている。1990年代、Fortran 90 や 95 の標準がつくられ、そこではモジュール機能や配列演算機能が定義されているのだが、当時、それをつかうのには有料のコンパイラが必要で、複雑なシミュレーションや理論計算のプログラムを自分で書いていなかったわたしは導入しないままきてしまったのだ。
そのほかの専門でどんなプログラム言語がつかわれているか、わたしはよく知らない。C++ やそこから発展した言語だろうか?
- 4 -
Python は、表現のうえでちょっとくせのある言語だ。条件分岐やループの制御構造のレベルを、ソースプログラムの各行の段さげ (indent) と対応づけている。段さげを実現する方法はなんとおりかあるようだが、わたしは空白文字を4ついれることにしている。
他のプログラム言語、たとえば Awk や Ruby をつかう際にも、プログラムの制御構造にあわせて段さげすることが奨励されてはいる。しかし、その段さげは読み書きする人のためのものにすぎない。言語処理系 (インタプリタやコンパイラ) は、段さげを無視する。制御構造のレベルを変えるには、Awk や Ruby では、波かっこ「{ ... }」で文をグループ化する機能をつかう。このような言語のプログラムは、へたをすると、段さげから想像される構造とちがう構造になっていて、期待とちがった動作をしてしまう、ということもありうる。
そういう意味では、Python が段さげと制御構造とを対応させているのは、いいことだ。
しかし、実際に Python で作業してみると、わたしは、条件分岐やループのレベルをふやしたりへらしたりしたくなることがたびたびある。深いレベルにある処理をとりだして別の「関数」にしたくなることもある。そういうとき、該当する行のひとつひとつについて、4個の倍数の空白をいれたりとりのぞいたりすることに時間 (計算機時間ではなくて人間時間) をとられるのは、つらい。わたしは、他の言語でも、レベルがふえるときはがんばって段さげをするが、レベルがへるときはよけいな段さげがあってもかんべんしてほしいと思う。Python でも「if True:」などをいれてよけいな段さげをのこすことはできるが、いかにもごまかしなのでやりたくない。
[2024-03-10 追記] わたしが教材づくりを Python に集中させることにしたのは、多様な目的をひとつの言語ではたせるからであって、Python の言語仕様がよいとおもったからではない。統計学的なデータ解析については、Python よりも R による教材のほうが標準化が進んでいると判断し、その部分は R で書いて Python とはデータファイルでひきわたす形をとろうとおもっている。正直なところ、わたしの感覚では、段下げを必須とする Python よりも、「{ ... } 」の入れ子で階層をあらわす R のほうが読み書きしやすい。Python の段下げはがまんしてやるが、段下げをかんがえるのがめんどうでほとんど同じ処理をだらだらとくりかえし書いてしまうこともある。
