  |
はてなキーワード: リファレンスとは
いまさらだがFizzBuzz。
1から100まで、3の倍数5の倍数云々って、全部定数の計算じゃね？
というところに気付き、自称メタプログラマー（略してメタグラマー）俺の血が騒いだ。
定数計算なら、それは実行時ではなくコンパイル時に行なわれるべきだ……。
#include <iostream> const int FIZZ_NUM = 3; const int BUZZ_NUM = 5; const int BEGIN_NUM = 1; const int END_NUM = 101; template<int N> struct Fizz { enum {PRINT = 0, NEXT = N + 1}; static void print() {} }; template<int N> struct Buzz { enum {PRINT = 0, NEXT = N + 1}; static void print() {} }; template<int N, bool ForB> struct Number {static void print() {std::cout << N;}}; template<> struct Fizz<FIZZ_NUM> { enum {PRINT = 1, NEXT = 1}; static void print() {std::cout << "Fizz";} }; template<> struct Buzz<BUZZ_NUM> { enum {PRINT = 1, NEXT = 1}; static void print() {std::cout << "Buzz";} }; template<int N> struct Number<N, true> {static void print() {}}; template<int N, int F, int B> struct FizzBuzz { static void print() { typedef ::Fizz<F> Fizz; typedef ::Buzz<B> Buzz; Fizz::print(); Buzz::print(); Number<N, Fizz::PRINT || Buzz::PRINT>::print(); std::cout << std::endl; FizzBuzz<N + 1, Fizz::NEXT, Buzz::NEXT>::print(); } }; template<int F, int B> struct FizzBuzz<END_NUM, F, B> {static void print() {}}; int main(int argc, char **argv) { FizzBuzz<BEGIN_NUM, 1, 1>::print(); return 0; }
ifなし%なしループ系なし、しかも実行時オーバーヘッドなし！（多分）
ああ、久しぶりにC++を触ったけど、やっぱC++のテンプレートってダメダメだな。20世紀の遺物といわざるを得ない。
君がもし21世紀のモテ系イケメンメタグラマーなら、21世紀のプログラミング言語、D言語を使うべきだ！
驚くべきことに、D言語はコンパイル時に関数が実行でき、その結果をソースコードとして取り込める！
ただし実行できるのは簡単な関数だけだけど……。
import std.stdio; // これでFizzBuzzを全部出力するコードを作るぜ！ string makeFizzBuzzCode() { string code; for(int i = 1; i <= 100; ++i) { // 効率？ コンパイル時にそんな配慮は要らん！ if(i % 3 == 0 && i % 5 == 0) { code ~= "writefln(\"FizzBuzz\");\n"; } else if(i % 3 == 0) { code ~= "writefln(\"Fizz\");\n"; } else if(i % 5 == 0) { code ~= "writefln(\"Buzz\");\n"; } else { code ~= "writefln(" ~ static_itoa(i) ~ ");\n"; } } return code; } int main(string[] args) { // おまけで生成されたコードも見せるよ。 pragma(msg, makeFizzBuzzCode()); // 生成したコードを埋め込む。コピペみたいな感覚。 mixin(makeFizzBuzzCode); return 0; } // 以下ユーティリティ。このぐらい標準で欲しいな……。 /// 整数→文字列変換（コンパイル時） string static_itoa(int n) { if(n == 0) { return "0"; } // 10で割りながら余りを文字にして追加。桁が逆転した文字列になる。 string s; for(; n; n /= 10) { s ~= ("0123456789")[n % 10]; } // 桁位置を正常にする。相変わらず効率無視。 return static_reverse(s); } /// 配列リバース（コンパイル時） /// 実行時ならarray.reverseが使えるんだけどね……。 T[] static_reverse(T)(T[] s) { T[] result; foreach_reverse(c; s) { result ~= c; } return result; } // 心配なので静的ユニットテスト（笑） unittest { static assert(static_itoa(0) == "0"); static assert(static_itoa(10) == "10"); static assert(static_itoa(999) == "999"); static assert(static_itoa(9999) == "9999"); static assert(static_itoa(12345) == "12345"); static assert(static_itoa(314159265) == "314159265"); }
コンパイル結果
$ dmd -unittest fizz_buzz.d writefln(1); writefln(2); writefln("Fizz"); writefln(4); writefln("Buzz"); writefln("Fizz"); writefln(7); writefln(8); writefln("Fizz"); writefln("Buzz"); writefln(11); writefln("Fizz"); writefln(13); writefln(14); writefln("FizzBu(ry
出力結果は略。
さすがD言語！C++やJavaやC#にできない事を平然とやってのけるッ
そこにシビれる！あこがれるゥ！
というか、
writefln(1);
writefln(2);
writefln("Fizz");
writefln(4);
もうwritefln（出力関数）要らなくね？
修正。
// これでFizzBuzzを全部出力するぜ！ string makeFizzBuzzCode() { string code; for(int i = 1; i <= 100; ++i) { // 効率？ コンパイル時にそんな配慮は要らん！ if(i % 3 == 0 && i % 5 == 0) { code ~= "FizzBuzz\n"; } else if(i % 3 == 0) { code ~= "Fizz\n"; } else if(i % 5 == 0) { code ~= "Buzz\n"; } else { code ~= static_itoa(i) ~ "\n"; } } return code; } int main(string[] args) { // もうコンパイル時のメッセージしか出さない。（笑） pragma(msg, makeFizzBuzzCode()); return 0; }
コンパイル結果。
$ dmd -unittest fizz_buzz.d 1 2 Fizz 4 Buzz Fizz 7 8 Fizz Buzz 11 Fizz 13 14 FizzBu(ry
実行するまでもなく結果が出力された。つまり実行時間ゼロ、ということは……
世 界 最 速
みんな使おうD言語！
http://www.kmonos.net/alang/d/1.0/index.html(1.0。こっちの方が安定してる？)
http://www.kmonos.net/alang/d/2.0/index.html(もっと凄い2.0)
うまくやる方法を考えてみた。
【目的】
社内でオープンソースのプロジェクトを行うことにより以下の４つの価値を生み出すことができる。
１．部門間におけるノウハウの共有
２．外部に公開した場合の宣伝効果
４．仕事そのものを作る効果
（４補足）
・新入社員の研修などが発生した場合に効果的に仕事を割り当てることができる。
・在宅勤務をせざる得ない状況における作業の割り当て。
【前提】
基本的に下記の事項を前提として考察を行う。
１．社内の人間であれば、誰でも参加できる。
２．途中で各人の任意のタイミングで抜けても、問題とならない。
３．社内の人間であれば、だれでもアクセス可能なWebサーバー上で情報を管理する。
ただし、必要に応じてアクセス制限をかけることができる。
インターネットに接続されている、Webサーバーは存在しているものとする。
４．各開発者は場所的、時間的に同じところにいないことを前提とする。
以上の前提より、下記の機能を有したWebサーバーの準備を行う。
１．構成管理機能
簡単にソースコードの取得、更新を行えるようにして、その履歴を残す。
２．Wiki
３．フォーラム
これにより、場所と時間にとらわれずに意見交換を行うことができる。
これにより、リリース時期の予測、作業の有無を効果的に確認できる。
５．テスト管理
これにより、リモート環境であってもリアルタイムにテストの進捗状況を確認できる。
案：TestLink
ReviewBoardの使用
http://blog.monospace.jp/2008/03/24/reviewboard_installation/
（※要調査）
７．フィードバックを受ける場
関係者のモチベーションを保つため、成果物に対して、フィードバックを受ける場を作成する。
案：社内のソーシャルブックマーク、アンケート機能
【効果的な手法】
その他、効果的な開発の進め方を考察する。
xUnitでテストコードを記述することにより以下の効果がある。
・修正後でも修正前と同じ動作するかどうかが、確認できる。
これにより、人の作成したコードでも修正を行いやすくなり、前提１、２の人の出入りに対応する。
自動ビルドを定期的に実行する。また、１のxUnitを使用して単体テストの失敗も監視する。
これにより、サーバー上にコンパイルが通らないソースコードや単体テストに失敗したコードの存在をチェックすることができる。
これは不特定の人間がかかわった場合に異常を検知するためである。
３．短期的なリリース
開発者のモチベーションを保つため、一定のめどがついた時点でα版という形でリリースを行う。
だめだまとまらん。
Re: http://anond.hatelabo.jp/20070304154248
ところでサー
javascriptってラッパー作りやすくていいよね。
名前を変えずにラップ出来るから好き。
クラスもインスタンスもメソッドも関数もオーバーライドしてラップして、好き勝手出来るから好き。
(function(){ var origin = hoge.prototype.foo; hoge.prototype.foo = function(){ ... }; hoge.prototype.foo.origin = origin; })();
perlはオーバーライドできるけど、元のメソッド呼べなくなる。すべてのインスタンスに影響する（たしか）。チョイめんどい。
use hoge; package hoge; sub foo { ... } package main; ...
他の言語では、どんな技がありますか？
[追記]
\&hoge::foo で元のコードのリファレンス取れたっけ？
すっかり忘れてる。
地味になって残念
SI業界における、気持ちよくアウトプットを高める事が出来て、キャリアにプラスな環境の条件を考察。
次に上げる、3つのステップが存在しているかどうかを一つの目安にしてみてはいかがでしょうか。
それぞれ、（１）新人（２）中堅（３）ベテランのチェックポイントに対応しています。
[ポイント]
（１）明快な規約と、明快なフレームワークが指定された仕事を振られている。
規約とフレームワークというのはあくまでも一例で、絶対にそれである必要はありません。
プロジェクト的には色々あっても、新人はやるべき事に迷わず仕事が進められる事が重要。
迷った時に根拠となるリファレンスがあれば、初歩的な事で周囲が煩わされなくて済む。
「外注(請負、派遣)クソッタレ」という現場に限ってこれが整っていない事が多いです。
もちろん、それがあっても出来ない部類の人間はいますが、仕事の振り方が間違っているから、
出力される結果が間違っているという場合の方が下手したら多いという事です。
（２）チーム内のトップクラスのプログラマがコメントしてくれる。→参考
本人に指摘された内容を理解し、受け入れるキャパシティが要求されるのはもちろん重要です。
しかし実際は、俺様が下っ端のコードなんか見れるかという態度の人が結構います。
確かに当人達は、そのような指摘がなく出来るようになっていた事が少なくありません。
だから、「なぜそんな事も解らないで続けてるの？」と相手を理解する事なく罵ります。
そして「こんな事も解らないクズを雇った奴は誰だ？」という人事への愚痴になります。
でも、そこでは自分が威張っていられて居心地がいいから転職は考えないという矛盾を無視しています。
そんな自分を誤魔化すために他人の成長の芽を摘み続けます。
（３）新しく入って来た新人に１と２を行えるようになった。
中堅までに鍛えられていないと、ベテランになった時に世間話でお茶を濁して笑いを取る事が
コミュニケーションスキルと勘違いしたリーダーの出来上がり、実際それは蔓延しています。
「情けは人のためならず」１＋１を２以上にするには、それぞれが学んできた事を他人に
フィードバックする事で他人を育てられないと、いつになっても自分の負担は軽減されません。
「俺がやるからオマエなんか不要」と言える技量持ちなら、好きなだけ抱え込めばいいでしょう。
しかし、成長した人間には難度の高い部分を任せたいのが社の意向、得意げになって下っ端のやれる
仕事を数多くこなされても非効率としか映らず、周囲の評価に結びつかないのが現実です。
「あんなにしてやったのに、”のに”がつくと愚痴になる」とは、相田みつをの言葉でした。
せっかくやるなら愚痴にならずに済む、無駄にならない仕事をしたいものです。
[まとめ]
上記の３点が整備されていない環境では、それぞれが自分の立場だけを守りがちになってしまいます。
情報を隠して自分がいないと進行しない状況を作り、楽な仕事を奪い合って困難な仕事の押しつけあう。
そういう仕事の仕方しか出来ない人間になると、仕事に喜びが見出せず仕事の時間が苦痛になります。
社会貢献とかそこまで考えなくてもいいのですが、仕事をする目的意識が低くなっていくものです。
仕事は仕事と割り切って卒なくこなし、自分の人生を豊かにする事を重視するならそれも良しですが、
そういうライフスタイルは、むしろ仕事に対する能力か集中力が人一倍高くないと成立しません。
常人にとっては、目的意識の低下はそれを妨げる最大の要因になります。
逆にいうと、これと反対の事を実践すると会社の離職率は高まり、担当案件は次々にデスマーチに陥れられ、
定時に帰れなくなるのと引き換えに、いつも同じネタでメシにありつく立派なSIerになれるでしょう。
つまり、ベテランが（１）と（２）を行わない限り、貴方の地位は安泰であるという事です。
でもそれじゃ業績評価に響くのじゃない？大丈夫、誰からも後ろ指を指されない社内ニートになるための10の方法の
特に「（４）新規事業・困難案件には積極的に参加」辺りがヒントになるかもしれません。→2.0
あとは社内ニートを駆除するたった５つのスゴい技により駆除されないように注意を払いましょう。
そういえば、未経験者でもしっかり教育、親切に教えてくれる先輩、経験を積んだリーダーになって活躍等
よく見ると上記に対応した仕組みが存在するかのように、入社案内で謳っている会社は少なく無いようです。
しかし大抵、具体的に誰が何をどうやって行うかは書かれていないので、誰も期待してはいないのでしょう。
軽く読み流されて、反故にされても気にならないポイントになってしまっているのではないでしょうか。
単純だけど根本的な問題に目が向かないから、なぜか毎度デスマーチになってる事に不満を洩らしつつ、
自分が未熟だからと無駄な謙虚さで、そこから逃げる事もせずに我慢している人が多いのでは無いかと。
我慢は体に毒なので、精神を病みやすい人には特に過酷な状態となります。
[これからSI業界に入る人]
その会社で自分が成長できるのか、それともツブシが効かない使い捨てにされるのか、
教育システムを備えていると謳っていても、現場のOJT環境に適うものはありません。
入社前に現場社員の声が聞ける機会があれば、上記ステップの有無を確認してみてください。
不幸にも、入ってしまった後で気がついた場合は以下に述べます。
[すでにSI業界にいる人]
与えられた権限で変更が出来ない環境のせいにしていても、状況が改善する事はありません。
周りを見回してこのステップが存在しない場合、自分の出来る範囲で導入を試みてください。
好意的なレスポンスが無かった場合、そこに未来はないようですから、退職条件を設定しましょう。
最近Perl界隈ではMoose、MooseってなんかMooseってのが流行ってるらしい。
自分自身のブログでは、さもずっと前からMoose知ってたかのように振舞うために、増田で先に放出しておく。てへへ。
プログラマ層が限りなく低い増田にこんなこと書いてもだれも見てくれない気はするけど。
初めてのMoose - Mooseのすすめ - はてな#hide-k
meta object protocol について考えてみる - TokuLog 改めChumbyとどきました日記
YappoLogs: Moose のコードを探索して理解を深めた
Mooseってのは結局のところClass::MOPのラッパーみたいなもんだと。
で、Class::MOPってのは何だ？ってことだけど、メタなんとかプログラミング？え？プロトコル？まーどっちでもいい。
よくよく読んでいくとメタなんとかとか大層な名前が付いてるけど、結局のところPerlのpackageそのものの操作をオブジェクティブ扱えるようにしたものみたいだ。
つまりだな、例えばpackageに対して動的に(静的ではなく！)メソッドを追加したい場合、今までなら
package Foo; **Foo::method = sub { return 'hoge'; }; print Foo->method;
のように型グロブに関数のリファレンスを突っ込むということをしなければなかったが
use Class::MOP; my $class = Class::MOP::Class->create('Foo'); $class->add_method('method',sub { return 'hoge'; }); print Foo->method;
みたいな感じでかっこよく追加できるってわけさ。ま、これはほんの一例だけどな。（他にもメソッドを削除したりフックしたり色々できる。その辺は今回省略。）
本来なら「package Foo」とするところを「my $class = Class::MOP::Class->create('Foo');」と書ける。
これの何が良いのかというと、$classというオブジェクト経由でFooパッケージを色々操作できるところにつきる。
型グロブを使用したり「no (warnings|strict)」をしたりパッケージを操作する処理っていうのはPerlのキチャナイ構文が多かったのだが、Class::MOPのおかげでスッキリ綺麗に書けるようになったってこった。
で、次にMooseだが、これは結局のところClass::MOPのパッケージ管理の部分に＋αしただけのラッパーだ。
でもその＋αってのが結構凄かったりする。
もうこの辺の話はさんざん既出だが、例えばhasという関数を使ってアクセサや型定義が出来たり
package Foo; use Moose; has 'method' => ( is => 'rw', isa => 'Int' , default => '10' ); my $obj = Foo->new; print $obj->method; # 10 $obj->method(50); print $obj->method; # 50 $obj->method('hoge') # Int型じゃないのでエラー
Moose::Roleを使ってRubyのMixinみたいなことができたりする。
でも実はこれらの処理ってのは本当は別に凄くもなんとも無い。
アクセサ生成なんてClass::Accessorがあるし、関数の引数の型チェックなんてのもParams::Validate等昔から存在してるし、Mixinに関してはもともとPerlは多重継承できるので最初からできるし。
じゃあなんでみんなMoose、Moose言ってるのかっていうと、それはやはりClass::MOPの存在が大きいであろう。
綺麗且つ柔軟にパッケージの操作が出来るClass::MOPが土台にあって、今まで別々の役割として存在してきたモジュール達を統合し、よりわかりやすく、より柔軟に、そしてより強力なPerlのオブジェクト指向を構築できるようにした。それがMooseなのだ。
・・・しかし、小生。
Mooseについて調べていくうちに一つ残念に思ったことがある。
オブジェクトにメソッドを追加する機構がないのだ。
オブジェクトにメソッドを追加する、だ。パッケージにではなく、オブジェクトに、だ。
具体例をあげる。
package Foo; use Moose; my $obj = Foo->new; $obj->meta->add_method('hoge', sub { return 'hoge' }); print $obj->hoge; # hoge
ちなみに$obj->metaというのはFooパッケージを管理するClass::MOPへのアクセサだ。
ということは上記の処理はFooに対してhogeというメソッドを追加していることになる。
では次の例。
package Foo; use Moose; my $obj = Foo->new; $obj->meta->add_method('hoge', sub { return 'hoge' }); print $obj->hoge; # hoge my $obj_2 = Foo->new; print $obj_2->hoge; # hoge
$obj_2->hogeが呼べてしまうわけだ。
$obj->metaは結局のところFooパッケージなのだから、そこにメソッドを追加しているので当然の結果である。
$objだけにメソッドを追加することは、Mooseではできないのだ。
非常に残念である。ああ、残念だ。
・・・しかし、小生。
これでもプログラマの端くれである。こんなことでめげていてはMooserを名乗れないのである。（あ、MooserってのはMoose使いの人の俗称ね。今僕が考えたの）
なのでオブジェクトにメソッドを追加できるように拡張して見せよう。
package Foo; use Moose; use Class::Object; my $class_object = Class::Object->can('new'); override new => sub { ref($class_object->(shift))->SUPER::new(@_) }; my $obj = Foo->new; $obj->meta->add_method('hoge', sub { return 'hoge' }); print $obj->hoge; # hoge my $obj_2 = Foo->new; print $obj_2->hoge; # エラー
たった3行追加するだけで実現できる。さすがMoose。
ただし、Class::Objectを利用しているのでFoo->newで返ってくるパッケージがFoo::0といったようにFooではなくなってしまっているのでrefとかでパッケージ名の比較ができなくなってしまう問題が発生する。
でもこれも継承順をいじったりと本気で頑張れば、表向きに見せるパッケージ名をFooすることも可能だろう。
その添削の役目はどこかのハッカーに任せるとして、今日のところはこの辺で終了としたい。
Moooooooooooooose!と叫ぶのが流行ってるみたいなので、もっとも長くMooooooooooooooose!と叫んだ最初の男となるべく下記の処理を残しておく。
length q chdir uc and print chr ord uc q rmdir and do { print chr ord q xor x while $a++ < 0xffffffff } or print chr ord qw q sin q and print chr ord q ne sin and print chr hex length q q shift shmread bless q;
FireFoxのDel.icio.us Bookmarks入れてから、ローカルのブックマークをほとんど使ってない。
自宅以外でPC触る機会があると、SBM無かったらやってられないぐらい。
ある程度以上ネットに触れてるなら、自然にSBMに行き着くような気がする。
検索にひっかからないから存在を知ることが無いってのは、確かにそのとおりじゃないかと思う。
Yahooに出てこないWebページは存在しないのと同義という人はかなり多い気がする。
しかし、携帯との接続性を高めて欲しいってのは自分もかなりそう思ってるが、それで利用者が増えるかっていうと微妙だと思う。
話題になってること探すにも、Yahoo!ニュースか、mixiニュースで充分。
わざわざ新しい事をしようとも思わないし、探す必要もないし、気づくこともない。
っていう人が携帯からわざわざブックマークしなきゃいけないほど何かWeb上のものを見返すとは思わない。
携帯でRSSリーダー使って記事を見て行ってる時に、「これはPCで見たい」とか、「リファレンス的に使える」とかそういうエントリがあったときに、携帯で即SBMに投げられるならそりゃ便利だと思うが、それ以外にそんな携帯からSBMに投げることがあるのかなって。
ヘビーユーザー視点でしか物事を考えられてないと、自分でも思わなくは無いがw
まあ、卵が先か鶏が先かみたいな話かもしれないね。
食い下がってんのはお前だろ。
いや、形式的にみても実質的にみても、撤回したはずなのにちっとも撤回して見えないのは君が食い下がってるからなんだが。
民主主義も自由主義も自然科学も、キリスト教と論理的に直結はしていない。
たまたまキリスト教圏で発生したから影響は見られるがな。
文学研究とか歴史研究という分野を知らんのかねこの人は。それからいうまでもなく東洋哲学とか仏教学がある。え？なに？広義の文系学問ばっかりだって？気象学とか地震学でも過去の記録は見るよ。
それが「一般人レベル」か？ 高校で教える価値があるかどうかは微妙だが。
そりゃどんな学問上の専門知識でも使う分野では使うに決まっているわけだが。
近代（あんたのいう近代と中世の境界線はどこだ。ルネッサンスかウェストファリア条約かフランス革命か）
日本の古典の話をしてるんだが。とりあえず便宜的に日本の言文一致体以前以後で区切ってみようか。
なんか、今でも一般人が学ぶ意義のあるような文献がそれ以前にある？
論文のリファレンスにニュートンだのライプニッツだのの著書を挙げる奴がたまにいるが、あれを実際に読んでるのは物好きだし、読まなければ理解できないなんてことはまるでない。
欧米の政治思想の本なんかはそれこそニュートンの時代のとか普通に今でも重要でしょ。直接読まなくても現代語でまとめた書籍が存在するという意味でいらないと言っているのなら分かるが、そういう言い方をしちゃうと、そもそも必要な古典なんかひとつもなくなってしまうぞ？
お前のいう「役に立つ」の定義は何なんだ。「金になる」という意味ならそれこそ文化政策やステータスシンボルとしてでも十分日本の文化は役に立つことになるだろう。「過去の旧弊を断つために異文化を学ぶ」のであれば、「一般人」にとって英語が役に立つ例にはなってないよなあ。
君の言うステータスシンボルのような意味での「役に立つ」自体を俺は批判し否定してるんだよ。まやかしだってな。で、撤回したんじゃなかったか？ やっぱ食いさがってんじゃんｗｗ
一方で、海外のほとんどのライブラリのドキュメントは英語で書いてあるから、英語はとても役に立つなあ。
「才能職」（笑）がどんなものかは知らんが、学問的なトレーニングという意味での努力が役に立つ仕事というのが情報工学の分野の主流なわけで
うーん、でも君のFORTRANやC,C++についての言及のとんちんかんぶりを見てると、そのトレーニング（笑）とやらはどうも成果が出てなさげに見えるんだがなあ。つーかそれなりに本を読んでれば言わないようなことばっか言ってるよなあ君。
おやおや、「本物のエリート」がえらく縮小したね。MITはそのレベルの大学だというのなら、人口比からいって日本にもそのレベルの素質を持った人間は毎年千人単位でいることになるし、MITと同レベルの大学はほかにもいくつもあるから、もっとすごい数になるだろうね。だったら、欧米先進国様に丸投げして済む数ではないね。
えーと、そういう主張をしたいのならまずソースよろ。
で、それが本当だろうがそうでなかろうが、そもそも君の突っ込みはずれてる。俺の言ってるのは、ただの東大卒程度でエリートなんて呼ぶ必要ないだろ、ってことなんだが。毎年数百人も生まれるのに。
本当に新天地を切り開くようなエリートってのは、せいぜい数人程度だろ。その数人にどういう教育をするかと考えた場合、国内でまかなおうなどと無駄な縄張り意識を発揮するよりは、とりあえず世界トップレベルの大学に送り込めばいいんじゃないの、と。
教育課程を見直すとして、国を背負うほどのものでもない普通の東大生数百人のレベルをギリギリにチューンすることに金を使うよりは、普通の大学を出る普通の何万人のレベルを上げるほうが安上がりだし価値があるんじゃねえの、と。だから、「公教育の目的は平均と底辺を上げること」と何度も言ってるんだよ。
確かに、スパコンとかを用いた理論物理の一部の分野でFortranが主流になっている分野は存在することは存在するらしいな。
つか、スパコンの対応状況の問題でそういうのがある。多分俺が知ってた頃よりだいぶ減ってはいるだろうが。
だが、そうした一部の分野の傾向だけを捉えてFortranが主流だなんていうと大間違いだろ。
俺はFORTRANを主流だとは言ってないと思うがね。スタンダード（標準）だとは言ったが。主流と標準の違いは分かるよな？
さすがにまだ標準の座はC++に奪われたりはしてないと思うんだが。
ちなみにあらかじめ釘をさしておくが、LAPACKとかそういう既製品の数値計算ライブラリがFortranで書かれてるから云々などと言うなよ。
そうか、じゃあライブラリが何で書かれているかはとりあえず別の話にしようか。
でも、コアの計算部分がライブラリに分離されちゃうケースが増えると、ますます低水準処理がどうこういう意味がなくなるような。
C++と、お前さんが「数値計算の実習はFortranではなくCを用いましたが」と表現したCとで、実際どの程度パフォーマンスが違うと思ってるの、と聞いてるんだけど。どっちも同程度に低水準な処理は書けるぞ。
不完全な引用でごまかさないようにｗ正しく引用しなおしてあげよう。
お前さんが「君も一応理解してるようにC++やましてJavaでの数値計算は「出来ない話じゃない」程度のことで、向いているとはお世辞にも言えないだろ？」と表現したC++と、お前さんが「数値計算の実習はFortranではなくCを用いましたが」と表現したCとで、実際どの程度パフォーマンスが違うと思ってるの、と聞いてるんだけど。
と俺は書いたんだ。
「君も一応理解してるようにC++やましてJavaでの数値計算は「出来ない話じゃない」程度のことで、向いているとはお世辞にも言えないだろ？」という文章内での君のC++評価と、「数値計算の実習はFortranではなくCを用いましたが」という文章内での君のC評価の乖離について俺は質問している。
いや、多分Javaに引きずられてつい実際より悪く書いちゃったんだろうとは思うんだけどな。だったらそう訂正すればいいんだよ。それにJavaが遅いのは低水準が云々以前の問題だしな。
前にも書いて綺麗に見ない振りされたけど、それ言語の選択と無関係だよね。低水準処理云々とも別問題だし。
そうか、お前は俺のことをウヨだと思ってたわけか。そういう前提で下らん決めつけをしてきたのだと考えると全て辻褄が合うが。で、なんだね？俺は近代国家なんてフィクションだと思ってるから敢えて分類すれば極左なんだがね。ワールドカップと同じで、わかった上でフィクションに乗るから楽しいんだよ。わかる？俺から見れば近代主義者ってのは保守反動なんだよ。というわけでお門違いだったな。
……じゃあなんで食い下がってるんだ？
食い下がってんのはお前だろ。お前が俺のことを捏造した発言に基づいて馬鹿呼ばわりすることに対して異を唱えているだけであって、文化は役に立たないで構わんということは何度も言ったはず。
いや、俺が助け舟出してやってるんだぞ？
なあにが助け船だよ。お前が食わず嫌いする論点をこっちから避けてやってただけじゃないか。偏狭なドグマを信奉してるのはお前なんだよ。カルト信者と宗教論争しないのは定石だろ。
それをいうとそれこそ、お前の大好きな欧米先進国様の思想は宗教的価値と直結しているんじゃないのか？
学問的知識で一般人レベルで近代以前の文献を参照しなきゃならんようなものはないだろうし（あったらそれを指摘してくれ。一発で納得してやるから）。
文学研究とか歴史研究という分野を知らんのかねこの人は。それからいうまでもなく東洋哲学とか仏教学がある。え？なに？広義の文系学問ばっかりだって？気象学とか地震学でも過去の記録は見るよ。そうでなくたって、自然科学研究だって近代（あんたのいう近代と中世の境界線はどこだ。ルネッサンスかウェストファリア条約かフランス革命か）以前の文献を実際に参照することはないぞ。論文のリファレンスにニュートンだのライプニッツだのの著書を挙げる奴がたまにいるが、あれを実際に読んでるのは物好きだし、読まなければ理解できないなんてことはまるでない。
お前のいう「役に立つ」の定義は何なんだ。「金になる」という意味ならそれこそ文化政策やステータスシンボルとしてでも十分日本の文化は役に立つことになるだろう。「過去の旧弊を断つために異文化を学ぶ」のであれば、「一般人」にとって英語が役に立つ例にはなってないよなあ。
端的に言って才能職だな。人それぞれ立場が違うのは分かってるよ。古典によるハッタリや学閥が幅を利かせる業種だってあるんだろう。
「才能職」（笑）がどんなものかは知らんが、学問的なトレーニングという意味での努力が役に立つ仕事というのが情報工学の分野の主流なわけで、工学のイロハのイである線型代数すら理解しないほど努力不足なお前が情報工学の本流を理解していることはあり得ない。いい加減に思い上がりを捨てたまえ。
おやおや、「本物のエリート」がえらく縮小したね。MITはそのレベルの大学だというのなら、人口比からいって日本にもそのレベルの素質を持った人間は毎年千人単位でいることになるし、MITと同レベルの大学はほかにもいくつもあるから、もっとすごい数になるだろうね。だったら、欧米先進国様に丸投げして済む数ではないね。
ま、MITがそこまですごい大学だと思ってるとしたら、どう考えても妄想ですよそれは。だいたい年に数人なんてレベルの人間を組織的に指導できるわけなんかなくて、非常に優秀な指導教官がそういうことをすることができるだけなんだが、そのレベルにある（つまり、ある学問分野の世界的権威の）研究者なら日本にも大勢いると言っているんだよ。
でも触ったことなさげだしなあ。
たとえ使わなくても、FORTRANが数値計算用の言語としてスタンダードであり、その利点は別に低水準な処理がどうこうというのとは関係ない、ということはこの議論では抑えてないとダメだろ。
俺には研究者の知り合いもそれなりに大勢いるが、Fortranの話なんて一度も出たことがなかったんだが、あんたが余りにも自信たっぷりにいうもんだから調べてみたわ。確かに、スパコンとかを用いた理論物理の一部の分野でFortranが主流になっている分野は存在することは存在するらしいな。
だが、そうした一部の分野の傾向だけを捉えてFortranが主流だなんていうと大間違いだろ。というわけであんたの話はハッタリか、少なくとも視野が狭かっただけだと確信できた。もう結構。
ちなみにあらかじめ釘をさしておくが、LAPACKとかそういう既製品の数値計算ライブラリがFortranで書かれてるから云々などと言うなよ。
C++と、お前さんが「数値計算の実習はFortranではなくCを用いましたが」と表現したCとで、実際どの程度パフォーマンスが違うと思ってるの、と聞いてるんだけど。どっちも同程度に低水準な処理は書けるぞ。
当たり前だろ。C++はCの（ほぼ）上位互換なんだから。誰がそんなことを言ったかね。重たいクラスライブラリの厚い壁を通して、数値計算という比較的単純な処理をやる奴はセンスがないだろうし、自分の書いたコードが計算機のなかでどういう風に動くかというイメージを持っておけば見通しがよくなるだろ、とそれだけのごく常識的なことを主張してるんだが、なんでこれだけのことを言うために（しかもこのことは何度か繰り返して書いたはず）お前の揚げ足取りに延々と付き合わないといかんのだよ。馬鹿馬鹿しい。
お前様の気に食う視点から、お前様の脳内の模範解答と一言一句違わない答えを書かなければ馬鹿だのウヨだのと認定されないといかんのかよ。どんだけ頭がいいんですかね。
ので、その結果を貼ってみます。とりあえず、はてなブックマークが始まってから１ヶ月(2005/2/10〜2005/3/9,1033エントリ)の、ブックマーク数によるベスト１０を出しました。
ここで皆さんにお願いがあるのですが、今回のベストX以外にどういう観点でデータを抽出したら良いか（どういう一覧がほしいか）、コメントをいただけませんか？データは集めてみたものの、活用方法に困ってます。
====================
でした。
当時はまだ「有名サイトのトップページにとりあえず貼っておく」みたいな使われ方をしていますね。ブックマークをどう使うか、というスタイルを探していたんでしょうか。
「b:keyword:コンピュータ(330回)」「b:keyword:ウェブ(321回)」「b:keyword:一般(147回)」「b:keyword:はてな(77回)」「b:keyword:Google(67回)」「b:keyword:サイエンス(47回)」「b:keyword:blog(42回)」「b:keyword:ゲーム(41回)」「b:keyword:Internet Explorer(33回)」「b:keyword:はてなブックマーク(31回)」「b:keyword:RSS(30回)」「b:keyword:Microsoft(30回)」「b:keyword:JavaScript(29回)」「b:keyword:読書(28回)」「b:keyword:iPod(25回)」「b:keyword:firefox(25回)」「b:keyword:Apple(24回)」「b:keyword:ニッポン放送(23回)」「b:keyword:サービス(23回)」「b:keyword:音楽(20回)」
「b:t:web(88回)」「b:t:blog(65回)」「b:t:ネタ(59回)」「b:t:news(49回)」「b:t:はてな(42回)」「b:t:it(33回)」「b:t:hatena(33回)」「b:t:社会(30回)」「b:t:ニュース(28回)」「b:t:neta(27回)」「b:t:misc(26回)」「b:t:ajax(26回)」「b:t:tool(25回)」「b:t:software(24回)」「b:t:tips(23回)」「b:t:javascript(23回)」「b:t:ブログ(22回)」「b:t:まとめ(21回)」「b:t:livedoor(20回)」「b:t:google(20回)」
でした。当時から「ネタ」タグって多かったんですかね(タグやキーワードは現在の付与状況しか分からないので、当時の本当の状態が分からない)。
作りたいものがあるのなら本なんていらないでしょ。
まずどこかの入門サイトでさささっと基本を掴んで（一日で読んじゃいなさい）、
後は作りながらリファレンス(php.net)参照しながら作っていけばもう十分。
後はコード量というか時間が君を深みに連れて行ってくれる。
ちなみに大学院というフレーズがあったから書くんだけど、大学院にPHPなんていらないよ。WEB技術なんていらないよ。
学問で高みにのぼって行こうと思うならむしろ数学とか研究分野をやらなければならないはず。
その友達に言っておけ。WEB技術なんてそれぐらいにしておきなさいと。
オレに言ってくれ。増田なんていちいちチェックする価値なんてないんだと。
唐突に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だけ仲間外れにしてたわけですね。
はは。
あー、あー、あー。
これで終わりだよぅ。みんなわかったかな！？
コレ読んでもわからんやつはもう死ぬか、もしくはわからん用語について死ぬほど調べてもっかい読みなおしてみろこのド低のぅッ・・・ごふんごふん、このクサレ脳みそがぁ！！！！！！！！！！！！１１
