こういうのって「取り敢えずやってみるか」って実行出来る人とそうじゃない人がいて、世の中の人ってのは98％くらいは後者な印象なんですよね。
どうやら星田さんは2%の人みたい。
すげぇな、この人。
(しかも紹介してから数日しか経ってないのに、もう第5章まで進んでいるwwww)
んでね、星田さんがすげぇ面白い事書いてるの。その通りなんだよ。
近所のすごく勉強できて今年からプログラマーになった女の子も「え？ネットで欲しいコード探してコピペしますｗ 無かったら書くって感じで」
なんて事を言ってるんですよね
この女の子、多分凄くデキる人だ。
UNIXという考え方って本があって。この本は凄く良書で、いつか書いた
「関数の行数は☓☓行以下にしろ」
ってのもこの本に書いてるんですが。
中に面白いエピソードがあんのよ。
著者の同僚に「プログラムがあんま出来ない」人がいて、でも高給取りなヤツの話が書かれてるのね。
この人、プログラムの仕様を受け取ってまず何をするか、っつーとOSが提供する機能から役立ちそうな機能をまず探す、と。それを組み合わせるか、あるいはOSのソースコードから必要なブツを抜書して組み合わせてデッチ上げるのね(笑)。
それで高給を得る、と。
この本の著者はそれを見下してるんじゃなくって、「すげぇ能力だ」って絶賛してるんですよ。
良く言われるんだけど「車輪の再発明はしない」ってのはこーゆー事で、実はプログラミングでまず第一に何が必要か、と言うと「プログラムを書ける能力」なんじゃなくって「検索能力」なんです。「探せる能力」。それがまず第一。
教えて!gooのプログラミングに関して投稿してくるヤツってのも9割以上は、まずは決定的に「検索能力が"ない"」んですよね。検索してどーしても分かんなかったんで投稿しました、なんつーのは1割に満たない。
つまり、もう教えて!gooに投稿してくる時点でかなりの確率で「プログラミングの才能が無い」んです。厳しい言い方するとそうなる。
言い換えると上の「OSの機能で適しそうなコマンドを探す」人とか、もう本人プログラム書かないにしてもプログラミングの能力はピカイチなんですよ(笑)。いや、マジで。そもそも問題をキチンと把握出来る能力が無いと検索も出来ないですしね。
だから「論理的もクソも関係ない」ってのはこういうトコで、要するに実は一番必要なのは要領の良さなんですよ。
余談だけど、だからプログラミングに於いても漫画「ドラゴン桜」で描かれてる事って結局かなり当てはまるのね。東大かどうか、ってのは関わらず。
曰く「要領の良さ」が大事、とかパターンの話もそうなんだけど、「暗記は大事」とか、あと上で書いたように、まずは問題をキチンと把握できる能力が大事だ、って事は当然「国語力が大事」とかね。あと、写経ってのは要するにある意味追い読みなのよ。大事な事は全部ドラゴン桜で書かれている。この漫画って今でも圧倒的に正しいんだ。
多分、だからその女の子は要領が良い。って事は言い換えるとデキるプログラマなのは間違いないでしょう。
何故なら圧倒的に正しい事を言ってるから。
コピペ万歳!なのよ。
ちなみに、何で長い間PythonがPerlに遅れを取ってたのか、そして日本ではRubyに遅れを取ってたのか、と言うのは。
もちろん、日本に於いては長い間日本語の処理が怪しい、って事があったから、ってのは一つの理由なんですけど。その辺「日本で作られた」Rubyに二歩も三歩も遅れてた。
ただ、世界的な傾向から言ってもRubyはともかくとしてPerlには負けてたのね。この最大の理由ってのは
- Perlは「なんかのやり方」が検索出来ると、「そのもの」が即インストール可能だった。反面、Pythonは「なんかのやり方」は検索出来るけど、それ「そのもの」は即時インストール出来なくて、コピペせんとアカンかった。
だったの。
今のPythonだとpipってので端末から欲しいライブラリをすぐさまインストールして使えるんだけど、ここにたどり着くまで紆余曲折だったのね。ハッキリ言って、この辺がPerl/Rubyの後塵を拝してた。
要領が良い人はホント面倒くささを嫌うわけ。Pythonはその辺を割に最近まである種理解してなかったんだ。
さて。
リリカル☆Lisp。
２話くらいまでは「ふ〜ん」って感じなんですけど、章の最後に確認問題があって途中でテキトーに聞いてると全然答えられないｗ
そうそう(笑)。
だから結構章末の問題は「歯ごたえあるよ」って言ったでしょ(笑)?
基本12問しかないんだけど、その12問は「Lispの歴史で使われた問題から精選された12問」だと言って良いです。
あ、ラムダってココから来てんのか〜。
まぁ、プログラミング言語ではそうです。ラムダって関数型言語の合言葉とかになってますよね。
例えば関数型言語Haskell(Pythonがリスト内包表記を借りてきた言語)のロゴマークも
とラムダ(λ)だし、こないだ紹介したRacketのロゴマークもラムダだ。
著名なLispハッカー、ポール・グレアムは次のように書いてる。
なぜ1950年代の言語(注: Lispの事)が時代遅れにならないかという簡単な説明は、 それが技術じゃなくて数学だったということだ。数学は色あせない。
別のハッカーは次のような事を書いてる。
今日のすべての言語はFortranかLispに基づいている。まずい方がFortranで、すばらしい方がLispだ。
PythonはLispに基づいている、って考えて良い。C言語はFortranの方だ。
さて、
特に第５話は途中で寝落ちしてしまったり（エンターキーを押したままうつ伏せで寝ていた）、最後の問題が解らなくて３周くらいしましたかね。間違えても正解が表示されたりしないし、ネットで検索しても見つからないので、結局章の最初から見返してちゃんと覚えないといけないってのが結果的によく機能してると思った
第5話の問題ってこれかな?
リリカル☆Lispの意図してる回答は次のようなカンジかしらん。
(define f (lambda (lst) (car (cdr lst))))
ただ、通常Scheme系だとまずはショートカットとして次のような書き方を好みますね。
(define (f lst) (car (cdr lst)))
んで、もっと言うと、リストの第二要素を返す関数ってのが、当たり前だけどSchemeには定義されてます。
言い換えると、こう定義しても正解。
(define f (lambda (lst) (list-ref lst 1)))
# または
(define (f lst) (list-ref lst 1))
他にもSchemeにはcarとcdrを組み合わせたcadrなんつー関数も定義されています。
(define f (lambda (lst) (cadr lst)))
# または
(define (f lst) (cadr lst))
ところで、上のcadrを使った定義を見てみると、事実上「関数名を変えた」だけで何もプログラミングしてない、って事が分かる。
実はこれも重要なテクニックで、あるプログラムを書く際に「名前だけをそのプログラムで利用するツールとして明示的に変える」ってのはオッケーなんです。
言い換えると、実は上のcadrを使ったプログラムは次のように「リネーム」するだけで機能する、って事になります。
(define f cadr)
従って、cadrって名前をfにすげ替えただけでこれも正解だ、って事になります。
しかしLISPってホンマ異質な印象・・本来のコンピューターの挙動に近いんでしょうけど・・
いや、むしろ本来のコンピュータの挙動とは遠いトコにあるんだけど、何か言わんとしてる事は分かります(笑)。
何かアレでしょ?「血なまぐさい」でしょ(笑)?手作りの何かを直接触ってるような感触があるんですよね。内蔵を直接触るような(笑)。ホラーなたとえしか出来ないけど。
何か素朴なんだけど、その「素朴さ」が剥き出しになってるような感触を与えるのがLispへの感想って言えば感想っぽくはなるんですよね。
感覚的な話ですが。
