Rubyが今のPythonの地位にいない理由
_ Rubyが今のPythonの地位にいない理由 歴史のことなんぞなんも知らんけど、「技術的には今のPythonの地位はRubyでもよかったのに、そうならなかった」のが何故か、その理由を書いてみよう。僕はRubyの歴史なんて知らないし、以下の文章は全部、まるで見てきたかのように書いてますが、適当に書いたくせに何故か断言口調になっている怪文書の類いです。 https://twitter.com/mametter/status/741950239662170112 まめさんの書いた理由リストはどれも関係ない。いやカスってるけど。難しいというのも関係ない。 僕がRubyを知ったころ…最初に書いた通りRubyの歴史なんて知らないので、別に早くもないわけだけど…Rubyというのは全く使われていない言語だった。どっかの好き者がPerlの替わりに単純な処理に使って、「ウフ、美しくかけた、グフッ」とかつぶ
はじめてのにき(2008-08-02)
_ jsstr.c http://d.hatena.ne.jp/Gimite/20080802/1217647596 の予想は正しげ。 JSString * js_ConcatStrings(JSContext *cx, JSString *left, JSString *right) { if (!JSSTRING_IS_MUTABLE(left)) { /* We must copy if left does not own a buffer to realloc. */ s = (jschar *) JS_malloc(cx, (ln + rn + 1) * sizeof(jschar)); if (!s) return NULL; js_strncpy(s, ls, ln); ldep = NULL; } else { /* We can realloc left's space
はじめてのにき(2008-06-24)
_ VM http://natu.txt-nifty.com/natsutan/2008/06/vm_e3c7.html そうそうレジスタマシンのメリットってよくわからない ってのはたしかに。思いつくのは スタックポインタ動かすコスト (YARVしか知らんけど、たぶんリアル CPU のスタック動かすよりは少し高い) 型がわかる場合に型ごとに別のレジスタにつっこんどけばチェックがはぶけたり？ あたりかなぁ。 あと parrot のドキュメント見ると速いと主張してるな。 http://www.namikilab.tuat.ac.jp/~sasada/prog/parrot-intro.html#i-4-2 スタックの伸長の話は本当かなぁ。 全然知らんけど関数呼ぶ時に レジスタを退避する空間というのはなんにせよ必要なので、 関数呼び出し時にスタック的なものは伸びると思う。 んでまぁスタックマシン
よみかたあんけーと
気が向いたら以下の単語の読み方のアンケートに協力して下さい。 自分がその読み方をしてなくても読み方を 追加してもらっていいです。 読み方はなるべくひらがなで記述して下さい。 一つの IP で 1回だけ投票できます。 単語増やすのも歓迎です。 このシステムのソースコードは GPL2 で。 アンケートに答えてくれた人には ごほうびにマイノリティ度チェックを。 八朔
Dynamic Test Runner
説明 なんというかユニットテストは気軽に書きたいのに そのためにテストフレームワークだの覚えたりだの そのフレームワークに従うとやたらと色んなところに 関数宣言しなきゃいけなかったりだのするのは なんか本末転倒な気がします。 これはとても手軽(たぶん)なユニットテストツールです。 更新情報 060313. 0.0.3 。 バグ取ったり 。 051127. 0.0.2 。 バグ取ったり機能追加したり 。 051123. 0.0.1 。 作った 。 ダウンロード dtr-0.0.3.tar.gz 0.0.3 はひょっとしたら少しダメなところもあるかもしれません。 dtr-0.0.2.tar.gz これはなに。 CUnit などでテストを書く場合、 なんかをインクルードしてテストスートを登録したりして、 とにかくフレームワークに従ってテストを書く必要があります。 DTR はそういった手間いらずの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://shinh.skr.jp/binary/fsij061115/index.cgi?i=0
