2010-08-31(火)
■そろそろIDEよりコマンドラインのほうが理解が深まるという有害な妄想は捨ててはどうか？ 
「Java入門ブックガイド（入門編)よりよき入門書と出会うために」を読んで。
第一印象として、よりよきJava入門ブックガイドに出会う必要があるなということ。
コマンドラインでは慣れ親しめない
サブタイトルに「慣れ親しむことが上達の秘訣」とあるけども、コマンドラインで慣れ親しむのは難しいと思います。
「慣れ親しむことが上達の秘訣」が正しいのであれば、IDEで慣れ親しんだほうが上達するのではないでしょうか？
現実問題として、書籍を買って勉強する人は強制されて勉強するわけではないです。自分の時間をやりくりして入門書を読んでいます。
そして、まだプログラムの面白さを知りません。
コマンドラインでコンパイルエラーが出たとき、じっくりとそのエラーを読み解くのではなく、そこでくじけてやめる可能性が高いと思われます。
それよりは、IDEでエラーを入力段階で修正しつつ進むほうがいいと思います。
javac/javaコマンドはJava技術の本質ではない
このような記述があります。
煩わしい作業の中にこそ、その技術の本質があったりするからです。
けど、少なくともコマンドラインでのコンパイル作業にJavaの本質はありません。
ぼくは長いことJavaのプログラム作ってますが、記事用の動作確認以外では、ここ数年はjavacコマンドでコンパイルしてません。実行時にはコンパイルされることもあまり意識してません。
意識しなくてもずっと仕事をやっていけるような部分に本質はないと思われます。
それより、オブジェクト指向のほうがJavaの本質に近いと思われます。オブジェクト指向を腫れ物のように扱って２分冊にするということのほうが、本質をはずしている気がします。
間違い探しはプログラムを組む訓練にならない
入門書のサンプル入力では、失敗した数だけ時間が多くかかるだけで、ほとんど学べることは増えません。
例えば、何かエラーが出たとします。統合開発環境を使わないのであれば、原因と思われるものを列挙し、丹念に個々の原因と思われるものを調べるうちに、失敗していなければ学べないことを学べるのです。
とありますが、ほとんどのミスが大文字小文字のミス、スペルミス、中括弧の抜けです。全角スペースが入ってしまっているというミスも多いです。
このようなエラーなら、おそらく、IDEの入力時のエラー訂正で十分です。
また、失敗していなければ学べないことを学べるようなエラーの場合は、IDEでも学べます。むしろそういうところに絞って悩めるので、有効だと思います。
コンパイルエラーをプログラムのエラーだと誤解する
入門者にとってはエンドレスと思われるこの作業こそ、エラーの少ないプログラムを作るための大変大切な訓練なのです。
とありますが、プログラムで減らすべきエラーはコンパイルエラーではなく実行時のロジカルなエラーです。
コマンドラインで勉強している場合、コンパイルエラーをとるのにあまりにも時間がかかるため、そこがゴールだと勘違いする人を多くみかけました。
けれども、実際はコンパイルエラーがなくなってからが勝負です。
コンパイルエラーを取るのに時間をかけるのではなく、ロジカルなエラーを取るのに時間をかけるべきです。
IDEのほうが調査範囲を広げてくれる
自分の狭い学習範囲を飛び越え調査することを怠るようになります。
とありますが、コマンドラインで学習しているからといって学習範囲を飛び越えて調査するとは限りません。むしろ、その可能性は低いです。
IDEのほうが、補完候補に「学習範囲を飛び越えた」内容を出してくれるし、修正候補にも「学習範囲を飛び越えた」内容を出してくれます。
Javaやライブラリのバージョンがあがったときに、補完候補から新しいAPIの追加を知ったという経験がある人も多いんじゃないでしょうか。
こちらのほうが、学習範囲を飛び越えた調査に結びつきやすいと思います。
大切な概念を学ぶ時間がとれない
たとえば、ぼくはjavacコマンドよりもデバッガやJUnitのほうが大切だと考えています。
「創るJava」ではコマンドラインの解説がないのは、コマンドラインの解説に20ページも取るのであれば、デバッガやJUnit、バージョン管理の説明をしたほうがいいという判断です。
ロジカルなエラーを排除するには、デバッガやJUnitが不可欠です。
その代わりに失う代償を覚えておいてください。
という場合、コマンドラインでの勉強で失うものもちゃんと考えるべきだと思います。コマンドラインでの学習は、もっとも貴重な「時間」というリソースが失われてしまいます。
実際はコマンドラインでの入門のほうが理解度が低い
いろいろあげましたが、コマンドライン信奉者の人たちは、もっとも大切な事実をおそらく知らないのです。
それは、コマンドラインでの入門のほうが理解度が低いということです。
コマンドラインでの学習が時間がかかるものの理解が深まるということが事実であれば、ここまで強く批判はしません。実際には、時間がかかり理解も深まらないです。
プログラムを組んでることすら気づかないのです。
学校でのプログラムの授業の感想として「何をやっていたのかすら理解できない」というものを多く聞きます。プログラムが難しいというのではなく、その授業がなんだったのかすらわからないということです。
理解を深める以前の問題です。
コマンドラインのほうが理解が深まるというのは、もともと理解がある人だけがコマンドラインで学習できたというだけの話にすぎません。
コマンドラインで学習することができた数少ない人を見ての誤解です。
はっきり言って、この記事にあるような、コマンドラインで理解が深めれるというのは、実際の入門者を見たことがない人の妄想としか言いようがありません。
それを信じてしまってコマンドラインで入門してしまうと、多くの人はくじけてしまいます。
それでくじけるようならプログラムなどやらなければいい、という考えならかまわないですが、それは入門書ガイドでやることではありません。
コマンドライン使ってもコマンドラインの使い方しか覚えれない
よいプログラムを組めるようになるためには、アルゴリズムなどの勉強が必要です。
コマンドラインをいくら使ったところで、その勉強の代替にはなりません。
Javaの勉強はIDE使ってとっととすませて、アルゴリズムなどの勉強したほうがよいと思います。
プログラム言語を深く知らせたいなら(2010/09/01 3:05追記)
プログラム言語について深く教えたいなら、javacコマンドでなやませるより、JavaCCでも使ってスクリプト言語作らせればいいと思う
プログラムが組める人にしたいなら(2010/09/01 3:05追記)
プログラムがちゃんと組める人にしたいなら、javacコマンドでなやませるより、計算理論の基礎とかアルゴリズムデザイン読ませてTopCoderやらせまくったほうがいいと思います。
20代の私からすると、「取っ付き難くてめんどくさいなぁ」というのが本音です。
同感です。コンパイルエラーに関する調査で勉強になることってまず感じた事無いです。
現在のIDEってコンパイルエラーに関してはリアルタイムでストレスなくずっとチェックしている状態ですもんね。理想のエラー発見は実行時エラーではなく全てコンパイルエラーとして検出されるべきなら、静的言語とIDEはマッチしてるなあと感じています。
「学習範囲を飛び越えて調査」に関してはEclipseのほうが遥かに優れていると思います。キーボードショートカットで定義箇所を辿って行けますし。
補完が役にたつってのも理解できないです。直前の変数名の補完ならわかります。
定義場所にジャンプするのはviでも昔からできます。多重定義とか継承でシンプルには行かなくなってしまいましたが。
最近のIDEが初心者に使いやすいかどうかは謎ですが、「IDEよりコマンドラインのほうが理解が深まる」というのは初心者に対するプレッシャー以外の何物でもないと思います。
IDEでひととおりやったあとでコマンドラインをやったほうが、コマンドラインからやるよりかなり効率が高いと思います。
IDEからしか実行できない人が平気でいることもあるので。
【ソースファイル→(コンパイル)→classファイル→(クラスローダ)→実行イメージ】
とか
【ソースファイル→(コンパイル)→オブジェクトファイル→(アーカイバ/リンカ)→ライブラリ→(リンカ)→実行ファイル→(OS)→実行イメージ】
とかを頭の中にイメージできるようにすることなんじゃないかと思うんですが。
そしてそれは、CLIを使えば理解できるというわけでもなければ、GUIを使ったら理解できなくなるというものでもないでしょう。
いま、javaコマンドでプログラムを起動する必要性はほとんどないですよね。
多くはWebアプリケーションだし、デスクトップアプリケーションならjarファイル作ってダブルクリックすれば起動するわけだし。
サンプルならIDEから実行すればいいと思います。
javaコマンドの説明は、時間があまったときのオプションのひとつで十分に思います。ぼくはjavaコマンドをしらなくて平気ということより、クイックソートをしらなくて平気ということのほうが問題と思っています。
僕はIDEはむしろ中級以降の人の作業効率を上げるためのツールの「一つ」としての側面のほうが大きいんじゃないかと思ってます。
異論反論が巻き起こると思い、IDEは補足とさせていただきました。いろいろな意見を聞けて非常に参考になりました。私自身、仕事ではEclipse、自宅ではNetBeansを使っています。ディベートと同じようにコマンドライン側で発言し、反論を待っていました。