プログラマの適性検査

より.

追記:元ネタの元ネタになったブログの後日談かな?

まず,元記事では「60%の人間はプログラミングの素質がない」というタイトルになってるけど,どうも元の論文ではそういうことを言ってないように思う.あくまで「適性検査の可能性」についての実験結果と提案であって,そこまで精度の高い適性検査が可能になったわけではないし,不特定多数の候補者に対し広範囲に長期間にわたって継続調査をしたわけでもないようだ.(そりゃそうだ.)

自分なりにまとめると,

  • プログラミングにおいては「すごくできる人」と「全然できない人」の二つのコブができて,しかもそれが明確に分かれるというのは,経験的にはよく知られた話である.*1
  • 「優秀な大学に進学し(学力があり,勉強が得意.いわゆる「頭が良い」),コンピューターサイエンスを専攻した(プログラミング習得の熱意もある)ような人達が,つまりは「極めて優秀で頭も良い」はずの人達が,なぜ全くプログラミングができずにどうしようもないほどの落ちこぼれになるということが頻繁に起きるのだろうか.*2
  • 様々な調査や改善が行われてきたが,ほとんど成果は出ていない.
  • これまでもプログラミングの適性というものがあるとは考えられていたが,今までそれを計る方法は見つかっていなかった.例の論文はその適性検査を提案している.*3
  • 実験の結果,「解答の一貫性の高さ」と「プログラミングの適性」には高い相関があった.
  • これは適性テストとして利用できると考えられる.
  • これはまた,「通常の学力とは独立してプログラマーの適性や素質というものが存在し,それはプログラミングを学習する以前の段階で既にある程度決まっている」という経験則を間接的に裏付ける物になっている.


ただし,(斜め読みだけど)元の論文では「60%の人間に素質が無い」とまでは断定していないように思う.このテストにはそんな精度は期待できないし,「素質の有無」というものは白黒が付けられるほど簡単なものではない.それを踏まえた上で,一般論として

  • 例えば「60%の人に素質がない」ことは「40%の人に素質がある」ということを意味しない.「あまりに低すぎて,あるかないか判定不能」も「素質が無い」とは断定できない.
  • 40%の「素質が無くはない」の中でも,「才能がある」と言える人はさらに少ない.*4 *5
  • 「才能がある」人でも,その才能を開花させるにはたゆまぬ努力が必要不可欠.
  • 勉強ができて「頭が良い」人でも「素質がない」と,どれだけ頑張っても低レベルのプログラマーにさえなれない.それだったら別の分野に進んだ方が本人のためではないか?

ということは言えるだろう.

それと,ここまでくると仮説だけど,

  • 「一貫している」とは平たく言えば「(妥当な)メンタルモデルが構築されている」,即ち「理解している」ということを意味する.*6

ということも言えるのではないだろうか.

多くのプログラミング学習者が理解に苦しむ問題を調査した所、以下のような結果が得られた。

  1. 代入とシーケンス実行
  2. 再帰と繰り返し実行
  3. 並列実行

3は結構難しい.2は超簡単.1はつまずく人がいるのが驚かされるレベル.

1や2でつまずく人は,プログラマーを目指さない方が自分のためでもあるし人のためでもある.*7


あわせて読みたい

Javaスクールの危険」

私のささやかな経験から言わせてもらうと、伝統的に大学のコンピュータサイエンスのカリキュラムで教えられているもので、多くの人がうまく理解できないものが2つあった: ポインタと再帰だ。

大学では連結リストやハッシュテーブルなどについて学ぶデータ構造の授業が最初にあり、そこではポインタを徹底的に使う。この授業はふるい分けに使われていた。あまりに難しくて、コンピュータサイエンスの学位の知的な挑戦に耐えられない者は脱落していたのだが、それは良いことなのだ。もしポインタが難しいと思っているなら、不動点理論に関する証明で難儀するのを覚悟しておくことだ。

高校ではApple IIのBASICでpongゲームをうまく作れていた子供たちが、大学に入ってデータ構造の授業のCompSci 101を取り、話がポインタのことになると彼らの脳みそは吹き飛んでしまう。そしてこれはロースクールに進むほうが良さそうだと思って政治科学専攻に切り替えるのだ。コンピュータサイエンス学科のドロップアウト率の数字をいろいろ見たが、それは通常40%から70%の間だ。大学はこれを損失だと考えているようだが、私はこのふるい分けを不可欠なものだと思っている。彼らがプログラミングのキャリアで成功したり幸福になることはないだろうからだ。

http://local.joelonsoftware.com/mediawiki/index.php/Java%E3%82%B9%E3%82%AF%E3%83%BC%E3%83%AB%E3%81%AE%E5%8D%B1%E9%99%BA

