 
|
はてなキーワード: クロージャとは
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と同じだよ。
まあでも…どうなんだろう。「クロージャがない言語のくせにムリヤリ関数を使おうとしたときのバッドノウハウ」とは言えなくもない。
そういうのはバッドノウハウとは言わないの？
関数ポインタをバッドノウハウとは言わないでしょ。C言語自体がバッドノウハウの結果だと言うなら、当たりだけど:)
手続き関数という抽象はまことに一般的な存在で（数学では汎関数というのもある）、それをC言語で直接的に表現したのが関数ポインタ。 関数的なものを オブジェクト指向言語でオブジェクトとして実装するほうがバッドノウハウだと思う。 少なくとも私は JavaのComparableインタフェースよりも C言語の heapsort/mergesort/qsort の関数引数 int (*compar)(const void *, const void *) のほうがシンプルで どちらかといえば本質をよりよく表していると思う。 なぜ関数的なものを表現するのに オブジェクトとかinterfaceとか継承とか「余計な概念」を導入する？それこそバッドノウハウでしょ。 まあでもC言語にはクロージャが無いから、関数的なものも扱いづらいことこの上ないが、Cにクロージャが無いこと自体はバッドノウハウとは言わないでしょー。
逆も然りで、オブジェクトを表現するために 関数を使ってれば そればバッドノウハウだけど、オブジェクトは関数ほど一般的な概念ではないと思う（オブジェクトなんか無くても別にいい、かも？）。
唐突にClass::Data::Inheritableのソースコードについて説明してやんよ。
使い方とかの説明はこの辺でも読んでから出直して来い、ごるぁ！
まぁとりあえずソース見てみろ、下記にはっつけてやっからよぉ！
1: package Class::Data::Inheritable; 2: 3: use strict qw(vars subs); 4: use vars qw($VERSION); 6: $VERSION = '0.06'; 7: 8: sub mk_classdata { 9: my ($declaredclass, $attribute, $data) = @_; 10: 11: if( ref $declaredclass ) { 12: require Carp; 13: Carp::croak("mk_classdata() is a class method, not an object method"); 14: } 15: 16: my $accessor = sub { 17: my $wantclass = ref($_[0]) || $_[0]; 18: 19: return $wantclass->mk_classdata($attribute)->(@_) 20: if @_>1 && $wantclass ne $declaredclass; 21: 22: $data = $_[1] if @_>1; 23: return $data; 24: }; 25: 26: my $alias = "_${attribute}_accessor"; 27: *{$declaredclass.'::'.$attribute} = $accessor; 28: *{$declaredclass.'::'.$alias} = $accessor; 29: } 30: 31: 1;
短いソースだなーこれ。でもな、なめんじゃねーぞ。短いけど色々な技術が盛り込まれてんだよコレはよぉ。
ハイ、まず3行目。
かるくstrictについて説明してやんよ。心して聞けよオマエラ。
strictっつーのはだな、つまりPerlにおける曖昧な部分をすこーしだけチェックしてくれるスグレモノなんだなコレが。
とりあえずざっくり言うと三つの機能があってだな、下記のよーに書くわけだ。
use strict 'vars'; use strict 'subs'; use strict 'refs';
varsってーのは簡単に言うとmyとかourとか宣言しろボケってやつですわ。
subsは裸体は許さんってやつですの、$とか%とかついていない裸の文字列をエラーにしてくれんだよ。
refsってのが一番やっかいな代物でな、これはムツカシイ言葉で言うとシンボリックリファレンスってんだが、要は変数名に変数を使うとエラーにしてくれるってこったよ。
で、これら全部ひっくるめてuse strict;なんだな。わかったか？オラ！
ちゅーことはだ、3行目を見ると意図的にrefsだけ外してるのがわかるよな。
つまりコレはこのコードのどこかで変数名に変数を使うってことを明示していることにもなるわけだ。けけけ。
あーもういいもういい、次だ、次。
4,5行目を見てみろよ。今時our使わずにuse vars使うなんてどんだけー。
ははは、まぁまてよ。
ourってのは明示的にグローバル変数を定義するもんなんだが、このourってやつが導入されたのがPerl5.6からなんだよ。
Perl5.5のころはourなんてなかったからグローバル変数定義すんのにこのuse varsを使っていたわけだ。
つまりこのモジュールはPerl5.5環境でも動くように配慮しているわけなんだな、ちゃんちゃん。ほほほ。
あーもう全然すすまねーよ。チクショウ、が、ま・・・・。
で、11-14行目。これはref関数使って$declaredclassがオブジェクトだったら死ぬって処理だ。
require CarpっつーのはCarpモジュールを動的にロードしてるっていうことだよぅ。
で、Carp::croak関数使ってエラー文はいて死ぬ、と。ちなみにこのCarp::croakってはまぁdie関数みたいなもんなんだ。
違いとしてはエラーの発生した原因を呼び出し元の奴のせいにして自分は悪くないんだよってアピールすることかな。まぁ実際使ってみりゃわかるよ。
さぁ、16行目。本編突入だ。長かった。長い道のりだったなお前ら。
sub {}ってのは無名サブルーチン(関数のリファレンス)ってやつだ。で、ここで注目すべき点はただひとつ！！！！！
19-23行目あたりをぼーっとみてると$declaredclass, $attribute, $dataっていう変数を使用していることがわかる。
これらの変数は9行目で受け取ったmk_classdataへの引数だ。
ここで問題が発生する。
myで宣言された変数の賞味期限はスコープの終端だ。それはわかるな？
つまり9行目で宣言された$declaredclass, $attribute, $dataといった変数どもは29行目のスコープの終端で消滅してしまうわけだ。
しかし！その消えてしまうはずの変数どもをsub {}という無名サブルーチンの中で使用してしまっている！！！
これが世間一般に語られているクロージャという仕組みなのだ！！！！！！うはははははははｈ！！！
本来生涯をまっとうするはずだった変数たちが別のサブルーチンの中にまぎれてしまうとその別のサブルーチンが消えてなくなるまでは死ぬことを許されなくなるのである！！！ざ・不☆老☆不☆死！
なんたる奇妙奇天烈なことであるが、この現実を受け入れることによってお前らの道が開けるんだ！！！すげーだろぉがよぉ！！
ボクはッ、キミがッ、クロージャを受け入れるまでッ、殴るのをやめないッ！
さて、肝心の16-24行目のアクセサ部分の処理の解説だけども、
引数が渡されてなければ特になんの処理もせずに$dataを返している。$dataってのは死ぬことを許されなくなったカワイソウな変数君だ。
つまり、Class::Data::Inheritableってやつはアクセサに渡された値をどこで保存してるのかというと、紛れも無いこの$data君に他ならない。
$data君がニート君になっちゃうとたちまちデータの読み書きができなくなるのであまり働かせ過ぎないように注意しよーね！
ハイ、次はアクセサに引数が渡された時の処理だけどな、20行目を見てみろ。$declaredclassに格納されてる値はmk_classdataメソッドを使用したときに格納された値になる。
package Hoge; use base qw/Class::Data::Inheritable/; Hoge->mk_classdata('hoge_accessor');
つまり上記の処理で例えると、$declaredclassには'Hoge'という文字列が入ってることになんだな。
で、この'Hoge'と$wantclassに入ってる値を比較しているわけだが、
package Hoge; use base qw/Class::Data::Inheritable/; Hoge->mk_classdata('hoge_accessor'); Hoge->hoge_accessor('aaa');
上記の処理で例えると$wantclassには$declaredclassと同じく'Hoge'が入ってくることになんだな。うっひょー。
んで、20行目のif文は$wantclassと$declaredclasが違う場合にだけ19行目の処理を実行しているわけだからこの場合はスルーするわけだぁ。ひょひょひょ。
じゃあだな、$wantclassと$declaredclasが違う場合ってどんな場合？ってことだが、下記に例を示すから目ん玉引ん剥いて網膜から直接見てみろよこのボケ野郎どもが。
package Hoge; use base qw/Class::Data::Inheritable/; Hoge->mk_classdata('hoge_accessor'); package Foo; use base qw/Hoge/; Foo->hoge_accessor('bbb');
HA！HA！HA！こういう場合だよ米ベー。$wantclass=Fooで$declaredclas=Hogeになるんで19行を実行し、Fooをベースにしてmk_classdataを呼ぶことでFooに同じ名前の新たなアクセサを提供し、元クラスHogeの値を壊さないようにするわけですなぁ。
考えた人すごいですなぁ。これがClass::Data::Inheritableが継承可能なクラス変数といわれる由縁でするまする。
で、最後の26-28行目はコレらの便利な処理をしてくれる$accessorさんをクラスに登録するというわけですよぉ。
27,28行目の*ってのは型グロブ変数ってという奴で、型グロブに対して無名サブルーチンを突っ込むと動的に関数を定義できるんだなぁコレが。
でここで、初めに俺が語った話を覚えてるか？へっ、オマエラなら覚えてないだろうなけっけ。use strictの話だよ。refsだよrefs。
ここでrefsを省いていたのが利いて来るんだ。refsって何だった？ホラ言ってミソ？
で良く見てみると型グロブ変数に対して「$declaredclass.'::'.$attribute」っていう変数を使おうとしているよね？これをしたかったからrefsだけ仲間外れにしてたわけですね。
はは。
あー、あー、あー。
これで終わりだよぅ。みんなわかったかな！？
コレ読んでもわからんやつはもう死ぬか、もしくはわからん用語について死ぬほど調べてもっかい読みなおしてみろこのド低のぅッ・・・ごふんごふん、このクサレ脳みそがぁ！！！！！！！！！！！！１１
小飼さんにまでご意見いただいて恐縮です。 でもトラバ全無視で新エントリを書いちゃう。
仮に子供の頃プログラミングに目覚めたとしても、その時点では打ち込んだゲームのコードを「追う」ことは出来ても、データ構造もアルゴリズムも「理解」するのは難しいだろう。ポインターもクロージャーも、むしろ大人になってからの方が理解は早い。一度面白さに目覚めてしまえば、今や教科書だって「実習環境」だっていくらでもある。慌てる必要は全くない。むしろ「老後の愉しみ」ぐらいでちょうどいいぐらいではないだろうか。
やっぱりそういうものなんでしょうね。 学ばせるなら大学とか専門学校とかでいくらでもありますし。
プログラム言語は、子供が触れてみて面白いというものではなくなった、ということで…
PC でなにか作るなら、ほかに絵とか音楽とかブログとかなんでもありますもんね。
ブクマのコメントみたら LEGO mindstorm とかロボットというご意見もいただきました。 ちょっと敷居高そうですが、楽しそうです。
。
プログラマが枯渇云々というのは、べつに日本にしかプログラマがいないわけじゃないし、どこへでも求められますので気にしちゃいないです。
これから就職活動するバカはいないだろうけど、そういう人もいるだろうから少し書いておこう。
どちらかというと、アンチMS派なUnix技術者がWindowsだけの世界で仕事をする辛さを。
Unix技術者は、業務実績にSolaris/AIX/Linuxって書いてあってもちゃんと質問しろ。Windowsの仕事は無いですよね？って。
僕が食べるために職を手にしているこのIT業界というのは、バッドノウハウとMicroSoftとExcelで出来ている。
その為、僕が手にしたUnixの知識は、特定の仕事以外でしか役に立たないし、使わない。
viだろうが、TeXだろうが、Xの知識よりも、MFCとVBAのちょっとした知識のあるヤツが上にみられる。
ExcelとWindowsの知識があればそれだけで仕事になるからだ。
いいか、viやTeX、Xなんて捨てちまえ、Excelがあればそれでいいのだ。
MSでは、ActiveXを使ってCOMを操作し、クライアントのレジストリを操作し、IE単体でできないことをやってしまうヤツがハッカーと思われている。
VBAマクロで作ったなんちゃってツールを3時間で作れるほうが、
perlやruby/pythonで、より少ない時間で作ったツールよりも凄く思われてしまう。
そして、それができるヤツの方が、Unix技術者よりもよりハッカーであり、技術力があると思われている。
ブラウザを例にしたが、
javascriptでalert/confirmを出すよりも、vbscriptでMsgBoxの方が多くのことができるから、
javascriptでNumberの計算よりも、vbscriptでDecimalを使った方が倍密度の計算ができるから、
vbscriptを駆使できるヤツは、凄く重宝される。
いいか、javascriptで汎用的に書くのなんてナンセンスだ。javascriptなんて捨てちまえ、覚えるのはJScript実装(WSH)だ。
この業界、何が不満になるかというと、
MSの、もっというとWindowsのことしか知らないヤツが多すぎるということ。
そういうヤツらは、Windowsだったらこんなこともできるのに、なぜUnix/Linuxだとこんなこともできないのか。と言う
そういうヤツらは、Windowsの未修正バグの合間を縫いながら中途半端な実装しかしない。
だって、中途半端(もしくは大雑把)な実装で動いているものの中で動くから。それ以上に実装しようとしてもできないのだ。
いいか、win32のメッセージングの仕組を覚えるんだ。無理矢理send_keyみたいなコードを書けるようにしろ。
コマンドを連結するよりも、結果に近いコードを書くんだ。線形になろうがヤツらは気にしないだろう。
何故か。
それは、.NETで作ればお客さんの要望が実現でき、Excelと連携できるからだ。
ヤツらは、C/Sの世界でこそ役に立つ技術者だが、Webの世界に連れてきてはならない。すぐに実装がIEだけになる。
ヤツらにLLを覚えさせるのは無理だ。
クロージャなんて知らないし、高階関数やカリーなんてコードを教えてみろ。後から辛くなるのは自分だ。
ヤツらにはPHPを教えておけ、それだけで満足する。すごいヤツになった気にさせれる。
バッドノウハウ慣れしているヤツらはそれを使ってコードを書いてもらえ、rubyで書かせるよりも修正が20倍楽だ。
いいか、まとめるぞ。
今まで一生懸命Unixを勉強してきたのは無駄だ。いますぐ忘れるんだ。
Excelを今から覚えろ。VBAを覚えろ。そしてMSの動きを身に着けるんだ。
Windowsでは単位がFormだ。それが標準出力と標準入力と思え。ときどきSheetとかWorkbookになるぞ。
ストリームやファイル操作には気をつけろ。Unixの気分でいると思わぬところで抜けが出るぞ。
IRCは使うな。Jabberを使うな。メッセンジャーを使え。移行のお薦めはGaimだ。Windows版がある。
viの使用頻度を減らせ、変なコマンドを身に着ける前に、秀丸マクロを書けるようにしろ、Notepadのショートカットを覚えとけ。
BindとかApache(Httpd)の知識はいらない。IISだ。ActiveDirectoryだ。
文字コードはCp943cを何がなんでも押せ。Shift_JISっていう大雑把な伝えかたはダメだ。絶対cp943cにしろ。UTF8/UTF7との格闘で身も心もぼろぼろになるぞ。
汎用性なんて無いんだ。Windowsというプラットフォームがあれば。
ああ、心が渇いていく。
javascriptで存在するほとんどのオブジェクトの実体はハッシュだよ。
var arr = [0,1,2,3];
とかをみると配列(人によってはリスト)に見えると思う。でも実際は違うんだ。
これは
var has = {0:0,1:1,2:2,3:3};
と基本的には等価なんだ。ただちょっと束縛されているメソッド(インターフェイス)が違うだけ。
ためしに
arr[4] = 4; arr['x'] = 'string'; arr[-1] = -1;
としてみよう。
Firebugで確認してみると[0, 1, 2, undefined, 4]というような値がかえってくるよ。
でもarr[-1]やarr['x']の値は保存されてないのかな？そんなことはないちゃんとアクセスできるんだ。
それどころかarr.xで'string'がかえってくるんだ。
別の例を見てみよう。
var fx = function(){}; fx[0] = 'somestring';
こうするとfx[0]に'somestring'が束縛される。
つまりfunctionも一つのハッシュだったんだ。
これでほとんどのものがハッシュだということが解ってくれたかな？
ハッシュじゃないのは文字列とか数字とかそいういシンプルなものだけなんだ。
ハッシュへはhash[name]でアクセスすることが出来る。
それ以外にもnameが演算子や空白を含まなくて頭が数字でない場合はhash.nameでアクセスできるんだ。
これでhash[name]が関数だったらhash.name(args)とできるよ。まるでメソッドみたいだね。
関数には名前を付けなくても使用可能だよ。
function(x){return x+x}(2); -> 4
関数宣言の書き方って次見たいの覚えてる人が多いんじゃないかな？
function funcname(args){ do something};
でもこれはsystax sugerだってことを知ってほしい。
上でも使ってるんだけど。
var funcname = function(args){ do something};
と等価になる。もちろんどちらの書き方でもかまわないよ。
ただ、(無名)関数を宣言してそれをfuncnameに束縛しているっていうことを理解しておくと便利だよ。
javascriptはレキシカルスコープを採用してるんだ。
レキシカルスコープなんていうと難しく感じるかもしれないけど、結構単純なんだ。
var x = 'global';
var fx1 = function(){return x};
var fx2 = function(){var x = 'local';return x}
これの実行結果は以下になるよ。
fx1() -> 'global' fx2() -> 'local' fx1() -> 'global'
fx2の変数xはほかの場所に影響しないんだ。これは関数の中と外ではスコープが違うからなんだ。
でも以下のような場合に注意してほしいな。
var x = 'global'; var fx1 = function(){return x}; var fx2 = function(){x = 'local';return x}
fx1() -> 'global' fx2() -> 'local' fx1() -> 'local'
fx2は自分のスコープに変数xがないからその外側スコープに探しに出かけたんだ。
つまり宣言文varはそのスコープに新しい名前を登場させる機能なんだよ。
別の場合を見てみようね。
var x = 'global'; var fx1 = function(){ var x = 'local'; return function(){return x} }; var fx2 = fx1();
x -> 'global' fx2() -> 'local'
この例だとfx2()の値がlocalになってるね。
なぜなら外側スコープっていうのは関数を評価した場所じゃなくて、関数を定義した場所の外側なんだ。
一つ上の例では実際に関数を返り値にしているね。
var fx1 = function(){ var x = 0; return function(){ x = x+1; return x; } }; var fx2 = fx1(); var fx3 = fx1();
fx2() -> 1 fx2() -> 2 fx2() -> 3 fx3() -> 1 fx3() -> 2
fx2とfx3の値が違うのはそれぞれ別の関数が作られるからだよ。
こんな風に関数が状態を持つことも出来るんだ。クロージャーとよんだりするよ。
関数がハッシュを使って複数の関数を返すとこんなことも出来るよ。
var fx = function(){ var x = 0; return { 'up':function(){ x = x+1; return x; }, 'down':function(){ x = x-1; return x; } } }; var obj = fx();
obj.up(); -> 1 obj.up(); -> 2 obj.down(); -> 1 obj.down(); -> 0
thisという機能があるよう。ちょっとだけつかってみるね。
var x = 0; var add = function(n){this.x = this.x + n; return this.x}; var mul = function(n){this.x = this.x * n; return this.x}; var obj = {'x':0,'do':add};
add(1); -> 1 add(1); -> 2 mul(2); -> 4 obj.do(); -> 1 obj.do(); -> 2 obj.do = mul; obj.do(); -> 4
thisは評価された場所によって値がかわるよ。
objの中にいるときはobj.xを扱うし、グローバルにいるときはグローバルのxを扱うんだ。
http://anond.hatelabo.jp/20070620200618を改訂してみたよ。
このぶんしょうがjavascriptを覚える上の一助になるとうれしいんだ。
あとここでつかってるハッシュは伝統的な意味。連想配列のことね。
突っ込みも大歓迎だよ。
「ブロック付きメソッド呼び出し」がわからん、ということでいいのかな。この概念は是非とも解ってほしいので、今日始めて Ruby を触った俺が頑張って解説しよう、と思ったけれど、いいドキュメントを見つけたのでリンクしておくよ。
これで解らんかったらOn Lispを途中まで読みんさい(お金がないならWeb 版をどうぞ)。「ブロック付きメソッド呼び出し」は元々関数型言語の界隈で「レキシカルクロージャ」と呼ばれるもので、要するに中身は一緒なのでクロージャが解れば「ブロック付きなんたら」も解る(Ruby を触ったことのない自分が「ブロック付きなんたら」を理解しているのはこれの為)。 On Lisp は Common Lisp という言語の本なんだけど、 Ruby は言語仕様の多くの点で Common Lisp を参考にしているので、勉強するのはそれほど難しくないと思う(つまり見た目はヘンテコだけど中身は Ruby ってこと)。
元記事:
http://www.arclamp.jp/blog/archives/marulec2006_2.html
http://d.hatena.ne.jp/t_yano/20061216/1166296467
こんな感じですか？
public interface Executable <T> { void execute(T argument); } public class IterationExecutor<T> { private Collection<T> collection; public IterationExecutor(Collection<T> collection) { this.collection = collection; } public IterationExecutor(T[] array) { this.collection = new ArrayList<T>(); Collections.addAll(this.collection, array); } public void each(Executable<T> e) { for(T element: collection) { e.execute(element); } } } public class IntegerBuffer { private int value = 0; public IntegerBuffer(int value) { this.value = value; } public void add(int number) { this.value += number; } public int getValue() { return this.value; } } public class Sample { public static void main(String[] args) { final IntegerBuffer total = new IntegerBuffer(0); new IterationExecutor<Integer>(new Integer[]{1,2,3,4,5}).each( new Executable<Integer>(){ public void execute(Integer it) { total.add(it); } }); System.out.println(total.getValue()); } }
importなどは省略しました。
Sample以外は再利用可能なので……いやどうだろう