  |
はてなキーワード: クロージャとは
まぁ、関数型として専門的に作られているような奴は、大体デフォでカリー化ついてるけど、そいつらも要は裏ではクロージャ的なものを使ってる。
で、それこそJavascriptとかLispみたいな「関数型として、本当に最低限必要なものだけ揃えている」系列の奴等は、プログラマ側がクロージャ駆使して書いてあげる必要がある。
まぁ、関数型ばりばりの奴等ほど、色々至れり尽くせりの構文になっててベースを見せないので、あんまり意識してクロージャ使ってる、って感じにはならないけど、ベースにある所よくよく見ると、クロージャが出てくるって感じか。
その「関数の部分適用」を実現するために（専用の機能を持っていない限りは）クロージャが必要なんだよ!!
（部分適用するために、まずカリー化 ⇒ そのカリー化にそもそもクロージャが必要）
http://kenokabe-techwriting.blogspot.jp/2015/04/amazon102-93.html
これのやつなぁ……。
確かに自分も最初に関数型勉強しだしたときに、混乱したポイントではあったんだよ。
なんでかというと、クロージャでぐぐると、まっさきにjavascriptのクロージャの説明が出てきて、その中で実用例として「呼び出すたびに出てくる数値がインクリメントされる」的な例が真っ先に出てくるから。
「えっ、クロージャって、これやるための機能なの？ 副作用バリバリじゃね？」って思っちゃうんだよね。
これはかなりのけっ躓きやすいポイントになってしまっていると思う。
実際はJavascriptの例でよく出てくる使われ方は、かなり特殊例なんだけど、これが代表、みたいな扱いに見えるんだよね、今の検索結果だと……。
http://b.hatena.ne.jp/entry/kenokabe-techwriting.blogspot.com/2015/04/blog-post_30.html
http://kenokabe-techwriting.blogspot.jp/2015/04/amazon102-93.html
この記事自体はどうでも良いのだけど、以前「クロージャ」という言葉の初期の使用例を探したことがあったのを思い出したので、参考までに。
Landin "A λ-Calculus Approach" (1966)
We represent the value of a λ-expression by a bundle of information called a "clusure", comprising the λ-expression and the environment relative towhich it was evaluated.
我々は、ラムダ式の値を「クロージャ」と呼ばれる情報の束で表す。「クロージャ」はラムダ式とそのラムダ式の評価に関する環境から成る。
Moses "The Function of FUNCTION in LISP,or Why the FUNARG Problem Should be Called the Environment Problem" (1970)
A useful metaphor for the difference between FUNCTION and QUOTE in LISP is to think of QUOTE as a porpous or an open covering of the function since free variables escape to the current environment. FUNCTION acts as a closed or nonporous covering(hence the term "closure" used by Landin).
LISPでのFUNCTIONとQUOTEの違いについては、次のように考えるのが有用な比喩になる。QUOTEは多孔的または開放的に関数をおおっていて、自由変数は現在の環境へと脱出できる。FUNCTIONは閉鎖的(closed)または非多孔的に関数をおおっている(このことからLandinはクロージャ(閉包)という用語を使っている)。
(訳はhttp://kreisel.fam.cx/webmaster/clog/img/www.ice.nuie.nagoya-u.ac.jp/~h003149b/lang/p/funarg/funarg.html から)
Sussman and Steele "SCHEME: An Interpreter for Extended Lambda Calculus" (1975)
In order to solve this problem we introduce the notion of a closure which is a data structure containing a lambda expression, and an environment to be used when that lambda expression is applied to arguments.
この問題を解決するためにクロージャという概念を導入する。クロージャはラムダ式とそのラムダ式が引数に適用されるときに使われる環境から成るデータ構造である。
Steele and Sussman "The Art of the Interpreter" (1978)
We say that the procedure is closed in the current environment, and the ＆PROCEDURE-object is therefore called a closure of the procedure, or a closed procedure.
この手続きは現在の環境に閉じられている(closed)と言い、それゆえ＆PROCEDUREオブジェクトはその手続きの「クロージャ」あるいは「閉手続き」と呼ばれる。
これ読んでも関数型分からないけど、入り口の前あたりに立つために
プログラマとしての引き出しが増える。
って書くと「そんなもんどんなプログラミングテクニックだって一緒だわ」って言われそうだけど、でもそうとしか言い様がない。
とりあえず、オブジェクト指向と同じで、プログラムを構造化して、複数のレイヤーに切り分けて部品化していくテクニックだとは言える。
ただオブジェクト指向とは大分切り口が違う。何ていうか、割と直交する切り口でプログラムの構造を切り分けていく。
なので、関数型とオブジェクト指向と両方憶えるだけで、大分切り口の引き出しが増える。
オブジェクト指向と関数型両方憶えると、プログラマとしての引き出し増やすのに効率が良い、って思えば良いかも。
オブジェクト指向は、プログラムの各部品を「あれの中のこれの中のそれの中にあるあれ」みたいな感じで組み合わせる。
部品が更に細かい別の各部品で構成されていて、それぞれの部品が噛み合わさって、複雑な一つのプログラムを構成するような切り方。
関数型言語は、プログラムの部品を「あれをした物にこれをした物にそれをした物にあれをする」みたいな感じで組み合わせる。
もっというとプログラム全体を簡単に記述するできるDSLがあって、そのDSLを簡単に実装するためのDSLがあって、DSLの入れ子構造で一番小さい部品はシンプルな関数、みたいな切り方。
ケースバイケース。
ではあるんだけれど、シンプルな部品を大量に組み合わせて構成するのがしっくりくるならオブジェクトで、部品数が少ないんだけど一個一個が複雑な動作する構成にしっくりくるのが関数型……かも？
関数型言語たる条件として「関数が第一級オブジェクト」ってのがあるんだけど、関数が第一級オブジェクトだとイミュータブルなデータを素直に扱える。
で、イミュータブルなデータ構造使うと色々便利、ってことで実例として一番出てくるという。
関数型言語のエポックメイキング的な言語が三つくらいあって、元祖のLispとその流れ汲んだMLとMLの一種で関数型をある種の到達点に持っていったHaskellって感じ(独断と偏見)。
で、このうちのMLって奴が、プログラミング言語に型システムがついてるんじゃなくて、型システムにプログラミング言語がついてきた存在だったりする。
型で色々やるために生まれたわけで、まぁなんというかそもそも型と密接な関係にあって、Haskellもその流れを汲んでて、こいつが超有名になった、って感じ。
おかげさまで、型使って色々やったりする方法が日々考えられているわけです、静的型付関数型の世界では。
関数型言語ではよく「関数と関数を引き取って、合成した関数を返す関数」みたいなのが使われるんだけど、関数と関数の合成って、それ合成された関数がもともと引数として与えられていた関数憶えてないと無理やん？ 自分自身の構成部品憶えてられないわけだから。
クロージャあると憶えててくれるわけですよ。
そんな感じで高階関数を実用的なレベルで使うのには大体必須と言う。
関数型言語はDSLを作りまくる言語みたいに書いたけど、モナドはちょっと複雑なDSLを簡単に作らせてくれる仕組みだと思っとけば良い。
まず純粋の定義だけど「全ての関数は同じ引数を与えられた際、必ず同じ値を返す」ってことで、これがいわゆる副作用がないって状態だ。
で、これって逆に言えば「プログラム内である関数に対して、絶対に同じ引数を与えさえしなければ、その関数がどんな値を返したところで、事実上純粋だと言えてしまう」ってことでもある。
本末転倒感があるんだけど、HaskellではIOモナドという仕組みと特別なmain関数を使って「呼び出すたびに絶対に違う引数を自動的に関数に与えてくれる仕組み」を実現していて、こいつを使って入出力する。
うん……凄い本末転倒。ちなみにこの自動的に与えられる引数はRealWorldって名前がついていて、要は「刻一刻と変わり続け絶対に同じ状況にならない現実世界の状態を引数に取っちまっているようなもんだからしょうがないだろ？」的な感じ。
なんだか話題になってるから書く。
やっと初心者を脱して中級者になりかけてるプログラミング学習者が関数型言語に何を感じているかを書こうと思う。
Haskellが短いコードでプログラムを書けるというのは分かる。
それでやりたい処理のほぼ全てがまかなえるということも実感している。
副作用のない小さな関数を合成して大きな関数を作る利点も分かる。
再利用性も上がるし、どこからどう影響を受けているかが簡単に分かるからバグも出にくい。
ただ、Haskellの基礎になってる圏論が何の役に立つのかは、まったく分からない。
むしろ邪魔なんじゃないかと思う。
ファンクターやモナドの概念が圏論で扱われているのは分かるけど、圏論なんて名前だけ知ってればコードを書くのに不都合はないだろう。
圏論が必要なのは、Haskellを設計する人であって、使う人ではないと思う。
なのに、やれクライスリ圏だ自己関手の圏だのと、うるさいったらありゃしない。
Linux上で開発環境整えるのにカーネルのコードを読めって言うぐらい的外れだと思う。
いや、知識として持っとくのはいいだろうけど、役に立たんだろ。
Rubyが羊の皮をかぶったLispとはよく言われることだけど、関数型言語もオブジェクト指向言語とそこまで違いがあるような気がしない。
純粋な言語ではできないけど、クロージャに内部状態を保持してもらって無名オブジェクトみたいな使い方をすることはあると思う。
その無名オブジェクトにもっとあれこれデータや関数詰め込めば、いつの間にか普通にJavaやC#で使うようなクラスのできあがり。
その間はなめらかにつながっていて、不連続に切れるようなもんじゃない。
関数プログラミングと言いつつ、オブジェクト指向の考え方は利用できる。
上級者はデザインパターンをdisるのが好きかもしれないけど、逆の考え方をするべきだと思う。
デザインパターンはオブジェクト指向言語の欠点を補うための苦肉の策じゃないよ。
関数プログラミングの基礎的なパーツだと思う。
だからちょっと見た目がすっきりするだけで、結局やることはオブジェクトプログラミングと変わりはないと思う。
関数プログラミングコミュニティの人って、業務でクソコードメンテさせられて、その現実逃避に美しいコードに擦り寄っているように見える。
もちろん、美しいコードを書けるなら書いた方がいいし、現代的な言語を使えるなら使ったほうがいいと思う。
けど、適材適所というか、オブジェクト指向言語でも、やってやれないことはないわけで。
役に立たない圏論をありがたがる所とか、どうもイキがってるように見える。
せいぜい生産性が倍になる程度で、他の要素が悪ければ帳消しになるような利点でしかないに違いないのに。
あ、まず前提として、
はたして貴女を幸福にするかどうか、それはまた別問題だけれど。
ＩＴ系の超かしこい男なども多く、
多くっつーか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/
補記２：
「プログラマー」か「プログラマ」かの問題については、特に意味は無いが前者を採用した。
補記３：
言うまでも無いけど、ネタです。
こういうのを望んでいるなら、不可能。
var i = 10; [1,2,3, ... ,99,100].each(function(i) { // 何かの処理 }); console.log(i); // 10と出て欲しい
jashkenasはこう主張している
if they do clash, shadowing the variable is the wrong answer. It completely prevents you from making use of the original value for the remainder of the current scope. Shadowing doesn't fit well in languages with closures-by-default ... if you've closed over that variable, then you should always be able to refer to it.
衝突が起こるとしても、変数の隠蔽(shadowing)は間違った解決法だ。スコープ内のその他のすべての変数に関して、オリジナルの値の利用を完全に塞いでしまう。隠蔽は、クロージャが標準(closures-by-default)な言語にはうまくマッチしない。その変数を閉じ込めているならば、常に参照出来るべきだ。
ソース：http://www.sixapart.jp/techtalk/2012/01/coffeescript.html
このお話はたぶんフィクションです。実在の個人や企業とはあんまり関係ありません。そういうことにしろください。
10年前、20代になったばかりの頃の僕は、今思えば本当に最低な生活を送っていた。高校を中退し、実家とは疎遠で、友達もなく、金もなく、夢も希望もなく、ただバイト先と自宅を行き来するだけの毎日。いつも視界には霞がかかったようで、底の見えない空虚さだけが僕の心を支配していた。
それでも趣味らしいものはあった。オンボロマシンにRedHatを入れ、ダイヤルアップの細い回線で自宅サーバを立て、Perlでガラクタのようなプログラムを動かす。そんな子供じみた遊びだけど、プログラムを組んでいるときだけは空虚さを忘れ、画面の中に没頭できた。
ただ、そのときの僕はもうすでにいろんなものに打ちのめされていて、若者にありがちな全能感などというものは霧散していた。自分がプログラミングで何かを成すだとか、それを仕事にしようなんてことは一切頭になかった。このまま夢も希望もなく人生を終えるのだと、そう思っていた。
それでも転機は訪れる。
勤めていた工場で派遣切りにあった僕は、「働きたくないでござる！ 絶対に働きたくないでござる！」とか言いながらニート生活をしていた。そろそろ翌月の家賃も払えなくなってきたころ、派遣会社から電話がかかってきた。「プログラム開発の仕事があるんですがやりませんか？」と。そういや履歴書だかスキルシートだかに、Perlがどうたらとか書いたっけ。実務経験もない中卒に仕事まわすとかｗｗｗ ……とは思ったものの、このままでは本気でホームレス一直線だったので引き受けた。
派遣された先は従業員数10人くらい、パートさん含めても50人くらいの小さな会社だった。現在手書きの伝票でやっている処理をWeb化したいのだという。システム担当者はおらず、事務員さんがExcelやAccessを使える程度。すべて僕一人でやらなければならない。マジか。
ともあれ、まずはサーバである。後々の運用を考えるとLinux系は使えない。事務所の片隅に放置されていたWindows 2000マシンにApacheを入れてそれでよしとした。
次はデータベース。でもこの頃の僕は「正規化ってなんれすか？」というレベルだったので基礎から勉強した。なんかMySQLってのがいいらしい→社長に申請→「今Access使ってるからそれでいけ」→「はい」→パフォーマンスの面で問題出るだろうなとは思ったがしょうがない。
次は言語。最初はPerlで書こうと思ってたけど、PHPってのが流行ってるらしいのでこっちにした。ウホッ！ いい言語……。
そして業務内容を把握するため、現場をあっちこっち駆けずり回りながらヒアリングする。ときには部長から愚痴を聞かされ、ときにはパートのおばちゃんから誘惑され、そんなこんなを繰り返し、仕様をつめていく。
そして数ヶ月かけて開発したシステムの稼働である。そのときのことは今でも忘れない。
現場の人がラインからデータを入力する。サーバにデータが送られてくる。別の事業所からも送信されてきてる。問題ない。事務員さんが伝票処理を行う。問題ない。すげえ、ちゃんと動いてる。お遊びで作ったプログラムではなく、本当に本気の業務用プログラムである。それを僕が1人で作ったのだ。このプログラムで業務がまわり、利益を生み出すのだ。社会に対して、何らかの作用を及ぼすのだ。僕みたいなクズにでも、そんなことが可能だったのだ。
そのことに気付いたときの感動を、僕は今でも忘れない。
それからちょっといろいろあって、ホームレスになった。うん、急展開なのはわかってる。でもこの間のことは語ってもあまり面白くないし、公序良俗に反する話もあるのでざっくりはしょる。どうせフィションなんだから細かいことを気にしてはいけない。
話を戻そう。
ホームレスになってからの数日はひどい精神状態だった。足元から世界が崩れていく感覚。視界がぐにゃりと歪む。帰りたい。でも帰る家がない。だからホームレスというのか……というトートロジーを何度繰り返しただろうか。
もうあまり覚えていないけど、このときの僕は本当にもう何もかもどうでもよくなってたと思う。ただ、自分の全財産がバッグ1つしかないということに対する心地よさ、開放感があったのはよく覚えてる。そんな状況で地べたに座り込んで見る風景。きっと、今はもう見えない。あの頃の僕にしか見えない風景が、そこにはあった。
いろんな人と出会い、流れ流れて、最終的に西成のあいりん地区にたどり着いた。関西圏の人には説明不要かもしれないけど、よく言えば日雇い労働者の街、ぶっちゃけて言えばホームレスのメッカである。今はもう綺麗になってしまったし、治安もそこそこよくなったけど、僕がいた頃はまさに「カオス」としか表現のしようがない状況だった。
どこから持ってきたんだといいたくなるようなガラクタばかりを並べた泥棒市。簡素な骨組みにビニールシートをかぶせただけの飲み屋。「ないかーないかー」と声が聞こえてきたので見てみると、警察署の近くなのに道端で堂々と丁半博打をやっている。コンビニのトイレの張り紙には「トイレが詰まる原因になるので注射器を捨てないでください」とある。いやトイレが詰まるとかの前に気にすることがあるだろ。ケンカなんて日常茶飯事。頭から血を流したおっさんが普通に歩いてる。数百人規模で並ぶ三角公園の炊き出しは圧巻。四角公園の炊き出しでは誰もいない場所にワンカップの瓶とかがたくさん並んでる。何かと思って聞いてみたら「あれで並んどることになってん」と返ってくる。学食の席取りルールみたいだ。ああもう全然書ききれない。
でも一番印象に残っているのは、南海線の高架下、うず高く積まれたゴミ山の前でガラクタを解体していたおっちゃんのこと。奇声を発しながらハンマーを振り下ろしていたおっちゃん。その両目は、これ以上ないほどにキラキラと輝いていた。その鉄屑を売った金でビールが何本買えるか皮算用でもしているのか、あるいは幸せになる魔法の薬でもキメているのか、そのときの僕にはわからなかったけど。
そして、人生を投げ出していた僕に付き合ってくれたおっちゃん、あなたのことも忘れません。モーニングをおごってくれて、いろんな話をしてくれて、聞いてくれて、役所の福祉課まで連れて行ってくれたおっちゃん。あなたがいなければ、僕は今でも西成でぬるま湯の日々を送っていたかもしれない。
いろんな人に助けられて、ホームレスの施設に入ることになった。舞洲という人工島にあるのだけど、これがまた周囲に何もないのだ。スポーツ関連施設、ゴミ処理場、物流センターが点在するくらい。コンビニ1件ありゃしない。だけど施設での生活は意外にも楽しかった。2段ベッドが6つ並んだ12人部屋。むさくるしいけど、みんなバラエティに富んでいた。刑務所上がりのいかついおっちゃん、虚言癖のひどいおっちゃん、ほとんど一日中寝てるじいちゃん、薬のフラッシュバックがひどい兄ちゃん。そんな人達の中で過ごせば、自分がどれほどクズであっても気にならない。やはり僕はこちら側の人間だと再認識した。
市街地にある施設へ移ってからはいろんな仕事をした。生駒の山奥にドブさらいに行ったり、事務所移転のバイトで腰をやってしまいそうになったり、なんやかんやあったけど、長くなるのではしょろう。結局のところ、またプログラマをすることになるのである。
そろそろ身バレしそうな領域に入ってきたのでここでもう一度強調する。このお話はたぶんフィクションです！ たぶんフィクションです！ 大事なことなので2回言いました。
そう、またプログラマとして働くことになった。今度は従業員数300人くらいの大きな会社である。日本人なら誰でも知ってるであろう大企業の子会社ということもあり、本社からの出向社員は東大京大卒当たり前みたいな状況。そんな人達の前で中卒の僕が前に座ってプレゼンやら仕様検討会やらをするのだ。何の罰ゲームだよ……。
最初に思ったのは、「ここにいる人達は育ちがいい」ということだった。みんな礼儀正しい。喋り方や立ち居振る舞いまで、今まで僕がいた世界とは何もかもが違っていた。まるでドラマに出てくるような「ちゃんとした人生を送っている人達」だ。そんな人達に囲まれていると、「生きていてごめんなさい」と言いたくなる。本当に。
他に驚いたこと。社内で連絡を取り合うのにメール使ってる。やばい。社内メーリングリストとかもある。やばい。定期的にミーティングとか勉強会とかもする。なにそれ怖い。自分がいっぱしの社会人になったかのような錯覚に陥る。ちょっと前まで西成でゴミ拾いのバイトしてたのに。「勘違いするんじゃない！ 西成の日々を思い出せ！」と何度も自分に言い聞かせ、自我を保った。
とはいえ、萎縮してばかりもいられない。気付いたことはどんどん提案した。あちこちに散らばっている共通の処理をライブラリ化したり、サーバで負荷がかかっている部分を改善したり。却下されたものも多かったけど、採用されたものもそれなりにあった。業務の改善案を考えるのは楽しい。誰かがプログラマの三大美徳に「無精」を上げていたっけ。極度のめんどくさがりで、楽をするための苦労は惜しまない僕には、こういう仕事は天職なのかもしれない。
システム開発の方も順調に進んでいた。この頃はMicrosoftですらWeb版のOfficeを出すような状況で、デスクトップアプリに比べても遜色ないレベルのWebアプリがどんどん出てきていた。この会社で開発しているのも、そんなAjax技術を多用したWebアプリだ。JavaScriptを用いた本格的な開発に最初はとまどったけど、書けば書くほど言語が自分の手に馴染んだ。クロージャ、prototypeといった基礎をちゃんと学ぶと、書けるコードのレベルが段違いに上がっていくのが楽しかった。
仕様にもこだわった。実際に使う人がどんなふうに操作するのか、何度も何度も脳内でシミュレートし、どんなUIが最適なのか、データ構造はどうするべきか考え、実行速度とメンテナンス性の板挟みに苦しみ、何度も何度もリファクタリングを繰り返す。
そのとき開発していたシステムは、メイン画面でほとんどの処理を行うタイプのものだったのだけど、そのメイン画面のJavaScriptコードは最終的に1万行を超えた。もうこの頃にはJavaScriptでのオブジェクト指向的な開発手法というものも自分なりに構築されつつあった。そしてこのカチャカチャとした手触りの、安物のオモチャのような言語は、僕の一番好きな言語になったのだった。
そんなある日、僕が作ったシステムのメインユーザーである他部署の偉い人が来て、開口一番こう言った。
この機能が素晴らしい、とか、あの発想はなかったわ、とか、とにかくべた褒めして、そして去っていった。機能追加要望の前口上だと思って身構えていた僕は拍子抜けした。「あの人が他人を褒めることなんてめったにないよ、すごいね」と近くの席の人が言う。
どこにもはまることのない歪な歯車。その僕が、社会という大きな機械の中に組み込まれる音だったのだと思う。まあすぐに外れてしまうのだけど。その一瞬だけは、僕は確かに社会の一部になれたのだ。
これからどうするか？ 今の技術力ならそれなりのところに就職できるかもしれない。でも僕にはやってみたいことがあった。半年かけて海外を旅するのだ。
今、僕の手元にはまとまったお金がある。こんなのは人生で初めてのことだ。そして僕は今、どこにも所属していない。どんなところに行ったっていいし、何をしたっていい。この先、そんな状況がどれだけあるだろうか？ 人生長いのだ、そりゃあ何度だってあるかもしれない。でも今回やりたいことをやらなかったのなら、僕はきっと何度だってやらずにいるままだろう。
もちろん怖くなかったわけじゃない。なにせ海外なんて行ったことがなかったのだ。ずっと極貧の生活をしてきた僕は、国内旅行だって満足にしたことがない。
いろいろと考えた。ない頭を使って考えた。自分の英語は通じる？ 病気になったときは？ 荷物をなくしたら？ あれこれ考えると心配事ばかりが頭をめぐって、わけがわからなくなる。
最終的に決定打になったのは、自分が何も持っていないという、この状況だった。
そう、僕は何も持っていない。家族も友達も、夢も希望も。だけど、そんな人間だからこそできることがあるんじゃないかと思ったのだ。何も持たないからこそ、どこにだって行けるし、何にだってなれる。それはタロットカードの「愚者」みたいなものだ。愚かな者は恐れも何も知らぬからこそ、無限の可能性を秘めている。
心を決めたら後は早かった。
パスポートを取得した。航空券を手配した。住民票を海外転出した。トランクルームを借りた。住んでいた部屋を引き払った。
空港へ向かう電車の中で、懐かしい感覚に襲われた。あの日、ホームレスになったばかりのころの感覚。世界が足元から崩れていく感覚。でもあのときとは決定的に違うことがあった。それは、今回は自分が望んでこうなったのだということ。流されるまま生きてきた僕が、初めて自分の人生に対して主導権を得た。それだけが決定的に違っていた。それだけで十分だった。足の震えは、これからの旅路への、期待に対する震えなのだった。
自分とは異なる人種、異なる言語。街の看板すらまともに読めない。レストランの注文すらおぼつかない。ちょっと電車に乗るのも大仕事だ。それでも時間をかけてひとつひとつなんとかしていった。
見知らぬ街の匂い、喧騒、バケツをひっくり返したようなスコール、旅の中で出会う怪しい人、優しい人。僕の前でたくさんの風景が流れていく。
川辺のレストランで昼ご飯を食べた後ボケーッとしていると、猫が膝の上に乗ってくる。動くのもめんどくさくてボケーッとしてたら日が暮れてた。そのまま猫と一緒に晩ご飯を食べた。そんな日もあった。
長距離列車に乗っていたとき、車内食にピーナッツバターのようなものが付いていたので、普通にパンに塗って食べた。でも梅干的なものだったらしく、めちゃくちゃ酸っぱかった。「すっぱ！ すっぱ！」とかやってたら向かいの席の女の子が爆笑していた。僕も笑った。そんな日もあった。
最初は少し移動するのにも大変な思いをした。でもいつの間にか、ローカルバスに乗って気ままに旅するようになっていた。
たどたどしかった英語も、日常会話程度なら普通に喋れるようになっていた。
いろんな国のバックパッカーにもたくさん出会った。お互いつたない英語でやりとりするのも楽しかった。今度は彼らの国にも行ってみよう。だからいつか世界一周に出ようと、僕は心に決めた。
こんな旅に出たところで自分は何一つ変わらないと思ってた。でも、何かが変わってきている。それが何なのかはわからない。たとえば図太さだったり、適当さだったり、そういうのもあるのだけど、何か違う。それよりもっとプリミティブなもの。感情になる前の感情、行動になる前の行動。マグマのような熱量を持ったドロドロとしたものが、自分の中に渦巻いているのを感じる。それがいつ形を成すのかはわからない、今はまだ。だけどいつかどこかで、忘れた頃にひょっこり出てくるんじゃないかと思う。そのときを楽しみにしていよう。
そして夢のような日々は終わる。
日本に帰ってきたとき、手持ちの金は10万以下だった。部屋は解約していたので住むところもなかった。普通にホームレスだった。僕は焦らず慌てず、西成へ向かった。
しばらくはドヤ(安宿)に泊まった。一番安いところなら500円から泊まれる。西成はいいところだ。
前の会社から戻ってこないかと誘われたけど、「働きたくないでござる！ 絶対に働きたくないでござる！」と言って断った。
いや働きたくなかったのは本当だけど、もう1つ理由があった。職業訓練で組み込み系を学ぼうと思っていたのだ。
スマートフォン含むタブレット端末の市場がこれからも拡大していくのは間違いない。そうすると必要になってくるのは組み込み系の知識。いやアプリ作るだけなら必要ないかもしれないが、そういった知識があれば、自分ができることの幅がぐんと広がると思う。
それに、今の僕には基礎的な力が圧倒的に足りない。すべてを独学で、我流でやってきたけど、やはり限界を感じる場面が多々あった。だから今回ちゃんと体系的に学んで、足元を固めようと思ったのだ。
結果的には正解だったと思う。本当に基礎の基礎から学べた。
ブレッドボードを用いて回路を組むところから始まって、アセンブラ、C言語、組み込みLinuxでのデバイスドライバ開発、アプリ開発。これまで高級言語の十分に進化しきった部分にしか触れてこなかった僕にとっては、どれも難しかったけど、どれも面白かった。これからどういう道に進むかまだわからないけど、ここで学んだことは絶対に無駄にならないと思う。
そうして職訓で勉強するかたわら、悶々と考えていたことがある。世界一周についてだ。
今はまだ金もないし、そんな金を稼げるあてもないのだけど、いつか(たぶん10年後くらいには)行こうと本気で思っている。
ルートだけでも今から考えておこうと思って、いろいろと旅程検討アプリを試してみたのだけど、どれもいまいち使い勝手が悪い。海外のものも含めて探しまくったけど、自分が思うようなものは見つからなかった。
だったらもう自分で作るしかない。せっかくだから就活のときにポートフォリオとして使えるよう、ちゃんとしたWebアプリを作ることにした。
最初の1ヶ月は地図APIの選定と、検証コードを書き捨てるだけで終わった。
2ヶ月目は基礎部分の構築だけで終わった。
3ヶ月目に本気を出し、ほぼできあがった。
そしてベータ版をリリースした。 http://planetter.com/
それが先週の話。
だからこのお話はここで終わりだ。正確に言うなら、ここから先の展開はまだわからない。
10年間を振り返ってみて思う。あの頃と比べて、何か変わっただろうか？
家族や親類とは縁が切れたままだし、いまだに人付き合いは苦手だし、金はないし、夢も希望もない。それは今でも変わらない。ただ、あの頃あれほど感じていた空虚さは、跡形もなく消えている。
西成の高架下で見た光景を思い出す。ガラクタを解体していたおっちゃん。あのキラキラした目。たぶんあの瞬間に僕は、自分にとって一番大切なものは何なのか、心の深い部分で理解したんだと思う。
世界一周だなんだというのも本当はどうでもいい。僕はただ、いつだってドキドキしていたいのだ。
初めて人を好きになったときの気持ち。知らない街で暮らし始めたときの気持ち。そして、プログラムが思い通りに動いたときの気持ち。
それを持ち続けていたいのだ。いつだって新しい世界にワクワクしていたいのだ。
ふと目を閉じれば、まぶたの裏に映る、あの日のメッセージ。
"Hello world!"
このお話はたぶんフィクションです。実在の個人や企業とはあんまり関係ありません。でも、ここに綴った僕の想いは、ノンフィクションです。
Pythonの方が弄れる対象が多いのに、なんでウェブ系だとPHPの方が流行ってんだろ
端末からのテキスト処理も楽だし、数値計算周りのライブラリも充実しているのに
PHPが優遇されているのって歴史的な経緯以外に何か他の理由でもあるのか？
けどまぁ、情弱な文系SEが大半を占めているバカだらけの日本じゃ別にPHPで困ることもないか
数値計算や端末からのテキスト処理なんてWeb系じゃ大して使わないからなあ…
Pythonに関しては、ZopeさえコケていなければWebサーバ用LLとして大成功していたはずなのに、
Railsなんかが登場したおかげで、すっかり影が薄くなってしまいますた....
ってか、railsにインスパイアされたフレームワークって今じゃ幾らでもあるよね
djangoとかCakePHPとか。rubyってRoRを使いたいユーザを除くと、
pythonやPHPの方がユーザー数は圧倒的に多いと思うんだけど
本家のrailsって、他を遥かに越えるほど良いものなんだっけ？
44
Zopeが登場した当時、「RDB+PHPはもう古い、これからはOODB+ZopeがWebの中軸になる！」と
少なくとも自分はZopeからPythonという言語を知ったし、その時点でRubyは知らなかった
そして、その後のORM(RDB)+Railsの出現と華々しい革新性への注目は、誰もが知っているだろう
今でもZopeの開発は継続されてはいるが、結果的に当初の期待が大きく裏切られたという事実は動かしがたい
djangoとCakePHPについては実際に触っていないので憶測になるが、おそらく技術水準ではRailsと同等だろう
しかしRailsはRailsでコミュニティの活動が活発だし、その進化は異常に早い
Railsに何か致命的なトラブルが発生して開発が停滞する、あるいはdjangoやCakePHPから
何かのイノベーションが提示されでもされない限り、後発のdjangoやCakePHPがRailsに追いつくのは無理
Railsは決して技術的に完璧なWebフレームワークではないんだけどね....（たとえばSeaSideのような.... ）
だからこそ「もしもZopeが....だったなら」という「たら・れば」感はPythonコミュニティの潜在認識になっている
C a k e P H P は う ん こ
CakePHP使ってんの？
可哀そうにw
でもやっぱりいつもの使い慣れたLL(Python/Ruby)で
Webサービスを書きたいってのがある
求人数は
Ruby on Rails＞＞＞＞＞＞＞＞Django
http://www.indeed.com/jobtrends?q=django%2Cruby+on+rails&l=
どういうことなの？
求人数が多いのはそのためだと思うよ
なんかのミスかと思ったがアメリカでもRuby on Railsは人気があるのかなあ・・・
Pythonのほうが使いやすいと思うのだがフレームワークはRailsが優位なんだろうか
Djangoは周辺ライブラリが微妙だし本体も鈍くさい感じがする。
でも、FlaskはSinatraより好きだから、Pythonが嫌いってわけではない。むしろ好き。
ただ、いざ作り始めるとやっぱりRailsが楽だなあってなって、Railsを使い続けている。
同感だ
同じように思っている人が他にもいて安心した
PHPはフレームワークが乱立しすぎているから、RailsをPHPで実装してみようというやつが出てきた。
それに比べてPythonは、Zopeというデファクトスタンダードが既に存在していたけど、
ただ、どうやってもRailsもどきがRailsを超えることはできないのは間違いない。
パクリはオリジナルを超えられない(ｷﾘｯ って定型句だけど、
これってｷﾘｯって言いたいだけだと思う。
D言語って超えたって？
B言語って超えたって？
PHPで同じ事をできないわけではないだろうけど、Ruby on Railsほど簡潔にはできない
まあくだらねえWEBサービス作って喜んでる情弱は早く死ねって事だよ
そういう理由じゃなくてRailsのほうが単純に情報もプラグインも多いからでしょ
linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
わざわざ不合理で不完全な言語を使うなんて
もしも
＞linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
真実であるのなら、今頃はdjangoの情報とプラグインが溢れかえっているはず
yumや、gdbとgnomeの拡張がpythonであるからといって、それをwebアプリでも使いたいと思う人は少ないというだけのこと。
ソースからインストールする必要があったとしても、web開発ではrubyを使いたいという人が多いというだけのこと。
というか、世界中のPythonプログラマが Remeber Zope!! を合い言葉に
打倒RailsたるWebフレームワークを開発しているはずだけど、
Railsも登場してから、かなりの年月が経過しているんだけどなぁ....
その間にもRailsはRails 3が登場して、REST/AJAXの強化等の進化が継続しているよ
Ruby では
ary.map {|x| x**2}
map(lambda x: x**2, ary)
となり、lambda の本体が1つの式では表現しきれなくなると
.....
と書き換える必要があります。
f = lambda x:(x and f(x-1)*x)or 1
RubyにはPythonのように「lambda本体は式でなければならない」という限定がありませんから、
f = lambda{|x|if x == 0 then 1 else x*f.call(x-1) end}
または
f = lambda{|x|x == 0 ? 1 : x*f.call(x-1)}
と書けます。lambda内でreturnが使えますから、書きたければ
f = lambda{|x|if x == 0 then return 1 else return x*f.call(x-1) end}
でもOKです。
348
これはPythonをdisっているように見せかけてRubyをdisっているのか？ と一瞬思ってしまったｗ
だってRubyのほうが長くない？CLのfuncallみたいなcall()がちょっとうざいし…
そしてどっちもlambda式の中で束縛変数の名前で再帰可能、と
print [x*2+100 for x in [1,2,3,4,5] if x > 2 and x < 5]
暗号のように見える。
puts [1,2,3,4,5].select{|i| i > 2 and i < 5}.map{|i| i*2+100}
思考の流れと、コードの流れが一致しているので書きやすい。
map(lambda x: x*2+100, filter(lambda x: x > 2 and x < 5, [1,2,3,4,5]))
pythonて可読性が高いのをうたってる割にはそこいまいちだよね
Rubyの場合には、左から右へと無名関数がデータフローあるいは
関数型プログラミングに不慣れな初心者でも、参照透明性のあるコードが自然に書ける
プログラマにとって優しい or プログラミングの楽しさを教えてくれるのがRuby
それと比較すると、Pythonのコードは、関数型プログラミングというものが
いかに高度で難解なものであるかという事をもったいぶってプログラマに押し付ける
もしもPythonしか知らないプログラマであれば、関数型 = 難解 という印象を持つだろう
階乗計算くらいだと単純すぎて、ナゼ重要なのかが分かりづらいと思うのでコードで示す
result_list = source_list.map { |elem|
x = foo(elem.x) # ここが局所宣言を書く部分
x + y # 最後に評価された式の値が、無名関数のリターン値になる
}
Rubyでは、map等に与える無名関数の中で局所的な環境(クロージャ)が作られるから、
x = foo(...) のような代入文がいくつでも(= 複雑な処理でも)書ける
このポイントは、実用的なプログラムを関数型風で書こうとした時に、威力を発揮する
余計分かりづらくなった
高卒ドカタなんだろうなぁと可哀想になる
集合の表記に似せてることが分かるから
355
＞map/filterはfor/ifと同じだと言っているだけだから、難解という印象は持たない。
関数型プログラミングに慣れた、あるいは得意な人であれば、そういった印象なんだろね
Rubyの魅力はこれから関数型プログラミングを学ぼうとする初心者、 あるいはそんな初心者へ教える立場から見た、優しさ or 分かりやすさなんだ
[1,4,3,2].sort.reverse.map{|x| x.to_s}.join('-')
Pythonだと読みにくい。
'-'.join(map(str, reversed(sorted([1,4,3,2]))))
Pythonでは思考の流れと一致しないばかりか、「カッコだらけ」のコードになると.....
カッコだらけのコードを分かりやすくする基本的な方法は静的単一代入じゃないか
Rubyのやり方は基本ではなく玄人のやり方だろ
Pythonでは組み込みの型でメソッドチェインはやって欲しくないな
似たようなコレクションtuple,deque,array,queue等にも同じメソッドが必要になってくるし。
372
外部のライブラリでも列挙可能なものは、たいていEnumerableモジュールをimportしてますね
Rubyユーザーは列挙可能なものはmapやselectできて当然だろって思ってる気がします
Pythonは「何かを便利に書くためのしわ寄せ」をはっきり寄せてくる
得意と不得意を言語レベルではっきり主張するのでメリケン好みと言えなくもない
Rubyは全方位になんとなく八方美人なので、全体的になんとなく書きやすくてなんとなくキモくて遅い
「書きにくいってことはその処理に向いてないってことだから諦めろ」を地で行く
無名関数が文を使うほど複雑なら名前を付けるのが Python 流と想像。
これを読みづらいと感じるのは、左から右に流れる
もしかしてアラビア語ネイティブな人からすると逆に読みやすいのか？
http://anond.hatelabo.jp/20110316202255 - ドラゴンボールで学ぶオブジェクト指向
また、ポイポイカプセルのように技を塊にして色んな人が使えるように出来ます。
var shotKamehameha = new function(){ //かめはめ波を打ちます。 } noumin.kougeki = sendKamehameha; buruma.kougeki = sendKamehameha; noumin.kougeki(); //カメハメ波がでます。
って書いてるけど、クロージャってのはそういうものじゃないよなぁ、と。 まあファーストクラスの関数オブジェクトっていうところはあってるけど、それだけでクロージャと言えるのかというとちょっと違う。
"a closure is a first-class function with free variables that are bound in the lexical environment." (Closure - Wikipedia) とあるように、関数内の変数がレキシカルスコープに結び付けられているようなものがクロージャなのである。 JavaScript で例を書くなら、次のようになる。
// クロージャを返す関数 var getClosure = function getClosure() { // クロージャからアクセスされる変数 var counter = 0; // クロージャ var closure = function closure() { return counter++; }; return closure; }; // クロージャを取得 var closure = getClosure(); // クロージャを実行 closure(); //=> 0 closure(); //=> 1 closure(); //=> 2
http://anond.hatelabo.jp/20110316202255
亀仙流やつ鶴仙流など、世の中にはいくつかの流派があり、それぞれ カメハメ波やドドン波、舞空術などの技（メソッド）がある。 実際に技を使う場合、技を覚えているZ戦士（インスタンス）が必要。
クラス = 流派
メソッド = 技
インスタンス = Z 戦士
というのはおもしろいと思うし, 例えばゲームを作るなら実際にそういう実装になると思う.
例）セルを作りましょう。 class Cell extends Goku,Veget,Picoro,Tenshinhan,Kuririn{ .... } cell_inst = new Cell(); cell_inst.shotKienzan(); //Kuririnをextendsしているので気円斬が使えます。
しかし, ここではクラス = Z 戦士になってしまっているので, 混乱を招くだろう.
むしろ, 「JavaScript における prototype」 に絞って説明するのはどうだろう.
(ついでに「撃つ」の現在形は shot でなく shoot ですね)
var Goku = function () {};
Goku.prototype.shootKamehameha = function () {
console.log("波!!!");
};
var goku = new Goku;
goku.shootKamehameha(); // 波!!!
var Gohan = function () {};
Gohan.prototype = new Goku;
var gohan = new Gohan;
gohan.shootKamehameha(); // 波!!!
そしてセルによる吸収は, 動的な継承として考えるのがより自然だろう.
var Goku = function () {};
Goku.prototype.shootKamehameha = function () {
console.log("波!!!");
};
var Vegeta = function () {};
Vegeta.prototype.shootBigBangAttack = function () {
console.log("ビッグバンアタック!!!");
};
var Cell = function () {};
// 吸収メソッド
Cell.prototype.absorb = function (target) {
for (var method in target) {
this[method] = target[method];
}
};
var goku = new Goku;
var vegeta = new Vegeta;
var cell = new Cell;
cell.absorb(goku); // 悟空を吸収
cell.absorb(vegeta); // ベジータを吸収
cell.shootKamehameha(); // 波!!!
cell.shootBigBangAttack(); // ビッッグバンアタック!!!
そして次にクロージャの使用例として挙げられた次の例.
例）連続エネルギー波 var shotRenzokuEnergy = function( count ){ var shotEnergy = function(){ //エネルギー波を放ちます }; for(var i=0;i<count;i++){ shotEnergy(); } };
この実装では, shotRenzokuEnergy を実行するたびに shotEnergy が毎回定義されてしまい, 非効率である.
以下のように書き換えることで, shootEnergy の定義は, shootRenzokuEnergy の定義時の 1 回のみとなる.
var shootRenzokuEnergy = (function () {
var shootEnergy = function () {
console.log("エネルギー波!!!");
};
return function (count) {
for (var i = 0; i < count; i++) {
shootEnergy();
}
};
})();
shootRenzokuEnergy(10); // エネルギー波!!! x 10
亀仙流やつ鶴仙流など、世の中にはいくつかの流派（＝クラス）があり、それぞれの流派にかめはめ波やどどん波、舞空術などの技（メソッド）がいくつかあります。
実際に流派にある技を使う場合、技を覚えているZ戦士（インスタンス）が必要になります。
例）亀仙流を覚えた孫悟空を使ってかめはめ波を放って敵を倒す goku = new KamesenRyu("goku"); goku.shootKamehameha(teki);
Z戦士によっては複数の流派の技が使えたり、自分の技を人に教えることが出来ます（継承）。
また悟空とクリリンのように同じ流派でも同じ技で違う性能を持っていたり、オリジナルの技を持っているなどの違いがあります。
クラスはセルを作るためのZ戦士達の遺伝子情報と言っても良いかもしれません。
例）セルを作りましょう。 class Cell extends Goku,Veget,Picoro,Tenshinhan,Kuririn{ .... } cell_inst = new Cell(); cell_inst.shootKienzan(); //Kuririnをextendsしているので気円斬が使えます。
世界（プログラミング言語）によってはただの人を後付でZ戦士にすることが可能です。
(JavaScriptやRubyなど）
noumin = new Hito();
noumin.kougekiKuwa = function(){
//戦闘力たったの5…ゴミめ！
};
noumin.shootKamehameha = function(){
//な、なんだと！？
};
農民がいきなりかめはめ波をうつようになったら危険ですね、危ないです。
このように後付でメソッドを追加出来るタイプは危険性を含んでいます。
とても良いつっこみが来たので追記します。
前半部分ではZ戦士をインスタンスとしましたが、セルを作るにはZ戦士がインスタンスでは出来ないので
何をインスタンスにして、何をクラスにするかが「設計」なんですね。
セルの第一段階ではGokuなどのZ戦士の遺伝子があれば作ることが出来ました。
cell_inst = new Cell(); //このセルは第一段階
cell_inst.absorb(17gou); //第二段階に変身 cell_inst.call18gou(); cell_inst.absorb(18gou); //最終段階に変身 class Cell ....{ function call18gou(){ if(!this.17gou)return error(); //17号を吸収していないと失敗する this.17gou.speak("＊＊＊＊略＊＊＊＊＊ドクターゲロ様＊＊＊＊略＊＊＊＊"); } }
17gouを吸収したので、17号の声で18号を呼ぶことが出来るようになりました。
でもドクターゲロ「様」って言ったのでセルだってバレバレですね。
http://anond.hatelabo.jp/20110316224648
クロージャについてちゃんと書こうと思って挫折。どなたか良いアイディアを下さい。
変数のスコープを解説する必要があるかなと思ったんですがオブジェクト指向からは外れるような気がします。
エネルギー波→連続エネルギー波がどこかに使えそうな気がしましたが、気のせいだったぜ…
なんか話が合いそうだなと思ったので返信。増田なのがちょっと勿体ない気もするけど。
ちなみに俺のバックグラウンドを書いておくと、学生時代の専攻は工学系なんだけど、それにしてはオーバースペックなぐらい数学をかじってた感じの方面。あんまり詳しく書くと特定されそうなんでこの程度で勘弁ね。
"Pattern Recognition and Machine Learning"のビショップも物理出身だけど、あの年代は確かにそういう色が強かったのかもしれない。
確かにその種の傾向は上の世代までかもしれないね。
ビショップが物理出身なのは知らなかったけど、それ聞いてなんか合点のいく気がした。何か妙に数学へのマニアックなこだわりの片鱗が見える割に、数学屋から見ると妙な記号法を使うんだよね、あの人。
全然高度じゃないです＞＜
いや、だからあくまで「工学として」ね。線型代数と、微積の「計算」以外を使うことって工学ではそうないでしょ（フーリエ変換とかだって工学の文脈では所詮「計算」だもんね。）。
制御理論とか機械学習では、関数解析の概念がちょっとだけ出てくるけど、あんなんでも数学屋にとってはオアシスだね。
もっとも、カーネル法関係ではいつも申し訳程度にMercerの定理が言及されているのを見ると「なんだかなあ」っていつも思うけど。
そうそう、あれに限らず統計学の理論の一部にはものすごく違和感あるんだよね。
増田だから書けるけど、情報幾何なんて「お前、双対接続って言いたいだけちゃうんかと」って感じだし、他にも色々、何でも抽象化して一般化すりゃいいってもんじゃないんだぞと言いたくなることが色々。
統計学の理論と機械学習・パターン認識の関係は、数理物理・理論物理と実験物理の関係に似てる気がするんだよね。しかも統計学の場合、普遍的に綺麗な構造なんてものがあると思えないだけに余計に始末が悪い。「ひも理論は実験で検証できないから科学ではない」って批判があるらしいけど、統計学にも同じ批判されても仕方ない理論が色々あるよね。データから何かを推定する理論なのに、データがどれだけあっても実用的には絶対まともな結果が出せないモデルとか。
CVのレイトレーシングで経路積分使って云々というのもあったけど（その人はGoogleに言ってアドセンスかなんか作ってるらしい）、あれもまぁ適当なパス空間で平均とるだけって感じがするし…。
CVはまあ何でもありの世界だよね。誰か無限次元リー群とか使ってみてくれないかなと思う。というか俺自身が一度やろうとして無意味なことに気づいてやめたんだけどさ。
イジングモデルとかその辺は不勉強なんであまりよく知らないんだけど、一般的にその手のモデルは、性能が変わらないだけならいいけど、計算量がどうとかデータ量がどうとかで事実上使えなかったりすることが多いんだよね。着想として物理からアイディアを持ってくるのはいいんだけど、物理から持ってきたアイディアなら必ず筋がいいはずみたいな思いこみ（そう思いたくなる気持ちはよくわかるけど）はどうかと思う。
普通に日本の伝統的新卒採用でそういう会社に行く人はいるけど、やってることは工学とかあるいは良くわからない専攻の人と同じな気がする。これはちょっと曖昧だけど。
うん、そうなってしまうのは仕方ないでしょうね。
ただ逆に、変わり種のバックグラウンド持ってる人は道具箱が豊富だから、新しいこと思いつく可能性もあるわけで、採用されるとしたらむしろそれを買われてじゃないかな。俺自身、工学部の人は普通は絶対知らない数学を色々知ってるので、それをどうにか武器にできないかいろいろ試行錯誤中だよ。というか特許とかの形で発表したのもすでにあるけどね。
特に情報系の分野は実装力で評価されることが多いし…。実装力は数値計算得意とかそういうのとは全く別のスキルだよね。プログラミングマニア的な要素が必要。
分野にもよるけどね。情報システムや計算機自体を専門にして、ハードとかインターフェイスに近い部分をやってたらどうしてもそうなるけど、信号とか画像とか音声とか言語とかの処理のコア部分を作るときにはコーディング能力よりも紙と鉛筆の能力の方が大事・・・、だと思いたい。
どうもパソコンマニア的気質は中高生のときに飽きてしまって、「PCパーツの種類とか流行の言語とか覚えたってどうせ10年したらすぐに廃れるんだから」という感じで、余りはてな民的に新しいネタ追いかけたくないんだよね。クロージャって何ですか、ああそうですね閉包ですね、集合の内部と境界の和集合ですねっていう感性の持ち主なので。正直、コーディングは単純作業と認識してます。
自分の仕事を「ＩＴ土方」なんていってる奴に出くわした。はっきり言えば、ただの甘え。と言うか、愚図。
こういう連中のせいで、エンジニア全般の価値が下がっているわけで、さっさと営業でもなんでもやってりゃいい。
出来るといわれる人々は、下記を否定しないはずだ。
エンジニアの仕事ほど、未来があって、毎日が新しいくて面白い仕事はない。
これから先、人の生活に益々コンピューターが入ってくる、ハードウェアや技術の進歩もまだまだ止まらない。
そろそろ頭打ちになって来たって言われてるＣＰＵだって、まだしばらくはムーアの法則に従う見込みだ。
シリコンフォトニクスとか夢見たいな技術も実現すべく日々研究されている。
そうしてハードが進歩すれば、開発技術もあたらしくなる。当然そこに新しい仕事がうまれていく。
仮に量子コンピューターが実現すれば、言語そのものに変革が起こる。
それを学べるってだけで涎が出るだろ？でなきゃおかしいんだよ。
毎日同じ様にだ。今持ってる知識で解ける範囲のみで仕事をしてれば、それは昨日とは何も差が付かないし面白い訳がない。
日本のエンジニアが馬鹿というかクソだと思うのは、平気で人が作ったものを何も考えずに使って仕事をすること。
そして使えることを技術だとのたまう事。そんなんで技術が付くかカス。
Hadoop使ってないで、key-value位は自作しようとしやがれ。
結果使うことになっても、作ろうとした過程で手にした経験ほど面白いものはないはずだろ。違うのか？
そしてもうひとつ。日本のエンジニアの大多数は数学がまるで分からないってこと。
いいか。エンジニアは文系の仕事じゃない。コーダーとエンジニアをプログラマって括りでまとめるな。
エンジニアリングを本気でやるなら、他の工学と同じようにコンピューターサイエンスを理解し使いこなせるだけの
数学の素養が必要だ。線形代数とか微分積分、解析学、エンジニアなら離散フーリエ解析くらいはわかっていて当然だろ？
だから思う。
ＩＴ土方とか言ってる奴は甘えてないで、仕事の中に面白さを探して作ればいい。
プロジェクトが火を吹いてるなら、アジャイル・ディベロップメントでも試せばいい。
何か面白そうな論文を見つけたなら、読んでおいていつか実装しようと虎視眈々と狙ってればいい。
アルゴリズマーの知識が羨ましければTopCoderにでも行けばいい。
ソフトウェアの世界にはコミュニティが幾つも開かれていて、学ぼうとする人や毎日を変えようとする人の
全てを受け入れてくれる。そりゃあ残業が多くて時間がないのかもしれない、それなら残業しないで余暇を
勉強に当てられる環境に転職したり、仕事の１０％を勉強に当てる事を認めさせたり、したらいい。
ソフトウエアの世界には、面白いものがいくつでも転がっていて、そして誰も拒絶されない。金も殆どの場合
かからない。だれでも、第一線の技術を作れるし、学べるし、楽しめる。
今は楽しんでいるし、この仕事を死ぬまで楽しんでも居たい。
今ＩＴ業界がつまらないと思ってる人は、もう一度言語を学び始めた頃の気持ちを思い出してみて欲しい。
あの頃は毎日が面白くて、試してみたいこと、知りたいことが山の様にあったはずだ。
その気持ちを何年でも変わらず保ち続けることが大事だよ。
ＩＴ土方なんて、ただの甘えだ。
毎日が楽しくなるなら、営業でもなんでもやればいい、ただし営業だって学ばないやつは使えないと思うよ。
ただ逃げたいだけの奴には、逃げ場なんかどこにもない。
◆日本でしか生きていけないと将来破滅するリスクがあるので、世界中どこでも生きていける戦略のご紹介
日本依存症は、国家依存症の一種であり、会社依存症とよく似ています。
会社依存症とは、ある特定の会社でしか通用しないスキルばかり蓄積して、他の会社では通用しない人材になってしまう病気です。
会社依存症にかかると、その会社の経営が悪化して、どんどん待遇が悪くなり、給料を下げられ、「このままここにいても、少しもいいことがないまま年を取っていくだけ」という状況になっても、ひたすらその会社にしがみつくしかなくなります。
また、会社の都合で延々とつまらない仕事をさせられたり、いまいち納得のいかない降格や減給をされても、なかなか拒否しにくくなります。
上司や同僚と相性が合わず、人間関係がこじれてギスギスした雰囲気になり、毎日会社へ行くのが憂鬱になっても、そこに居続けるしかありません。
なぜなら、その会社を辞めると、ほかに行くところがなくなり、路頭に迷ってしまうからです。
このため、このことがよく分かっているエンジニアなどは、その会社の独自製品や独自環境でしか通用しないスキルしかたまらないような仕事をできるだけ避けるようにします。
そして、「広く普及しており、かつ中長期的に需要があり、供給が不足ぎみで、かつ陳腐化しにくいスキル」を戦略的に蓄積します。
たとえば、以下のようなものが考えられます。
・要求分析、要求仕様定義、システムアーキテクチャ設計、RDBスキーマ設計、サーバの負荷分散設計、各種サーバのパフォーマンス解析・チューニング、デザインパターン、マルチスレッドプログラミング、システム管理、ネットワーク管理
・マネージメント、プロデューサ・デザイナ・経営者・営業・顧客との交渉スキルや連係プレースキル
・普遍性の高いコンピュータサイエンスの基礎
・Unix、RDB、正規表現、Java、Perl、TCP/IP、.NET、C#
日本にはたくさんの会社があり、それぞれが浮き沈みを繰り返しています。
いまいる会社が今後もずっと浮いたままだという保証はありません。
一つの会社に依存しきると、その会社が沈むとき自分まで一緒に沈んでしまい、酷い目に会います。
いまいる会社が沈みそうになったら早めに別の会社へ移れるように準備しておくべきではないでしょうか。
国家に対しても同じことが言えます。
政府は全ての国民を幸せにするような政策を実行するべきですが、必ずそれに成功するとは限りません。
ときに間違った政策を行い、多くの犠牲者を出すこともあります。しかも、その犠牲者を救済するための政策が実行されないこともあります。
もっと最悪なことに、間違った政策で、国全体が沈んでしまうようなことすらあります。
もちろん、そうならないように、われわれは選挙で正しい政策を実行してくれる政治家に投票すべきですが、常に正しい政策を実行してくれる政治家が自分の選挙区から立候補してくれるとは限らず、自分以外の人々が常に正しい政策を実行してくれる政治家に投票してくれるとも限らないというのが、世の中の現実です。
だから、どんなに自分が正しい政治行動を取っていても、おかしな政策が実行され、自分の将来が危うくなるリスクは常に存在します。
たとえば、金持ちばかりが得をし、平均的な労働者が搾取される最悪の格差社会になってしまうかもしれません。
あるいは逆に、今後スキルアップし、キャリアアップし、実力を身につけて高い年収をゲットしようと思っているのに、高額所得者の所得税が大増税されて、酷い搾取に苦しむようになるかも知れません。
あるいは、少子化対策で、実質的に独身税をかけられたのと同じような状態になり、結婚するつもりも子供を作るつもりもない人たちの生活の質がかなり落ちるかも知れません。
あるいは、国の医療システムが疲弊しまくって、まともな医療サービスを受けられなくなるかも知れません。あるいは、まともな治療を受けようとしたら、恐ろしく高い料金を徴収されるようになってしまうかもしれません。
あるいは、地方格差を埋めるため、都市部の住民を徹底的に搾取し、地方にじゃんじゃんばらまくような政治が行われるかもしれません。そうすると、田舎に住む人間の暮らしはよくなるかもしれませんが、今後も都市に住み続けるつもりの人間の暮らしの質が大きく低下するかも知れません。
あるいは、非正規雇用を減らし正社員を増やすという名目で、おかしな規制がかけられ、予期せぬ副作用が出て逆に多くの人が職を失うことになるかも知れません。余波で、自分まで失職するかもしれません。残された正社員の自分に酷いしわ寄せが来るかも知れません。
労働者保護や消費者保護という名目で、過剰に企業の手足を縛るような規制がかけられて、企業の活動が阻害されて経済が悪化したり、企業がどんどん日本から逃げ出すかも知れません。雇用が減り、治安が悪化し、日本が住みにくい国になるかも知れません。
要するに、投資において、全ての資産を一点がけするのが危険な投資戦略であるように、自分の生活基盤となる国家を一カ所だけに限定してしまうのも、極めて危険な賭なのです。
この国にずっと住み続けるのが一番賢い戦略でした。
しかし状況は変わりました。
いまや日本よりも豊かな国や都市がどんどん生まれつつあります。
日本などよりも、はるかに先行きの明るい国や都市がたくさんあります。
本来、この惑星には、たくさんの国家があり、それぞれ浮き沈みを繰り返しています。
いまいる国家が、今後もずっと浮いたままだという保証はありません。
一つの国家に依存しすぎると、その国家が沈んでいくとき、酷い目に会います。
いまいる国家が沈みそうになったら、早めに別の国家に移れるように、準備しておくべきではないでしょうか。*1
こういうことを言うと、「おまえに愛国心はないのか？」と言い出す人間が時々いますが、依存症と愛国心とは別の話です。
これは、結婚において、夫を愛していることと、夫に依存することが異なるのと同じことです。
経済的にも精神的にも自立していることと、夫を愛することは両立します。
夫婦仲は冷め切っていて、夫の暴力に怯えながら暮らしているにもかかわらず、夫に経済的に依存しているためにガマンし続けているような状態は、とても健全だとは言えません。
むしろ、特定の国にまったく依存していないにもかかわらず、その国を愛し、その国に貢献することこそ、純粋に打算抜きの愛国的な行為なのではないでしょうか。
そもそも、「いろんな異性とつきあってみて、そのなかから最高のパートナーを見つけ出して結婚する」というのは、少しもおかしなことではありません。
「1人の異性しか知らず、最初につきあった異性と一生添い遂げなければならない」というのはいかにも古めかしい道徳観念です。これは国家についても同じことです。たまたま日本に生まれたからと言って、日本と一生添い遂げなければならないということはありません。
むしろ、さまざまな国に住んでみて、そのなかから、自分にいちばんあった国に落ち着き、添い遂げる、という人生も十分にありなのではないでしょうか。
日本以外で暮らしたことのない人々の中には、日本だけが世界で唯一暮らしやすい場所で、日本以外には暮らしやすい場所などないと信じて疑わない人もときどきいるようですが、そんなことは決してありません。
むしろ、日本よりもはるかに、晴天の日が多く、気候が温暖で、からっとさわやかで、毎日気持ちよく暮らせる国や地域がたくさんあります。
食べ物も美味しく、人々も気持ちよく、街の各種施設も充実しており、遊び場所もたくさんある快適な都市は世界中にたくさんあります。
どんなところでも、けっこう住めば都なのです。
また、日本以外の国は治安が悪くて暮らしにくいという偏見を持っている人もいますが、どんな国でも、きちんとした安全対策を講じ、危険な地域に近寄らないようにすれば、それなりに安全に快適にくらせるものです。
それに、どうせネット環境さえあれば、世界中どこでも、twitterやtumblrやmixiで遊べるし、ブログのコメント欄でクネクネすることもできるし、2ちゃんでだらだら過ごすことも出来るし、エロ画像をダウンロードすることもできるし、はてブで脊髄反射的なコメントを付けることもできるし、はてなスターを連打しまくって顰蹙をかうこともできるのです。
「わたしは(この国に生まれたというより)この惑星に生まれたのだ」という感覚を持ちながら生きるというのは、広々とした感じがして、なかなか気持ちの良いものです。
せっかくこの美しい惑星に生まれたのに、日本という小さな小さな島国に引きこもったまま一生を終えるのは、じつにもったいないことではないかと思えてきます。
●依存症からの脱出は難しい
ギャンブル依存症、アルコール依存症、買い物依存症、恋愛依存症、セックス依存症、たいていの○○依存症は、そこから抜け出すのに苦労するように、日本依存症も、一度それにかかると、そこから抜け出すのにかなり苦労します。
また、タバコ依存症から抜け出すために、さまざまな方法があるように、日本依存症から抜け出すにも、さまざまな方法があります。
日本依存症から抜け出す一番効果的な方法は、実は、英語力をアップすることではなく、日本の外でも安定した収入源を得られるようにすることです。(もちろん、最低限の英語力は必要ですが)
これに一番効果的なのが、資産運用で暮らせるようにすることです。
利回りのよい債権や株式に自分の資産を分散投資し、運用することは、どこの国に居住していてもできます。
日本の国債や株式で資産を運用していたとしても、日本に住んでいなければ運用できないということはありません。世界中どこに住んでいても、日本の国債や株式で資産運用することは可能です。
それどころか、そもそも、日本の国債や日本の株式で資産を運用しなければならないということはありません。
むしろ、全資産を円ベースに一点がけしてしまうと、今後円安が進んだときに、自分の資産が大きく目減りしてしまうというリスクを抱え込むことになります。
資産は、全世界に分散投資しておいた方が安全だし、世界全体の経済は、多少の波はあるものの、中長期的にはつねに成長し続けているので、正しくポートフォリオを組んで、世界中に分散投資しておけば、それほどひどいことにはなりません。
だから、いったん資産運用で暮らせるだけの資産を蓄積してしまえば、日本依存症からの脱却はかなり容易になります。
ここで、「日本がキャピタルゲイン課税の大増税を行ったら、資産運用では暮らしていけなくなるのではないか？」という疑問がわく人もいるでしょうが、そうでもありません。
まず、税金の徴収には、属人主義と属地主義の二つの方式があります。
日本は属地主義なので、自分が居住している国や地域に税金を納めることになっています。
このため、日本でキャピタルゲイン課税の大増税が行われたとしても、海外で暮らしている限り、影響を被ることはありません。*2
現在、属人主義を採用しているのは、アメリカとフィリピンぐらいなもので、極めて例外的なケースです。
ですから、今後日本が属人主義に変更するリスクは、とても低いと思われます。
また、万一、日本が属人主義に切り換えたとしても、ある程度の資産を持つ人間に国籍を与えてくれる国は、けっこうあります。
日本が属人主義に切り換え、さらにきわめて重いキャピタルゲイン課税をかけてきたら、単に国籍を切り換えればいいことです。
ただ、問題は、資産運用で暮らせるようになるほどの資産を蓄積することが難しい、ということです。
そのため、当面は、収入の全てを資産運用だけで稼ぎ出すのではなく、収入の一部だけでも資産運用で稼ぎ出すような状態を目指してみてはどうでしょうか。
そうすると、日本がヤバくなったので、脱出して海外で職を得たのはいいが、最初のうちはまだ英語にも不慣れで、十分な収入を得られないというようなケースでも対応できます。
たとえば、前述のUnix、Web、RDB、Java、Perl、.NET、C#など、世界中に普及している技術の場合、そのスキルを身につけることで、日本依存から抜け出すことができます。
また、これらに関連する要求仕様定義、オブジェクト設計技術、デザインパターンを適切に使いこなしたクラス設計、プロジェクトマネージメント、スケジュール管理なども、特定の国家に依存しないスキルです。
これらのスキルを身につけたITエンジニアは、さまざまな国で職を得ることが出来ます。
実際、ボクの知り合いでも海外で働いているプログラマーがいます。
むしろ、日本よりも快適に働いているようです。
もちろん、これらの技術は、会社依存症から脱却するための技術としても有効で、きわめて安全性の高い技術だと言えます。
これらの標準的なITスキルは、このように、会社や国家を超越して有効ですが、それ以上に驚きなのは、かなりの長い時間をも超越する力を持っているということです。
たとえば、unixの基本アーキテクチャはボクが知っているだけでも十数年、ほとんど変わってません。マルチスレッドプログラミングやデザインパターンも十数年前に身につけたスキルは、かなりの部分、いまでもそのまま役に立ちます。はるか昔に覚えた、クロージャや再帰を使ったさまざまなプログラミングテクニックも、RDBのスキーマ設計のスキルも、ほとんどが、いまだに現役です。
TCP、UDP、IP、HTTP、SMTP、POPなどのプロトコル類もいまだに基本はほとんど変わりません。新しく登場した.NETやC#にしても、過去にマスターしたスキルにほんのちょっと上積みしたぐらいのわずかな薄皮でしかなく、いままで蓄積した基本スキルはそのまま通用します。Haskellのような関数型言語ですら、似たようなコンセプトのプログラミングアーキテクチャは昔からあり、十数年前にマスターした技術の延長線上でなんなくマスターできます。
このように、長期的に安定した技術やスキルを選んで身につけるようにすれば、会社、国家、時間を超えて、安定した収入源を確保できるのです。
ただ、注意しなければならないのは人材の需給バランスです。とくに、インドや旧共産圏からのプログラマの大量供給は要注意です。
一方で、ヨーロッパ、BRICs、VISTAなど、世界中で急速に経済が発達しており、ITエンジニアの需要が今後も全世界的に巨大化し続けるのは確実です。
ここでのポイントは、下級エンジニアや中級エンジニアは、需要はそれほど拡大しそうにないのに、供給は膨大になると思われるので、リスクが大きいということです。
つまり、下級エンジニアや中級エンジニアの場合、海外に行くと、日本にいたとき以上に悲惨になる可能性があります。安易に日本から出て行くべきではないでしょう。
一方で、上級エンジニアは技術分野にもよりますが、今後、世界中で爆発的に需要が拡大することが見込まれていますが、供給が不足する可能性は十分に考えられます。
従って、自分が今後上級エンジニアになる可能性があると考えている人たちは、この戦略に沿って日本依存症から脱却しておいたほうが良い可能性が高いです。
あと、もう一つ考慮すべき点は、上級エンジニアになるような人は生産性が高いため、今後、高額所得者になる可能性があるということです。
今後、この機運の盛り上がりに押されて、高額所得者を狙い打ちする形で大増税が行われ、酷い搾取の対象にされるリスクもあります。
このリスクに対する保険という意味でも、早めに日本依存症を治療し、いつでも仕事と生活の場を海外に移せるようにしておいた方が安全かもしれません。
日本人が海外で暮らしてみると、さまざまな小さなニッチビジネスのチャンスに気がつくことがあります。
たとえば、日本にはあって当たり前なのに、その国にはない商品やサービス。
それは、日本のやり方を現地方式にアレンジすれば、それなりに繁盛する商売ができるかもしれません。
あるいは逆に、その国のおもしろい商品やサービスで、アレンジすれば日本でもウケそうなもの。
もしくは、現地の安い人件費を利用して、何かを作らせ、日本に持ち込むというパターンもあるでしょう。
実際、ネパールに小さな工場をもっていて、そこで自分のデザインした服を作らせ、日本に輸入して販売しているという女性に会ったことがあります。
こういうビジネスのネタをみつけたとき、スモールビジネスを興すスキルを持っていると、そのチャンスを活かして、その国で商売をはじめることができたりします。
とくに、最近急速に豊かになったアジアの国々では、日本がかなりブランドになっています。
とくに富裕層は、日本のさまざまな質の高い品々やサービスを求め、日本の産物に信仰のようなものを抱いています。
これをうまく利用することで、いろいろなニッチビジネスを作り出すことができるかもしれません。
スモールビジネスのスキルとは、小さな会社向けのマーケティング、マネージメント、経理などのスキルです。
たとえば、どんな小さなビジネスでも、どんな商品を、どんな顧客に売るのか、そのために、商品にはどのような魅力がなければならないのか、顧客は、どういう理由でその商品にお金を払うのか、どのようにして利益が出る構造になっているのか、などのビジネスモデルを組み立てなければなりません。
そして、いざ、ビジネスプランが出来たら、場合によっては人を雇い、契約を結び、信頼関係を作り上げ、法律に則って取引しなければなりません。関係者全員が気分良く仕事できるように、win-winの構造を作り出す必要があります。
また、さまざまな法律を調べ、その法律に則ってビジネスを運営する必要があります。
さらに、会社を設立し、会計ソフトで帳簿を付け、経理と資金の管理をする必要があります。
また、予算計画を立て、融資なり出資なりで資金を調達する必要もあります。
こういう小さなビジネスを最小限の規模ではじめてみて、いざ、顧客の反応が上々だったら、しだいに規模を拡大していけばいいのです。
思ったより反応が悪ければ、早期に撤退するか、あるいは、やり方を変えて再度トライしてみたりすればいいでしょう。
そして、スモールビジネスの醍醐味は、たまたま大ヒットしたときのうまみです。
日本のサラリーマンの頂点とも言える、上場企業の社長の年収でも、たかだか4000万円にしかなりません。
これに比べ、スモールビジネスをヒットさせた場合、実質的に年収1億円を優に越えてしまうということは、それほど珍しくないのです。
実際、ぼくの知り合いにもそういう人がいます。
「たかが自営業」とばかにできるようなもんでもないのです。
自営業は、あたると凄いんです。
どのようなモデルで日本依存を脱却するのであれ、共通して必要な Permalink | 記事への反応(0) | 22:10
普通にクロージャという場合、レキシカルスコープを持つことを期待されると思うけど、DLLやらsoからエクスポートされる関数は普通のCのスコープだからクロージャとは言わないと思うよ。（そもそもDLLもsoも標準C/C++じゃないから、もしこれらがクロージャ的な動きをするとしてもこれを以て「Cのクロージャ」と呼ぶのはおかしいというのは置いといても。）
ダイナミックスコープなemacs Lispのlambdaとか、ダイナミックスコープもどき(っていうのか?なんて表現したらいいか分からん)なPHPのcreate_functionは動的に作りはしてもクロージャとは言わないんじゃないかな。
http://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%AD%E3%83%BC%E3%82%B8%E3%83%A3
例示された 5つ が 動的コード操作のことを指しているのなら、そりゃバッドノウハウかもね。
これだけ世界に普及しているC言語のプログラミングスタイルを云々できるかどうだかは知らないけど、設計次第では普通にあり得るよね？
というか qsortって標準ライブラリだし 始めから意図されて作られていると思うよ。
高階な概念はそこらにある。
例えばあまりに定型的なツリーの操作を10個書くときに、 ツリーのトラバース1つ＋関数ポインタ10個を使うのは 普通のテクニックだと思う。
qsortと同じだよ。
まあでも…どうなんだろう。「クロージャがない言語のくせにムリヤリ関数を使おうとしたときのバッドノウハウ」とは言えなくもない。