「何でもいいからプログラミングを始めてみたい」と言う人に薦めるプログラミング言語は、相も変わらずRubyだ。
以前にも色々書いたが、極論、Rubyの言語仕様がどーの、ってのは関係がない。
単にWeb上でタダで読める、良く出来たプログラミング初心者用の記事があるから、だ。
どちらも薄く、「プログラミングってどうやんの?」と言う概要を知るには良いチュートリアルになっている。マジメにやれば多分2週間掛からず終わる事となる筈だ。
断っておくが、この2つのウチのどちらかを(好みによって)終えてもすぐさまプログラミングが自在に出来る、ようにはならんだろう。大体、大学に通って一学期みっちりそこで勉強してもプログラムを書けるようにはならんのだ。
どっちにしてもならんけど、何事もまずは「概要を知る」のが一番だ。そして上の2つの文書は、敷居としても働く。この2つの文書のどちらかでも「全く理解出来ない」のならプログラミングに向いてない、のである。
人には向き不向きがある。そして出来ないヤツが出来たヤツより劣る、ってワケでもない。そういう人には別の才能があるだろう。たった2週間で「プログラミングに向かない」事を分かれば以降、無駄な事に時間を費やす事もなくなるのだ。あるいは、貴方はIT土方にならずに済む事が分かっただけ、でも人生の得かもしれんのだ。
そして、どうしてもそれでもプログラムを作りたい、とか言う場合、プログラマを雇えば良いのだ。日本の場合、歴史的に見ると、プログラミングが全く出来ない人がプログラムを作って売る会社を立ち上げて、その方が上手く行った、と言う例の方が多いのだ。貴方にプログラミングの才能がなくても経営者の才能はあるかもしんない。繰り返すが、日本だとそっちの方が多いのである。マジで。
いずれにせよ、Rubyを薦める最大の理由は、Web上でタダで読める良質なプログラミングのチュートリアルの存在、である。これ以上もこれ以下の理由も存在しない。
ところで、上で「言語仕様は問わない」と言った。
うん。まぁ、出来れば動的型付けの言語であれば・・・と言うような希望はあるけれども、それでも敢えて言うとその辺は重要じゃない。言語デザインはあまり重要な話じゃあないんだ。
例えば、だぜ。初学者向きの言語、と考えた時「なるべく構文が易しくて、覚える事が少ない言語を・・・」とか思うだろ?まぁ、当然だわな。初学者の負担にならんように、とかさ。
でさ。そこらにある本屋・・・なるたけプログラミング言語関連の書籍が置いてある本屋にブラっと入ってご覧?そういうトコだと見慣れない「☓☓言語入門」って題した本がかなりあるだろう。10冊くらい前書きだけ目を通して見てみればいい。ほぼ、すべての本で
「このプログラミング言語☓☓は構文は易しく、覚える事が少ないんで、初学者にも良いでしょう。」
って書いてあるから(笑)。
ほぼ100％そうだぜ(笑)?
つまり、どの言語も覚える事が少なく、構文は易しいのだ(笑)。っつー事はそんな事で差別化は出来ない、と言う事だろ(笑)?ハッキリ言えば、「C言語入門」の類の本でもんな事書いてある(笑)。
これ、考えてみれば当然なんだよ。つまりさ、言語デザイナーになった時、
「俺が考えるプログラミング言語は、構文が意味不明で、理解するのに苦労する言語を作ろう!」
なんつーヤツは一人もいねぇから、だ(笑)。仮にそういうヤツがいても、そういうヤツが作るのは冗談プログラミング言語だ。実用性は初めから放棄している。
要するに、ある程度実用性があるプログラミング言語は、あのC言語を含めても「覚える事が少なく構文は易しい」の。それが前提となる筈だ。
じゃなけりゃあ、どの言語も掲げてる「覚える事が少なく構文は易しい」ってのがウソなのか、ウソで悪けりゃ「あくまで枕詞であって意味はない」のか。そう言った話となる(※1)。
ところで構文が易しく覚える事が少ない、ってのとプログラムの記述が簡潔になって実用性がある、ってのは実はあんま関係ねぇと思ってるんだ。
個人的な観点では、構文が易しく覚える事が少ない言語、だとSchemeが一番そうだろ、とは思っている。ただし、それで、書いたプログラムが簡潔になって実用性が上がるか、っつーと「残念ながらんな事はねぇ」ってのが正直な感想だ。
このブログでは何度も取り上げてるけど、SchemeはLisp語族の一種で、LispはList Processingの略称だと言われている。つまり「リスト処理器」だ。で、知ってる限りで言うと、リスト処理では最高の能力を発揮する。
そしてまさしく「構文は易しく一貫してて覚える事は少ない」。むしろ「構文はない」って言っても良いくらいだ。「前置記法」と言う一貫した体系しか持ってない。
ところがだぜ。例えば配列、と言うデータ型相手になると「え?」とか思う。
Schemeだと例えば二次元配列相手だと、要素へのアクセスは
(vector-ref (vector-ref v j) i)
とか書くだろ?前置記法で構文は一貫してる。でも使いやすいとか読みやすい、とかとはまた別の話なんだよな。
これなら確かにC言語みたいに
v[i][j]
とか、あるいはPascalみてぇに
v[i, j]
って書いた方が見やすいし書きやすいでしょ?
でもこれを採用したら「構文は一貫しない」の。
結局、「構文が易しい」のと「記述上シンプルになる」てのは必ずしも一致せんのだよ。
あと、Schemeの仕様書は100ページに満たない。結果「覚える事は少ない」。
でも、仕様の範疇内で書ける「実用的プログラム」(何をもって実用的とするか、は議論が必要だけど)ってのは殆どない、って言って良い。
つまり、「覚える事が多い」方が「実用性は上がる」んだよ。Pythonとか標準モジュール全部知るのは相当の骨だぜ。っつー事は「覚える事が少ない」ってのはウソだ、って事だ。当然やれる事が増えれば覚える事は比例して多くなるんだ。
当たり前、ってば当たり前の話だろ?
結局、いくらプログラミング初学者向け、っつったって「構文が易しくて覚える事が少ない」ってのはメリットにはならん、って事だ。
ここで例えばVisual Basicを考えてみよう。
最初に断っておくけど、僕はVisual Basicを使った事は一度もない。VBAもちょぴっとだし、VBSも洒落で一回使ってみた程度の経験しか無い。
そんな僕だが、恐らくVisual Basicはそんなに悪い言語じゃあないんじゃないかな、とか思ってる。
何故なら運用実績が桁違いだし、誰も彼もが色々書いてるトコ見ると、絶対「使いやすい」言語の筈なんだ。
オープンソース界隈だと「Visual Basic」って聞いただけでバカにするような風潮がある。ハッキリ言うと、「マイクロソフトが作った」って事によるバイアスがかかってて、Visual Basicを不当に貶めるような状況になってる。反面、Appleが作った言語はすげえ持ち上げるんだよな。
歴史を見てみろ。Appleがサポートした、あるいは作った言語は負け続けで「覚えても消えていく奴ら」ばっかだ(笑)。Object Pascalから始まってDylan、HyperCard、Objective C。一体どれだけが残って依然多くのユーザーを抱え支持されてると言うんだ。
今じゃSwiftがあるけど、これも登場時はそこそこ持て囃されているが、その時の熱気は既にない。経験則で言うとAppleが薦める、あるいは作った言語は「賭け」の対象にしちゃあダメなんだよ。歴史を知る人の知恵、だな。
反面、色々言われててもVisual Basicは長期間に渡るマイクロソフトのサポートがあり、依然使われ続けてるのだ。Appleと比べたら失礼な程のレベルだ(笑)。
別のトコにも書いたけど、マイクロソフトはプログラミング言語の選択、設計及び販売で「失敗はしない」(※2)。
と言う事実を踏まえて、Visual Basicは「良い言語」なんだろう、と思う。
思ってるが、それでもプログラミング初学者には推薦しないのだ。もちろん、僕がVBを全く知らないから、ってのは当然あるんだけど、実のこと言うとそれより大きな問題がある。
それは「如何にVisual Basicで綺麗なコードを書くのか」と言う指南書が、調べてみた限り一冊もねぇ事だよ(笑)。それが理由だ。
要するに僕もかつて、Visual Basicを学んでみようか、って思った事があったんだけど、鉄板の「Visual Basic How to」ってのが全く存在しない、って事に驚いたんだ。
Visual Basicは、ぶっちゃけ、素人でもプログラミングが出来るように設計してある。コレ自体は実は全然悪いことではない。Pythonも素人でもプログラミングが出来るように設計してる。「素人でもプログラミングが出来るように」作る、ってのは全然悪い話じゃあないんだ。
問題はそのせいで、エキスパートが「マトモなプログラミング言語としてその存在を捉えない」事が生じる(ついでに「BASIC」と言う単語が冠されてる事へのバイアスもかかる)。だから指南書が生まれない。
結果、Visual Basicは「見様見真似で」プログラミングする事が可能であり、ノウハウらしいノウハウが形成されない。そして出てくるコードは汚いモノばっか、となるだろう。それでも「動く」わけだ。
そしてクソなコードが大量生産され、そのクソを真似たコードが出てくる。ハッカーがそれらを覗いた時、「こんな風に書かなきゃならないのならクソな言語なんだろ」と判断する。結果、「クソを書く」悪循環は断ち切られないのだ。
これもすべて「指南書が存在しない」せいである。
例えば似たようなケースとしてのオープンソース陣営の言語で言うとJavaScriptがそれにあたる、だろう。JavaScript自体は、何度も言うが、基本設計は「Cの皮を被ったLisp」である。非常に志が高い設計をしてるが、同時に「プログラミング素人でも扱える」事を念頭に設計した。
これで何が起きたか、と言うと「クソコードの量産」である。結果、登場からかなり経っても、プロも「使わなければならないから使う」だけであり、決してJavaScriptを「愛する」と言う事が無くなったのだ。誰も「JavaScriptで綺麗なコードが書ける」とは夢にも思わず(そもそも外側がHTMLやCSS塗れだし、内側はDOM塗れだし!)その正体に長い事気づかない、って事が生じたのだ。プロ「でさえ」だ。
つまり、これも、「プログラミング初学者でも扱える」前提だったため、指南書が登場しなかった事による不幸なんだ(今現在だとこんな本が出てるが、未読なんで良く分からない)。
ここで分かるのは、どういったプログラミング言語を学ぼうか、ってのは実は重要ではなく、「どういった指南書が存在するのか」がむしろ重要なんだ、って話だ。言語そのものがあっても仕方がないんだ。その言語で「どうやったら綺麗なコードを書けるようになるのか」説明する媒体の方が必要なんだ、と(※3)。
以前チラッと書いた事があるけど、実は、特に初学者相手だと、文法がどーの、って説明するよか「綺麗なコードはこうやって書くんだ」と言うスタイルの提示の方が大事だと思ってる。
「カッコいいコードはこうやって書くんだ!」と言うメッセージは極めて大事だ。そして(C言語を除くと)「カッコいいコード」には無駄がない。ここで言う「無駄がない」ってのは必ずしも「(ハードウェア上)効率的だ」って事を意味しないけど、メインテナンスなんかを考慮しても最良のコードとなる筈なんだ。もし、その「カッコよさ」と「無駄がない」が一致しないのなら、そのプログラミング言語は「ダメなプログラミング言語」だ、って事になる。大方においてこれは正しいんじゃないか。
繰り返すけど、だからこそ「指南書の存在」ってのは重要になる。そしてこれも何度か言ったけど、ANSI Common Lispでさえ「汚いコードを書こう」としたらメチャクチャに書けるのだ。でもPeter Norvigセンセみたいな「書法の伝道師」的な人が良書を書いてくれてるお陰で、何とか踏みとどまっていられるわけだ。
Schemeだって1990年代に出てたような本は総じてメチャクチャだった。川合史朗さんみたいな「書法の伝道師」的な人がいなかったら、日本でのSchemeプログラミングのスタイルは多分メチャクチャなまま、だっただろう。
それくらい「スタイルの伝授」ってのはものすごく大事、なのである。「自由に書けば良い」って話じゃあないんだ。
と言うわけで本題のPythonに入る。
僕も10年くらい前だったら迷わず初学者にはPythonを挙げていたクチだ。
当時はトーシロ界隈にはPythonの知名度がなかった。だからいきなりPythonを挙げられても「何だそれ?」ってのが大まかな判断だっただろう。いや、「判断」でさえない。何故なら判断材料がトーシロにはまるで無い、からだ。
だからぶっちゃけた話、知名度のせいで殆どマトモには受け取られなかっただろう。
それで言うと、10年も経ってトーシロが「Pythonを学びたい」って言い出す状況を見ると「随分と変わったんだな」って正直思ってる。
人によっては「最近はPythonにはプログラミング初学者向けの入門書も多いし良いだろう」とか言ったりしている。書籍の数が増えた、って事に関してはその通りだ、と思う。10年以上前だとPythonの本を探す事でさえ大変だった、からだ。
しかし、だ。
今までの議論を見てくれば分かるだろう。「Pythonの書籍数が増えた」と言うのが、イコール「どの本も優れたプログラミングスタイルを伝える指南書たり得てる」ワケじゃない。
言っちゃえば「クズな本がいくら増えても役には立たない」と言う事なんだ。
逆に僕から言わせれば「クソなPython本が増えてる以上、Pythonを初学者に薦める事は危険だ」とまで思うようになっている。
そしてプログラミング初学者は常に情報不足だ。つまり「どういう本を用いれば正しい(あるいはカッコイイ)プログラミングスタイルが学べるのか」それを知るノウハウがない。そしてそのノウハウを知ってる奴らは既に初学者じゃないんだ。
さぁ、どうすんだ、と言った場合、一番良いのは「君子危うきに近寄らず」である。
それもあって、Pythonを薦めるのならRubyを薦めた方がより良い、と思ってるんだ。
今のPython界隈はダメだ。Pythonは初学者向きじゃなくなってる。
ここで一つ恐るべき真実を伝える。
いや、既に何度か書いてるけどな。
実はこのテの「技術書」と言われるジャンルの本。「すげぇテクニカルでしっかり書かれた(ある種)難しい本なんだろうな」と思うだろう。
僕もかつてはそう思ってた。
違うんだ。
実はこれらの実態の殆どは同人誌なのである。ハッキリ言って、「技術書専門出版社」と言うもののその殆どは同人誌販売屋、なのだ。よって「マトモな技術書」と言うものを見つけるのはすごく難しいんだ(※4)。
素人が想像すると、
「何か本を出すのは物凄く難しいんだろうし、出版社側が"信頼を置ける"著者を探し出して企画をキチンと出して書いてもらってるんだろう。」
とか思うだろ?
実は違う。世の中に出ているいわゆる「技術書」のその殆どは持ち込み企画なんだ。
つまり、一回も本を書いたことのない人が「こんな本出せば売れるんじゃね?」ってぇんで、出版社に原稿を持ち込む。出版社側としては「ある程度元を取れればいいや」的に考えてgoサインを出す。ここで編集がやるのは誤字脱字のチェック程度だ。それで出版されるわけだ。
ちょっと考えてみれば「これはかなり異常な出版体制だ」って分かるだろ?一体、世の中の誰が、例えば素人のマンガ描きが集英社に原稿持ち込んで即単行本になる、なんて考えるだろうか。フツーはこんな事は「あり得ない」んだけど、この「あり得ない事」がまかり通ってるのが「IT系出版業界」なんだ。
要するに「出版物のクオリティ」ってのに全く信頼がおけない、って事になる。
それが現実だ。
断っておくが、プロのプログラマ(当然、プロの「物書き」ではないわけだが)がプロ向けに何らかの技術のHow toを伝える、って意味ならそれでも問題はないのかもしんない。
問題は、だ。プログラミング初学者用書籍を出版するなら「それでエエんか?」って事だ。
例えば、だぜ。日本語覚えたての幼児向けの本を出すことを考えてみろ。文筆家としては全くの素人が書いた本を読ませるべきなのか。そうじゃないだろ?「子供向け」だからこそフツーの本を出す以上に神経を使わなアカンのだ。
プログラミング初学者は「そういう状態」だ。今から伸びるか伸びないか、ってのは最初の一冊にかかっている。「既にプロとしてやっている」プログラマ向け「以上に」神経を使わなきゃ「プログラミング入門書」とか書けないんだよ。いや、書いちゃいけないんだ。
繰り返すがプロが書いたプロ向けの書籍に関してはどーでも良い。そうじゃなくって「初心者向けの本のクオリティ」は上げようとしてなかなか上げられるもんじゃない、って話だ。
例えばこういう事を書くと「ネット上で査読したらクオリティが上がる」とか言う意見を言うヤツが出てくる。冗談じゃねぇよ、と。査読なんざ複数人数でやってもクオリティなんざ上がるわけがねぇんだ。せいぜい「バクマン。」での七峰透君状態になるだけ、だ。
本を出す場合「想定読者像」と言うのをしっかりとイメージしなければならない。果たして、プログラマのプロでも編集的にはトーシロがそういったイメージ作りが出来て、それに沿って査読なんざ出来るのか。
せいぜい出来るのは「誤字脱字チェック」くらいである。しかも、初学者向けへの説明には「嘘も方便」が必要だ。しかし、恐らくそういう「曖昧な記述」ではなく、厳格な説明しか求めないだろう。これも「プログラマのプロ」ではあっても「編集作業を行う人」としてはトーシロだから、だ。
プロは日常的に「専門用語」を使う。従って「プログラミング初学者」の所与の知識の想定が出来ない。っつーかゼロである、って仮定さえ出来ないんだ。一体どの辺から「専門用語を混ぜだすか」その指針も分からんだろう。
そしてよってたかった結果、「誰向けの本を書いてたんだか」サッパリ分からなくなる本が出来上がる。
そして、筆者側としては、色々言われるのが嫌ならK&R辺りを下敷きにした「無難な本」しか作れないのだ。しかし、往年のリファレンスとしてならいざ知らず、プログラミング初学者向けへのK&Rの章構成はサイテーだ(※5)。
どれもこれも、ぶっちゃけ、「IT出版社にマトモな編集がいたら」起きない問題なのだ。しかし、IT出版社にはどうやら「バクマン。」の服部哲氏にあたる編集は存在しない模様だ(※6)。だから「ネットで査読」なんつー毒にしかならない方法論が蔓延する。
一方、「査読」行為がネットで拡散すると、ある意味そのテの本の著者には有利になる。情報が伝搬して出版した本の知名度が上がる、からだ。だから「お布施」と言う行為が出てきて、数字上は本の売り上げが見込める。出版社側もそして「書評依頼」としてアルファブロガーなる層に献本してブログで取り上げてもらう。
とどこまで行っても内輪受けの本の出来上がり、である。大体、身銭を切らない本の書評なんざアテになるか、と言いたい(※7)。アルファブロガーなる者達だって本をタダで入手してぇから厳しい事は書かんだろ。出版社が臍を曲げても困るからな。
プログラミング初学者はこういうヘンな出版体制の同人サークル状態には巻き込まれないようにして離れていた方が良い。
と言うわけで、依然と初学者には冒頭に挙げたネットでタダで読める文書を使ってRubyをまずはやってみる事をオススメする。
どうしてもPythonをやりたい、と言った場合、結論から言うと日本の本を買っちゃダメだ。これはPythonに限らず、どの言語でも言える。欧米で書かれて出版された本の翻訳本を買え。多少値段が高くても、翻訳された文章が硬くても、長い目で見るとそっちの方がマシなのだ。
別に僕自身は欧米マンセーの人間ではない。だから本の著者となった場合、欧米人の方が日本人よりアタマが良くって良い本を書くから、と言った理由でそれを薦めてるわけじゃあないのである。単純に資本主義的フィルタがそこにかかってるから言っている。
ぶっちゃけた話、「同人誌制作率」は日本より欧米の方が高いかもしんない。でも日本に入ってくる本は結果質の良い本が入ってくる。何故か、と言えば簡単だろ?どの出版社も翻訳本を出す際に箸にも棒にも引っかからないような本をわざわざ翻訳・出版しよう、とは思わないから、だ。要するに向こうで「分かりやすい」と既に売れた本であり、実績がある本であり、そうでもなければ日本で翻訳出版、と言う運びにならんから、だ。資本主義的フィルタ、って言ったろ(笑)?
まぁこうやって好きな事を書いてるが、中には
「クソ、IT出版社編集部とせっかくコネが出来て小遣い稼ぎしようと思ってたのに余計な事書きやがって」
とか思う人もいるだろう。
ただ、繰り返すが、プロがプロ向けに、どういった過程を経ようと、本を作って出すこたぁ勝手である。好きにすりゃあエエ。
ここで問題にしてるのはあくまで「初学者向けと謳ってる本」の話をしてるんだ。あまりに粗悪な本が出てる、そしてそれを作り出す体制になってる、って言ってるのであって、なおかつこちとら身銭を切ってきてるんだ。怒る権利は当然あるのである。
そして話をもっとPythonに寄せていく。
この「プログラミング初学者向け」って事でPython界隈はある意味バブル状態である。
しかしながら、本当にPythonを知ってて理解してるヤツが書いてんのか、っつーと疑わしい本が多い。ぶっちゃけ「C言語しか知らんのだけど、Python程度の本だったら簡単に書けるだろ」と言ったようなフザケた本が出てきてるのだ。
出てきた。「C言語がすべての基礎である」と言ったような世迷い事を言ってる層だ。C言語脳の奴ら。
断っておくが、真のC言語のエキスパートはこんな考え方はしない。問題は残りの奴らだ。その中で「小遣い稼ぎ」を狙って「Pythonを使ってC言語を教えようとする」ドアホが出てきているのである。タイポじゃないよ?文字通り、「Pythonを使ってC言語を教えようとする」ドアホがいるようなのである。
とこんな事を書いてるが。人によっては
「あんたの書いたPythonコードを見たけどPythonらしくねぇよ。あんたこそPythonでLispを教えようとしてない?」
とか思う人もいるだろう。
しかしハズレだ。全然そんな事は意図していない。
いや、僕が色々と洒落で書いたコードは確かに「Pythonで書くスタンダードとは思えない」と抵抗を感じる人もいるかもしれない。ある意味「PythonでLispを教えようとしてる」ように見えるとは思う。
しかし誤解だ。
言い訳させてもらうと、まずは「C言語がすべての基礎」と言うような世迷い事をまずは捨てて欲しい。そして全てのプログラミング言語は「おしなべて皆平等である」わけじゃない。全てのプログラミング言語には抽象度の高低がある。そしてどっちかと言うと、単にPythonはC言語より、よりLispに近いだけ、なんだ(いつか書いたけど「PythonはC言語の派生」なんつーのは大嘘だ)。
そしてLispは抽象度の位置では最高位に属する。C言語は最低辺だ。それだけ。
感覚的に言うと、Pythonは取り立てて特徴のある言語だ、とは思っていない。非常に「平凡な」「中庸な」言語なのである。恐らくあらゆる言語を集めて抽象度を比較してみても「ど真ん中」の位置にいるだろう。それくらい「フツーの」言語だ。
しかしそれでもC言語よか高抽象度なのだ。それをもって「Lispにより近い」と言っている。
そしてそういう感覚ってのは「抽象度の低い位置」から眺めても分からんモンなんだ。「C言語は全ての基礎」と言う世迷い事を盲信してると全く見る事が出来ない。これをポール・グレアムは「ほげ言語のパラドックス」と呼んだ。
ポール・グレアムのこの発言は賛否両論を呼んだが、大方正しいと思われている。と言うのも、実の事を言うとプログラマってのはあまり「新しい言語を自ら学ばない」モンなんだ。C言語使いだってANSI Cに齧りついてC17と言う新仕様を自ら学ぼう、って事さえしないのがフツーだ。ましてや何かの仕事上の要請でもねぇ限り、「自ら新しい言語を学ぼう」とは思わない。
ところが、複数の言語を自ら学ぶ好事家なプログラマになってくると「抽象度の違い」ってのが現実問題「ある」って事に気づいてくる。ある特定の問題に対して「C言語が絶対書きやすい」ワケではなく、他の言語の方がどう見ても「得意だ」って現象に出くわすわけだな。その辺で「言語にはパワーレベルがあるんじゃないか?」って分かってくるわけ。
だから複数の言語を知ってる層程「ほげ言語のパラドックス」ってのは確かに存在する、ってのを知覚してくるわけだ。結果、取り立ててLispを持ち上げる気がなく、ポール・グレアムに大賛成、ってワケじゃなくても、抽象度の高低がある、って事だけは分かってくる。
それでだな。殆どのLisperはそういうこたぁしねぇんだけど、僕はLispを使うし好きだけどLisperではないんで、Pythonも使う。
んで、Pythonを使う際に気をつける事は「Lispで出来る事で何がPythonで出来ない事か」考える事なの。
こういう事書くと
「あれ、Lispは実用的じゃない、って言わなかった?なんでLispで出来る事がPythonで出来ない、って仮定してんの?おかしくね?」
とか言う人も出てくると思う。
いや、言ってるレベルがちょっと違うんだ。確かにLispはそんなに実用的ではない。一方Pythonは実用的だ。
でもその差を何が生むのか、と言うのは「ビルトインライブラリ」とか「外部ライブラリ」とかのライブラリの差なのね。
ここで言ってる「Lispで出来る事でPythonで出来ないこと」ってのは「構文の自由度」の事を指してる。ライブラリの差を考えなければやっぱりLispの圧勝なの。あらゆる事を自分で自由に書ける。
でも実用レベルで考えると、その「書く」のがメンド臭いわけじゃない(笑)。PythonはLisp程自由じゃないけど、ぶっちゃけ「何か作らなくても」プログラムにはなる。そういう事なの(※8)。
構文の自由度とライブラリの豊富さ、ってのは要するに関係ないのね。僕が言ってる「Lispで出来る事で何がPythonで出来ないか」と言うのは、Lispの構文上の自由さで許される事のウチ、Pythonの構文上許されないのは何かチェックする、って事(※9)。
結果、
- Lispのコード - Lisp構文の自由さ = Pythonコード
って方程式になる。これが僕の書いてるPythonコードの正体だ。
で、LisperはまずPythonは使わねぇ、っつーかLisp以外の言語を嫌ってるんで(笑)、LisperがPythonコードを書くこたぁあり得ないんだけど、恐らくPythonを彼らが使ったら僕が書いてるようなコードになるんじゃねぇのかなぁ。もっとも彼らはそもそも「不自由さに我慢ならない」人たちだけどね。
いずれにせよ、同様に、生粋のPythonistaがCのコードを書く場合、
- Pythonのコード - Python構文の自由さ = C言語のコード
になるだろう。方程式を弄くれば
- Pythonのコード = C言語のコード + Python構文の自由さ
になる。明らかだ。問題は凡百のC言語脳は「Python構文の自由さ」を学ぼうとしない辺りなんだわ(※10)。
繰り返すけど、真のC言語エキスパートはこんな考え方はしない。「郷に入りては郷に従え」ってのを知っている。でも凡百のC言語脳はやっぱ「C言語は全ての基礎」って妄言を信じ切っていて「足りない部分を学ぼう」とはしないんだ。
そして最悪な事にPythonはC言語的に書いた汚ねぇコードでも動くんだよな(※11)。何故ならPythonはC言語より抽象度が高いからだ。一般に、抽象度が高い言語はそれよりも抽象度が低い言語での書き方を全て受け入れちまう(※12)。
もちろん、自分でPythonを使ってプログラミングをするだけならどんな風に書いても構わないだろう。僕もPython使ってる時は好きなように書いてるしな。
ただしだ。プログラミング初学者向けに本を書こう、っつーのならそれじゃダメだろ、って事を言ってるんだ。もっとPythonをマジメに勉強してから書け。Cしか知らずにPythonのコードを汚く書いて、これが綺麗なPythonコードです、とでも言うつもりなんか?ふざけんな、って話をしてるんだ。
だからこーゆー輩が跋扈してて、スタイルの伝授もクソも無くなってる、ってのが今のPythonブームの裏側なのである。
だからホント、今まで一回もプログラミングをやった事がなくって、今からプログラミングを学びたい、って人達はPythonを避けた方がいい、とまで思うようになったんだ。今のPython界隈は伏魔殿である。ろくすっぽPythonを学習した事が無いC言語脳が害毒を垂れ流している状態だ。
とまぁ、今まで危機感を覚えてアッチコッチに書いてた事をここで纏めている。
もう一度言う。まずプログラミング初学者がもしもPythonから始めたい、と言うのならまずは洋書の翻訳本を買え。Pythonは既に紛れが多い言語になってる。そんな中で最善手は、まずは洋書の翻訳本の購入になる。
そしてGoogle Colabなんぞには手を出すな。なんかオンラインでやればインストールも不要で簡単、とか一生懸命宣伝してるらしいがそれはウソだ。結果初学者にゃ一番敷居が高い方法論になっている。そしてそれを薦めたヤツは決して貴方のサポートはしない。それで教えて!gooに困って質問投稿するようなハメになるんだよ。初学者にGoogle Colabを薦めるバカは総じて無責任である。
じゃあ、PaizaとかProgateなんかのプログラミング学習サービスやらYouTubeなんかの動画で学ぶ事はどうなのか。結論から言ってしまうと、サブ媒体としては悪くはないがメインにはならないししてはいけない。まずはしっかりした本を買え。話はそれから、だ。
このPaizaやらProgateやらに引っかかって教えて!gooに質問してくる、って状態に辟易してた。と言うか学習サービスなのに質問を受け付けてないの?ってビックリしてたクチである。当然ながら、そんなんだったら意味がねぇのである。少なくとも、これでの学習で成功してる人は一人しか知らん(言わずと知れた星田さんだ・※13)。
大体、サイトのトップで受講者のサクセスストーリーとか貼ってたりするが、んなのホントかどうか分からんわけだ。そもそもそいつらが実在してるのか、って事さえ疑わしい(笑)。広告だったら何でもアリ、だからな。モデル事務所に頼んで写真撮って、適当な文章貼り付けりゃあ一丁上がり、である。基本的に雑誌の裏表紙の怪しい広告と大して変わらん、と思ってる。こんなヤツな。
そしてこれを疑う最大の理由。それはPaizaやProgateが受講者の中から優秀者を青田買いしてるかどうか、である。そんなにすぐに優秀なエンジニアとして育てられる、としたらそのサービスを提供してる会社が雇用してなければおかしいだろ、って思うわけだ。雇用してない、としたらそこまで絶大な学習効果があるわけではない、と言う話になる。
話半分にしとけ。そしてだからこそこういう媒体を「学習の中心」に据えればダメなのだ。
じゃあ動画はどうか。悪くはない。いや、「悪くはない」ってレベルなだけだ。言い換えれば可もなく不可もなく。つまり学習効果もありとも言えない、ないわけでもない。要するにどっちつかずで推せないわけだ。
最大の問題は不便だと言う事だ。「え?」とか思う?動画は便利なのに?
確かに初見は楽しいだろう。しかし、動画はシーケンシャルアクセスが前提なのだ。つまり、貴方が何かに躓いて「調べ直したい」と言った時に特定の発言をしてる特定の場所を探すのが困難なのだ。ハッキリ言って調べ直したい、等と言った場合、本の索引から該当箇所を探す方が簡単なんだ。
言い換えると、書籍はランダムアクセスを許す。動画はそういう媒体ではなく、初見で観る分には楽しくても「何度も観直す」には逆にツラい媒体に変質するんだよ。
本は読むやつが早ければ早いし、貴方の気分によっては「読み飛ばし」も可能だ。そこに個人差が生まれる。そして時間が短縮出来る。
一方、動画は、例えば20分モノなら誰が観ても20分だ。これを何度もアタマから再生すっか?視聴時間は本で費やす時間より結果長くなって非効率的なんだ。
動画に頼るな、とは言わない。時には有用なのは認めよう。ただし、学習のメインに据える程、ではないんだ。「動画で全部学ぼう」なんつー調子のいい事は考えないように。
オンライン学習サービスも動画で学ぶスタイルも将来もっと便利になるかもしれない。そこは否定しないが、言いたいことは「それは今ではない」。
人身御供になりたいんです!とか言う強い意思でもない限り、まずは洋書の翻訳書を入手して、それをメインとして、サブとしてオンライン学習サービスなり動画を併用する程度に留めよう。
口を酸っぱくして(タイピング的には腱鞘炎になりながら)繰り返す。初学者がPythonをどうしてもやりたい、と言うのならまずは欧米で書かれた初学者向けの翻訳本を買え。
そして一番良い方法論は冒頭にも書いた通り、Web上の文書を使ってまずはRubyに触ってみる事、だ。Pythonは2番目に学習する言語にすれば良い。そうすれば色々な準備が整う。RubyはPythonとライバル視されてたが、実の事を言うとPythonより高抽象度だ(つまりよりLispに近い)。それは貴方に俯瞰的にPythonを「見下ろす」地点を与える。
Rubyで出来る事で何がPythonに出来ないか考えよう。そしてこの時点でたとえC言語脳が書いた本を使っても「批評的に」コードを読む事が出来る筈だ。
1個目の言語の場合は「言われるまま」書くしかない。2個目の言語になれば「貴方は考えながら本を読んでコードを書く事が可能」になる。「自分ならこう書く」とリファクタリングしながら書け。それはとても良い練習になる筈だ。
結果、貴方はC言語脳ウィルスに抵抗力を持つ事が出来るだろう。最初にRubyを学んでおけば貴方はC言語脳に対抗するワクチンを手に入れる事となる。
C言語脳パンデミックを避けるんだ。
僕は今は、それが正しいルート、だと信じている。
※1: 一つの指標として、プログラマが再定義不可能なリテラルの並び、つまり「予約語」(例えば多くの場合、条件節を形作る「if」の再定義は出来ない)の多寡、があるが、しかし現実的な観点では予約語が少ないから、と言って「覚える事が少ない」は成り立たない。
※2: 何度も言うが、Cの優勢が決定的になったのは、マイクロソフトがWindows 95対応のVisual C++を発表して以降、であり、UNIXは全く関係がない。それまではPascalとCの優勢はどっちつかず、だった。
また、90年代半ばくらいまでは典型的なアメリカの大学のカリキュラムでは、最初にPascalを学ばせるトコが多く、Advanced CourseになってからC、と言うパターンが定番で、結果として、当時学んだCプログラマはPascalもよく知ってたのである(つまり、当時、アメリカの大学で学んだプログラマは、仕事場の要求じゃなけりゃ「好みで」CかPascalかのどちらかを選んでた、と言う事だ)。
そして、Pascalはそもそも「教育用言語」として設計されていて、まさしく「プログラミングの基礎」を学ぶには良い言語だと当時は考えられていた。従って、「Cはプログラミングの基礎」なんつー世迷い言は当時は無かったのだ。
余談だが、実用Common LispやSICPの冒頭に「今は使われてない」Pascalへの若干、批判めいた文章が載ってるのは何故か、と言うのは、これらの本の出版当初、ほとんどのアメリカの大学では、初級者用言語としてPascalが選定されていた、と言う背景があったから、である。
当時はそれくらい、嫌でもPascalはポピュラーなプログラミング言語だったのだ。
※3: また、これがC言語を薦めない別の理由でもある。
ぶっちゃけ、市場に溢れる「C言語入門」の類で、「標準C言語を教える本」は一冊もない。
「C99対応」とか「C11対応」とか謳っててもそれがウソだ、ってのが最悪なのだ。「本当に言語仕様に目を通したのか?」と思うくらい、ANSI C/ISO C89の書き方で書いてある。30年前の書き方をしていて全く最新のCに対応していない、ってのが実情だ。
そんな本、どうにも薦めようがないし、著者陣が「勉強してない」ってのが明らかとなる。
Cはバックワードコンパティビリティに神経を使って設計されているので、「古い書き方でも動く」のが初学者向けとしては学習上の諸悪の根源であって、結果、老害のようなプログラマが昔の「不便な」書き方を若者に強要し、マウントを取りやすい言語となっているのだ。
結果「カッコイイコード」を論じる以前の状態である(そして狂ってる事に、Cの「カッコイイ」は、通常、バッドノウハウと密接な関係がある)。
※4: 全部の出版社がダメ、とは言わない。
これらしかない。
一応言っておくけど、別にこれら出版社から金を貰ってるわけではない(笑)。そもそもこんなマイナーブログの発言とか誰も気にせんだろうし。
いずれにせよ、「身銭を切って」何度も失敗した経験から言うと、この3社だけは別格だ。特にオーム社は「自社で企画を立てられる」編集が多いっぽいんで、信頼に価する。
※5: そもそもK&R自体はプログラミング初学者向け、を想定してない。序章を読めば分かるが、元来はPascalやFortran経験者に向けて書かれたモノであり、ズブの素人が読むようには作ってない筈なのに、プログラミング初学者向けにこういう章構成を丸パクリした「つまらん本」まで出てる始末である。
なお、実の事を言うと、大方「☓☓プログラミング入門」等の題名がふってある本は「入門書」とは言っても「初学者へのプログラミング入門書」を意図してる事は少ない。だから「入門書」と書いてて初学者向けなのか?と思って読み始めるとすんげぇ難しくて「何じゃこりゃ」ってなる人は割といるんじゃないか。
プログラミング初学者が技術書を見る際には「入門書は入門書を意味しない」と言う事をキチンと押さえておこう。本屋で立ち読みする際は序文辺りに目を通して「初学者向け」を意図して書かれてるか確認する癖を付けよう。じゃないと、どっちにせよ「誰向けに書いた本だか分からん本」を掴まされる可能性がある。
※6: 「査読」とは関係ないが、どうしてAmazon辺りで批判される「コードが全く動かない書籍」が出版されるのは何故か、と言うのは、要するに「IT出版社の編集」が誤字脱字しかチェックしないから、である。自分でコードを打ってみて動くかどうかチェックする編集がいたら「良心的だ」と言えるだろう。
しかし、何度も繰り返すが、IT系出版社は所詮「同人誌屋」なので、書籍に重版をかけるつもりもないし、粗悪本を作ったとしてもすぐ廃刊にする前提なので、「キチンとした編集作業」は割に合わない、と思ってるらしい。
※7: 余談だが、僕が本を購入しようとする場合、当然アルファブロガーなる者達の書評なんざ読まない。頼りにするのはAmazonに投稿されている「身銭を切った」名もなき人々の書評だ。しかも悪口を探すようにしている。「褒めまくりの本」は、これまで説明した、IT系出版社の出版方針から言うと、確実に「怪しい」のだ。
そして「合理的な悪口」なのか否かを検証するようにしている。その方が、ハズレを引く確率が低い、と思ってる。
あとは本屋で実際に確かめてみるだけ、だ。
※8: ある意味、Pythonは「プログラミングをする為のプログラミング言語」ではなく、レゴのようにブロックを拾ってきて組み合わせる言語、となっている。
ちなみにこういう発想は、かつて批判されて失敗した経産省のΣ計画の内訳とそっくりで、「とにかく大規模なライブラリを集中管理して、それを用いて簡単にプログラムを組み立てられるようにする」と言う発想自体は実は間違ってなかったんじゃないか、と思われる。
Σ計画の失敗は、ハードウェアメーカーを巻き込んだ事にあるんじゃないか。
※9: この辺の「構文の自由度」がピンと来ない人に補足しておく。
例えばPythonで、「リスト (lst) から要素 (x) を取り除いたリストを返す関数を書け」と言う問題を考える(もちろんPythonのリストにはremoveメソッドがあるが)。
オーソドックスにPythonで書けば以下のようになるだろう。
def my_remove(x, lst):
acc = []
for item in lst:
if item != x:
acc += [item]
return acc
しかしLisp使いが「構文の自由度を試せ」と言う命題を与えられると、次のように書くのがPythonで許されるのかどうかチェックするのだ。
def my_remove(x, lst):
if lst == []:
return lst
else:
h = lst[0]
return (lambda y: y if x == h else [h] + y)(my_remove(x, lst[1:]))
多分そこそこPythonを自由に扱える人でも「ウゲ」とか思うだろう。C言語脳に至ってはまたもや「難読だ!」と騒ぎ出す筈だ。
もちろんこの書き方が「Pythonでスタンダードたるべき」と言ってるわけではない(大体、Pythonは「再帰が苦手な」言語だし、ラムダ式もヘナチョコだ)。
しかし、「この程度」のコードはLispでは「至極当たり前の」コードである。だから「Python構文の自由度」をチェックするには丁度良いんだ(だから実用上こう書け、とは絶対に言わないし、僕もPythonではフツーこんな風には書かない)。
「ほげ言語のパラドックス」は別にマクロを持ち出す程の話でもないのだ。
Lispを良く知ってる層だと「関数がファーストクラスオブジェクトで、ラムダ式が使えるんなら、この程度のコードは機能的には当たり前に書けなきゃなんないよね」と言うだろう。つまりLisp使いにとって上のコードは常識(あるいは定番テクニック)なのである。
一方、C言語では関数はファーストクラスオブジェクトではない。ラムダ式もない。C言語脳がPython入門書を書く時、「関数はファーストクラスオブジェクトです」って書くだろう。しかしそれは「皆が言ってるからそう言ってる」だけであり、実は「関数がファーストクラスオブジェクトである」と言う意味を分かってるわけではないのだ(自在に使えない、ってのはそういう事で、上のLisp調のコードなんかは思いつきもしないだろう)。分かってる場合は上のコードの意味を即刻理解して許容する筈だ。
言い換えると、Lispの目で見るとPythonはそこそこの自由度が保証されてる言語だ、と言う事になる。ある程度は「安心して使える言語」なわけだな。
一方「C言語の常識に凝り固まった」C言語脳の目には「Pythonは良く理解できないC言語的には邪道な機能(だからそれらは使いたくないし使わないようにしよう)が満載なプログラミング言語」に映るわけだ。
もう一度「ほげ言語のパラドックス」が何を意味してるのか考えてみよう。
※10: 僕は「関数型言語ユーザーは怠惰だ」と言ったが、一方こう言うのは怠惰ではなく、単純に頑固である、とか頑迷である、と言った類の性質である。
※11: 繰り返すが、C言語経験者がJavaを覚えてすぐ、Javaしか知らないユーザーよりJavaコードを綺麗に書くようになる、って話は事実だろう。
ただし、それは元々JavaがC言語系(正確に言うとC++)を模した構文を採用してて、似た構文の言語なら綺麗に書く事が出来る、と言う割に当たり前の話なのだ。しかし、それが「どんな言語でも綺麗に書く事が出来る」保証なんかにはなりはしない。
※12: Lispも同様である。C言語はLispな書き方は受け入れないが(抽象度が低いから)、LispはC言語的な書き方もやろうと思えば受け入れてしまうのである(それは、決して「C言語がプログラミングの基礎だから」通用しているのではない)。
※13: 星田さんの場合特徴的なのは、基本メモ魔なんだろう。ブログで「進度を記録する」とかやってないとオンライン学習サービスを上手い事活用出来ない、と言う事である。
で、確かに「進度チェック」なんかは本と比べて、オンライン学習サービスの利点だとは思われるが、星田さんの場合は検索能力が格別で、要するに「学習サービス」にベッタリで調べる手段が無い人だ、と言うわけではない。進度チェックで悩んだ場合、星田さんみたいに代替手段(つまり検索を駆使)を容易に行える人でないと、早々と挫折する事は簡単に想像出来る。
要するにこれはある種「才能」の話であって、いつぞや書いたけど、プログラミングに必要な能力は理論性よりも検索能力である、って実例である。