どのような規則で回答するかというのは問題ではない。このテストでの評価は、ひとつの規則を、複数の似たような問題に首尾一貫して適用できたかどうかをみた。つまり、=は値を交換するという規則を推測したとしたら、ほぼすべての問題に対しておなじ交換の規則を適用した結果を回答した場合のみ、一貫したグループ(consistent group)とした。問題毎に違う規則で答えたものを、一貫していないグループ(inconsistent group)とした。何も書かずに提出したものを、空欄グループ(blank)とした。

割合としては、一貫したグループが44%、一貫していないグループが39%、空欄グループが8%であった。
(中略)
しかし、結果は異なっていた。もっとも高成績のグループは、一貫したグループであった。一貫していないグループと空欄グループに属する人間は、プログラミングの理解に苦しみ、試験の成績も低かった。

こはちょっとニュアンスが違う気がする.

4.1 Three groups
We could hardly expect that students would choose the Java model of assignment (model 2 in table 1), but it rapidly became clear that despite their various choices of model, in the first administration they divided into three distinct groups with no overlap at all

  • 44% used the same model for all, or almost all, of the questions. We call this the consistent group.
  • 39% used different models for different questions. We call this the the inconsistent group.
  • The remaining 8% refused to answer all or almost all of the questions. We call this the blank group.

4.1 三つのグループ
我々は学生が(正しい)Javaの代入のモデルを選択できるとは期待してなかったが,様々なモデルを選択できたにもかかわらず,それらが三つの重複のないグループに分類できることがすぐに明らかになった.

  • 44%は,全て或いはほとんど全て問題に対して同じモデルを使用した.我々はこれを一貫したグループと呼ぶことにした.
  • 39%は,異なる問題に対して異なるモデルを使用した.我々はこれを一貫してないグループと呼ぶことにした.
  • 残り8%は,全てまたはほとんど全ての回答を拒否した.我々はこれを白紙回答グループと呼ぶことにした.

くらいな感じだと思う.「一貫(consistent)してるかを見た」のは結果論であって,書いている内容としては「まずは試してみた.するとこういう三つのグループに分かれることが結果として分かった.そのグループとは〜」ということだと思う.



また平たく言うと,このテストはメンタルモデル構築の成否を間接的に計るものだと思う.メンタルモデルが構築できたか否かは,ソースコードを理解し把握できたか否かとほぼ同義だろう.

メンタルモデルは思考の中にしか無いので,それを直接計る方法は無い.だが,もし妥当なメンタルモデルが構築されていれば,それは無矛盾(consistent)であるだろうし,それを適用して問題を解いた結果もやはり無矛盾だろう.逆に解答の傾向に矛盾(inconsistent)があれば,それはメンタルモデルが構築できていない,もしくは構築されたメンタルモデルに矛盾が内包されている,つまりはモデルが論理的に破綻しているということを意味する.メンタルモデルが矛盾していたり,或いは構築できていないで解答を埋めたとしてもそれは単なる「当てずっぽう」でしかなく,論理的に意味のある答とは呼べないだろう.


プログラミングに適性のある者は,プログラミング言語を学習する前に既に,ソースコードを読んだ段階で適切なメンタルモデルが構築できている.そのような人間にとってのプログラミングの学習とは,そのメンタルモデルを適宜修正し,肉付けしていくだけの作業にすぎない.これに対し適性の無い人間は,ソースを見た段階では見てはいても理解していないためにメンタルモデルがなく,プログラミングの学習を経ても骨格がないままに無関係な用語や概念が無秩序に積み重なっていくだけの物になるのではないか.

プログラミング言語とは、それ自体は無意味なものである。ある一定の一貫した規則に従って解釈した結果、これまたそれ自体では無意味な結果を出す。つまり、プログラミングの素質は、構築したメンタルモデルを、ブレずに一貫して適用できるかどうかにかかっているようだ。

無意味な文脈から一貫した規則を形成して適用できる人間は、プログラミングの素質がある。無意味な文脈から多くの規則を生成してバラバラに適用する人間は、プログラミングを学ぶのが難しい。白紙回答した人間は、無意味な文脈に対して規則を生成することを拒否する人間である。この種類の人間も、プログラミングを学ぶのは難しい。

ここは元論文でも「推測であるが」と注釈がついていたと思う.*8自分はこの解釈には必ずしも賛成できない.


たとえば,たとえ文字通りの意味で「意味を持っていない」という意味だとしても,プログラマー的にはプログラミング言語を「無意味(meaningless)」というのには抵抗がある.*9 プログラミングには意味もルールもある.ただそれが日常生活で見られるものとかけ離れた,或いは全く異質なものであるというだけで.

人間が持つ「常識」は日常生活においては便利なものだろう.何も考えていなくても,常識に従った行動をすることで理解したフリをしたまま生活ができる.しかしプログラミングはそういった日常のルールとは断絶した,全く異なる常識が支配する全く異なる論理体系だ.日常生活の常識を根っこにして,その上にプログラミング論理を接ぎ木して論理を合成しようと考えると,おそらく上手くいかずに破綻する.その結果は矛盾した支離滅裂なメンタルモデルが構築されて,「全く訳が分からない」状態になるのではないか.

