タグ

ブックマーク / kazu-yamamoto.hatenablog.jp (5)

  • Haskell(GHC)での軽量ユーザスレッドの実装方法 - あどけない話

    命令型言語の JavaRuby がユーザスレッドからカーネルスレッドに移行したのとは対照的に、関数型言語の Erlang や Haskell では軽量なユーザスレッドを提供することに成功しています。僕は、この違いが何から生じているのか理解したいと思っています。この記事では、これまで調べたことをまとめます。 軽量なユーザスレッドは Erlang が有名ですが、Haskell (GHC)でも利用できることを重ねて強調しておきます。Haskell の方が Erlang よりも速いようです。追記:フェアな比較ではないようなので、話半分で参照して下さい。 Rubyの場合 Ruby 1.8 まで提供されていたユーザスレッドは、軽量とは言えませんでした。その理由は、ユーザスレッドをコンテキストスイッチさせる際にスタックをコピーしていたからです。Rubyソースコード完全解説の第19章 スレッドによれ

    Haskell(GHC)での軽量ユーザスレッドの実装方法 - あどけない話
  • Haskell から見た node.js - あどけない話

    誤訳 以前、「サーバサイドJavaScriptのNode.js、最初はCやHaskellを検討し失敗。開発者ライアン・ダール氏へのインタビュー」という記事が twitter で話題になっていました。 ―― なぜJavaScriptを選んだのでしょう? ダール氏 実は最初は違いました。最初はC、Lua、Haskellなどで失敗していました。そんなときV8(Chromeが採用しているJavaScriptエンジン)に気がついて、やろうとしていることに対してJavaScriptが完璧な言語だと突然ひらめいたのです。 ただでさえ、Haskell は遅いと誤解されているのに、このような悪意さえ感じらえる訳だと、さらに誤解が深まりそうです。原文にはこう書かれています。 Dahl: Originally I didn’t. I had several failed private projects doi

    Haskell から見た node.js - あどけない話
  • Emacs補完候補の選択を便利に - あどけない話

    今話題のauto-complete.elを使ってみましたが、以下の点が使いづらく、使うのを止めてしまいました。 候補が最大10個しか出ない 10個以上の候補がある場合、次に打つべき文字が分らない バッファの最下部でメニューが表示されると、勝手にスクロールされる 個人的には、Emacsが提供する標準の Completion List モードを拡張する方がいいなぁと思いました。Completion List モードが使いにくいのは、以下の点です。 C-f/C-b/C-n/C-pはカーソルの移動であって、候補間の移動ではない RETで選ぶと、候補のリストを表示する前の状態に戻れない Emacs 22では、カーソルが他のバッファに行ってしまう Emacs 23では、元のバッファにカーソルが戻るが、余計なバッファが表示されたまま という訳で、これらを解決するコードを書いてみました。最後に付けているコ

    Emacs補完候補の選択を便利に - あどけない話
    Watson
    Watson 2008/11/19
  • プログラマの壁 - あどけない話

    プログラマに向いている人と向いていない人がいるそうです。 Jeff Atwood さんの「どうしてプログラマに・・・プログラムが書けないのか?」: プログラムを書ける者とプログラムを書けない者の間にある大きな溝についてはよく知られているが、プログラマの職に応募してくる人間は、すでにこの溝を飛び越えているものだとばかり思っていた。明らかにこれは妥当な仮定ではないらしい。プログラムを書けないプログラマの面接で時間を無駄にしないために、FizzBuzzスタイルのふるい分けが必要ということだ。 どんなことでも向き不向きはあるでしょうから、これには納得いきます。しかし、プログラマになれる人の中にも、溝があるようです。 Joel Spolsk さんの「Javaスクールの危険」: 私のささやかな経験から言わせてもらうと、伝統的に大学のコンピュータサイエンスのカリキュラムで教えられているもので、多くの人が

    プログラマの壁 - あどけない話
  • 偉大な習慣 - あどけない話

    「僕は、偉大なプログラマなんかじゃない。偉大な習慣を身につけたプログラマなんだ。」 --- Kent Beck 僕の信じた伝説 この一年間、あまりコードを書かずに、たくさんのを読み、勉強ばかりしていました。そして、自分がかなり時代に取り残されたプログラマであることが身に染みて分りました。 僕の信じていたプログラミングの伝説は、こんな感じです。 初期工程で完全な仕様を作れ 実際問題、完全な仕様なんて作れるはずがありません。仕様は変わります。また、時代の変化やユーザの要望の変化により、要求も変わります。ですから、仕様が変わってもよいように、実装に柔軟性を持たせないといけません。 効率第一 大切なのは、コードの分りやすさです。効率はよいが分りにくい大きな関数を書くのではなく、効率はやや悪いが分りやすい小さな関数を書くべきです。関数呼び出しは遅いという伝説もありますが、最近のコンピュータは高速で

    偉大な習慣 - あどけない話
  • 1