Matzにっき

_ [Ruby] 第11回　オブジェクト指向言語Ruby

島根大学講座「情報と地域〜オープンソースと地域振興」の第11回。

40人くらいいたかなあ。NHK松江放送局の人も来てたけど、 これいつの日か放送されるのかしら？

ま、情報を専門としない学生も半分はいるようなので あまり難しい専門用語などは使わないように。 途中、Rubyの文法を解説するスライドも用意していたのだが、 聴衆の顔つきを見る限り、ついていけなそうだったのでその辺はパス。

反省すると、抽象的な話が多くて、辛そうにしている人がいたような。 もうちょっと具体的な例を持ち込むべきだったかも。 たとえば、コードの簡潔さの話をしている時には、 簡潔なコード例とか。

とはいえ、もっとも重視したい「気分」や「ノリ」は視覚化できないのが痛い。

次回は実際にRubyを使った演習を行うそうだけど、 なるたけ多くの人がついていってほしいなあ。 2回ほどRubyについて学んだ後は、前田くんによるRails入門。

考えてみると結構ぜいたくな講義だよな。

_ [言語] Useless Factor: The incomplete, would-be Unicode implementor's guide

スタックベースの言語FactorにおけるUnicodeの取り扱いについて。

かなりちゃんと調べていることがわかる。 で、内部表現としては固定長であることを重視してUTF-32を採用することにしたとか。 Unicodeに拘泥する限り、ある程度妥当な選択だと思う。

しかし、Factorでは将来codepoint単位ではなく、 grapheme(複数codepointから構成される「文字」)を取り扱うことを 想定しているようなんだけど、それって結局は可変長文字を取り扱わなくちゃいけない ってことじゃないんだろうか。それだったら内部表現にもUTF-8で十分のような。

ちなみにRubyでは、

• 内部エンコーディングはステートレスならどんなものでも選択可能
• (デフォルトの)UnicodeハンドリングはUTF-8
• UTF-16やUTF-32も扱えるようにしたい
• けど、スクリプトはASCII互換である必要がありそう
• ということはUTF-16やUTF-32のリテラルが書けないので大変そうだなあ

というレベル。graphemeに関しては、デフォルトでは扱わない。 けど、graphemeを扱うようなエンコーディングハンドラを書くことは可能だと思う。

_ オープンソース/C言語に学ぶ「ソースコードの読み方」：ITpro

ソースコードの読み方を身に付けることは重要だよね。

で、正直、ここ数日、こうやって自分の文章を読み返す機会が立て続いているわけだが、 実は私は自分の書いた文章がとても好みだということが実感できた。 自分の好きなように書いた文章だから当然だ、という気もするけど、 なんかナルシストみたいでイヤという気持ちも同時にある。

_ FPN-格差社会で生き残る為の５つの能力

「生き残るための」というよりは「良いデザインのための」という印象もあるが。 で、その5つの能力は以下の通り。

1. デザイン力
2. 商品・サービスの物語力
3. 新コンセプト構築力（新たな組合せを創造する力）
4. 共感力
5. 遊び心

偶然ながらRubyのデザインにおいて(結果的に)強調されている点とかなり似通っている。 言語そのものにはあまり「遊び心」はないような気がするけど。 コミュニティ(の参加者)にはたっぷりありそうだ。Poignant Guideとか。

_ [Ruby] christopher baus.net | 2007-06-02 | Rails is written in the wrong language

DHHが語る以下の言葉は、RubyというよりもむしろPythonの思想を連想させる。 ということは、RailsはRubyではなく、Pythonで書かれるべきではなかったか、という話。

Decisions are bad.

Because decisions take up your brain power, and it requires brain cycles to consider which or the other.

The more decisions you can take out of the whole the thing, the more brain power you free up to consider the really important things.

That's of course how this leads to simplicity. It leads to simplicity in the fact that it is not even something you think about anymore.

Constraints are liberating.

It [Rails] takes a stand on lots of issues.

If you design a new schema and you want to use composite primary keys you're insane. And basically if you want to indulge in insanity it should hurt. It shouldn't be a walk in the park to be insane...

うーん、どうだろうか。Railsはopinionated softwareと呼ばれる通り、 「私の言うことに従えば楽できるよ」と呼びかけてくるタイプのフレームワークだ。 しかし、そのクレージーな実装のためには open classみたいな機能が使いやすい状態で存在している必要があったんじゃないかなぁ。

つまり、opinionated frameworkを実現するためには、 それを実装する言語自身はopinionatedであるよりは、 むしろ上位層のopinionを受け止める柔軟さ(悪くいえばいいかげんさ)が 必要だったんじゃないかと。

Larry Wallの言うところの単純さと複雑さの関係と似ているよね。 言語が単純だとソリューションが複雑になるというアレ。

だから、Lisp on Railsは可能だったかもしれないけど、 Python on Railsは無理だったと思う。

とはいえ、DjangoとかTurboGearが頑張っているという話を聞くと、 まあ、そんなに「無理」と断言することもないのかもしれない。 聞くところから想像すると、やはり、Djangoとかちょっと「Rails的」ではないようだけど(悪いことではない)。

_ [言語] jessenoller.com - “Too many ’self’ in python.That’s a big flaw in this language.”

「selfが多すぎるのがPythonの欠点だ」と言われるけど、 なんでselfがそんなに嫌われるのかがわからない、という話。

まあ、ある言語に慣れ親しんでくると、その言語でもっとも頻出するものが、 意識下にもぐりこんでだんだん認識されなくなってくるような傾向があるのかもしれない。

• Lispの括弧
• Pythonのself
• Rubyのend
• Perlの$@%{}/

そう言われればそんな気がする。ゲシュタルト問題なのかもしれない。

とはいえ、今回も参照されている Zen of Pythonのひとつ「Explicit is better than implicit(明示は暗黙に勝る)」には反対だ。 明示的な記述は簡潔ではないので、「Succinctness is Power(簡潔さは力)」と矛盾する。

ふたつの原則のうち、どちらかを選べと言われたら、(私にとって)答えはひとつだ。 私の視点からはこの原則こそが「Pythonの最大の欠点」だと思う。

同意しない人は多そうだけど。

_ [Ruby] ［動画］うまくやればたくさんのプログラマはいらない − ＠IT情報マネジメント

えー、「たくさんのプログラマはいらない」なんて言ったっけ、 と思ったけど、どうやらほんとに言ってるようだ。 アルコールは入ってないけど、てけとーに放言しているからなあ、この時は。

一般論としてではなく「という局面もある」ということで、受け止めていただきたい、ぜひ。

とはいえ、「生産性重要」というのは本当。

_ 嘘か誠か？元社員が明かすグーグルの職場環境と待遇:ニュース - CNET Japan

別にフツーだと思うけど？ というか、このリークがMicrosoftから来たということを考えると 「Googleは理想郷ではないよ」ということが言いたいのかもしれない。 が、そんなのは当たり前で、勝手に妄想を膨らませる方が悪い。

むしろ、リーク元のMicrosoftの職場環境と待遇を考えると どうなのか、と思う。 特に私にとって重要なオープンソースソフトウェア開発者としての暮らしやすさについて。

で、その観点から考えると私は絶対にMicrosoftでは働きたくない。 私にとってGoogleは理想郷ではないけれども、Microsoftは...ちょっと...(言えないことがあるらしい)。