プログラミングの論理体系はそれ独自の物で,それを自分の脳内に一から構築し,言わば脳内でコンピューターの処理をエミュレートして「コンピューターの気持ちになって考える」ことがとても重要だと思う.*10 それができる人だけが,プログラミングを通じてコンピューターと会話できるのではないか.*11 *12



採用試験に使えないかという話も出てるけど,このテストでは改良しても試験対策が可能なのでそういう用途には向いていない.それにこのレベルの試験なら,ちょっと難しめのFizzBuzz問題でも十分.リスト操作や再帰呼び出しを書かせるのも良いでしょう.サンプルコードを与えて「こういう機能を追加して下さい」とか「深さ優先探索になってるけど,幅優先探索に書き換えて下さい」みたいなのもアリかな.

このテストの用途としてはむしろ進路指導かな.たとえばプログラミングもやったことのない高校生が進路を選ぶ時に,「○○大学情報工学科」と書く前に適性検査を受けて適正無しだと分かれば,自ら進路を変更することで無駄な努力を回避できると思うのです.

プログラマのための論理パズル 難題を突破する論理思考トレーニング

プログラマのための論理パズル 難題を突破する論理思考トレーニング

Puzzles for Programmers and Pros

Puzzles for Programmers and Pros

Real Education

ちょっと思い出したので,ついでにメモ.

Real Education: Four Simple Truths for Bringing America's Schools Back to Reality

Real Education: Four Simple Truths for Bringing America's Schools Back to Reality

  • 自分の能力に限界を感じながら、平均以下の実績しか出せずに働くほどつまらないことはない。しかも来る日も来る日もオフィスの内勤。電気工として外で楽しく手を動かし、毎日きちんと問題解決しながら、しかも「できるヤツだ」と言われて働くのはやりがいのある素晴らしい働き方である

と。だからといって「お前は電気工にしかなれん」と決めつけるのはアメリカンドリームに反する訳だが、本人に上記の情報を提示して、

「・・・てなことがあるんだけど、どう思う?」

と考えさせるのは大事だ、というのはよくわかるなぁ。

http://www.chikawatanabe.com/blog/2009/01/realeducation.html

自分はプログラマだ.だからマネージャーになりたいと思ったことは一度もない.それはまさに「自分の能力に限界を感じながら、平均以下の実績しか出せずに働くほどつまらないことはない」と思うから.だけどそうすると生きていくのが辛いのが,日本のIT業界なんだよなあ.

http://b.hatena.ne.jp/entry/cpplover.blogspot.com/2012/05/60.html

  • id:xlc プログラミングが特殊な才能というのはその通りと思うが、この業界はそれを信じない人が牛耳っているところに不幸がある。
  • id:shun_libra 確かに開発の分野って、センスない人はとことん向いてないイメージがあるもんなあ / 「諸君は自分の才能を正しく使っているだろうか」この国じゃ歳とってもコードいじりしていたい奴は河原乞食扱いですが?
  • id:cogen おれはエリートなのか。いや、そんなわけねえなw
  • id:princo_matsuri 【照れるなぁ】【それほどでも】

