Ruby2にいたる文法変更の一環。
{foo: 1, bar: 1}
のような式を許すようにした。その意味は
{:foo => 1, :bar => 1}
ChangeLogには私の名前でエントリしてあるが、実際には中田さんのコード。
それと、これはまだ実現できないけど、
method(a=>b, c=>d)
のような、「末尾の引数にハッシュを直接書ける」文法は今後使わないようにしてほしい。
これの意味を
method({a=>b, c=>d})
から
method(**{a=>b, c=>d})
に変更して、将来の名前付き引数に使うつもりなので。
追記:
警告した方が良いというakrさんのツッコミ。
確かにその通り。もうちょっと考えが煮詰まったらちゃんとコードでもアナウンスします。
だんだん原作から離れていく。いいのかっ。 下手すると原作より(私にとって)面白いという怪作になるかも。 あ、原作も好きだけど。
会議。乗せてもらったのでラクチン。道中ほとんど寝ている。先週の疲れが残っているのだろうか。
会議では運営方法について提案を行ってみたが、通じたかどうかは分からない。 いや、変更した方が良いと思っているのは私だけかもしれず、 変更した方がまずい側面もあるのかもしれないが。
それとは別にちょっとショックなこともあった。 嬉しいことも一緒にあったのだが(詳しく書けないのが残念)。
B000ES0OFY
今のデジカメに不満があるとすれば、
点だ。最近は光学式手ぶれ防止機構や高感度撮影が流行しているので、 いいのが欲しいところだ。が、うちにはすでに3台もデジカメがあるわけだし(今、２台はほとんど使ってないけど)、私は物欲番長ではないので、なかなか踏み切れないところだ。
が、そんなところで、光学式手ぶれ防止付き、10倍ズーム、高感度撮影(ISO800)も可能な B000ES0OFYがAmazonで妙に安い。
ちょっとほしいかも。
ジャストとの件は結審したし、 Panasonic製品にそれ以上の恨みはないので、買ってもいいかな。
後は大蔵大臣の許可さえ出れば。 ...でも、出そうにないな。
あと、レンズバリアがないらしいとの情報あり。どこで読んだんだっけ。 キャップはあんまり好きじゃないんだよなあ。
「休刊したオープンソースマガジンの記事を再利用したいから 承諾してほしい」というメールを頂いて、 「いいですよ」と返事したら、数時間後に公開されていた。
素早い。ちょっと古い記事だが まあ、人間の性質はそんなに変わるものじゃないから。
なんか最近あちこちさすらっているような気がするDebianの「-ianの方」、 Ian MurdockをSunが雇用したという話。
Sunのオープンソースに対する真剣さを表している、のかな？ 「チーフ・オペレーティング・プラットフォーム・オフィサー」ってなにするんだろう？
OSSの最大の利点はベンダーロックインの回避である、という話。 「普通の人」にも伝わる書き方だと思う。
RailsCastの紹介。 スクリーンキャストってインパクトあるよね。
言語でもそういうのやるべきなのかな。 「Emacsとirbを駆使してRubyプログラミング」とか。
春分の日でお休みなので、 下の二人を連れてフォーゲルパークへ。 鳥たちをみて喜んでいた。
モモイロペリカンがけっこう頑張って芸をしていた。 頭、いいのね。そうとう大きい(羽を広げると1.5m以上ありそう)が、 まだ生後10ヶ月というのも驚き。
しばらく前に献本していただいていた本を読む。
しばらく前に言語探訪で紹介していたりするのだが、 こうやってまとめて読んでみるとかなり知らないことが多い。
「ビット構文」とか、pack/unpackより便利かもしれない。 あと、多重代入の代わりにパターンマッチとか。
ただ、文法はちょっと分かりにくい。 よくわからない句読点のルールとか、endとか。
単一代入しかない関数型言語というのは 「普通の言語」とは、かなり異なったプログラミングスタイルを要求するが、 その故に便利な点も数多くあるなあ。副作用がないから プロセスが遠慮なく中断できる点とか。
しかし、改めて考えてみると Erlangってば、参照透過性はないし、 静的型はないし、関数型言語である必要はないのではないか。
Erlangを真に特徴づけているのは、
ではないだろうか。他のものは目立つけど実はそれほど重要じゃない。
アクターモデルがあるから、並列プログラミングが簡潔に記述でき、 値がimmutableであるから、「オブジェクトの状態」で悩むことがない。 オブジェクトのアイデンティティが重視されないから、 メモリ空間を超えて値を伝搬しても影響がない。
おまけに(GCの)実装としてはライトバリアが要らなかったり、 循環参照がないことも保証されるから、リファレンスカウントでも十分だったりするのもありがたい。
としたら、たとえばRubyとそっくりな外観で 値がすべてimmutableな言語があったとしたら、どうだろう。 関数型というパラダイムの代わりにオブジェクト指向というパラダイムを提供する Erlang的な言語。
文字列や配列についてはさほど問題はないだろう。 Pythonをはじめ文字列がimmutableな言語は珍しくないし、 配列も(一部の「容器」として使っている場合以外は)大丈夫。
問題になりそうなのは、 ハッシュやオブジェクトである。 これらが状態を持たない、というのはかなりプログラミングスタイルに変革を要求しそう。
そもそも書けるんだろうか。 入出力とかはLazyなSequenceとして扱うんだろうか。
Ruby on Railsを使っている有名企業。
あまり公表はされてないが筆者(Obie Fernandez)の知ってるのでは、他に
もある。