ときどきの雑記帖 濫觴編

最新ページへのリンク
目次ページへのリンク

一つ前へ 2011年10月(中旬)
一つ後へ 2011年11月(上旬)

ホームへ

2011年10月31日

■_

ベイスターズはまだ話の決着がついてないというw

うーむ今ひとつ見栄えがしないチャートじゃ喃 ○| ̄|_

■_ Common Lisp

が、入門には一番いいのではないか。という話。

a CONS is an object which cares: Common Lisp is the best language to learn programming


October 30, 2011

Common Lisp is the best language to learn programming

Now that Conrad Barski's Land of Lisp (see my review on Slashdot) has come out, I 
definitely think Common Lisp is the best language for kids (or anyone else) to start 
learning computer programming.

Conrad Barski の Land of Lisp が出版されて、わたしは Common Lisp は子供(あるいは
そのほか誰でも)がコンピュータープログラミングを学び始めるのに最良の言語ではないか
と確信しています。

Between Land of Lisp, David Touretzky's Common Lisp: A Gentle Introduction to Symbolic 
Computation (really great book for people new to programming, available for free) and 
The Little LISPer (3rd edition, editions four and up use Scheme) you have three really 
great resources to get started.

Land of Lisp のほかにも、David Touretzky の
Common Lisp: A Gentle Introduction to Symbolic Computation
(プログラミング入門者にとって本当に great な本で、無料で入手できます)
と
The Little LISPer (第三版。第四版以降はSchemeを使っています) があり、
入門するのに really great なりソースがみっつもあるのです。


Lisp's syntax is a great advantage because it is so simple to learn and has so few 
special cases. The interactive, iterative development style and real late-binding 
means you can build programs in parts and add to them as you go. The presence of real 
metaprogramming means you always have the ability to look at any part of your program 
and its state to find out what it's doing/what's wrong. The HyperSpec and Common Lisp 
The Language are two of the best programming language reference manuals ever written.

Lisp の構文は大きなアドバンテージです。なぜなら学ぶのにとてもシンプルなものであり
特殊なケースがほとんどないからです。対話的な、iterative な開発スタイルと
本物の遅延束縛によってあなたはプログラムをパーツごとに構築するのが可能となり、
それを思うように組み合わせられることができます、
本物のメタプログラミングの presence はあなたが自分のプログラムの任意の部分を
調べる能力と、正しく動いているのか間違っているのかを見分けられる能力とを
常に持っているということを意味しています。
HyperSpec と Common Lisp The Language はこれまで書かれたプログラミング言語の
リファレンスマニュアルとして最良の二つです。


The best parts about Common Lisp are that it's a language that's hard to outgrow and 
that it makes difficult things easy. One of the chapters in Land of Lisp explains HTTP 
and HTML and has you build a basic web server. That chapter is only 15 pages! There's 
tons of ideas in the language, and because you're not restricted to a particular 
programming paradigm, you're always discovering better ways of doing things and 
developing a personal style.

Common Lisp について最良の部分は、肥大しすぎにくいということと
難しいことを簡単にするというところです。
Land of List の章のひとつで HTTP と HTML を説明しているところがあって
あなたはそこで基本的なwebブラウザーを作ります。
その章はたったの15ページしかありません。
この言語にはやまほどのアイデアがあり、
特定のプログラミングパラダイムに制限されないので
あなたは常に、なにかを行い個人的なスタイルを develope する
最良の方法を見つけ出せるのです。

Posted by Vladimir Sedach at 15:00

■_

■_

むー、あと二つくらいはいきたかったんだがなあ

■_

そして十一月

2011年10月30日

■_

だるーん

ああ、あれとかあれとかあれとかやるつもりだったのに!

■_

PST で10月30日一杯、オライリーが一部の電書を半額にしているそうです。

Dennis Ritchie Day - O'Reilly Radar

Tim O'Reilly

Dennis Ritchie Day

On 10/30/11 let's remember the contributions of computing pioneer Dennis Ritchie.

by Tim O'Reilly

Sunday, October 16 was declared Steve Jobs Day by California's Governor Brown. I admire
Brown for taking a step to recognize Jobs' extraordinary contributions, but I couldn't
help be struck by Rob Pike's comments on the death of Dennis Ritchie a few weeks after
Steve Jobs. Pike wrote:


    I was warmly surprised to see how many people responded to my Google+ post about 
    Dennis Ritchie's untimely passing. His influence on the technical community was vast, 
    and it's gratifying to see it recognized. When Steve Jobs died there was a wide lament 
    — and well-deserved it was — but it's worth noting that the resurgence of Apple 
    depended a great deal on Dennis' work with C and Unix.

    Dennis Ritchie の untimely な死去についてのわたしの Google+ への投稿に対するとても
    多くの人の反応を見て、わたしは彼の technical community における影響は非常に大きく、
    and it's gratifying to see it recognized.
    Steve Jobs が死去したとき、
    there was a wide lament   -and well-deserved it was -
    しかし、Apple の復活は C と Unix による Denis の成果に大きく依存したものなのです。


    The C programming language is quite old now, but still active and still very much in use.
    The Unix and Linux (and Mac OS X and I think even Windows) kernels are all C programs.
    The web browsers and major web servers are all in C or C++, and almost all of the rest of
    the Internet ecosystem is in C or a C-derived language (C++, Java), or a language whose
    implementation is in C or a C-derived language (Python, Ruby, etc.). C is also a common
    implementation language for network firmware. And on and on.

    C というプログラミング言語は今となってはとても古いものですが、今日なお非常に広い範囲で使わ
    れ続けています。Unix や Linux (そして Mac OS X。さらに Windows もそうだとわたしは思ってい
    ます) のカーネルはすべて C で書かれたものです。web ブラウザーや主要な web サーバーはすべて
    が C か C++ で書かれているし、Internet ecosystem (インターネット生態系) の残りすべては C
    か C から派生した言語 (C++ や Java) で書かれていますし、さもなくば C や C から派生した言語
    で記述されている言語 (Python、Ruby などなど) で書かれています。C はまた、 ネットワークのファ
    ームウェアの実装に一般的に使われている言語でもあります。And on. and on.

    And that's just C.

    Dennis was also half of the team that created Unix (the other half being Ken Thompson),
    which in some form or other (I include Linux) runs all the machines at Google's data
    centers and probably at most other server farms. Most web servers run above Unix
    kernels; most non-Microsoft web browsers run above Unix kernels in some form, even in
    many phones.

    Dennis はまた Unix を作り出したチームの半分でもあります(もう半分は Ken Thompson です)。
    Unix は Google のデータセンターにあるすべてのマシンで動いているし、おそらくは他の
    server farms のほとんどでもそうでしょう。web サーバーの大半は Unix カーネル上で動いて
    います。Microsoft のものでない web ブラウザーの大部分は何らかの形でUnix カーネル上で
    動いています。それは多くの電話(携帯電話?) であってもそうです。


    And speaking of phones, the software that runs the phone network is largely written in C.

    今電話について触れましたが、phone network で実行されているソフトウェアの大半は C で書かれたものです。

    But wait, there's more.

    でもちょっと待ってください。まだあります。

    In the late 1970s, Dennis joined with Steve Johnson to port Unix to the Interdata. From
    this remove it's hard to see how radical the idea of a portable operating system was;
    back then OSes were mostly written in assembly language and were tightly coupled, both
    technically and by marketing, to specific computer brands. Unix, in the unusual (although
    not unique) position of being written in a "high-level language," could be
    made to run on a machine other than the PDP-11. Dennis and Steve seized the opportunity,
    and by the early 1980s, Unix had been ported by the not-yet-so-called open source
    community to essentially every mini-computer out there. That meant that if I wrote my
    program in C, it could run on almost every mini-computer out there. All of a sudden,
    the coupling between hardware and operating system was broken. Unix was the great
    equalizer, the driving force of the Nerd Spring that liberated programming from the
    grip of hardware manufacturers.

    70年代の終盤、Dennis は Steve Johnson と共に Interdata への Unix の移植に参加しました。
    From this remove it's hard to see how radical the idea of a portable operating system was;
    そのころの OS は大部分がアセンブリ言語で書かれ、技術的にもマーケティング的にも
    コンピューターのブランドを specific するためにそれと固く結びついていました。
    “高水準言語”で書かれた unusual (ただし unique ではない) な位置にあった Unix は PDP-11
    以外のマシンでも動作するよう作ることが可能でした。
    Dennis と Steve は機会を掴み、そして1980年代の初めまでに
    基本的には世にあったすべてのミニコンピューターに
    その時点ではまだオープンソースコミュニティと呼ばれてはいなかったコミュニティによって
    Unix は移植されていました。
    それはつまり、わたしのプログラムが C で書かれていれば
    世にあったほとんどすべてのミニコンピューター上で実行できたということを意味します。
    All of a sudden,
    ハードウェアとオペレーティングシステムのカップリングは壊れたのです。
    Unix は great equalizer であり
    ハードウェアのmanufacturers の grip からプログラミングを自由にした
    Nerd Spring の driving force でした


    The hardware didn't matter any more, since it all ran Unix. And since it didn't 
    matter, hardware fought with other hardware for dominance; the software was a given. 
    Windows obviously played a role in the rise of the x86, but the Unix folks just 
    capitalized on that. Cheap hardware meant cheap Unix installations; we all won. All 
    that network development that started in the mid-80s happened on Unix, because that 
    was the environment where the stuff that really mattered was done. If Unix hadn't been 
    ported to the Interdata, the Internet, if it even existed, would be a very different 
    place today.

    ハードウェアはもはや重要ではありません。なぜならすべてのハードウェアで Unix が走るからです。
    さらに言えば、ハードウェアはほかのハードウェアと与えられたソフトウェアをめぐって争いをするからです。
    Windows は明らかにx86の興隆に一役買いました。しかし Unix folks はそれを capitalize したのです。
    安価なハードウェアは安価な Unix のインストールを導きます。われわれは勝利したのです。
    80年代中ごろに始まるネットワーク開発はすべて Unix 上で行われました。
    それは本当に重要なことが行われた環境が Unix であったからです。
    もし Unix が Interdata に移植されていなかったら、
    そしてそれでも Internet が存在していたとしたら、
    今日のそれとは非常に異なるものであったでしょう。

    I read in an obituary of Steve Jobs that Tim Berners-Lee did the first WWW development
    on a NeXT box, created by Jobs' company at the time. Well, you know what operating
    system ran on NeXT's, and what language.

For myself, I can attest that there would be no O'Reilly Media without Ritchie's work. 
It was Unix that created the fertile ground for our early publishing activities; it 
was Unix's culture of collaborative development and architecture of participation that 
was the deepest tap root of what became the open source software movement, and not 
coincidentally, much of the architecture of the Internet as well. These are the 
technologies I built my business around. Anyone who has built their software or 
business with knowledge from O'Reilly books or conferences can trace their heritage 
back to Ritchie and his compatriots.

わたし自身の話をすると、Ritchie の成果がなかったら O'Reilly Media もあり得なかったでしょう。



I don't have the convening power of a Governor Brown, but for those of us around the 
world who care, I hereby declare this Sunday, October 30 to be Dennis Ritchie Day! 
Let's remember the contributions of this computing pioneer.

わたしには Govnor Brown ほどの convening power はありませんが、

わたしはここに、10月30日を Denis Ritchie Day とすることを宣言します!

P.S. Help spread the word. Use the hashtag #DennisRitchieDay on Twitter and Google+


© 2011, O'Reilly Media, Inc.

(707) 827-7019(800) 889-8969

All trademarks and registered trademarks appearing on oreilly.com are the property of their respective owners.


■_

■_ ホンネとタテマエ

ちと違うか。

The Codist

Objects in the Job Description May Be Fuzzier Than They Appear
Published: 10/29/2011

Look for a job in most places involves reading a lot of job descriptions. Once you get 
a job you usually find out that the description never matches the actual work. Even 
worse is reading a job description for your replacement - you wonder how you ever did 
all of that.

Eventually you begin to understand job-description-speak and being a good engineer you 
figure out what the coded words mean. It's like reverse engineering, except there was 
no engineering to speak of at the start.

   1. Great work environment (素晴らしい職場環境)

      We give you a chair to sit in and we expect you to sit there for 10 hours a day or more
      わたしたちはあなたに椅子を一脚提供します。
      一日に十時間以上そこに座っていることをわたしたちは期待しています。

   2. Minimum Required Skills (要求されるスキルは最低限)

      You must know everything there is to know about everything, including stuff we no
      longer use and stuff that hasn't been invented yet

      あなたは知っておくべきことはすべて知っていなければなりません。
      それにはわたしたちがもはや使っていない技術やまだ発明されていない技術も含まれます。

   3. Compensation: Not Specified (報酬)

      We want you to go through our 24 hours of interview hell before we tell you how
      little the salary is

      給与が以下に少額であるかを伝える前に、あなたにはわたしたちによる24時間のインタビュー地獄
      を受けてもらうことを要求します。

   4. Translate business requirements and functional specifications into software and
      suggest innovative solutions to business problems/processes that leverage technology
      to provide marketing differentiation, performance improvements, and better user
      experiences


      We're hiring you to write programs
      わたしたちはプログラムを書かせるためにあなたを雇いました。

   5. Follow relevant coding standards
      適切なコーディング標準に従います

      We don't have any but maybe you know some? Or possibly we prefer style over substance

      わたしたちはそういったものを一切持っていませんが、あなたは何かしら知っているでしょうか?
      さもなければわたしたちは substance 以上の style を良しとします。

(略)

I could go on and on, reading job descriptions should be a professional sport. But I'd 
rather work as a programmer writing iOS or OSX apps than read a description for one.

Copyright © 2007-2011 Andrew Wulf Mail 

