プログラミングは一朝一夕に達成できるものじゃない

http://anond.hatelabo.jp/20130322031333

プログラミング出来る方法教える。

書いた本人に悪意があったかどうかは知らないが,予想通り結果的に初心者を惑わせるだけの悪質な記事.

まあこの手の奴は99%デマと考えてよい.このくらいの文章量では,プログラミングができるようになる方法を記述するには全然足りない.


一応ツッコミは入れておく.

世の中「プログラミング言語」を説く本はごまんとあれど「プログラミング」を説く本やブログはあまりない。

ほとんどのプログラミング言語本は,多かれ少なかれプログラミングのやり方も含めて説明している.

C実践プログラミング 第3版

C実践プログラミング 第3版

Javaチュートリアル 第4版 (The Java Series)

Javaチュートリアル 第4版 (The Java Series)

  • 作者: シャロンザクァワ,ジャコブロイヤル,アイザックラビノビッチ,マークホーバ,トーマスリーサ,スコットホンメル,Sharon Zakhour,Isaac Rabinovitch,Thomas Risser,Jacob Royal,Scott Hommel,Mark Hoeber,安藤慶一
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2007/11
  • メディア: 単行本
  • 購入: 12人 クリック: 505回
  • この商品を含むブログ (8件) を見る


「プログラミング」全般を扱う本がなぜないかというと,一つには非常に広範囲で多岐にわたるネタを扱う必要があるために膨大な文章量になるから.そしてあまりに広範囲にわたるために,いかにベテランプログラマーでも一人で執筆するのは不可能に近い.*1 *2

プログラマが知るべき97のこと

プログラマが知るべき97のこと

初心者必読の書.

それぞれのネタを2ページで軽く扱うだけでも,本一冊分になるのだ.しかもそれぞれの項目毎に,下手すると本一冊以上のネタがあるのだから,全体として網羅しようとすると本棚1〜2個埋めるくらいの書籍が必要になるんだよ.ブログ程度で書けるわけが無いでしょ.

プログラミング作法

プログラミング作法

プログラミング入門本としては古典.ただしまともな大学の情報系に進んだ人なら,これに相当するくらいの知識は既にたたき込まれてるはず.

プログラマのためのサバイバルマニュアル

プログラマのためのサバイバルマニュアル

http://d.hatena.ne.jp/JavaBlack/20120505/p1
これも初心者にはお勧め.読んで損は無いと思う.


リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

ソフトウエア開発 55の真実と10のウソ

ソフトウエア開発 55の真実と10のウソ

http://karetta.jp/book/okite , http://www.pro.or.jp/~fuji/mybooks/okite/
この辺りも,初心者なら一通り目を通しておいた方が良いと思う.


達人プログラマー―システム開発の職人から名匠への道

達人プログラマー―システム開発の職人から名匠への道

  • 作者: アンドリューハント,デビッドトーマス,Andrew Hunt,David Thomas,村上雅章
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2000/11
  • メディア: 単行本
  • 購入: 42人 クリック: 1,099回
  • この商品を含むブログ (347件) を見る
CODE COMPLETE 第2版 上 完全なプログラミングを目指して

CODE COMPLETE 第2版 上 完全なプログラミングを目指して

あとはこの辺かな?ただし必読ではないが.


この辺りについては気が向いたら加筆修正して,別記事にまとめなおすかもしれない.

例えば、「計算機プログラムの構造と解釈」や「実用 Common Lisp」、「コンピュータプログラミングの概念・技法・モデル」などの書籍は現実の問題に対し "プログラム" をどう書くかという問題に正面から取り組んでいる良書だ。

計算機プログラムの構造と解釈

計算機プログラムの構造と解釈

