«前の日記(2008年02月03日) 最新 次の日記(2008年02月05日)» 編集

Matzにっき


2008年02月04日 [長年日記]

_ [言語] 初心者向けの言語

一口に「初心者」と言っても、ただ単に経験が足りないだけの「真の初心者」もいれば、 「やる気」、「向上心」に欠けるので実力がいつまでも伴わない「自称初心者」もいる。 あるいは「真」と「自称」の中間に位置するとか。

で、やる気や向上心のない人は手のつけようがないので、ここでは扱わないことにする。

さて、初心者向け言語の話だ。

しばしば「初心者向けの言語」と宣伝される言語がある。 たとえば、BASIC, HSP, PHPなどがそれにあてはまるようだ。

これらの言語にはなんらかの共通項があって「初心者向け」と考えられている のだと思う。つまり、初心者にアピールする特質を抽出できれば、 その特質を他の言語に付与することも、あるいは可能かもしれない。

で、これらの言語の仕様(文法や組み込みの機能)について思い返してみると

  • 機能は手続きベースでフラット
  • データ構造をユーザー定義する機能がない、または強調されない
  • モジュール化機能がない、または強調されない

というような感じに思える。PHPに関しては最近はオブジェクト指向機能も備えて Java化しつつあるけど、機能が関数ベースでフラットな点は依然として事実だ。 また、PHP使いには「関数化すること」や「オブジェクト指向機能を使うこと」への 抵抗感が強い人がそれなりに観測されるようだ。

ここから「初心者向け言語が避けていること」言い替えれば 「初心者が苦手なこと」が何であるかだいたいわかる。 彼らは「抽象化」が苦手なのだ。

関数がなければ、あらゆる機能はプリミティブの組み合わせをたどっていくだけで (原理的には)理解できる。ある意味、安心だ。

抽象データ型やオブジェクト指向機能のような新しい概念を 新たに学ぶときの複雑さの増加は、たとえば100ある基本関数にひとつふたつ新しいものを加える ような複雑さの増加に比べると敷居が高い。

また、20数年前のBASICプログラムを思い出したり、U-20プロコンにおける若者のプログラムを 見る限り、抽象度が低く(私のようなスレたプログラマには)理解が難しいような プログラムでも力業でなんとかしてしまうのが、初心者、あるいは経験の少ないプログラマ のようだ。

しかし、考えてみれば「抽象化」というのは、この半世紀にプログラミング言語が進化してきた方向そのものだ。 あらゆるプログラミング言語はそれぞれの方向でより高い抽象化を実現するために 進化してきている。

抽象化は

  • アルゴリズムの再利用を促進し生産性を高める
  • コードの柔軟性を高め、生産性を高める
  • コードのカプセル化を推進し、変更耐性を高める
  • バグの影響範囲を限定し、保守性を高める

などなど、良いソフトウェアを開発するのにもはや不可欠な概念だと言ってもよい。

新たな概念を学ぶことを拒否して、初心者のままでいつづけるか、 抽象化を体得して脱初心者を目指すか、という究極の選択を迫られているような気がしてきた。

そういう観点からは、「初心者向け言語」の「初心者向けの性質」は 実は活用してしまうと良いプログラマーになることを疎外する危険性がある。

初心者にウケるために抽象化を強調しない言語があってはいけないとまでは 言わない。趣味のプログラミングであれば、良かろうが悪かろうが関係ない。 それなりに楽しければそれでよいんじゃないか。 が、良いソフトウェアを開発したい人は、むしろ積極的に抽象化機能を 学び、活用すべきだろう。特に職業的ソフトウェア開発者は。

初心者への間口を広くするために基本機能はフラットにし、 オブジェクト機能などを追加して抽象化もできる言語にすればいいじゃないか、 と思う人もいるかもしれない。

が、個人的にはそれはうまくいかないと思う。 そのような言語では学ぶことを拒否する「自称初心者」は いつまでも抽象化機能を身につけず、質の悪いプログラムを生産し続けるだろう。

もちろん、志の高い人はそのような言語を通じて抽象化機能について学び 使いこなせるようになるだろうが、 それくらい志が高ければ、最初から初心者にこびない言語を使っても 同じくらいか、もしかするとより短い期間で、良いプログラマに成長するだろう。

_ ソフトウェア開発における初心者

とはいうものの、初心者向け言語への要求があるのは事実である。 それを否定するつもりはない。

そのうちのいくばくかは、初心者向け言語から入門して段階的に(スムーズに)進歩できる という「誤解」によるものだろう。しかし、すでに述べたように 「初心者向け」という性質は、良いソフトウェア開発に必要な性質とある程度矛盾する。

とはいえ、最大の原因はプログラマにはないのではないか。 間違っているのはプログラマじゃない、社会が間違っているのだ。

どういうことか。

私がなにか大きな買い物をするとしよう。 平均的サラリーマンが購入する一番高額なものといえば住宅なので、 家を買うことを考えよう。 新築であれば、土地と建物で3000万とか4000万とかかかるのではないだろうか。

では、私はこの家を素人に立ててもらいたいだろうか。 現場に行ったら職人がどれもこれも、専門教育も受けていません、修行もしていません、 先月までは関係ない職業でした、とかいうような人の集まりだったら。

私はイヤだ。

が、ソフトウェア開発ではそれに近いことが平気でまかり通っている。 ソフトウェア開発現場には「自称初心者」がたくさんいるし、 そのような人でも開発に投入するために「初心者向け言語」が重宝される。

本当はそんな初心者を現場に投入してはいけないはずだ。 建築業界でもあまり良くない噂を聞くことはあるが、 それでもここまでではないはずだ。 ソフトウェアを設計するのに「建築士」のような資格は不要だし、 大工や左官に比べてソフトウェア開発者の技能のありなしを明確に判別する手段もない。

開発費用を値切る顧客、対抗に素人を投入するベンダー、 火を噴くプロジェクト、投入される火消し、 まわりの「素人」に足を引っ張られ抑圧ばかり高まる「できる」プログラマ。

まるでババ抜きのようだ。 「使えないソフトウェア」を引いて顧客が損するか、 「プロジェクト赤字」を引いてベンダーが損するか、 「消耗しきって体調不良」を引いて火消し開発者が損するか。

それでも「自称初心者」だけは、「私はわかりません」という顔をして生き残り、 ますますはびこることになる。

もちろん、そういう開発現場ばかりじゃないんだけどね。

問題提起だけで答えはないのだが、 「自称初心者の撲滅」と 「顧客のソフトウェア開発に対する意識向上」が 鍵だと思う。

もっともどちらも実現困難だよなあ。

_ Linux 2.6.24 on Thinkpad X61

2.6.18/2/2.6.23の使い分けから移行。 X.orgのintelドライバも動くし、サスペンド・リジュームの問題も解決したようだ。 ありがたい。これで一本化できる。

しかし、なぜかACPIからバッテリが見えない。/proc/acpi/battery が見えなくなっている。 gnome-power-managerやgnomeバッテリアプレットからはバッテリ容量が見えるのが不思議だ。


«前の日記(2008年02月03日) 最新 次の日記(2008年02月05日)» 編集