禿げしく同意.orz

  • id:daiaso なるほど、面白い。でも4割もいるとは思えないけどね。。まあ素質の問題だから、素質ある人間がプログラミングとは無関係の仕事をしている確率のほうが高いのかもしれないな。
  • id:s1bf8z1x むしろ40も?w
  • id:kappaseijin 60%も才能のあるヒトがいるのが驚き。首尾一貫規則を適用できるヒトってそんなにいるのね。
  • id:yo-11-06 結構素質ある人多いじゃん。他の専門職はどれくらいの割合なのかな
  • id:SnakeHole 実感としては素質がある人間が40%もいるとは思えない。ま,素質があってもほかのコトをしてるヒトが多いのかもだけど。
  • id:yokomichisizuka 40%も居るの…。もっと少ないかと思っていた(-ω-`)

論文ではそこまで断言してないと思う.それに仮に6割に素質がなかったとしても,4割に才能があるわけじゃない.

  • id:raitu 「一貫したグループが44%、一貫していないグループが39%、空欄グループが8%」残りの9%はどこに行ったんや。。。

残りは「判定不能」だったのでは.一貫しているとも一貫していないとも判定できなかった.*13

  • id:kokosusu assignment and sequence、って代入とシーケンス実行じゃなくて、代入と配列と訳すのではないでしょうか?

「配列」だとarrayだと思う.
この場合はsequenceは「逐次実行」では.*14「Aをして,つぎにBをして,さいごにCをする」.実に単純で,ほとんど自明な制御構造だ.テストの方を見てもそんな感じ.

  • id:legnum 向き不向きは確実にあるなあと感じてるけどこのテスト結果の括り方に意味あんのかなあ。点を取る事を目的としちゃう人だと一貫性無くても不思議はないような。白紙回答の解釈も一種類でいいのかっていう

一応はコンピューターサイエンス専攻の学生みたいだから,教官から渡されたテストなら真面目に取り組むのでは.たとえ成績には反映しないつもりと言われてもね.

  • id:kusopro これ本当に不思議なんだけど、プログラミングを学校で学んだ経験からしても「どうしてもプログラミングが理解できないって人は出る」ってのは本当なんだよね。for文で挫折した人が何人かいた。 : 本の虫: 60%の人間は
  • id:blue1st 大学の実習思い出しても確かに初期段階から「凄くできる層」と「かろうじてわかる・全くできない層」に別れてて中間的な人って殆どいなかった気がする。
  • id:yocchi24 パズルとかが得意な人のほうができそうな感じがする。
  • id:sys-arts 確かにできる人とできない人にきっちり分かれる。が、「見よう見まねでそれっぽく仕上げる」って人も居た
  • id:namikawamisaki 某社の講習で「開発・プログラミングとは何か」を、全くその方向の興味が無い人にどう説明するか、ものすごく難しい経験をしたことがある。素質が無い=ダメじゃなくて。
  • id:yashide Java習い始めたときに講師が落ち零れを減らす為にアルゴリズムの講義から始めたんだが、何故アルゴリズムの講義からか理解できなかった連中とアルゴリズムを理解できない連中が見事落ち零れた
  • id:Akaza whileを全く理解できなかった友人は自然言語を扱うのが大変に上手かった。
  • id:nanoha3 プログラミングの概念が理解できない人は結構いる。外資コンサルでもそうだった。
  • id:iouri いままでの経験から言って、状態遷移というかステートマシンをどうしても理解できない人が一定の割合でいる気がする。図で説明すればわかってるようなんだけど実はわかっていない。
  • id:s-kic 興味深い。そういや、新人の頃にやった適性検査とやらは、問題の中から法則性を見つけて解答するようなヤツだったな。
  • id:twotiger あー、分かるわ。最初に覚える言語はCか?PHPか?とかどうでもいい。何で始めても出来る人は出来るし、出来ない人は出来ない。あと、文系、理系も関係ないな。高度な数学を要求される特殊な分野以外では。
  • id:okra2 楽しいだとか学習法以前に、専門学校を出ていながら条件分岐の意味がわかんなかったりあたまの中で機能を抽象化出来なかったりアルゴリズムが思いつかない人が山ほどいる。つまりコードを書ける時点で凄いって事。
  • id:terutorauesugi あ〜この感覚理解できるなぁ。出来ない人はいくら教えてもムリw
  • id:tanimiyan プログラミングって構造化・抽象化・パターン化とかの得意不得意にものすごく左右されると思う。裏を返せばそれを鍛えるツールにもなりうるけど。
  • id:legoboku 言語能力とか高いがfor文が理解できないなんて例を聞いたことある。
  • id:hnw 代入=元論文ではassignment。破壊的代入が難しいとかいう話題ではなく値をメモリにストアするという概念 / シーケンス実行=プログラムが上から順に実行されること / concurrencyが怪しい人は開発の現場にもいる気がする。
  • id:atoh 「代入とシーケンス実行」そこかっ、そこでつまづくのか。
  • id:honeybe 素質のない俺様が通りますよっと。/真面目な話きちんと分析して会社の採用試験に反映させたい気分はある。
  • id:mad_ochi ほとんどの人が仕事でやるプログラミングって、ただの「通訳」とか「翻訳」と呼ばれるような作業だと思うのです。すべての人を一括りでプログラマと呼ぶには本当に抵抗を感じます。
  • id:indication らくだ、60%はできない=perlの基本的文法を理解できるのは40%ということか(嘘)
  • id:lp008962ラクダという名前で知られている有名な論文」何故オライリー?と脊椎反射した私は完全な負け組。Perl限定すぎる上にひとこぶだし。。

プログラミングPerl〈VOLUME1〉

プログラミングPerl〈VOLUME1〉

....f(^^;

  • id:ikd9684 おもしろい。/ 情報処理系の学科を卒業したからと言ってプログラミングができるわけでは無いのは周知の事実。むしろ情報処理系の学科を出た学生は避けようかなんてちょうど昨日冗談半分に上司と話してた。

情報系学部を避けるとまで行くと,さすがにそれは極端だと思うけど.

学部卒でもプログラマーの素質がなくて全然ダメな人も多いだろうけど,素質があっても勉強してなければ良いプログラマにはなれない.学部卒ならアルゴリズムとデータ構造とかオブジェクト指向プログラミングとかの基礎的なことは一通り学習しているはず.*15

アルゴリズムC・新版―基礎・データ構造・整列・探索

アルゴリズムC・新版―基礎・データ構造・整列・探索

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


あと,名門大学に入れた人だと,普通は英語もそれなりに勉強しているよね.英語ができるかどうかはプログラマとして大きな違いになる.*16

  • id:Rion778 代入記号が=なのがいけないと思うし「教育用言語」とやらはRにすべき

Pascalもそうだった,かな?それを変更しただけでわかりやすくなるとも思えないけれど.

  • id:usamyu56 興味深い。エリートにはプログラミングを「理解出来ない」事が理解出来ないんだろうし

エリートとは思えないけど,後半はそんな感じ.なんで再帰呼び出し程度で苦労するのか理解しかねる.

  • id:fukken プログラマの90%は、自分を「プログラミングの素養がある、いや自分にはプログラミングの天賦の才がある」と考える、と聞いた

むしろ素質のない人を見て「なんでこんな簡単なことが分からないのか不思議」と思うことの方が多い.自分が理解できるのはごく当然のことであって,息をしたりご飯を食べたりするのと同じで取り立てて自慢するほどのこととは思えない.

  • id:sunin 超一流ならともかく、ある程度できるぐらいだったら、継続的学習・複数の言語を学ぶなどで、ここでいうメンタルモデルは身に付くと感じるが、どうだろうか。

必要なのは「メンタルモデルを身につけること」ではなく「無矛盾で妥当なモデルを構築する能力」だと思う.

  • id:araishi phpとjsは少しできるようになったけど、javaが全くできないのは向いてないってことなのかなぁ。

悲しいけど,基本その通りだと思う.

phpやjsの初歩だと,前述されてるメンタルモデルが無くても,行き当たりばったりで書くだけでも少しは動くものができるが*17Javaはそうではない.適性のあるものならJavaなんてすごく簡単に使える易しい言語だけど,それが全く理解できず使えないのだとしたら,おそらく適性が全く無い.

まだ学習の初歩段階で勉強不足がJavaを使えない唯一の原因だというのでも無い限り,こんなアコギな業界からはさっさと足を洗うことをお勧めする.プログラミング適性があっても生きていくのが辛い国で,プログラミング適性のない者がプログラマを志望するなど破滅への一本道を歩いてるようなものだから.

  • id:yuri_donovic 認知や思考の特性の幅を考えさせる。パソコンや機械が苦手な人は対象の反応規則を構造化し背後のロジックを想像するのが苦手だという印象を受けるが、それと重なるだろうか。かくいう私も文系人間らしいのだが。

自分が思うに,同じでは無いけど方向性は一緒,かな?

ただし物理的な機械ではモデルも単純だし,素人でも矛盾したモデルを構築することはあまりないと思う.そもそも普通の機械は良いメンタルモデルが構築できるようにするのが良い設計とされているが,プログラミング言語では必ずしも単純で理解しやすいメンタルモデルがあることが良い言語の条件ではない.

誰のためのデザイン?―認知科学者のデザイン原論 (新曜社認知科学選書)

誰のためのデザイン?―認知科学者のデザイン原論 (新曜社認知科学選書)

  • id:vid なんとなーく、地図を読めるかどうかとか思った。

「方向音痴か否か」というのとは方向性は似ているかも.たとえば一つの仮説として,地図が読めない人は地図を「二次元画像」として認識しているが,読む人はそれを画像であると同時に「(三次元)グラフ」として認識しているみたいな差があるのかもしれない.

ただし地図なんてたかが二次元画像に過ぎないので,読めない人でもコツさえ教えれば「初めての土地でも地図さえあれば道に迷わない」くらいにはなれると思う.プログラミングではそういう簡単に習得できるコツがない.

  • id:YuT 学生時代の授業がまさにそんな感じだったなぁ/ヘンテコな指摘をしているブックマークな人が結構居るのは一体(こやつら、組んだこと無いな/(悲しい事に)エリートでは無い気が(社会的に

そういう頓珍漢な人達を無くすためにも,家庭科や音楽などと並んでプログラミングを義務教育に取り入れて,大多数の人間に早期に挫折を経験させておくのはとても良いことだと思う.*18日本のIT業界の不幸は,そういう挫折を経験した人や挑戦さえせずに現実逃避した人達が,嘘に嘘を塗り固めて自分は挫折してないフリをして業界を支配していることだから.

  • id:ystt 程度の差はあれ他の分野でも似たようなものだと思う。よっぽど変なテストを行わない限り、成績の分布はふたこぶになることが多いし。
  • id:hrsttフタコブラクダ」がプログラミングの素養に限るように読めるが,学習成績の分布をしらべると「フタコブラクダ」は珍しくもなんともない.プログラミングに限らないよ.

フタコブラクダは共通でも,程度の違いが極端なことは大きな違いなのです.

たとえば走る速度なら2倍も違うことはあまりないけど,プログラミング能力だと30倍以上違うのがザラ.


  • id:C_L 示唆に富む。プログラムはもちろんだけども、印刷の組版規則にしても既存印刷物を読んでルールを見いだせる人に適性があると言えよう。このエントリを引くと60%の人は組版の素質がなくなるわけだが、さて現場では。
  • id:Domino-R 一見無意味な諸要素間にさえ一貫した体系や論理的な整合的を求めてしまうのは、素質や才能というよりは(たとえば潔癖症のような)性癖。無論優れたプログラマには相応の才能も必要だろうが
  • id:mcgomez つまり、「学校の帰り道に影から出たら地獄におちる」とか「石ころを家まで蹴り続けないと死ぬ」とかそういう自分ルールを追求できる小学生がプログラミングの天才ということか。みんなそうだったじゃん。
  • id:e-domon 記号に後付けで「意味」を持たせて操作する、と言うプログラミングの作業は、専門用語を正しく使いながら文章を紡ぐ作文技術に似ているかもしれない。
  • id:angmar ここで言ってる「プログラミングの素質がある人」は「自身の幻想に囚われやすい人」くらいの意味。
  • id:sekirei-9 一貫したメンタルモデルってのがよく分からないが、一度決めたルールを、他の問題にも適用するって事? 問題に応じて柔軟にルールを変えると、プログラミングは出来ないのか。政治家は向いてなさそうだけど。
  • id:pmint この一貫性はバカの一つ覚えのことだろう。文中にあるようにプログラミングは無意味を寄せ集めて、結果「正解は出るからいいんだよ」というものになっている。この素質だけで作れるのは単機能ツール。意味が必要。
  • id:nean プログラミングも言語だからあまり素質とか関係ないんじゃとは思う。言語能力って生まれ持ってくるものじゃなくて、修得するものだから。ASCIIコード速く読めるとかは素質しれんけど。一貫性ってそれとは違うのかな

たぶん違う.どこから突っ込んでいいのやら.

twitter





なまじプログラミングの才能なんてあったがために,人生で道を踏み外しちゃいましたよ?一種の呪いという指摘は当たっているかもしれない.

ここでいう「社会階層が低い」が「頭が悪い/勉強できない」という意味だとして,勉強ができてもプログラミングの素質がない人はプログラマになれないが,プログラミングの素質だけあっても勉強ができない人はプログラマとして大成するのはやはり難しいと思う.たとえば数学とか英語とか.特に英語は今じゃほとんどの分野で必要不可欠だと思う.さらに時には会計だったり金融工学だったりバイオテクノロジーだったりを知らないとプログラムは書けない.

「どのレベルまでプログラミングスキルが達していれば、素質/才能があると言えるか」は難しい問題だと思います.
しかし「Fizz-Buzz問題再帰呼び出しがスラスラ書けない人には全く素質がない」とは言えるでしょう.「代入と逐次実行」となると,理解できない人がいることにビックリ.

「一貫している(consistent)な処理」について

初歩的な算数を例にとって説明する.

注:以下の「=」 は等号であって代入演算子では無い.

問題例

1+2-3 =
1+2*3 =
2+3*4 =
3*4*5 =

一貫している例1

1+2-3 = (1+2) - 3 = 3 - 3 =0
1+2*3 = 1 + (2*3) = 1 + 6 = 7
2+3*4 = 2 + (3*4) = 2 + 12 = 14
3*4*5 = (3*4) * 5 = 12 * 5 = 60

一貫している例2(通常の算術的には誤り)

1+2-3 = (1+2) - 3 = 3 - 3 =0
1+2*3 = (1+2) * 3 = 3 * 3 = 9
2+3*4 = (2+3) * 4 = 5 * 4 = 20
3*4*5 = (3*4) * 5 = 12 * 5 = 60

一貫している例3(算術的には誤りだが,APL的にはだいたい正しいはず.)

1+2-3 = 1 + (2-3) = 1 - 1 =0
1+2*3 = 1 + (2*3) = 1 * 6 = 7
2+3*4 = 2 + (3*4) = 2 + 12 = 14
3*4*5 = 3 * (4*5) = 3 * 20 = 60

一貫していない例

1+2-3 = (1+2) - 3 = 3 - 3 = 0
1+2*3 = 1 + (2*3) = 1 + 6 = 7
2+3*4 = (2+3) * 4 = 5 * 4 = 20
3*4*5 = 3 * (4*5) = 3 * 20 = 60

というような意味だと思われる.


この場合,ルールが一貫して適用されていないとしたら,それはそういう戦術ではなくて,単に演算子の優先順位とか結合規則を理解せず,行き当たりばったりに処理している可能性が高いと思う.非常に「筋の悪い」解法だ.「乗除算の優先順位が加減算より高い」ということを知ってれば例1になるし,間違って覚えていて「左から順」と覚えて入れば例2のようになる.*19一貫していない例では,その当たりの基本となるロジックが頭の中で全く整理できてない.


なお,各プログラミング言語における演算子の優先順位はその言語の定義によってのみ決まる.基本的なルールは通常の数学のものに似せてあることが多いけれど,そういう決まりがあるわけではないし,通常の数学で使われないような演算子も存在する.

例えば有名な「逆ポーランド記法」の場合は上記のような表記にはならないし,APLでは全く異なる結合規則を有すると聞いた.*20 一貫している例3の方は一応APL風に書いたつもりだが,APLはよく知らないので間違ってるかもしれないのでそのつもりで.

hp 50G F2229AA ABA

hp 50G F2229AA ABA

かけ算の順序

ちょっと余談.

少し前に「3×5でも5×3でも答が一緒だからどっちでもいい」という議論がでていたけど,上記のようなメンタルモデルの一貫性を見る上では,必ずしも一緒で良いとは思わない.まずは順序があって,その後に「スカラー値の乗算は可換である」から順序の置き換えが可能という話であって,そこをすっ飛ばして「結果さえ良ければいい」という姿勢を取ると複雑な処理を扱えなくなる危険がある.*21 *22

教育において順序が逆の時にバツを付けるべきかについては異論はあるだろうが,初期の「さんすう」の教え方限定ならば悪くないと思う.

まして「3×5と5×3の違いが分からない」と本気で言ってる人は,数学やプログラマの素養を疑うかもしれない.*23


たとえば java.lang.Object#equals(Object obj)のオーバーライドにおいては,以下のようなルールを守るようなメソッドを自分で定義する必要がある.プログラミングにおいて可換な演算は必ずしも規定の事象ではなく,プログラマが定義し,自ら創り出す類のものなのだ.

equals メソッドは、null 以外のオブジェクト参照での同値関係を実装します。

  • 反射性 (reflexive):null 以外の参照値 x について、x.equals(x) は true を返す
  • 対称性 (symmetric):null 以外の参照値 x と y について、x.equals(y) は、y.equals(x) が true を返す場合だけ true を返す
  • 推移性 (transitive):null 以外の参照値 x、y、z について、x.equals(y) が true を返し、かつ y.equals(z) が true を返す場合に、x.equals(z) は true を返す
  • 整合性 (consistent):null 以外の参照値 x および y について、x.equals(y) を複数呼び出すと常に true を返すか、常に false を返す。 これは、オブジェクトに対する equals による比較で使われた情報が変更されていないことが条件である
  • null でない任意の参照値 x について、x.equals(null) は false を返す

Object クラスの equals メソッドは、もっとも比較しやすいオブジェクトの同値関係を実装します。 つまり、null 以外の参照値 x と y について、このメソッドは x と y が同じオブジェクトを参照する (x == y が true) 場合にだけ true を返します。

通常、このメソッドをオーバーライドする場合は、hashCode メソッドを常にオーバーライドして、「等価なオブジェクトは等価なハッシュコードを保持する必要がある」という hashCode メソッドの汎用規約に従う必要があることに留意してください。

http://java.sun.com/javase/ja/6/docs/ja/api/java/lang/Object.html#equals%28java.lang.Object%29

メンタルモデル

ひょっとしてだけど,一部でメンタルモデルのことを「メンタル面で強い/弱い」みたいな意味での「メンタル」な何かと勘違いしている人がいるような気がする.

メンタル・モデル
mental model
認知科学(心理学)用語。なんらかの課題を与えられ,その解決をはかるとき,とりあえずその解答として想定する仮のモデルをいう。研究や課題の状況に試行錯誤的に関与するための手引となる。他人に何かをわからせたいときには必須のものであり,相手がメンタル・モデルをもっていることを十分に認識したうえ,相手のメンタル・モデルの内容に配慮する必要がある。たとえば,ある集団の構成員について互いのメンタル・モデルに共通性のある場合はまとまりがよくなり,違いがありすぎると紛争が起りがちだと考えられる。
(ブリタニカ百科事典 電子版より)

普通に推論とかの知的な精神活動の話のはず.関連研究でもそういう話になってる.


「開発者「大増殖時代」の到来で、プログラマーの存在意義はどう変わる?」

http://engineer.typemag.jp/collaboration/2012/05/post-12.php
さらに余談.

Webサービススマートフォンアプリの隆盛、プログラミングを簡易化する各種フレームワークの普及......。ここ最近、文系学生が就職の武器としてプログラミングを学ぶほど、「創る人」の数が増えている。

とりわけフロントエンドで顕著なこの傾向。「1億総Webアプリ開発者の時代が来た」といったような過激な記事も出始めている中、IT・Web業界ですでに仕事に取り組むプログラマーの役割はどう変わっていくのか。

「コードが書ける」こと自体が付加価値ではなくなりつつある今、プログラマーの存在意義はどこに置かれるようになるのか。

例の論文を読んだ直後だけに,何一つ心に響かない記事だった.

自分では頑張って書いてるつもりでも,とても正視できない汚いスパゲッティプログラムを書く人も知ってるしね.

「なぜ60%の人はプログラミングが出来ないのか」

http://ameblo.jp/bradnine/entry-11911830387.html
メモ.

その論文は著者が撤回を表明しました

撤回表明はこちら:
http://www.eis.mdx.ac.uk/staffpages/r_bornat/papers/camel_hump_retraction.pdf

*1:ブクマ見る限りは程度の違いはあれど,プログラミングに限らないらしい.そりゃそうか.ただしプログラミングにおいては,その中間が無く,しかも非常に明確に分かれる点が特徴.

*2:論文によると,だいたい30%−60%がそうなるらしい.「Javaスクールの危険」の方だと「通常40%から70%の間」.

*3:スポーツの世界だとごく普通に見られるよね.身長体重,懸垂や腕立て伏せ,100m走,持久走,垂直跳び,反復横跳び,などなど.スポーツ毎に求められる特性は異なるけど,大抵はある一定基準以下の選手は「見込み無し」ということで一次テストでバッサリ落とされるだろう.

*4:バスケの選手でいえば,「60%の人」は「身長160cm以下」みたいな基準でバッサリ切ってるだけ.身長180cm,できれば190cm以上に加えて,ジャンプ力や筋力や判断力や各種テクニックその他諸々も全部兼ね備えて初めて,「才能のある有望な選手」になる.

*5:で,まあ高度なプログラミング教育を施すのであれば,この才能のある10%かそこらの人達に絞って行うべきだと.10%って結構多いよ?適性のない人にプログラミング教育を施すのは,経費の無駄遣いだし本人達にとっても不幸だ.

*6:メンタルモデルについては論文中でも関連研究として取り上げられている.

*7:Fizz-Buzz問題は,2の繰り返し実行のあたりか.これもやはり超初心者レベル.

*8:"It has taken us some time to dare to believe in our own results. It now seems to us, although we are aware that at this point we do not have sufficient data, and so it must remain a speculation, that what distinguishes the three groups in the first test is their different attitudes to meaninglessness.
Formal logical proofs, and therefore programs – formal logical proofs that articular computations are possible, expressed in a formal system called a programming language – are utterly meaningless. To write a computer program you have to come to terms with this, to accept that whatever you might want the program to mean, the machine will blindly follow its meaningless rules and come to some meaningless conclusion. In the test the consistent group showed a pre-acceptance of this fact: they are capable of seeing mathematical calculation problems in terms of rules, and can follow those rules wheresoever they may lead. The inconsistent group, on the other hand, looks for meaning where it is not. The blank group knows that it is looking at meaninglessness, and refuses to deal with it."

*9:この部分は読み難くてよく分からなかった.たとえば"formal logical proof"ってなんぞや?

*10:http://d.hatena.ne.jp/JavaBlack/20060331/p1

*11:内容は全然関係ないんだけど,なんだかこのタイトルを連想した.

断絶への航海 (ハヤカワ文庫SF)

断絶への航海 (ハヤカワ文庫SF)

*12:むしろこっちの世界が近いか?

四次元の冒険 第2版?幾何学・宇宙・想像力

四次元の冒険 第2版?幾何学・宇宙・想像力

*13:言われるまで全然気づかなかったわ...

*14:逐次実行,繰り返し(ループ),条件分岐.sequence とiterationとconditionかな? iterateはGoFで有名になったよね.

*15:それこそ「人月の神話」とかGoF本とかを知らないまま卒業する人は,あんまりいないと思う.読むかどうか,理解できるかどうかは別にして.

*16:日本語も得意な英語ネイティブを雇った方がいいような気もするけど.

*17:ただし「JavaScriptを使いこなす」となるとすごく大変.

*18:子供の頃,クレヨンで絵を描いた時点で画家になるのは無理だと思ったし,ハーモニカをぴーぱー鳴らした時にも音楽家になるのは無理だと思った.

*19:算数くらいで間違って覚えるのは相当に頭が悪い気もするけど,一般的なプログラミング言語全般で考るとプログラミング言語の方が遙かに多様で複雑なので,そういう間違いも起こったりする.

*20:「APLでは右から左に、(3+(2-1) ) の意味(右結合)である。さらに、APLにはこの「右から左」のルールしか存在しない。」 http://ja.wikipedia.org/wiki/APL#.E5.8F.B3.E3.81.8B.E3.82.89.E5.B7.A6

*21:プログラミング的には誤差の問題もあるけどね.計算順序によって誤差が大きくなったり小さくなったりするから.

*22:行列の乗算は可換では無いよね?アフィン変換の順序を間違えるのはありがちな初歩的ミスの一つ.

*23:数値は同じでも通常は次元(単位)が異なるように問題が設定されている.プログラマ的には,それらは異なる型やクラスで定義されることが多い.