4番なにこれ…(^^; 元記事には40番まであります。

■_ 正規表現

これ、「困難」どころか「不可能」だと思うんですけど きちんと「証明」できるでしょうか? …ってどうすりゃいいんだろう

Perlの正規表現について | OKWave

Perlの正規表現について質問です.

■質問
aaa bbb
aaa bbb ccc "ddd"
aaa bbb ccc "ddd eee"
aaa bbb ccc ddd eee "fff ggg hhh iii"

というような,文字列が書かれているファイルがあるとします.

※ダブルクォーテーションが無い行もあります.
※ダブルクォーテーション内のスペースの数は,行によってそれぞれ異なります.

これを,ダブルクォーテーションの中にあるスペースだけ
アンダーバーに置換する場合の正規表現を教えて下さい.

つまり,下記の出力にしたいです.
aaa bbb
aaa bbb ccc "ddd"
aaa bbb ccc "ddd_eee"
aaa bbb ccc ddd eee "fff_ggg_hhh_iii"

■条件
※ちょっと古いPerlでも動くよう,ゼロ幅肯定/否定後読((?<),(!<))は使わないでください.

※単に実現するだけなら,

# cat inputfile | print -pe 'sub f(){}(shift;s/ /_/;return $_;); s/(\".*\")/&f($1)/e;'

みたいな感じで置換できそうですが,「正規表現だけで簡単に書けるかどうか」が知りたいのです
(正規表現だけで実現出来る場合,そのアルゴリズムを知りたいです).
そのため,関数と/eオプションは使わないでください.

投稿日時 - 2011-10-12 08:40:54

質問者が選んだベストアンサー

正規表現「のみ」では困難で、私なら、
#! perl -p
1 while (s/(\"[^" ]+) ([^"]+\")/$1_$2/);
ぐらいで妥協します。

ダブルクォーテーションに囲まれた文字列が1行に0~1個まで、
すなわち、以下のような行がないなら、もう少し簡略化できるでしょう。
aaa bbb ccc ddd eee "fff ggg hhh iii" "jjj kkk"

■_

■_ もなど

Yet Another なんちゃら

Mike's World-O-Programming - Yet Another Monad Tutorial (part 1: basics)

Yet Another Monad Tutorial (part 1: basics)

It's a standing joke in the Haskell community that every Haskell programmer, as part 
of his or her learning process, will eventually write one or more monad tutorials. I'm 
certainly no exception. But since I know that there are already dozens of monad
tutorials out there, some quite good, why on earth would I want to write Yet Another 
One? There are two reasons:

Haskell コミュニティには、すべてのHaskellプログラマーはその学習の過程の一部として
ひとつ以上のモナドチュートリアルを書いてしまうという standig joke があります。
わたしもまた例外ではありません。
しかしわたしはすでに何ダースものモナドチュートリアルがあることを知っていますから、
わたしがさらにもうひとつのチュートリアルを書こうというのは当然のことです。
それには二つの理由があります。
#ちょっと無理やり

   1. I think I can explain some aspects of monads better than most of the monad tutorials
      I've seen.

   2. My own understanding of monads has improved greatly, and I'd like to try to pass that
      on if I can.

(略)

Executive summary: What are monads?

"What is a monad?" is a question I've been asked many times. I don't want to 
describe a monad as a "thing" because that is uninformative and also misleading.
Instead, my executive summary is this:

“モナドとは何か”という質問をわたしは何度も受けました。
“もの”としてのモナドを説明する気はありません。
なぜなら、それは uniformative であると同時に misleading であるからです。
わたしの executive サマリーを代わりに示します

    Monads are a generalization of functions, function application, and function 
    composition to allow them to deal with richer notions of computation than standard 
    functions.

    モナドとは、標準の関数よりも richer な notions of cumputation を扱うことを
    可能とするための関数の一般化であり、関数の適用であり、関数の合成です。

As we progress, I hope to explain to you not only what monads are and how they work, 
but also why monads can be so confusing to programmers unfamiliar with them. (Hint: it 
isn't because they're not smart enough or because they don't know enough category theory.)

詳しい説明は略

2011年10月29日

■_

Excel (2007) と、Libra Office の calc、キングソフトのOffice 互換ソフト とで同じ操作 (あるデータをクロス集計して、積み上げ棒グラフを作成) を やってみたのだけど、慣れがある程度あるとはいえ Excel が一番楽にできた (Excel でも2003あたりだとどうか?)。 ほとんど操作に迷うことなく欲しい結果を得られた。 さすがに良くできてるよなあと思った瞬間。 2003 以前のExcel とか互換ソフトだと、 ピボットテーブル作ってそれからグラフ作るのってかなり面倒な作業な気がする (表の「値」だけ別のシートなりにコピーしてからグラフ作成しないとうまくいかない感じ)。

電人ザボーガーとゴーカイジャーの主題歌を繰り返し聴いて時代の流れを感じてみたり(笑) むかーしのこの手の曲の歌詞って 「倒せ」とか「命を賭けろ」とかわりと物騒な表現が頻出してたと思うんだけど、 最近のはそうでもないのね。 歌詞の変化の傾向とか調べてみたいw Songs For Heroes<赤盤> Songs For Heroes <青盤> 海賊戦隊ゴーカイジャー主題歌

仮面ライダーはよくわかりません :)
Switch On! SG+DVD

"Don’t Call Yourself A Programmer, And Other Career Advice | Kalzumeus Software" http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/ "Don't Call Yourself A Programmer : programming" http://www.reddit.com/r/programming/comments/lsyok/dont_call_yourself_a_programmer/

■_ Prolog

そいや「来年の言語」はどうしよう。 ってここ何年かまじめにやってなかったりするんですがw

【論理】Prolog【初心者】

313 デフォルトの名無しさん [sage] 2011/10/28(金) 18:22:41.97 ID: Be:
    twitterへのPrologに関する日本語の書き込みがここのところ約一ヶ月
    24時間で15~20ツイートを常に維持している。
    4-5月ころは3~5平均だったから、相当の増加。外国語のツイートはさらに
    爆発的で5倍どころではない。

314 デフォルトの名無しさん [sage] 2011/10/28(金) 18:28:01.50 ID: Be:
    なんかあったの? 

315 デフォルトの名無しさん [sage] 2011/10/28(金) 18:53:04.11 ID: Be:
    >>314
    8月から「7つの言語 7つの世界」の影響で2倍以上の書き込みになった。
    外国の事情は、よく判らないけど、似たようなことが起こっているようだ。
    9月後半からの急増は相乗効果ではないか。過去の遺物といった否定的な
    先入観による書き込みはほとんどなくなり、面白いという書き込みが突然
    増えた。

316 デフォルトの名無しさん [sage] 2011/10/28(金) 19:00:13.44 ID: Be:
    難しい。わからないも多いな。 

317 デフォルトの名無しさん [sage] 2011/10/28(金) 19:35:17.42 ID: Be:
    よく分からんが、関数型言語への注目が集まった波及効果によって、
    宣言型言語の一つである論理型言語(Prolog)にも関心が増えたのではないかと推測

    あとはCoqのような実用的な定理証明系が登場して一般人向けの情報が増えた
    (実用的といっても....だし、一般人といっても.....だけどね)
    その結果として「論理とプログラミングとの関係」について考える人が増えたのかも
    物事を形式的にモデル化するには関数だけでは足りなくて、論理も必要になるから 

318 デフォルトの名無しさん [sage] 2011/10/28(金) 20:06:42.91 ID: Be:
    >>317
    確かにそんなことをつぶやいてる人が結構いる。関数型への関心の波及効果と
    いうのも。対で語られることも多い。 

319 デフォルトの名無しさん [sage] 2011/10/28(金) 20:57:19.14 ID: Be:
    そこでCurryですよ

320 デフォルトの名無しさん [sage] 2011/10/28(金) 21:08:44.19 ID: Be:
    第五世代のころは世間的にはどんな扱いだったんだろう?
    銀の弾丸みたいだったのかな 

321 デフォルトの名無しさん [sage] 2011/10/28(金) 21:28:30.72 ID: Be:
    >>320
    過大評価されたし、バブル期でもあった。
    Prologプログラマを派遣してもらうにはひとり120万/月とか。
    ナレッジエンジニアの必須技術とされた。実はプログラマ数は
    あまり増えなかったが、一応メジャー言語の末席。bit誌などの
    広告ではProlog処理系が他を圧倒していた。
    企業がPrologを見限って、C++に移行して急速に衰退した。
    PrologでやりかたったことをC++でできるというわけではなく、
    AI技術発展のお裾分けにあずかるという目論見はその時点で
    挫折。 

Prolog とは直接関係ないけど、 むかーし人工知能とかエキスパートシステムとか知識表現なんかをちょっとだけやってた。 エキスパートシステムって、パソコン(PC-9801)用のパッケージもあって 売ってたりしてたんだけどその後どうなったんだろうか。

■_

釣り企画。かなあ…

こんなのチェックしてる自分に呆れましたね。 同一人物のものっぽい質問が OKWave にもあるんだけどそれはいいやもうw

■_ 4th

Larry には Perl 6ネタで一冊書いてほしいなあと思ったり。 別に Programming Perl のようなそれ、というのではなく こういう Programming is Hard, Let's Go Scripting... - Perl.com 話を広げた感じのとか。 そいやこれ、途中まで訳してたけど投げ出してるな(^^; 誰か完訳した人いるのかな。

4th Edition of the Camel Book coming out in December : perl


4th Edition of the Camel Book coming out in December (shop.oreilly.com)


Wow, I can learn about pseudohashes.


Pseudohashes were already written up in great detail in the 3rd edition. I'm willing to
bet that this new edition will remove most, if not all, of that content.

I haven't read this edition; I'm going by the marketing blurb:

Many Perl books explain typeglobs, pseudohashes, and closures, but only this one shows 
the motivations behind these features and why they work the way they do.

I had no idea what pseudohashes were and just now read this: 
 http://perldesignpatterns.com/?PseudoHash

Now i'm horrified and glad they're deprecated.


Honestly I have no excitement about this book. I read the last version a few times but 
I think there is better and cheaper alternatives now. For learning Perl the language I 
recommend the following:

正直云って、この本に対しては興奮を覚えない。
この本の(現時点での)最新バージョンを何度か読んだのだけど、
今となってはもっと安くて良い代替候補があると思う。
Perl を学ぶのなら、わたしがオススメするのはこんなところ:


    * Modern Perl (free online)
    * Perl Best Practices
    * Higher Order Perl (free online) or Mastering Perl (old draft free online)

PBP is somewhat optional. I recommend it to cut off the bad habits before they start but
Modern Perl does this as well to a certain extent.

PBP についてはオプションで。
悪い習慣がついてしまうのを防ぐためにこの本を薦めるのだけど、
Modern Perl が一部のものについてはそうならないようにしている。

Mastering Regular expressions is a great book but it is not an all Perl book either.

Mastering Regular expressions (邦訳 詳説正規表現) は、すばらしい本ではあるけれども
丸々 Perl についての本ではない。

My view is somewhat biased since I knew a few programming languages before learning Perl
so keep that in mind.

自分は Perl を学ぶ以前には少数のプログラミング言語しか知らなかったので、
自分の見方にはバイアスがかかっているであろうことを念頭においてほしい。

What I want to know is, will they fix the 3rd edition's glaring omission from the glossary?

I'm speaking, of course, about "thingy."


I'm very happy about this. It's one of the best books on programming there is. I'm
definitely buying it. I read most parts of it about 7-8 years ago and I still remember 
its funny and witty style.

■_ JavaScriptCore

興味をひく単語がちらほら

JavaScriptCore, the WebKit JS implementation -- wingolog

JavaScriptCore, the WebKit JS implementation

28 October 2011 3:51 PM

My readers will know that I have recently had the pleasure of looking into the V8 
JavaScript implementation, from Google. I'm part of a small group in Igalia doing 
compiler work, and it's clear that in addition to being lots of fun, JavaScript 
implementations are an important part of the compiler market today.

But V8 is not the only JS implementation in town. Besides Mozilla's SpiderMonkey, 
which you probably know, there is another major Free Software JS implementation that 
you might not have even heard of, at least not by its proper name: JavaScriptCore.

しかし V8 は単なる JavaScript の唯一の実装ではなく、ほかにもあなたもご存知であろう
Mozilla の SpiderMonkey のように、major な Free Software である
あなたがこれまで耳にしたことのない、
少なくともその正式名称である JavaScriptCore を知らないであろう
JavaScript の実装が存在しています。

jsc: js for webkit

JavaScriptCore (JSC) is the JavaScript implementation of the WebKit project.

JavaScriptCpre (JSC) とは WebKit プロジェクトによる JavaScirpt の実装です。

(略)

a register vm

The interpreter has a number of interesting pieces, but it is important mostly for 
defining the format of bytecode. Bytecode is effectively the high-level intermediate 
representation (IR) of JSC.

このインタープリターには多くの interesting pieces がありますが、
このレジスター vm はバイトコードのフォーマットを決める上で最も重要なものです。
バイトコードは、JavaScript の効率的な高水準の中間表現です。

(略)

future

So that's JavaScriptCore. The team -- three people, really -- is mostly focusing on 
getting the DFG JIT working well right now, and I suspect they'll be on that for a few 
months. But we should at least get to the point where the DFG JIT is working and 
enabled by default on free systems within a week or two.

The one other thing that's in the works for JSC is a new generational garbage 
collector. This is progressing, but slowly. There are stubs in the code for 
card-marking write barriers, but currently there is no such GC implementation, as far 
as I can tell. I suspect that someone has a patch they're cooking in private; we'll 
see. At least JSC does have a Handle API, unlike SpiderMonkey.

conclusion

So, yes, in summary, JavaScriptCore is a fine JS implementation. Besides being a correct
implementation for real-world JS -- something that is already saying quite a lot -- it
also has good startup speed, is fairly robust, and is working on getting an optimizing
compiler. There's work to do on it, as with all JS implementations, but it's doing fine.

Thanks for reading, if you got this far, though I understand if you skipped some parts 
in the middle. Comments and corrections are most welcome, from those of you that 
actually read all the way through, of course :). Happy hacking!

きちんと全部読むのは結構骨がおれそう。

■_ Don't Call Yourself A Programmer, And Other Career Advice

あとで読む(多分)

Don't Call Yourself A Programmer, And Other Career Advice | Kalzumeus Software

Don't Call Yourself A Programmer, And Other Career Advice

Posted on October 28, 2011 by Patrick in Uncategorized

If there was one course I could add to every engineering education, it wouldn't involve
compilers or gates or time complexity.  It would be Realities Of Your Industry 101,
because we don't teach them and this results in lots of unnecessary pain and suffering.
This post aspires to be README.txt for your career as a young engineer.  The goal is to
make you happy, by filling in the gaps in your education regarding how the “real world”
actually works.  It took me about ten years and a lot of suffering to figure out some of
this, starting from “fairly bright engineer with low self-confidence and zero practical
knowledge of business.”  I wouldn't trust this as the definitive guide, but hopefully it
will provide value over what your college Career Center isn't telling you.

以下略

■_

2011年10月28日

■_

ある機械を使うときに、その機器に割り当てられたIPアドレスを「電話」でやり取り しないといけなかったりするんですが、アドレスが IPv6 になったとき そのやり取りはどうなるんだろうなあと考えてみたり。

■_

■_

C++ でシェルを書いているのになんでそれを活用しないのよ的な。

If the shell is written in C++, why not just export its base classes? - The Old New Thing - Site Home - MSDN Blogs

If the shell is written in C++, why not just export its base classes?

シェルがC++で書かれているというのなら、なぜその base class 群を export しないの?


ton suggested that since the shell is written in C++, IShell­Folder should have been 
an abstract class, and then it could have used techniques like exceptions and 
Inversion of Control.

シェルがC++で書かれているのだから、IShell-Folder は抽象クラスであるべきで、
それにより例外だとか Invernsion of Control のようなテクニックを使えるように
すべきだというたくさんの提案がなされています。

Okay, first of all, I'm not sure how Inversion of Control is something that requires 
C++, so I'm going to leave that aside.

よろしい。わたしは Invension of Control がどのように C++ を必要としているものなのか
良くわからないので、これは脇におきます。

Second of all, who says the shell is written in C++? As it happens, when IShell­Folder 
was introduced in Windows 95, the entire shell was written in plain C. That's right, 
plain C. Vtables were built up by hand, method inheritance was implemented by direct 
replacement in the vtable, method overrides were implemented by function chaining, 
multiple inheritance was implemented by manually moving the pointer around.

第二に、シェルがC++で書かれていると誰が言ったのでしょうか?
IShell-Folder はWindows 95で導入されたもので、シェル全体が plain な C で
書かれていました。そう、plain な C です。
Vtable は手作業で構築され、メソッドの継承は vtable を直接置き換えることで
実装されていましたし、メソッドオーバーライドは function chaining によって
実装されていて、多重継承はポインター周りを手作業で移動することで実装されていました。

    const IShellFolderVtbl c_vtblMyComputerSF =
    {
        MyComputer_QueryInterfaceSF,
        MyComputer_AddRefSF,
        MyComputer_ReleaseSF,
        MyComputer_ParseDisplayName,
        ... you get the idea ...
    };
    
    const IPersistFolderVtbl c_vtblMyComputerPF =
    {
        MyComputer_QueryInterfacePF,
        MyComputer_AddRefPF,
        MyComputer_ReleasePF,
        MyComputer_Initialize,
    };
    
    struct MyComputer {
        IShellFolder sf;
        IShellFolder pf;
        ULONG cRef;
        ... other member variables go here ...
    }
    
    MyComputer *MyComputer_New()
    {
        MyComputer *self = malloc(sizeof(MyComputer));
        if (self) {
            self->sf.lpVtbl = &c_vtblMyComputerSF;
            self->pf.lpVtbl = &c_vtblMyComputerPF;
            self->cRef = 1;
            ... other "constructor" operations go here ...
        }
        return self;
    }
    
    // sample cast キャストの例
    MyComputer *pThis;
    IPersistFolder *ppf =  &pThis->pf;
    
    // sample method call メソッド呼び出しの例
    hr = IShellFolder_CompareIDs(psf, lParam, pidl1, pidl2);
    // which expands to
    hr = psf->lpVtbl->CompareIDs(psf, lParam, pidl1, pidl2);
    
    // sample forwarder for multiply-derived method
    HRESULT STDCALL MyComputer_QueryInterfacePF(
        IPersistFolder *selfPF, REFIID riid, void **ppv)
    {
        MyComputer *self = CONTAINING_RECORD(selfPF, MyComputer, pf);
        return MyComputer_QueryInterfaceSF(&self->sf, riid, ppv);
    }

So one good reason why the shell didn't export its C++ base classes was that it didn't 
have any C++ base classes.

ですから、シェルが C++ の base class 群をエクスポートしていない理由は
一切の C++ の base class を持っていなかったからなのです。

Why choose C over C++? Well, at the time the Windows 95 project started, C++ was still 
a relatively new language for systems programming. While there were certainly people 
on the shell team capable of writing code in C++, the old-timers grew up with C as 
their native language, and the newcomers weren't taught C++ in their computer science 
classes. (Computer science departments still taught primarily C or Pascal, with maybe 
some Lisp if you took an AI class.) Also, the C++ compilers of the day did not provide 
fine control over automatic code generation,¹ and since even saving 4KB of memory had 
a perceptible impact on overall system performance, manually grouping rarely-used 
functions into the same region of memory of memory (so they could all remain paged out) 
was still a common practice.

なぜ C++ ではなく Cを選択したのでしょうか>
それは、Windows 95 のプロジェクトが始まった時期、
C++ は依然としてシステムプログラミングでは比較的新しい言語だったからです。
一部にはシェルのアイテムをC++のコードで書ける人もいましたが、
C をネイティブ言語としてともに成長した old-timers もいたし、
コンピューター科学のクラスで C++ を教えらていなかった新人もいました
(コンピューター科学の departments では依然として primarily には C か Pascall
を使っていて、AIクラスであれば Lisp も使ったりしているでしょう)。
また、当時の C++コンパイラーは自動コード生成に対する fine control を
提供していませんでしたし、4Kバイトのメモリーを節約することですら
システム全体のパフォーマンスに perseptible な影響を及ぼしていましたから、
めったに使われない関数はメモリーのメモリーの同じ領域に押し込む
(そのようにしてその領域全体をページアウトできるようにしていました)
ことは依然として一般的な practice だったのです。



But even if the shell was originally written in C++, exporting the base classes 
wouldn't have been a good idea. COM is a language-neutral platform. People have 
written COM objects in C, C++, Visual Basic, C#, Delphi, you-name-it. If IShell­Folder 
were an exported C++ base class, then you have effectively said, "Sorry, only C++ 
code can implement IShell­Folder. Screw off, all you other languages!"

しかしたとえシェルが originally に C++ で書かれていたとしても、
その base class 群の export は良い考えではありませんでした。
COM は言語中立なプラットフォームです。
ユーザーは C をはじめとして C++ や Visual Basic、C#、Delphi 等々で
書かれた COM オブジェクトを持っていました。ですから仮に Ishell-Folder が
C++ の base class 群を export していたならば、あなたは effectively にこう言うでしょう
"Sorry, only C++ code can implement IShell-Folder. Screw off, all you other languages!"


But wait, it's worse than just that. Exporting a C++ base class ties you to a specific 
compiler vendor, because name decoration is not standardized. So it's not just 
"To implement IShell­Folder you must use C++" but "To implement 
IShell­Folder you must use the Microsoft Visual Studio C++ compiler."

しかし待ってください。it's worse than just that.
C++ の base class の exporting は
特定のコンパイラーベンダーに強く依存するものでした。
ですから単にIShell-Folder を十ソウルには C++ を使わなければならない
“けれども”、
そのIShell-Folder の実装のために Microsoft Visula Studio を使わなければならない。
とはできなかったのです。


But wait, it's worse than just that. The name decoration algorithm can even change 
between compiler versions. Furthermore, the mechanism by which exceptions are thrown 
and caught is not merely compiler-specific but compiler-version specific. If an 
exception is thrown by code compiled by one version of the C++ compiler and reaches 
code compiled by a different version of the C++ compiler, the results are undefined. 
(For example, the older version of the C++ compiler may not have supported RTTI.) So 
it's not just "To implement IShell­Folder you must use C++" but "To 
implement IShell­Folder you must use Microsoft Visual C++ 2.0." (So maybe Bjarne 
was right after all.)

とはいうものの、

But wait, it's worse than just that. Exporting a C++ base class means that the base 
class can never change, because various properties of the base class become hard-coded 
into the derived classes. The list of interfaces implemented by the base class becomes 
fixed. The size of the base class is fixed. Any inline methods are fixed. The precise 
layout of member variables is fixed. Exporting a C++ base class for IShell­Folder 
would have mean that the base class could never change. You want support for 
IShell­Folder2? Sorry, we can't add that without breaking everybody who compiled with 
the old header file.

Exercise: If exporting base classes is so horrible, why does the CLR do it all over 
the place?

演習:
base class 群の export がそんなに horrible なことであるのなら、
なぜ、CLR はそういったことを行ったのでしょう?

Footnote

¹ Actually, I don't think even the C++ compilers of today give you fine control over 
automatic code generation, which is why Microsoft takes a conservative position on use 
of C++ in kernel mode, where the consequences of a poorly-timed page fault are much 
worse than simply poor performance. It will bluescreen your machine.

    * © 2011 Microsoft Corporation.

■_

Island Life - O(n^2)正規表現

O(n^2)正規表現

Past comment(s)

ボツ♪

■_

should i bother trying to make a program with python for data analysis over using excel macros? or will it be a waste of time? : Python

I want to do a data analysis on a survey that is comprised of about 25 questions, 
maybe over 100 files.

おおよそ25個の質問がある100 個以上のファイルについての survey で
データ解析をしたいと考えています。

What I have been doing so far is writing excel macros to find relationships between 
the results between the questions.. i.e. making a macro to sort the strength of 
correlations of the results of all the combinations of questions by telling excel to 
go to a specific folder and look for it and extract, put it in, sort it at the end, 
etc..

わたしがこれまでやったことといえば、複数の質問の結果にある関係を見つけ出すために
Excel のマクロを書いたくらいです。
要するに、

It's getting much tedious. Is there a better way to analyze such data? I'm assuming 
python will be more user friendly as well if other ppl wanted to use it.

こんなことをするのにはうんざりしてきました。
このようなデータを解析するのにもっといい方法はないでしょうか?
わたしは python がほかの ppl が使いたいと思ったならば
より user friendly になるものじゃないかと思っています。

I only have basic understanding of python..
わたしは python についてはほんの基本的なところしか理解していません。

Will python be easier to process all these data? What kind of other tools do you 
recommend if I decide to use python for these data analysis? Should I just stick with 
doing macros on these files?

I feel like i want to make like a desktop app just for this survey, but i don't know 
if that will take a lot of time.. Things i want to do are something like 
cross-tabulation, graphing charts(meaningful ones ofc), etc.

I'm not a programmer; but intro compsci courses i took covered python.


It may be too obvious to say, but if you learn and use Python, you will have a tool 
you can use in all sorts of situations: a general purpose scripting language, with a 
vast community. Today data analysis, tomorrow category theory, the next day 
simulation...


If your not set on python R and or matlab are the defacto data analysis tools for power users.


Having tried both, I would definitely use R for stats processing over Python/NumPy if 
given the choice.


I would not. I work with R daily and too many times I have to work around the many 
inconsistencies of the language (accessing non-existing names in a vector that yields 
you an empty vector, for example). I use rpy2 to interface R with Python to have a 
much saner work environment. And where I could, I moved to Python/NumPy/SciPy entirely.


Projects like pandas and scikits.statsmodels are aiming to fill in the gaps for doing 
this sort of thing in Python.


And in fact I'm using both. ;)


Same here. R was just too much to handle. I am not a statistician by trainig,nor a 
programmer, I do not want to fight the language, just develop smooth algorithms.


each of them has there advantages and disadvantages.

python is definitely a (by far) more universal tool...


Sounds like you want something like this: http://rattle.togaware.com/

I don't think we have enough information to make a judgement on whether or not 
replicating this in Python is a "waste of time". The author does have Python 
skills though, so there's probably a good reason he chose not to use it in this case.

If you were serious about ramping up your Python skills, you could make a good job of 
it with numpy or RPy, pyqt/pyside and something like traits/chaco, matplotlib, 
networkx, or similar. Maybe start something on github & let other interested 
people join in.


From what I gather, R is way to go for this kind of stuff?


Actually, Pandas: http://pandas.sourceforge.net/

It uses Numpy underneath the hood, but provides an R-style DataFrames interface. It has lots of built-in statistics and whatnot. The author is a friend of mine and is actively developing it, so if you run into features that it doesn't support, ping him via email or Twitter and I'm sure he'll be responsive.


I second that statement. I recently switched part of a project to pandas and it's awesome.


I've made several pull requests & bug reports against Pandas, and I can vouch that 
Wes is very quick to respond - stuff is often resolved within a few hours. Pandas 
development moves at an impressive pace.


Thanks, I think Rstudio looks pretty good and Numpy stuff I'd definitely look into.. I'm tired of excel..


From a purely educational point of view: No, it's not. It's worthwhile learning any 
new skill.

From an efficiency point of view: You've already got a working system, why change it? 
Is it severly hindering progress? Is it in-secure? Is it slow? Inaccurate?

I have to deal with changes in process in the company I work for and make sure any 
changes that are going through are actually for the benefit and those questions above 
are similar to what I have to ask.

NumPy is a good library with some good documentation for this sort of thing.

Maybe http://www.knime.org/ is another option worth looking at?


Try resolver one

Its a spreadsheet that has python embedded. It can also publish webforms i think.



I already have resolver one, but I found that it's buggy and has slow response time. 
It's just a spreadsheet but I can put in python functions within cells.

Try python as an exploratory process. Read the files calculate a few numbers and see 
how much hair you have lost. Matlab seems to be a little more interactive. I've made 
some simple data analysis/gui applications before in python and it wasn't too bad.

Just so you know, you can read/write excel ss from python.

Python is far easier than excel macros.

Also, fuck excel macros. My boss once gave me a huge data analysis file with excel 
macros for piecing together 3databases and analyzing about 30 columns of data. Goddamn 
mess. I gave up trying to figure it out and just wrote out a few handy python 
functions.

Also, if you need help reading and piecing together excel files, pm me.

Sorry, Python tops out at processing 99 files. :-( You'll have to stick to Excel.

wat


Yeah, it's because Guido won't do a Tail Call Optimizer.

■_

2011年10月27日

■_

プロ野球のドラフト会議今日だったのね。 すっかり興味を失っていたので以下略。 まああれもねえ

■_

John McCarthy ≪ Sutter's Mill

John McCarthy

2011-10-25 by Herb Sutter

What a sad, horrible month. First Steve Jobs, then Dennis Ritchie, and now John McCarthy.
We are losing many of the greats all at once.

If you haven't heard of John McCarthy, you're probably learning about his many important
contributions now. Some examples:

もしあなたが John McCarthy のことを聞いたことがないのなら、今ここであなたは
彼の数多い重要な貢献を知ることになるでしょう。いくつか例を挙げます:

  He's the inventor of Lisp, the second-oldest high-level programming language, younger
  than Fortran by just one year. Lisp is one of the most influential programming languages
  in history. Granted, however, most programmers don't use directly Lisp-based languages,
  so its great influence has been mostly indirect.

  彼は Lisp を発明しました。この言語はFortranよりもほんの一年若いだけの二番目に古い
  高水準プログラミング言語です。Lisp は歴史上最も影響を及ぼしたプログラミング言語の
  一つです。
  granted, however,
  大部分のプログラマーはLispベースの言語を直接使ったりはしないので
  その偉大な影響はほぼ間接的なものとなっています。

  He coined the term “artificial intelligence.” Granted, however, AI has got a bad rap
  from being oversold by enthusiasts like Minsky; for the past 20 years or so it's been
  safer to talk in euphemisms like “expert systems.” So here too McCarthy's great
  influence has been less direct.

  彼は“artificial intelligence”(人工知能)という言葉を発明 (coin) しました。
  granted, however,
  AI は Minksky のような enthusiast たちによって oversold されて

  そのため、ここでも McCarthy の 偉大な影響は less direct なものとなったのです。

  He developed the idea of time-sharing, the first step toward multitasking. Okay, now we're
  talking about a contribution that's pretty directly influential to our modern systems and
  lives.

  彼はマルチタスキングの最初のステップである時分割のアイデアを生み出しました。


But perhaps McCarthy's most important single contribution to modern computer science is still
something else, yet another major technology you won't hear nearly enough about as being his
invention:

しかしMcCarthyのmodern コンピューター科学に対する最も重要な貢献とはおそらく、
これらのどれでもないあなたがこれまでそれが彼の発明であるとは知らずにいた
もう一つ別の major technology です。

Automatic garbage collection. Which he invented circa 1959.

自動ガーベジコレクションがそれです。彼はこれを 1959年ころに発明しました。

No, really, that's not a typo: 1959. For context, that year's first quarter alone saw the
beginning of the space age as Sputnik 1 came down at the end of its three-month orbit;
Fidel Castro take Cuba; Walt Disney release Sleeping Beauty; The Day the Music Died; the
first Barbie doll; and President Eisenhower signing a bill to enable Hawaii to become a
state.

いえ、間違いではありません。1959年です。
For context,
スプートニク1号が三ヶ月の周回の終わりに燃え尽きたことで宇宙時代が開幕し、
Fidel Castro がキューバを支配し、
Walt Disney が Sleeping Beauty を公開し、
The Day the Music Died;
最初のバービー人形が登場し、
Eisenhower 大統領が Hawaii を州へと昇格させる宣誓書にサインした
その年です。
#スプートニク1号は1957年10月の打ち上げらしいんですが…


GC is ancient. Electronic computers with core memory were still something of a novelty
(RAM didn't show up until a decade or so later), machine memory was measured in scant
kilobytes, and McCarthy was already managing those tiny memories with automatic
garbage collection.

GC は ancient です。コアメモリを備えた電子計算機は未だ something of a novelty であり
(RAM は十年以上後にならないと登場してきません) マシンのメモリーはキロバイト単位で
数えられていたのですが、McCarthy はそのときすでにそのような小さなメモリー空間を
自動ガーベジコレクションを使って管理していました。


I've encountered people who think GC was invented by Java in 1995. It was actually invented
more than half a century ago, when our industry barely even existed.

わたしは GC が1995年に Java において発明されたものと信じ込んでいる人たち遭遇したことがあります。
実際には、 GC は半世紀ほど前のわたしたちの indutry が barely even existed なころに発明されていたのです。


Thanks, John.

ありがとう John。

And here's hoping we can take a break for a while from writing these memorials to our giants.

■_

Dennis Ritchie « Sutter's Mill

Dennis Ritchie

2011-10-12 by Herb Sutter

dmr (Dennis Ritchie)

What a sad week.
なんと悲しい週なのだろう。

Rob Pike reports that Dennis Ritchie also has passed away. Ritchie was one of the pioneers
of computer science, and a well-deserved Turing winner for his many contributions, notably
the creation of C — by far the most influential programming language in history, and still
going strong today.

Rob Pike が Dennis Ritchie の死去を報告しました。Ritchie はコンピューターサイエンスの
パイオニアの一人であり、彼の数々の功績、とりわけ歴史上もっとも影響力を持ったプログラミ
ング言語であって今日もなお強力であり続けている C の作成に対してチューリング賞が贈ら
れています。

Aside: Speaking of “still going strong,” this is a landmark week for the ISO Standard C
Programming Language as well. Just a couple of days ago, the new C standard passed what
turned out to be its final ballot,[*] and so we now have the new ISO C11 standard. C11
includes a number of new features that parallel those in C++11, notably a memory model
and a threads/mutexes/atomics concurrency library that is tightly aligned with C++11. The
new C standard should be published by ISO in the coming weeks.


“still going strong,”ということについてですが、
今週は ISO standard C Programming Language にとっても landmark week です。
ほんの数日前に新しい C の標準が パスしており、
そしてそれは新しい ISO C11 standard になるでしょう
C11 は数々の新しい機能を含んでいて、それには
メモリモデルや C++11 と tightly に alinged された
threads/mutexes/atomics の concurrency ライブラリが含まれています。
この新しい C の標準はこれから数週間のうちに publish されるでしょう


[*] ISO rules are that if you pass the penultimate ballot with unanimous international 
support, you get to skip the formality of the final ballot and proceed directly to
publication.

Bjarne Stroustrup made an eloquent point about the importance of Ritchie's contributions
to our field: “They said it couldn't be done, and he did it.”

Bjarne Stroustrup は our field に対する Ritchie の貢献の重要性について
eloquent に 主張しました
“They said it couldn't be done, and he did it.”
(皆はそんなことは不可能だと言ったけれども、彼はやってのけた)。


Here's what Bjarne meant:
Bjane の発言の意味するところはこうです

Before C, there was far more hardware diversity than we see in the industry today. Computers
proudly sported not just deliciously different and offbeat instruction sets, but varied
wildly in almost everything, right down to even things as fundamental as character bit
widths (8 bits per byte doesn't suit you? how about 9? or 7? or how about sometimes 6 and
sometimes 12?) and memory addressing (don't like 16-bit pointers? how about 18-bit pointers,
and oh by the way those aren't pointers to bytes, they're pointers to words?).

C 以前には、今日わたしたちが industry で目にしているものよりもずっとたくさんの
ハードウェアの多様性がありました。
Computers proudly sported not just deliciously different and offbeat instruction sets,
コンピューターは

キャラクターのビット幅 (1バイトが8ビットであることはあなたにとって都合が良いですか?
9ビットはどうでしょうか? 7ビットは? あるいは6ビットだとか12ビットはどうでしょうか?)
であるとかメモリーアドレッシング
(16ビットポインターはお好きでない? では18ビットポインターはどうでしょうか?
and oh by the way those aren't pointers to bytes, they're pointers to words?).
のような fundamental なことにいたるまでほぼすべてのことについて
非常に幅があったのです。


There was no such thing as a general-purpose program that was both portable across a 
variety of hardware and also efficient enough to compete with custom code written for 
just that hardware. Fortran did okay for array-oriented number-crunching code, but 
nobody could do it for general-purpose code such as what you'd use to build just about 
anything down to, oh, say, an operating system.

広範囲のハードウェアを通して portable であると同時に、そのハードウェアのためだけに書か
れたカスタムコードに匹敵するくらい効率が良い汎用のプログラムというものは存在していませ
んでした。Fortran は配列指向の number-crunching なコードには良いのですが、誰もそれを
オペレーティングシステムのようなものを構築するための general-purpose なコードには使え
ませんでした。


So this young upstart whippersnapper comes along and decides to try to specify a language
that will let people write programs that are: (a) high-level, with structures and functions;
(b) portable to just about any kind of hardware; and (c) efficient on that hardware so that
they're competitive with handcrafted nonportable custom assembler code on that hardware. A
high-level, portable, efficient systems programming language.

そこでこの若き upstart whippersnapper (小癪なヤツ、青二才) は、次のようなプログラムを書くことを
可能とするであろう言語の specify に挑むことにしました。それは
(a) 構造体と関数を備えて高水準であり
(b) すべてのハードウェアに対して portable であり
(c) 同じハード向けの手書きの nonportable なカスタムアセンブラーのコードに匹敵するほどハード
    ウェア上で効率が良い
高水準で portable で効率の良いシステムプログラミング言語です。


How silly. Everyone knew it couldn't be done.

そんなことはできないと誰もが思っていました

C is a poster child for why it's essential to keep those people who know a thing can't be
done from bothering the people who are doing it. (And keep them out of the way while the
same inventors, being anything but lazy and always in search of new problems to conquer,
go on to use the world's first portable and efficient programming language to build the
world's first portable operating system, not knowing that was impossible too.)

C は、成し遂げられないことを知っている人たちを
それを行っている人たちをわずらわせないように
遠ざけるための essential である理由のための poster child (広告塔) です

(And keep them out of the way while the same inventors,
being anything but lazy and always in search of new problems to conquer,
征服すべき新しい問題を捜し求める

それまでは不可能であろうと信じられていた、
世界最初の portable なオペレーティングシステムを構築するため
世界最初の portable かつ efficient なプログラミング言語)。



Thanks, Dennis.
ありがとう Dennis。


■_

■_

ボツ♪

2011年10月26日

■_

そういや先月はダムエーをついに買わなかった (創刊号からずっと買っていた)。

■_

ruby-core が結構活発です。


[ruby-core:40356] JIT development for MRI
[ruby-core:40357] Re: JIT development for MRI
[ruby-core:40361] Re: JIT development for MRI
[ruby-core:40384] Re: JIT development for MRI
[ruby-core:40385] Re: JIT development for MRI
[ruby-core:40390] Re: JIT development for MRI
[ruby-core:40394] Re: JIT development for MRI
[ruby-core:40395] Re: JIT development for MRI
[ruby-core:40399] Re: JIT development for MRI
[ruby-core:40405] Re: JIT development for MRI
[ruby-core:40409] Re: JIT development for MRI

[ruby-core:40322] [ruby-trunk - Feature #5482][Open] Rubinius as basis for Ruby ...
[ruby-core:40323] [ruby-trunk - Feature #5482] Rubinius as basis for Ruby 2.0
[ruby-core:40325] [ruby-trunk - Feature #5482] Rubinius as basis for Ruby 2.0
[ruby-core:40382] Re: [ruby-trunk - Feature #5482] Rubinius as basis for Ruby 2....
[ruby-core:40383] Re: [ruby-trunk - Feature #5482] Rubinius as basis for Ruby 2....
[ruby-core:40401] Re: [ruby-trunk - Feature #5482] Rubinius as basis for Ruby 2....
[ruby-core:40326] Re: [ruby-trunk - Feature #5482][Open] Rubinius as basis for R...
[ruby-core:40330] Re: [ruby-trunk - Feature #5482][Open] Rubinius as basis for R...
[ruby-core:40400] Re: [ruby-trunk - Feature #5482][Open] Rubinius as basis for R...
[ruby-core:40332] [ruby-trunk - Feature #5482] Rubinius as basis for Ruby 2.0
[ruby-core:40336] Re: [ruby-trunk - Feature #5482] Rubinius as basis for Ruby 2....
[ruby-core:40347] [ruby-trunk - Feature #5482] Rubinius as basis for Ruby 2.0

この辺とか。

Ruby 2.0 Implementation Work Begins: What is Ruby 2.0 and What's New?

Ruby 2.0 Implementation Work Begins: What is Ruby 2.0 and What's New?
Ruby 2.0の実装作業が始まった: Ruby 2.0 とはなんであり、何が新しいの?

By Peter Cooper / October 20, 2011

Yesterday, Matz made a commit to the MRI Ruby repository bumping the trunk version 
from 1.9.4 to 2.0.0, marking the start of the work of implementing the long-discussed 
ideas for Ruby 2.0.

What is Ruby 2.0?
Ruby 2.0 とはなにか?

Ruby 2.0 is the next major version release of MRI Ruby, the de facto official Ruby implementation.

Ruby 2.0 とは、デファクトオフィシャル Ruby である MRI Ruby のリリースの次なる
メジャーバージョンのことです。


Ruby 1.9.3 is due out any time soon and Ruby 1.9.4 is under active development (it has 
moved to a separate branch now that trunk is 2.0.0). We recently learned that Ruby 2.0 
would then follow Ruby 1.9.4.

Ruby 1.9.3 はまもなくリリースされますし、Ruby 1.9.4 は活発に開発がなされています
(ブランチは分割されて、trunk は現在 2.0.0 となっています)。
We recently learned that Ruby 2.0 would then follow Ruby 1.9.4.

Will Ruby 2.0 be a huge leap forward?
Ruby 2.0 では大きな飛躍があるのでしょうか?

No. While 2.0 will include a number of syntax changes, new features and general 
improvements, mentioned below, it is anticipated to remain backward compatible with 
code written for 1.9.3 and Matz has stated that the changes are less significant than 
those made in the 1.8 to 1.9 jump.

いいえ、2.0 には後述する数多くの構文の変更であるとか、新機能、一般的な改良といったものが
含まれますが、1.9.3 向けに書かれたコードに対する後方互換を保つように anticpated されて
います。また、Matz は 1.8 から 1.9 へジャンプさせたものよりも less significant な
変更をすでに始めています。

    The version number goes up to 2.0 but the changes are rather small. Smaller than the
    ones we made in 1.9.

    バージョン番号は 2.0 となりますが、その変更点はむしろ小さなものです。
    1.9 へとバージョンを進めたときのそれよりも小規模なものとなるでしょう。

Matz

The discussion surrounding Ruby 2.0's feature set spans back several years (mostly on the
ruby-talk and ruby-core mailing lists) and 2.0 was initially expected to introduce
significant syntax changes and not be backwards compatible. Things have changed with Ruby
1.9 moving into production (it was originally a development only version) and 2.0 being an
evolution rather than a revolution.

What will (probably) be new in Ruby 2.0?

Ruby 2.0 で(おそらく)新しくなるであろうことは?

Ruby 2.0 is still not well defined. At the moment, ideas and features are being actively
suggested and discussed, but a number have been tipped to make it into Ruby 2.0 at this
early stage:

Ruby 2.0 はまだ well defined ではありません。現時点で、
アイデアや機能が活発に提案されたり議論されたりしています。
しかし、この early stage にあっても多くのものが Ruby 2.0 に取り込まれています。

Keyword Arguments
キーワード引数

In Ruby 2.0: What We Want to Accomplish in the Near Future (recorded in 2010), Matz showed
off an example where 1.step(20, 2) could become 1.step(by: 2, to: 20) with the method
definition of def step(by: step, to: limit).

Ruby 2.0 では、

An implementation of keyword arguments by Yusuke Endoh actually triggered the discussion
to move trunk to 2.0.0 so this is actively being discussed and implemented.

キーワード引数の実装は


Bytecode export/import
バイトコードのエクスポートやインポート

Ruby 1.9 runs on the YARV virtual machine and so will Ruby 2.0, but Ruby 2.0 is expected
to make it simple to save pre-compiled Ruby scripts to bytecode representations and to
then run these directly. Running pre-compiled bytecode will skip the parsing stage of the
standard interpretation process. If you use Rubinius or JRuby you may be familiar with
this concept.

Ruby 1.9 は YARV virtual machine 上で動作し、Ruby 2.0もそうなるでしょう。
しかし Ruby 2.0 ではバイトコード表現へとプリコンパイルされた Ruby スクリプトの保存と
その直接実行を簡単にすることが期待されています。
プリコンパイル済みバイトコードの実行は標準の解釈プロセスの構文解析ステージを
スキップするでしょう。もしあなたが Rubinius か JRuby を使っているのならこのコンセプトには
慣れ親しんでいるかもしれません。

Refinements

"Refinements" are a construction to make monkey patching safer. Essentially 
you could "refine" a global class within the context of a specific module so 
that the monkey patches would only apply in a certain context. Yehuda Katz wrote an 
excellent writeup about refinements last year.

"Refinements" とは、モンキーパッチをより安全にするものです。
a global class within the context of a specific module を "refine" できるので
モンキーパッチはある特定のコンテキストにおいてのみ適用されます。
Yehuda Katz は昨年 refinements についての素晴らしい writeup を書いています。


Refinements are.. controversial. The performance hit they'd introduce has recently made them
less likely to arrive in Ruby 2.0 but I don't believe they're entirely off the table yet.
Some form of namespacing of class modifications will probably eventually make it in, however.
Another implementation has been called 'traits' and is shown off in the Matz video (linked above).

Standard libraries becoming gems
標準ライブラリが gem となる

On Twitter today, Aaron 'tenderlove' Patterson of the Ruby core team said that the Ruby
standard library would be 'moved to gems' in Ruby 2.0 although many of these would still be
included with the implementation (rather than being an optional extra download).

And more..

As I said before, things are a bit up in the air, but the ideas surrounding Ruby 2.0 
should begin to settle over the next year.

A couple of weeks ago, Koichi Sasada posted the results of a Ruby 2.0 feature questionnaire
to the ruby-core mailing list and encouraged people to extend it. It's not a list of
features that will make it into Ruby 2.0, but an attempt to see what people would like.

Koichi's initial list was:
ささだ氏による initial list は以下の通りです

    * Cleanup syntax (構文のクリーンアップ)
    * Bytecode export (バイトコードのエクスポート)
    * Symbol GC 
    * Remove Proc binding (Proc バインディングの除去)
    * Macros
    * Getting parse tree (解析木の取得)
    * Getting source code (ソースコードの取得)
    * Cross thread Fiber migration (スレッドを跨いだ Fiber の migration)
    * Standard Gem
    * Review all standard libraries (標準ライブラリすべてのレビュー)
    * Remove obsolete one standard libraries (obsolete な標準ライブラリの除去)
    * Improve Proc#curry (Proc#curry の改良)
    * Non-blocking I/O
    * Dtrace
    * GC API (replaceable GC)

As Ruby 2.0 development continues, I'm going to regularly summarize what's going on 
and show off new features here on Ruby Inside, so keep your eyes peeled :-)


Copyright © 2006–2011 Peter Cooper

■_

Garbage Collection Synopsis, and C++ « Sutter's Mill
Garbage Collection Synopsis, and C++

2011-10-25 by Herb Sutter

Insert your favorite "stop the world" joke here.

In response to my note about John McCarthy's inventing automatic (non ref-counted) 
garbage collection, rosen4obg asked:

    OK, GC was invented half a century ago. When it is going to land in the C++ world?

Here's a short but detailed answer, which links to illuminating reading and videos.

The Three Kinds of GC

The three major families of garbage collection are:
ガベージコレクションには大きく三つの系統があって、それは

   1. Reference counting.
      参照カウント

   2. Mark-sweep (aka non-moving) collectors, where objects are collected but live
      objects don't move. This is what McCarthy first invented.
      マークアンドスイープ型のコレクター。
      オブジェクトの回収は行われますが、生きているオブジェクトが移動することはありません。
      

   3. Mark-compact (aka moving) collectors, where live objects are moved together to
      make allocated memory more compact. Note that doing this involves updating pointers'
      values on the fly. This category includes semispace collectors as well as the more
      efficient modern ones like the .NET CLR's that don't use up half your memory or
      address space.

      マークアンドコンパクト型のコレクター。
      生きているオブジェクトも割り当てたメモリーをコンパクトにするために移動します。
      このことによりポインターの値が on the fly で更新されるということに注意してください。
      このカテゴリには semispace collectors も含まれます

GC and C++

C++ has always supported #1 well via reference counted smart pointers. Those are now 
standard in C++11 in the form of unique_ptr, shared_ptr, weak_ptr. C++98 had auto_ptr, 
but it was never great and has been deprecated.

C++ は、参照カウント型のスマートポインターによって #1 を常にサポートしています。
C++ 11 で標準になったものには unique_ptr、standard_ptr、weak_ptr があります。
C++ 98 には auto_ptr がありましたが、これは great ではなく deprecate となりました。

C++ has long supported #2, but less formally because the products were nonstandard, 
conservative, and not as portable. The major prior art is the Boehm (later Great 
Circle and Symantec) mark-sweep garbage collector. The new C++11 standard has just 
added a minimal GC ABI to more formally bless such non-moving collectors; see 
Stroustrup's GC FAQ for more.

C++ は長いこと #2 をサポートしてきていますが、less formally です。
なぜならその products は非標準で、conservative であり、portable ではなかったからです。
major prior art は Boehm の mark-sweep ガーベジコレクターです。
新しい標準の C++11 では minimal な CG ABI が追加されていますが、
これは non-moving なガーベジコレクターをより formaly に  bless するためです。

C++ cannot support #3 without at least a new pointer type, because C/C++ pointer values
are required to be stable (not change their values), so that you can cast them to an int
and back, or write them to a file and back; this is why we created the ^ pointer type for
C++/CLI which can safely point into #3-style compacting GC heaps. See section 3.3 of my
paper A Design Rationale for C++/CLI for more rationale about ^ and gcnew.

C++ は、少なくとも新しいポインター型を導入することなしには #3 のガーベジコレクターを
サポートできません。なぜなら、C および C++ のポインターの値は stable であることを
要求されるからです(その値が変わってはいけない)。それによってポインターを
int へキャストしたりそこから戻したりできるし、あるいは、ポインターの値を
ファイルに書き出したりファイルから読み込んだりできるのです。
これはまた、C++/CLI に #3形式の compacting GC のヒープを安全に point できるように
わたしたちが ^ ポインター型を作った理由でもあります。


Other GC Resources

For a wonderful 57-minute conversation on garbage collection by one of the world's top 
GC experts, run don't walk to the C9 “Inside Garbage Collection” interview with 
Patrick Dussud. Patrick wrote the .NET CLR's GC, and it was far from his first; before 
that he had deep experience implementing Lisp runtimes, and I'm sure has forgotten 
more about GC than I'll ever know. He's also a great guy to work with.

For a great book on GC, I love Garbage Collection by Jones and Lins.

■_ Emacs ソースコードの構成の変遷

count から。

emacs-18.59.tar.gz
ファイル数	言語	空行	コメント
121		C	10,210	10,536	56,309
158		Lisp	6,108	6,658	44,540
159		C/C++ Header	4,711	6,815	5,141
1		yacc	82	136	373
7		make	76	67	297
1		Assembly	43	58	219
1		Perl	13	48	159
1		lex	25	0	125
3		Bourne Shell	34	44	117

emacs-20.1.tar.gz
553		Lisp	47,686	71,759	303,068
180		C	28,593	31,351	144,389
277		C/C++ Header	7,911	12,930	11,935
12		Bourne Shell	889	1,405	7,130
1		yacc	82	136	373
2		Assembly	42	93	253
5		DOS Batch	10	46	182
1		Teamcenter def	24	57	129
1		lex	25	0	125
3		make	17	12	94
1		Bourne Again Shell	6	16	23
1		C Shell	2	14	9
1		sed	0	3	4

emacs-21.1.tar.gz
758	Lisp	71,814	102,108	473,338
181	C	47,449	48,124	220,643
304	C/C++ Header	9,754	15,610	15,539
12	Bourne Shell	1,306	2,041	10,971
2	XML	91	106	4,262
2	Perl	337	59	1,036
1	C#	268	0	775
1	m4	44	19	469
6	DOS Batch	34	144	417
2	Assembly	42	93	253
1	Teamcenter def	27	65	138
1	lex	25	0	125
1	Bourne Again Shell	6	16	23
1	make	8	5	20
1	C Shell	2	14	9
1	sed	0	3	4

emacs-22.1.tar.gz
1,071	Lisp	118,419	150,649	894,478
183	C	52,107	58,872	238,055
12	Bourne Shell	3,103	2,881	24,153
316	C/C++ Header	11,182	18,132	17,358
1	XML	54	62	2,224
2	HTML	2	4	1,368
3	Perl	383	89	1,172
1	C#	269	0	778
6	DOS Batch	86	257	662
1	Patran Command Language	37	0	192
1	Python	24	49	159
1	m4	10	4	68
1	make	39	41	46
1	Bourne Again Shell	16	32	23
1	C Shell	7	18	9
1	Assembly	2	34	6
1	sed	0	5	4

emacs-23.1.tar.bz2
1,274	Lisp	123,494	159,385	935,625
176	C	49,795	56,490	231,086
11	Bourne Shell	3,309	2,757	25,216
135	C/C++ Header	6,366	9,441	13,917
6	Objective C	2,339	1,785	9,574
3	HTML	3	6	1,369
4	Perl	425	109	1,257
1	C#	268	0	772
6	DOS Batch	117	245	763
3	Python	56	101	333
1	Patran Command Language	36	0	190
1	m4	10	4	68
1	make	42	33	66
3	XML	17	18	43
1	Bourne Again Shell	17	31	23
1	C Shell	8	15	8
1	sed	0	5	4

んー、もうちょっと見やすくまとめなおそう。

■_ Ada

Ada じゅーよー

Ada matters! - By Dr. Robert Dewar (AdaCore)
Ada matters!

By  Dr. Robert Dewar

The computing industry is rather peculiar: If a technology is not the latest and greatest,
people think it has vanished entirely. You can, for example, often meet otherwise
knowledgeable people who think that mainframes and COBOL have completely disappeared.

Here at AdaCore, we often find people who think that Ada has disappeared and are surprised
to find out that not only is it still around - in the domain of large, critical
applications it is especially alive and well. For example, the new air-traffic control
system for the UK, iFACTS ( www.praxis-his.com/news/radarMar2007.asp ),is being written
from the ground up in Ada using the SPARK formal methods approach.

So why is Ada still around when many college students are learning Java, and there are 
even people around who think C and C++ are disappearing? The answer is remarkably simple.
A recent National Academy of Sciences report, "Software for Dependable Systems:
Sufficient Evidence?" ( http://books.nap.edu/catalog.php?record_id=11923 ), addresses
the issue of security-critical software, and states:

ではなぜ、多くの大学生が Java を学んでいて、さらに C や C++ が disappearing していると
考えている人すらいるときに Ada はまだ生き残っているのでしょうか?
その答えはとても簡単です。
最近の National Academy of Sciences report の
"Software for Dependable Systems: Sufficient Evidence?" 
では、serurity-criticcal なソフトウェアや stetes の問題に言及しています。


"The overwhelming majority of security vulnerabilities reported in software products
- and exploited to attack the users of such products - are at the implementation level.
The prevalence of code-related problems, however, is a direct consequence of higher-level
decisions to use programming languages, design methods, and libraries that admit these
problems."

There are no silver bullets when it comes to safety- and security-critical software. No
tools can guarantee success, but as this quote indicates, it helps to use appropriate
technology, including the right programming language. Last year's High Confidence Software
and Systems (HCSS) conference, sponsored by NSA to address security-critical issues,
featured an interesting presentation from Microsoft addressing such issues in the context
of Windows. The primary sources of problems in Microsoft's experience are buffer overruns
and integer overflow problems. Reasonable enough, so how can a programming language help?

safety-critcal であったり serurity-critical なソフトウェアについては、銀の弾丸は存在しません。
成功を保証できるツールもありませんが、上記の引用が示すように、
正しいプログラミング言語を含む適切な技術を使うことが助けになります。


The answer is: quite a bit. However, if we look at C or C++, these languages notoriously
have absolutely nothing to help avoid overruns. Microsoft is trying to add assertions to
C to help, and found about 100,000 possible buffer overflows in the Vista code. Ada, by
contrast, fully checks all array references as a matter of course, to eliminate the
possibility of buffer overflow.

Although Java is often cited as a safer alternative to C and C++, when it comes to
integer overflow, the semantics for Java can introduce some dangerous vulnerabilities. 
Overflows wrap silently, so that adding 1 to a positive number can suddenly make it 
negative. In Ada, every integer value can have a sensible range assigned, and 
automatic checks ensure that values do not go outside this range.

Java はしばしば C や C++ に対するより安全な代替物として看做されますが、
整数オーバーフローを考えたとき、そのJavaに対するセマンティクスは
いくつかの危険な脆弱性を持ち込む可能性があります。
オーバーフローは黙ってラップするので、正の数値に1加えたときに
突如としてその結果が負の数になってしまう可能性があるのです。
Ada においてはすべての整数値は sensible range を割り当てられていて、
値がその範囲からはみ出さないことを保証するための検査が自動的に行われます。

These are just a couple of small examples of how a language can help. It's not at all 
surprising that Ada should address issues like these; it was designed for the purpose 
of writing large critical programs, something that cannot be said of languages like C, 
C++, or Java. If you search language standards for features related to safety and 
security, you will draw a blank, unless you are looking at the Ada standard. With Ada, 
you will find a whole annex devoted to high-integrity programming.

Ada によって、high-integrity プログラミングのために devote された
annex 全体を見出すことでしょう。

Ada does not guarantee success, but as the NAS study indicates, it makes sense to use 
tools suitable for the purpose; if one's purpose is writing large safety- or 
security-critical programs, then Ada is a natural choice. That's why it should not be 
surprising that Ada continues to play a critical role and that Ada is a programmer's 
frequent companion. Many might not be aware of that fact, however. An example, though, 
is the avionics system of the new Boeing 787 Dreamliner, which makes extensive use of 
Ada. Of course, travelers won't be aware of this when they fly, and that's the point. 
Software that works properly is out of sight, and out of mind. Programmers who build 
such systems know the advantages of Ada - and continue to choose it as one key element 
of critical systems.

Dr. Robert Dewar is cofounder, president, and CEO of AdaCore; he also has had a 
distinguished career as a professor of Computer Science at the Courant Institute of 
New York University. He has been involved with the Ada programming language since its 
inception in the early 1980s and, as codirector of both the Ada-Ed and the GNAT 
projects, led the NYU team that developed the first validated Ada compiler. Robert was 
one of the authors of the requirements document for the Ada 95 revision, and he served 
as a distinguished reviewer for both Ada 83 and Ada 95. He has coauthored compilers 
for SPITBOL (SNOBOL), Realia COBOL for the PC (now marketed by Computer Associates), 
and Alsys Ada. He is also a principal architect of AdaCore's GNAT Ada technology. He 
has also written several real-time operating systems for Honeywell Inc. and frequently 
shares his thoughts on computers and on open-source software at conferences. He can be 
reached at dewar at adacore.com.

じかんたんねー

■_

■_

2011年10月25日

■_

例の本
買いました。 有隣堂やらジュンク堂あたりの大型書店では24日から売ってたところもあるようですが、 行ってる時間的余裕がなかったので今日に(って本来の発売日今日だよねえ)。 んでまあいろいろあるようですが wrong, rogue and booklog - 伝記の冒頭部分で描かれるのは、ジョブズ氏が1984年、思うように販売が進まない「マッキントッシュ」を売... wrong, rogue and booklog - 黙ってようと思ったんだけれど… 伝記「Steve Jobs スティーブ・ジョブズ」の翻訳者、井口耕二さんの語る翻訳作業の舞台裏とは? | 和洋風◎ 『スティーブジョブズI・II』の翻訳について-その1: Buckeye the Translator 『スティーブジョブズI・II』の翻訳について-その2: Buckeye the Translator 『スティーブジョブズI・II』の翻訳について-その3: Buckeye the Translator 『スティーブ・ジョブズ』を買っていい電子書店はどこか - ただのにっき(2011-10-24) ジョブズの本で考える、本の適正価格 « マガジン航[kɔː]

ぼつぼつ読んでいきます。
スティーブ・ジョブズ I
スティーブ・ジョブズ I

■_

■_

Island Life - 本の帯

けっこう好きなんですけどね。あれ(ジョブズ本のが、というのではなく帯一般)。 とはいえこれはなあと思うようなのも少なくないわけですが。

■_ Be Pythonic

Be Pythonic

Be Pythonic
Shalabh Chaturvedi, 12:30AM on 20 Nov, 2009

This article is intended for new users of Python.
本 article は Python の新規ユーザーに向けています

When going from one language to another, some things have to be unlearned (see Transfer of
Learning). What you know from other languages may not be always useful in Python. This page
contains some idioms used in Python that I particularly like, and I hope others find useful
in their quest for Pythonicity.

ある言語から別の言語へと移るとき、いくつかのことがらを unlearn しなければなりません。
あなたがほかの言語について知っていることは Python では有用ではないかもしれません。
このページでは、Python で使われているいくつかのイディオムを紹介します。
それは特にわたしが気に入っているものであり、ほかの人が Pythonicity を求めるときに
有用になるとよいと思っているものです。

You need counters rarely, and iterators only occasionally
カウンターが必要になることはほとんどなくて、イテレーターだけでほぼ用が果たせます

Wrong:
間違い(Python的でない)

  i = 0
  while i<10:
       do_something(i)
       i += 1

Pythonic:

  for i in xrange(10):
      do_something(i)

The following example indexes a list.
リストのインデックスを使うサンプルです

Wrong:
間違い(Python的でない)

  i = 0
  while i<len(L):
      do_something(L[i])
      i += 1

Pythonic:

  for item in L:
      do_something(item)

An iterator variable is useful when you want to maintain looping state between two 'runs':
二つの 'runs' の間で looping state を保持したいときにイテレーター変数は便利です。

  itrL = iter(L)

  for item in itrL:
      do_something(item)
      if is_some_condition(item):
          break

  for item in itrL:            # continues where previous loop left off
      do_something_else(item)  # 先のループの残りを続ける

You may not need that for loop
このようなループは必要ないかもしれません

Python provides many higher level facilities to operate on sequences, such as zip(), 
max(), min(), list comprehensions, generator expressions and so on. See Built-in 
Functions for these functions and more.

Python は zip()、max()、min()、list comprehensions、ジェネレーター式などといった
シーケンスを操作するための higher level な facitilites がたくさんあります。

Keep data in tuples, lists and dictionaries, and operate on entire collections for that
fuzzy Pythonic feeling. For example, here is some code that reads a CSV file (with first
row being the field names), converts each line into a dictionary record, and calculates
the sum on the 'quantity' column:

  f = open('filename.csv')                    # f is an iterator
  field_names = f.next().split(',')           # get the first item from the iterator using next()
  records = [dict(zip(field_names, line.split(',')))  for line in f]  # this will pull remaining lines
  print sum(int(record['quantity'])  for record in records)

Though a little naive (you should be using the csv module anyway, which is part of the 
Python Standard Library), this example demonstrates some useful features. Using zip() 
with dict() you can combine a tuple of field names with a tuple of values and make a 
dictionary - combine with list comprehensions you can do this to an entire list in one 
go.

Tuples are not read-only lists
タプルはリードオンリーのリストではない

Tuples usually indicate a heterogenous collection, for example (first_name, last_name) 
or (ip_address, port). Note that the type may be same (as in first_name and last_name 
may both be strings), but the real world meaning is usually different. You can think 
of a tuple as a row in a relational database - in fact the database row is even called 
a tuple in formal descriptions of the relational model. By contrast, a list of names 
is always a list, even though a particular function may not change it, that does not 
make it a tuple.

Tuple unpacking is a useful technique to extract values from a tuple. For example:
タプルのアンパッキングはタプルから値を extract するのに有用なテクニックです。

  for (ip_address, port) in all_connections:
      if port<2000:
          print 'Connected to %s on %s' % (ip_address, port)

Reading this code tells you that all_connections is a list (or iterable) contaning 
tuples of the form (ip_address, port). This is much clearer than using for item in 
all_connections and then poking inside item using item[0] or similar techniques.

Unpacking is also useful while returning multiple values from a function:

  name, ext = os.path.splitext(filename)    # split a file name into first part and extension
                                            # ファイル名を fist part と拡張子にわける

Classes are not for grouping utility functions
クラスはユーティリティ関数群のまとめるためのものではない

C# and Java can have code only within classes, and end up with many utility classes 
containing only static methods. A common example is a math functions such as sin(). In 
Python you just use a module with the top level functions.

Say no to getter and setter methods
getter メソッドや setter メソッドはいらないと言おう

Yes, encapsulation is important. No, getters and setters are not the only way to 
implement encapsulation. In Python, you can use a property to replace a member 
variable and completely change the implementation mechanism, with no change to any 
calling code.

Functions are objects
関数はオブジェクトである

A function is a object that happens to be callable. This example sorts a list of 
dictionaries based on the value of 'price' key in the dictionaries:

  #  define a function that returns useful data from within an object
  def get_price(ob):
      return ob['price']

L.sort(key=get_price)   # sort a list using the ['price'] value of objects in the list

You can also use sorted(L, key=get_price) to return a new list instead of modifying 
the list in-place.


■_ 記号がたくさん

Scala Punctuation Help : scala

I'm reading some Scala code, trying to learn the language and understand the code 
itself, and I keep coming across some unintelligible punctuation that does stuff. 
Problem is that it's pretty much impossible to search in any search engine for 
punctuation - it's all filtered out before the query get's processed. This is 
compounded by the fact that I haven't found any single document that outlines all the 
insane shortcuts that Scala seems to have in an easy way.

Can you point me to, or better yet write, such a guide? Just a comment/document/html 
page/blog post with a list of punctuation and the thing it does. In particular, I'm 
confused about:

    * ->
    * ||=
    * ++=
    * <=
    * _._
    * ::
    * :+=

Your help would be greatly appreciated!

Edit: added more to the list
Those can be methods or combination of assignments and methods, so the meaning depends 
on the class defining the methods. Without context here is the most likely 
interpretation:

-> is utility method creating a tuple: those are the same:

1 -> "one"
Tuple2(1, "one")
(1, "one")

||= is most likely apply the || method (such as boolean or) on a var and reassigning 
the result to it like in

  scala> var b = false; val a = true
  scala> b ||= a
  scala> b
  // Boolean = true    

This is similar to Java's int i = 0; i += 1 but generalized.

Same for ++=, where ++ most of the time concatenates Traversable (a collection)

  scala> var arr1 = Array(1)
  arr1: Array[Int] = Array(1)
  scala> arr1 ++= Array(2)
  scala> arr1
  // Array[Int] = Array(1, 2)

<= is likely less than equal

  scala> 1 <= 1
  // Boolean = true
  scala> 1 <= 0
  // Boolean = false

_._ is likely using placeholder syntax in an anonymous function. The first underscore 
is the object, the second the method being called. I'll have to think of an example. 
Edit: most likely this is invalid scala code. Can you post a larger context on this 
example?

:: is most likely use for adding (really prepending) an element to a list or pattern matching:

  scala> val l = 1 :: Nil
  l: List[Int] = List(1)
  scala> l match { case a :: Nil => a case _ => -1 }
  // Int = 1

:+= is most likely applying :+ to an object and reassigning to the var, where :+ appends an element to a collection.

  scala> var v = Vector(1)
  v: scala.collection.immutable.Vector[Int] = Vector(1)
  scala> v :+= 2
  scala> v
  // scala.collection.immutable.Vector[Int] = Vector(1, 2)

2011年10月24日

■_

日経ソフトウエア
買ったがまだほとんど読んでいない

表紙等に出てくるこのキャラが一部で話題に
日経ソフトウエア 2011年 12月号 [雑誌]

■_

■_

某球団の話はおおむね方向性が見えてきているようですが、まだなにも書かないw

■_

だめだ寝る。

■_

2011年10月23日

■_

Hacking: 美しき策謀 第2版 ―脆弱性攻撃の理論と実際
が出たというので本屋で探してみたら、前のとは値段がえらく違うのねえ(^^; 厚みも増えてるみたいだけど。
Hacking: 美しき策謀 ―脆弱性攻撃の理論と実際

274p → 564p ということなんだけど、目次を見た感じではなにが増えたのか良くわからなかった。 前のを読んだのもだいぶ前のことだしねえ。

O'Reilly Japan - Hacking:美しき策謀 第2版
謝辞
訳者まえがき
賞賛の声
はじめに
0x100 はじめに
0x200 プログラミング
    0x210 プログラミングとは何か?
    0x220 擬似コード
    0x230 制御構造
    0x231 if-then-else
    0x232 whileループとuntilループ
    0x233 forループ
    0x240 その他の基本コンセプト
    0x241 変数
    0x242 算術演算子
    0x243 比較演算子
    0x244 関数
    0x250 実際に使ってみる
    0x251 全体像を見る
    0x252 x86プロセッサ
    0x253 アセンブリ言語
    0x260 基本に立ち返る
    0x261 文字列
    0x262 符号付き、符号無し、長整数、短整数
    0x263 ポインタ
    0x264 フォーマット文字列
    0x265 キャスト
    0x266 コマンドライン引数
    0x267 変数のスコープ
    0x270 メモリのセグメント化
    0x271 C言語におけるメモリセグメント
    0x272 ヒープの使用
    0x273 エラー判定付きのmalloc()関数
    0x280 続・基本
    0x281 ファイルアクセス
    0x282 ファイルの権限
    0x283 ユーザID
    0x284 構造体
    0x285 関数ポインタ
    0x286 疑似乱数
    0x287 運試しゲーム
0x300 プログラムの脆弱性攻撃
    0x310 汎用的な脆弱性攻撃テクニック
    0x320 バッファオーバーフロー
    0x321 スタック上でのバッファオーバーフロー攻撃
    0x330 bashを用いた実験
    0x331 環境変数を使用する
    0x340 他のセグメントでのオーバーフロー
    0x341 ヒープセグメントでのオーバーフロー
    0x342 関数ポインタのオーバーフロー
    0x350 フォーマット文字列
    0x351 フォーマットパラメータ
    0x352 フォーマット文字列を利用した攻撃
    0x353 任意のメモリアドレスから読み込みを行う
    0x354 任意のメモリアドレスに書き込みを行う
    0x355 ダイレクトパラメータアクセス
    0x356 ショートライトを使用する
    0x357 .dtorsを狙った攻撃
    0x358 notesearchのさらなる脆弱性
    0x359 グローバルオフセットテーブル(GOT)の上書き
0x400 ネットワーク
    0x410 OSIの参照モデル
    0x420 ソケット
    0x421 ソケット関連の関数
    0x422 ソケットアドレス
    0x423 ネットワークのバイト順
    0x424 インターネットアドレスの変換
    0x425 簡単なサーバの例
    0x426 ウェブクライアントの例
    0x427 tinywebサーバ
    0x430 下位層に目を向ける
    0x431 データリンク層
    0x432 ネットワーク層
    0x433 トランスポート層
    0x440 ネットワークのスニッフィング
    0x441 生のソケットをスニッフィングする
    0x442 libpcapスニッファ
    0x443 階層を読み解いていく
    0x444 アクティブスニッフィング
    0x450 DoS攻撃
    0x451 SYN Flooding
    0x452 Ping of Death
    0x453 Teardrop
    0x454 Ping Flooding
    0x455 Amplification Attack
    0x456 分散DoS攻撃
    0x460 TCP/IPのハイジャック
    0x461 RSTを用いたハイジャック
    0x462 継続的ハイジャック
    0x470 ポートスキャン
    0x471 ステルス型のSYNスキャン
    0x472  FINスキャン、X-masスキャン、NULLスキャン
    0x473 デコイの使用
    0x474 アイドルスキャン
    0x475 積極的な防御策(シュラウド)
    0x480 ネットワーク経由でハッキングを行う
    0x481 GDBを用いた分析
    0x482 最後の詰め
    0x483 ポートバインド型シェルコード
0x500 シェルコード
    0x510 アセンブリ言語 VS. C言語
    0x511 アセンブリ言語によるLinuxのシステムコール
    0x520 シェルコードへの道
    0x521 スタックを用いたアセンブリ命令
    0x522 GDBを用いた調査
    0x523 nullバイトの除去
    0x530 シェルを起動するシェルコード
    0x531 優先順位の問題
    0x532 さらに小さく
    0x540 ポートバインド型シェルコード
    0x541 標準ファイル記述子を差し替える
    0x542 制御構造の実装
    0x550 コネクトバック型シェルコード
0x600 攻撃と防御の共進化
    0x610 攻撃を検知する
    0x620 システムデーモン
    0x621 シグナル超入門
    0x622 tinywebデーモン
    0x630 ハッカーの必需品
    0x631 tinywebdに対する脆弱性攻撃ツール
    0x640 ログファイル
    0x641 人ごみに紛れる
    0x650 見逃してはいけない明らかな兆候
    0x651 小分けにして考える
    0x652 すべてを元通りにする
    0x653 子プロセスでの作業
    0x660 高度なカムフラージュ
    0x661 ログに出力されるIPアドレスを詐称する
    0x662 ログレス攻撃
    0x670 全体インフラ
    0x671 ソケットの再利用
    0x680 ペイロードを隠密裏に搬入する
    0x681 文字列のコード化
    0x682 NOPスレッドの隠蔽
    0x690 バッファの制約
    0x691 ASCIIコードの印字可能文字だけで作られたポリモーフィックシェルコード
    0x6a0 さらなる対策
    0x6b0 実行不能スタック
    0x6b1 ret2libc
    0x6b2 system()へのリターン
    0x6c0 スタック領域のランダム化
    0x6c1 BASHとGDBを用いた調査
    0x6c2 linux-gateのバウンスオフ
    0x6c3 知識の応用
    0x6c4 最初の試み
    0x6c5 確率を味方にする
0x700 暗号学
    0x710 情報理論
    0x711 無条件安全性
    0x712 ワンタイムパッド
    0x713 量子鍵配布
    0x714 計算量的安全性
    0x720 アルゴリズムの実行時間
    0x721 漸近的計算量
    0x730 対称暗号
    0x731 Lov Groverの量子検索アルゴリズム
    0x740 非対称暗号
    0x741 RSA
    0x742 Peter Shorの量子因数分解アルゴリズム
    0x750 ハイブリッド暗号
    0x751 MitM攻撃
    0x752 SSHプロトコルによるホストのフィンガープリントの違い
    0x753 ファジーフィンガープリント
    0x760 パスワードクラッキング
    0x761 辞書攻撃
    0x762 総当たり攻撃
    0x763 ハッシュ検索テーブル
    0x764 パスワード確率マトリクス
    0x770 ワイヤレス802.11b暗号
    0x771 WEP(Wired Equivalent Privacy)
    0x772 RC4ストリーム暗号
    0x780 WEP攻撃
    0x781 オフライン総当たり攻撃
    0x782 キーストリームの再利用
    0x783 IVに基づく解読用辞書データベース
    0x784 IPリダイレクション
    0x785 FMS(Fluhrer、Mantin、Shamir)攻撃
0x800 まとめ
    0x810 参考文献
    0x820 リソース
索引
O'Reilly Japan - Hacking:美しき策謀
訳者まえがき
まえがき
1章	0x100	はじめに
2章	0x200	プログラミング
	0x210 プログラミングとは何か?
	0x220 プログラムの脆弱性攻撃
	0x230 汎用的な脆弱性攻撃テクニック
	0x240 マルチユーザにおけるファイル権限
	0x250 メモリ
		0x251 メモリの使用を宣言する
		0x252 文字列終端のNULLバイト
		0x253 メモリ領域のセグメンテーション
	0x260 バッファオーバーフロー
	0x270 スタックを足場にしたオーバーフロー攻撃
		0x271 攻撃コードを使わない攻撃
		0x272 環境変数の使用
	0x280 ヒープやbssを足場にしたオーバーフロー攻撃
		0x281 ヒープを足場にしたオーバーフローの基本
		0x282 関数へのポインタのオーバーフロー
	0x290 フォーマット文字列を利用した攻撃
		0x291 フォーマット文字列とprintf()
		0x292 フォーマット文字列の脆弱性
		0x293 任意のメモリアドレスを読み出す
		0x294 任意のメモリアドレスに書き出す
		0x295 ダイレクトパラメータアクセス
		0x296 dtorsを狙った攻撃
		0x297 GOTの上書き
	0x2a0 シェルコードを開発する
		0x2a1 よく使用するアセンブリ命令
		0x2a2 Linuxのシステムコール
		0x2a3 Hello, world!
		0x2a4 シェル起動コード
		0x2a5 他のセグメントを使用しないようにする
		0x2a6 NULLバイトの除去
		0x2a7 スタックを活用することでシェルコードをさらに小さくする
		0x2a8 ASCIIコードで表示可能な命令
		0x2a9 ポリモーフィックシェルコード
		0x2aa ASCIIコードの表示可能文字だけで作られたポリモーフィックシェルコード
		0x2ab Dissembler
	0x2b0 libcへのリターン
		0x2b1 system()へのリターン
		0x2b2 libcへのリターンの連鎖的な実行
		0x2b3 ラッパを使用する
		0x2b4 libcへのリターンを用いてNULLを出力する
		0x2b5 1回の呼び出しで複数のワードを出力する
3章	0x300	ネットワーキング
	0x310 ネットワーキングとは?
		0x311 OSIの参照モデル
	0x320 興味深い階層の詳細
		0x321 ネットワーク層
		0x322 トランスポート層
		0x323 データリンク層
	0x330 ネットワークのスニッフィング
		0x331 アクティブスニッフィング
	0x340 TCP/IPのハイジャック
		0x341 RSTを用いたハイジャック
	0x350 DoS攻撃
		0x351 Ping of Death
		0x352 Teardrop
		0x353 Ping Flooding
		0x354 Amplification Attack
		0x355 分散DoS攻撃
		0x356 SYN Flooding
	0x360 ポートスキャン
		0x361 ステルス型のSYNスキャン
		0x362 FINスキャン、X-masスキャン、NULLスキャン
		0x363 デコイの使用
		0x364 アイドルスキャン
		0x365 積極的な防御策(シュラウド)
4章	0x400	暗号学
	0x410 情報理論
		0x411 無条件安全性
		0x412 ワンタイムパッド
		0x413 量子鍵配布
		0x414 計算量的安全性
	0x420 アルゴリズムの実行時間
		0x421 漸近的計算量
	0x430 対称暗号
		0x431 Lov Groverの量子検索アルゴリズム
	0x440 非対称暗号
		0x441 RSA
		0x442 Peter Shorの量子因数分解アルゴリズム
	0x450 ハイブリッド暗号
		0x451 MiM攻撃
		0x452 SSHプロトコルによるホストのフィンガープリントの違い
		0x453 ファジーフィンガープリント
	0x460 パスワードクラッキング
		0x461 辞書攻撃
		0x462 総当たり攻撃
		0x463 ハッシュ検索テーブル
		0x464 パスワード確率マトリクス
	0x470 ワイヤレス802.11b暗号
		0x471 WEP(Wired Equivalent Privacy)
		0x472 RC4ストリーム暗号
	0x480 WEP攻撃
		0x481 オフライン総当たり攻撃
		0x482 キーストリームの再利用
		0x483 IVに基づく解読用辞書データベース
		0x484 IPリダイレクション
		0x485 FMS(Fluhrer、Mantin、Shamir)攻撃
5章	0x500	まとめ
		参考文献
索引

んーむ。ジョブズ本があるし後回しでいいかなあ。

■_ shibuya.lisp

Shibuya.lisp » Blog Archive » 括弧への異常な愛情 または私は如何にして心配するのを止めてCommon Lispを愛するようになったか Shibuya.lisp » Blog Archive » Compiler言語に負けないハッキング耐性を持ちながら更なるセキュアなアプリ構築を容易にしたSecure Scheme Suite の提案 Shibuya.lisp » Blog Archive » Lispマシンを作ってみた

トップバッターの方は時間配分を間違えた感じがあったのが残念ですね。 時間が足りなくなって飛ばしてしまったスライド(と内容)が気になるw

二番目のセッションはどうにもわたしには狙いどころが良くわかりませんでした(^^;

で、本日の主役 :) こういう (ハード寄りという意味での) low-level な話は大好きです。 命令フォーマットの設計とか興味津々で聞いてました。 んで、DRAMの制御のあたりはやはり難しいのだなあと。 わたしは仕事でもメモリーコントローラーに丸投げ(リセット直後にパラメーターセットするだけ) しかやったことがないので、FPGAで云々というのはやるときついでしょうね。

LT 編はまた。 はやみずさんの飼っているハリネズミが可愛いのはわかった :)

そのLTで発表できるようなネタをようやく思いついたので、次回なんとかできるように頑張る (と自分にプレッシャー)。

■_

twitter で気になる発言があったときに、 どういう意図でそのように発言したのかを確かめたいことがままあるのだけど、 それが RT で流れてきたもので自分とフォローしている/されている の関係がない人 だったりするとどう切り出したものやら悩んでしまって結局何もしないということが。 喧嘩売ってるようにとられちゃかなわんしねえ。

で、そういうものの例を挙げようとしたらなぜか発言主がそのツイートを削除してしまったw

■_ ばーがー

以前から気にはなってたんですよ、 「ハンバーグ」でひとつの単語なんだからそこから「バーガー」だけ切り出して 「テリヤキバーガー」とか「チーズバーガー」とかいうのは変じゃないかと。 最近なにかのときに基本あれは「サンドウィッチ」であって、 ~バーガーと呼ぶのは日本語化された結果だと教えてもらいました (マクドナルドに限ったことではないそうです)。

マクドナルドのハンバーガーはサンドイッチだった | 水無月ばけらのえび日記

ビッグマック200円の話題でマクドナルドのサイトを見ていたのですが、驚きの発見が。

それはメニューのページ。


「ビッグマック」や「チーズバーガー」などのメニュー、一般的にはハンバーガーと呼ばれてい
ると思いますが、公式サイトのメニューに付けられた見出しのラベルは、なんと「サンドイッチ」。
下の方にも「サンドイッチとのお得なバリューセット」という文言がありますし、間違いなどで
はないようです。どうもマクドナルドでは、いわゆるハンバーガー類を正式には「サンドイッチ」
と呼ぶらしいですね。

■_ Java は

Is Java Really Losing Popularity Among Developers? 本当に developer たちからの支持をなくしてしまったの? というのを TIOBE index 結果から推察。

Is Java Really Losing Popularity Among Developers? | Java.net

Is Java Really Losing Popularity Among Developers?
Posted by editor on October 22, 2011 at 1:17 AM EDT

In his latest post, Dustin Marx points us to an article by Paul Krill which was originally
posted on InfoWorld, titled Survey: Java losing popularity among developers. The article
is subtitled: "If recent trends continue, C could supplant Java as the most popular
programming language by next month."

Being a student of numbers and graphs and statistics and mathematical modeling of all types
of data (see, for example, my 1999 Stock Market Modeling Techniques paper), I found this
title and subtitle both provocative and interesting. I wasn't surprised to find that the
base data for the article was the latest TIOBE Programming Community Index (October 2011).
Their October headline is "Java is losing ground despite its new version 7 release."
And the first sentence is:

    Java lost almost 1% of its popularity in September. If this trend continues, C will
    be number one again next month. 

Huh? So, are they saying that 1% of global Java developers were suddenly laid off in 
October? That seems unlikely! What are we really talking about here? Let's take a look 
at the TIOBE October 2011 graph:

(略)

Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Oracle and Java 
are registered trademarks of Oracle and/or its affiliates. Other names may be 
trademarks of their respective owners.

reddit での反応。

Is Java Really Losing Popularity Among Developers? : programming


tl;dr version: Java isn't losing it's mindshare, it's losing it's sex appeal.


If it ever had any. Jave got that backoffice Cobol feel a long time back. (I am not 
saying that it is a bad thing).


Oh, it had sex appeal...in 1995.

Seriously. People got excited about it. A language that didn't lock you in to Microsoft
tools? A language that you could write a program in Windows, compile on a UNIX
workstation, and run on MacOS? Applets that could be embedded into webpages? This was
sexy stuff, back then.


Yep. I was thrilled to move to Java from years of C++, and before that C. Automated 
garbage collection, without any horrible auto_ptr stuff? Built in cross-platform gui 
tooling? And later on, the magic of reflection and generics...

Mind you, now I've moved on again, to a range of newer languages (as suits the environment)
- [J]Ruby, (Java|Coffee)Script, Scala, maybe if I'm lucky some Clojure. Java is a fine
language, but it's stagnated, and all these languages have moved beyond it.

C ?

It's still more run-anywhere than Java ever was - from 8-bit-CPUs to odd 20-bit and 
24-bit processors.

    Simplicity has always been a design goal of Java.

I don't agree. Scheme is simple.

I think that Java had as design goals:

    * Platform portability
    * Being safe
    * Adding certain features that C and C++ didn't have in the language itself to reduce
      fragmentation across platforms. Threads, networking, GUI stuff, etc.
    * Improving the way in which interfaces to modules were exposed.
    * Adding GC

    A simple languages means complicated (or at least verbose) code.

I disagree. Well, okay. At an extreme point, a simple-to-the-exclusion-of-all-elese 
language might do that. Say you had a Turing machine or something.

I think that Java's verbosity tends to be due at least in part to two factors: (1) 
wanting to avoid hard-to-read abbreviated terms of the sort that show up all over in C 
and (2) its original lack of generic containers (so that casting showed up everywhere 
a container does).

    Sex appeal was not a goal.

Possibly not in designing the language itself, though its marketing tried really, 
really hard to attach "cool" and "Java".

    In this context simplicity means a lack of features (generics, value semantics, all
    that crazy shit you read about when you read a C++ standard).

Java has generics and also pass-by-value semantics.


    Java has generics

Still rudimentary when compared to Scheme macros, or C++ templates and constexpressions.

As someone who has made a good living from Java for ten years,

IT'S TOO DAMNED VERBOSE!!!!

That said, Java has produced some great pragmatic libraries, like Spring, Ibatis, Hibernate,
and Wicket. While they lack the panache of C++'s STL, they make real-world "plumbing"
problems go away.

But still, yeah, I'm tired of writing Java.


C is my first love and last love.


The JVM still has potential, Java the language does not.


That's the biggest question.

Everyone has been saying for 10 years that Java is dying, but then what on earth 
should replace it?

    * Redditors say Python. (and okay, a few say Ruby)
    * Scala fans say Scala
    * Clojure fans say Clojure
    * Haskell fans say... nothing (hmmmm)
    * Go fans say Go!
    * Groovy fans say Groovy
    * Cylon fans say nothing (but they do have a plan)
    * Lua fans say Lua
    * Putri fans say Putri
    * F# fans say F#
    * etc etc

Meanwhile, there's barely a language that really is getting the critical mass that Java has.
There's just 20 semi-popular and over a 100 obscure languages all claiming to be The Next Java.

なんで Haslell fan はなにも言わんのだろう?

■_ 心配?

sympy - Python library for symbolic mathematics - Google Project Hosting

SymPy is an open source Python library for symbolic mathematics. It aims to become a 
full-featured computer algebra system (CAS) while keeping the code as simple as possible
in order to be comprehensible and easily extensible. SymPy is written entirely in Python
and does not require any external libraries.

■_ Zed

古い発言が元で reddit でまた盛り上がってましたが

An interview with Zed Shaw

October 21, 2011

Who are you, and what do you do?

I am Zed A. Shaw and my life can currently be carved into three pieces of the pie:

I have written software for other people, and also created my own open source projects 
like Mongrel, Lamson, Mongrel2, and a bunch of others.

I now tend to write books teaching people to code, insane satirical blog posts to piss 
people off, essays on various topics, and I am the creator of one software methodology. 
Included in this is frequent speaking gigs at different conferences, teaching classes 
on programming, and just generally being a kind of Clown-Pauper-Prince of the software 
world.

I also attempt to make music and post everything I make, good or bad, as part of the 
act. I created Fretwar as an experiment in getting other people to give people a 
reason to make music and put it online. I've also built 3 guitars, two of which 
really suck and one which I love and play a lot.

(略)

What would be your dream setup?

This is my dream setup. It's a constant work in progress, but if I'm going to spend most
of my days and nights doing something I'm going to invest the time and money to have nice
good tools. That's part of the fun of technology. You can envision something that you want
to try or produce and then go looking around for a piece of tech to build or buy.

略

■_ Signs that you're a bad programmer

訳している余裕が

とりあえず大見出しのところを抜き出し。

Signs that you're a bad programmer - Software Engineering Tips

Signs that you're a bad programmer

Why was this written?

Most of these faults were discovered the hard way by the author himself, either because he
committed them himself or saw them in the work of others. 

This paper is not meant for grading programmers, it was intended to be read by programmers
who trust their ability to judge when something is a sign of bad practice, and when it's a
consequence of special circumstances.

This paper was written to force its author to think, and published because he thinks 
you lot would probably get a kick out of it, too.

1. Inability to reason about code
2. Poor understanding of the language's programming model
3. Deficient research skills / Chronically poor knowledge of the platform's features
4. Inability to comprehend pointers
5. Difficulty seeing through recursion
6. Distrust of code


Signs that you are a mediocre programmer

1. Inability to think in sets
2. Lack of critical thinking
3. Pinball Programming
4. Unfamiliar with the principles of security
5. Code is a mess

このあともいろいろ続く

■_

これも別の機会に Design mistakes in mixed C C and Lua projects was: How can I be sure LuaJIT is working?

Design mistakes in mixed C/C++ and Lua projects | Hacker News

This is interesting. What made you adopt Io instead of Lua? Or was it dictated by the engine?


First, because I knew Io and not Lua. I had gotten interested in Io years before. Io 
was actually my first dynamic language, not Python or Ruby or Javascript. I stopped 
using Io for a few years when I moved on to other things, but _why's article "Io 
Has a Very Clean Mirror" brought it back to mind.

I seriously considered Lua but I felt object orientation needs to be incorporated very 
fundamentally in a language. I had previous experience with mIRC which shares Lua's 
idea of "everything is a table", and while mIRC is no doubt productive I 
felt tables would be a step backwards compared to Io's objects.

At the time I started, the C/C++ binding frameworks for Lua were not as mature as they 
are now, not as numerous, or I simply wasn't aware of them.

From a language aesthetic standpoint my decision came down to Io, or Ruby, but I looked at
the C Ruby source code and it didn't seem very suited to embedding. For instance the
official implementation of Ruby had some dependence on global/static variables which
precluded the idea of running multiple instances of the VM in a process. Io allows this,
although I haven't used it yet; I plan to use it to support threading, one VM per thread.
And basically the Ruby interpreter codebase wants to own main() and call my code as a
library; I wanted to own main() and call the interpreter as a library. Io supports this,
and it's codebase is smaller.

■_

2011年10月22日

■_

・大盛堂
創業者のエピソードが昨日辺りのついったーで流れてましたが、 西武百貨店のある辺りから今のところに移ったのっていつ頃でしたっけ?

・フリーソフト Free software

・twitter でによによ

・買った
漢晋春秋司馬仲達伝三国志 しばちゅうさん(1) (イブニングKC)
同じ作者の別の作品があわせて発売されていたのだけど、 シュリンクされていて中身を見られなかったので結局買わなかった。 たぶん大外れにはならないと思うのだけど、 上下巻をノーチェックでぽんと買うほどの余裕が今はないので(^^; そりゃあ店員さんに見せてくれといえば見せてもらえるのだろうけど、心理的障壁高いのよね。 シュリンクせざるを得ない事情はわからんでもないのだけど、どうにかならんもんですかい喃。
大アレ国志 上巻 (MFコミックス フラッパーシリーズ) 大アレ国志 下巻 (MFコミックス フラッパーシリーズ)

・んで、こういうのも買った。
アド・アストラ 1 ─スキピオとハンニバル─ (ヤングジャンプコミックス・ウルトラ)
雑誌はほとんど追いかけなくなっているのでこういう作品があったとは気がつかなんだ。

・shibuya.lisp#7

行ってきた。あとで書く。

■_ reddit で訊け

Perl 6を学びたい。どうすれば? というお悩み。

Learning Perl 6, a good idea? : perl


I've never used Perl, but I'm intrigued by its philosophy and community. I'm currently 
thinking of learning Perl 6, but is it perhaps too early? When discussing the features 
of Perl 5 most people mention CPAN and how great it is, but my understanding is that 
there is no such thing for Perl 6 yet. Also, I'm unsure about the state of 
documentation and books. My question is: Why should one learn Perl 6 nowadays and what 
does it have to offer?

わたしは Perl を使ったことがありませんが、その philosophy であるとかコミュニティに
興味があります。今、Perl 6を学んでみようかと考えているのですが、まだ早すぎるでしょうか?
Perl 5の機能について議論をしたとき、ほとんどの人は CAPN とそれがどれほどすごいもので
あるかに言及します。でもわたしの理解は Perl 6 でそれにあたるものはまだないという
ものです。また、Perl 6のドキュメントや書籍の整備の状況についてよく知りません。
わたしの疑問はこうです:
Perl 6を今日学ぶべき理由と、offer すべきものはなにか?



Perl 6 Modules lists ~100 modules which worked with Rakudo at some time in the past, 
but that's no guarantee they work now.

The book Using Perl 6 is a work in progress. It needs a lot of editing. Beyond that, 
you probably need to scour the Perl 6 specification and trawl through several blog 
posts.

Learning something new is often a good thing in and of itself.

    Learning something new is often a good thing in and of itself.

This is the main reason for why i'd encourage people to look at Perl 6.


I love the ideas behind perl 6, and the language has some amazing things in it, but 
the implementations are all quite limited right now.

わたしは perl 6の背景にあるアイデアが好きだし、言語そのものもいくつかの amazing な
ものを持っています。けれども、その実装は現状では非常に限定されたものに過ぎません。

Perl is in a very awkward place right now, with perl 5's arrow syntax being quite 
different from the "." syntax all the other languages have standardized on, 
and it's C based implementation being oriented around command line, unix, and single 
threaded short running applications. It's asynchronous IO is a bit clunky and it's 
threading, while I've found rather easy to use, seems to cause lots of people trouble.

Perl 6's promises to address a lot of 5's issues eventually, it's syntax is much more 
appropriate for today's programming, but the implementations are all incomplete and 
still quite a way from being ready for production. From what I understand none of the 
implementations have touched threading in a meaningful way.

To me, learning perl 6 as a way to broaden your programming horizons makes sense, but 
if you want to actually do anything with it, go for perl 5.


If you are interested in a useful language, learn Perl 5. But if your interest goes 
beyond that and you're interested in languages, Perl 6 is totally amazing and worth 
learning.

あなたが有用な言語に興味があるのなら Perl 5を学びましょう。
そうではなくて乗り越えようとしているものだとか言語そのものに興味があるのなら
Perl 6 は totally amazing で学ぶ価値のあるものでしょう。


Chromatic expresses why Perl 6 isn't much use at the moment as a practical language 
pretty well. That being said, Perl 6 takes all the greatest and best ideas from the 
popular dynamic languages, tidies them up and puts them all in 1 place for you to play 
with, and then occasionally introduces bugs to them.

If you're looking for community, Perl 5 is still the place to be, and with Moose and 
Method::Signatures and a few other tools you get a language approaching the futuristic 
idea's of Perl 6.

■_ マクロ

もうひとつ reddit から。

small question about the case macro in common lisp : lisp

consider:

  (defun test (x) (case x ((1 2 3 a b c) t) (t 'nil)))

  (test 1) -> t

  (test 'c) -> t

  (test 'f) ->nil

ok fine. makes sense. But because case is a macro, the list of symbols to compare x 
against in each clause of the case statement is not being evaluated. So what if I 
wanted to do something like

  (case 1 ((range 5) t) (t 'nil)) -> nil

even though 1 is certainly in (range 5). I dont know much about CL, so I made up some 
random crap like

  (case 1 (`(,range 5) t) (t 'nil)) ->nil

and other variants. I even tried:

  (let ((x '(1 2 3)) (case 1 (x t) (t 'NIL)) ->nil

and

  (let ((x '(1 2 3)) (case 1 ((x) t) (t 'NIL)) -> nil

So how can I get the case macro to actually expand the first argument of a clause 
inside a case statement?


(let ((list '(a b c d e f g)))
       (cond 
         ((member 'e list) :yes)
         (t :no)))


Yes. Much better than my suggestion. :)


yes cond is certainly the right way to go in that particular case, but I was wondering 
the syntax to force case (or similar macro) to eval the case keys.

Long story short, I believe CASE works the way it does because of historical performance
considerations (which are probably still pertinent today). Look at why and how switch
statements work in C to gain some insight. However, you can make a new macro that takes
something that looks like a case statement and converts it into a COND statement. For
instance, see CLISP's macro EXT:FCASE for an example of how you might do this, although
I don't think FCASE does exactly what you want.

Edit: In case you don't have the source at hand, here is what I have in my personal 
util library (adapted/stolen from CLISP source):

#-clisp
(defun case-expand (whole-form form-name test keyform clauses)
  (let ((var (gensym (concatenate 'string (symbol-name form-name) "-KEY-"))))
    `(let ((,var ,keyform))
      (cond
        ,@(maplist
           #'(lambda (remaining-clauses)
               (let ((clause (first remaining-clauses))
                     (remaining-clauses (rest remaining-clauses)))
                 (unless (consp clause)
                   (format t "~a: missing key list" whole-form)
                   (break) )
                 (let ((keys (first clause)))
                   `(,(cond ((or (eq keys 'T) (eq keys 'OTHERWISE))
                             (if remaining-clauses
                                 (format t "~a: the ~a clause must be the last one"
                                         whole-form clause )
                                 't))
                            ((listp keys)
                             `(or ,@(mapcar #'(lambda (key)
                                                `(,test ,var ',key))
                                            keys)))
                            (t `(,test ,var ',keys)))
                     ,@(rest clause)))))
           clauses)))))

#-clisp
(defmacro fcase (&whole whole-form
                 test keyform &body clauses)
  (case-expand whole-form 'fcase test keyform clauses))


No, case does not evaluate case keys. You can use read-time evaluation if you want to 
test for constants, like this:

(defconstant +foo+ (list (gensym) (gensym)))

(defun bar (x)
  (case x
    (#.+foo+ 100)
    (t 0)))

That will only work for compile-time constants, though.


I think everybody ends up writing that macro. You should, too, it's a good exercise :).

誰もが結局はそういうマクロを書くものだと思うし、あなたもそうすべきだろう。
いい練習になるよ :)

But if you don't want to, you can use alexandria:switch.

■_ Perl Search Engine

あるあるなお悩みから。

Perl Search Engine – Perl Hacks

Perl Search Engine

Often on sites like StackOverflow you'll see questions that people could have answered 
for themselves if they had just searched the right web sites (usually perldoc or CPAN). 
But instead, they just went straight for Google and ended up with some dodgy, out of date
information that just left them confused.

StackOverflow のようなサイトでは、webサイト(通常は perldoc とか CPAN) を検索するだけで
質問者自身が回答を見つけられるような質問をしばしば見かけます。
彼らはそういったことはせずにただ単にぐぐっていまい、結局のところ
doggy で混乱を招くだけのような out of date な情報をつかんでしまっています。

In order to get round that, I've created a Google Custom Search Engine which searches 
known Perl web sites. You can try it out here.

そういった状況に対処するために、
既知の Perl web サイトを検索する Google Custom Search Engine を作ってみました。


If you want to use this search engine on your site, the code is below.
<div id="cse" style="width: 100%;">Loading</div>
 <script src="//www.google.co.uk/jsapi" type="text/javascript"></script>
 <script type="text/javascript">
 google.load('search', '1', {language : 'en'});
 google.setOnLoadCallback(function() {
 var customSearchControl = new google.search.CustomSearchControl('008350714774536055976:a2zesuxuecs');
 customSearchControl.setResultSetSize(google.search.Search.FILTERED_CSE_RESULTSET);
 customSearchControl.draw('cse');
 }, true);
 </script>
 <link rel="stylesheet" href="//www.google.com/cse/style/look/default.css" type="text/css" />

■_

Please explain Haskell for a layperson : haskell

I know programming a little, and every programming news site I visit talks/praises about
Haskell. Since I have a poor mathematical/theoretical background on CS, I can't see why
Haskell is admired by a huge amount of people. Could any of you please explain me in a
very intuitive way as to why Haskell could become better than C/C++/Java and so on? What
are its weakness and strength?

わたしは少ししかプログラミングを知らないのですが、わたしが訪れるプログラムニュースサイトは
どこも Haskell について言及しています。わたしのコンピューター科学に関する数学的な
背景だとか理論的な背景は poor なものなので、なぜ Haskell がこれほど多くの人から
賞賛されているのかが理解できないのです。なぜ Haskell が C/C++/Java などよりも
良いものになる可能性があるのかを、直感的な方法でわたしにどなたか説明しては
もらえないでしょうか? Haskell の弱点と強みとは何でしょうか?


This is a very common question in this sub-reddit. See cdsmith's recent comment to 
another thread for some relevant reading material:

http://www.reddit.com/r/haskell/comments/l7wtd/why_learn_haskell/c2qi03c

There are a multitude of reasons why people like Haskell over other languages. I think 
in the end you'll need to read up, get your feet wet and see for yourself.

Edit: Here's another link that may be helpful: 
http://amtal.github.com/2011/08/25/why-haskell-is-kinda-cool.html


"Why Functional Programming Matters"


Read Learn You A Haskell for a hands-on introduction to Haskell.

Why use Haskell?

Haskell is type-safe. Where other languages let you write code that mistakenly passes 
a string to a function that takes an int, Haskell refuses to compile such code. 
There's a joke in the Haskell community that when your code finally does compile, it's 
guaranteed to be bug-free. There's a grain of truth in that, because most bugs are the 
result of poorly-typed code.

Haskell は型安全です。他の言語があなたに int を引数にとる関数に文字列を間違って
渡してしまうコードを書くのを見過ごしてしまうのに対して、Haskell はそのような
コードのコンパイルを拒絶するのです。
コードがコンパイルできれば、それはバグがないコードであることが保証されるという
冗談が Haskell コミュニティにはあります。
大部分のバグというものは poorly-typed なコードのためなので、
この冗談にはわずかながらも真実があります。

Although Haskell is strictly typed, its type system is also rich. You can easily write 
your own custom data types, called records, and Haskell can automatically figure out 
how to print, compare, and sort instances of your types if you write deriving (Eq, Ord, 
Show). Haskell's algebraic type system lets you construct data structures of arbitrary 
complexity, by building onto types such things as [Thing], a list of Things, or 
[[Thing]], a matrix of Things, or Tree Thing, a tree of Things. Again, Haskell 
automatically figures out how to print, compare, and sort these abstract types, too.

Haskell は厳格に型付けされるものですが、その型システムは rich なものでもあります。
record と呼ばれるあなた独自のカスタムデータ型は簡単に書けますし、
Eq、Ord、Show の deriving を記述していれば
Haskell は自動的にあなたのその型のインスタンスの print、compare、sort を
自動的に figure out できるのです。


Haskell is pure. Code for computations, x = 2 + 2, is separate from code for side 
effects, putStrLn (show x). For newbies, this one is an inconvenience, but once you 
get used to it, it's quite powerful.

Haskell is parallel. Because Haskell is pure, parallelization is trivial. As long as 
code has no side effects and doesn't share variables, it can be run in multicore mode. 
See YelloSoft.

Haskell is lazy. Because Haskell is pure, Haskell can intelligently decide when to 
perform calculations. It's normal to write a Haskell function like primes :: [Int] 
that returns the infinite list of prime numbers. How do you use such a thing? You only 
take a finite chunk of numbers from it at a time. take 5 primes -> [2, 3, 5, 7, 11]

Haskell is declarative. Haskell's pattern matching allows you to write clear, concise 
functions.

  fib 0 = 0
  fib 1 = 1
  fib n = fib (n-1) + fib (n-2)

It's just like a partial function in mathematics.

Where other languages use try/catch blocks to handle errors, Haskell code mostly uses 
the Maybe a type, where a is a type of your choice. If you're parsing an integer, 
you'll could use maybeRead :: Maybe Int, which either returns Just x, where x is the 
successfully parsed integer, or Nothing, to signify that the parse failed. The type 
system itself is the error handling mechanism.


One word: composition.

The bane of modern software engineering is that software is complex, and no one can 
sanely hold all the details of a large project in their mind at the same time. The key 
is to find ways to express the result in smaller pieces which are individually 
understandable. The problem then becomes that when you take two pieces and put them 
together, they end up doing something you didn't expect or want.

Haskell, more through culture than anything else, manages this. Various people here 
have pointed to technical merits, but at the end, it's really the culture that these 
technical merits have encouraged/forced/enabled which allows for this.

ほかにもたくさん回答が寄せられていますが省略。

■_ キッド

ダイナマイト・キッド。覚えてる。

平野耕太†247 ドリフターズ 不死身の化物などこの世におらん!! 

675 名無しんぼ@お腹いっぱい [sage] 2011/10/21(金) 19:37:38.65 ID:/vYWLLQ20 Be:
    ノブ:義務教育終えてる奴で知らんやついないだろう
    与一:ひょうふっと矢を射る人、古典でやるよね
    お豊:誰だ1号
    菅野:誰だ2号
    ハンニバル:世界史取ってなかったからよくは知らんかった、知ってるのキーワードくらい
    スキピオ:同上
    ワイルドバンチ:キッドは聞いた事ある、ブッチはごめん
    アナスタシア:誰だ3号
    他の廃棄者:知ってる
    晴明:神社とか某漫画が昔流行ったよね
    サンジェルマン:オカルト系好きだとどっかで確実に引っかかる人
    多聞:名前は知ってる程度

    とりあえず知らん・よく知らん人らが扱われてる本を暇な時に読みたいなと思う
    確か過去スレで何度かお勧め上がってたよなぁ 

679 名無しんぼ@お腹いっぱい [sage] 2011/10/21(金) 19:45:03.26 ID:G6CqGuw+0 Be:
    >>675
    ブッチが分からない時点で、そのキッドは「ビリー・ザ・キッド」と間違えてる気がするんだが
    通常、ブッチ・キャシディとサンダンス・キッドのセットで記憶されてるはず
    つか、こいつらがバラ売りされてるのって見た事ない 

680 名無しんぼ@お腹いっぱい [sage] 2011/10/21(金) 19:49:17.48 ID:XuwCFXa40 Be:
    キッドは弾きれても戦えるんだろ。
    テキサスクローバーホールドとかスピニングトゥホールドとかで。 

681 名無しんぼ@お腹いっぱい [sage] 2011/10/21(金) 19:52:05.72 ID:zr6dCZdQ0 Be:
    ペキンパー映画で見た筈だが、正直忘れとった>キッド&ブッチ 

682 名無しんぼ@お腹いっぱい [sage] 2011/10/21(金) 19:58:20.51 ID:I0eO/ETV0 Be:
    いまのいままでビリーザキッドのことだと思ってたw 

683 名無しんぼ@お腹いっぱい [sage] 2011/10/21(金) 19:58:49.39 ID:4uFwYTH80 Be:
    キッドと言われて思い出すのはテリー・ザ・キッドよりダイナマイト・キッド 

684 名無しんぼ@お腹いっぱい [sage] 2011/10/21(金) 20:02:13.93 ID:jg/6maUE0 Be:
    サンダウン・キッドかな 

685 名無しんぼ@お腹いっぱい [sage] 2011/10/21(金) 20:05:03.99 ID:G6CqGuw+0 Be:
    >>681
    ペキンパーの「ワイルドバンチ」は強盗団の名前こそ同じだがコイツらとは関係無いはず 

686 名無しんぼ@お腹いっぱい [sage] 2011/10/21(金) 20:14:55.75 ID:3rJnwv3vO Be:
    ブッチとサンダンスは明日に向かって撃てで知ったな
    あれももう40年前の映画か。

687 名無しんぼ@お腹いっぱい [sage] 2011/10/21(金) 20:16:25.55 ID:zr6dCZdQ0 Be:
    >>685
    あー関係ないのか。どおりで。 

688 名無しんぼ@お腹いっぱい [sage] 2011/10/21(金) 20:30:27.63 ID:/vYWLLQ20 Be:
    >>679
    いや、あれなんだ、ますむらひろしの昔の作品で
    サンダンスキッドが猫で出ててな
    ブッチは猫のありがちな名前だと思って完全スルーしてたんだ… 

693 名無しんぼ@お腹いっぱい [sage] 2011/10/21(金) 20:41:16.00 ID:tmPrcpf10 Be:
    >>683
    ダイナマイト・キッドといえば佐山タイガーのデビュー戦・・・って年バレるなw

    でもキッドといえばペガサス・キッドだろ
    そういえば中の人=クリス・ベノワも悲しいというか無惨な最期だったなぁ 

706 名無しんぼ@お腹いっぱい [sage] 2011/10/21(金) 21:06:39.27 ID:4uFwYTH80 Be:
    >>693
    エディ・ゲレロとか新日ジュニア→WWF(WWE)レスラーはなんというか落差の大きい人生になっちゃってるなぁ…



    gdgd妖精s面白ぇ 

■_

■_ 返事が来たよ

2011年10月21日

■_

無印良品
たまにいくと面白げな文房具が増えてたりするので見逃せない。

文房具といえば Amazon.co.jp: 最強の文房具 (別冊宝島) (別冊宝島 1786 カルチャー&スポーツ): 美崎栄一郎: 本 Amazon.co.jp: ニッポンの新オドロキ文房具―技術に、機能に、デザインに世界が驚嘆する! (別冊GoodsPress): 本 Amazon.co.jp: すごい文房具 リターンズ (CIRCUS MAX 11月号増刊): KKベストセラーズ: 本 最近この辺の本を立て続けに買って(微妙に内容が被ってないから困ったもんだ :)、 これいいなあ、あれいいな、これ試してみたいなあなどと楽しんだり。

■_ 「属性」

使い分け難しい

Perlについての質問箱 48箱目

755 デフォルトの名無しさん [sage] 2011/10/21(金) 13:27:53.49 ID: Be:
    用語の質問です。
    Perlのオブジェクト指向では、「attribute」と「property」の両方が使われているようなんですが、
    これらはどのように使い分けられていますか。
    ググってみたけど、いまいちわかりません。

    package Hogehoge;
    sub new {
     my $class = shift;
     return bless {@_}, $class;
    }
    sub x { return $_[0]->{x} };
    sub y { return $_[0]->{y} };

    my $hoge = Hogehoge->new(x=>1, y=>2);
    print $hoge->{x}; # これはattribute? property?
    print $hoge->x; # これはattribute? property?

758 デフォルトの名無しさん [sage] 2011/10/21(金) 14:43:43.08 ID: Be:
    >>755
    こういう認識しか無いんだけど、こういうのとは違うん?
    http://perldoc.perl.org/perlglossary.html

    インスタンス変数
    > instance variable
    > An attribute of an object; data stored with the particular
    > object rather than with the class as a whole.

    アクセサ
    > accessor methods
    > A method used to indirectly inspect or update an object's state
    > (its instance variables). 

759 デフォルトの名無しさん [sage] 2011/10/21(金) 15:53:56.50 ID: Be:
    sub x : lvalue { $_[0]->{x} };
    sub y : lvalue { $_[0]->{y} };

    こういうのかな。
    メソッドでもLvalue subroutineと呼ばれてる希ガス。 

760 デフォルトの名無しさん [sage] 2011/10/21(金) 16:53:02.26 ID: Be:
    755です。
    もいっかい調べ直したところ、Perlでの「attribute」というのは、オブジェクト指向とは関係なく、
    関数定義において付属的に追加できるデータのことのようです。
    ttp://gihyo.jp/dev/feature/01/perl-pluggable/0002
    でもオブジェクト指向の説明でもよく見かけるように思うし、どうなんでしょ。 

761 デフォルトの名無しさん [sage] 2011/10/21(金) 17:06:03.59 ID: Be:
    perlの言語仕様でいうところのattributeはサブルーチンやレキシカル変数に
    つけられるやつの方だけど、オブジェクト指向でもattributeという言葉は
    よく使われるのでperlのオブジェクト指向ライブラリの一つのMooseみたいに
    その意味でattributeを使っちゃってることもある。どれを指しているかは
    よく考えながら読むしかないね。 

762 755 [sage] 2011/10/21(金) 17:20:01.32 ID: Be:
    こっちはインスタンス変数をプロパティといっている。
    ttp://d.hatena.ne.jp/chaichanPaPa/20100206/1265436393
    > 結果的にリファレンスが、ハッシュ変数(プロパティ)とサブルーチン(メソッド)を持つことになるのです。
    > プロパティとメソッドと言えば、そう、オブジェクトになるのですね…これが!!

    こっちはインスタンス変数とアクセッサの両方をプロパティと呼んでいるっぽい。
    http://idocsq.net/page/350

    うーん。用語が統一されてない。

■_ 限定継続

原語では delimited coutinuation つーのですね。

Delimited continuation - Wikipedia, the free encyclopedia


Delimited continuation

In programming languages, a delimited continuation, composable continuation or partial 
continuation, is a "slice" of a continuation frame that has been reified 
into a function. Unlike regular continuations, delimited continuations return a value, 
and thus may be reused and composed.

プログラミング言語において、delimited continuation もしくは composable continuation
とか partial continuation というものは、ある関数へと reified (具現化?) された
continuation frame の“スライス”である。通常の continuation とは異なり
delimited continuation は値を返す。したがって、再利用されたり組み合わされたりする
可能性がある。

「限定継続」だから limited ~ かと思ったのですが違うのですね。 というかなんで「限定」継続?

delimitedの意味 - 英和辞典 Weblio辞書

delimited
【形容詞】
1

限界がある、または境界を作る

(having the limits or boundaries established)

a delimited frontier through the disputed region 紛争地域を通って区切られた国境
delimitの意味 - 英和辞典 Weblio辞書

delimit

区切る, 限界を定める

用例
delimit [限界を定める,区切る]

These motifs consist of clusters of hydrophobic residues which are delimited from one 
another by short stretches of Asp, Glu, Pro and other residues favoring the formation 
of loops. (Plant Mol Biol) 

■_

Island Life - O(n^2)正規表現

では、NFAでもDFAでもO(n^2)は避けられないのか、というとこの正規表現については 高速化の
可能性はある。

まずこのパターンは、"@"が入っていない文字列にはマッチしようがない。 したがっ
てあらかじめ"@"を入力文字列中から探して、見つからなければ マッチ無しと断定で
きるので、真面目に入力をひとつづつずらしながらマッチを試みる 必要はない。一般的には、
パターン中に「必ずマッチしなければならない部分文字列」 がある場合に、それを取り出して
Boyer-Mooreなどの高速な部分文字列検索を 行うことで、マッチしない場合を高速に除外できる。 
これをやってるエンジンを見たことはあるんだけど、Perlだったかな。

ちょっと方向が違いますが、GNU の regex がマッチする文字列の先頭に来うる文字集合を チェックしてて、その集合に入ってない限り読み飛ばすということをしています。 言及されている「必ずマッチしなければならない部分文字列」を検索するのは Perl だったと思います。ほかでもやっているかもしれないけど(最近のは(特にPCRE) 眺めてないのでどう変わったかよくわかってない)。

perl はこの辺かな

/* Most of decisions we do here should have been done at compile time.
   The nodes of the REx which we used for the search should have been
   deleted from the finite automaton. */

char *
Perl_re_intuit_start(pTHX_ REGEXP * const rx, SV *sv, char *strpos,
		     char *strend, const U32 flags, re_scream_pos_data *data)
{

(さくっと略)

  restart:
    /* Find a possible match in the region s..strend by looking for
       the "check" substring in the region corrected by start/end_shift. */
    
    {
        I32 srch_start_shift = start_shift;
        I32 srch_end_shift = end_shift;
        if (srch_start_shift < 0 && strbeg - s > srch_start_shift) {
	    srch_end_shift -= ((strbeg - s) - srch_start_shift); 
	    srch_start_shift = strbeg - s;
	}
    DEBUG_OPTIMISE_MORE_r({
        PerlIO_printf(Perl_debug_log, "Check offset min: %"IVdf" Start shift: %"IVdf" End shift %"IVdf" Real End Shift: %"IVdf"\n",
            (IV)prog->check_offset_min,
            (IV)srch_start_shift,
            (IV)srch_end_shift, 
            (IV)prog->check_end_shift);
    });       
        
    if (flags & REXEC_SCREAM) {
	I32 p = -1;			/* Internal iterator of scream. */
	I32 * const pp = data ? data->scream_pos : &p;

	if (PL_screamfirst[BmRARE(check)] >= 0
	    || ( BmRARE(check) == '\n'
		 && (BmPREVIOUS(check) == SvCUR(check) - 1)
		 && SvTAIL(check) ))
	    s = screaminstr(sv, check,
			    srch_start_shift + (s - strbeg), srch_end_shift, pp, 0);
	else
	    goto fail_finish;
	/* we may be pointing at the wrong string */
	if (s && RXp_MATCH_COPIED(prog))
	    s = strbeg + (s - SvPVX_const(sv));
	if (data)
	    *data->scream_olds = s;
    }
    else {
        U8* start_point;
        U8* end_point;
        if (prog->extflags & RXf_CANY_SEEN) {
            start_point= (U8*)(s + srch_start_shift);
            end_point= (U8*)(strend - srch_end_shift);
        } else {
	    start_point= HOP3(s, srch_start_shift, srch_start_shift < 0 ? strbeg : strend);
            end_point= HOP3(strend, -srch_end_shift, strbeg);
	}
	DEBUG_OPTIMISE_MORE_r({
            PerlIO_printf(Perl_debug_log, "fbm_instr len=%d str=<%.*s>\n", 
                (int)(end_point - start_point),
                (int)(end_point - start_point) > 20 ? 20 : (int)(end_point - start_point), 
                start_point);
        });

	s = fbm_instr( start_point, end_point,
		      check, multiline ? FBMrf_MULTILINE : 0);
    }
    }
    /* Update the count-of-usability, remove useless subpatterns,
	unshift s.  */

う。記憶にあるのとだいぶ違う(上記のコードは 5.12 のもの)……また時間見つけて読まねば。

引用したコードの最後のほうにある fbm_instr ってのが、 Boyer-Moore 法を使った固定文字列検索。のはず。

■_ MATLAB's function syntax is abysmal

MATLAB はぜんぜん知らんのですが。

MATLAB's function syntax is abysmal : programming


    MATLAB's syntax is abysmal

FTFY

It's pretty decent for doing interactive calculations in a terminal, but it quickly 
falls apart when you have to do longer scripting.


This is exactly how I feel about bash - it's nice for interactive uses, but it quickly 
becomes incredibly unwieldy when you have to do longer scripting.

I was talking to a guy once who was doing some research for his sociology PhD or 
something. He mentioned how he had an 80,000-point dataset and he had done all the 
statistical analysis on it in shell script because he didn't know anything else. I 
cringed a little when I herd that.

Oh...my...god


What? An 80k dataset isn't that large, and if he's got the shell utilities to do the 
computations you want, shell doesn't seem unreasonable at all for it. I've processed 
much larger things from the shell.

In fact, if the computations you are doing permit processing a stream and you're 
running a whole pipeline of computations, using a shell pipeline may well be both 
vastly more memory-efficient (doesn't need to load the dataset into memory) and faster 
(pipelines give you some degree of free parallel processing) than the alternative you 
may have been thinking of.

The problem I have with shell is mostly that:

    * the straightforward thing in string processing is usually also not the bulletproof
      to do things, due to whitespace issues

    * shell has a bazillion weird little features to learn (at least in bash and zsh; 
      maybe back in the day, it was smaller)

    * fancy data structures are a pain, which is either not a problem or very annoying, 
      depending upon your task

    * shell code itself isn't that fast, though stringing together shell utilities can be
      just fine.

    using a shell pipeline may well be both vastly more memory-efficient (doesn't need 
    to load the dataset into memory) and faster (pipelines give you some degree of free 
    parallel processing) than the alternative you may have been thinking of

What is the alternative you have been thinking of that doesn't support stream processing?
I use Python and iterator support is fine..

    MATLAB's programming language is abysmal

FTFTFY


    MATLAB is abysmal

FTFTFTFY

    Mad

FTFU


U mad, bro?


    MATLAB is not a programming language FTFTFTFY


    MATLAB is abysmal

FTFY

で、元記事。

Matlab function syntax is abysmal « Dale Peterson

Matlab function syntax is abysmal
By luke, on October 12th, 2011

Today I was helping some undergraduates in a mechanical vibrations course to use ode45. 
The way you specify the right hand side of the ode's must fit Matlab's particular 
form (using an @ before the function name, which must be contained in a file of the 
same name, with a ‘.m' extension). Looking at the documentation, I found this gem 
that really made me want to suck start a shotgun:

One way to provide additional parameters to a functional argument of a function 
function is to write a file that:

-- Accepts the additional parameters as inputs
-- Invokes the function function
-- Contains the function called by the function function as a nested function

That last one is a real doozy. Try saying that 5 times real fast, then explain what 
the hell it means to an undergrad. I'd rather explain what a pointer to pointer to 
char is, personally.

■_ チェックリスト

自分が作った新言語をアピールする材料探しのためのチェックリスト?

Programming Language Checklist

 Programming Language Checklist
by Colin McMillen, Jason Reed, and Elly Jones.

You appear to be advocating a new:
[ ] functional  [ ] imperative  [ ] object-oriented  [ ] procedural [ ] stack-based
[ ] "multi-paradigm"  [ ] lazy  [ ] eager  [ ] statically-typed  [ ] dynamically-typed
[ ] pure  [ ] impure  [ ] non-hygienic  [ ] visual  [ ] beginner-friendly
[ ] non-programmer-friendly  [ ] completely incomprehensible
programming language.  Your language will not work.  Here is why it will not work.

You appear to believe that:
[ ] Syntax is what makes programming difficult
[ ] Garbage collection is free                [ ] Computers have infinite memory
[ ] Nobody really needs:
    [ ] concurrency  [ ] a REPL  [ ] debugger support  [ ] IDE support  [ ] I/O
    [ ] to interact with code not written in your language
[ ] The entire world speaks 7-bit ASCII
[ ] Scaling up to large software projects will be easy
[ ] Convincing programmers to adopt a new language will be easy
[ ] Convincing programmers to adopt a language-specific IDE will be easy
[ ] Programmers love writing lots of boilerplate
[ ] Specifying behaviors as "undefined" means that programmers won't rely on them
[ ] "Spooky action at a distance" makes programming more fun

Unfortunately, your language (has/lacks):
[ ] comprehensible syntax  [ ] semicolons  [ ] significant whitespace  [ ] macros
[ ] implicit type conversion  [ ] explicit casting  [ ] type inference
[ ] goto  [ ] exceptions  [ ] closures  [ ] tail recursion  [ ] coroutines
[ ] reflection  [ ] subtyping  [ ] multiple inheritance  [ ] operator overloading
[ ] algebraic datatypes  [ ] recursive types  [ ] polymorphic types
[ ] covariant array typing  [ ] monads  [ ] dependent types
[ ] infix operators  [ ] nested comments  [ ] multi-line strings  [ ] regexes
[ ] call-by-value  [ ] call-by-name  [ ] call-by-reference  [ ] call-cc

(略)

■_


一つ前へ 2011年10月(中旬)
一つ後へ 2011年11月(上旬)

ホームへ


リンクはご自由にどうぞ

メールの宛先はこちらkbk AT kt DOT rim DOT or DOT jp