«前の日記(2007-02-14) 最新 次の日記(2007-02-16)» 編集

Matzにっき


2007-02-15 [長年日記]

_ [Ruby] YARV without 1.9

会社でRubyビジネスについて打ち合わせ。 詳細は書けないが。

で、その中で「Rubyに新しい機能(クラスローカルインスタンス変数とか)を求める人よりも、YARVが今欲しいって人の方が多いと思いますよ」という発言。

確かにそうだ。

もともと今年12月の1.9リリース宣言も、青木さんのそういう発言が発端だものな。 どうしたものかな。

  • YARVに新機能を追加するのはやめる。 すでに追加したものはrevert。 新機能追加はmatzruby(旧インタプリタに基づくなら)、 または新ブランチ(YARVに基づくなら)。
  • trunk(YARV)は現状のまま。新機能を追加しないブランチを起こす。 だれかがメンテナを引き受ける必要あり。

うーん、前者の方が現実的か。私が「2.0っぽいこと」から手を引くのは ありえないし(楽しくないから)。

来週の合宿で相談しよう。

_ 現代のソフト開発の生産性は1920年代の自動車産業並

まあ、それはそうだと思う。

もっとも、現代開発されているソフトウェアは 1920年代のフォードTよりもはるかに複雑だが。

しかも、この複雑さは今まで人類が取り扱ったことのないタイプの 複雑さのような気がするのは気のせいだろうか。

  • 物理法則の制約を受けない
  • 複雑さに理論的限界がない
  • 複雑さに工学的根拠がない
  • 変更が簡単で頻繁に要求される
  • 「正しい結果」が存在する

最後のものがなければ、 「小説」など芸術の分野に似たような複雑さが存在しうるのだが、 小説なら内部に少々矛盾があったり、伏線がいかされなくても たいして困りはしないものなあ。

_ Regular Expression Matching Can Be Simple And Fast

Rubyをはじめとして広く用いられている NFAと比較するとDFAはめちゃめちゃ速いぞ、という話。

まあ、それはそうなんだけど、DFAはバックリファレンスとか実現できないし、 マッチの挙動が異なっちゃうんだよねえ。

GNU grepは両方のエンジンを積んでDFAでも問題ないケースに限ってDFAを使っていると聞いてるけど。Rubyでもそうすべき?

_ [言語] RedSix perl6 implementation on ruby

RubyによるPerl6の実装。

完成度はまだまだだけど(テスト20%パス)、 やる人がいるという時点ですごいことだと思う。

_ [Ruby] Top 10 Ruby on Rails performance tips

Railsアプリケーションを高速化する10のアイディア。

多くはRailsに限定されないし、Webアプリケーション限定でないものもある。

しかし、RailsBenchの GCパッチってなんだ? 初耳だ。

どうやらGCログと環境変数によるGCパラメータの設定を許す パッチのようだ。欲しい人はいるかもしれないなあ。

本日のツッコミ(全2件) [ツッコミを入れる]
_ きむら (2007-02-22 00:41)

> GNU grepは両方のエンジンを積んで<br>現行バージョンはそうですけど、次では多分DFAを動的に構築する<br>ハイブリッド型になります。GNU sedがすでにそうです。<br>gawkもほぼそうなんですが、現状では旧来のDFAエンジン混載です。<br>DFAは(多分)ほとんどのPerl5拡張と相性が悪そうな気がするので、混載するにしても問題がありそうな…<br>あ、でもTclのエンジンはPerl5拡張を使えるけれども、動的にDFAを構築していくタイプだった記憶が。<br><br>すいません。きちっと調べます。

_ shiro (2007-02-22 04:19)

TclエンジンはGaucheのregexp書いたときに調べたら動的DFAでした。文字列をwchar_t[]に変換してからマッチかける必要があったので使うのをあきらめた記憶があります。

お名前:
E-mail:
コメント:
[]

«前の日記(2007-02-14) 最新 次の日記(2007-02-16)» 編集

track feed Matzにっき Creative Commons License This work is licensed under a Creative Commons License.