  |
はてなキーワード: common lispとは
どんなに優れたツールや設計思想などがあっても、使う奴がダメだと全く無意味。弊社もWebアプリを作ってて、RESTだのFluxアーキテクチャだのいろいろ導入を試みたが、ほとんど無駄に終わった。
どんなクソ組織でも効果があると確信持って言えるのは上の3つだけ。1つ目は初歩的すぎると思われるかも知れないが、筆者の想定するダメな組織・ダメなプログラマというのは、このレベルの連中を含む。
静的型付け言語（サーバーサイドならJavaやC#、フロントエンドならTypeScript）を使わせれば、少なくともコンパイル時に分かるエラーは修正させられる。
というか、ダメなプログラマに動的型付けの言語は触らせてはいけない。必ずそのプロジェクトは半年後には保守できなくなる。
テストは強制的に書かせるし、テストのないクラスや、通らないテストあったらコミットできないようにする（それは容易にできる）。
もう一つの方法は、そもそも優秀なエンジニアしか参加できないようにすること。たとえば、Scala、Haskell、Erlang、Common Lispなどで書かれていれば必然的にそれが分かるエンジニアしか開発できないし、こういう言語を自主的に学習しているエンジニアは優秀である可能性が高い。
一周目は軽く読み流し、二周目にコードを書きながらしっかり読んだ。2週間かかった。
これに手を付ける前のLisp歴は1週間。ネットでLisp入門読んだ程度。
オライリーの本にあるまじきファンキーな表紙なだけでなく、中身もジワる漫画やイラストがちょくちょくある。
にもかかわらず内容は恐ろしく難しかった。
読んでいて素晴らしい技術書だと絶賛されているのがわかったし私もそう思うが
ソケット通信やゲーム木、ミニマックス法によるAIの実装など出てきて
それを今学習中の未知のプログラミング言語で解説されるので二重の複雑さ・苦しみになっていた。
---
1年の間、プログラマとして働いていたが、続けていくことが無理だと思い、さようならする話。
プログラマになる前は、コーヒー屋で働いていた。しかし、色々とあり辞め、職業訓練校に通ってプログラミング(php)を学び、60人ほどのソフトウェア開発会社に就職した。
会社に入ると、まずC#の研修があった。研修と言っても、C#で内製ツールを独りで作るという研修だった。この研修中に「あれ、オレ、プログラム書けねー」と思ったりしたが、研修は終えることができたし、社内の人にも「なかなか良く出来ている」と言ってもらえ、大丈夫だろうと思っていた。
研修が終わり、C#の社内で実際に使われているツールに、機能をいくつか追加する仕事を振られた。前任者にどんな設計になっているのか大雑把に聞き、なんとなくイメージができ、コードを読み始めたのだが、これが全く意味不明で、何のために有るかがわからないクラスが大量にあった。名詞の王国だと思った。前任者に、何故このクラスは、この単位で分割されているのか聞くと、「単一責任の原則だよ」とか「hogeパターン使うと、後から機能追加しやすいじゃん」というような回答をもらった。納得は出来なかったが、プルリクも承認されて、このツールがデプロイされていたので、社内的にも、このコードは、クソコードと言われる物では無いはずだと思ったので、自分もプログラムを書き続けていれば、こんな感じの設計に慣れてくるんだろうと思った。モヤモヤは残っていたものの、仕事はしなければいけないので、前任者のコードに習うように、クラスを追加したりして、機能を追加した。プルリクを出すと、設計には何も言われずに、タイポや、テストコードを注意されただけだった。指摘された点を修正すると承認された。振られた仕事は完遂した。が、結局最後まで、モヤモヤは消えなかった。むしろ、モヤモヤモヤモヤになった。
次に振られた仕事は、内製ツールを設計から自分で行い作成する仕事だった。言語はGoだった。Goで書いてと言われた時は、以前からの自分のモヤモヤはオブジェクト指向のせいで、モヤモヤしているんじゃないかとも思っていたので、喜んで！という感じであった。が、Goを触ってみると、結局、Goも継承の無いオブジェクト指向言語やないかと思った。Goの標準ライブラリのinterface名もHogerみたいな感じに接尾辞に-erを持ってくることが慣習らしく、この命名だと、interfaceを満たす構造体自身が-erになるので、正にオブジェクトだなぁと思った。巷での「Goはオブジェクト指向ではない」というのに期待していたのだが、自分にとっては、とてもオブジェクトしていました。
Goに対する印象は良くなくなったが、ツールの設計をしないといけなかったので、Goの構造体をC#のクラスに見立て、前回の前任者のコードのように、単一責任も持つ構造体に(無駄に)分けて、プログラムを書いて、プルリクを出した。自分でクソなコードだと思いながら。だけれどもレビューでは、「errorのチェック忘れ」「標準ライブラリにこの機能ある」「こんな風に書ける」といった感じだった。こんなコードで良いんかよと思ったが、良いらしい。ワケワカメだった。
ここらで、プログラムを書く仕事は、無理だと悟った。現実世界は、自分が自然だと思う方法と違う方法で、プログラミングをすることを強要してくる。
ちなみに、仕事ではC#とGoを書いていましたが、オブジェクト指向と仲良くなるためにSqueak(Smalltalk)で、オレオレ言語を作ってみたりもしましたが、何が嬉しくて、オブジェクト同士のメッセージパッシングでプログラムを作るのかわかりませんでした。
Clojureは、気持ち良くプログラムを書いていても、Javaが顔を出すところでフラストレーションが溜まってしまって、つらくなりました。
Common Lispは、自分が触った言語の中でも、秀でて良いと思いました。プログラマを辞めても、プログラム書く必要に迫られたらCommon Lispで書こうと思うくらいにです。Land of Lispが楽しいです。あと、CLOSの総称関数の考え方が大好きです。
最後に、この投稿は、一種の決別の表明です。いつまでも、自分に向いていなかったことに、時間を掛けてしまっている自分との決別です。
あ、まず前提として、
はたして貴女を幸福にするかどうか、それはまた別問題だけれど。
ＩＴ系の超かしこい男なども多く、
多くっつーかIT系でないのにプログラミング大好き男っていうのは超かしこい学生（まぁこれは有望株）か研究者系なんか、
あとはまったくかしこくもないクセに頭いいつもりして「Lispやってます（ｷﾘｯ ハローワールドくらいですが」とか言っちゃうアホしかいないわけで、
したがって、釣り師たる女たちにとっては、
なかなかあなどれない釣り場です。
では、プログラミング大好き男に「どの言語が好き？」と訊ねられたとき、
まず最初に、その男がCOBOLのようなタイプのレガシーコードと
あとはC/C++、そして（TechEdに参加するほどではないけれど）VisualBasicが大好きな、
貴女はかれの目を見て、微笑みとともに質問など無視して、こう言いましょう、
「わたしが、仕様書を作ってあげる♪」
これこそまさに必殺の答えです。
そこでプログラミング大好き男が、えへへ、とやにさがったならば、
貴女は、ひそかに、「コピペ量産しやすい技術的ポイントを抑えた仕様書」あたりを
ひそかに練習しておきましょう。これで成功まちがいなしです。
しかし、ここでは、もう少しハイブロウな（？）いわゆるプログラミング好きの男の
落とし方をお伝えしましょう。
「わたしは、JVM上のScalaが好き。
型推論もあるしラムダ式やクロージャもスクリプト言語みたいに書けるの、豊富な組み込みのコレクションメソッドはいつも便利だし、
XMLリテラルもCaseクラスによるパターンマッチもTraitベースのMixi-inも、大好き♪」
もしも貴女がそう答えたならば、
かれの貴女への恋心は、
２０％増量になるでしょう。
なぜって、Scalaは、
コンパイルは遅いながらも、そこがまた
ちょっぴりメモリを多く積めばいい富豪プログラミングみたいなふんいきをかもしだしていて。
質高くふるまっていて、なおかつ、
JVM上で動くくせにJavaが「やるやる」と言ったまま実装してなかったラムダ式と仮想拡張メソッド、型推論を実装した功績もあって。
したがってScalaこそは、
本来なんの接点もないまったく縁もゆかりもない別々の世界に生きている、
インタプリタ言語大好きな綺麗系ＯＬと、玉もあれば石も混じっている、そんなプログラミング大好き男たちが、
この世界で唯一（いいえ、JVM系列のJRuby、Clojure と並んで唯三）遭遇しうる場所です。
●
では、参考までに、危険な回答を挙げておきましょう。
プログラミング大好き男に「どの言語が好き？」と訊ねられたとき、
「MicrosoftのVisual Basic for Applicationが好き♪ 週３回は Excelでコーディングするの。」
特にOfficeは平凡ながら、ま、無難にまとめてあるものの、
しかし、「新UIのリボンUI！」「メトロUI対応！」とかなんとか無意味な自慢を吹聴し、
VBAはさらにプログラミングについての謬見を撒き散らした罪がありますから、プログラミング大好き男にとっては天敵なんです。
ティーガー戦車乗りのオットー・カリウスは「ティーガー乗りなら誰でも片側の履帯がはずれ僚車に牽引されて帰ってきた経験を持つはずだ」 って言ったけど
社内SEかSIerなら誰でもクソみたいな前任者が書いたクソみたいなExcel-VBAコードを直した経験があるはずなんです。
また、もしも貴女が「PHPが大好き♪ あたしが書いたPHPのWebサイトが、さくらサーバに７件あるよ♪」
と答えたとしても、同様の効果をもたらすでしょう、
なぜって、PHPは、１９９０年代にはWeb系を目指す人にとっては簡単で要件を満たすWebサイトが簡単に作れる輝きの道だったものの、
しかし２０００年代そうそうから、セキュリティ関係の問題で転落し、
いまや、あの貧弱な言語能力では、Rubyの魅力に遥かに及びません。
（注１）
「わたし、.NET FrameworkのC#が好き、フォームアプリでも書くけど、
最高に好きなのはASP.net♪ SQLServer連携も、ajax control toolkitもすっごくおいしいの。」
と、答えたとしたらどうでしょう？
なるほど、貴女の趣味は高く、
たしかに.NET Frameworkは、C# が cool であるのみならず、
.NET Framework上で動く F# や IronPythonやIronRuby、マネージJScriptも最高においしいんですけれど、
しかし、貴女の答えを聞いて、プログラミング大好き男はきっとおもうでしょう、
（なんだよ、MS信者な女だな、カネかかりそう）って。
（注２）
貴女が、プログラミングが大好きで、言語の名を挙げるにしても、
たとえば、JavaScript(node.js)ならば安心でしょう、
なぜならば、JavaScriptは、かけだしのプログラミング初心者にもマニアにもともに愛されるめずらしい言語で、
貴女がその名前を挙げても必ずしも、(jQueryがやっとの初心者と思われることはあっても)あなたがプログラミング言語おた宣言をしているとは受け取られないでしょう。
むしろ「へぇ。ちゃんとprototypeは使ってる？」と聞かれたら「当たり前じゃない。むしろnode.jsでいいMVCフレームワークが分からないんだけど…」と話を振ってみましょう。
男は嬉々として、３０個くらいのnode.jsのフレームワークを教えてくれることでしょう。（まぁどれもどれで帯に短し襷に長しなんですが）
あるいはRighno上で動かしたコードをnodeへ移植する話とか、CoffeeScript、甚だしきはClojureScriptを振ってみてもいいかもしれません。
しかし、たとえば、世界が（つーか竹内先生とポール・グレアムが）誇る超絶関数型言語の名作、Common Lispにせよ、
selfと書きまくることと海外で使われてることに定評のあるPythonにせよ、
バージョンアップごとに言語仕様が変わり、かなり素敵なものではあるもののobsolatedな罠にはまりやすいRubyにせよ、
まったく読めない$_だらけで頭悪い仕様をリセットしてPerl6にする（そしてまた全く読めない）Perlにせよ、
気さくなクジラ飛行机さんがふるまう素敵においしい日本語プログラミング言語のひまわり・なでしこにせよ、
基地外トリッキー言語の代表BrainFxck・Glass・Missa・WhiteSpaceにせよ、
ましてや貴女が、「Haskellが大好き♪ わたし、プロジェクト・オイラーの問題もうほとんどHaskellで、解いちゃった♪」
と答えたならば、どうでしょう？
これはかなり博打な答え方で、
なるほど、Haskellは、純粋関数型でありつつも副作用のある操作が行える超絶名言語ゆえ、
あなたがそう答えた瞬間、プログラミング大好き男がいきなり超笑顔になって、
「へぇ、やっぱりHaskellなら大抵の問題は４行以内くらいで解いちゃった？」とか言いながら
鼻の下がだら～んと伸びちゃう可能性もあるにはありますが、
しかし、逆に、（なんだよ、この女、プログラミングおたくかよ）とおもわれて、どん引きされる可能性もまた大です、
なぜって、必ずしもプログラミング大好き男がプログラミング大好き女を好きになるとは、限らないですから。
男たちは、女を導き高みへ引き上げてあげることが大好きゆえ、
もしも貴女が、「Haskellが大好き♪」なんて言ってしまうと、
そこにはもはや、男が貴女に圏論のモナドを教育する余地がまったく残されていません、
したがって貴女のその答えは、
プログラミング大好き男の貴女への夢を潰してしまうことに他なりません。
ま、ざっとそんな感じです、貴女の目にはプログラマーたちはバカでスケベで鈍感に見えるでしょうが、
しかし、ああ見せて、プログラマーはプログラマーで繊細で、おざなりに扱われると傷つきやすく、ローカル変数の名前一つにも気を使い、女と自分の将来に夢を持っています、
貴女の答え方ひとつで、プログラマーの貴女への夢は大きくふくらみもすれば、
一瞬で、しぼんでしまいもするでしょう。
●
では、スキットを繰り返しましょう。
「わたしは、JVM上のScalaが好き。
型推論もあるしラムダ式やクロージャもスクリプト言語みたいに書けるの、豊富な組み込みのコレクションメソッドはいつも便利だし、
XMLリテラルもCaseクラスによるパターンマッチもTraitベースのMixi-inも、大好き♪」
そして、その瞬間、プログラミング大好き男の目がらんらんと輝いたなら、
貴女はこう重ねましょう、
「それからね、いま、わたしが使ってみたいWebアーキテクチャは、
Play Framework、素敵なリアルタイム嗜好のアーキテクチャって噂を聞いたから。
あなたのお暇なときがあったら、わたしをPlayへ連れてって♪」
これでもう完璧です。
PlayFrameworkと、Play（遊ぶ・じゃれる）のダブルミーニングでかれの股間も刺激しちゃえます。
そうなったらこっちのもの、
デートの日には、ペアプロ用に Happy Hacking Keyboard をばっちり決めて、かわいい下着をつけて（注３）、
github.comの通販で売ってるoctcatのTシャツか、facebookの「いいね！」ボタンがムネのところにあるTシャツ、 あるいは初音ミク（ないし彼のお気に入りのアニメキャラ。北米ならMyLittlePonyで鉄板なんだけど）のコスプレを着てゆきましょう。
その日から、プログラミング大好き男は貴女の虜になるでしょう。
注１：
（と、書いたもののPHPの現状をよく知りません。グローバル変数だらけになるのとか旧ASPみたいなもんなのかなぁ。count($array); とか書くのアホと思うがpythonも同じだった）
（あと、マジで単機能とかTwitter連携とか診断メーカー的なのでもPHPで７つも作ってる女子居たら付き合いたい）
注２：
もっとも。objective-Cなんていう言語をやることに比べれば個人で行う程度なら金のかからない手法もなくはないのですが。
注３：
プログラマーにとっての「かわいい下着」と、女性にとっての「かわいい下着」の定義にずれがあるので注意。
半数くらいのプログラマーはしましまぱんつが可愛いと思ってる気がするので、妙齢の女性が着用するには抵抗あると思うが、ボーダー柄のコットンショーツ（ただしキャラ絵のは除く）とか、
過度でないていどにフリルがついたものがオススメ。また、色は、レッドだとプログラミング大好き男は引いてしまう（だってそれはコンパイルエラーのときの色だ）ので、薄ピンクかホワイト、薄ブルー、せめて黒（に差し色でピンクとか）あたりに留めたい。
補記：
元ネタ： http://tabelog.com/tokyo/A1301/A130101/13002457/dtlrvwlst/3464106/
補記２：
「プログラマー」か「プログラマ」かの問題については、特に意味は無いが前者を採用した。
補記３：
言うまでも無いけど、ネタです。
世の中「プログラミング言語」を説く本はごまんとあれど「プログラミング」を説く本やブログはあまりない。
いや実際に "ない" というのはかなり語弊があるかもしれない。
しかし、通常この種の説明している本に辿り着くまでには多くの時間が必要だ。
普通の人は、多くの間違った方法を試し、その都度試行錯誤を重ね、プログラミング経験を経ることよって、重要な概念を獲得するのだと思う。
例えば、「計算機プログラムの構造と解釈」や「実用 Common Lisp」、「コンピュータプログラミングの概念・技法・モデル」などの書籍は現実の問題に対し "プログラム" をどう書くかという問題に正面から取り組んでいる良書だ。
しかし、どれだけ”普通の”プログラマが上記のような書籍を読んでいるのだろうか。
そして、"普通のプログラマ" がプログラミングを学ぶ書籍として、それらは果たして適切と言えるだろうか。
僕はそうは思わない。
というのも、多くの人は計算機科学を学び、効率のよいアルゴリズムとデータ構造、美しい階層化・モジュール化されたプログラム、などを作るためにプログラミングするのではない。目の前の問題を解決するためにプログラミングを行うからだ。
授業で出された宿題だったり、人それぞれだろう。
このような目の前の問題を解決したい人達が、わざわざ Lisp や Mozart など何の役に立つのか分からない言語を、根気よく勉強するのだろうか。（ちなみに、Lisp や Mozart は上記の書籍で実際に使われている言語である。）
新しいプログラミング言語を学ぶことや、プログラミングの種々の概念を獲得することではない。
もちろんプログラミング言語を上達するためには一つでも多くの概念を会得する必要があるので、あるレベル以上を目指すのであればこれらの書籍を読むことや、抽象化を実現するための様々なツールを手にすることは必須だと思う。
純粋にプログラミングを楽しんでいる人やハッカーを目指したい人はこのような文章を読むのではなく、ぜひ上記に挙げた本を実際に購入し、自分の手で動かして確かめてみることを勧める。プログラミングに対する考え方や姿勢が変わるのは間違いないと思う。
今回はそのような”純粋にプログラミングを楽しんでいる人”に向けた文章でない。
現実の問題をプログラミングを用いて取り組んでいる人に向けて書いた文章だ。
そのような人の中で、なかなかプログラミングが上達しないという人に向けた文章である。
もしプログラミングの学習に限界を感じているのであれば、プログラミングの学習方法が間違っている可能性が高い。
そして残念なことに、初学者向けの書籍では、"プログラミング言語の文法" を説く本はあれど、"プログラミングの学習方法や上達するための正しいスタンス" を説く本はほとんどない。
できるだけ多くの人にプログラムをする楽しみを知ってもらうためにも、
より多くの人がより生産的にプログラムが出来るようになるためにも、
そして特に、右も左も分からなかったプログラミングを始めたばかりの過去の自分に対して、
効果的な学習方法やプログラムする際の指針を書き記したいと思う。
それらは単に指針を示しているだけなので、
どんなプログラミング言語を使っていようとすぐに実践に移せるはずだ。
後はどれだけそれを実践に移し地道にプログラミングしていくだけである。
正しい努力と、ちょっとしたコツさえ知っていれば驚く程生産性を挙げられるはずだと確信している。
プログラマのレベルを以下の 3 つに分けてそれぞれについて説明していきたい。
・使えるプログラミング言語は一つだけ
ただし以下のことは出来ない。
・500行以上のコードが書けない
2. 中級者レベル
・1つ以上のプログラミング言語は使える
・オブジェクト指向は理解している
ただし以下に当てはまる。
・自分が制作しているアプリケーション向けに "実用的なフレームワークやライブラリ" を書けない
・1万行以上のコードだとスパゲッティコードになり、保守不能になる
・適切なサブルーチン化できない
3. 上級者レベル
・プログラミング歴 3 年以上
・現実の問題に対して適切なデータ構造とアルゴリズムを選択できる
・抽象化について理解し、可変部分と不変部分を考慮した設計ができる
またそれぞれのレベルをクリアするには明確な壁がある様に思う。
これらの壁を超えるにはどうすればよいかを説明する。
前置きが長くなったが、以下ではまず初級者レベルの人に向けた具体的なアドバイスをする。
完全に初心者レベルの人はまずどのようにプログラミングを行えばよいのか分からない。一行も書けない。そのため、必然的に以下のような行動を取ると思う。
・本に載っているプログラムをそのまま書き写す（いわゆる写経）
上のような行動を行なっているだけでは、いつまで経っても自分でプログラミングが出来るようにならない。
なぜなら上記のプロセスでは決定的に重要なことが学べないからだ。
それは、【プログラミング言語のモデル】を自分の中に作ることである。
それは普通の言語と同じように文法が存在し、そのしきたりに沿って記述しなければならない。
そのしきたりを学べば書けるようになれる。非常に単純だ。
それなのに、なぜいつまで経っても書けないのか？
それは、”書き写す・コピーする” だけでは、そのしきたりが習得できないからである。
特に最初のうちのプログラミングは頭を作業使う作業でなく、むしろ "体で覚える" 類のものである。
それは例えば、日本語を話すことと似ている。
友達と会話する時、頭を使っているだろうか。
それは簡単な受け答えについては体が覚えているので、考えるより先に日本語が出てくるのではないだろうか。
プログラミングも同様に頭を使うのではなく、こうしたい時はこう書く、という反射神経を育てなければならない。
もちろん日本語話せるだけでは、ミーティングでプレゼン出来ないのと同様に、文法が出来ただけではプログラミングが出来るとは言えない。しかし、文法が出来ないと "現実の問題に対処するソフトウェアを作る" というレベルには到底進めない。そのために、まずそのような文法の反射神経やパイプラインを頭の中に作る必要があるのだ。
・"何をしたい時" に "どう書けば正しく動くか" というデータベース（プログラミング言語のモデル）を自分の中に作ること
このままでは抽象的すぎるので、このような "データベース" や "考える習慣" を自分の中に作るための具体的な指針を以下に挙げる。
1. エラーをたくさん出す
2. デバックの仕方を覚える
3. 小さく動かして確かめる
4. Google を使い倒す
つまり、小さく動かして、エラーをいっぱい出し、デバッグを素早く行なって、分からないことは google などの検索エンジンで解決する。これが上達のコツである。
これらについては以下で詳しく説明するとして、
無理して覚えなくてよい。
プログラマは覚えることが星の数ほどあるので、メソッドなどはリファレンス片手に検索できればよい。
よく使うメソッドなどについては自然に覚えていくので、積極的に覚える必要はなし。それこそ、"体" で覚えるはずである。
覚えられないメソッドについてはそもそもあまり使わないから覚えられないので、重要性は低く覚える必要はない。
むしろ実現したい処理が既にメソッドや関数として提供されていないか、調べる力の方が大事。
・エラーがいっぱい出てつらい
全く問題ない。
・写経をしなければならない
教科書や本の中に書いてあることをそのままエディタで書き写し、実行することを写経という。
上記でも述べたように、これからあまり無駄な努力をしないことを願って言えば、
写経して書いた 10000 行のプログラムより、自分で考えて書いた 100 行のプログラムの方が遥かに意義がある。
そこに "言語のモデル" や "思考" が伴わないと意味がない。
”思考” が伴わないとただの書き写す作業をしているだけだ。
自分の中に "モデル" が出来ていないので、いざ自分でプログラミングしようと試みても、写経をしているだけでは全く書き出せないだろう。
写経はそもそもプログラミングに対するスタンスやプロセスそのものを勘違いさせる危険性をはらんでいるいる。
写経する場合、書き写しの間違いがなければプログラムは問題なく動く。
しかし実際のプログラムではコンパイルや実行するまで、そのプログラムが期待通りに動くかどうか、は絶対に分からない。
そして通常は一気に全てを書き上げるのではなく、まず小さなコア部分を書き、少しずつ他のコア以外の部分を書き上げながらプログラムを完璧なものにしていく。
書き間違えさえなければ正しく動くと知っているプログラムを、上から一行ずつ書いていくプロセスとは正反対だ。
また、以下で述べるようにエラーが発生した場合のデバッグ作業は非常に重要であるだが、そのための作法も写経から学ぶことができない。
なぜならば、写経中にエラーが発生した場合、教科書と自分で書いたプログラムの間違い探しをまず一番最初に行うからだ。これはプログラミングに関する作業ではなく、むしろ間違い探し絵本とにらめっこしているに近い内容である。
それでは、デバッグ方法や言語のモデルを作るとても大切なプロセスを経験できない。
ゆえにそのようにして完成したプログラムもおそらく正しく動きはするが、得られる経験値は驚くほど低いはずである。
とは言え、いきなり自分で書けと言われても書けないと思うので、小さなプログラムを一旦は教科書通り写し、その後自分なりに改変していくのがよいと思う。この場合も写経にはほとんどが意味がないと思った方がよい。"自分なりに改変する" というプロセスこそ意味がある。
今度はどのように "言語のモデル" を自分の中に作っていくかについて説明する。
初心者はエラーを出さない様にと慎重にプログラミングしようとしがちだ。
なぜならば、エラーを出すごとに、その言語の新しいルールを１つずつ学んでいくことになるからだ。
PHP で例えると、
printf の書式だとか
文末に付けるセミコロンだとか
function はネストできないとか
変数には $ を付けなければならないだとか
グローバル変数を関数の中で使う場合は global 宣言するとか
などである。
初心者のうちは一切上のようなルールは知らないはずだからエラーを全て踏むかもしれない。
例え今回作っていたプログラムでエラーを踏まなかったとしても、回数をこなしていけばいくつかエラーに遭遇するだろう。
しかし、それでよいのだ。
エラーを修正することの繰り返しの中で、その言語のモデルが自分の中に出来てくる。
そのようなトライアンドエラーを繰り返えすことで、"言語のモデル" は文字通り体の中に染み込み、プログラムをだんだんと書ける様になっていく。
おそらくこれはは自転車に乗れるようになるプロセスと似たようなものだと思う。
誰しも最初は上手く走れずに転んでばかりいるけれど、何度も何度も転んで起き上がってを繰り返しているうちに少しずつ多くの距離をこげるようになっていくだろう。
そして最終定期には、難なく自転車を乗りこなせるようなっている。
それらのエラーを地道に１つずつ潰して間違いを訂正していくうちに、少しずつ多くの行数の複雑なプログラム書けるようになっていく。
そして最終的には、自由にプログラミング言語を使いこなせるようになっていることに気付くだろう。
自転車も本を読んだだけで乗れるようにはなれないのと同じで
プログラミング言語も本を読んだだけで出来るようになれると思わない方がよい。
それらはトライアンドエラーの繰り返しの中でしか得ることはできないし、誰かから教わる類のスキルでもない。
そして、プログラミングを行うからにはエラーとは一生付き合っていかなければならない。
早めにそれに気付いて受け入れる必要がある。
実際にエラーに遭遇した時に大事なのはエラーに遭遇した時にいかにその原因を突き止めるかだ。
期待しない動作をした時のデバッグという。
まずいちばん基本的で一番重要なデバック方法は printf デバックである。これをまず出来るようにする。
怪しい変数をとにかく printf で出力し、変な値が入っていないかを確かめる方法である。
僕が常々許せないと思っていることは、初学者向けの書籍にはデバッグの重要性やその具体的な方法論が非常に重要であるにも関わらず、それについては解説すらされていないことである。
初心者だからこそ、デバッグの方法論や開発環境をきちんと整えるべきである。
ほとんどの言語処理系では、デバッグ作業を支援する機能を提供している。
分からなければ、"言語 デバッグ方法" でグーグルで検索してみればよい。
例を挙げると、
javascript だったら firebug
各言語にはいわゆる"定石"と言われるデバッグ方法があるはずで、それらを検索し習得すること。
これは無益な時間を過ごさないためにも本当に重要な要素なので、面倒くさがらずに開発環境を整えや方法論をマスターすること。
最初の内は、基本的にプログラミングする時は小さな部品に別けてから1つずつ確かめながら作る習慣を付けるようにする。
その理由は簡単で、人間は正確無比に物事を進めるのは苦手な一方で、プログラミングでは正確無比に物事を進めることを要求されるからである。そのため、大きなプログラムを一度も実行せずに作成し、一気に確かめようとするとまず間違いなく正しく動作しない。
そして厄介なことに、大きなプログラムを作ってしまうとどこに問題があるのか切り分けすることが困難になるので、ますますデバックが難しくなってしまう。
そのためまず小さく作って小さく確かめ、部品を組み合わせてプログラムを作っていくことが大事になる。
一般的に言って、どんなに熟練したプログラマーであろうとも、一つのミスもせずに一定以上の大きさのソフトウェアを作り上げることは不可能である。そのため、ミスやエラーはある程度発生することを前提に、少し作っては実行して確かめる、というサイクルをたくさん回す習慣を付ける。
ソフトウェアは一行書き上げた瞬間から指数関数的に複雑性が増大し、気付いた時にはどうにもならなくなっていることも多い。そういう時は思い切って一から作り直すという選択肢も検討してみるべきだ。
"Small is Beautiful"
これは非常に有名な unix （という OS）の設計理念である。
unix の開発者は様々な失敗経験から、このようなソフトウェア開発のベストプラクティスを学んだに違いない。
まだプログラミング経験の浅い人も、これから偉大な開発者の経験から学ぶことができるはずである。"Small is Beautiful"。小さく作って動かすこと。
先ほどから何度も書いてあるように、プログラミングする上ではエラーとの付き合い方が非常に重要になってくる。
おそらく何らかの上手くいかない場合は何らかのエラーメッセージが出るはずだ。
原因がどうしても分からない場合は、エラーの文章をそのままコピーして検索してみる。そうすると、おそらくエラーの原因と対策方法などが表示されるので、それを足がかりに再度挑戦する。
現実のプログラミングは、どんなにスキルが伸びようとも、いつも上手くいかないことばかりだ。それこそ、何をしてもエラーが出てくるし、何をしても上手く動作しない。だから僕は初心者のうちで一番大事な能力とは、実は "忍耐力" だろうと少しばかり思っている。
でも悩んでるのはあなただけではなく、おそらく全てのプログラマーが通ってきて道だ。
そして、自分の思い通りに動くプログラムを見た時程うれしいものはない。
ぜひ初心者の人はこれを読んで少しでもプログラミングが出来るようになればと思っている。
つ
■ C
for( const char *s="12345"; *s; ++s ) if( '2'<*s&&*s<'5' ) printf( "%d", (*s-'0')*2 );
console.log([1,2,3,4,5].filter(function (i){ return (i > 2 && i < 5 ); }).map(function(i){ return 2 * i; }));
■ Python
print(map(lambda x: x*2, filter(lambda x: x>2 and x<5, [1,2,3,4,5])))
■ Ruby
puts [1,2,3,4,5].select{|i| i > 2 and i < 5}.map{|i| i*2}
■ C#
new{}{ 1,2,3,4,5 }.Where(x => 2 < x && x < 5).Select(x => x*2);
(print (loop for x in '(1 2 3 4 5) if (< 2 x 5) collect (* x 2)))
■ Haskell
print [x*2| x <-[1,2,3,4,5], x > 2, x < 5]
■ J
■ R
print((function(){x<-c(1,2,3,4,5);x[2<x&x<5]*2})())</p>
■ Clojure
(print (for [x [1,2,3,4,5] :when (< 2 x 5)] (* x 2)))
(1 to: 5) select: [:x | x between: 3 and: 4] thenCollect: [:x | x * 2]
支えてくれる家族または友人がいない場合、社会的な制度が整っていない以上、今の環境を逃げようが結果的には死にたいであるから、さっさと今の辛い環境を受けいれろ
が理解できないからその帰結の理由を教えてほしいといっただけなのですが...論点がずれているようですね？
プログラマーとしてはどうなんだろう。
ぜひ上を
プログラマーとしては彼の著書を二冊ANSI Common Lisp、On Lisp、後半は2回読み直すと考え方が変わると思います
またLispでWebサービスを作る意義は当時はあったのだと思いますが、今ではメタ言語でプログラムを生成することが一般的になって
きておりマクロの有用性、Slimeの素晴しさ、最適化ヒントのための機構が言語に内包されている点以上に特別な認識はしておりません
ただリーダマクロを利用すると構文自体を拡張することが出来るためLispを書く人はすべからく言語設計者としての腕が試されるのだと思います
(といっても私は本物のLispプログラマーではなく初〜中級者の域程度のものと認識しているため上級者以上の方はまた違う見解なのだと思います)
正直なところ、一時期自分もLuaに感動して、Luaで(mod_lua？)Webアプリを書こうとしたときもあったけど、RailsやCake、Nodeのexpressみたいなのでさえ、多くのユーザーが書いている方法の方が同じ悩みにぶつかり、googleすれば誰かがstackoverflowで解決しているので、コピペで取り敢えず乗り切る可能性が高くなる。
が、mod_luaに関してはガチレスしますと、Apache のpre post filter, mod_rewriteの煩雑さ軽減、Access,Auth,UserCheckのpre post、CustomLog置き換えくらいに試作品として個人だったら利用すると思います(プロダクションレベルならば実際利用する前に検証すると思います) mod_luaでもいいですが文章は何が目的かをはっきりさせて書いてください
後半のRails、Cake、Nodeでも同じで、「形にすることが目的」であれば、コピペ出来るものを御自分でえらべばいいのじゃないのでしょうか？なにが主張したいのかよくわかりません
# ゲームなどのアプリケーション内で使う言語はシンプルが一番だ。それはBASICやTclのように、美的には醜いものでも正解になることが多々ある。
# lispを選ぶのは正解だと思う。
TclをVHDLのシミュレーションツールとして数年利用しましたが、美的に醜いものではありません そしてなによりもゲームと一括りにしておりますが近年のゲームプロダクションを「舐めないでください」？？？Lispを触りもしないのに正解だと思うなども？？？
そんなことを最近のApple製品やGoogle製品の苛立ちとともに感じ、自分の人生の終焉や世界の終わりに思いを馳せながら今日もコードを書くか、身辺整理をするか、絶望感を眠ることでかわす毎日を送るだろう。
現実ではなく煽り文章だと理解しているつもりなのですが、中身がよくわからず何を伝えたい文章で帰結はなんなのかが大変よくわかりませんでした
酷い会社に就職するとブール演算さえまともに理解していない人たちが、銀行や年金のコードを書いている日本の恐ろしさに驚かされる。
金に困って、私もときどきバイトを探すのだが、バイトで地方銀行のプログラミングとか書いてあるのが普通の日本はちょっとおかしい。
多分、証券会社とかの方がまともなコードを書いているのだと思うが、精神的にはキツい気がして門を叩いたことはない。
もう、年齢的にも限界なんでね。
テクノロジーや数字に対して無知な文章と思えるようなことを主張しているようにしか理解できないことがひっかかります。他人は他人ですし変えることは出来ません。ですが自分の考え方はいくらでも受けとめかたは変えられるのではないでしょうか？
別にPerlでなくても、シェルスクリプト、Cでも構わないけど、所詮CGIだし、正規表現とか文字列に明るいから、打算的な面もあったんだろうと思う。
考えてみれば、あの頃は負荷についてあまり考えてなかったよな。
根本的なコンピュータの仕組みの理解が食い違っている認識なのですが、当時負荷を考えたときスケールアップをしていた理由は、「1台」のマシンと「2台以上」のマシンを管理する方法がまったく別のスキル(コスト)を要求するからです 現在ではフェールオーバだけでなく、冗長化の考え方が広くオープンソースの世界でプロダクションレベルに適用されたためであって、当時から負荷自体については考えている所では考えていました
また所詮CGIという意味では標準入出力さえあればどの言語でも出来るのは事実かと思いますが一方Lispだから打算というのは異なるのではというのは上の文章を読んでいただければ
エッセイのどのことを示唆しているかは不明ですが「成功している理由」を考察していることはあっても(時系列でいう後ろから前への考察)、「こうすれば成功する」という考察(時系列でいう前から後ろへの考察)について伝えてる文章は知りません よろしければその文献情報はどこにあるのでしょうか？
あの頃に成功しなかった人(つまり、私)はもう浮かばれることはないだろうし、今、彼らが言うようにやったとしても、あまり夢がないというか、生きてくのもどうだろうという気がしてならない。
誰も失敗した人の発言には耳を傾けないからね。
人生というのは、確かに一定の年齢を過ぎると選択の幅が狭まるというのは事実ですが「なくなる」というのは嘘です そしてそもそもその歩いてきた道だけは変えることは出来なく、これからの道は落とし穴かもしれませんが90度直角に歩くことさえ出来るものだと思います
また失敗した人の発言に耳を傾けないわけではないと思いますよ？むしろ否定的な感情を表に出しすぎるために難しくなってるのではないでしょうか？
この考察はその通りだと思いますが合理的ではないでしょうか？前回もお伝えしたように株式会社なのであれば株辺りの利益を最大限にすることが目的です また会社というのは民主主義ではなく株主主義です それさえ理解すれば組織の維持=経営者が優先されるのは当然なのではないでしょうか？従いまして「人間的に正しい」の意味を理解していませんが、あなたのいうその「人間的に正しい」と「組織の目的」との間で落とし所をつけ提案することが本来の従業員の仕事に含まれると理解しています。
支えてくれる家族または友人がいない場合、社会的な制度が整っていない以上、今の環境を逃げようが結果的には死にたいであるから、さっさと今の辛い環境を受けいれろ
長々と書きましたが、上の内容を簡潔に聞きたいだけでして、ブール演算やらLuaなどの話は聞いていません ブール演算などは高校生に3時間でも教えれば理解する人はいるでしょう
基礎体力を養う意味ではここら辺がいいと思うんですがどうでしょう。
これがわかるとCLRやJVMのインフラ部分もわかりますし、組み込み方面にも強くなります。
C++はマルチパラダイム言語であり、これをひとつやれば構造化プログラミングとオブジェクト指向プログラミングの両方がわかります。
C++はCのほぼ上位互換言語ですので（正しくはC99が制定されるまでは）、プレーンなCしかやらない理由はありません。
嫌なとこも多くある言語で（どうしてEffective C++シリーズやExceptional C++シリーズみたいな書籍が多くでてるか考えるといいよ）、メモリ管理も手動ですが（これは半分嘘。RAIIがあるから半分自動。GCがないから半分手動）、逆に細かいとこに気を配る態度を養うには最適です。
Erlangで並列プログラミングをやるのもいいかもしれません。
Common LispかSchemeで怪しい（でも美しい）世界を爆走するのもいいかもしれません。
これだけやっとけばC#やJava、軽量言語の類はあっさりと料理できるでしょう。
あくまでもプログラミング言語についてはですからね。
元増田の苦悩は、日本語では、断片的なTipやリファレンスはあっても、
市販されている書籍のような情報がインターネットでは手に入らないということに原因があると思う。
英語だと、市販されている本がまるまるネットで公開されていることがある。
例えば、
SICP http://mitpress.mit.edu/sicp/
Real World Haskell http://book.realworldhaskell.org/read/
Practical Common Lisp http://gigamonkeys.com/book/
How to design programs http://www.htdp.org/
Thinking in C++ 2nd Edition http://www.mindview.net/Books/TICPP/ThinkingInCPP2e.html
Thinking in Java, 3rd Edition http://www.mindview.net/Books/TIJ/
GNU Autoconf, Automake, and Libtool http://sources.redhat.com/autobook/
Managing Projects with GNU Make, Third Edition http://oreilly.com/catalog/make3/book/index.csp
Dive Into Python http://www.diveintopython.org/
Programming Ruby The Pragmatic Programmer's Guide 1st edition http://ruby-doc.org/docs/ProgrammingRuby/
On Lisp http://www.paulgraham.com/onlisp.html
The Art of Unix Programming http://www.faqs.org/docs/artu/
BRUCE PERENS’OPEN SOURCE SERIES http://www.informit.com/promotions/promotion.aspx?promo=135563
O'Reilly Open Books Project http://oreilly.com/openbook/
Creating Applications with Mozilla http://books.mozdev.org/
http://anond.hatelabo.jp/20090404235214です。
ご協力ありがとうございます。
普通の：
・Compiler Construction (Louden)
・Effective C# (Wagner)
・Compilers (Aho, et al.)
・Virtual Machines (Smith, Nair)
・Garbage Collection (Jones, Lins)
・車窓で旅する日本列島
・Common Lisp 第2版 (Steele Jr.)
・Assembly Language for Intel-Based Computers (Irvine)
・Concrete Mathematics (Knuth, et al.)
・Programming Language Pragmatics (Scott)
・Basic Category Theory for Computer Scientists (Pierce)
ダメげなの：
・サモンナイトコレクション
・しろ画集
・カーネリアンコレクション
・Bittersweet Fools ビジュアルファンブック
・ISO/IEC 13211 Information technology - Programming languages - Prolog - (Prologの規格書)
・県別マップル十数冊
整理されてなさすぎるのがよくわかった。
その他本棚にあるもの：
・危ない28号 3冊
・夏少女の紙袋
via Twitterオタが非オタの彼女にTwitter世界を軽く紹介するための10ユーザ
まあ、どのくらいの数のプログラミング言語オタがそういう彼女をゲットできるかは別にして、
「オタではまったくないんだが、しかし自分のオタ趣味を肯定的に黙認してくれて、
その上で全く知らないプログラミング言語の世界とはなんなのか、ちょっとだけ好奇心持ってる」
ような、ヲタの都合のいい妄想の中に出てきそうな彼女に、プログラミング言語のことを紹介するために
習得させるべき10言語を選んでみたいのだけれど。
（要は「脱オタクファッションガイド」の正反対版だな。彼女にプログラミングを布教するのではなく
相互のコミュニケーションの入口として）
あくまで「入口」なので、アーキテクチャに過度に依存するアセンブラ等の低級言語は避けたい。
あと、いくら基礎といってもBrainf*ckやUnlambdaのような難しすぎるものは避けたい。
ポール・グラハムが『Arc』は外せないと言っても、それはちょっとさすがになあ、と思う。
そういう感じ。
彼女の設定は
ロジカル度が高く、頭はけっこう良い
まあ、いきなりここかよとも思うけれど、「Java以前」を濃縮しきっていて、「Java以後」を決定づけたという点では
ただ、ここでオタトーク全開にしてしまうと、彼女との関係が崩れるかも。
この情報過多な言語について、どれだけさらりと、嫌味にならず濃すぎず、それでいて必要最小限の情報を彼女に
伝えられるかということは、オタ側の「真のコミュニケーション能力」の試験としてはいいタスクだろうと思う。
アレって典型的な「オタクが考える一般人に受け入れられそうなプログラミング言語（そうオタクが思い込んでいるだけ。実際は全然受け入れられない）」そのものという意見には半分賛成・半分反対なのだけれど、それを彼女にぶつけて確かめてみるには一番よさそうな素材なんじゃないのかな。
「プログラミング言語オタとしてはこの二つは“教育用言語”としていいと思うんだけど、率直に言ってどう？」って。
ある種の言語オタが持ってるラムダ計算への憧憬と、ACM監修の関数型言語的純粋さへのこだわりを
彼女に紹介するという意味ではいいなと思うのと、それに加えていかにも参照透過な
の二要素をはじめとして、オタ好きのする要素を言語にちりばめているのが、紹介してみたい理由。
たぶんこれを見た彼女は「Emacsだよね」と言ってくれるかもしれないが、そこが狙いといえば狙い。
この系譜の作品がその後続いていないこと、これがポール・グラハムの間では大人気になったこと、
ポールグラハムがウェブサービスの構築に使って、それがいろんなウェブサービス開発者にも影響しててもおかしくはなさそうなのに、
実際のウェブサービスでこういうのが使われないこと、なんかを非オタ彼女と話してみたいかな、という妄想的願望。
「やっぱりプログラミングはバッチ処理のためのものだよね」という話になったときに、そこで選ぶのは「awk」
でもいいのだけれど、そこでこっちを選んだのは、この言語にかけるラリーとdankogaiの思いが好きだから。
断腸の思いで延ばしに延ばしてそれでも2008年、っていうPerl 6のリリース予定日が、どうしても俺の心をつかんでしまうのは、
そのリリースというイベントへの諦めきれなさがいかにもオタ的だなあと思えてしまうから。
Perlのリリース延期を無駄だとは思わないし、拙速なリリースは無茶だろうとは思うけれど、一方でこれが
GuidoやMatzだったらきっちり予定通りリリースしてしまうだろうとも思う。
なのに、各所に頭下げて迷惑かけてリリースを延期してしまう、というあたり、どうしても
「自分の言語を形作ってきた哲学(TMTOWTDI)が捨てられないオタク」としては、たとえラリーがそういうキャラでなかったとしても、
親近感を禁じ得ない。言語自体の高評価と合わせて、そんなことを彼女に話してみたい。
今の若年層でPostscriptを直で書いたことのある人はそんなにいないと思うのだけれど、だから紹介してみたい。
PDFよりも前の段階で、DTPの哲学とか印刷技法とかはこの作品で頂点に達していたとも言えて、
こういうクオリティのプログラミング言語がエディタで書かれてたんだよ、というのは、
別に俺自身がなんらそこに貢献してなくとも、なんとなくプログラミング言語好きとしては不思議に誇らしいし、
いわゆるJava VMでしかスタック型言語を知らない彼女には見せてあげたいなと思う。
PHPの「HTMLに埋め込み可能な点」あるいは「RDBMSとの接続性」をオタとして教えたい、というお節介焼きから教える、ということではなくて。
「HTMLのテンプレートエンジンを作り続ける」的な感覚が言語オタには共通してあるのかなということを感じていて、
だからこそアメリカ版『Yahoo!』の開発言語はPHP以外ではあり得なかったとも思う。
「MとVとCを分離なんてできない」というオタの感覚が今日さらに強まっているとするなら、その「オタクの気分」の
源はPHPにあったんじゃないか、という、そんな理屈はかけらも口にせずに、
単純に楽しんでもらえるかどうかを見てみたい。
これは地雷だよなあ。地雷が火を噴くか否か、そこのスリルを味わってみたいなあ。
こういう述語論理風味の計算をこういうかたちで言語化して、それが非オタに受け入れられるか
気持ち悪さを誘発するか、というのを見てみたい。
9本まではあっさり決まったんだけど10本目は空白でもいいかな、などと思いつつ、便宜的にC++を選んだ。
Javaから始まってC++で終わるのもそれなりに収まりはいいだろうし、テンプレート以降のメタプログラミング時代
の先駆けとなった言語でもあるし、紹介する価値はあるのだろうけど、もっと他にいい言語がありそうな気もする。
というわけで、俺のこういう意図にそって、もっといい10本目はこんなのどうよ、というのがあったら
教えてください。
「駄目だこの増田は。俺がちゃんとしたリストを作ってやる」というのは大歓迎。
こういう試みそのものに関する意見も聞けたら嬉しい。
「ブロック付きメソッド呼び出し」がわからん、ということでいいのかな。この概念は是非とも解ってほしいので、今日始めて Ruby を触った俺が頑張って解説しよう、と思ったけれど、いいドキュメントを見つけたのでリンクしておくよ。
これで解らんかったらOn Lispを途中まで読みんさい(お金がないならWeb 版をどうぞ)。「ブロック付きメソッド呼び出し」は元々関数型言語の界隈で「レキシカルクロージャ」と呼ばれるもので、要するに中身は一緒なのでクロージャが解れば「ブロック付きなんたら」も解る(Ruby を触ったことのない自分が「ブロック付きなんたら」を理解しているのはこれの為)。 On Lisp は Common Lisp という言語の本なんだけど、 Ruby は言語仕様の多くの点で Common Lisp を参考にしているので、勉強するのはそれほど難しくないと思う(つまり見た目はヘンテコだけど中身は Ruby ってこと)。
