Movatterモバイル変換


[0]ホーム

URL:


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

Matzにっき

<<2008/02/11. [言語]「ハッカーと画家」の著者が新しいLisp系言語「Arc」を公開 | エンタープライズ | マイコミジャーナル
2.「セキュリティ、なめんなよ!」 なめねこも一緒に情報セキュリティ強化宣言 | ネット | マイコミジャーナル
3.「サイオステクノロジーはグルージェントの未来技術に期待し子会社化」:ITpro
21. [Ruby]Nimble Method: Garbage Collection is Why Ruby on Rails is Slow: Patches to Improve Performance 5x; Memory Profiling
2. [言語]LuaJIT roadmap 2008
3. [Ruby]What will Matz do?
4. [Ruby]EURUKO 2008 − European Ruby Conference, Prague, March 29th − 30th
31. [教会] 末娘の成長
2. [教会] ゴードン・B・ヒンクレー葬儀および埋葬
41. [言語] 初心者向けの言語
2. ソフトウェア開発における初心者
3. Linux 2.6.24 on Thinkpad X61
51. [Ruby] Copy-on-write friendly patch for Ruby 1.9
2.セキュリティキャンプ・キャラバン with プログラミング -鳥取-
3. [言語]最もタメになる「初心者用言語」まとめ - UK is not Britonish - ハチロク世代
4. [Ruby]Ruby.NET is dead | Zen and the Art of Ruby Programming
5.立ち位置と情熱とバランス感覚:ITpro
61.思わずうっかりついポロリ!これがエンジニアの失言だ/Tech総研
2. [Ruby]Ruby Waves: Home
3. [言語]Static Languages: Rationalizations and Myths :: Steve Vinoski’s Blog
4. バランスボール
71.microBlog >> Bounties for bug fixers: a bug-tracker plugin
2.Years of irrelevance - (37signals)
81. 米子工業高校 情報電子実習
2. たこ焼きパーティ
3. [言語]Garbage-first garbage collection
4. [OSS] Bigtableオープンソース実装2題
91. [原稿] Beautiful Code + 日経Linux
2. [言語]use Perl | Perl is now Y2038 safe
3. [言語]CPython用拡張モジュールをIronPythonから呼び出す (1) 「CPython Extensions for IronPython」とは? | マイコミジャーナル
4. [言語]プログラミング言語の進化を追え: 第1回 サルでも分かるプログラミング言語の新潮流(前篇)
101. [教会] 福千年
111.Life is beautiful: 原点に戻って徹底的に納得するまで理解する
2. スケート
3.SEDA - Architecture for Highly-Concurrent Server Applications
121. 取材
2. [Ruby]nishimotzの日記 - Rubyのチカラ
131. デブサミ2008 1日め (ディープな1日)
141. デブサミ2日目
2. [言語] PythonをDISる。
3.Pre New Generation Chronicle:上野康平−−3次元空間を統べる若き天才プログラマー - ITmedia エンタープライズ
4.New Generation Chronicle:べにぢょ−−ギークプロトコルの解読を試みるサイバーヤンキー - ITmedia エンタープライズ
151. 米澤先生講義
2.京都 - jkondoの日記
3. [OSS]「島根県CMS」のオープンソースとしての公開について
161. [言語]io - Objective-C Syntax
2. [言語]InfoQ: John McCarthy on Elephant 2000, Lisp, Ruby and the Computer Industry
171. 風邪引き
181. 渡米
2.Matzに聞いてみた:効率の良い開発についてどうお考えでしょう? - builder by ZDNet Japan
3.レノボX300 封筒に入る超薄型ThinkPad - Engadget 日本語版
4. Hilton San Francisco
191. Sun Microsystems
2. [言語]A small example of the hidden dangers of dynamically typed programming languages.
3. [言語]Curlは関数型?というか、カオス - noblog
4.Time to rewrite DBMS, says Ingres founder | Reg Developer
5. [Ruby]almost effortless >> El Dorado
201. Google TechTalk
2.B・ゲイツ氏、マイクロソフトとスタンフォード大学の結びつきを強調:ニュース - CNET Japan
3. 月蝕
4. [言語]greenlet Lightweight in-process concurrent programming
211. オレゴンOTBC
2. オレゴンディナー
221. 帰還
2.しまねOSS協議会などに「地域づくり総務大臣表彰」:ITpro
3.Matz×Dan×Daiji「エンジニア進化論」|「てくらぼ」オープニングイベント スペシャル対談開催|パソナテック(PASONA TECH)
4.【インタビュー】Love Code, Love CodeGear! - 22年目の親愛なるコードオタクDavid I参上 Love Code, Love CodeGear! | マイコミジャーナル
231. 帰還(2)
241. 帰還(3)
2. [Ruby] Happy Birthday Ruby
251. 帰還(4)
2. 誕生日
3. [Ruby]programming: Google TechTalk: Matz on Ruby 1.9
4. [Ruby]Virtuous Code > Monkeypatching is Destroying Ruby
261. [Ruby]KIISセミナー
2.国内ベンチャーの海外進出ってどうなの?:CNET Japan オンラインパネルディスカッション - CNET Japan
3. [OSS]アドビ、SQLite Consortiumに参加で開発を支援:ニュース - CNET Japan
271. 楽天ミーティング
2.楽天、電子マネーサービス「楽天キャッシュ」を開始
281. [Ruby]MacRuby - ruby - Trac
2. [Ruby]Ruby, a message to you >> Boy, what ISN'T destroying Ruby these days?
291. [Ruby] 1.9.0-1 リリース準備
2. [Ruby]Webエンジニア武勇伝 第18弾 笹田耕一氏 | 株式会社ウェブキャリア
>>

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バッテリアプレットからはバッテリ容量が見えるのが不思議だ。

[ツッコミを入れる]
ツッコミ・コメントがあればどうぞ! E-mailアドレスは公開されません。
お名前:
E-mail:
コメント:

«前の日記(2008年02月03日)最新次の日記(2008年02月05日)»編集
Sponsored byRuby Association
Generated bytDiary version 5.3.0
Powered byRuby version 3.4.7-p58

[8]ページ先頭

©2009-2025 Movatter.jp