タグ

ブックマーク / blog.yugui.jp (9)

  • オープンクラスとVisitor - 世界線航跡蔵

    RDToolを弄ってたら久々にRubyでVisitorパターンを見た。 起源の古いライブラリではVisitorも見るけど、最近のRubyライブラリではあまり多くない気がする。 そう言えばVisitorパターンは GoF には、「継承階層への追加を困難にするかわりに振る舞いの追加を容易にする」と書いてある。 継承階層のノードに応じて様々な挙動をするのは来は多態性の役目だ。ところが、Visitorパターンではメソッドのシグネチャ自体を変えることによりノードを区別する。ノードを追加するにはVisitorの提供するインターフェースに新しいメソッドを追加しなくてはならないので、追加は困難となる。 一方、違う振る舞いをしたければ違うVisitorを渡せばよい。通常は違う振る舞いをしたかったら継承階層に新たにメソッドを追加しなくてはならなくて、これが再コンパイルをもたらすような言語では巨大な階層にメソ

    オープンクラスとVisitor - 世界線航跡蔵
  • C/C++向け多倍長整数資料を探している人のためのガイド - 世界線航跡蔵

    多倍長整数の解説執筆がいつまで経っても進展しないので、お詫びの印にガイドを書いてみる 実装が欲しいよ派(実用主義派) お金は掛けたくないよ派 GMPとか、Mintはどうでしょうね。前者は開発者もユーザーも多いのでその点で信頼性が期待できますし、かなり速いです。後者は、x86限定ですが、ドキュメントも日語ですし分かりやすく、設計上も使いやすい感じです。作者の苫米地聰さんは数体篩い法の実装などで知られる、計算実験に関してはかなり凄い人です。 あるいは、いっそPythonインタプリタやGaucheを埋め込んでしまうのはどうでしょうね。どちらもCプログラムに埋め込み易く書かれていますし、元来は汎用のスクリプティング言語ですから、アプリケーションにマクロ言語機能も付けられるというおまけがあってお得な感じです。アプリケーションのマクロ言語としてはRubyは最高と思うのですが、如何せん、現Ruby実装

    C/C++向け多倍長整数資料を探している人のためのガイド - 世界線航跡蔵
  • Understanding Go compiler tools (2) - 世界線航跡蔵

    Today I read memory management in go compiler. There are go.y , y.tab.[ch] , lex.c and other files in src/cmd/gc/ directory. It seems that the go compiler has a lexical analyzer written by hand and a syntax parser generated by yacc ( bison ). lex.c also contains the main function for the compiler. Here are the head lines of main function: int main(int argc, char *argv[]) { int i, c; NodeList *l; c

    Understanding Go compiler tools (2) - 世界線航跡蔵
  • (´-`).。oO 人はLispに戻ってくるんだよ - 世界線航跡蔵

    角谷さんとこ 経由で見に行った、「 2009年あたり LISP がはやる? 」。いい味だしてます。 確かに、ECMAScriptのSpecificationが出たときはおぉっと引き込まれたものね。で、「JavaScriptって、みんなが思ってるようなつまらない言語じゃないよ」と言い続けて、でもなかなか分かって貰えなかったりした。互換性問題もあってなかなか使う機会もなく。今年に入って当に「Ajaxで解禁」された感じだ。 もっとも、私の場合は仕事格的にJavaScriptを使うことができたのはAjaxじゃなく、IEツールバーの開発が最初なのだけれど。このときは、どうせIE5以降(for Win32)限定のものだからってことで、JavaScript処理系をかなり絞り込むことができ、おかげでクロージャーも高階関数も気楽に使ってさくさく開発が進んだ。 そして、インテリジェントな情報検索処理系を

    (´-`).。oO 人はLispに戻ってくるんだよ - 世界線航跡蔵
  • Lisperから見たRuby - 世界線航跡蔵

    Lisperから見たRubyの印象は、もしかしてC++使いから見たDのそれと同じじゃなかろうか。 とりあえず、基的なテクニックに関しては、対応する文法が組み込まれてるなーと。 でも、自分の足を撃つのがえらく困難そうだなーと。窮屈だなーと。 このテクニックは対応する文法すらないじゃないか。これ便利だったのに! そもそも、ちょっとしたテクニックを覚えれば解決できる問題に、どうして専用の文法を定義するのかなーと。

    Lisperから見たRuby - 世界線航跡蔵
  • Rubyの呼び出し可能オブジェクトの比較(1) - 世界線航跡蔵

    Rubyにはコード片を表すオブジェクトが複数ある。 Method , UnboundMethod , Proc である。 Continuation は少し違うけど、実行コンテキストを記憶しているオブジェクトという意味では近いものがあるか。『 Ruby Way 』にはこういういろいろがあることについて「驚くほどのことではありません」と書いてあるけれども私は驚いた。で、これらが微妙に違うのだ。困ったもんだ。いや、便利なのかもしれないが。 それで今回はこれらの概要を眺めてみたいと思う。 普通のメソッド defでメソッドを定義するのが一番普通だやな。 class C def greeting(arg) puts "C#greeting reveived #{arg}" end def iterator yield 'iterator 1st' yield 'iterator 2nd' yield

    Rubyの呼び出し可能オブジェクトの比較(1) - 世界線航跡蔵
  • ファーストクラスオブジェクトとしてのメソッド - 世界線航跡蔵

    Rubyと高階関数 : 関数そのものがファーストクラスではない やー、Rubyのメソッドはファーストクラスですよ。返り値にできて、変数に格納して演算できて、引数にできるという意味では。 確かに、RubyPythonJavaScriptやSchemeに比べると高階関数を陽に使うプログラミング *1 は不格好になる。Pythonなら簡単なのに、 bound_function = obj.hoge bound_function(arg1, arg2, arg3) Rubyは余計なメソッド呼び出しがくっついて不格好だ。 method = obj.method(:hoge) method.call(arg1, arg2, arg3) 私もこの点が気にくわなくてまつもとさんに「メソッドがファーストクラスだったらいいのに」と言ったことがある。でも、まつもとさんの考えではすでにファーストクラスというこ

    ファーストクラスオブジェクトとしてのメソッド - 世界線航跡蔵
  • プログラミング言語の進化の方向 - 世界線航跡蔵

    セキュリティ&プログラミングキャンプ のBoFで、笹田さんがやってたセッションで話したことがある。言語の進化はベストプラクティスの取り込みにある、と。 ベストプラクティス取り込みの歴史 計算可能である事柄を計算するだけが問題であるなら、チューリング完全な言語なら何でも良いということになるし、不完全な言語は出る幕すらない。ラムダ計算からの自然なマップを考えるならS式で書いて何か実行すれば良いんだし、最小のプリミティブから出発するのが目的ならLazy Kなんかもいいかもしれない。 でも、工学的要請からは、計算可能関数が等しく計算の対象となるわけではない。そして、ある種の計算の傾向、パターンに対して「こうすればいい」「こう考えればいい」「こう設計すればいい」というベストプラクティスが生まれてくる。プログラミング言語の歴史を眺めていると、経験の中から立ち現れるベストプラクティスを取り込んだものが多

    プログラミング言語の進化の方向 - 世界線航跡蔵
  • Javaと中二病 - 世界線航跡蔵

    java.lang.だのjava.io.みたいな古いAPIは「これからオブジェクト指向な新しい世界が始まる」と気負いすぎている割にマーカーインターフェースとか痛々しいことをやっていたりする。その辺は『 Effective Java 』で、中の人自身が「あちゃー。いたた」と反省を述べている。というわけで、このJavaAPI設計における良書でもあるわけだ。 この痛々しいAPIを「 中二病 的インターフェース」と呼ぶならば、その後に台頭した"えんたーぷらいず"な重厚長大APIはさしずめ「 高二病 的インターフェース」だろうか。 昨今のSeasarの活動で成し遂げられ、また羽生さんが「これからようやくJavaが始まる」と言っているのはこのような多重に痛々しい過去を受け入れ、乗り越えてJavaが成人するということなのかもしれない。でも、乗り越えそこなうと「 大二病 」への道なので気をつけよう。

    Javaと中二病 - 世界線航跡蔵
    koko1000ban
    koko1000ban 2007/11/15
    ”「業務システムは結局は画面ベースで、フロントにオブジェクト指向はいらない」というのは正当”
  • 1