コンピュータプログラミングの概念・技法・モデル (IT Architects' Archiveクラシックモダン・コンピューティング)

コンピュータプログラミングの概念・技法・モデル (IT Architects' Archiveクラシックモダン・コンピューティング)

「実用Common Lisp」はともかく,それら以外はどちらかというと「プログラミング理論」とでもいうべき分野であって,プログラミング入門本じゃ無いと思う.*3 *4

この違いも分かってない時点で,こいつの能力に疑問が出る.

初めてのプログラミング 第2版

初めてのプログラミング 第2版

はじめから間違った理論や極論を引用し,それが間違ってると主張することで専門家を嘲笑の対象とする.これも詭弁術の一つでは無いか.

というのも、多くの人は計算機科学を学び、効率のよいアルゴリズムとデータ構造、美しい階層化・モジュール化されたプログラム、などを作るためにプログラミングするのではない。目の前の問題を解決するためにプログラミングを行うからだ。

多くのプログラマーは,問題を解決するために「計算機科学、アルゴリズムとデータ構造、美しい階層化・モジュール化」,オブジェクト指向プログラミング,デザインパターンなどを手段として使うんだよ.

関連:http://postd.cc/confessions-of-an-intermediate-programmer/

今回はそのような”純粋にプログラミングを楽しんでいる人”に向けた文章でない。

現実の問題をプログラミングを用いて取り組んでいる人に向けて書いた文章だ。

これも詭弁だろう.

この文章もプログラミングを用いて取り組んでいる人の視点では無い.


どちらかというと,

プログラマーになろうと思って勉強してみたけど,アルゴリズムとデータ構造やOOPとかGoFとかがさっぱり分からなくて挫折して,それで「オレがプログラミングができないのはオレが悪いんじゃ無い.社会の方が悪いんだ.」「わたしの豊富な経験からいうと,OOPとか高度なプログラミング手法なんて糞の役にも立ちません!」とか主張し始めた.

オレは「現実の問題をプログラミングを用いて取り組んでいる人」であって,高度なアルゴリズムが実装できたり,難しい数学や理論が理解できたり,OOPGoFやDesign by Contractみたいな『難しい理屈』を使いこなすような「純粋にプログラミングを楽しんでいる人」とは違うんだ.オレの方が実践的で偉いんだあ.

と主張しているプログラマー脱落者の泣き言に見える.

上級者レベル

  • 現実の問題に対して適切なデータ構造とアルゴリズムを選択できる
  • 抽象化について理解し、可変部分と不変部分を考慮した設計ができる

これが上級者?やけに能力が低い上級者だな.


適切なアルゴリズムとデータ構造を「選択できる」のは初級レベルで,「一般的なアルゴリズムとデータ構造を,設計,実装,改良できる」のが中級者.「最先端のアルゴリズムとデータ構造を実装したり或いは発明したり,アルゴリズムを最速の形で実装・チューニングできる」のが上級者だと思うけどね.

というか,この「上級者レベル」って,コレを書いた人のレベルのことじゃないかなあ.こういう文書を書く以上は自分は上級者のつもりだろうし,書いた人は自分がこの上級者のくくりに入るように書いているだろうから.


アルゴリズムイントロダクション 第3版 第1巻: 基礎・ソート・データ構造・数学 (世界標準MIT教科書)

アルゴリズムイントロダクション 第3版 第1巻: 基礎・ソート・データ構造・数学 (世界標準MIT教科書)

アルゴリズムイントロダクション 第3版 第2巻: 高度な設計と解析手法・高度なデータ構造・グラフアルゴリズム (世界標準MIT教科書)

アルゴリズムイントロダクション 第3版 第2巻: 高度な設計と解析手法・高度なデータ構造・グラフアルゴリズム (世界標準MIT教科書)

アルゴリズムに関する定番「教科書」.かなり硬派なので,初心者がいきなり読んでも消化不良を起こすだろう.一方で,このくらいの本をマスターできなければ,どのみちまともなプログラマーにはなれないので,そういう意味でも一度本屋で立ち読みしてみると良いと思う.


アルゴリズムクイックリファレンス

アルゴリズムクイックリファレンス

アルゴリズム集.初心者向けでは無い.

本に載っているプログラムをそのまま書き写す(いわゆる写経)

学習法としての写経自体が,ごく最近出てきた都市伝説レベルの一つだと思う.いったい誰が言い始めたのだろう.*5

んなものが役に立つなんて思ってる方が頭おかしいので,特別に自慢するほどのことでもない.

特に最初のうちは、エラーをなるべく多く出した方がよい。

なぜならば、エラーを出すごとに、その言語の新しいルールを1つずつ学んでいくことになるからだ。

PHP で例えると、

プログラムの初心者が,その学習過程のどこかで「エラーを出しては潰す作業」を経験する必要はあるけど,それで成長するかと言われるとそうでもない.


それに,なんでSyntax Errorの例でPHPを引用するかな.ひょっとして筆者はPHP以外の言語を知らないんじゃ無いか?

PHPは言語仕様がいいかげんすぎる糞仕様なので,シンタックスエラーを消しただけで安心してはいけない.この例における極めて優れた反面教師だ.こういう練習を積む初心者としては,PHPではなくJavaとか他の言語をお勧めしたい.

そしてJavaのような言語であってもSyntax Errorを消してからが,本当のデバッグの始まりだ.そこからの方がずっと長い.

実際にエラーに遭遇した時に大事なのはエラーに遭遇した時にいかにその原因を突き止めるかだ。

期待しない動作をした時のデバッグという。

まずいちばん基本的で一番重要なデバック方法は printf デバックである。これをまず出来るようにする。

怪しい変数をとにかく printf で出力し、変な値が入っていないかを確かめる方法である。

printfデバッグはもっとも原始的で有名ではあるが,最も低レベルで粗悪なデバッグ手法だ.

時に最後の砦になることはあるので一応は知っておくべきだが,可能ならば使うべきでは無い.「最も重要なデバッグ手法はprintfデバッグです(キリ)」とか答えると赤っ恥をかくので注意するように.


デバッガはその次くらい.*6 時に必要になることもあるので覚えておくべきだが,実はあまり強力なデバッグ手法では無かったりする.


デバッグ手法としては,printfデバッグよりむしろアサーションとかロギングとかユニットテストを覚えるべし.*7

そしてそれと同じくらい重要なのが,「正しい動作とは何か?」「その時の内部状態とはどうなっているか?内部状態がどうなっていれば正常で,どういう時は異常と言えるのか?」というのを,常に意識すること.それが分かってないと,内部状態をどれだけ詳細に調べても,それがバグなのかどうなのかを定義できなくなる.

各言語にはいわゆる"定石"と言われるデバッグ方法があるはずで、それらを検索し習得すること。

アサーションやロギングやユニットテストは定石でないとでもいうつもりか?

初心者だからこそ、デバッグの方法論や開発環境をきちんと整えるべきである。

この意見には賛成だが,それで主張するのがprintfデバッグとデバッガという当たりが,大きく間違っているような.

デバッグの理論と実践 ―なぜプログラムはうまく動かないのか

デバッグの理論と実践 ―なぜプログラムはうまく動かないのか

実践 デバッグ技法 ―GDB、DDD、Eclipseによるデバッギング

実践 デバッグ技法 ―GDB、DDD、Eclipseによるデバッギング

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)

むしろこっちの方が良くないか?*8

最初の内は、基本的にプログラミングする時は小さな部品に別けてから1つずつ確かめながら作る習慣を付けるようにする。

間違っては無いが,かなり高い確率で初心者には誤解される表現だと思う.

そもそも部品の切り分けやAPIの設計は,初心者には荷が重すぎる.そういう部品の切り分けは決して簡単なテクニックでは無いのは,GoFとか読めば分かるはず.

オブジェクト指向における再利用のためのデザインパターン

オブジェクト指向における再利用のためのデザインパターン

また複雑なプログラムにおいては,「正常動作を定義する」ことさえ初心者には荷が重かったりするものだ.

「オモチャのプログラムでは正常動作と異常動作の区別はたやすい.factorial(n)は正しい数値を返しているか?それをチェックするのは簡単だ:一つの数値が入力され,別の数値が出力される.しかし大きなプログラムでは,関数の引数だけでなくシステムの内部状態も含む多数の入力が存在し,そして多数の出力や副作用が存在する.これらのチェックは(オモチャのプログラムと違って)容易ではない.」

http://d.hatena.ne.jp/JavaBlack/20120505/p1

たとえば「疑似乱数が本当に乱数として使えるか?十分にランダムであるか?」を検証する方法などが好例.

おそらく多くの初心者は手も足も出ないし,ソフトウエア工学を専攻した者でも容易には答えられない難問の一つ.この辺りはソフトウエア工学上,重要な課題の一つなので調べればいろいろと出てくると思う.興味があれば調べてみると良い刺激になるだろう.

4 Google を使い倒す

これも比較的最近*9出てきたテクニックで,時に非常に強力である.的確なエラーメッセージを出力してくれる広く使われている言語,データベース,OS,フレームワーク,ライブラリ等を使っている場合には非常に役に立つ.

一方で自分たちが作ったプログラムや,マイナー又は最新バージョンの言語,データベース,OS,フレームワーク,ライブラリ等のデバッグには全く役にも立たないことも多い.的確なエラーコード/エラーメッセージを返してくれないものの場合も同様だ.*10特にマイナーな製品の最新バージョンの新機能の場合などは,時間の無駄になる可能性の方が高いのでそのつもりで.



この文章からどんな人か推測(或いは妄想)してみよう.

  • 専門教育は受けていない.*11
  • 専門書もあまり知らない/読んでない.
  • 良い師匠がいない.ほぼすべて独学かも.
  • 一方で,「計算機プログラムの構造と解釈」や「実用 Common Lisp」、「コンピュータプログラミングの概念・技法・モデル」という小難しいタイトルはなぜか知っている.
  • 「効率のよいアルゴリズムとデータ構造、美しい階層化・モジュール化されたプログラム」を武器として使いこなせてない.
  • デバッグ技法が重要だとは認識している.しかし体系的なデバッグ手法を学んだことが無い.
  • printfデバッグを重要なデバッグ手法だと思っている.

このことから,たとえば

彼(or彼女)は畑違いの分野から「学歴不問・未経験者歓迎」で求人している底辺ブラックIT企業に入社し,そこの先輩から上記のような小難しい本を紹介されるも,それの何がいいかがサッパリ理解できていない.ひょっとしたら先輩から学習法として「写経」を勧められたのかもしれない.

加えてその先輩たちは口は達者だがプログラミングスキルは非常に低く,彼が独学で会得した「printfデバッグのようなデバッグ手法」の足下にも及ばない程度のスキルしか無い.

彼本人のスキルは決して高くないのだが,その会社に勤める先輩の方がさらに低いスキルしか持っていないために,自分を過大評価してしまっている.自分のいる会社が底辺で,先輩たちもそれ相応にスキルが低いということに,まだ気付いていない.

みたいな場合も考えられる.技術力の低い会社はとことんまで低いから.

例えばそんな感じの人が自分の経験に基づいて書けば,こういう文章になると思う.



関連

  1. 良い本を読め.
  2. 良いコードを読め.
  3. 優れたプログラマーに師事しろ.間違ってもスーツ(笑)な人に師事するな.
  4. 自分でコードを書いて実践しろ
  5. それでもダメなら才能がないから諦めろ.

特に最後が重要.

http://d.hatena.ne.jp/JavaBlack/20100814/p1

http://b.hatena.ne.jp/entry/anond.hatelabo.jp/20130322031333

  • id:raitu デバッグ」でなく「デバック」と書きまくってる時点でちょっと怪しく思ってしまいましたデバッグ重要という割に、自分の文章をデバッグできてなくね…?

うあ,本当だよ……

「バグ」は超基本単語だし,デバッグはdebugなので間違うわけないのに.*12


ということは,この点でも超絶初心者の可能性が高いか.

  • id:okra2 ところが専門の学校でそれなりに勉強してきてもなお、条件分岐すら理解できない人間もいるので、人間やっぱり向き不向きはあろう。

まず最初にこれが一番重要だと思う.


FizzBuzz問題で躓くような人は,200%才能が無いから他の道に進んだ方が幸せになれると思う.*13

  • id:kirine 「プログラム出来ない人」はそも素養がないので諦めた方がみんな幸せ。「これからプログラムを始める人」ならまずはコーチ探しから。自分で調べる姿勢も大事だけど検索エンジンなしじゃ何も出来ない人をよく見かける
  • id:isseium 運の要素もあるだろうけど、技術の師匠をみつけることが一番だと思ったり。あとはめげずにプログラミングを好きでいること。

これも同意.

それと真面目にコーチ探しをするなら,まともな大学に行った方が早いよ.

  • id:fut573 他人にコード読んでもらわないととんでもない間違いに気が付かないことがあるから、読んで貰う機会が大事だなぁと僕は思うわけだけど。

そのためにもコーチ探しは重要.

初心者は糞コードを書いても,それが糞だと気付かない.

  • id:blue1st コードの美しさみたいなものを意識できるようになるのが重要だと思ったり。

改訂新版 Cプログラミング診断室

改訂新版 Cプログラミング診断室



  • id:SUM 熟読するつもりないけど、こういうのを書きたくなる年頃というのは案外と少なくない人が経験しては黒歴史を残すものと昔から相場は決まっている
  • id:kyon_mm これに共感するくらいなら、エンジニアやめたほうがいい。まぢダサくて吐き気がする。

すごく納得.

そら匿名で書くべきですね.生暖かく見守ってあげましょう.

  • id:okoppe8 確かに最初は体育なんよ。自転車の乗り方を転んで覚えるのに似ている。

それが自転車なら転びながら覚えることもできるだろう.

しかしそれと同じくらいに,たとえ初心者といえど「他の人が乗ってるのを見て,既にやり方を知っている」というのは忘れちゃいけない.自転車の乗り方について全く何も知識がないままに,ただ自転車本体のみを与えられて乗れるようになったわけでは無いのだ.仮にできたとしても難易度は格段に上がってしまう.*14


ましてそれが自転車でなく飛行機だったら?
シミュレータを使って墜落の危険がなくとも,十分な知識無しに離陸から着陸までこなせる人間などいないだろう.

ジャンボ・ジェットを操縦する―B747-400の離陸から着陸まで (ブルーバックス)

ジャンボ・ジェットを操縦する―B747-400の離陸から着陸まで (ブルーバックス)

そして実際に仕事として飛ばす場合は,絶対に落ちないようにあらゆる状況を想定した訓練が必要になるのだ.それこそ「ハドソン川の奇跡」を起こすことを求められるのがプロのパイロットなのだから.

  • id:kany1120 何をしてもエラーが出てくるし、何をしても上手く動作しない。だから僕は初心者のうちで一番大事な能力とは、実は "忍耐力" だろうと少しばかり思っている。

その能力はいつまでたっても必要.熟練者だからといって挫折を経験しないなどとは思って欲しくない.

デバッグスキルが重要」というなら同意するが,「上達の要」と言われると違う気がする.

優れたプログラマはすべからく高いデバッグスキルも持っているが,デバッグスキルを磨いたからといってプログラミングスキルも上達するかというと,そうとは限らないだろう.

プログラミングの上達においては,むしろ「バグを事前に防ぐにはどうするか?」の方が重要.特にマルチスレッドプログラミングともなると,大半のデバッグスキルが無力になる.良いコードを書くためには,コードを書く前に既にどんなバグが出てそれをどうやってデバッグするかが分かってなければならない.*15その点においてデバッグスキルは良いコードを書くための基礎となるスキルの一つ.

http://karetta.jp/book-node/okite/003137
http://d.hatena.ne.jp/JavaBlack/20101201/p1

  • id:ckh23020 中級者が上級者になるために重要な部分とか教えて欲しかった。1万行以上のプログラム一人で書いて完成させられる人とかどういう手順で取り組んでるのか知りたい。

などなど.

それぞれの項目一つで本一冊以上書けるくらいのネタだと思う.

  • id:oukisyougun 2chで見た事ある
  • id:gasparl VIPにスレ立ってまとめブログで読めそうなネタが何故か増田に。/2chは規制にでも巻き込まれたのか?

2chのまとめレベルか.納得.

  • id:thesecret3 新卒の初心者が研修受けただけで現場に来て書いたプログラムって1メソッドに2000行とかあって謎のフラグが混乱してて、全部読んでも何がしたいのか不明ってのが普通だと思う。

情報系学部卒以外の新卒の話ですよね?情報系卒ならそのくらいできなきゃ恥.

  • id:snow113 この分野の上達とは、言語をたくさん覚えることではないのに、世の中には言語のチュートリアルが多すぎる

イコールではないが,中上級者ならパラダイムの異なる数種の言語を学び,そのうち複数の言語を自在に操る能力を持っていると思う.異なる言語,異なるプログラミングパラダイムを学ぶことは,自分のスキルを磨く手段の一つ.

  • id:ledsun 「プログラミング」を説く本には「プログラミング作法」と「達人プログラマー」という名著がある。どっちか読むといい。(俺がプログラマ1年生に読ませてる理由が分かって参考になった。)
  • id:luccafort 言いたいことはわかるのだが中級と上級の差が狭くないかい?と思ったり。どっちかというとここで定義している初心者向けなんだろうなー。
  • id:hikalin8686 上級者の枠が大雑把すぎる。その上にさらに3段階くらいあると思うけど
  • id:zz_sexy 目の前の問題を解決するために「効率のよいアルゴリズムとデータ構造、美しい階層化・モジュール化されたプログラム」が強力な武器であることに気がつけないならまだまだかなあ。
  • id:aoi_tomoyuki 中級者になれずに経験だけはやたらと長い初級者が一番厄介。ナチュラル難読化スキルが常時発動してる。
  • id:kaiteki61 本質の議論が少なくてアドホックな対策の議論が多いっていうのはなにもプログラミングに限った話ではないし,ネット以外のメディアでもそうだとおもう
  • id:happy_siro いろいろ間違ってる気がする
  • id:kabutch 本当の初心者はどういうプログラム言語があるか、それをどうやったら動かせるかも分からない。まずはそこから解説しないと。
  • id:shsh0shsh プログラムなんてできたところで大して役に立たんぞ

「これからプログラミングを覚えようと思う」という人のうち、純粋に興味がある人か、実現できたら楽しそう・儲かりそうなアイデアがある人であれば是非、と思いますが

単に”手に職つければ就職できそう”とか、ざっくり「Androidアプリ作ったら儲かりそう」くらいであれば、あまりお勧めしません。きっと、もっと幸せになれる方法があります。

http://blog.techboon.info/?p=261

そだね.

同意せざるを得ないのが悲しい現実.

  • id:moondoldo この増田の文章にプログラマの方々が脊髄反射しすぎ これは問題解決するためにプログラミングをしたいけど上手く出来ない人への話であって、プログラマになりたい人への話じゃないでしょ

違うと思う.

本文中でも

しかし、どれだけ”普通の”プログラマが上記のような書籍を読んでいるのだろうか。

そして、"普通のプログラマ" がプログラミングを学ぶ書籍として、それらは果たして適切と言えるだろうか。

僕はそうは思わない。

というのも、多くの人は計算機科学を学び、効率のよいアルゴリズムとデータ構造、美しい階層化・モジュール化されたプログラム、などを作るためにプログラミングするのではない。目の前の問題を解決するためにプログラミングを行うからだ。

のようにあることから判断して,この文章は初級プログラマ向けに書かれている.*16

且つ,たとえその人がプログラマ志望でないプログラミング学習者だとしても,その学習方法についてはプログラマを目指す学習者となんら変わりは無い.

  • id:RyuichiXP これは後世にも語り継がれるべき文章。ここにだすのがもったいない。
  • id:tyoro1210 いい事書いてるけど、初級者に向けるには ちょっと前置きが長いのと、pre記法の所為で全体的に文字が小さくて読みづらい。 / 内容はもっともだと思うので、ブコメにけっこう批判的なのが多くて意外。
  • id:katagirishuujin 勉強しようと思っていた所。よさげなのであとで見よう
  • id:kirishima2813 こんな有用なプログラミング学習法を増田で発表しちゃうのか、それが実に勿体ない。確かにブクマ数は伸びるが、経験値の羅列だけでは、初心者の関心は得られないだろう。
  • id:originalorange プログラミング初心者としては役立つようなページでした。
  • id:atcgouch 「有益なことなのに増田に書いちゃう奴ちょっと来い」というエントリを書くチャンス
  • id:so-do12 いいこと書いてある気がする。
  • id:tmura3 この増田は素晴らしく熱くわかりやすいので是非
  • id:mad_ochi え、なにこんなクソ当たり前なことでありがたがってんのさすがはてブ情強!wwwwww
  • id:penpen-0704 良い事書いてありそうだけど読みにくすぎて挫折した
  • id:tyoro1210 いい事書いてるけど、初級者に向けるには ちょっと前置きが長いのと、pre記法の所為で全体的に文字が小さくて読みづらい。 / 内容はもっともだと思うので、ブコメにけっこう批判的なのが多くて意外。
  • id:himeatball プログラミング出来る奴も読むべき。増田に書くにはあまりにも勿体無い…
  • id:windscape これはいい記事
  • id:wizard23104 イイ事書いてあるなぁ・・・。心構えとして覚えておこう。
  • id:shields-pikes これは後でよく読もう。

正直に言って,あまり良い内容では無いと思う.100点満点中で10点〜20点くらい.「もっとがんばりましょう」レベル.

twitter

そういうことはあるかも.

特定環境に依存しているのはデメリットだが,同時に具体的に書きやすいのは初学者には大きなメリットでもある.

同意.

それは無理じゃ無いかな.

「難しいことを努力せずに,短期間で,金もかけずに楽して簡単に教えてもらう」というのは初学者の永遠の夢.

断定はしないが,ありそうな話ではある.


新人教育に限定してさえも,中身はかなりヒドイよ.

これを素晴らしいと言ってる人は,プログラミングができない人と考えて,まず間違いない.


http://ja.wikipedia.org/wiki/UNIX%E5%93%B2%E5%AD%A6#.E3.82.AC.E3.83.B3.E3.82.AB.E3.83.BC.E3.82.BA:_UNIX.E3.81.AE.E5.93.B2.E5.AD.A6

ソフトウェア工学は失敗している」のか?

追記

  1. ソフトウェア工学は失敗している」 http://d.hatena.ne.jp/nowokay/20130322#1363969460
  2. ソフトウェア工学は失敗している」のか? http://togetter.com/li/476197

これと同じ流れを感じる.

1では「特に学術的にソフトウェア工学に触れたことはないのですが、」とマトモにソフトウエア工学を勉強したことも無い人が,「自分の知ってるソフトウエア工学」は失敗してるように見えると主張.
たとえば「CMMの失敗がソフトウエア工学の痛手」とか言ってるけど,CMMなんて今じゃソフトウエア技術者からは最初から真面目に議論さえされてないトンデモ系なわけであって,痛手だと思っているのは日本のお役所とSIビジネスくらいのもんじゃないかと思う.

そして,その辺に対する反論がTogetterにまとめられてる.


でもこういう「分かってない」人達の妄言を放置しとくと非常に危険.面倒でも毎回潰しておかないとえらいことになることがある.

日本「半導体」敗戦 (光文社ペーパーバックス)

日本「半導体」敗戦 (光文社ペーパーバックス)

また「半導体なんて装置を買って並べれば誰でもできる」と断言する人々にも多数であった.社会科学者だけでなく,政府関係者やマスコミの方からも同じ事を言われた.これが間違っていることを示すために,「半導体は装置を買って並べただけではできない」ことを証明する論文を書くことにもなった.

これは笑い事ではすまされない.「わかっちゃいない」社会科学の論文や,「半導体なんて装置を買えば誰でもできる」ことが書いてある本や記事が,経済産業省などの官僚が政策立案する際の参考にされていたりするからである.その結果,まったく日本半導体の実情に合わないようなコンソーシアムや国家プロジェクトができてしまう.さらに,ここに多額の税金が投入される.まったく笑い事ではない.

http://d.hatena.ne.jp/JavaBlack/20091207/p1

「写経」と"Learn Python The Hard Way"

コメントで指摘されたので, Learn Python The Hard Way, 3rd Edition を見てみた.

With the help of this book, you will do the incredibly simple things that all programmers need to do to learn a language:

  1. Go through each exercise.
  2. Type in each sample exactly.
  3. Make it run.

That's it. This will be very difficult at first, but stick with it. If you go through this book, and do each exercise for one or two hours a night, you will have a good foundation for moving onto another book. You might not really learn "programming" from this book, but you will learn the foundation skills you need to start learning the language.

http://learnpythonthehardway.org/book/intro.html

「『プログラミング』の学習にはならないかもしれないけど,(python言語学習に必要となる基礎スキルを身につけることができるだろう.」みたいな話になってる.

またここで出されているサンプルコードはどれも簡潔で,超初心者が手入力でポチポチ入力するために厳選されているものであるようだ.

  • 初心者以前の人が,プログラミング入門以前の基礎の基礎を学ぶための学習法.
    • 細部に注意する習慣
    • @とか'とか$のような特殊(?)記号を識別すること,時にその読み方を覚えること.
    • 一字一句間違わずに入力するスキルや習慣
    • 一文字でも間違えたらエラーになることに慣れておく
    • エラーメッセージが出た時の対処の仕方
  • 入力するのは,この本の厳選された短いサンプルコード
  • 各項目にはコードだけでなく,多くの解説が付随する

みたいな話.


もしこの本が「写経」の原典だとすれば,「プログラミング学習に写経が有効」というのは,少々歪曲されて伝えられた結果な気がする.*17

余談

にしても,こんなたわいも無い記事が,なぜにブクマ数700オーバーしたのかは謎.
ひょっとして季節的な物?ITブラック企業に内定している新卒がそれだけ多いからとか?


たしかにこの文章自体はズブの素人向けではないが,書籍については初心者向けにかなり絞り込んである.たとえば「 The Art of Multiprocessor Programming 並行プログラミングの原理から実践まで 」とか「 コンパイラ―原理・技法・ツール (Information & Computing) 」とか「 コンピュータアーキテクチャ 定量的アプローチ 第4版 (IT Architects’ Archive) 」のような本は,名著ではあっても初心者向けでは無いから紹介していない.
アルゴリズム・イントロダクションについては,初心者には難しすぎるかもしれない.ただし適切な師匠なしに,独学でアルゴリズムとデータ構造を勉強するための日本語で書かれた「教科書」としては,今出ている中でも最有力候補の一つだ.

それとリンク先の元記事についても,あれは「初心者向け」ではない.仮に筆者が初心者向けに作っていたとしても,決して初心者のためにはならないよ.

*1:しかも技術の進歩と共にプログラミングパラダイムも二転三転しているので,古い名著に書かれているテクニックが,必ずしも現在のプログラミングでそのまま使えるとは限らない.

*2:日本以外ではプログラマーは専門職なので,大学進学して専門教育を受けるのが普通だから,プログラミング全般を扱った入門書のニーズが少ないというのもあるかもしれない.

*3:言語学」と「英会話入門」くらいの違いがある.

*4:ていうか,プログラミング作法も知らんのか?この本については著者名を見て,あのK氏と気付いて欲しいくらいなんだけどな.

*5:自分が初めて見たのは,たぶん2011年11月.それ以前は不明だけど,長くてもせいぜいここ数年ではないだろうか. http://d.hatena.ne.jp/JavaBlack/20111104/p1
もっと早い時期に,いつどこで見たことがあるという情報は歓迎します.

*6:デバッガという単語も出てきていないけど,まさかひょっとしてデバッガを知らない??

*7:まさかとは思うが,筆者はアサーションやロギングを知らないんではあるまいか?

*8:「テスト自動化ツールを導入済みは8.5%、85%以上が検討していないか必要を感じない」.テスト関連本リストアリ. http://d.hatena.ne.jp/JavaBlack/20120602/p2

*9:といっても10年くらいたってるけど

*10:完成度の低いオレオレフレームワークやライブラリだと良くある話.そういう時は同時にドキュメントも整備されてなくて,結局はソースコードを読まないとデバッグする手がかりさえ得られないことも多い.オープンソース製品でも,まだできたばかりで知名度も完成度も低い段階だと,十分に的確なエラーメッセージを返してくれないことも多いだろう.メッセージ自体が間違ってることだって,そんなに珍しい話では無い.

*11:専門知識がスッパリ抜け落ちているため.専門教育を受けてなくても独学で専門知識を持っている人もあるが,専門教育を受けていながら専門知識を全く持っていない人間は珍しい.

*12:debugの日本語表記はデバッグで確定しているので,ガーベジコレクションのような表記揺れのせいではない.

*13:運動音痴な人がプロスポーツを目指すような物.運動音痴は認める人は多いのにが,なぜにプログラミング音痴を認めようとしない人がいるのか謎.

*14:一輪車とか竹馬とかベーゴマとかって,今じゃわりとそうなってないか?竹馬を乗ってるのを見たことが無い人が,一人で乗れるようになるのって割と厳しいと思う.
探せば解説書とかブログくらいはありそうだけどね.

*15:「新しい技/暗号を考える時は既に,その返し技/暗号解読法をも編み出している」的な話.

*16:内容は不適切だけど.

*17:「写経」を試している程度の日本人の超初心者プログラマー見習いが,この英語の文章をきちんと読んでるとは思えんし.orz