『Dr.WEB メールデーモン』、MTA 用迷惑メール対策製品です！
一口に「初心者」と言っても、ただ単に経験が足りないだけの「真の初心者」もいれば、 「やる気」、「向上心」に欠けるので実力がいつまでも伴わない「自称初心者」もいる。 あるいは「真」と「自称」の中間に位置するとか。
で、やる気や向上心のない人は手のつけようがないので、ここでは扱わないことにする。
さて、初心者向け言語の話だ。
しばしば「初心者向けの言語」と宣伝される言語がある。 たとえば、BASIC, HSP, PHPなどがそれにあてはまるようだ。
これらの言語にはなんらかの共通項があって「初心者向け」と考えられている のだと思う。つまり、初心者にアピールする特質を抽出できれば、 その特質を他の言語に付与することも、あるいは可能かもしれない。
で、これらの言語の仕様(文法や組み込みの機能)について思い返してみると
というような感じに思える。PHPに関しては最近はオブジェクト指向機能も備えて Java化しつつあるけど、機能が関数ベースでフラットな点は依然として事実だ。 また、PHP使いには「関数化すること」や「オブジェクト指向機能を使うこと」への 抵抗感が強い人がそれなりに観測されるようだ。
ここから「初心者向け言語が避けていること」言い替えれば 「初心者が苦手なこと」が何であるかだいたいわかる。 彼らは「抽象化」が苦手なのだ。
関数がなければ、あらゆる機能はプリミティブの組み合わせをたどっていくだけで (原理的には)理解できる。ある意味、安心だ。
抽象データ型やオブジェクト指向機能のような新しい概念を 新たに学ぶときの複雑さの増加は、たとえば100ある基本関数にひとつふたつ新しいものを加える ような複雑さの増加に比べると敷居が高い。
また、20数年前のBASICプログラムを思い出したり、U-20プロコンにおける若者のプログラムを 見る限り、抽象度が低く(私のようなスレたプログラマには)理解が難しいような プログラムでも力業でなんとかしてしまうのが、初心者、あるいは経験の少ないプログラマ のようだ。
しかし、考えてみれば「抽象化」というのは、この半世紀にプログラミング言語が進化してきた方向そのものだ。 あらゆるプログラミング言語はそれぞれの方向でより高い抽象化を実現するために 進化してきている。
抽象化は
などなど、良いソフトウェアを開発するのにもはや不可欠な概念だと言ってもよい。
新たな概念を学ぶことを拒否して、初心者のままでいつづけるか、 抽象化を体得して脱初心者を目指すか、という究極の選択を迫られているような気がしてきた。
そういう観点からは、「初心者向け言語」の「初心者向けの性質」は 実は活用してしまうと良いプログラマーになることを疎外する危険性がある。
初心者にウケるために抽象化を強調しない言語があってはいけないとまでは 言わない。趣味のプログラミングであれば、良かろうが悪かろうが関係ない。 それなりに楽しければそれでよいんじゃないか。 が、良いソフトウェアを開発したい人は、むしろ積極的に抽象化機能を 学び、活用すべきだろう。特に職業的ソフトウェア開発者は。
初心者への間口を広くするために基本機能はフラットにし、 オブジェクト機能などを追加して抽象化もできる言語にすればいいじゃないか、 と思う人もいるかもしれない。
が、個人的にはそれはうまくいかないと思う。 そのような言語では学ぶことを拒否する「自称初心者」は いつまでも抽象化機能を身につけず、質の悪いプログラムを生産し続けるだろう。
もちろん、志の高い人はそのような言語を通じて抽象化機能について学び 使いこなせるようになるだろうが、 それくらい志が高ければ、最初から初心者にこびない言語を使っても 同じくらいか、もしかするとより短い期間で、良いプログラマに成長するだろう。
とはいうものの、初心者向け言語への要求があるのは事実である。 それを否定するつもりはない。
そのうちのいくばくかは、初心者向け言語から入門して段階的に(スムーズに)進歩できる という「誤解」によるものだろう。しかし、すでに述べたように 「初心者向け」という性質は、良いソフトウェア開発に必要な性質とある程度矛盾する。
とはいえ、最大の原因はプログラマにはないのではないか。 間違っているのはプログラマじゃない、社会が間違っているのだ。
どういうことか。
私がなにか大きな買い物をするとしよう。 平均的サラリーマンが購入する一番高額なものといえば住宅なので、 家を買うことを考えよう。 新築であれば、土地と建物で3000万とか4000万とかかかるのではないだろうか。
では、私はこの家を素人に立ててもらいたいだろうか。 現場に行ったら職人がどれもこれも、専門教育も受けていません、修行もしていません、 先月までは関係ない職業でした、とかいうような人の集まりだったら。
私はイヤだ。
が、ソフトウェア開発ではそれに近いことが平気でまかり通っている。 ソフトウェア開発現場には「自称初心者」がたくさんいるし、 そのような人でも開発に投入するために「初心者向け言語」が重宝される。
本当はそんな初心者を現場に投入してはいけないはずだ。 建築業界でもあまり良くない噂を聞くことはあるが、 それでもここまでではないはずだ。 ソフトウェアを設計するのに「建築士」のような資格は不要だし、 大工や左官に比べてソフトウェア開発者の技能のありなしを明確に判別する手段もない。
開発費用を値切る顧客、対抗に素人を投入するベンダー、 火を噴くプロジェクト、投入される火消し、 まわりの「素人」に足を引っ張られ抑圧ばかり高まる「できる」プログラマ。
まるでババ抜きのようだ。 「使えないソフトウェア」を引いて顧客が損するか、 「プロジェクト赤字」を引いてベンダーが損するか、 「消耗しきって体調不良」を引いて火消し開発者が損するか。
それでも「自称初心者」だけは、「私はわかりません」という顔をして生き残り、 ますますはびこることになる。
もちろん、そういう開発現場ばかりじゃないんだけどね。
問題提起だけで答えはないのだが、 「自称初心者の撲滅」と 「顧客のソフトウェア開発に対する意識向上」が 鍵だと思う。
もっともどちらも実現困難だよなあ。
2.6.18/2/2.6.23の使い分けから移行。 X.orgのintelドライバも動くし、サスペンド・リジュームの問題も解決したようだ。 ありがたい。これで一本化できる。
しかし、なぜかACPIからバッテリが見えない。/proc/acpi/battery が見えなくなっている。 gnome-power-managerやgnomeバッテリアプレットからはバッテリ容量が見えるのが不思議だ。
PHPスクールの危険?
建築系だと、やはりそのせいで人が死ぬかも知れないという性質から
いちいち設計審査等で、政府の認証が必要になっていますが、
今後もWEBアプリケーションではそのようなことは無いのかも知れません。
一番現実的な解はウェブサービスの安全性の認定を行う会社が出てきて、それがメジャーになることかも知れませんね。
自分で建築をたとえに出しといてなんですが、建築と同じやり方で解決はしないと思うのです。が、今のところ「向上心のない人は雇わない」くらいしか対策を思いついてません。それじゃ大局的には解決しないんですが。
作りたい建物が沢山ある時に全建築業者が団結して「もう作れません諦めて」と言えれば良いけど、
そうは行かなくて、見習いに簡単な所を手伝ってもらう業者や、
腕の悪い大工しかいない欠陥業者や、
その様子を見て悲しむ良心的な業者がいる、と言う構図ではないでしょうか。
一番目の業者みたいに、
基本機能はフラットでかつ抽象化もできる言語を使って
忙しい時は自称初心者には部品を作ってもらって
あとでその部分だけリファクタリングするのが現実的に良いんじゃないでしょうか。
まつもとさん、コメントありがとうございます。
「向上心がない人が雇わない」を続けた結果、そのベンダーが一般にもある程度認知されれば(長い道のりですが)解決になりそうな気がします。
確かに建築業と同一にはできないですが、建築業でも大工さんの腕はピンキリなので、ある程度参考にはなると思います。
建築業界だと、政府以外だとそこをカバーしてるのは施工業者の会社の信用度なんですよね。
大手は大工さんが下手しても必死にフォローしますし。
WEBアプリケーションのベンダーは一般的には知名度が全然ないんですよね。
データ系だと富士○やNT○データなんかが強いのはそのへんのブランド力ということなのかと思います。
私は事務機の内部ソフトウェアを書いていますが、みんな参照するにはWEBが良いなんて言うんですが、
WEB情報推進してるのが周囲だと私ぐらいという現実もあり、
近いソフトウェア業界でもこのありさまなので、一般にWEBの重要性を認知してもらうにはもうしばらくかかりそうだな。と思います。
当たり前すぎて釈迦に説法ですが、プログラミングとは（一部のハッカーを除き）それ自体が目的ではなく、それでもって何らかの対象領域におけるアプリケーションを実現することが目的です。
『エンドユーザ開発』なる言葉に代表されるように、世の中が要請する『初心者向け言語』とは、これからプログラミングの専門家になろうとする人の入り口としての言語ではなく、対象領域については専門家である人間が、『プログラミングに関しては初心者のまま』(!!)ソフトウェアが作れる言語、のことではないかと思うのです。
この考え方の典型とも言えるのが「プログラミングの専門知識がなくてもクリエイターの創造性を具現化してどうたらこうたら」という、オーサリングツールやゲーム制作ツールの売り文句。
この考え方は、映像・音声の垂れ流し系コンテンツのような、作成中のプログラムモデルとプログラムの最終出力がかなり一致するものの作成においてはある程度成功している（しかし、FlashのActionScriptのように、少々こみ入った『制御』が入ってくると、プログラミングの初心者だけではあっという間に暗礁に乗り上げる）というのは、以前ビジュアルプログラミングの話題でまつもとさんが仰った通り。
「プログラマの雇用コストをケチりたい」という欲求がある限り、「初心者向け言語」は生み出され続け、「万年初心者」に悩まされる日々が続くかもしれません。
変数の型の概念を身に付けることの方が抽象化より先決のような気がします。
そういう意味ではPascalみたいな「不自由な」言語が一番初心者向けかも。
社会ではなく、会社に責任があるんじゃないでしょうか？
自由度が高くて、言語仕様がある程度成熟してきてるし、
カンタンですぐ覚えられて、実績もそこそこあったりで生産性が高い、
いいこといっぱいのスクリプト言語！！
だからこそ、会社がしごとで使うからには、
それを覆い被せるほどのガイドラインを設けるべきだと思うんです。
それができてなければどの言語使ったって、
ある程度の規模を超えれば同じような確率でいけてないコードは書かれると思います。
それを踏まえると、どの言語がココが悪いココ良いとか、案外些細な問題だと思います。
だから向上心の無いヤツがいると生産性が下がる！的なことは、ギーク主観ではありがちですが
社会とか業界とか会社とかの規模で見るとちょっと違うんじゃないかと思います。
Ruby自体が、あんまり抽象化を強調していないし、フラットな感じで書けてしまう言語なんでは?(まつもとさんの言うフラットを誤解しているかもしれませんが)
それから、初心者は抽象化が苦手ではなくて、世界を抽象化して整理する能力を身に付けていない者が、初心者なんでは?
「自称初心者の撲滅」とは質的転換を計るのか、排除するのか。
どちらを意図しているのか気になるところ。
なんとなくですが、『抽象化する』手前の『分析する』というところが弱いと脱初心者できない気がします。既存のプログラムまたは実装しようとしている機能がどういう性質を持つものなのかを分析できないと、そもそも抽象化しようというモチベーションにつながらない気がします。
『分析』を行わず『作る』ことにのみ終始していると、『抽象化する』必要性に気づかないかな〜とか思いました。事実、既存機能の組み合わせで結構いろいろなもの作れたりする開発環境も多いので(これがまつもとさんの言う初心者向けの言語なのかな、とか思ってます)。
上記、すべての人にあてはまるとは思いませんが、私の場合は分析能力の向上が脱初心者に直結していたように思います。
結局のところ、人材のマネジメントについては『正当に評価する』ということが大半を占めるのかと考えています。最も基本的で最も難しいことですが……。
顧客サイドも、プロジェクトを正当に評価するだけでずいぶん状況が変わるかと思います。…………そのための工数を絞り出すのは大変ですけどね。
抽象化についてはなかなか難しいですね。Forthが（スタックと辞書を利用して）抽象化の多層構造を上手いこと正規化できていると思うのですが、誰も使いこなせてないですからね。
上手く設計すれば、それこそ『初心者向け学習用言語』に近付ける言語だと感じているのですが……。
FORTHは確かに面白いですし、Lispとは違う意味で熱狂的なファンがいるのですが、一般的になるには遠そうですねえ。
あ、あと一つ
>新たな概念を学ぶことを拒否して、初心者のままでいつづけるか、抽象化を体得して脱初心者を目指すか、という究極の選択を迫られているような気がしてきた。
問題は、この２つの間が物凄く離れていることだと考えています。初心者にとっては千尋の谷を越えるようなものです。しかも間を橋渡ししてくれる便利な道具があるわけでもないですし。
本や解説で説明しているものもありますが、そもそも初心者が本を読んだぐらいで理解できるはずもありませんしね。
oopがはやりだして、c++を勉強したが挫折(intもobjectじゃないし)。
vc++も挫折。(何処探してもmainがないんです)
javaは体で覚えました。(技術評論社の初版の[スタートアップjava]の繰返し)--何とかoopを理解し、感動。
servlet,jspでwebアプリを作って感動。
eclipseにも感動。
Visual Studio、ASP.NET(c#)はjavaに比べて楽チンで感動。
struts,ejbは手間が多くて、面倒くさくて、しかもそれを厭わない人と仕事して挫折。(好きになれませんでした)
この挫折の後、手間が少なくシンプルなrailsには非常に感動。
私の場合、時々訪れる感動が、新技術を勉強しようというモチベーションになっています。
初心者には、この楽しさ、感動を伝えたい。
(「仕事はつまらないもんなんだよ」という人もいる)
抽象化や分析の能力は誰もが身につけられるものではなく、素質の部分も多いのではないでしょうか。そこに乗り越えられない壁があるとすれば、互いを理解することは困難です。もしそうなら壁の存在を意識してそれを前提とすることが、お互いが幸せになる道のような気がします。
あとMind等のいくつかの日本語プログラミング言語はForthの影響を受けているようです。
ettemさん
>Ruby自体が、あんまり抽象化を強調していないし、フラットな感じで書けてしまう言語なんでは?(まつもとさんの言うフラットを誤解しているかもしれませんが)
私もこの意見にある意味同意します。
Rubyの一番の長所は、構文的にという話しですが、いろいろな抽象度でプログラミング出来ることだと私は思っています。
だからRubyは、本質的には初心者から上級者まで、幅広い層のプログラマが使えるはずの言語だと思うのですが、PHP愛好家の方は、Webプログラミングを手早く作るという目先の事だけを考えてRubyを毛嫌いしているような気がしてなりません。
人の間違いを防ぐ思想に乏しい言語は、例えどんな言語でも「初心者向け言語」とは言いづらいですね。
抽象化するが目的では無いと思いますし
抽象化という言葉自体が抽象的なので
意図を上手く伝えられていないのでは、ないでしょうか？
私は、他人に何故ちゃんと動くか説明できるプログラムが良いものだと思っています。
抽象化は、そういうプログラムを作るための有効な手段
の一つではないでしょうか？
そういうプログラムを作る様になるためには
教育・啓蒙活動を地味の行っていくしかないと私は考えます。
話は変わりまして質問なのですがMatzさんから見て
JavaScriptは初心者向け言語ですか？
抽象化って楽するための手段じゃないですかね？
「なんのために抽象化するの？ いらないじゃん」って意見を散見しますが、抽象化が楽するための手段だとすれば、その意見は確かに苦手意識以外のなにものでもないかと。
元職業プログラマさん
> だからRubyは、本質的には初心者から上級者まで、
> 幅広い層のプログラマが使えるはずの言語だと思うのですが、
そうですよね。
Rubyは初心者にもお薦めの言語だと思います。
プログラミングを勉強したいと聞かれたら、まず薦めようと思える言語ですよね。
それから、初心者向けの言語には、コードを書いていて楽しいと言う事も必要だと思います。「るびま」を読んでるとRubyは楽しそうに見えるので、その点でも、初心者向けなんでは?
>抽象化が楽するための手段
抽象化によって工程が縮むと儲からないという派遣や偽装請負で稼いでいるIT(笑)企業もありますからね。長い目で見たら滅びる企業かもしれませんが、技術よりも算盤という会社やサラリーマンが多いのも事実。
ニュータイプとオールドタイプぐらいの差があるんだよな
オブジェクト指向書ける書けないは
・上級者が小難しい英語まじりの言葉を使いたがり、しかもかなり高い所から見下す態度をとるのでますます理解できない。（まず抽象化って何？）
・本音では上級者は他人が上級者になるのを阻害したい気持ちがある。
・上級者と言ってしまって期待に応えられるほどではない自覚がある。
・失敗しても言い訳が立つ。
・教える義務や面倒が無い。
・業界が中級者を評価しない。
ま、世間が
* 能力が高低に応じて待遇がさほど違わない
* むしろ残業代により能力の低い人の方がお金がもらえる
* 能力の高い人の方が仕事が集中して負荷が高い
と、能力が低い人に甘いので、能力を向上させるインセンティブがないのは事実ですよね。
そこは否定しません。
能力を向上させる気がない技術者は人間として尊敬できませんが。
自称初心者の弁明さん
抽象化ってのは、私もまだマスターしていませんが、Rubyでプログラムってると、知らないうちに身に付くものだと思いますよ。
因みに、未だ見ぬ抽象化の世界を垣間見たいならば、世捨て人になった気持ちで、Haskellをやるのが一番だと思いますよ。
> 彼らは「抽象化」が苦手なのだ。
gaucheのshiroさんは拷問プログラミング言語と称して、MELを挙げているのを思いだしました。
『その欠陥を表現する一文を思いついた。MELは、「プログラマによるあらゆる抽象化の試みを拒否する」のだ。 』
ハッカーとして有名なお二方がどういう思考回路を持っているのか伺えて面白いです。発言を自重する声など気にせず、これからもどんどんお願いします。
> 彼らは「抽象化」が苦手なのだ。
うーん、
「抽象化」のためには「具体化」が大切だと教えれるほど日本のソフトウエア業界は進歩していませんけどね。。
「抽象化」集団の中にいると、「抽象化」が苦手なことが不思議に思えたりするものだとは思いますが。
一般の、訓練されていない人にいきなり抽象化は無理だと思います。オブジェクト指向の「オブジェクト」をちゃんと考えることころからスタートしないと。
言語に期待しても、何も変われない。いくらでも曲解できるし。せいぜいHOW TOが溜まるくらいでしょ。
結局挫折して次の言語にまた期待する。。の繰り返しでしょうね。(^^
＞と、能力が低い人に甘いので、能力を向上させるインセンティブがないのは事実ですよね。
自分に能力があれば、能力を正当に評価できるのでしょうが、いかんせん、能力が低い人が多すぎ。
地道に王道を進む。 これしか結局ないでしょ。