ときどきの雑記帖 i戦士篇 2009年1月(中旬)

2009年01月20日

■_

・シーゲートのハードディスクはありましたが、問題の型番ではありませんですた。

・東スポに中村優の記事が
元々グラビアアイドルだったのか。そっち方面疎いから知らなかったｗ

・なんか紛らわしいこと極まりないPython本の、Py3k対応版が21日発売? → 書籍情報―はじめてのPython3 本書は前著「はじめての Python」を「Python 3.0」用に加筆修正したものです。「Python 3」は「Python 2」と細かい点でかなり異なっているので、コードや説明は、全面的に見直しました。また、第6章を大幅に加筆しています。

・ふと、麻奈様の「はじめてのプログラミング」(だったと思う)を書店で手にとってぱらぱらと眺めてみた。 Cで書かれたサンプルプログラムの解説で、参照呼び(call by reference)の説明が間違ってる＞＜ Cの本は間違ってなかったと思うんだけどなあ。こっちのが古いとか?


Eagle Beta 1.0.3301.37337 Released - PLNews: Programming Language News
"Eagle Beta 1.0.3301.37337 has been released. Eagle is an implementation of Tcl for the .NET CLR. "
http://plnews.org/posts/eagle_beta_10330137337_released_20090116_073047.html


Hop 1.10.0 Released - PLNews: Programming Language News
"Hop 1.10.0 has been released. Hop is a higher-order language designed for developing Web applications. "
http://plnews.org/posts/hop_1100_released_20090116_073859.html

■_ 苦労じゃ?

【Java SE 7】 次世代Javaの動向 ７ 【dolphin】 
492 デフォルトの名無しさん [sage] Date:2009/01/11(日) 22:47:05  ID: Be:
    今言えるのは、このスレみたいな状況下でクロージャぶち込んでも混乱するだけ。
    プログラマーが苦労するか楽するかだけの問題ならね。 




598 デフォルトの名無しさん [sage] Date:2009/01/13(火) 23:53:25  ID: Be:
    C#にはヘジたんという言語設計のプロがいるが
    Javaは素人が寄せ集まってるだけなので
    どちらが優れているのかは言わずもがな
    このままでは差は開いて行くばかり 

600 デフォルトの名無しさん [sage] Date:2009/01/13(火) 23:57:13  ID: Be:
    >>598
    それを言うなら、Sunだって言語仕様策定のプロ中のプロのGuy Steele Jr.が居るだろw
    まあ、Guy SteeleはJavaに関しては言語機能を追加する方向では
    関わって無さそうな気はするけど。 

601 デフォルトの名無しさん [sage] Date:2009/01/14(水) 00:13:41  ID: Be:
    >>600
    仕様策定ではなく仕様書作成に関わってるだけじゃね？ 

602 デフォルトの名無しさん [sage] Date:2009/01/14(水) 00:18:19  ID: Be:
    GLSは仕様策定のプロというよりも仕様書書きのプロだろ 

603 デフォルトの名無しさん [sage] Date:2009/01/14(水) 00:32:40  ID: Be:
    しかしSchemeは最初からボスと二人でやってるからなあ。
    あれだけでも凄い。
    他にもConnection Machine Lispがある。
    これも強烈。 

605 デフォルトの名無しさん [sage] Date:2009/01/14(水) 00:51:54  ID: Be:
    正直言ってGLSが最初から設計してたらJavaはもっとましな言語だっただろうな
    というのはFortressの言語仕様見てて思った。近代的な静的型言語なら最初から
    あれくらいは欲しいところだ(並列処理や演算子オーバーロード周りの部分はさすがに
    チャレンジングなところがあるけど) 

606 デフォルトの名無しさん [sage] Date:2009/01/14(水) 00:55:17  ID: Be:
    >>602
    仕様書書くことと仕様策定は密接に関わりがある作業だと思う。
    それに、仕様書書くだけじゃなくてC,Fortran,Common Lispとかの仕様
    策定にも関わってたはずだけど。 

607 デフォルトの名無しさん [sage] Date:2009/01/14(水) 07:10:41  ID: Be:
    Common Lispの仕様策定に関わってたらマイナスだろ
    取捨選択せずにすべて取り込むとかセンスがない
    ただし、あれを書き上げたのは天才 

608 デフォルトの名無しさん [sage] Date:2009/01/14(水) 11:00:55  ID: Be:
    Ken Arnold や James Gosling がスルーされてカワイソス 

616 デフォルトの名無しさん [sage] Date:2009/01/14(水) 17:23:44  ID: Be:
    VMでコード再利用が出来て、
    豊富なライブラリが存在して、
    通信、DB、GUIの仕様が決まっていれば、
    便利だということを証明したことがJavano最大の功績だった。 

617 デフォルトの名無しさん [sage] Date:2009/01/14(水) 18:01:24  ID: Be:
    なにこの過去に縋った流れ 

618 デフォルトの名無しさん [sage] Date:2009/01/14(水) 19:16:24  ID: Be:
    お復習ですやん 

626 デフォルトの名無しさん [sage] Date:2009/01/14(水) 23:11:20  ID: Be:
    しかし、なんだな
    .NETとJavaは用途が異なるから似たような技術であっても
    住み分けるはずだ、と言われていたが
    最近はそうでもないんだな

    まぁまだJavaの方が強いと思うけど、これから先はわからんね 

631 デフォルトの名無しさん [sage] Date:2009/01/15(木) 01:17:45  ID: Be:
    VB化するC#とCOBOL化するJava
    どっちがマシなんでしょうかｗｗｗｗｗｗｗｗ 

633 デフォルトの名無しさん [sage] Date:2009/01/15(木) 01:25:18  ID: Be:
    別に好きに選んでる人はいると思うけどな
    俺は世間に流されるが！ 

637 デフォルトの名無しさん [sage] Date:2009/01/15(木) 14:08:48  ID: Be:
    >>616
    LispのVMが出れば最強、そういうことですね？ 

638 デフォルトの名無しさん [] Date:2009/01/17(土) 22:58:19  ID: Be:
    http://www.atmarkit.co.jp/fdotnet/special/linqtoxml/linqtoxml_01.html
    これはいつJavaに入りますか？ 

639 デフォルトの名無しさん [sage] Date:2009/01/17(土) 23:11:21  ID: Be:
    LINQ to XMLは確かにすごく使いやすいけど
    この標準無視の独自性はMSならでは
    さすがにJavaにこういうのは入らないだろうな 

640 デフォルトの名無しさん [sage] Date:2009/01/18(日) 03:15:06  ID: Be:
    >>638
    川俣晶か…相変わらずイタい文章書いてるな、この人
    ＞XMLという技術を襲った最大の災厄とは、「僕の賢さ」を誇示しようとする
    ＞「精神の子どもたち」の大挙流入にあるといえる。
    とか根拠レスで自分の思い込み書いてるだけだし。あと、技術的にも
    間違いが多いから、この人の書く技術系記事は基本的に信用できん 

641 デフォルトの名無しさん [sage] Date:2009/01/18(日) 03:27:56  ID: Be:
    その人とは関係ないけどVBの小ネタ記事なんかもっとすごいよ。
    MSDNによくあるけど「特集１１号 これは目からうろこ！！VBプログラマ必見！」とかｗ

    VBもC#も７年後も同じような言語仕様として存在するかどうか怪しいし、
    その人も同じ主張で責任を持っていられるかどうかも怪しい。
    結局そういうキモイ世界で頑張ってられるようなITドカタが集まった世界、
    「類友ドカタ」ってことじゃね？ｗ 

642 デフォルトの名無しさん [sage] Date:2009/01/18(日) 05:28:59  ID: Be:
    LINQだけど、ODBMSの標準化界隈では一応こんな話もあるという事で。
    http://www.odbms.org/blog/2008/08/linq-is-best-option-for-future-java.html 

643 デフォルトの名無しさん [sage] Date:2009/01/20(火) 00:47:05  ID: Be:
    >>492
    苦労じゃ

    どうしても言ってみたかったんです。ごめんなさい。。。 

644 デフォルトの名無しさん [sage] Date:2009/01/20(火) 01:26:21  ID: Be:
    >>643
    おまえはITドカタ決定！

えー、わしも「苦労じゃ」ネタは使ったことあるんだがw

この会社辞めようと思ったソースコード＃1B 
355 仕様書無しさん [] Date:2009/01/05(月) 21:19:38  ID: Be:
    ２年前に会社辞めた奴の残したコード

    } catch(Exception e) {
        Exception x = new Exception();
        x.initCause(e);
        e.initCause(x);
        throw x;
    }

356 仕様書無しさん [sage] Date:2009/01/06(火) 14:04:19  ID: Be:
    俺はクミコ系なので、スローとキャッチの意味は推測なのだが、
    その残したコードは恨みか愉快犯か故意犯か、どれかに思えるな。 

357 仕様書無しさん [sage] Date:2009/01/06(火) 15:06:32  ID: Be:
    >>355
    これ、試しに書いてみたら、
    stackTrace出すと、stackOverflowでこけるな
    initCauseの時点では問題なさげだけど、参照をお互いに保持してるから、
    printStackTrace()とかを呼ぶと、問題になるね

    意図せずにこんなコード書かないだろうから、
    遠回しな悪意の表明だろうなぁｗ 

358 仕様書無しさん [sage] Date:2009/01/06(火) 18:35:17  ID: Be:
    x.initCause(e); // ちくしょう…
    e.initCause(x); // ちくしょう…
    throw x; // ちくしょぉぉぉぉぉぉぉぉ!!

    に見えた。

【Perl,PHP】LLバトルロワイヤル3【Ruby,Python】
512 デフォルトの名無しさん [sage] Date:2009/01/19(月) 20:35:40  ID: Be:
    ＄＠％の記号やブロックに｛｝を使うrubyか、
    インデントの崩れない、かつ、sysやらreやらを書かなくていいpythonか、
    MSやSUNと仲が良くて、馬鹿でも分かりやすいようにしか書けないperl
    みたいな言語を誰か作って。 

514 デフォルトの名無しさん [sage] Date:2009/01/19(月) 20:37:00  ID: Be:
    自分で作るしか 

517 デフォルトの名無しさん [] Date:2009/01/19(月) 21:17:07  ID: Be:
    結局、最終的には
    C言語・Java・Pythonの三つが勝ち残ると思うな。
    というわけでLLはPythonで決まり。
    でもPythonの発想に近いのはC言語ではなくPascalだと思うんだよね。
    C言語的発想なのはRubyでしょ。
    教育用かプログラマに出来ることを阻害しないかということで。 

518 デフォルトの名無しさん [sage] Date:2009/01/19(月) 21:25:57  ID: Be:
    Perlより標準ライブラリの品揃えのいいPythonを「教育用」ってのは
    なんか違う気がするぞ
    明らかに「実用的」にするためにあんだけのバッテリーを積んでるんだし
    Cとの連携のためのFFIも標準で入れてるわけだろ 

519 デフォルトの名無しさん [sage] Date:2009/01/19(月) 21:30:47  ID: Be:
    言語なんて大差ねえだろ、それにIronPythonなんてキワモノじゃん・・・
    なんでそんなのに盛り上がってんだ・・
    普通CPythonだし・・
    個人的にはRubyじゃなく、Scalaが流行ればいいな 

520 デフォルトの名無しさん [sage] Date:2009/01/19(月) 21:34:35  ID: Be:
    VMで動く言語は全部LLの代用にはならん
    巨大でコンパイルが必要で起動も遅いもん

    Scalaが取るべきポジションはJavaの代替であってLLの代替じゃない 

521 デフォルトの名無しさん [sage] Date:2009/01/19(月) 21:50:55  ID: Be:
    >>520
    いやだから今はVMに載ってるけど、
    別に言語としてはそういうJavaのポリシーみたいなものは無いし継承してないでしょ？
    LLに誰かする人は出てもおかしくないよ 

526 デフォルトの名無しさん [] Date:2009/01/20(火) 05:15:30  ID: Be:
    日本ではPHPやVBが強いけど
    米国ではそうじゃないんだよね。
    C++が依然強大だしVBよりもC#のほうが使われてる。
    日本だとRubuの仕事はあってもPythonは皆無といっていいけど
    米国じゃ結構仕事あるみたいだし。
    日本の場合、基幹ソフトが少ないからC++よりVBなんだろうと思う。
    WEB系で米国はJava・JavaScript・C#が強いのに対し
    日本はPHP・ActionScriptが強いというのはおもしろいと思った。 

527 デフォルトの名無しさん [sage] Date:2009/01/20(火) 06:26:17  ID: Be:
    携帯向けが多いからかね。PHP,ASって 

528 デフォルトの名無しさん [sage] Date:2009/01/20(火) 06:44:47  ID: Be:
    >>526
    日本もある程度の規模以上だとWEB系はjavaばっかりじゃない？

    ゴミ案件は確かにPHPばっかり
    つーか、ゴミ案件を安値で安易に受けてPHPで安易に作ってPHPが巷に溢れてる感じ 

529 デフォルトの名無しさん [sage] Date:2009/01/20(火) 07:43:14  ID: Be:
    低価格で作って欲しいという需要はいっぱいあるからそれに応えるには
    必然的に人を安く雇えるPHPを選ぶほかないんだと思う。
    ただ敷居が低くなりすぎて技術者のレベル低下＆ダンピングが進んで
    Webデザイナー並になってるな。
    米国と違って冷遇されている日本ではPythonが流行ることは無いと思う。
    今まで通り糞案件を底辺PHPプログラマーが支え大規模はJavaという流れ。 

531 デフォルトの名無しさん [sage] Date:2009/01/20(火) 10:11:36  ID: Be:
    自分が社長やってると想像してみろよ。
    毎月売上に追われてるのに、末端社員がPythonがとかクロージャがどうとか
    言ってるとめんどくさいだろ。いいから
    PHP(スコップ)とかいうやつでとにかく早く作業を終わらせればいいんだよって思うだろ。 

532 デフォルトの名無しさん [sage] Date:2009/01/20(火) 10:45:32  ID: Be:
    そして技術革新に乗り遅れて自滅への一直線になるわけだな。
    いまだにPHP3だったりするんだろw 

533 デフォルトの名無しさん [sage] Date:2009/01/20(火) 10:49:28  ID: Be:
    逆に難しい 

535 デフォルトの名無しさん [sage] Date:2009/01/20(火) 16:10:41  ID: Be:
    そもそも言語ってどうやって作るの？
    作れるなら自分で作ってみたい 

536 デフォルトの名無しさん [] Date:2009/01/20(火) 16:16:23  ID: Be:
    マイクロソフトに入社 

537 デフォルトの名無しさん [sage] Date:2009/01/20(火) 16:41:18  ID: Be:
    >>535
    本格的なものは難しいが、原理は簡単
   テキストデータを読んでいって、何かするってだけ 

542 デフォルトの名無しさん [sage] Date:2009/01/20(火) 19:57:24  ID: Be:
    自分はPython使ってますが
    それそのもので開発するのではなく
    インタプリタであることを生かして
    ちょっとapiを試すのに重宝しています。
    こういう使い方してる人結構いると思います。
    PHPみたいにプロジェクトの
    主要開発言語に選ばれることは少ないので
    普及していないと錯覚されていますが
    自分が知る限りではPythonユーザー相当数いますよ。 

543 デフォルトの名無しさん [sage] Date:2009/01/20(火) 20:11:07  ID: Be:
    //Rhino犀強伝説

    (function(cmdlArgs,　index,　argsLength)　{
    　
    　if　(index　<　argsLength)　{
    　　
    　　java.lang.System.out.print(readFile(cmdlArgs[index]));
    　　
    　　arguments.callee(cmdlArgs,　index　+　1,　argsLength);
    　}
    　
    })(arguments,　0,　arguments.length);

■_

Choosing a language for 2009

Posted by Piers Cawley Mon, 12 Jan 2009 17:31:00 GMT

The Prags will tell you that you should learn a new language every year, and I think 
they have a point. This year though, I’m going to do things slightly differently. If 
you read the Healthcheck: Perl article I wrote for Heise Online then you’ve probably 
worked out that my language for 2009 is Perl 5, version 10 (hopefully it’ll be 
version 10.1 real soon now). I’m still paid to write ruby for AmazingTunes in my day 
job, but Perl’s the language I learned to program with and developments around Moose 
and its extensions mean that Perl in 2009 is a different language from the one I 
pretty much stopped using a couple of years ago.

Time to get reacquainted.

I'm hedging my bets mind – I’m also working through Real World Haskell (which still 
sounds like an oxymoron – I probably haven’t read enough of it yet).

今年は新しいのに手を出さずに? Google Sumer Code でPerl 6に関するのをどうとかというが他であったような。

■_ SELECT * (続)

SELECT *を使うべき場面と言うのも存在します。
EXISTS述語のサブクエリ内では、SELECT * を使う
http://www.geocities.jp/mickindex/database/db_optimize.html#LocalLink4


◆SELECT * from A2009/1/20 14:59jijixi
http://jijixi.azito.com/cgi-bin/diary/index.rb?date=20090120#p01
こんなテーブル触りたくねえw もうなんつーか全然リレーショナルじゃないよね。

おっとフィールド100個というのはスルーしてましたw 確かにそれだけの数を全部列挙しろというのは無体な話ですし、触りたくねー作り直せボケというのも異論ありません。つかそんなに数があって正規形になってるのかなあ。とか。んで、ようやっと SELECT * すんなといってたページを見つけました → parseerror.com / sql / SELECT * IS EVIL

■_

教えてください！ -OKWave
Arrayってなんですか？ -OKWave
エラー箇所をお願いします。 -OKWave
間違いを教えてください。 -OKWave
この人のプロファイルにある自己紹介文に注目
発作的コーディング
カーネル開発者からのメッセージ(1)---LWN.net Jonathan Corbet氏：ITpro
Rubyの障害解析まで行うサポート・サービス，CTCが開始：ITpro
2008-11-05 - ラシウラ
配列のソートはいまさらいうまでも無いアルゴリズムですが、なぜか最初にくるアルゴリズムがバブルソートだったりするのはなぜでしょうか。正直バブルソートは直感的にわかりにくいと思います。
バカが征く on Rails 2009年01月20日
「みんなの迷惑になるから帰れ」っていえば済むことじゃん？そのほうがお互いのためになるんだし。
Twitter / Tajima: 死刑より苦しむ拷問刑というのを考えた。朝早く叩き起こ ...
ASCII by Jason Scott / FUCK THE CLOUD
Main Page - Croquet Consortium
Croquet is a powerful open source software technology that, in the form of the Croquet Software Developer's Kit (Croquet SDK), can be used by experienced software developers to create and deploy deeply collaborative multi-user online virtual world applications on and across multiple operating systems and devices. Derived from Squeak, the Croquet system features a peer-based messaging protocol that dramatically reduces the need for server infrastructures to support virtual world deployment and makes it easy for software developers to create deeply collaborative applications. Cobalt is a National Science Foundation-sponsored effort to develop an open source virtual world browser and authoring toolkit application based on the Croquet technology.

2009年01月19日

■_ xxxdup(3)

http://www.hi-matic.org/diary/index.cgi?20090118#18-2
めもがき: 2009/1/18 09:00

strndup(3)はGNU拡張ですが ISO/IEC TR24731-2にあるので、C1Xには入りそうな予感。

ちなみにGNU拡張にはstrdup(3)のワイド文字版wcsdup(3)はあれど
なぜかwcsndup(3)はないとゆー中途半端な状態、ふしぎ！

strdup(3)のalloca(3)版、strdupa(3)とかになるともう勘弁してちゅーかんじ。

なるほど単なる xxxxdup() だと呼び出し側がその領域の解放の面倒見なければならないからその手間を省くために alloca()で(ry という話ですか。気持ちはわかりますが、オマエそれはちょっと待てという感じですね。大体 strlcpy/strlcat をアレだけけなした頭があって strdupa とか作ろうという気になるのかと。というか、いいかげんライブラリアンとかリンカーの仕様まで踏み込んでかないと言語としてのCはもーどうにもならんような気がします。 C++だって、結局グローバルオブジェクトのコンストラクターやらデストラクターのために対応してもらう羽目になってますよね。まーそうすると、名前空間欲しいよね、とかアレとかコレとか言う方向にいって収拾つかなくなるのと、どこでもコンパイルできるという利点がかなり失われやすくなるでしょうけどってそーすればCからサヨナラできる?(笑)

■_ (SQL) SELECT * from

SQLの書き方なんですけどね。 SQL文「Select *」を使用するのは邪道？ - Insider.NET

SQL文「Select *」を使用するのは邪道？ - Insider.NET
■質問事項
ソース上に記述するSQL文において、たとえばＡテーブルの
5割以上の項目を使用する場合のSELECT文で「select * from A」と
するのは避けましょうと言われます。
要するに使用する項目を1つずつちゃんと記述しなさいということなのです。

100項目あるようなテーブルの２，３個の項目を使用するためだけに、
「Select * from A」とするのは、レスポンスやメモリ使用率等の観点から
避けようという気にはなりますが、厳密にはどうなんでしょうか？

抽出されるレコード件数にも左右されるとも思われますが、皆さんが
ＳＱＬを書く上での持論をお聞かせ下さい。

ざっくりな質問になりましたが、ご意見を頂けると幸いです。
以上、よろしくお願い致します。

一ヶ月くらい前かそれよりもう少し前に、“SELECT * するようなプログラムを書くなボケ” (超意訳)的な主張をしている web ページを読んだのだけど(英語でしたが)、実際のところどうなんでしょうか。

自分はそのページにあった、* でまとめて持ってきてからごにょるんじゃなくて、対象となっているデータベースの構造を把握した上で必要なフィールド全部をきちんと指定して受け取れという意見に賛成です。

■_ OCmalネタふたつム板より

関数型言語ML(SML, OCaml, etc.), Part 5
813 デフォルトの名無しさん [sage] Date:2009/01/13(火) 10:25:50  ID: Be:
    lispわかってる人がOCamlマスターするのにかかる時間ってどのぐらい？
    3日じゃ無理？ 

814 デフォルトの名無しさん [sage] Date:2009/01/13(火) 12:24:20  ID: Be:
    >>813
    3時間ぐらい 

815 デフォルトの名無しさん [] Date:2009/01/13(火) 18:09:27  ID: Be:
    ↑↑馬鹿だろ 

816 デフォルトの名無しさん [sage] Date:2009/01/13(火) 18:17:27  ID: Be:
    >>813
    lispマスターがOCamlわかるのには大体3週間ぐらい。(これはマジレス)
    lispわかってる人がOCamlマスターできないと悟るのが3分くらい。

関数型言語ML(SML, OCaml, etc.), Part 5 
817 デフォルトの名無しさん [sage] Date:2009/01/17(土) 20:38:13  ID: Be:
    初Ocaml

    階乗計算を2通りやってみた。
    http://codepad.org/5vBjk9Cm

    どっちの書き方の方が多い？ 


OCaml code - 14 lines - codepad

let rec fact1 n =
  match n with
    0 -> 1
  | n -> n * fact1(n - 1);;

print_int (fact1 5);;

print_string "\n";;

let rec fact2 n = 
  if n < 2 then 1 
           else n * fact2(n - 1);;

print_int (fact2 5);;





818 デフォルトの名無しさん [sage] Date:2009/01/17(土) 21:00:36  ID: Be:
    let rec fac=function
    | 0 -> 1
    | x -> x*fac(x-1);;
    はどうよ？ 

819 デフォルトの名無しさん [sage] Date:2009/01/17(土) 21:13:25  ID: Be:
    >>818
    同意。 

820 デフォルトの名無しさん [sage] Date:2009/01/17(土) 21:16:50  ID: Be:
    >>817, >>818
    3通り
    http://codepad.org/5bAL8aRu 


OCaml code - 22 lines - codepad
let rec fact1 n = 
  match n with
    0 -> 1
  | n -> n * fact1(n - 1);;

print_int (fact1 5);;

print_string "\n";;

let rec fact2 n = 
  if n < 2 then 1 
           else n * fact2(n - 1);;

print_int (fact2 5);;

print_string "\n";;

let rec fact3 = function
  | 0 -> 1 
  | x -> x*fact3(x-1);; 

print_int (fact3 5);;




821 デフォルトの名無しさん [sage] Date:2009/01/17(土) 21:54:19  ID: Be:
    型の例
    http://codepad.org/UGqmVJcb 

822 デフォルトの名無しさん [sage] Date:2009/01/17(土) 22:01:22  ID: Be:
    凄く細かいことだけど、自分は OCaml なら fact (n + 1) と必ず空白を入れるかな。
    C や Java だと、その括弧は関数の引数を括るための特別な記号だけど、
    OCaml だとそういう意味はなく、単に演算の優先順位を示す普通の括弧だから
    2 * (3 + 4) の括弧に空白を入れるのと同じ理由で fact の後の括弧にも空白を入れる。

823 デフォルトの名無しさん [sage] Date:2009/01/17(土) 23:08:59  ID: Be:
    >>822の言うように修正したコード
    http://codepad.org/i8vprhP5 



OCaml code - 22 lines - codepad
let rec fact1 n = 
  match n with
    0 -> 1
  | n -> n * fact1 (n - 1);;

print_int (fact1 5);;

print_string "\n";;

let rec fact2 n = 
  if n < 2 then 1 
           else n * fact2 (n - 1);;

print_int (fact2 5);;

print_string "\n";;

let rec fact3 = function
  | 0 -> 1 
  | x -> x*fact3 (x-1);; 

print_int (fact3 5);;




824 デフォルトの名無しさん [sage] Date:2009/01/17(土) 23:20:24  ID: Be:
    let fact n = fold_left ( * ) 1 [2..n]
    とか書けたらいいのにと思いますた
    遅延計算で 

825 デフォルトの名無しさん [sage] Date:2009/01/17(土) 23:23:22  ID: Be:
    >>823を相互再帰にする。３つの関数のどこから計算しても同じ。
    http://codepad.org/x8n2Lk8r 




OCaml code - 16 lines - codepad
let rec fact1 n = 
  match n with
    0 -> 1
  | n -> n * fact2 (n - 1)
and fact2 n = 
  if n < 2 then 1 
           else n * fact3 (n - 1)
and fact3 = function
  | 0 -> 1 
  | n -> n * fact1 (n - 1);; 

print_int (fact1 5);;
print_string "\n";;
print_int (fact2 5);;
print_string "\n";;
print_int (fact3 5);;




826 デフォルトの名無しさん [sage] Date:2009/01/17(土) 23:51:52  ID: Be:
    Yコンビネータを2種類追加して全部で5通りになった。
    http://codepad.org/oGJ4Mwzh 




OCaml code - 27 lines - codepad
let rec fact1 n = 
  match n with
    0 -> 1
  | n -> n * fact2 (n - 1)
and fact2 n = 
  if n < 2 then 1 
           else n * fact3 (n - 1)
and fact3 = function
  | 0 -> 1 
  | n -> n * fact1 (n - 1) ;; 

(* チューリングの賢人鳥 *)
let rec turing's_sage f x = f (turing's_sage f) x ;;

(* カリーの雲雀 *)
let lark x (`M y) = x (fun z -> y (`M y) z) ;;
let curry's_sage f x = lark f (`M (lark f)) x ;;

print_int (fact1 5) ;;
print_string "\n" ;;
print_int (fact2 5) ;;
print_string "\n" ;;
print_int (fact3 5) ;;
print_string "\n" ;;
print_int (turing's_sage (fun f x -> if x = 0 then 1 else x * (f (x-1))) 5) ;;
print_string "\n" ;;
print_int (curry's_sage (fun f n -> if n = 0 then 1 else n * (f (n-1))) 5) ;; 




827 デフォルトの名無しさん [sage] Date:2009/01/17(土) 23:53:36  ID: Be:
    >>825
    相互再帰を入れれば全部で６通り。

828 デフォルトの名無しさん [sage] Date:2009/01/18(日) 00:24:56  ID: Be:
    >>824
    Haskellならできるね
    fact n = foldl1 ( * ) [1..n] 

829 デフォルトの名無しさん [sage] Date:2009/01/18(日) 00:35:06  ID: Be:
    PythonもHaskellよりはダサいですが一応出来ます
    from operator import mul
    fact = lambda n: reduce(mul, xrange(1, n+1)) 

830 デフォルトの名無しさん [sage] Date:2009/01/18(日) 15:24:18  ID: Be:
    末尾再帰バージョン
    http://codepad.org/vE2CJfG0




OCaml code - 8 lines - codepad

let rec fact = function
  | n -> fact2 n 1
and fact2 n m =
  match n with
    0 -> m
  | n -> fact2 (n - 1) (m * n) ;;

print_int (fact 5) ;;

OCamlのプログラム。見てもわかるようなわからないような。パターンマッチを自在に使えればおもしろいんだろーなあ。

■_ Perl 6

ループの話。

Operation on a Series of Integers in Perl 6
Operation on a Series of Integers in Perl 6

I was a bit silent about it but I keep working on the Perl6::Cookbook Here is one of 
the entries from chapter 2.

Iterating over a series of integers in a range is similar in Perl 6 to the same code 
in Perl 5 except of slightly different format of the foreach loop that is spelled only 
as for now.

ある範囲に存在している整数列を iterating over する場合、Perl 6でも
Perl 5の場合と大まかなところでは一緒であるが、foreach loop の形式が
異なっている。
#that is spelled only as for now ってのは
# foreach ってキーワードを使ったループの話?

 my $x = 23;
 my $z = 25;

 for $x .. $z -> $i {
     say $i;
 }

Will print the numbers 23, 24, 25 as expected.

これは数値の23、24、25を(予想通り)出力する。

C-style, 3-part for loops are also available in Perl 6 and they are called loop but 
they are not really recommended. Better to use the for loop as described above. You 
could say this, but it has the same issues with off-by-one errors as we have already 
learned to avoid in Perl 5.

C形式の三つのパートをもつ for ループもPerl 6で使うことができる。それはループとは呼ばれ
ているものではあるものの、実際に使うことはお薦めしない。上で例示した形式のループを使う
ほうが好ましい。以下のような形式のループも使えはするけれども、これはPerl 5ですでに我々
が捨てることを学んだはずのoff-by-one エラー問題がつきまとっているのだ。


 loop (my $i = $x; $i <= $z; $i++) { 
     say $i;
 }

Iterating over every 2nd number is also possible with the for loop of Perl 6 using the 
by adverb.

Iterating over every 2nd number も adverb を使ったPerl 6のループで書くことが
可能である。


for $x .. $y :by(2) -> $i {
	say $i;

}

Obviously you could use it to jump any, even negative numbers.


Unfortunatelly as I am writing this, the above code using the by adverb does not yet 
work in Rakudo.

すでに述べたように、この adverb を使ったコードはまだRakudo では
残念ながらまだ動作しない

帰納変数に → ってやる表記法はPHPっぽい?

■_

なぜPHPが勝ったのか | Selfkleptomaniac で触れられている Lessons Learned: Why PHP won や alan dipert - Why PHP REALLY won に噛み付いた? ものです。 you have made yourself a commodity とかこえーよー

Giles Bowkett: Why Hacker News Thinks PHP Won Something
http://gilesbowkett.blogspot.com/2009/01/why-hacker-news-thinks-php-won.html

Saturday, January 17, 2009
Why Hacker News Thinks PHP Won Something
This happened yesterday:

I found these headlines strange.

The obvious question, of course, is what PHP allegedly won. And I mean
that in both senses: what was the contest, and what was the prize?

The obvious question, of course, is what PHP allegedly won.
僕が言いたいのは、どんな競争ったのかということと、賞品 (prize) は
なんだったのかということだ。

The next question is: did PHP really win?

次なる疑問はこれだ: 本当にPHPは勝利したんだろうか?

The third question could be: why did PHP win? It could also be: why does
Hacker News think it won?

三番目の疑問はこんな感じだろう: なぜPHPは勝利を収めたのか?
あるいはこう表現しても良い: なぜHacker News はPHPが勝ったと判断したのだろうか?

Both blog posts say PHP won by becoming the dominant programming language on the Web.
This means that the contest was to see which language would obtain the most users, and
the prize was having more users than anybody else. Whether this means they really won
or not depends on whether or not this idea has any validity.

どちらのblogも、Web上で支配的なプログラミング言語になったからPHPが勝利したんだと
post している。これは contest がどちらの言語が 多くのユーザーを獲得するかということであり、
prize が 他の何よりも多くのユーザーを有することだったということだ。
Whether this means they really won or not depends on whether or not this idea has any validity.

Of course, the answer's no. If you program in the most popular programming language,
your skill in that particular language is a commodity. If you program only in the most
popular programming language, you have made yourself a commodity. A commodity can only
compete on location and price, and location doesn't really get you much on the
Internet. This means that only people with a poor understanding of economics program
in PHP.

もちろんその答えはノーだ。もしあなたがもっともポピュラーなプログラミング言語で
プログラムしたらあなたのその言語に関するスキルは commodity なものだ。
仮にあなたがたった一つの、最もポピュラーな言語でしかプログラムしないのなら
あなたは自分で自分を commodity にしてしまっている。
commodity であるということは場所と価格でしか競争できないということであり、
場所というのはインターネット上では事実上意味がなくなっているものである。
つまり、経済をロクに理解していない連中だけがPHPでプログラムをするということだ。

For years I hid the PHP experience on my resume and even lied in job interviews,
saying I didn't know the language. In reality, I've used every version. I remember it
well. Back then we all used Perl. I was writing CGI scripts in Perl before there were
HTTP libraries. Back then we hand-coded our headers, and we liked it. We walked twelve
miles uphill through the snow both ways, and we opened database connections with
backticks, and we liked it. Why? Because we were primitives and we didn't know any
better, that's why.

僕はこの数年というもの自分のresume からPHPの経験を消してしまっていて、
job interviews にあってさえPHPなんて言語は知りませんとうその発言をしてきた。
本当は、すべてのバージョンを使ってきたのだけどね。
I remember it well. Back then we all used Perl.
HTTPライブラリができる前から僕はCGIスクリプトをPerlを使って書いていた。
Back then we hand-coded our headers, and we liked it.
We walked twelve miles uphill through the snow both ways,
データベースへの接続を backticks を使って開いていた
そして僕らはそれが好きだった。
なぜかって?
それは僕らが primitives (素朴)でそれよりも良いもの知らなかったから。それが理由だよ。

I'd like to call this a Hacker News smackdown, but it isn't. First, top of the list of
links for one day is just a blip on the radar. Second, if I really couldn't stand
Hacker News, I wouldn't read it. Third, it's not a smackdown because it's not a
decisive defeat. It's a tie. PHP didn't win, because what it was (allegedly) aiming
for was something bad to have. But PHP also did win, because it got what it was
(allegedly) aiming for.

僕はこれを Hacker News smackdown と呼びたいのだけどそうではない。
第一に
top of the list of links for one day is just a blip on the radar.
リンクのリストのトップは
Second, if I really couldn't stand Hacker News, I wouldn't read it.
第二に
Third, it's not a smackdown because it's not a decisive defeat.
第三にそれは decisive defeat ではないので smackdown ではない。

The blog posts Hacker News links to - which, honestly, would be unusually moronic even
if this was not Hacker News but Reddit or Digg -ascribe PHP's "success" to either its
community or its features. In fact, PHP's "success" came from a combination of lucky
timing, and two design decsions: embedding code in a web page, and imitating Perl.

Hacker News links に post された blog ってのは正直なところ、
たとえそれが Hacker News じゃなくて Reddit や Digg -ascribe PHP's "success"
to either its community or its features
だったとしても unusually moronic なものだろう。
#moron → ばか、まぬけ
事実、PHPの“成功”は時の幸運に恵まれたということと、
webページにコード埋め込み、Perlを模倣するという二つのデザイン上の決定からきているものだ。

Compare Microsoft's market dominance in the early days of GUI desktop PCs with PHP's
dominance in the early days of Web scripting. In either case, an inferior technology
overcame a similar, superior technology, within an emerging category. When PHP emerged,
everybody was already writing CGI scripts in Perl. PHP was similar enough to Perl that
a Perl hacker could be up and running in 15 minutes, and it was easier to use, in one
simple, important way: it was embedded in the Web page. You didn't need to code up
headers; you didn't need separate files.

PCのGUIデスクトップの初期段階におけるMicrosoftの market dominance と
Web スクリプティング初期における PHPの dominance を比べてみよう。いずれのケースも、
an inferior technology overcame a similar, superior technology, within an emerging category.
PHPが広まっていったとき、誰もがすでにPerlでCGIスクリプトを書いていた。
PHPはPerlハッカーが15分もあればセットアップして実行できるようなものであり
使うのが簡単なシンプルなものだった。
ここで重要なのは、PHPがWebページに埋め込まれていたということだ。
スクリプトの書き手はヘッダー部分をコーディングする必要はないし、
別のファイルに分ける必要もなかった。

This was a tiny win, but it occurred in the context of an epochal, unprecedented,
world-changing paradigm shift that created thousands of jobs and destroyed entire
industries. These extraordinary historical conditions magnified PHP's advantage. If
you could create Web scripts faster than the next company, in the period from 1994 to
1999, it meant the difference between driving a Honda and piloting a yacht.

これは小さな勝利ではあったけれども、それは
in the context of an epochal, unprecedented,
created thousands of jobs し
and destroyed entire industries をした
世界を変えるパラダイムシフトを引き起こしたのだ。
These extraordinary historical conditions magnified PHP's advantage.
もし、1994年から1999年の間で、あなたが next company よりも早く
Webスクリプトを作ることができたなら、それは
it meant the difference between driving a Honda and piloting a yacht.

People who wrote a ton of PHP in those years invested a great deal of
their time in PHP. They now have PHP skills, and they've given the world
frameworks and libraries. These silly blog posts, which everyone on
Hacker News voted up, both claim that PHP is the language most used on
the Web, and although I have no evidence confirming or refuting it, I'm
willing to believe them. But the blogs go on to say that PHP's
"advantage" comes from its language features or its community.

この数年で大量のPHPスクリプトを書いた人はその人たちの多くの時間をPHPのために使ってきた。
現時点でその人たちはPHPスキルを持っていて、
そして they've given the world frameworks and libraries.
These silly blog posts, which everyone on Hacker News voted up,
どちらもPHPはWeb上で最も使われている言語だと主張している。
けれどもこのblogでは、PHPの言語としての機能や言語に関わったコミュニティから来た
PHPの“アドバンテージ”とやらについて述べていくことにしよう。

First of all, PHP has no advantage. I once got an e-mail from a
recruiter where the recruiter had mistakenly forwarded private comments
from his boss. It said they were looking for a Perl hacker who would
work for less money because they would get to choose Perl. That's how
these people think.

まずはじめに書いておくと、PHPはアドバンテージを持ってはいない。
僕はリクルーターから、上司から彼宛の私的なコメントを
間違ってフォワードしてしまったメールを受けたことがある。
そのメールには、彼らは実はもっと安い金で働いてくれるPerl Hackerを
探しているのだということが書いてあった。
彼らがそうしていたのは彼らがPerlを選んでいたからだ。
That's how these people think.

Market forces are not about Care Bears and hugs. If you clone aprogrammer,
two programmers with the same brain, and you send one out to hack PHP, and
you have the other one use a language where you can charge a reasonable amount
of money, the PHP programmer will make less money with the exact same brain.
If you love PHP, for some insane reason, you're making less money than you could make,
because of your poor taste in languages and your naive assumptions about market forces.
This is not an advantage. PHP could not have lost harder.

市場圧力は熊の面倒を見たり熊を抱きしめたり(Care Bears and hugs.)することではない。
もしあなたがプログラマーのクローンをつくって、同じ頭脳を持った二人のプログラマーの
うちのひとりをPHPをハックする道に送り、さらにもうひとりはあなたが reasonable amount
なお金を稼げる言語を使うようにしてみたとしたら、
同じ頭脳を持っているのにも関わらずPHPプログラマーの方はもう一方と比べて
小額の金しか稼げないだろう。
あなたがなにか馬鹿げた理由(for some insane reason)でPHPを愛しているのなら、
あなたは本来あなたが稼げたであろう額よりも小額のお金しか稼ぐことができない。
because of your poor taste in languages and your naive assumptions about market forces.
こんなことはアドバンテージではない。
PHP could not have lost harder.

Second, PHP's advantage came from a tiny ease-of-use boost, in an era where A) Web
programmers did everything by hand, and B) the world changed overnight. There are no
lessons for language designers here. You might as well be reading tea leaves.
World-changing paradigm shifts by definition do not occur in the same category twice.
Before PHP vs. Perl, it was Microsoft vs. Apple. A hundred years ago it was Railroad A
vs. Railroad B. It's not going to be languages twice, for the same reason it's never
going to be railroads again. There's no point making any language-design decisions
based on PHP's success story. The gains PHP got from these design decisions do not
correlate to the wisdom of the decisions but to the epochal circumstances of the
moment when the decisions happened.

第二に、tiny ease-of-use が加速した PHPのアドバンテージは
A) Webプログラマーがすべてを手書きしていて かつ
B) the world changed overnight. という era な領域でのことだ。
そこには lessons for language designers なんてものは存在していない。
You might as well be reading tea leaves.
世界を変えるパラダイムシフト(World-changing paradigm shifts)
が同じカテゴリで二回起きることは決してない。
PHP 対 Perl 以前にはMicrosoft 対 Apple があった。
百年前には路線A 対 路線B というものだった。
It's not going to be languages twice, for the same reason it's never going to be railroads again.
鉄道の世界で二度パラダイムシフトがなかったのと同じ理由で、
プログラミング言語の二度目のパラダイムシフトも起こりはしない。
PHPのサクセスストーリーに基づいた language-design decisions を行う機会もない。
The gains PHP got from these design decisions do not correlate to the wisdom of the decisions
but to the epochal circumstances of the moment when the decisions happened.

The secret strategy behind PHP's "success" is to already be standing in
the right place when the big ball of money falls out of the sky. That
strategy works, but it's not scaleable.

PHPの“成功”の裏に隠されている戦略というのは、空からお金の塊が降ってきたときに
はおいしい位置で待ち構えていろってことだ。
#チョー訳全開
そしてその戦略はうまくいった。
でもそれは scalabeじゃあない。

So you have two blog posts, at number 1 and number 2, debating which
irrelevant cargo-cult strategy will net you a historic, unrepeatable
"advantage" and enable you to "achieve" a "goal" which would decrease
your earnings and have you writing painful, ugly code.

Hacker News used to be too good for this kind of thing. So the question
here is: what on earth is wrong with Hacker News? Why is its quality
declining? Is the decline inevitable?

But I've already answered that.

Posted by Giles Bowkett at 5:36 PM

■_

ドライブ名について＼(◎o◎)／！ -OKWave
Karetta|VC2008はC99に対応していない

Jim McBeath: You Should Learn Scala
http://jim-mcbeath.blogspot.com/2009/01/you-should-learn-scala.html

Zach's Journal - Buy your very own Symbolics Lisp Machine
http://xach.livejournal.com/209801.html

So I want to learn LISP, where to start? : lisp
http://www.reddit.com/r/lisp/comments/7qo1s/so_i_want_to_learn_lisp_where_to_start/

briancarper.net » Blog Archive » Clojure: 1, Common Lisp: 0
http://briancarper.net/2009/01/19/clojure-1-common-lisp-0/

What are the differences between LLVM and java? - Stack Overflow
http://stackoverflow.com/questions/454720/what-are-the-differences-between-llvm-and-java

伊藤悠総合2 【シュトヘル】 

397 名無しんぼ＠お腹いっぱい [sage] Date:2009/01/12(月) 06:24:53 ID:oWlwc/AlO Be:
    モンゴルの最大版図は1241年のワールシュタットの戦い。漫画は1209年だからユルール40歳くらいの時か。

    わずか30年でユーラシアの東からウィーン近郊まで進撃したモンゴル軍の軌跡を全部書ききるんですね！
    期待してます。 

398 名無しんぼ＠お腹いっぱい [sage] Date:2009/01/12(月) 07:47:12 ID:J1XNF1OY0 Be:
    ワールシュタットの戦いって本当にあったの？

424 名無しんぼ＠お腹いっぱい [sage] Date:2009/01/13(火) 10:10:08 ID:SNv96mgc0 Be:
    >>398
    モンゴル軍はさらに西へ進み、「レグニツァの戦い」もしくは「ワールシュタットの戦い」が起きる。
    だが、世界史上有名なこの会戦も、本当にあったのか定かでない。
    同時代の文献には全く見えず、十五世紀の文献で突然大きく語られるからである。
    だから、あったとしても、ささやかなものであった可能性が高い。

    バトゥのもとにオゴデイ崩御の知らせが届き、モンゴル諸王家の部隊は東方へ引き上げてゆく。
    だが、バトゥのジョチ家はヴォルガ下流の草原に腰を据え動かなくなった。
    「ジョチ・ウルス」はトルコ系のキプチャク族が大半を占める独特の構成となり、
    そのため俗称としてのキプチャク・カン国という風にいわれる。
    西北ユーラシアに巨大な世界が誕生し、ゆるみ、崩れ、変形しながらも三百年続き、
    ロシア帝国もこの中から誕生した。

    「モンゴル帝国の興亡（上）」杉山正明　講談社現代新書より


    本当になかった、というわけではないかも知れんが、そんなに重要ではないということかな？
    ハンガリー＆ポロヴェーツがモンゴルに蹴散らされたモヒの戦いの方が重要かも知れない。

へー＞ワールシュタットの戦い

2009年01月18日

■_

・図書館
家の近くにある図書館に行ってきました(歩いて数分のところに公立の図書館があるというのはとてもありがたい)。規模としてはそれほど大きくはないのですが、同じ区の図書館同士で蔵書情報を共有していて、その図書館になくてもあるところから転送?してくれたりもします。いつ頃から稼動しているかは知らない(ここ十年以上いってなかった)のですがIT化(笑)されてその蔵書情報も区内の図書館まとめてで検索可能なシステムもあります。で、ちょっと検索してみると、わたしが出向いたその図書館の書架にはないけれどもほかの図書館や保存庫(中央図書館にあるらしい)にあるもので、 The Art of Computer Prorgamming (ASCII版。残念なことに3巻までで分冊のはない模様)だとか、岩波書店の情報処理シリーズ(情報科学シリーズだったかな?)とかがあることが判明。そうそう、アスキーの256倍シリーズのひとつ、「Cを256倍～」を蔵書に持っているところがあるのがわかりまして、早速予約しました(笑) ずいぶん昔に処分しちゃったんだよなあ。Cを256倍。 awkを256倍はまだ書店で見かけるのに、Cとかsed(はなにか別のに収録されてたんだっけ?)が絶版状態なのはとても残念。

■_ r

syntax.ml, unify.ml, solve.ml, lexer.mll, parser.mly, message.ml, miniprolog.ml
http://andrej.com/plzoo/html/miniprolog.html

Lessons Learned: Why PHP won
http://startuplessonslearned.blogspot.com/2009/01/why-php-won.html

Why PHP won : programming
http://www.reddit.com/r/programming/comments/7q94r/why_php_won/

IBM patents trim() : programming
http://www.reddit.com/r/programming/comments/7q9uo/ibm_patents_trim/

Dan Weinreb’s blog ≫ Blog Archive ≫ What Conditions (Exceptions) are Really About
http://danweinreb.org/blog/what-conditions-exceptions-are-really-about

SD Times Blog | Integration Watch: The end for Perl? - SD Times On The Web
http://www.sdtimes.com/link/33186

Nathan Sanders : Journal - Avoid Casual Parsing
http://sandersn.com/blog/index.php?title=avoid_casual_parsing&more=1&c=1&tb=1&pb=1

Java's new math, Part 2: Floating-point numbers
http://www.ibm.com/developerworks/java/library/j-math2.html?ca=dgr-btw03JavaMath2&S_TACT=105AGX59&S_CMP=grsitebtw03

Dan Weinreb’s blog » Blog Archive » What Conditions (Exceptions) are Really About
http://danweinreb.org/blog/what-conditions-exceptions-are-really-about

SD Times Blog | Integration Watch: The end for Perl? - SD Times On The Web
http://www.sdtimes.com/link/33186

Nathan Sanders : Journal - Avoid Casual Parsing
http://sandersn.com/blog/index.php?title=avoid_casual_parsing&more=1&c=1&tb=1&pb=1

Java's new math, Part 2: Floating-point numbers
http://www.ibm.com/developerworks/java/library/j-math2.html?ca=dgr-btw03JavaMath2&S_TACT=105AGX59&S_CMP=grsitebtw03

http://dablog.rubypal.com/2009/1/16/son-of-10-things-to-be-aware-of-in-ruby-1-9


Rationale behind unwind-protect and double errors - comp.lang.lisp | Google グループ
How To Criticizing Computer Scientists
jQuery is a Monad « Important Shock

PEP 3142 -- Add a "while" clause to generator expressions
英語圏の人はこういう構文でも違和感ないの?

Notes on the LHC: Why LLVM probably won't replace C--.
InfoQ: Ruby 1.9.1 Is Close - Time To Switch From 1.8.x?
GPLについて教えてください。 - Yahoo!知恵袋

d.y.d. 論文ファイブ
実は５個思いつかなかったので論文じゃなくて本でお茶を濁します。タイトルの通りひたすら構文解析の技法を解説しまくってくれる本です。
を見て、D. Grune and C. Jacobs "Parsing Techniques - Second Edition" に興味を引かれたのですが
Amazonさんにお伺いしてみると2008年4月に買っていたでござる。の巻。
おかしいな。本棚に見当たらないぞw

【コラム】ダイナミックObjective-C (121) デザインパターンをObjective-Cで - Visitor (2) | エンタープライズ | マイコミジャーナル
このような訳で、Objective-Cに関する連載は終了という決断にいたった。読者の方々の、長年のご愛顧に感謝したい。次の機会にお会い出来る事を楽しみにしている。

Object-Oriented Considered Harmful
http://www.iwriteiam.nl/AoP_OOCH.html

Rees Re: OO
http://www.paulgraham.com/reesoo.html

Why OO Sucks
http://www.sics.se/~joe/bluetail/vol1/v1_oo.html

この三つ後でチェック。

■_ ruby 1.9にむけて

続編。



DABlog Son of 10 things to be aware of in Ruby 1.9!
David A. Black's weblog
Son of 10 things to be aware of in Ruby 1.9!
January 16th, 2009

I'm happy to see that my recent 10 things to be aware of in moving to Ruby 19 article 
has proven helpful to lots of people. This article is a follow-up.

The goal of the article was to point out 1.9 features and changes that might cause 
your existing code not to run correctly, or not to run at all. I went a bit soft, 
though: two of the original ten (hashes being ordered and the changes in 
method-argument syntax) weren't really things that might break your 1.8 code.

So I feel I owe the world two more code-breaking 1.9 features! And they're here, 
along with a bonus one.

But first, some links

The denizens of ruby-talk have provided lots of helpful ideas and feedback. James 
Edward Gray II and others mentioned M17N, a topic on which I defer to the more expert 
among us, especially James who has written a multi-part M17N guide. He's going to be 
expanding it to include 1.9 encoding, so keep an eye on it.

Brian Candler suggested that people might be interested in the presentation by me and 
Dave Thomas at RubyConf 2008 on Ruby 1.9: What to Expect. We cover some pitfalls but 
also some new, non-pitfall features you might want to know about.

If you're interested in Ruby 1.9 generally, you might be interested in my forthcoming 
book The Well-Grounded Rubyist, which is a fully revised, revamped, “Ruby only” 
second incarnation of my 2006 book Ruby for Rails.

Apologies to anyone I've failed to credit, and thanks to all for the feedback.

And with that, here are the pitfalls! (Speaking of pitfalls, I think I've remembered 
all the <pre> tags this time….)

String indexing behavior has changed
文字列に対するインデクシングの挙動が変更されました

(Thanks to Michael Fellinger and Robert Dober)

In Ruby 1.8, indexing strings with [], as in "string"[3], gives you an ASCII code:

1.8では、文字列に対して[] を使って "string"[3]のようにインデクシングした
場合、その結果はASCIIコードとなっていました。

  >> "string"[3]
  => 105

In order to get a one-character-long substring, you have to provide a length:
長さが1の部分文字列を得るには、その部分文字列の長さを指定しなければなりませんでした:

  >> "string"[3,1]
  => "i" 

In Ruby 1.9, the indexing operation gives you a character.
Ruby 1.9では、インデクシング操作の結果はキャラクターとなりました。

  >> "string"[3]
  => "i" 

Also, kind of along the same lines, the ?-notation now gives a character rather than a 
code. In 1.8:
同様に、?表記による結果も1.8におけるコードからキャラクターになりました。

  >> ?a
  => 97

and in 1.9:

  >> ?a
  => "a" 

if-conditions can no longer end with a colon
ifの条件をコロンで終端することはできなくなりました


In 1.8 you can do this:

  if x:
    puts "Yes!" 
  end

In 1.9, you can't use that colon any more. The same is true of when clauses in case 
statements. This will not parse in 1.9:

1.9では上記のようなコロンを使った記述は許されません。
これはcase文の clause についても同様です。

  case x
  when 1: "yes!" 
  end

Bonus thing! No more default to_a
デフォルトの to_a はもうたくさんだ

In 1.9 you cannot assume that every object has a to_a method. You've probably seen 
warnings about this in 1.8, and the day of reckoning has now arrived.

1.9ではすべてのオブジェクトが to_a メソッドを持っているという仮定はできなくなりました。
1.8でもおそらく警告を目にしていたことでしょうが、day of reckoning has now arrived.

  >> "abc".to_a
  NoMethodError: undefined method `to_a' for "abc":String

You can use the Array method to turn anything into an array. If it's an array already, 
it returns the object itself (not a copy). If it's anything else, it tries to run 
to_ary and to_a on it (in that order), and if those aren't available, it just wraps it 
in an array.

Array のメソッドをなにかを配列へと変換するために使うことができます。
もし対象がすでにArrayであるのなら、その結果としてそのオブジェクトそのものが
返ってきます(コピーではありません)。もしArray以外の何かであったなら
to_ary と to_a をこの順序でそのオブジェクトに対して実行することを試みます。
それによってもまだArrayを得られなければ、そのオブジェクトをひとつのArrayの中に
取り込みます。

Array isn't new, but we're likely to be using it a lot more now that there's no 
default to_a operation.

Arrayは新しいものではありませんが、わたしたちはそれもデフォルトの to_a 操作
ができないものとして扱うようにしています。

Have fun!
Posted by dblack Filed in Computers, Ruby

■_ 本日の[マム]板から

計算アルゴリズム【Ⅱ】
910 デフォルトの名無しさん [sage] Date:2009/01/18(日) 02:25:35  ID: Be:
    strstrの実装で、BM法も結構複雑なんですけど、
    文字列検索はアルゴはあまり存在しないんですか？
    ソートは結構な種類がありますが、文字列の方の比較的簡単なアルゴ
    はあとはハッシュ法ぐらいしか思い浮かびません。
    一応正規表現を自作してるのでstrstr（とmemchr）は切っても切り離せないんですけど、
    何か助けとなるような助言はありませんか？ 

912 デフォルトの名無しさん [sage] Date:2009/01/18(日) 02:31:36  ID: Be:
    >>910
    助言もなにも、何がしたいのかが分からんよ。

    文字列検索なんて、それだけで一冊本が書けるほど大量にある。
    簡単なものでも http://www-igm.univ-mlv.fr/~lecroq/string/index.html くらい。 

913 デフォルトの名無しさん [sage] Date:2009/01/18(日) 02:31:48  ID: Be:
    アルゴって何だろう？ 

914 デフォルトの名無しさん [sage] Date:2009/01/18(日) 02:31:54  ID: Be:
    >>910
    有名なのには他にKMP法ってのもあるよ。
    Wikipedia を見ると他にもあるようだよ。
    ttp://ja.wikipedia.org/wiki/%E6%96%87%E5%AD%97%E5%88%97%E6%A4%9C%E7%B4%A2%E3%82%A2%E3%83%AB%E3%82%B4%E3%83%AA%E3%82%BA%E3%83%A0 

916 デフォルトの名無しさん [sage] Date:2009/01/18(日) 03:10:01  ID: Be:
    結構あるんですね。助言ありがとうございます。
    奥村先生の本でやってるんですけど文字列検索はあまり載ってなかったんで、
    検索アルゴはあまりないのかなって。
    ただ、正規表現自体が文字列検索そのものなので、BM法みたく表作ろうかどうしようかなって・・・
    ソートしたり、表作ったりするよりも、結局一番単純なmemchrがいいのかなってのが感想です。

    多少遅いかも知れませんが、今のハードの資源を考えると、
    BM法も単純なリニア検索もたぶん10ミリ秒以内の差しかないんでしょうけど。
    検索アルゴ自体よりも、newしたりメモリにアクセスする方が時間かかるんじゃないかなとか・・・

917 デフォルトの名無しさん [sage] Date:2009/01/18(日) 03:17:22  ID: Be:
    実測してから考えたら 

918 デフォルトの名無しさん [sage] Date:2009/01/18(日) 03:43:17  ID: Be:
    >>913
    Javaスレにいたアルゴ厨です。 

919 デフォルトの名無しさん [sage] Date:2009/01/18(日) 03:44:15  ID: Be:
    >>916
    やっぱり何がやりたいか分からんよ．正規表現をどうしたいんだ．

    あと線型探索は実装にもよるけど普通は O(n^2) でしょ．
    aaaa....a から aaa...b を探すことを考えたら時間が大差なのは明らかだと思うけど． 

920 デフォルトの名無しさん [sage] Date:2009/01/18(日) 03:47:34  ID: Be:
    >>913
    http://www.sansu-olympic.gr.jp/algo/　これじゃね？ 

921 デフォルトの名無しさん [sage] Date:2009/01/18(日) 03:49:40  ID: Be:
    ああ、きっとそれだな 

922 デフォルトの名無しさん [sage] Date:2009/01/18(日) 04:07:54  ID: Be:
    正規表現を自作ライブラリとして実装してるんですけど・・・・通じませんでしたか？
    アルゴは、アプリと同じくなんとなく響きがいいですよね。

    既にどういう状況でアルゴを適用するか決定してるので、>>919のようなaaaaaa...aの状況は現実的にありません。
    別に１００ミリ秒以内に結果が出ればどうでもいいかなってところです。上の１０ミリは１００ミリの間違えです。
    どうせGUIとかWEB環境で使うつもりなんで難しい実装で小手先技を披露するよりも、
    簡単な実装でかつバグがなく動く（必ず停止する）方が重要なんで・・・
    そういう実装が容易なアルゴはないかなって。 

926 デフォルトの名無しさん [sage] Date:2009/01/18(日) 04:27:55  ID: Be:
    >>922
    正規表現を実装したかったのか．

    正規表現なんて決まりきった実装法があるでしょ．
    決定化しなかったら数十行で書ける．
    memchr やら何やらを持ち出す理由が分からん． 

928 デフォルトの名無しさん [sage] Date:2009/01/18(日) 04:44:54  ID: Be:
    >>926
    いや、だから正規表現自体が、（検索キー・パタンが固定ではない）文字列探索なんですけど。おｋ？ 

934 デフォルトの名無しさん [sage] Date:2009/01/18(日) 05:28:18  ID: Be:
    実装が難しいのは、いくら高速でもあまり評価されませんけどね。
    あまりに複雑な仕様のコンパイラなどは誰だって実装したくはありませんよね。
    実際ハードの方が技術革新していった高速化していけば、線型探索でも十分に実用なんでしょうけど。
    その発明＆研究した複雑怪奇なアルゴリズムはいつ寿命が尽きるんでしょうか？ 

935 デフォルトの名無しさん [sage] Date:2009/01/18(日) 05:51:59  ID: Be:
    >>934
    > 実際ハードの方が技術革新していった高速化していけば、線型探索でも十分に実用なんでしょうけど。
    そんなことはないよ。
    ハードウェアが高性能化すればするほど扱えるデータが増えるから、
    効率の良いアルゴリズムが必要になる。
    アルゴリズムが使われなくなるのは、より良いものが出たときだけ。

    つーかそもそもの話題だった正規表現の標準的なアルゴリズムは
    非常に簡単で、しかも高速なんだけど？ 

936 デフォルトの名無しさん [sage] Date:2009/01/18(日) 06:05:06  ID: Be:
    >>935
    ネタ投入するといきなり活性化するスレですね。

    あなたの論調では、扱えるデータ量が増えたら、それを扱う使う人も当然データ量を増やしていくって前提がありますね？
    普通の人間なら、新しい機械が導入されたとしても従来からやってる仕事（例えばお役所仕事・事務処理とか）が速く終わるってことだけであって、
    だからといって従来の仕事量以上の仕事を抱え込んだりはしませんよ。どうせ給料も同じなんでしょうし。
    そういう辺りをちゃんと考慮しているかどうかってのが現実的な実用的なアルゴかどうかってことです。
    正規表現は、文字クラス[ab]をどうしようかなってところですけど。 

938 デフォルトの名無しさん [sage] Date:2009/01/18(日) 09:19:24  ID: Be:
    アルゴ君と遊ぶスレかここは 

940 デフォルトの名無しさん [sage] Date:2009/01/18(日) 11:18:47  ID: Be:
    >>936
    > 正規表現は、文字クラス[ab]をどうしようかなってところですけど。

    お前には無理。

すげーw



【逆立ちしても】使えない新人 0x18
594 仕様書無しさん [sage] Date:2009/01/17(土) 13:10:37  ID: Be:
    ポインタわからないでもやっていけるもんなの？
    俺Cは独学でWinAPI使ってちょっとしたツールを
    作れる程度なんだけどCのプログラムってポインタだらけだよね？
    WinAPIとか関数ポインタとか普通に使われているのに
    ポインタ理解しないでもプログラマになれるなら
    俺もプログラマになってもいい？ 

595 仕様書無しさん [sage] Date:2009/01/17(土) 13:13:46  ID: Be:
    プログラマなりたいと思った時点でプログラマなのですよ 

596 仕様書無しさん [sage] Date:2009/01/17(土) 13:14:17  ID: Be:
    に　が抜けたｗ 

597 仕様書無しさん [] Date:2009/01/17(土) 13:14:52  ID: Be:
    マ抜け 

600 仕様書無しさん [sage] Date:2009/01/17(土) 13:39:14  ID: Be:
    >>594
    JavaもC#も「おまいらポインタなんて難しい概念はどうせ理解できんのだろ？
    だから無くしてやったぜ。感謝しろよ」っていう言語。 

602 仕様書無しさん [sage] Date:2009/01/17(土) 13:59:28  ID: Be:
    でもポインタを理解してないと使いこなせないわな。ポインタじゃなくてリファレンスなだけだから。 

603 仕様書無しさん [sage] Date:2009/01/17(土) 13:59:36  ID: Be:
    でもJavaもC#もポインタがわからないヤツには
    参照も使いこなせないワナ

604 仕様書無しさん [sage] Date:2009/01/17(土) 14:37:35  ID: Be:
    >>594
    ポインタわからないヤツのレベルに合わせられないとやっていけないということもある 

605 仕様書無しさん [sage] Date:2009/01/17(土) 15:11:48  ID: Be:
    >>603
    それは極論。

606 仕様書無しさん [sage] Date:2009/01/17(土) 15:36:39  ID: Be:
    >>594
    まぁそのレベルで技術者を自称している人達はいっぱい居るね
    Javaしか使えませんとか、VBしか使えませんとか

    この手の連中は、Cのソースを見せると、拒否反応を見せるのが特徴
    彼らは「ポインタが解らない」と思っているが故に、Cのソースを読むことを毛嫌いし、
    ぐぐって出てくる資料がCばかりだと、解りませんでしたとか抜かす連中ｗ 

609 仕様書無しさん [sage] Date:2009/01/17(土) 15:50:52  ID: Be:
    俺Javaしか使えないけどCは文字列の足し算が嫌過ぎ 

610 仕様書無しさん [sage] Date:2009/01/17(土) 15:57:23  ID: Be:
    文字列の足し算を頻繁に行うようなプログラムでCを使うのが間違ってる 

611 仕様書無しさん [sage] Date:2009/01/17(土) 16:00:47  ID: Be:
    文字列の足し算ならstrcat使えばいいじゃん。 

612 仕様書無しさん [sage] Date:2009/01/17(土) 16:27:52  ID: Be:
    えsprintf便利じゃん 

613 仕様書無しさん [] Date:2009/01/17(土) 17:35:25  ID: Be:
    何でもいいよｗ 

614 仕様書無しさん [sage] Date:2009/01/17(土) 17:41:02  ID: Be:
    参照私と根渡しの違いって
    メモリをのすペースを減らす以外のメリットってあるの？ 

615 仕様書無しさん [sage] Date:2009/01/17(土) 17:43:54  ID: Be:
    >>614
    日本語で帰れ 

616 仕様書無しさん [sage] Date:2009/01/17(土) 19:33:25  ID: Be:
    >>614
    スレ違い 

617 仕様書無しさん [sage] Date:2009/01/17(土) 20:16:09  ID: Be:
    矢切の私 

628 仕様書無しさん [] Date:2009/01/18(日) 11:11:01  ID: Be:
    ね・・・値渡し

Lisp Scheme Part25 
40 デフォルトの名無しさん [sage] Date:2009/01/16(金) 23:53:23  ID: Be:
    http://jibun.atmarkit.co.jp/ljibun01/rensai/genius/03/01.html
    誰も言及しないのは何故。 

41 デフォルトの名無しさん [sage] Date:2009/01/17(土) 01:26:16  ID: Be:
    既にCyanスレで見たから。 

42 デフォルトの名無しさん [sage] Date:2009/01/17(土) 01:40:01  ID: Be:
    そんなのもあるんだ 

43 デフォルトの名無しさん [sage] Date:2009/01/17(土) 01:40:49  ID: Be:
    クラスのないオブジェクト指向とかS式のないマクロとかは面白いね
    大前提をぶっ壊すところが 

44 デフォルトの名無しさん [sage] Date:2009/01/17(土) 03:00:46  ID: Be:
    >>43
    S式の無いマクロならDylanがあるし、
    プロトタイプベースのOOPならSelfとかがあるじゃん。

    むしろ、そういう引用元の概念を、あの歳できっちり理解してるのが末恐ろしいよ。 

45 デフォルトの名無しさん [sage] Date:2009/01/17(土) 04:16:34  ID: Be:
    ５つの自然言語ならよかったのになあ 

46 デフォルトの名無しさん [] Date:2009/01/17(土) 15:28:41  ID: Be:
    高速で使えるライブラリのそろったCyan実装が登場したら
    Ruby以上に世界中のハッカーにインパクトを与えそう。 

47 デフォルトの名無しさん [sage] Date:2009/01/17(土) 16:11:52  ID: Be:
    >>40
    ニュータイプって感じだね。 

48 デフォルトの名無しさん [sage] Date:2009/01/17(土) 20:20:32  ID: Be:
    私は信じんよ、ニュータイプの存在など 

49 デフォルトの名無しさん [sage] Date:2009/01/17(土) 21:30:31  ID: Be:
    既存のpythonのlibraryが使えてマクロありなら便利かもね 

50 デフォルトの名無しさん [sage] Date:2009/01/17(土) 23:55:38  ID: Be:
    現状だと荒削りだし、そりゃ言い杉なんじゃないかな。将来は楽しみだけど。
    素直に理論面とかハードウェアの知識を学んでいったら楽しみだね。
    まだだ、まだ終わらんよ！とか言わされちゃうのかなー 

51 デフォルトの名無しさん [sage] Date:2009/01/18(日) 00:14:09  ID: Be:
    本人乙ｗｗｗ 

52 デフォルトの名無しさん [sage] Date:2009/01/18(日) 01:22:19  ID: Be:
    クワトロ・バジーナ降臨ときいてすっ飛んできました。
    アクシズ落とさないでね。

■_ goto

コメントがある程度集まるような再度チェックします。

GOTO still considered harmful? - Stack Overflow
http://stackoverflow.com/questions/46586/goto-still-considered-harmful

The following statements are generalizations; while it is always possible to plead
exception, it usually (in my experience and humble opinion) isn't worth the risks.

1. Unconstrained use of memory addresses (either GOTO or raw pointers) provides too
many opportunities to make easily avoidable mistakes.

2. The more ways there are to arrive at a particular "location" in the code, the
less confidant one can be about what the state of the system is at that point. (See
below.)

3. Structured programming IMHO is less about "avoiding GOTOs" and more about making
the structure of the code match the structure of the data. For example, a repeating
data structure (e.g. array, sequential file, etc.) is naturally processed by a
repeated unit of code. Having built-in structures (e.g. while, for, until, for-each,
etc.) allows the programmer to avoid the tedium of repeating the same cliched code
patterns.

4. Even if GOTO is low-level implementation detail (not always the case!) it's
below the level that the programmer should be thinking. How many programmers balance
their personal checkbooks in raw binary? How many programmers worry about which sector
on the disk contains a particular record, instead of just providing a key to a
database engine (and how many ways could things go wrong if we really wrote all of our
programs in terms of physical disk sectors?

■_ redditに訊け!

自分は18歳です。大学にはいけませんがプログラマーになりたいと思っています。何をしたら良いでしょうか?

I am 18 years old, I want to be a programmer, and I can't go to college. What do I do? : programming
Read code, join open source projects, and watch the SICP lectures from MIT. Study them
like they're the bible. If you have some talent and you do those things, you'll be
ahead of most programmers with college educations.

Also..

Working on open source is good networking. It could lead to your first job. Stick with
small companies.. they don't care about education as much. And when you do get some
money think about going to college because it opens many doors.

UC Berkeley Webcasts too!

http://webcast.berkeley.edu/course_details_new.php?seriesid=2008-D-26263&semesterid=2008-D

I am going to try to teach myself, that's the idea. Beyond that though... that's what
I'm talking about. Also, what languages are worth the time and the effort ( I started
learning C with K&R ).

I don't want to sound uptight, but I want to learn what is really gonna pay the bills.
The more I can learn the better though.

Brief thought: you might want to consider taking the CSGRE if you have trouble
convincing employers why they should hire someone without a college degree. Being able
to say "I scored in the 80th percentile of students intending to go to grad
school" might help you.

That being said, you're going to want to learn a few different things well:

1) A scripting language. Mine is Bash. Learn to use it for everything that you would
normally type out by hand. Set up scheduled tasks to do backups and defrags. You'd be
AMAZED how useful this is and how few programmers can script effectively. Bonus:
Cygwin.

2) A dynamic language, like Python. Dynamic languages tend to be "get things
done" languages. I recommend writing a large nontrivial program (>5k lines of
code) in order to see just how easy large-scale development should be. This should set
the bar as far as programming time goes.

3) A popular language. Mine is C++. You could also pick from Java or C# (out of these
two? I prefer C#, but Java has picked up some neat features in the past few releases).
This is what will pay the bills! You will be supported by your scripting language and
grounded by your dynamic language. You don't necessarily have to master the language
itself, but you should be able to design programs for this language in your sleep. If
you're doing serious Windows programming, you'll want a language where you can write a
DLL. Also, learn the libraries associated with this language; for C++, learn Boost and
MPZ and learn about your compiler's support for OpenMP.

Best of luck!

Edit: I agree with those who commented on the difficulty of the CSGRE: I'm studying
for it myself. There's no good prep book, only practice tests. It will probably take a
few months of quality studying to get a good score, but it just might be the
difference. Also, it tests a lot of stuff that you should be aware of (algorithmic
complexity!!!!!), even if you don't memorize it.

I'd like to add to his list. Not all the theory they teach in college is useless. You
will need to know some of it at least to pass the interviews. You will need at the
bare minimum:

* Algorithms
* Data structures (basics)
* Computational complexity
* Operating systems
* Databases (basics)
* Networking (basics)
* Formal languages and automata theory
* Software Engineering

Knowing this will be required to pass the CSGRE and you should understand the
underlying fundamentals at least to pass interviews and it will help you in design.

あ、バークレイのwebcastってすっかり忘れたような。

■_ MySQLの正規表現

MySQL はヘンリー・スペンサーの正規表現の実装を使用します。これは、POSIX 1003.2. との適
合性を目指したものです。付録 E. Credits  をご覧ください。MySQL は、SQL 文での、REGEXP  
演算子とのパターン照会演算をサポートするため、拡張バージョンを使用します。Pattern 
Matching  および 項11.3.1. 「文字列比較関数」  を参照してください。

てのがあって、まあこれはいいとして


MySQL :: MySQL 5.1 リファレンスマニュアル :: 11.3.2 正規表現#

[.characters.]

括弧式 ( [ と ] で書かれたもの ) に囲まれた中で、照合要素である文字のシークエンスをマ
ッチします。characters は単一の文字、または newline のような文字の名称です。文字の名称
の完全なリストは、regexp/cname.h ファイルに含まれています。

mysql> SELECT '~' REGEXP '[[.~.]]';                     -> 1
mysql> SELECT '~' REGEXP '[[.tilde.]]';                 -> 1

[=character_class=]

括弧式 ( [ と ] で書かれたもの ) に囲まれた中で、[=character_class=] は等価クラスを表
します。これは、それ自体を含む、同じ照合値を持つすべての文字にマッチします。例えば、o 
および (+) が等価クラスのメンバーである場合は、[[=o=]] 、[[=(+)=]] 、そして [o(+)] は
すべて同義です。等価クラスを範囲の週末点として使用できない場合もあります。

この二つ、本当に実装しているんだろうか? 結構面倒なはずなんだけどなあ。

2009年01月17日

■_

・Type P 買おうかどうしようか悩んでます。

・今日はReal World Haskellを20p弱読んだ。最初の方だからまだ何とかついていける。

・すっぽすっぽ先生の新刊もちょっと読み進んだ。この本を「C++の入門書」とか企業サイトで大々的に書いた御仁は腹をき(ry

■_ gawk

cvsリポジトリから変更履歴をたどって regex関連の修正内容を確認してみた。アルゴリズムに関わるようなものでもないようだ。たとえば http://cvs.savannah.gnu.org/viewvc/gawk-stable/regcomp.c?root=gawk&r1=1.10&r2=1.11 にあるような if (mbrtowc (&wc, (const char *) buf, p - buf, → if (__mbrtowc (&wc, (const char *) buf, p - buf, てきな書き換えとか、コメントとか…でもないかかこういうのがある

           if (wc == WEOF || wc >= SBC_MAX)
             re_set_fastmap (fastmap, icase, i);

           /* See if we have to start the match at all multibyte characters,
                     re_set_fastmap (fastmap, icase, i);
              i.e. where we would not find an invalid sequence.  This only
              applies to multibyte character sets; for single byte character
              sets, the SIMPLE_BRACKET again suffices.  */
           if (dfa->mb_cur_max > 1
               && (cset->nchar_classes || cset->non_match
# ifdef _LIBC
                   || cset->nequiv_classes
# endif /* _LIBC */
                ))
             {
               unsigned char c = 0;
               do
                 {
                   mbstate_t mbs;
                   memset (&mbs, 0, sizeof (mbs));
                   if (__mbrtowc (NULL, (char *) &c, 1, &mbs) == (size_t) -2)
                     re_set_fastmap (fastmap, false, (int) c);

[gawk] View of /gawk-stable/regcomp.c
http://cvs.savannah.gnu.org/viewvc/gawk-stable/regcomp.c?revision=1.11&root=gawk&view=markup

[gawk] View of /gawk-stable/regex.c
http://cvs.savannah.gnu.org/viewvc/gawk-stable/regex.c?revision=1.4&root=gawk&view=markup

[gawk] View of /gawk-stable/regex.h
http://cvs.savannah.gnu.org/viewvc/gawk-stable/regex.h?revision=1.5&root=gawk&view=markup

[gawk] View of /gawk-stable/regex_internal.c
http://cvs.savannah.gnu.org/viewvc/gawk-stable/regex_internal.c?revision=1.3&root=gawk&view=markup

[gawk] View of /gawk-stable/regex_internal.h
http://cvs.savannah.gnu.org/viewvc/gawk-stable/regex_internal.h?revision=1.9&root=gawk&view=markup

[gawk] View of /gawk-stable/regexec.c
http://cvs.savannah.gnu.org/viewvc/gawk-stable/regexec.c?revision=1.9&root=gawk&view=markup

■_

フリーランス開発者が身につけるべき技術、米oDeskが傾向を分析
“高画質スリム一眼”を実現するマイクロフォーサーズ（1/2）－＠IT MONOist
2009/1 (b) C++ のテンプレートライブラリはこれは「プログラム」であるので、 LGPL v2.1 で配布されてる C++ ヘッダを include するとこれは「ライブラリの派生物」とみなされる、とゆうわけ。あー、ややこしい。そしte, もちろん、C++のテンプレートなぞを喜んで使っている人間に同情する気はない。つまりこの場合はアホの二乗なわけだから符号反転されて 1 に戻る。
GOTO復活という悪夢 - 酔狂人の異説
あって困った経験を持つ私などから、言わせると、「gotoで書いた方が極めて簡単に書けるコード」の利点より、「gotoで極めて簡単に書けるスパゲッティコードコード」のリスクの方がはるかに高い。
供給能力は需要を上回っていなければならない - 酔狂人の異説
MSN相談箱英語の利用規約皆さん理解した上で同意してますか？
Rationale behind unwind-protect and double errors - comp.lang.lisp | Google グループ
How To Criticizing Computer Scientists
LGPL 2.1, Qt 4.5 and C++ templates | obsethryl's lab
１バイトはなぜ８ビットなのですか？１０ビットのほうが感覚的にわかりやすい気が... - Yahoo!知恵袋
プログラミング言語で初めに学のはC言語が一般的ですか？色々調べましたが、Pyt... - Yahoo!知恵袋
Wataru's memo(2009-01-16) 専門書に落第させられる読者
PHP プログラミングのための 5 つの良い習慣を身につける
めもがき:2009年1月17日分 ○[NetBSD] PR/40411
やっぱり必ずstrndup(3)使おうぜってことですな(当時まだlibcに無かった)。 "
おっとそんなものがっ。ってなかったのが不思議なのか。

■_ 本物?

SD Times Blog | Integration Watch: The end for Perl? - SD Times On The Web まあいろいろつっこみやら入ってますがそれはおいといて。


  Integration Watch: The end for Perl?
  
January 15, 2009 —   In 1996, I hired a writer/programmer named Randal Schwartz to 
write a column on Perl for Unix Review, the magazine I headed up at the time. I 
believe I was one of the first, if not the first, editor of a broad-circulation tech 
publication to feature regular coverage of Perl. The rationale was that I could see 
the rapid adoption of Perl in the Unix community—combined with the difficulty new 
users had in coming up to speed on the language.

Schwartz was probably the biggest name in Perl at the time (his book was the 
equivalent of K&R to C or the Pickaxe book to Ruby) after Larry Wall, the language's 
inventor. The column, Perl Advisor, was very popular during and after my tenure Unix 
Review, and it lasted until the magazine folded several years later.

(略)
  
By contrast, Perl has been in a massive funk when it comes to updates. The 
now-infamous Perl 6 release is still a long way off—as it has been since its 
announcement in 2000. In September  2003(!), I wrote an installment of this column 
discussing the features of the soon-to-beta Perl 6. I referred to O'Reilly's Perl 6 
book, which had just appeared in its second edition. And still five years later, we'
re years away. Languages that do not advance become stale, especially in the light of 
the numerous advances in competing languages. For example, since Perl 6 was announced, 
Java has enjoyed three major releases.

A second aspect of Python's rise and Perl's fall is that Python has become the 
language of choice for several key technology companies that are trendsetters: Google 
(in particular), BitTorrent, Yahoo and others. In addition, the community has created 
multiple versions of Python: IronPython (for .NET), Jython (for the JVM), and various 
versions for handheld devices and smartphones. Perl has only the original Perl 
implementation plus an experimental version in Haskell under development. Not quite 
the same.

The pain point in this is that Perl needs an update more than Java or Python ever did. 
Its arcane syntax might have been fine when competing with CGI, but when users have 
alternatives such as Python and Ruby, difficult syntax is just a chore. To this end, 
you'll note the upcoming revisions to Ruby eliminate precisely those Perl-like 
syntactical elements.

Despite its syntax and slow release cycle, Perl won't die, of course. But it seems 
likely that greenfield Perl projects will dwindle and Perl will be consigned to 
maintenance of legacy codebases and the writing of quick-and-dirty admin scripts. That'
s not a bad fate (Smalltalk would be happy with that much industry relevance), but it'
s not growth.

Andrew Binstock is the principal analyst at Pacific Data Works. Read his blog at 
binstock.blogspot.com.


SD Times Blog | Integration Watch: The end for Perl? - SD Times On The Web
01/15/2009 12:56:58 PM EST

Since you referenced me in your article, allow me to say that the Perl 6 development 
process is alive and well, and gaining incredible speed. Rakudo (Perl 6 on Parrot) is 
rapidly approaching beta status, with more useful functionality being generated every 
day. A usable public beta release should appear at OSCON this summer, with an 
early-adoptor production-ready release available by year's end. Sure, it's a long time 
since Perl6 was first announced, and a few false starts to test implementation ideas 
have come and gone, but with each round, more was learned about how to tame this beast. 
A language that has all the things we've come to appreciate in classic Perl, as well 
as all the things people expect from a modern language, is not an easy task. The work 
to create a solid VM base that will allow language interoperability (20+ languages 
have proof-of-concept implementations) that would also support Perl's unusual demands 
was a bit more difficult than had been initially imagined, and that led to some delay 
as well. We've also had to deal with illnesses and distractions of some of the key 
members. I'm still fully committed to updating our seminal 
Learning/Intermediate/Mastering Perl series for Perl 6 as soon as we get closer to a 
good beta release, and continuing to have Stonehenge be the leading boutique training 
and consulting company for both Perl 5 *and* Perl 6.

United States
Randal L. Schwartz

本人?

■_ 道具は選んでつかおう

まあ何でもかんでも正規表現でやるなというお話。

Nathan Sanders : Journal - Avoid Casual Parsing
Here's a quote from Real World Haskell, chapter 16:

    In many popular languages, people tned to put regular expressions to work for “
    casual” parsing. They're notoriously tricky for this purpose: hard to write, 
    difficult to debug, nearly incomprehensible after a few months of neglect, and they 
    provide no error messages on failure.

    If we can write compact Parsec parsers, we'll gain in readability, expressiveness, 
    and error reporting. Our parsers won't be as short as regular expressions, but
    they'll be close enough to negate much of the temptation of regexps.

I can't agree more. Regular expressions have two problems. The first is obvious: they 
look like line noise. Of course, you can argue that a compact representation is a boon 
if you are careful with your formatting. And you can use tricks like those I talked 
about in Make Regular Expressions Suck Less to make things more readable.

(略)

To conclude, I wanted to put a rip-roaring recommendation of Parsec or at least some 
parsing package in here (every language has one). Unfortunately, I'm just learning 
Parsec myself, and having a bit of trouble. Parsing is just hard. No two ways around 
it. But the safest way is to do something well or not at all. I usually take the 
second route but I need to know how to take the first when it's really necessary**.

Note: Real World Haskell uses the phrase “in many popular languages” all over the 
book when they want to refer to some language with a bad cultural habit without naming 
names. The language they're talking about here is Perl. Perl 6 (may it soon be 
released) notably fixes the regex problem by introducing grammars consisting of rules.

まあメールアドレスのチェックを～というのはOKWaveあたりでも定期的に見かけますね。

■_ reddit からネタひろい

その1。勝者は誰か? Why PHP won : programming (ネタ元の記事はこちら→ Lessons Learned: Why PHP won)

PHP didn't win, we all lost.

PHP is like the VB6 for the web. VB6 was horrible but popular. But not all popular 
things are good.

PHP is the new VB, Java is the new COBOL.

A good programmer using PHP 5 can be very productive, and write clean, maintainable 
code.

PHP has got it's bad rap from the thousands of newbie users it's attracted and 
painfully bad previous versions.

その2。以前にも同じようなものがありましたが。 Ask Proggit: What is the most intrusive wart on your favourite programming language? : programming あなたの好きな言語の珠に瑕なのもの

I use Mathematica, so cost.

うはははは。あの値段じゃあちょっと買って試してみよういう気にもなれないw

■_ ピンチはチャンス

書店員の情報交換スレ39 

22 マロン名無しさん [sage] Date:2009/01/16(金) 12:55:05 ID:??? Be:
    ヘタリアアニメ中止ktkr
    もう発注かけちまったよ……orz 

23 マロン名無しさん [sage] Date:2009/01/16(金) 12:59:33 ID:??? Be:
    ttp://www.kids-station.com/rni9hp00000027q9.html
    これだな 

24 マロン名無しさん [sage] Date:2009/01/16(金) 13:01:44 ID:??? Be:
    ﾌﾞﾌｰｰｰ
    諸事情って何だ！ 

30 マロン名無しさん [sage] Date:2009/01/16(金) 14:30:01 ID:??? Be:
    >>22
    逆に話題性うｐと考えるんだ 

32 マロン名無しさん [sage] Date:2009/01/16(金) 16:14:24 ID:??? Be:
    騒動になったおかげでちょっと動きがよくなった 

36 マロン名無しさん [sage] Date:2009/01/16(金) 19:11:11 ID:??? Be:
    これでヘタリア知らない人にも知れ渡る可能性があるので
    正直こっちとしてはおｋ 

41 マロン名無しさん [sage] Date:2009/01/17(土) 01:19:50 ID:??? Be:
    「諸般の事情により絶版にされる(かもしれない)問題作!?今の内にご購入ください！」
     とPOP立てたらまあ売れる売れる 

42 マロン名無しさん [sage] Date:2009/01/17(土) 13:17:24 ID:??? Be:
    ヘタリア全然入って来ねえ 

43 マロン名無しさん [sage] Date:2009/01/17(土) 18:50:58 ID:??? Be:
    >>41
    それまねてうちもやってみたら
    まったく売れる気配なかったのに、今日午後から急に売れ出したｗ
    マジありがとうｗｗ

■_

プログラミング質問すれ Part1 b
339 名無しさん＠お腹いっぱい。 [sage] Date:2009/01/14(水) 22:36:54  ID: Be:
    金をdoubeで扱う勘定系プロジェクトに配属になったけど
    ソッコーで抜けさせてもらったことがある
    「おかしい計算が合わない…」
    とかいうつぶやきが遠くで聞こえてるうちに逃げてきた 

340 名無しさん＠お腹いっぱい。 [sage] Date:2009/01/14(水) 22:39:50  ID: Be:
    あはははははは

これは(ry

ぐち0x1B ～最も働いている現場の人間から解雇～ 
45 仕様書無しさん [sage] Date:2009/01/16(金) 14:05:17  ID: Be:
    背後の席のお姉ちゃんがえらく体調が悪そうだ。
    朝から咳こんでるし、暖房が効いてるフロア内でコートを着込んでる。
    そっちのチームのリーダーも帰宅を勧めてるが、何故かひたすら断って仕事を続けてる。
    話を聞く分にはスケジュールに支障が出るような段階でもなさそうなのに。

    正直言って非常に迷惑だ。
    他人に感染させる前にとっとと帰ってほしいんだが、
    俺が外注という事もあってよそのチームには口出し辛い。 

46 仕様書無しさん [sage] Date:2009/01/16(金) 14:12:06  ID: Be:
    いるな、そういう奴ｗ 

47 仕様書無しさん [sage] Date:2009/01/16(金) 14:14:54  ID: Be:
    いるいるｗｗｗ

    俺は木曜日にそれをやって、同情かつ若干の「休めよもう」の空気を作って
    金曜日に休んで3連休、とかの作戦をするクチだがｗｗｗｗ 

48 仕様書無しさん [sage] Date:2009/01/16(金) 15:55:52  ID: Be:
    そしていつの間にか「辞めろよもう」の空気が 

49 仕様書無しさん [sage] Date:2009/01/16(金) 16:05:21  ID: Be:
    うちの職場かと思った

    今は落ち着いているが、さっきまで、10分近くずーーーーーーーーーーーーーーとげっほげっほげっほげっほ（ｒｙ
    気の毒に思うのと、うるさい早くｶｴﾚと思うのと半々で('A`)
    でも、課が違うので口出しもできない('A`) 

50 仕様書無しさん [sage] Date:2009/01/17(土) 14:33:37  ID: Be:
    同じ課でも口出さないほうがいいよ
    今日は仕事中止して休めという意味で
    今日はやめなさいといったら

    大事になったぞ 

51 仕様書無しさん [sage] Date:2009/01/17(土) 16:49:27  ID: Be:
    休日なのに今日も来ている咳の人('A`)
    忙しいから休めないんだな、それは解るが
    頼むからマスクしてお願い・・・・・・ 

52 仕様書無しさん [] Date:2009/01/17(土) 18:38:17  ID: Be:
    職場の上司や顧客は帰って良いと言ってくれても、
    契約上の上司や営業のプレッシャーで帰れない立場の人もいる。
    ひどい会社なんかだと、契約してる最低作業時間を割ると自腹切らせたりする。
    そうなるとコート着込んででも職場に居続けざるを得ない訳だ。 

53 仕様書無しさん [sage] Date:2009/01/17(土) 19:27:06  ID: Be:
    職場に恨みがあるとしか思えんな。
    あるんだろうけどｗ 

54 仕様書無しさん [sage] Date:2009/01/17(土) 21:42:16  ID: Be:
    >>51
    だな。休む休まないは色んな事情があるだろうが
    咳が出てるのにマスクしない奴は非常識

■_

Pythonのお勉強 Part31
206 デフォルトの名無しさん [] Date:2009/01/16(金) 22:36:49  ID: Be:
    ドラマのブラッディーマンデイで主人公がputhon多様していたみたいだが、
    彼が使っていたエディタはなにかわかるひといる？
    ttp://imagepot.net/view/123211290262.jpg 

207 デフォルトの名無しさん [sage] Date:2009/01/16(金) 22:51:13  ID: Be:
    vimじゃん 

208 デフォルトの名無しさん [sage] Date:2009/01/16(金) 23:25:13  ID: Be:
    >>207 はあ？

    わかるひといます？ 

209 デフォルトの名無しさん [sage] Date:2009/01/16(金) 23:41:10  ID: Be:
    vimだろ 

211 デフォルトの名無しさん [sage] Date:2009/01/16(金) 23:42:31  ID: Be:
    どう見ても vim だな。 

212 デフォルトの名無しさん [sage] Date:2009/01/16(金) 23:52:00  ID: Be:
    gvimだな 

220 デフォルトの名無しさん [sage] Date:2009/01/17(土) 06:27:30  ID: Be:
    >>206
    1-6行目不明
    7行目以降
    try: host,frm,to=sys.argv[1:4]
    except ValueError:
    print 'Usage: %s <host> <from> <to>' % (sys.argv[0])
    sys.exit(1)

    print 'Connecting to %:25 ...' % (host)

    sock = socket.socket()
    try: idx = host.index(':')
    except ValueError: addr = (host, 25)
    else: addr = [host[:idx], int(host[idx+1:])]
    sock.connect(addr)

    print 'Connected'

    1-6行目わかる？ 

221 デフォルトの名無しさん [sage] Date:2009/01/17(土) 06:33:51  ID: Be:
    import socket
    import sys

    あとコメントが数行入って終了じゃないか 

224 デフォルトの名無しさん [] Date:2009/01/17(土) 07:26:49  ID: Be:
    25って決め打ちなんか 

225 デフォルトの名無しさん [sage] Date:2009/01/17(土) 12:18:38  ID: Be:
    >>220
    普通にこれで使えるな 

226 デフォルトの名無しさん [sage] Date:2009/01/17(土) 13:18:20  ID: Be:
    print 25のとこおかしいね。 

227 デフォルトの名無しさん [sage] Date:2009/01/17(土) 13:19:10  ID: Be:
    これで女子高生にvim使いが増える！ 

228 デフォルトの名無しさん [sage] Date:2009/01/17(土) 14:58:57  ID: Be:
    >>226
    元の画像には%sになってたからただの写し間違いだと思うが
    host="hoge.fuga:587"
    とかだったときにやっぱり表示は変になるね 

229 デフォルトの名無しさん [sage] Date:2009/01/17(土) 15:00:35  ID: Be:
    1行目は #!/usr/bin/env python だと予想。 

230 デフォルトの名無しさん [sage] Date:2009/01/17(土) 16:10:24  ID: Be:
    1. #!/usr/bin/env python
    2. '''hogehoge
    3. fugafuga
    4. '''
    5. import socket
    6. import sys

    でFA? 

231 デフォルトの名無しさん [sage] Date:2009/01/17(土) 16:14:28  ID: Be:
    1. #!/usr/bin/env python
    2. # -*- coding: hoge -*-
    3.
    4. import socket
    5. import sys
    6. 

232 デフォルトの名無しさん [sage] Date:2009/01/17(土) 16:25:29  ID: Be:
    >>231
    それっぽいw 

233 デフォルトの名無しさん [sage] Date:2009/01/17(土) 16:58:53  ID: Be:
    PEP8守ってないから訓練されたPythonistaじゃないな 

234 デフォルトの名無しさん [sage] Date:2009/01/17(土) 18:54:52  ID: Be:
    パイソニスタじゃなくてパイソニアンがいい 

235 デフォルトの名無しさん [sage] Date:2009/01/17(土) 19:03:38  ID: Be:
    Pythonista, Pythonian, Pythonese, Pythonist, Pythoner
    どれでも好きなのを選ぶといい 

236 デフォルトの名無しさん [] Date:2009/01/17(土) 19:06:40  ID: Be:
    日本語なら「Py使い」でいいでしょ。 

237 デフォルトの名無しさん [sage] Date:2009/01/17(土) 19:15:42  ID: Be:
    お、py使い 

238 デフォルトの名無しさん [sage] Date:2009/01/17(土) 20:18:26  ID: Be:
    訓練されてないのは、盲py 

239 デフォルトの名無しさん [sage] Date:2009/01/17(土) 20:51:27  ID: Be:
    PEP8守って書き直すとどうなりますか

関数型言語Part IV 
692 デフォルトの名無しさん [] Date:2009/01/15(木) 20:38:26  ID: Be:
    Exelのマクロは関数型言語って聞いたことあるんだけどほんとですか。
    VBだと思うんですけど。 

693 デフォルトの名無しさん [] Date:2009/01/16(金) 03:07:56  ID: Be:
    本当ではないです。 

694 デフォルトの名無しさん [sage] Date:2009/01/16(金) 04:09:53  ID: Be:
    Lotus Notesは関数型です

695 デフォルトの名無しさん [] Date:2009/01/16(金) 13:39:42  ID: Be:
    関数型インフレの予感！！！！

    関数型まんじゅう
    関数型ソフトクリーム
    関数型戦隊ファンクター
    萌え関数型米

696 デフォルトの名無しさん [sage] Date:2009/01/16(金) 19:54:43  ID: Be:
    メンバー紹介
    　レッド　並　列(ならび　れつ)
    　ブルー　台　一休(だい　いっきゅう)
    　ピンク　三勝　籐花(さんしょう　とうか)
    　イエロー　Curry(カレー)
    　グリーン　今彼 九厘(こんかれ ぐりん) 

697 デフォルトの名無しさん [sage] Date:2009/01/16(金) 23:07:39  ID: Be:
    長官：　茅園　氷華（ちえん　ひょうか）
    敵：　複鎖妖（ふくさよう）

698 デフォルトの名無しさん [sage] Date:2009/01/17(土) 15:18:08  ID: Be:
    列「くらえっ！フォォォォルド、レフトォォォ！！！！」

    複鎖妖軍 スパゲティ男爵「な、何だこの技は・・ワシのオーダでは歯がたたん！！」

    藤花「末尾再帰よ」

    スパゲティ男爵「マツビ・・サイキ・・？こんな・・こんなことが・・あのお方にお伝えしなければ・・」

なんだなんだw

2009年01月16日

■_

・ハマの総長
ベイスターズの今年の新人で、その外見から「総長」という二つ名を奉られたのがいるそうだ (東スポ記事)。チームにはもう番長がいるのにねえ。とはいえ、話題性先行でも何でもいいからチャンスをつかんでくれw。

■_

[NetBSD] pkgsrc/wip/scim 他2009/1/15 09:00
Unicodeなんぞ銀の弾丸どころか悪魔そのものだろ(ぉ
2009/1 (a)
C++ を好んで使ってるプログラマーで、まともな考え方をするやつを今までに見たことがない。
CGI is Dead; mod_perlite is Alive! - O'Reilly Broadcast
Ruby: This is what I call a community — DEV_MEM.dump_to(:blog) - Multimedia systems blog
TIOBE Software: Tiobe Index
HOPL-III (2007)
HOPL-IIIって本にはなってないのでしたっけ?
Rubyにインクリメンタル演算子がない理由は？ -OKWave
パクリなフリーソフト２本 - Yet Another Diary
mEditorは外見とか何とかより、その名前が一番性質が悪いのではないかと。あと、GNUを「オープンソース」とか呼ぶとrmsにお説教されますw
BLUEPIXY日記:C99
「Ｃ９９」っていつぐらいから使って良いのか私も知りたい。
VCがサポートしたそのときから。ということは未来永劫使え(ry
やる夫で学ぶ就職氷河期:ハムスター速報　２ろぐ
tazantが道をそれた！ : OKの日記
30日でできる！OS自作入門について - Lispのひび
まあ若いんだし寄り道するのも良いだろうし、最初からゴールとか分野を決めつけないでもいいでしょ。
ヒビルテ(2009-01-15)
そこかしこでRandom thoughts on Haskell の名前を見るなあ。まだ斜め読みしかしてないのだけどね
Greenbear Diary - 「expr」は本当にexpressionなのか？ - Rubyの式と文について考える
アニメメーカー横断宣伝マンブログ：『ヘタリアＡxis Ｐowers』キッズステーション放送中止のお知らせ
Cabos(カボス)について -OKWave
Cabosは音楽などのダウンロードが出来るサイトだと聞きました。使うとそれなりに便利なものだそうで、私の友人はi-podに音楽をダウンロードしていました。
Twitter / Faith and Brave: これ誰か読んだひといる？『C++の進化』 http: ...
Amazon.co.jp： C++の進化―ユーザたちが作り上げた言語 (SOFTBANK BOOKS): Jim Waldo, 岩谷宏: 本
記憶にないなあ



Ｃ言語なら俺に聞け（入門篇） Part 42 
658 デフォルトの名無しさん [sage] Date:2009/01/15(木) 22:26:14  ID: Be:
    N88-BASICとか、非構造化言語が使われていた時代から、Cとかpascal、構造化BASICのような
    構造化言語が使われだしたときにも、非構造化言語で構造化プログラミングをするテクニック
    みたいのが雑誌に載ってたけど、プログラマの負担が大きすぎて、とてもやってられない
    ようなのばっかりだったな。
    (Vzのソースは、MASMのマクロを使って、うまく構造化していてあれは感銘をうけたけど)

VzのソースはOPTASMでないとアセンブルできないんじゃなかったっけ?

■_ Ruby 1.9へ移行するにあたって注意しておくべき十のことがら

DABlog 10 things to be aware of in moving to Ruby 1.9
DABlog

10 things to be aware of in moving to Ruby 1.9
January 14th, 2009

I've been writing a lot about Ruby 1.9 (my book The Well-Grounded Rubyist is due out 
in a couple of months), and I thought I'd share my personal list of things you need 
to be careful of as you go from 1.8 to 1.9. This is not a list of changes; it's a 
list of changes that you really need to know about to get your 1.8 code to work in 1.9, 
things that have a relatively high likelihood of biting you if you don't know about 
them.


わたしはこれまでRuby 1.9について数多くのことを書いてきました
(my book The Well-Grounded Rubyist is due out in a couple of months)。
そこで、わたしの個人的な1.8から1.9へ移行するにあたって注意が必要であることがらの
リストを共有したいと考えたのです。これは変更点のリストではありません。
1.8用のコードを1.9で動作するようにするために本当に知っておかなければならない
変更点のリストです。
things that have a relatively high likelihood of biting you if you don't know about 
them.

Strings are no longer enumerable (文字列が enumerableでなくなった)

You can't do string.each and friends any more. This has an impact, for example, on 
the Rack interface, where there has in the past been a requirement that the third item 
in the returned array respond to each.

もはや string.each やそれに類することはできなくなりました。
これには大きな影響があります。
たとえばRack インターフェースにおいて
where there has in the past been a requirement that the third item 
in the returned array respond to each.


Block argument semantics (ブロック引数のセマンティクス)

This is a big change, and a big topic. The salient point is that when you do this:

これは大きな変更でありかつ、big topic です。
The salient point は、あなたが次のようにしたときに:

  array.each {|x| ... }

the block parameter list is handled like a method parameter list. In 1.8, blocks use 
assignment semantics, so that @ is like @x=. That's why in 1.8 you can do:

ブロックパラメーターリストがメソッドのパラメータリストの様に扱われるということです。
1.8ではブロックは代入セマンティクスを使うので @ は @x= のようなものでした。
そのため、1.8では以下のようにできたのです:


  array.each {|@x| ... }

(assign to an instance variable) or even:
(インスタンス変数に対する代入) あるいは

  array.each {|self.attr| ... }

(call the attr= method on self). You can't do those things in 1.9; the parameters are 
bound to the arguments using method-argument semantics, not assignment semantics.

(self の attr= メソッドを呼び出す)
1.9ではこのようなことはできません。
ブロックに対するパラメーターは代入のセマンティクスではなく
メソッド引数のセマンティクスを用いて束縛が行われます。

Block variables scope (ブロック変数のスコープ)

Block parameters are local to the block.
ブロックに対するパラメーターはそのブロックにローカルなものとなります。

  x = 1
  [2,3].each {|x|  }

In 1.8, x would now be 3 (outside the block). In 1.9 the two x's are not the same 
variable, so the original x is still 1.

1.8では、これを実行したあとのxは(ブロックの外側で)3になります。
1.9では二つのxは同一の変数ではないのでブロックの外側にあるxの値は
1のままになります。

However, a variable that (a) already exists, and (b) is not a block parameter, is not 
local to the block.

ただし、(a) 既に存在していて、かつ
(b) ブロックパラメーターでない変数はそのブロックに対してローカルにはなりません。

  x = 1
  [2,3].each {|y| x = y }

x is now 3. If you want or need to shield your existing variables from being used 
inside the block, declare variables as block local by putting them after a semi-colon 
in the parameter list:

実行後のxは3になります。
既存の変数をブロックの内側で使うものから防御する必要があるようなときには
変数をパラメーターリストの中でセミコロンのあとに置くことによって
ブロックローカルなものとして宣言します。

  x = 1
  [2,3].each {|y;x| x = y }

x is still 1.
この場合実行後もxは1です。

Method argument semantics
メソッド引数のセマンティクス

Method arguments do some new things too. In particular, you can now put required 
arguments after the optional argument glob parameter:

メソッド引数もまた新しいことをします。特に、必須引数 (required arguments)を
glob パラメーターのオプション引数のあとに置けるようになりました。

  def my_meth(a,*b,c)

There aren't too many situations where you'd want to do this (though there are one or two).

あなたがこのようなことをしたいと考えるであろう状況はそう多くはないでしょう
(though there are one or two)。

The * operator has changed semantics
*演算子はそのセマンティクスが変更されています
Compare 1.8:

  >> a = [1,2]
  => [1, 2]
  >> *b = a
  => [[1, 2]]
  >> b
  => [[1, 2]]

and 1.9:

  >> a = [1,2]
  => [1, 2]
  >> *b = a
  => [1, 2]
  >> b
  => [1, 2]

I've always interpreted the * operator in the following way:
わたしは常に *演算子を以下のようにして解釈しています:

The expression *x represents the contents of the array x, as a list.

*x という式は配列 x の内容をリストとして表現する。

In 1.8, *b = [1,2] means that [1,2] is the contents of the array b, which means that b 
is [[1,2]]. The 1.9 semantics don't seem to behave that way. I'm not sure what the 
new general rule for * is, or whether maybe I was wrong that there was such a rule 
that governed all cases (though I can't think of an exception).

1.8では、*b = [1,2] は配列 bの内容であることを意味していて、結果としてbは[[1,2]] となります。
1.9のセマンティクスではそのような動作はしません。
わたしはまだ新しい *x の general rule がどういうことか確信が持てません。
or whether maybe I was wrong that there was such a rule 
that governed all cases (though I can't think of an exception).


Hashes are ordered (ハッシュは順序を持つように代わりました。)

This isn't likely to bite you but it's something to be aware of, both in your own 
code and in looking at the code of others. Hashes are ordered by insertion order. 
Reassigning to a key does not change the insertion placement of that key.

これはあなたに噛付くようなことではありませんが、
あなた自身のコードと参照している他の人のコードの両方で
気をつけなければならないことです。
ハッシュは挿入された順序で順序付けされます。
キーに対する再代入はそのキーが置かれていた順番を変えることはありません。

method and friends return symbols

Expressions like obj.methods and klass.instance_methods return symbols instead of 
strings in 1.9. That means that you might have to do to_s operations on them, if you 
need them as strings. However…

1.9では obj.methods や klass.instance_methods のような式は
文字列ではなくシンボルを返すようになりました。
これは、式の値として文字列が必要であるときに
その式に対して to_s 操作を行う必要があるかもしれない
ということです。ただし…

Symbols are string-like (文字列のようなシンボル)

... symbols have become very string-like. You can match them against regular 
expressions, run methods like #upcase and #swapcase on them, and ask them their size 
(i.e., their size in characters). I'm not sure what the purpose of this is. I'd just 
as soon have symbols not be any more string-like than they absolutely have to be.

シンボルはより文字列に似たものになりました。
シンボルに対して正規表現を使ってマッチングをすることもできますし
#upcaseや#swapcaseといったメソッドの実行もできます。
また、その大きさ(キャラクタで数えたときの大きさ)を訊ねることもできます。
わたしにはこれが一体何の目的のためなのかはわかりません。
I'd just as soon have symbols not be any more string-like than they absolutely have to be.


Gems are automatically in the load path (gemsはロードパスに自動的に含まれるようになりました)

When you start Ruby (or irb), your load path ($:) will include the necessary 
directories for all the gems on your system. That means you can just require things, 
without having to require rubygems first. You can manipulate the load path per gem 
version with the gem method.

Ruby (や irb)を起動したとき、ロードパス ($:) は
使用しているシステム上のすべてのgemsのディレクトリを取り込む必要が出てきます。
これにより、一番最初に require rubygems をする必要なく
require したいものをそのまま帰るようになったということです。
gemメソッドをつけてgemのバージョンごとにロードパスを操作することができます。

Lots of enumerable methods return enumerators
(enumerable メソッドの多くがenumeratorを返すようになりました)

Called without a block, most enumerable methods now return an enumerator. It's fairly 
unusual to use the return value of blockless calls to map, select, and others, but it's 
worth knowing that now you cannot assume that, for example, Array#each will always 
return its receiver.

ブロックなしで呼び出したときに、大部分の enumerable メソッドは enumerator を
返すようになりました。
客観的に見てmapやselectなどをブロックなしに呼び出したときの戻り値を使うことは
通常はありえないことでしょうが、その仮定が絶対ではないことを知ることは重要でしょう。
たとえばArray#each は常にそのレシーバーを返します。

You can use this feature to chain enumerators, though the circumstances in which 
chaining enumerators really buys you anything are pretty few. I don't know of a case 
where you would do this:

この機能を enumerator を連ねるために使うことができます。
enumerator を連結するような circumstances が
実際にはbuys you anything are pretty few なのですが。
わたしにはあなたが次のようなことをしたいだろうと考える状況が思いつきません:


  array.map.other_method { ... }

with the exception of map.with_index. The map call is essentially a pass-through 
filter here. (This was not true in early versions of 1.9, where you could attach 
knowledge of a block to a chained enumerator, but that behavior was removed.)

with the exception of map.with_index. 
この map の呼び出しは本質的にには pass-through フィルターです
(これは初期の1.9ではそうではありませんでした。
where you could attach knowledge of a block to a chained enumerator,
but that behavior was removed.)

Incidentally, you win the prize (which is endless glory :-) if you can account for the 
difference between these two snippets:

Incidentally,
以下の二つのコード片の間の違いを指摘できれば
you win the prize (which is endless glory :-)


  >> {1 => 2}.select {|x,y| x }
  => {1=>2}
  >> {1 => 2}.select.select {|x,y| x }
  => [[1, 2]]

It's all about enumerators….

If you're careful about these changes, and keep an eye out for others, you should be 
able to continue to have fun with Ruby in version 1.9 and beyond!

これらの変更点に注意し、その他の事柄についても気を配っておけば
あなたはRubyのバージョン1.9やそれ以降のバージョンでも楽しみつづけることが
できるでしょう!

■_ 青年(かどうか知らないけど)の主張

Eight Python warts - glyphobet • глыфобет • γλυφοβετ
musings over a tuna fish sandwich »essays »blurbs »travelog
Eight Python warts
Thursday, January 15th, 2009 at 10:49  

I love Python, but a few things still bug me about it. I've bashed on several other 
technologies; here's some Python bashing. In no particular order:

わたしはPythonが大好きではあるけれども、自分にとってはバグ同然の仕様も幾つかある。
以前、別のテクノロジーを幾つか叩いたことがあるけれども、今回はPythonについて。
特に決まった順序ではない:

    * len() should be a method on collections, not a built-in.
      len() は組み込み関数ではなく、コレクションのメソッドであるべきだ。

    * The GIL sucks, and it's going to get suckier until someone fixes it, and that 
      will be hard.
      GILは××で、誰かが修正するまではsuckier になっていくことだろう。
      もっともそうするのは困難だろうけど。

    * (Mutable) default arguments are shared across function invocations: def 
       foo(bar=[]). This one nails newbies all the time.
      (Mutable) デフォルト引数が関数呼び出しの間で共有される: def foo(bar=[]) 。
      これは入門者がいつも引っかかることの一つだ。

    * (1) != (1,) — the first is an integer, and the second a singleton tuple.
      (1) が (1,) とは別のものだったりする  — 最初のものは整数で、二番目は要素が一つのタプル。

    * 2**29 in xrange(2**30) should return instantly, like it does in Ruby, rather than
      iterating up to 2**29. In other words, range objects should have basic knowledge 
      of their endpoints.
      2**29 in xrange(2**30) はRubyがそうであるように即座に戻ってくるべき。
      バカ正直に 2**29 まで数え上げる必要はない。言い換えると、範囲オブジェクトは
      自身の endpoints について基本的な知識をもっているべき。

    * Decorator syntax is ugly and un-Pythonic.  If I wanted @ signs all over my code 
      I would be using Perl.
      デコレーターの構文は醜く(ugly)、Python的ではない。わたしのコードに @記号を
      巻き散らかしたいのなら、わたしはPerlを使うだろうね。

    * No support for labeled break and continue. I continue to respectfully disagree 
      with the rejection of my PEP.
      ラベルつきの break や continue のサポートがない。

    * There's a copy() method on the mutable dict and set types, but not one on list 
      — the best solution is to write foo[:], which is cryptic at best.
      mutable な辞書や集合に対する copy() メソッドが存在しているのにリストに対する
      それがない — それの最善の解決策がなんとも暗号的な foo[:] という記述だとは。

Update: This has started a pretty good discussion on Reddit. Many people correctly 
guessed that I'm using singleton in the mathematical sense, not in the sense of the 
programming pattern. The comments from Cairnarvon and tghw are particularly worth 
reading.

xrange って3.0でなくなったものぢゃん?

2009年01月15日

■_

・高橋会長の例のイベントで書き忘れたこと
といいつつまるで関係のないことではあるのですがw 紹介される本の中に、素材集がいくつか出てきたのですね。イラストレーターに直接食わせられるフォーマットのやつとかいろいろ。んでまあ、こういうもののようにたとえばCGI(のような)スクリプトやプラグインなどは素材として本にまとめて売ることはできるのだろうか。とかなんとか。単にふと思いついただけのことなので何も考えていませんw

■_

Ensuring Code Consistency - AndrewMoore
lair of the dustbunny: Higher Order Perl (Python Style) TOC
C言語はどのように勉強すればよいでしょうか？ - Yahoo!知恵袋
C言語でポインタってどういうメリットがあるの？ - Yahoo!知恵袋
Cyanを設計した高校生、5カ月で5つの言語を習得－＠IT自分戦略研究所
Unicode in Japan
Popular Beliefsが興味深い。
10年先を考えたことがありますか？：ITpro
Big Sky :: select(2)の第一引数にディスクリプタの最大値を渡すのは間違い？
Generator Tricks for Systems Programmers - Version 2.0
Scala 2.7.3 final Released - PLNews: Programming Language News
This release includes: optimization improvements and fixes, improved JVM 1.4 support, scaladoc fixes, ScalaSwing fixes and improvements, bug fixes, and other changes.
tecomp 0.7 Released - PLNews: Programming Language News
tecomp 0.7 has been released. It is an open source, cross-platform Eiffel compiler.
Nordier & Associates
Why Lisp? 3 answers
Why Haskell is beyond ready for Prime Time « Integer Overflow

■_

Guidoパパが新しいblogを始めたもより。 Pythonの歴史について語ってくれるらしい?

http://python-history.blogspot.com/2009/01/introduction-and-overview.html
Introduction and Overview
Introduction

Python is currently one of the most popular dynamic programming languages, along with 
Perl, Tcl, PHP, and newcomer Ruby. Although it is often viewed as a "scripting" 
language, it is really a general purpose programming language along the lines of Lisp 
or Smalltalk (as are the others, by the way). Today, Python is used for everything 
from throw-away scripts to large scalable web servers that provide uninterrupted 
service 24x7. It is used for GUI and database programming, client- and server-side web 
programming, and application testing. It is used by scientists writing applications 
for the world's fastest supercomputers and by children first learning to program.

Pythonは現時点においてPerlやTcl、PHP、そして newcomer である Rubyなどと同じく
最もポピュラーな動的プログラミング言語のひとつです。
Pythonは“スクリプティング”言語とみなされることがほとんどですが、
実際には Lisp や Smalltalkに連なる汎用目的のプログラミング言語なのです
(as are the others, by the way)。
今日、Pythonは使い捨てのスクリプトから24時間365日止まることのない
large scalable webサーバーに到るまであらゆることに使われています。

In this blog, I will shine the spotlight on Python's history. In particular, how 
Python was developed, major influences in its design, mistakes made, lessons learned, 
and future directions for the language.

このブログでは、Pythonの歴史に対してスポットライトをあてようと考えています。
特に、どのようにPythonが開発されたとか、
その設計におけるおいて受けた主な影響とか犯してしまった間違い、
学んだこと、そして future directions for the language

Acknowledgment: I am indebted to Dave Beazley for many of the better sentences in this 
blog. (For more on the origins of this blog, see my other blog.)

A Bird's Eye View of Python (Pythonに対する鳥瞰)

When one is first exposed to Python, they are often struck by way that Python code 
looks, at least on the surface, similar to code written in other conventional 
programming languages such as C or Pascal. This is no accident---the syntax of Python 
borrows heavily from C. For instance, many of Python's keywords (if, else, while, for, 
etc.) are the same as in C, Python identifiers have the same naming rules as C, and 
most of the standard operators have the same meaning as C. Of course, Python is 
obviously not C and one major area where it differs is that instead of using braces 
for statement grouping, it uses indentation. For example, instead of writing 
statements in C like this

少なくとも表面上は他のCやPascalのような
conventional programming languages　で記述したものとよく似ています。
これは偶然そうなったのではありません。
Pythonの構文はCからかなりの部分を借りてきているのです。
たとえばPythonのキーワードの多く(if, else, while, for, etc.)はCのものと同じです。
Pythonにおける識別子はCと同じ名前規則に従っています。
そして標準的な演算子のほとんどがCのそれと意味が同じようになっています。
もちろんPythonはCではないことは明らかなことであり、
文をまとめるのにブレースを使わずにインデントを用いているいう点は大きな違いです。



if (a < b) {
    max = b;} else {
    max = a;}

Python just dispenses with the braces altogether (along with the trailing semicolons 
for good measure) and uses the following structure

Python は単にブレースをとりのぞいて次のような構造を使用します
(末尾についたセミコロンは良い指標になります)。

if a < b:
    max = b else:
    max = a

The other major area where Python differs from C-like languages is in its use of 
dynamic typing. In C, variables must always be explicitly declared and given a 
specific type such as int or double. This information is then used to perform static 
compile-time checks of the program as well as for allocating memory locations used for 
storing the variable's value. In Python, variables are simply names that refer to 
objects. Variables do not need to be declared before they are assigned and they can 
even change type in the middle of a program. Like other dynamic languages, all 
type-checking is performed at run-time by an interpreter instead of during a separate 
compilation step.

PythonとCに似た言語との違いでほかに大きなものとして、動的な型付けをしている
ということがあります。Cでは変数は常にきちんと宣言して、
intやdoubleのような特定の型を与えておかなければなりません。
この情報はその後のプログラムに対する静的なコンパイル時チェックで使われます。
as well as for allocating memory locations used for storing the variable's value.
Pythonでは、変数は単にオブジェクトを参照する名前に過ぎません。
変数は代入する前に宣言する必要もなく、プログラムの途中で型を変えることさえ可能です。
他の動的言語と同じく、すべての型検査は独立したコンパイルステップはなく
実行時にインタープリターによって行われます。


Python's primitive built-in data types include Booleans, numbers (machine integers, 
arbitrary-precision integers, and real and complex floating point numbers), and 
strings (8-bit and Unicode). These are all immutable types, meaning that values are 
represented by objects that cannot be modified after their creation. Compound built-in 
data types include tuples (immutable arrays), lists (resizable arrays) and 
dictionaries (hash tables).

Pythonの基本的な組み込みのデータ型には、Boolean、数値(機械の整数、任意精度の整数と
浮動小数点数による実数および複素数)、文字列(8ビットとUnicodeの両方)が含まれます。
これらはすべて immutable な型です。それはどういうことかというと、
オブジェクトによって表される値は生成が終わったあとではもう内容を変えることができない
ということです。複合型の組み込みデータ型にはタプル(変更することのできない配列)、
リスト(大きさを変えることのできる配列)や辞書(ハッシュテーブル)が含まれます。

For organizing programs, Python supports packages (groups of modules and/or packages), 
modules (related code grouped together in a single source file), classes, methods and 
functions. For flow control, it provides if/else, while, and a high-level for 
statement that loops over any “iterable” object. For error handling, Python uses 
(non-resumable) exceptions. A raise statement throws an exception, and 
try/except/finally statements specify exception handlers. Built-in operations throw 
exceptions when error conditions are encountered.

プログラムを組織化するために、Pythonではパッケージ(モジュールやパッケージの集合)や
モジュール(関係のあるコードをひとつのソースファイルにまとめたもの)、
クラス、メソッド、関数をサポートしています。
フロー制御のためには、if/else、whike、および
任意の“iterable” できるオブジェクトについてloop over する
高水準のfor 文があります。
エラーハンドリングのためにPythonでは(復帰することができない)例外を使います。
raise 文は例外を送出し、try/except/finally といった文は例外ハンドラーを特定します。
組み込みの操作はエラー状態に遭遇したときに例外をスローします。

In Python, all objects that can be named are said to be "first class." This means that 
functions, classes, methods, modules, and all other named objects can be freely passed 
around, inspected, and placed in various data structures (e.g., lists or dictionaries) 
at run-time. And speaking of objects, Python also has full support for object-oriented 
programming including user-defined classes, inheritance, and run-time binding of 
methods.

Pythonでは名前をつけることのできるオブジェクトはすべて“first class”であると言えます。
これは、関数やクラス、メソッド、モジュールおよび
そのほか全ての名前がついたオブジェクトは自由に
passed around, inspected, and placed in various data structures (e.g., lists or dictionaries) 
at run-time.
そしてオブジェクトについて語るとき、Pythonはユーザー定義クラスやインターフェース、
メソッドの実行時束縛を含むオブジェクト指向プログラミングも完全にサポートしています。

Python has an extensive standard library, which is one of the main reasons for its 
popularity. The standard library has more than 100 modules and is always evolving. 
Some of these modules include regular expression matching, standard mathematical 
functions, threads, operating systems interfaces, network programming, standard 
internet protocols (HTTP,FTP, SMTP, etc.), email handling, XML processing, HTML 
parsing, and a GUI toolkit (Tcl/Tk).

Pythonは大規模な標準ライブラリを有しています。これはPythonがポピュラーになった
理由のひとつです。
標準ライブラリには百を超えるモジュールがあり、常に改良が続けられています。
そのようなモジュールには、正規表現マッチングや、標準数学関数、
スレッド、オペレーティングシステムに対するインターフェース、
ネットワークプログラミング、
標準インターネットプロトコル(HTTP,FTP, SMTP, etc.)
emailの取り扱い、
XMLの処理、
HTMLの解析、
GUIツールキット (Tcl/Tk)

In addition, there is a very large supply of third-party modules and packages, most of 
which are also open source. Here one finds web frameworks (too many to list!), more 
GUI toolkits, efficient numerical libraries (including wrappers for many popular 
Fortran packages), interfaces to relational databases (Oracle, MySQL, and others), 
SWIG (a tool for making arbitrary C++ libraries available as Python modules), and much 
more.

これに加えて、サードパーティにより非常に大規模に供給される
モジュールとパッケージがあり、それらのほとんどはオープンソースでもあります。
そういったものにはwebフレームワーク(挙げていくには多すぎるほどの数です!)や、
GUI ツールキット、
効率の良い数値演算ライブラリ (多くのポピュラーなFotranパッケージに対する
ラッパーを含みます)、リレーショナルデータベースに対するインターフェース
(Oracle、MySQL、などなど)、SWIG
(C++によるライブラリをPythonのモジュールとして使えるようにするツール)
といったものがあり、その他にもたくさんのものがあります。


A major appeal of Python (and other dynamic programming languages for that matter) is 
that seemingly complicated tasks can often be expressed with very little code. As an 
example, here is a simple Python script that fetches a web page, scans it looking for 
URL references, and prints the first 10 of those.

Python の major appeal (とPython以外の動的プログラミング言語 for that matter)
はほんの少しのコードで複雑なタスクのほとんどをこなすことができるようだということです。
たとえば以下にあるのはwebページをフェッチする単純なPythonスクリプトで、
対象となるURL リファレンスをスキャンしてから最初の十個を出力します。

# Scan the web looking for references

import re
import urllib

regex = re.compile(r'href="([^"]+)"')

def matcher(url, max=10):
    "Print the first several URL references in a given url."
    data = urllib.urlopen(url).read()
    hits = regex.findall(data)
    for hit in hits[:max]:
        print urllib.basejoin(url, hit)

matcher("http://python.org")

This program can easily be modified to make a web crawler, and indeed Scott Hassan has 
told me that he wrote Google's first web crawler in Python. Today, Google employs 
millions of lines of Python code to manage many aspects of its operations, from build 
automation to ad management (Disclaimer: I am currently a Google employee.)

このプログラムはweb クローラーに変更するのも簡単にでき、
Scott Hassan はわたしにGoogleの最初のwebクローラーを彼がPythonで書いたと
話してくれたことがあります。今日、Googleは何百万行というPython コードを
ビルドの自動化から広告のマネージメントに到るまで
 (Disclaimer: I am currently a Google employee.)
manage many aspects of its operations
のためにemploy しています。

Underneath the covers, Python is typically implemented using a combination of a 
bytecode compiler and interpreter. Compilation is implicitly performed as modules are 
loaded, and several language primitives require the compiler to be available at 
run-time. Although Python's de-facto standard implementation is written in C, and 
available for every imaginable hardware/software platform, several other 
implementations have become popular. Jython is a version that runs on the JVM and has 
seamless Java integration. IronPython is a version for the Microsoft .NET platform 
that has similar integration with other languages running on .NET. PyPy is an 
optimizing Python compiler/interpreter written in Python (still a research project, 
being undertaken with EU funding). There's also Stackless Python, a variant of the C 
implementation that reduces reliance on the C stack for function/method calls, to 
allow co-routines, continuations, and microthreads.


いくつかの言語のプリミティブは実行時に使用可能になるようコンパイラーに要求します。
Python の de-facto standard の実装がCでかかれたものであるにも関わらず
コンパイルは暗黙のうちにモジュールがロードされたかのように振る舞い、
いくつかの他の実装もポピュラーになってきています。
JythonはJVM上で動作するバージョンであり、シームレスにJavaと integration されています。
IronPython はMicrosoft .NET プラットフォーム向けのもので、
.NET上で動作する他の言語と同様に integration されています。
PyPy はPythonで書かれた最適化Python コンパイラー/インタープリター です
(これはまだ research project で being undertaken with EU funding)。
さらにStakless Pythonというものもあります。これはCで実装されたものの変種で
コルーチン(co-routhines)や継続(continuations)、マイクロスレッド(microthreads)
を使えるようにするために、関数やメソッドを呼び出す際のCのスタックに対する
依存性を減少させたものです。

http://python-history.blogspot.com/2009/01/pythons-design-philosophy.html

The History of Python
"skip to main | skip to sidebar
The History of Python

A series of articles on the history of the Python programming language and its community.

Tuesday, January 13, 2009
Python's Design Philosophy

Later blog entries will dive into the gory details of Python's history. However, 
before I do that, I would like to elaborate on the philosophical guidelines that 
helped me make decisions while designing and implementing Python.

いずれこのブログで、Python の歴史の細かいところ (gory details)へ潜っていくことに
なりますが、その前にPythonの設計と実装に関してわたしの判断を助ける
philosophical guidelines を eraborate したいと思います。

First of all, Python was originally conceived as a one-person “skunkworks” project – 
there was no official budget, and I wanted results quickly, in part so that I could 
convince management to support the project (in which I was fairly successful). This 
led to a number of timesaving rules:

まず最初に、Pythonは元々ある一人の人間の“スカンクワークス”プロジェクトであった
ということです。there was no official budget (公式な予算もついていませんでした)
わたしは即座に結果が欲しかったので
I could convince management to support the project (in which I was fairly successful).
これはいくつかの timesaving rules を導き出しました:

    * Borrow ideas from elsewhere whenever it makes sense.
      使えるものならどこからでもそのアイデアを拝借する
    * “Things should be as simple as possible, but no simpler.” (Einstein)

    * Do one thing well (The "UNIX philosophy").
      ひとつのことをきちんとやろう (UNIXの哲学)

    * Don't fret too much about performance--plan to optimize later when needed.
      性能にこだわり過ぎないようにしよう。必要になったらそのとき最適化を考えよう

    * Don't fight the environment and go with the flow.

    * Don't try for perfection because “good enough” is often just that.
      完璧を求めない。なぜなら “good enough”で十分なことがほとんどなのだから。

    * (Hence) it's okay to cut corners sometimes, especially if you can do it right later.
      であるから、時には角を切り落とすこともありです。特にあとで正しくできるときには。

Other principles weren't intended as timesavers. Sometimes they were quite the opposite:
この他の原則は timesaves としてではありません。
they were quite the opposite であることもあります。

    * The Python implementation should not be tied to a particular platform. It's 
      okay if some functionality is not always available, but the core should work 
      everywhere.
      Python の実装はある特定のプラットフォームに結びついたものであるべきではない。
      一部の機能が常に使えるわけではないという場合にのみそれは許されるけれども
      コアの部分はどこででも動作するものであるべきだ。

    * Don't bother users with details that the machine can handle (I didn't always 
      follow this rule and some of the disastrous consequences are described in
      later sections).
      ユーザーを機械が扱うことのできる詳細に bother させない
      (わたしはこの規則に常に従っているわけではなく、後のセクションで
      some of the disastrous consequences are described)

    * Support and encourage platform-independent user code, but don't cut off access 
      to platform capabilities or properties (This is in sharp contrast to Java.)
      ユーザーが書くコードをプラットフォーム独立なものとするのをサポートし、かつ
      推進する。ただしプラットフォームのcapabilities であるとか properties に
      アクセスするのを遮断したりはしない(これはJavaとは明確な違いです)。

    * A large complex system should have multiple levels of extensibility. This maximizes
      the opportunities for users, sophisticated or not, to help themselves.
      large complex system は multiple levels of extensibility を有するべきである。
      それは、sophisticated されているいないに関係なく
      ユーザーがhelp themselves する opportunities を最大化する。

    * Errors should not be fatal. That is, user code should be able to recover from 
      error conditions as long as the virtual machine is still functional.
      エラーは致命的なものであるべきではない。つまり、ユーザーのコードは
      仮想機械が動作可能である限りエラーから回復可能であるべできであるということ。

    * At the same time, errors should not pass silently (These last two items 
      naturally led to the decision to use exceptions throughout the implementation.)
      同時に、エラーをだまって握りつぶすべきではない

    * A bug in the user's Python code should not be allowed to lead to undefined 
      behavior of the Python interpreter; a core dump is never the user's fault.
      ユーザーのPythonコードにあるバグは
      Pythonインタープリターの未定義動作
      ユーザーの失敗によってコアダンプすることがあってはならない。

Finally, I had various ideas about good programming language design, which were 
largely imprinted on me by the ABC group where I had my first real experience with 
language implementation and design. These ideas are the hardest to put into words, as 
they mostly revolved around subjective concepts like elegance, simplicity and 
readability.

わたしは良いプログラミング言語の設計についての様々なアイデアを持っていました。
それはわたしが最初に実際のプログラミング言語の実装と設計とを経験した
ABC グループの影響によるものが大です。
そのようなアイデアは言葉にすることがとても難しく、
as they mostly revolved around subjective concepts like elegance,
simplicity and readability.

Although I will discuss more of ABC's influence on Python a little later, I'd like to 
mention one readability rule specifically: punctuation characters should be used 
conservatively, in line with their common use in written English or high-school 
algebra. Exceptions are made when a particular notation is a long-standing tradition 
in programming languages, such as “x*y” for multiplication, “a[i]” for array 
subscription, or “x.foo” for attribute selection, but Python does not use “$” to 
indicate variables, nor “!” to indicate operations with side effects.

PythonがABCから受けた影響については少しあとで言及することになりますが、
ここで特に一つの readability rule について述べておきたいと思います。
punctuation characters  は英語の表記法や高校の数学で通常使われているように
conservatively に使うべきです。
例外は、掛け算を “x*y” と書くとか配列の添え字付けを “a[i]” のようにしたり
attribute selection を “x.foo” とするような長く使われてきた特別な表記だけです。
Python では変数を示すのに “$”を使ったり副作用を持つ操作を明示するために“!”
を使うようなことはありません。

Tim Peters, a long time Python user who eventually became its most prolific and 
tenacious core developer, attempted to capture my unstated design principles in what 
he calls the “Zen of Python.” I quote it here in its entirety:

古くからのPythonユーザーであり
tenacious core developer である Tim Peters は
“Zen of Python” と彼が呼ぶものにわたしがunstatedにしている design principles
をまとめました。

    * Beautiful is better than ugly.
    * Explicit is better than implicit.
    * Simple is better than complex.
    * Complex is better than complicated.
    * Flat is better than nested.
    * Sparse is better than dense.
    * Readability counts.
    * Special cases aren't special enough to break the rules.
    * Although practicality beats purity.
    * Errors should never pass silently.
    * Unless explicitly silenced.
    * In the face of ambiguity, refuse the temptation to guess.
    * There should be one-- and preferably only one --obvious way to do it.
    * Although that way may not be obvious at first unless you're Dutch.
    * Now is better than never.
    * Although never is often better than right now.
    * If the implementation is hard to explain, it's a bad idea.
    * If the implementation is easy to explain, it may be a good idea.
    * Namespaces are one honking great idea -- let's do more of those!

(すでに訳があるのでご自分で探しておくんなまし)

Although my experience with ABC greatly influenced Python, the ABC group had a few 
design principles that were radically different from Python's. In many ways, Python 
is a conscious departure from these:

Pyhonに多大な影響を与えた ABCでのわたしの経験ではありますが
ABCグループはPythonとは大きく違う (radically different)デザイン原則
を幾つか持っています。
In many ways, Python is a conscious departure from these:

    * The ABC group strived for perfection. For example, they used tree-based data 
      structure algorithms that were proven to be optimal for asymptotically large 
      collections (but were not so great for small collections).
      ABCグループは strived for perfection
      たとえば、彼らは
      asymptotically large  collections に対して理想的に検索を行う
      tree-based なデータ構造アルゴリズムを
      使っていました(しかしこれは小さなコレクションに対してはそれほど良いものではありませんでした)

    * The ABC group wanted to isolate the user, as completely as possible, from the 
     “big, bad world of computers” out there. Not only should there be no limit on the 
      range of numbers, the length of strings, or the size of collections (other than the 
      total memory available), but users should also not be required to deal with files, 
      disks, “saving”, or other programs. ABC should be the only tool they ever needed. 
      This desire also caused the ABC group to create a complete integrated editing 
      environment, unique to ABC (There was an escape possible from ABC's environment, for 
      sure, but it was mostly an afterthought, and not accessible directly from the language.)
      ABCグループはユーザーを“big, bad world of computers”  から
      isolate することを望みました。
      数を表現する範囲や文字列の長さ、コレクションの大きさといったものに(使用可能な
      メモリの量以外の理由で)制限を持たせないだけでなくファイルやディスク、“セーブ”、
      といったものを扱うことをユーザーが要求されるべきではないとしたのです。
      このことは、ABCグループがABCに特有の
      complete integrated editing environment
      を造ることに繋がったのです。
      (もちろん ABCの環境から逃れることは可能ではありましたが、それはほとんど後付けの
      ことであり言語から直接アクセスすることができなかったのです)

    * The ABC group assumed that the users had no prior computer experience (or were 
      willing to forget it). Thus, alternative terminology was introduced that was 
      considered more “newbie-friendly” than standard programming terms. For example, 
      procedures were called “how-tos” and variables “locations”.

      ABCグループではユーザーはそれまでにコンピュータに関する経験がないものである
      (あるいは忘れてしまっている)という
      仮定を置いていました。
      このため、より“初心者向け”になるように通常のプログラミング用語を
      言い換えるようなことをしていました。
      たとえば手続きは “how-tos”と呼ばれますし、変数は“locations”という名称です。

    * The ABC group designed ABC without an evolutionary path in mind, and without 
      expecting user participation in the design of the language. ABC was created as a 
      closed system, as flawless as its designers could make it. Users were not encouraged 
      to “look under the hood”. Although there was talk of opening up parts of the 
      implementation to advanced users in later stages of the project, this was never 
      realized.
      ABCグループは evolutionary path を考慮せずにABCを設計しました。
      また、言語の設計において user participation  を期待するということもありませんでした。
      ABC は (as flawless as its designers could make it) クローズドシステムとして作られました。
      ユーザーは“look under the hood”を encourage されることはありませんでした。
      プロジェクトのlater stages で advanced users のための実装が話されることはあったのですが
      それが実現することはなかったのです。

In many ways, the design philosophy I used when creating Python is probably one of the 
main reasons for its ultimate success. Rather than striving for perfection, early 
adopters found that Python worked "well enough" for their purposes. As the user-base 
grew, suggestions for improvement were gradually incorporated into the language. As we 
will seen in later sections, many of these improvements have involved substantial 
changes and reworking of core parts of the language. Even today, Python continues to 
evolve.

わたしがPythonを作るときに使っている設計哲学 (design philosophy) とは
probably one of the main reasons for its ultimate success.
アーリーアダプターたちはPythonに完全を追い求めるのではなく
自分たちの目的を "well enough"  にこなしてくれることを発見したのです。
ユーザーベースが増加するにつれて改良の提案が gradually incorporated into the language.
後々見ることになるのですが、そういった改良の多くは
言語の核の部分の substantial changes and reworking 
を必要としました。今日においてもなお、Pythonは進化しつづけているのです。

Posted by Guido van Rossum at 9:29 AM 5 comments

■_

推薦図書/必読書のためのスレッド 43 
897 デフォルトの名無しさん [sage] Date:2009/01/14(水) 23:18:00  ID: Be:
    >>893
    あの手の嘘はもう秋田よな

    そういえば最近CJKV情報処理の新版が出たぞ
    急いで読む本じゃないから訳を待つか原書で読むか悩み中

お、出たのか。これだな。 CJKV Information Processing | O'Reilly Media


CJKV Information Processing | O'Reilly Media
CJKV Information Processing, Second Edition

By Ken Lunde
December 2008
Pages: 900
ISBN 10: 0-596-51447-6 | ISBN 13: 9780596514471

Description

CJKV Information Processing, the unsurpassed source of information on processing text 
in Chinese, Japanese, Korean, and Vietnamese, has been thoroughly updated to provide 
web and application developers with the latest techniques and tools for disseminating 
information directly to audiences in East Asia. This second edition reflects the 
considerable impact that Unicode, XML, OpenType, and other modern technologies have 
had on East Asian text processing in recent years.

Full Description

First published a decade ago, CJKV Information Processing quickly became the 
unsurpassed source of information on processing text in Chinese, Japanese, Korean, and 
Vietnamese. It has now been thoroughly updated to provide web and application 
developers with the latest techniques and tools for disseminating information directly 
to audiences in East Asia. This second edition reflects the considerable impact that 
Unicode, XML, OpenType, and newer operating systems such as Windows XP, Vista, Mac OS 
X, and Linux have had on East Asian text processing in recent years.

Written by its original author, Ken Lunde, a Senior Computer Scientist in CJKV Type 
Development at Adobe Systems, this book will help you:

    * Learn about CJKV writing systems and scripts, and their transliteration methods
    * Explore trends and developments in character sets and encodings, particularly 
Unicode
    * Examine the world of typography, specifically how CJKV text is laid out on a 
page
    * Learn information-processing techniques, such as code conversion algorithms and 
how to
      apply them using different programming languages
    * Process CJKV text using different platforms, text editors, and word processors
    * Become more informed about CJKV dictionaries, dictionary software, and machine
      translation software and services
    * Manage CJKV content and presentation when publishing in print or for the Web

Internationalizing and localizing applications is paramount in today's global market 
-- especially for audiences in East Asia, the fastest-growing segment of the computing 
world. CJKV Information Processing will help you understand how to develop web and 
other applications effectively in a field that many find difficult to master.

あれ、薄くなってる?



CJKV Information Processing | O'Reilly Media
CJKV Information Processing Chinese, Japanese, Korean & Vietnamese Computing

By Ken Lunde
January 1999
Pages: 1128
ISBN 10: 1-56592-224-7 | ISBN 13: 9781565922242

jp にもあるな。 Amazon.co.jp: cjkv: 洋書どうしよう。 Amazon.com: CJKV Information Processing: Ken Lunde: Books comで買っても安くつくかどうかは微妙っぽいな。

■_ xgawk update

glibcのregexにバグフィックスでもあったのかな?


======
Note: to view a patchset, just run this command inside the Savannah
gawk-stable directory:

   cvsps -u -g -s <patchset number>

(the '-u' arg updates the cvsps cache, so not required each time)

---------------------
PatchSet 229 
Date: 2009/01/12 15:31:00
Author: arnold
Branch: HEAD
Tag: (none) 
Log:
Bi-annual sync with GLIBC.

Members: 
	ChangeLog:1.87->1.88 
	getopt.c:1.2->1.3 
	regcomp.c:1.10->1.11 
	regex.c:1.3->1.4 
	regex.h:1.4->1.5 
	regex_internal.c:1.2->1.3 
	regex_internal.h:1.7->1.8 
	regexec.c:1.7->1.8 

---------------------
PatchSet 230 
Date: 2009/01/13 02:24:56
Author: arnold
Branch: HEAD
Tag: (none) 
Log:
Clean up sync to GLIBC.

Members: 
	ChangeLog:1.88->1.89 
	regex_internal.h:1.8->1.9 
	regexec.c:1.8->1.9 


Note: to view a patchset, just run this command inside the Savannah
gawk-stable directory:

   cvsps -u -g -s <patchset number>

(the '-u' arg updates the cvsps cache, so not required each time)

あとでチェックしてこう。

2009年01月14日

■_

・PC
いよいよデスクトップの方が怪しくなってきたなあ。とはいえどうしたものか。

■_ Some things every C programmer should know about C

"Some things every C programmer should know about C PMK 10-16-2002 "
http://www.klausler.com/cnotes.txt

Types
-----

Every constant, object, function, and expression in C has a type.
Most generally, a type is either an unqualified type or such a type
qualified with "const", "volatile", or both qualifiers.  Unqualified
types comprise three categories:

Cにおけるすべての定数、オブジェクト、関数、式は型を持っています。
最も一般的には、
型は修飾されていない型(unqualified type) か“const”などによって
修飾されている型のいずれかになります。
修飾されていない型には三つのカテゴリがあります。


	Object types (オブジェクト型)
		Scalar (スカラー)
		   Arithmetic (算術型)
		      Integral (整数型)
		         signed/unsigned/plain
		            character types
		            short, int, long
		         bitfield (ビットフィールド)
		         enumeration (列挙)
		      Floating-point (浮動小数点型)
		   Pointer to general type (一般型へのポインター)
		Aggregate (集成型)
		   struct/union of object types and bitfields (構造体/共用体とビットフィールド)
		   known-size array of objects (オブジェクトの大きさが既知である配列)
	Incomplete types (不完全型)
		void
		undefined struct/union (未定義の構造体/共用体)
		array of unknown size of objects (オブジェクトの大きさが未知の配列)
		array of incomplete type (except void) (不完全型の配列。voidを除く)
	Function returning void or unqualified object type (except array)
		(with no arguments, with unknown or old-style arguments, or
		 with prototyped arguments of general types)
                 引数を持たないか、未知の引数もしくは旧形式の引数をとるか
                 プロトタイプつきの一般型の引数をとる

Bitfields may appear only as struct/union members, so
there are no pointers to bitfields, arrays of bitfields, or
functions taking or returning bitfields.

ビットフィールドは構造体もしくは共用体のメンバーとしてのみ使うことができるので
ビットフィールドへのポインターであるとか
ビットフィールドの配列、
ビットフィールドを引数にとったり戻り値として返す関数というものは存在しません。

Some types are silently replaced.  A qualified array type becomes
an unqualified array of the qualified type, and function arguments
that are arrays or functions become pointers.

一部の型は暗黙のうちに置き換えられます。
修飾された配列型はその修飾型の修飾されていない配列になり、
関数の引数として与えられた配列はポインターになります。


Declarator Syntax (宣言の構文)
-----------------

Binding is just like expressions: postfix before prefix.  So
parentheses are necessary in declarators only for function arguments
and for pointers to functions and arrays!

束縛はちょうど式のようなもので、後置形式(postfix)と前置形式(prefix)があります。
ですから、カッコ対が必須となるのは
関数の引数宣言であるか関数か配列へのポインターの宣言においてのみです!

In qualified pointer types, the pointer qualifiers appear after the *.
修飾されたポインター型では、そのポインター修飾子は*のあとに現れます。

How to easily read a declaration from left to right:
宣言を左から右へ簡単に読む方法:

	transform function argument types from inside out first
	関数の引数の型をinside から変形する
	move the base type to the end
	ベースとなる型を末尾に移動する
	add outer parentheses if there's an initial *
	先頭に * があった場合にはその外側にカッコを付加する
	change every (*...) to ... ->
		one -> for each *
		move qualifiers, so * const becomes const ->
        すべての (*...) を ... → に変更する(一つの * に対して一つの→)
                 修飾子を移動して * const を const → のようにする

Example: const int *(**const x [])()

	*(**const x [])() const int		base type to end
	(*(**const x [])()) const int		add outer parens
	(**const x [])() -> const int		remove outer ()
	x [] const -> -> () -> const int	remove inner ()

	array of constant pointers to pointers to functions
	returning pointers to constant ints
	const int へのポインターを返す関数へのポインターへの const ポインターの配列


Types of Constants (定数の型)
------------------

Floating-point constants are "double" unless suffixed by 'F' or 'L'.

浮動小数点数の定数はサフィックス'F'もしくは'L'がつかない限り“double”となります。

Integer constants take the first type that fits in one of these lists:
整数定数は以下のリストの上から見て行って最初に適合した型となります:
	with 'U':	unsigned int, unsigned long
	with 'L':	long, unsigned long
	with 'UL':	unsigned long
	decimal:	int, long, unsigned long
	octal, hex:	int, unsigned int, long, unsigned long
(So 2147483648 is long but 0x80000000-0xffffffff are unsigned int.)
したがって 2147483648 は long になりますが 0x80000000-0xffffffff は unsigned int になります。

Character constants are "int".
String literals are arrays of "char".

文字定数は“int”です。
文字列リテラルは“char”の配列となります。

Null pointer constants: (ナルポインター定数)
	any zero-valued integral constant expression,
	possibly cast to (void *)
	(void *) にキャスト可能な値がゼロとなるような任意の整定数式。


Operator Precedence and Associativity (演算子の優先順位と結合性)
-------------------------------------

These are the classes of operators in decreasing order of precedence.
以下に挙げるのは優先順位の高いものから低いものの順に演算子を分類したものです。

	(x)
	postfix:	x[y], x(...), x.y, x->y, x++, x--
	prefix:		++x, --x, (type) x, sizeof x, &x, *x, +x, -x, ~x, !x
	multiplicative:	x*y, x/y, x%y
	additive:	x+y, x-y
	shift:		x<<y, x>>y
	relational:	x<y, x<=y, x>y, x>=y
	equality:	x==y, x!=y
	bitwise and:	x&y
	bitwise xor:	x^y
	bitwise or:	x|y
	logical and:	x&&y
	logical or:	x||y
	conditional:	x?y:z
	assignment:	x=y and *= /= %= += -= <<= >>= &= ^= |=
	sequence:	x,y

All binary operators are left-associative where it makes a difference,
except of course for assignment.  The conditional x?y:z operator
is the ONLY doubtful case that is right-associative!

make a differenceの場合、代入を除きすべての二項演算子は左結合になります。
条件演算子 x?y:z は右結合である *唯一の* doubtful case です!

	So	x ? y : a ? b : c
	is	x ? y : (a ? b : c)
	not	(x ? y : a) ? b : c

Some syntactic equivalences:
文法的に等価なものがいくつかあります:

	x->y	means	(*x).y
	x[y]	means	*(x+y)
	!x	means	x == 0

Rules applying to x.y and *x may thus apply to x->y or x[y] as well.
Note that "!!x" is equivalent to "x != 0".

当然、x.y と *x に適用される規則はそれぞれx->y や x[y] にも適用されます。
 "!!x" は "x != 0" と等価であることに注意してください。


Notes on Operators (演算子に関する注意)
------------------

Pointer arithmetic is always in units of the pointer's base
type.  This means that adding or subtracting an integer to or
from a pointer yields a pointer to another element in the
same array.

ポインターの演算は常にそのポインターのベース型のユニットで行われます。
これは、あるポインターに対して整数の加減算を行ったときの結果が
同じ配列中の別の要素を指すということを意味します。

	p + 1 == &p [1]

Subtracting two pointers yields a distance that is also in
units of the pointer's base type.

二つのポインター間の減算もそのポインターのベース型のユニットで行われ、
結果はその差となります。

These operators always return either 0 or 1:

以下の演算子は常に0もしくは1を返します:

	!x
	relations and equalities (<, <=, >, >=, ==, !=)
	x && y
	x || y

The logical operators (x && y, x || y) do not evaluate their
second operands if the first operand determines the result.

論理演算子 (x && y, x || y) は、
その最初のオペランドが結果を決定できる場合には二番目のオペランドを
評価しません。


On two's-complement processors,

二の補数を使用しているプロセッサーにおいては以下のようになります。

	-x == ~x + 1
	~x == -1 - x
	x & -(1<<y)	lowers x to a multiple of a power of two
				xより小さい2の冪の積
	(1 << x) - y == y ^ ((1 << x) - 1)
	(x&y) + (x|y) == x + y == (x^y) + ((x&y) << 1)

Note that sizeof (type) requires parenthese, while sizeof expression
does not.

sizeof 式 がカッコを省略できるのに対して、sizeof (型)では必須であることに
注意してください。

Lvalues
-------

An Lvalue represents the location of an object or function, and
might be the target of assignment.  An Rvalue is any other value,
such as an object's value or a constant or a function result.

lvalueとは、オブジェクトもしくは関数の位置を示すものであり、
代入の対象となることができるものです。
rvalueとはその他の任意の値のことで、オブジェクトの値であるとか
定数、関数の戻り値などが含まれます。

Only these expressions are Lvalues:

以下に挙げる式だけがlvalueです。

	identifiers of objects and functions (オブジェクトや関数の識別子)
	"string literal" ("文字列リテラル")
	(Lvalue) 
	Lvalue.member
	*Rvalue

x.y is an Lvalue if x is, and has all the qualifiers of
the types of both x and y.  Casts are not Lvalues.
As a consequence of the syntactic equivalences noted above,
these expressions are also Lvalues:

x がlvalueであればx.yもlvalueであり、xとyの両方の型の修飾子すべてを持ちます。
キャストはlvalueではありません。
先に述べた syntactic equivalences によって以下の式もlvalueになります:

	Rvalue->member
	Rvalue [Rvalue]


An Lvalue is modifiable if its type is none of these:
lvalue は以下に挙げる型のいずれでもなければ変更することが可能です:

	function
	array
	incomplete
	const-qualified
	struct/union with any unmodifiable member


Implicit Promotions, Conversions, and Operations (暗黙の昇格、変換、操作)
------------------------------------------------

Lvalues (other than arrays and functions) become Rvalues of
unqualified type except in these contexts:

(配列でも関数でもない) lvalue は以下に挙げるコンテキストの場合を除き
修飾されていない型 のrvalueとなります。

	sizeof
	&x
	x++, x--, ++x, --x
	x.member
	left sides of assignments (x=..., x+=..., etc.)

Lvalues of array type are converted to Rvalues of pointer type
pointing to their first members except in these contexts:

配列型の lvalue は、以下に挙げるコンテキストの場合を除き
その先頭要素を指すポインター型のrvalueへと変換されます。

	sizeof
	&x
	"string literal" in a character array initializer


There are no Rvalues of array type in C outside sizeof.

Cにおいては、sizeof の外側では配列のrvalue というものは存在しません。

Function designators are converted to Rvalues of pointer to
function type (except in &x which does that anyway).
So if "f" is the name of a function, all of these are synonyms,
and all have type "pointer to function":

Function designators は関数型へのポインターのrvalueに変換されます
(except in &x which does that anyway)。
したがって、関数の名前が“f”であるときに以下に挙げるすべてがsynonymであり、
かつすべての型が“関数へのポインター”となります。

	f
	*f
	***f
	************************************f

Integral promotions: (整数の昇格)
Rvalues of these types (plain, signed,and unsigned) become "int" or "unsigned int":

以下に挙げる型(のplain, signed, unsignedのすべて)は“int”もしくは
“unsigned int”となります:

	char
	short
	bitfields of type int or smaller
	enum

The famous Usual Arithmetic Conversions:
Given two operands to a binary operator, find the first type
in this list that matches one of the operands, then convert
the other operand to that type.

ある二項演算子に二つのオペランドを与えたとき、
以下のリストにおいていずれかのオペランドが最初に適合する最初の型を見つけ出し、
もう一つのオペランドをその型へと変換します。

	long double
	double
	float
	(apply integral promotion, then)
		unsigned long
		long + unsigned -> long or unsigned long
		long
		unsigned
		int

Function argument conversions in the absence of argument types:
関数の引数に対する変換は in the absence of argument types:

	integral promotions
	float -> double


There is an implicit "x != 0" in
以下の状況においては "x != 0" が暗黙のうちに仮定されます

	if (x)
	while (x)
	do while (x)
	for (; x; )
	x && x
	x || x
	x ? y : z

An explicit "x != 0" in these contexts serves no semantic purpose.
And "x == 0" in these contexts might be better written as "!x".

これらのコンテキストにおいてはっきりと "x != 0" のように記述することは
serves no semantic purpose.
また、これらのコンテキストにある "x == 0"  は
"!x" と記述するよりも好ましいかもしれません。

Scopes, Namespaces, and Linkage (スコープ、名前空間、リンケージ)
-------------------------------

Scopes: (スコープ)
	file (ファイル)
	block (ブロック)
	entire function body (for labels) ((ラベルに対して)関数の本体全体)
	prototype (プロトタイプ)

Beware struct/union/enum tags in prototype scopes.

プロトタイプスコープ中にある struct/union/enum のタグに注意するしてください。

Distinct namespaces (per scope): 
名前空間は(スコープごとに)区別されます:
	struct/union/enum tags (構造体/共用体/列挙)
	labels (ラベル)
	everything else (それ以外)

Storage classes determine linkage of names thus:

ストレージクラスは名前のリンケージを決定します:

	if "static" {
		if file scope
			linkage is internal
		else
			no linkage
	} else if "extern" or a function {
		if a declaration is visible at file scope
			link to it
		else
			linkage is external
	} else if file scope
		linkage is external
	else
		no linkage

Object declarations with initializers and function declarations
with bodies are definitions.  Object declarations without
initializers are tentative definitions with zero fill if
they are not "extern".

初期化を伴うオブジェクトの宣言および
本体を伴う関数の宣言は定義としてみなされます。
初期化を伴わないオブジェクトの宣言は 
"extern" がついていなければ
ゼロによってその領域が埋められます。


Translation Steps (翻訳のステップ)
-----------------

A C compiler must behave as if each of these steps were completely
performed before proceeding.

Cコンパイラーは以下のステップが存在するかのように順番に、手前の処理が終了してから
続く処理を行わなければなりません。

	Turn end-of-line indicators into newlines and replace ??trigraphs
	end-of-line indicators の改行への変換とトライグラフの変換

	Delete all backslash-newline pairs
	すべての backslash-newline pairs の削除

	Form tokens and replace comments by single spaces
	トークンの形成とコメントの一つの空白への置換
	
	Preprocessing and macro expansion
	プリプロセスの実行とマクロの展開

	Process \escape sequences in 'character constants' and "string literals"
	文字定数および文字列リテラル中のエスケープシーケンスの処理

	Delete white space, including newlines
	改行を含む空白の削除

	Concatenate adjacent "string literals"
	"文字列リテラル" のConcatenate adjacent

	Parse and generate code
	構文解析とコードの生成

	Link
	リンク

■_

teideal glic deisbhéalach » Blog Archive » Fun with Haskell view patterns
Fun with Haskell view patterns

January 11th, 2009 by Bryan O'Sullivan

One of the pleasant new features in GHC 6.10 is the long-awaited addition of view 
patterns. This feature is usually advertised as making it possible to pattern match 
against the values of an abstract type. An essential aspect of modular software design 
is that we don't want to expose the implementation of complex code. Someone will 
surely come along and start making decisions based on bits of our code that they can 
see, thus limiting our future room to manoeuvre. This is all amply explained on the 
view pattern wiki page and in the GHC User's Guide.

GHC 6.10 での pleasant な新しい機能の一つに
長らくその追加が待たれていた view patterns があります。
この機能は抽象型の値に対するパターンマッチを可能にするものとしてよく喧伝されています。
modular software design の essential aspect とは
わたしたちは複雑なコードの実装を expose することを望まないということです。
Someone will surely come along and
start making decisions based on bits of our code that they can see,
thus limiting our future room to manoeuvre.
This is all amply explained on the view pattern wiki page and in the GHC User's Guide.

However, view patterns give us some nice capabilities even if we're not building fancy 
abstract code. For instance, I often find myself wanting a function like this:

view pattern はわたしたちがfancy な抽象コード (abstract code)を構築しないとしても
わたしたちに some nice capabilities  をもたらしてくれるものです。

dropPrefix :: Eq a => [a] -> [a] -> ([a],[a])
dropPrefix left@(x:xs) right@(y:ys)
    | x == y    = dropPrefix xs ys
dropPrefix left right = (left,right)

Given two lists with common prefixes, this drops any common prefix from each, and 
returns the residual lists. Here are some examples from messing around with ghci:

共通の prefix を持った二つのリストを与えたとき、
これはリストのそれぞれにある共通 prefix をすべて drop して、
residual リストを返します。
Here are some examples from messing around with ghci:

Prelude> dropPrefix "foo" "foobar"
("","bar")
Prelude> dropPrefix "foo" "quux"
("foo","quux")
Prelude> dropPrefix "foolish" "football"
("lish", "tball")

A perennial source of mild annoyance with Haskell patterns is that matching a pattern 
against a string is a pain. Suppose we're doing some quick and dirty processing of a 
FASTA protein sequence:

>gi|5524211|gb|AAD44166.1| cytochrome b [Elephas maximus maximus]
LCLYTHIGRNIYYGSYLYSETWNTGIMLLLITMATAFMGYVLPWGQMSFWGATVITNLFSAIPYIGTNLV

The ">" above indicates that a line is a header, while the data on the 
following line is the beginning of the cytochrome B protein sequence. If we we're 
reading a GenBank sequence, we know that the header will begin with ">gi|", 
but matching this with a normal Haskell pattern is a pain:

genbankHeader ('>':'g':'i':'|':rest) = muddle rest

All of the ticcy syntactic noise above masks the simplicity of our aim: we want to 
bind the name rest to the remainder of the string, if it begins with 
">gi|".

An alternative formulation might be as follows:

genbankHeader str | ">gi|" `isPrefixOf` str =
    let rest = drop 4 str
    in muddle rest

This is easier to read, but it's quite wordy, and we have to traverse str twice: once 
to match, once to drop.

これは読みやすいものではありますが、quite wordy であり
str を二度トラバースする必要があります。
一度はマッチのために、もう一度は drop のために。

What can we do with our dropPrefix function?

genbankHeader str =
    case dropPrefix ">gi|" str of
      ("", rest) -> muddle rest

This is better, but still not ideal. What can view patterns offer here?

これは better ではありますがまだ理想的なものではありません。
ここで view pattern が offer できることとは?

{-# LANGUAGE ViewPatterns #-}
genbankHeader (dropPrefix ">gi|" -> ("", rest)) = muddle rest

GHC will compile this last form into the equivalent of the case expression above, but 
this notation is much more compact, and hence (at least to my eyes) rather easier to 
read.

GHC はこの最後のフォームを前述した case expression と等価なものにコンパイルしますが、
この記法はより一層コンパクトなものでありそれによって(少なくともわたしの目には)
より読みやすいものになっています。

5 Responses to “Fun with Haskell view patterns”

■_



「人間を甘く見ている」巨匠・出崎統が"萌え"を斬る！（後編） : 日刊サイゾー
──そういうワーカーホリックな人生をすばらしいと思うし、たくさん労働するのは、好きな仕
事だから全然かまわないと思うんです。ただアニメーション業界の職場環境について、今後改善
していかなければならないこともあると思うんですが、出崎さんからみてのご意見は。

【出崎】ぼくも全部を知っているわけじゃないから、迂闊なことは言えない。でも昔は虫プロに
したって東映にしたって、人をちゃんと育てていたよね。ちゃんと給料を払って、育てる時間を
持った。会社が、組織がね。それがないでしょ、いま。虫プロの第何期生という身分は、それは
とても力になるし、誇りでもある。習ってはいるけれどもぼくたちはプロなんだという状況で覚
えていくことと、ぼくたち学生ですという状況で覚えていくこととでは、体験の質が、重さが、
全然違う。そこを業界がどう考えてんだろうな、って。それは課題ですよね。

──いまアニメがデジタル化して機械技術的には進歩したけど、アニメーションそのものの質が
上がっているかどうかというところについてはいかがですか？

【出崎】いやいや、決して上がってないと思う。だってもう自然現象を描ける人がいないんだか
ら。この海の感じどうすんの、この川の流れどうすんの。実写より綺麗な絵を作ろうよと言った
ときに、いまはもうCGを使っちゃうけどね。自然現象は、学問とは言わないけれども、少なくと
も力学を常識的にわかってないと出来ない。昔はみんなそれを一所懸命勉強したんだよ。

■_



「コンパイラ・スクリプトエンジン」相談室12 [bbs2chreader]
950 デフォルトの名無しさん [] Date:2009/01/14(水) 15:19:28  ID: Be:
    LRで還元した記号は次の入力になりますよね？
    この次の入力になる記号って普通どこに置くものなんですか？
    次の入力専用に非終端記号型の変数を用意するもの？ 

951 デフォルトの名無しさん [sage] Date:2009/01/14(水) 16:59:35  ID: Be:
    >>950
    なりません。
    次の入力（移動で得られる記号）はあくまでも終端記号列でできた入力記号から取られます。
    還元して得られた非終端記号はどこにも保存されません。
    スタックされたLRの状態遷移表の状態そのものがそれまでの履歴を表しているからです。
    LRの説明で分かりやすくするために状態と一緒に還元された記号も入れることはありますが、
    本質的なものではなく本来入れる必要はないものです。 

952 デフォルトの名無しさん [sage] Date:2009/01/14(水) 17:20:46  ID: Be:
    「入れる」は状態スタックにプッシュするってことね。多くのLR構文解析系はスタックを使って状態記号を保存するので。
    LR構文解析は状態記号が入ったスタックのトップの状態と入力記号列の最初の終端記号からだけで次に行うべき動作を決定する。
    その動作が移動なら入力から一つ記号を取り出し構文解析表から次に移る状態を引いて状態スタックにプッシュする。
    還元なら生成規則に従って状態スタックから特定の数だけ状態をポップして、
    その時の状態スタックのトップの状態と還元された非終端文字で決まる状態をプッシュする。
    この時にだけ還元された記号が使われるが後から使ったりしないので特に保存する必要はない。 

953 デフォルトの名無しさん [] Date:2009/01/14(水) 18:07:01  ID: Be:
    >>952
    だとするととてもありがたいのですが、それほんとに信じてもいいんですよね？
    LR構文解析機を作ったことがあったうえで言ってるんですよね？ 

954 デフォルトの名無しさん [sage] Date:2009/01/14(水) 18:18:51  ID: Be:
    >>953
    感謝の言葉もなしに>>952になんて失礼なことを言ってるんだ、こいつはｗ 

955 デフォルトの名無しさん [] Date:2009/01/14(水) 18:21:41  ID: Be:
    ちょっと読み返すと失礼にあたる書き方に見えてきました。
    どうもすいません。
    >>953をちょっと補足します。
    コンパイラIの286ページ図4.39を参考にします。
    ここでI0からI1へ遷移するためには非終端記号Sの入力が必要なのではないか？
    と考えたわけです。
    逆に終端記号のみから次の遷移先を決定できる項集合について考えると、
    循環する文法記号がある場合、永遠に展開し続けねばならず、終端記号のみからなる
    gotoグラフの作成は不可能ではないかと考えたのです。
    これを可能にするには、goto表の入力となる非終端記号を何に置き換えればいいのでしょう？

    よろしくお願いします。

956 デフォルトの名無しさん [sage] Date:2009/01/14(水) 18:22:25  ID: Be:
    相談に来ておいて相手に文句たれる奴っているよね。
    なんで相談する気になったのかいつ見ても不思議 

957 デフォルトの名無しさん [] Date:2009/01/14(水) 18:23:05  ID: Be:
    >>954さんも>>952さんの考えを裏付けるってことですか？
    私はドラゴンブックを見て考えていたので、最近の事情は知らないのです。
    よろしくお願いします。 

958 デフォルトの名無しさん [sage] Date:2009/01/14(水) 18:26:03  ID: Be:
    >>957
    裏づけがほしいんだったら、相応の対価を払って専門家に会って聞くべき 

959 デフォルトの名無しさん [sage] Date:2009/01/14(水) 18:54:20  ID: Be:
    構文解析系が入力記号列と状態スタックから構成されている場合、
    状態スタックには最初に初期状態０がプッシュされている。
    構文解析動作は、入力記号列の先頭の記号と状態スタックのトップ状態を見て、
    対応する状態遷移表の項目からその動作を決定する。
    移動なら、入力記号列の先頭記号を消費し、指定の状態を状態スタックにプッシュ。
    還元なら、指定の生成規則の右辺の記号数だけ状態スタックからポップし、
    　　　　　その時の状態スタックのトップ状態と生成規則の左辺とで決まる状態をプッシュ。
    受理なら、正しく構文解析が完了。それ以外はエラー。
    構文解析系はこれだけで動作する。還元された非終端記号はそれ以降の動作に出てくることはない。
    例えば、数と＋を終端記号、式を非終端記号として、
    (1) 式 ::= 式 ＋ 数
    (2) 式 ::= 数
    のような生成規則に対して、＋は左結合的とすると、
    状態０：入力記号が数なら移動し状態１、還元されたものが式なら状態２
    状態１：有無を言わせず生成規則(2)によって還元する
    状態２：入力記号が＋なら移動し状態３、入力が終端に達していたら受理
    状態３：入力記号が数なら移動し状態４
    状態４：有無を言わせず生成規則(1)によって還元する
    のような状態遷移表が作られる。
    状態スタック：０｜入力記号列：数＋数＋数　（０と数で状態１移動）
    ０，１｜＋数＋数　（１と＋で生成規則(2)による還元、状態を1個ポップし０と式なので状態２をプッシュ）
    ０，２｜＋数＋数　（２と＋で状態３移動）
    ０，２，３｜数＋数　（３と数で状態４移動）
    ０，２，３，４｜＋数　（４と＋で生成規則(1)による還元、状態を3個ポップし０と式なので状態２をプッシュ）
    ０，２｜＋数　（２と＋で状態３移動）
    ０，２，３｜数　（３と数で状態４移動）
    ０，２，３，４｜　（４と終端で生成規則(1)による還元）
    ０，２｜　（２と終端で受理）
    で、受理される。 

960 デフォルトの名無しさん [] Date:2009/01/14(水) 19:11:39  ID: Be:
    >>959
    どうもありがとうございます。
    よくわかりました。
    お礼に私に出来ることはありますか？ 

961 デフォルトの名無しさん [sage] Date:2009/01/14(水) 19:13:47  ID: Be:
    >>955
    「コンパイラIの286ページ図4.39を参考に」できないからその内容はよく分からないけれど、
    LR項の集合族間の状態遷移図とLR構文解析系の状態遷移表による動作とは別物。
    LR構文解析系の状態遷移表を構成するための理論的裏づけがLR項の集合族間の状態遷移というだけであって、
    実際に構文解析を行うに当たって非終端記号を入力記号として記録する必要はない。
    もちろん、次の状態を決定するために、ある１動作の範囲内で非終端記号は必要になるが、それだけ。
    そして、その必要な非終端記号は還元時に定まるもので入力として記憶するものではない。 

962 デフォルトの名無しさん [sage] Date:2009/01/14(水) 19:17:23  ID: Be:
    >>960
    別にないよｗ
    構文解析関係は理論だけでは取り付き難いから、
    小さな系でもいいから実際に動作を手で追いかけながら見ていくと理解が進む。 

963 デフォルトの名無しさん [sage] Date:2009/01/14(水) 19:22:28  ID: Be:
    LISPやれば構文とかどうでもよくなる 

964 デフォルトの名無しさん [sage] Date:2009/01/14(水) 19:28:34  ID: Be:
    推敲せずに書いたらちょっと不要なことまで書いてしまった。
    >>959の「＋は左結合的とする」必要はなかった。
    生成規則の定義だけで結合性を指定しなくても衝突は起きない。

ちょっと読み返すと～思えてきました。ってどんだけ(ry



Ruby 初心者スレッド Part 24
489 デフォルトの名無しさん [] Date:2009/01/13(火) 22:34:17  ID: Be:
    今、ドラクエやってるんだけど、太陽の石ってどこにありましたっけ？ 

490 デフォルトの名無しさん [sage] Date:2009/01/13(火) 23:19:46  ID: Be:
    みつかりました
    ありがとうございました 

491 デフォルトの名無しさん [] Date:2009/01/14(水) 00:13:04  ID: Be:
    >>490
    ざけんなｗ 

515 デフォルトの名無しさん [] Date:2009/01/14(水) 21:58:54  ID: Be:
    すいません、まだドラクエやってるんですが、竜王ってどこにいましたっけ？ 

516 デフォルトの名無しさん [sage] Date:2009/01/14(水) 21:59:53  ID: Be:
    竜王城 

517 デフォルトの名無しさん [sage] Date:2009/01/14(水) 22:00:52  ID: Be:
    玉座の後ろの隠し階段だよ 

518 デフォルトの名無しさん [sage] Date:2009/01/14(水) 22:12:27  ID: Be:
    ryuou.castle.search('ryuou') 

519 デフォルトの名無しさん [] Date:2009/01/14(水) 22:15:02  ID: Be:
    一緒に世界征服しようとしたらバッドエンドだ、気を付けろ 

520 デフォルトの名無しさん [sage] Date:2009/01/14(水) 22:26:02  ID: Be:
    昔ファミコンでやってた時何も知らずにバッドエンドだった時は放心した。。。
    パスワードとらずにやってたから初めからやり直しだったなwww
    苦い青春だったぜ

2009年01月13日

■_

・明日はいつもよりも一時間ほど前倒しになるので
縮退バージョンでございまする。

・ネタかぶり
ranha-pagesの日記と微妙に取り上げるものが被ってて、さらに向こうのほうが先に書いてたりしても泣かないw

typedefクイズ
typedef クイズ - odz buffer にコメントもトラックバックもついていないけど、odzさんのところをチェックしている人にとっては今更的なネタなんだろうか。

■_ PHPはなんで(ry

PHPを意に染まず使っている方々にはご愁傷様。

Five reasons why the shut-op operator (@) should be avoided - Derick Rethans

Five reasons why the shut-op operator (@) should be avoided 
(黙れ演算子 (@) を使うべきでない五つの理由)
[ Saturday, 3rd of January, 2009 - 22:21 - Skien, Norway ]

Reason 1: It creates a debugging hell (デバッグ地獄を作り出す)

The @-operator is often used to silence errors in noisy PHP functions - functions that 
generate warnings that can not be easily prevented. An example might be to silence 
network errors with stream_socket_client(), or hiding connection errors for mysql_connect(). 
In those cases, there is no way how to check up-front whether the function call will 
not issue a warning when being called (unlike fopen() where you could first call 
file_exists() for example).

@演算子はしばしばPHPの口うるさい関数でのエラーを静かにさせるために使われています。
functions that generate warnings that can not be easily prevented.
たとえば stream_socket_client() を使ったときのネットワークエラーを黙らせたり
mysql_connect() でコネクションエラーを隠すために使われています。
そのようにしてしまった場合、その関数呼び出しが行われたときに警告するような
事象があったかどうかを確かめる術はありません
(unlike fopen() where you could first call file_exists() for example)。

Using the @-operator can have annoying side effects however. Years ago I was helping a 
co-worker debugging a MySQL issue with our software eZ Publish. We could not find out 
why it would not successfully create a connection to the database through Apache, 
while it was working fine from the command line with the same code. We started 
browsing through our code and found that the mysql_connect() call was prepended by the 
@-operator to hide possible connection warnings/errors from our users. After removing 
the @ to see what errors we would get, we were surprised to see that the error message 
was "Fatal error: Call to undefined function mysql_connect()". Turned out 
that the MySQL extension was a shared object that was only loaded by the php.ini file 
that the command line client of PHP was using, while the one used by the PHP in Apache 
did not load the extension. In this case, only after about two hours, we found that 
the @-operator was hiding slightly more errors than we'd expected.

@演算子を使うことでよろしくない副作用も抱え込むことになる可能性があります。
何年か前のことですがわたしは同僚の eZ Publish というわたし達のソフトウェアの
MySQLに関連したデバッグ作業を手伝ったことがあります。
わたしたちは、
コマンドラインから実行したときには正しく動くのと同じコードが
Apache経由のときにデータベースへの接続が成功しないというその理由を
見つけることができないでいたのです。
わたしたちは自分たちのコードを隅から隅まで眺めていって、
接続時のエラーや警告のメッセージをユーザーから隠すために
mysql_connect() の呼び出しが@演算子つきで行われていることを発見しました。
@を取り除いたあとでわたしたちが見ることのできたエラーはわたしたちを驚かせるものでした。
そこにあったエラーメッセージは
"Fatal error: Call to undefined function mysql_connect()"
だったのです。
php.ini の設定により
PHPをコマンドラインから使ったときにだけ MySQL エクステンションの共有オブジェクトが
ロードされるようになっていて、ApacheからPHPを使ったときにはそのエクステンションは
ロードされていなかったのです。
このときわたしたちはさらに二時間ほど調べてみたのですが、
@演算子がわたしたちが当初考えていたよりも多くのエラーを握りつぶしていることを発見したのです。


From then on, we made it our policy that the @-operator should be avoided, and if used, 
only is allowed with a comment with what error we're supposed to be hiding with them.

このようなことがあってから、わたしたちは自分たちのポリシーとして
@演算子は排除すべきものであって、どうしても使う場合には
わたしたちが隠すことを前提としているエラーをコメントしている場合にのみ許可する
ということを決めたのです。

Reason 2: It's slow (part 1) (遅い Part1)

Whenever the @-operator is used, PHP needs to invoke the INI settings mechanism to 
change the temporary value of the error_reporting setting to 0. That this happens, can 
be seen in the following example:

@演算子が使われたときはいつでも、PHPは 
一時的に変更された error_reporting の設定値を0に戻すために
INI setting mechanism の起動を必要とします。
That this happens, can be seen in the following example:

<?php $error_reporting = ini_get( 'error_reporting' ); echo $error_reporting, 
"\n"; $error_reporting = @ini_get( 'error_reporting' ); echo 
$error_reporting, "\n"; ?>

The output of this example is:
この例の出力はこうなります:

32767 0

It requires the INI mechanism because it allows a proper clean-up at the end of each 
request, where every internal value of each INI setting is reset back to its original 
value. Without this, a call such as @die(); would set error_reporting to 0 and when 
the script bails out PHP does not get the chance to reset it back to its original 
value.


これは INI機構を要求します。
なぜなら、各リクエストごとに適切な後処理を許可しているために
各 INI 設定の内部的な値のすべてが元の値へと reset back する必要があるからです。
これがないと @die() のような呼び出しで
error_reporing が 0にセットされる可能性があり
スクリプトの実行が中止されたときにPHPは元の値を復帰させる機会がなくなってしまいます。

Reason 3: It's slow (part 2) (遅い Part2)

Whenever PHP generates an error message internally, it's processed and formatted all 
the way up to the fully formatted message that can be outputted straight to the browser. 
Only just before it is displayed the error_reporting setting is checked. This however, 
is not related to the @-operator exclusively. The error message is just 
always fully formatted before error_reporting is checked - or display_errors for that 
matter.

PHPがエラーメッセージを内部的に生成するときはいつでもブラウザーでそのエラーメッセージ
が正しく表示できるように fully format されます。
メッセージを表示する正にその直前で error_reporting がセットされているかどうかの
検査が行われるのです。しかしその検査は @演算子が使われているかどうかとは
関係していません。
error_reporting や display_erros がチェックされるよりも前に
エラーメッセージは常に完全に組み立てられるのです。


Reason 4: It's slow (part 3: It generates crappier code) (遅い Part3: crappier codeを生成する)

The reason why I started writing about the @-operator comes from a new feature that I 
am implementing for Xdebug : the addition of variable assignments in function traces. 
When writing tests I found out that the Zend compiler generates quite a bit slower 
code in case the @-operator is used. With VLD we can see this difference clearly. For 
the code:

わたしが @演算子を使うようなコードを書き始めた理由は、Xdebugを実装するために
関数のトレース中での変数代入という新しい機能に取り組んでいたときにあります:
テストを書いているときにわたしは @演算子を使ったときに
Zend コンパイラーがはっきりと認識できるくらい遅いコードを生成していることに
気がつきました。VLDを使ってわたしたちは@演算子の有無でどのように違うかを
はっきりと理解することができました。
次のようなコードがあったとしましょう:


<?php $t['a'] += $b; ?>

The compiler creates the following opcodes:
コンパイラーは以下のようなオペコードを作り出します:

compiled vars: !0 = $tf, !1 = $t, !2 = $b 15 EXT_STMT 16 ASSIGN_ADD !1, 'a' 17 ZEND_OP_DATA !2, $7

But for the code:
しかしソースコードが次のようなものであった場合

<?php @$t['a'] += $b; ?>

The compiler generates:
コンパイラーが生成するのはこうなります:

18 EXT_STMT 19 BEGIN_SILENCE ~8 20 FETCH_R local $11 'b' 21 FETCH_RW local $9 't' 22 ASSIGN_ADD $9, 'a' 23 ZEND_OP_DATA $11, $12 24 END_SILENCE ~8

This shows that when the @-operator is used, the compiler does not generate the much 
faster compiled variables that were introduced with PHP 5.1. Instead, it falls back to 
use the FETCH_* opcodes that look up variables by name. This is much slower as it 
requires a hash lookup. On top of that, more opcodes are generated as well.

これを見てわかるように、@演算子が使われた場合にはコンパイラーは
PHP 5.1で導入されたより高速であるコンパイル済み変数を生成しません。
その代わりに変数をその名前によって検索する FETCH_* オペコードを
使うように falls back してしまっています。
これはハッシュ表の検索を要求するので格段に遅くなります。
On top of that, more opcodes are generated as well.

Reason 5: Apfelstrudels were harmed (Apfelstrudels は有害だ)

The last reason is a bit of a silly one. While looking at the implementation of the 
@-operator, I found the following bits of code in zend_compile.c :

@演算時の実装を調べているときわたしは zend_compile.c の中に以下のような
コードを見つけてしまったのです。

void zend_do_begin_silence(znode *strudel_token TSRMLS_DC)

and

*strudel_token = opline->result;

This last reason is of course not the most important one :-)

この最後の理由はもちろん重要なものではありません :-)

Wesley - Monday, 5th 2009f January, 2009; 19:43:10
So the @ operator also prevents the error from being added to the error_log file? Didn't know that.

■_ 今日のム板から


Lisp Scheme Part24 

964 デフォルトの名無しさん [sage] Date:2009/01/11(日) 23:44:52  ID: Be:
    純粋さよりシンプルさを重視する傾向にあるRnRS-Schemeで
    どうしてsyntax-rulesやsyntax-caseみたいな複雑なマクロが採用されているのかわかりませんね

965 964 [sage] Date:2009/01/11(日) 23:53:51  ID: Be:
    syntax-rulesやsyntax-caseを否定／批判しているわけではありませんので、悪しからず 

966 デフォルトの名無しさん [sage] Date:2009/01/12(月) 00:17:44  ID: Be:
    いや、もっともな意見だね
    define-macroでいいもの
    追求してオナニーするための道具でしかない 

967 デフォルトの名無しさん [sage] Date:2009/01/12(月) 00:44:12  ID: Be:
    シンプルさ重視ならレガシーマクロもいらないんじゃないの
    eval-whenとかけっこう複雑だし
    javascriptかluaを使えばいいと思うよ 

968 デフォルトの名無しさん [sage] Date:2009/01/12(月) 01:53:51  ID: Be:
    個人的な意見だけど、ハイジーニックなマクロは
    define-macroに付き物の 「実行時・コンパイル時」とかそういう「泥臭い」概念を
    排除して、純粋に「アルゴリズミックランゲージ」を追求しようとしたんじゃない
    かなーと思う。
    あと、コンパイル時にLispコードが走るってのは理論面でちょっと扱いづらい
    ような気もするので、それもあるかも。

    まぁ良し悪しは別ね。

    俺はdefine-macroの方が好き。 

969 デフォルトの名無しさん [sage] Date:2009/01/12(月) 05:37:37  ID: Be:
    ERR5RS だと Explicit Renaming を入れて
    syntax-case や syntax-rules はライブラリにしちゃおうなんて提案も挙がってるね。
    http://scheme-punks.org/wiki/index.php?title=ERR5RS:A_Concrete_and_Conservative_Proposal 

970 デフォルトの名無しさん [sage] Date:2009/01/12(月) 10:34:25  ID: Be:
    > 968
    syntax-rulesまではよかった、までは・・・

971 デフォルトの名無しさん [sage] Date:2009/01/12(月) 20:20:15  ID: Be:
    そのよさを説明できないのが問題なんだな
    逆に、syntax-caseのほうが強力だと説明するのは簡単だけど 

972 デフォルトの名無しさん [sage] Date:2009/01/13(火) 01:00:06  ID: Be:
    >>968
    >あと、コンパイル時にLispコードが走るってのは理論面でちょっと扱いづらい
    ような気もするので、それもあるかも。

    それはあると思う。別にdefine-syntaxはコンパイルタイムで実行しなければならない
    というわけじゃないんじゃないか。
    たまたま、分離できるから分離してコンパイルタイムで実行しているだけで、別にその
    必然は無いだろう。

    関係ないけれど、Schemeがらみでよく考えると意味がつながらない説明が結構ある気が
    する。（いままで何となく納得していたけど）
    例えば、代入はダメとか。手続き型みたくはプログラム書くなとか。それでいて、
    具体的に、どういうものが関数型プログラミングなのかよくわからないという状態。
    なんかもー別に、関数型スタイルにこだわる必要ないんじゃない？ 

973 デフォルトの名無しさん [sage] Date:2009/01/13(火) 01:40:52  ID: Be:
    >>972
    内部に状態を持たない処理を組み合わせて、
    プログラムを書く手法が関数型なんだと思うが。
    お前さんも自分で書いてるように。

    関数型にマッチしなけりゃオブジェクト指向とかも使えばいいし、
    何でもかんでも参照透明にしないでもいいじゃない。
    ハッシュとか普通に副作用使ってるし。 

974 デフォルトの名無しさん [sage] Date:2009/01/13(火) 01:57:38  ID: Be:
    参照透明にしたところで、幸せになれることってそんなに無いし。

975 デフォルトの名無しさん [sage] Date:2009/01/13(火) 02:01:06  ID: Be:
    お前が幸せになるためにあるわけじゃないから当たり前だな。

976 デフォルトの名無しさん [sage] Date:2009/01/13(火) 02:30:38  ID: Be:
    再現できたりできなかったりするバグとお別れできるのって、
    割と幸せじゃない？ 

977 デフォルトの名無しさん [sage] Date:2009/01/13(火) 07:10:03  ID: Be:
    関数型で書くから人は幸せになれるんじゃない
    幸せになろうとする過程こそが幸せなんだ 

978 デフォルトの名無しさん [sage] Date:2009/01/13(火) 07:34:48  ID: Be:
    幸せってなんだっけ 

979 デフォルトの名無しさん [sage] Date:2009/01/13(火) 08:07:25  ID: Be:
    しょうゆ～こと 

980 デフォルトの名無しさん [sage] Date:2009/01/13(火) 10:12:26  ID: Be:
    言語が複雑になるとcall/ccの実装が困難になるの？
    common lispにcall/ccないのはそのため？ 

981 デフォルトの名無しさん [sage] Date:2009/01/13(火) 10:42:16  ID: Be:
    call/ccがあるとunwind-protectの実装が不可能になるとか
    GCとC++デストラクタみたいな関係？ 

982 デフォルトの名無しさん [sage] Date:2009/01/13(火) 10:54:28  ID: Be:
    >>976
    手続き型から関数型への変換は機械的にできるんだが、
    それをやってもバグが簡単に見つかるわけじゃない。 

984 デフォルトの名無しさん [sage] Date:2009/01/13(火) 11:03:46  ID: Be:
    そうやって変換したものは、形式上は関数型だが
    内容は手続き型そのものだから「こんなの関数型じゃない！」となる。
    「関数型」の定義が分からないっていうのはそういうこと。 

985 デフォルトの名無しさん [sage] Date:2009/01/13(火) 11:55:53  ID: Be:
    >>982
    関数的な、参照透明性が保証されている書き方をするなら、
    同じ引数を渡せば必ず同じ値が返ってくる。

    再現できたりできなかったりするバグっていうのは、
    内部に状態を持ってて、その状態がその時々で異なるからこそ、
    発生するわけじゃない？

    ついでに言うと、どんなバグでも見付かりやすくはならんぞ。勿論。 

986 デフォルトの名無しさん [sage] Date:2009/01/13(火) 12:43:33  ID: Be:
    説明しよう

    手続き型のプログラムを機械的に変換することで
    「再現できたりできなかったりするバグ」はなんか別の種類のバグに変換されるのだ

    そして、どんなバグでも見付かりやすくはならないのだ 

987 デフォルトの名無しさん [sage] Date:2009/01/13(火) 12:57:43  ID: Be:
    綺麗なモジュールと汚いモジュールを分離できるのはある程度有効なんじゃね
    綺麗な奴はテストで品質を保証しやすいし、
    怪しいのは汚い方だろう、と見当がつけられる 

988 デフォルトの名無しさん [sage] Date:2009/01/13(火) 13:50:55  ID: Be:
    綺麗か汚いかをどんな基準で決めるかって話だが・・・
    代入を使うか使わないかはあまり意味がない気がしてきた。

    ポイントフリースタイルは複雑にならなければ綺麗だと思う。
    代入を使わないんじゃなくて、変数を使わないスタイル。 

989 デフォルトの名無しさん [sage] Date:2009/01/13(火) 14:04:09  ID: Be:
    >>988
    綺麗汚いっつったらなんか主観的な美的観点っぽい話になってしまうか

    俺の判断基準はもっとシンプルで、
    外部の状態に依存する／外部の状態を変更するものは汚い
    そうでなく、もし状態を扱っていても、内部で完結していれば、綺麗
    です

    グローバル変数、I/O、状態を扱う外部モジュールへの依存、などなどが
    「汚い」部類に入ることになります 

990 デフォルトの名無しさん [sage] Date:2009/01/13(火) 15:05:04  ID: Be:
    オブジェクト指向っぽくなってきたね
    やはり最後に勝つのはマルチパラダイムか 

991 デフォルトの名無しさん [sage] Date:2009/01/13(火) 15:54:57  ID: Be:
    Lisp的にはもともとそうなのでは

    LispでEmacsのようなプログラムが作れるわけですが
    参照透明でお上品でお綺麗なEmacsなんて想像もつかない
    キーを一文字打鍵するだけで全部コピーするのは流石にナシでしょうし
    モナドだらけになるのでしょうか？ 

992 デフォルトの名無しさん [sage] Date:2009/01/13(火) 16:23:23  ID: Be:
    >>989
    I/Oもなの?
    Lisp/Schemeが、I/Oに対して行なったストリーム抽象の貢献は、
    先行があったとはいえ、独自のものがあったと思うけれど… 

994 デフォルトの名無しさん [sage] Date:2009/01/13(火) 16:33:38  ID: Be:
    >>992
    えーと、自分の「汚い」という意味は、「悪い」というのとは違います
    I/Oなしで意味のあるプログラムを書くのは不可能ですし……

    単に「現実の泥仕事」に近く、「バグや問題が出やすい場所」と認識しているだけです

997 デフォルトの名無しさん [sage] Date:2009/01/13(火) 18:18:13  ID: Be:
    きれいな言語仕様してるだろ
    ウソみたいだろ
    死んでるんだぜ。それで…
    たいしたキズもないのに、ただ、ちょっとタイプどころが悪かっただけで…
    もう動かないんだぜ
    な
    ウソみたいだろ 

998 デフォルトの名無しさん [sage] Date:2009/01/13(火) 20:49:17  ID: Be:
    もうわけわからん。 

999 デフォルトの名無しさん [sage] Date:2009/01/13(火) 21:28:50  ID: Be:
    まだだまだ終わらんよ 

1000 デフォルトの名無しさん [sage] Date:2009/01/13(火) 21:29:44  ID: Be:
    1000なら今年はLispで仕事ができる 

1001 １００１ [] Date:Over 1000 Thread ID: Be:
    このスレッドは１０００を超えました。
    もう書けないので、新しいスレッドを立ててくださいです。。。

1000に幸あれw

推薦図書/必読書のためのスレッド 43 
815 デフォルトの名無しさん [sage] Date:2009/01/12(月) 20:07:49  ID: Be:
    ミサトとリツコのプログラミング言語C出せば売れるかしら 

816 デフォルトの名無しさん [sage] Date:2009/01/12(月) 20:36:26  ID: Be:
    >>815
    （赤木）ナオコとリツコじゃないの？ 

817 デフォルトの名無しさん [sage] Date:2009/01/12(月) 20:39:34  ID: Be:
    今からエヴァは辛い
    せめて春日 

818 デフォルトの名無しさん [sage] Date:2009/01/12(月) 20:46:55  ID: Be:
    >>816
    駄目よ。それじゃK&Rにならないじゃない。
    そうね。マギも2/3で却下しているわ。（残りの1は、きっと科学者としての母さんね） 

819 デフォルトの名無しさん [sage] Date:2009/01/12(月) 20:47:08  ID: Be:
    一瞬かすがって何だって思っちゃたじゃないか
    でもその手の本はもう既にあると思う 

820 デフォルトの名無しさん [sage] Date:2009/01/12(月) 20:48:07  ID: Be:
    萌えるC言語が出るのは時間の・・・っていまさら出ねえなｗ 

826 デフォルトの名無しさん [age] Date:2009/01/12(月) 23:21:56  ID: Be:
    詳説Ｃ＋＋と言う本の、Ｃ言語版みたいな本はないのでしょうか？
    もしくは組み込み系のＣ言語の本でおすすめ本はありませんか？

    今度、組み込みソフト系の仕事をしてみたいと思っているのですが、
    本屋でＣ言語の本を見ても良さそうな本が見あたりませんでした。
    また定番と言われているK&Rは、まだ難しそうでした。 

827 デフォルトの名無しさん [sage] Date:2009/01/12(月) 23:23:42  ID: Be:
    明解C言語はよく名前が出る 

828 デフォルトの名無しさん [sage] Date:2009/01/12(月) 23:25:57  ID: Be:
    趣味ならいいけど仕事は無理 

829 デフォルトの名無しさん [sage] Date:2009/01/12(月) 23:27:18  ID: Be:
    >>826
    C言語プログラミング　（ダイテル著）

830 デフォルトの名無しさん [sage] Date:2009/01/12(月) 23:27:34  ID: Be:
    組み込みやったことないんだけど
    普通のCと何が違うんだろう？
    昔触ったゲーム機では標準出力がなかったので
    stdio.hなんかが使えなかったりしたがそれくらいしか思いつかん 

831 デフォルトの名無しさん [sage] Date:2009/01/12(月) 23:29:01  ID: Be:
    K&Rが難しいって言ってるんだから
    組み込み系とかよりも、初心者向けでいいんじゃないか 

837 デフォルトの名無しさん [sage] Date:2009/01/13(火) 00:24:00  ID: Be:
    萌えるC言語とか書きたいけど
    画力が足りない。

■_

思っているよりもずっとずっと人生は短い。
バカが征く on Rails 2009年01月13日
会社に潜む情報セキュリティの落とし穴：Winny利用の果て――家族崩壊した銀行マンの悲劇 (1/2) - ITmedia エンタープライズ
The Evolution of Python 3 - O'Reilly Broadcast
QITAB - a collection of free Lisp code
Paratrooper in Haskell
Lesson1：IPv6ではIPアドレスとパケットのヘッダーが変わる：ITpro
次期Visual Studio 2010と.NET Framework 4.0の新機能－＠IT
本稿では、次期Visual Studio 2010（以降、VS 2010）および.NET Framework 4.0（以降、.NET 4）の新機能を概観する。C# 4.0、Visual Basic 10については、本稿では紹介しない。
PCによる目の疲れは、仕事にも恋にもダメージ大－＠IT自分戦略研究所
ask proggit: Whats the opinion on Prolog? : programming
Starting programming career at age 33. How employer see it? - Stack Overflow

Tiny C compiler written in Forth - comp.lang.forth | Google グループ
http://groups.google.ca/group/comp.lang.forth/msg/98fc97704cda1b07

Tiny C compiler written in Forth : programming
http://www.reddit.com/r/programming/comments/7or3b/tiny_c_compiler_written_in_forth/

What is the best way to store UTF-8 strings in memory in C/C++? - Stack Overflow
http://stackoverflow.com/questions/435147/what-is-the-best-way-to-store-utf-8-strings-in-memory-in-c-c

ask proggit: Whats the opinion on Prolog? : programming
http://www.reddit.com/r/programming/comments/7p3mk/ask_proggit_whats_the_opinion_on_prolog/

Prolog いかがっすか?

A 3-INSTRUCTION FORTH FOR EMBEDDED SYSTEMS WORK
http://pygmy.utoh.org/3ins4th.html?0

The Top Ten Erlang News Stories of 2008 – Erlang Inside
http://erlanginside.com/the-top-ten-erlang-news-stories-of-2008-69

Favorite language follow-up: If you could change one thing about your favorite programming language, what would it be? : programming
http://www.reddit.com/r/programming/comments/7p8bq/favorite_language_followup_if_you_could_change/

これは明日かあさってあたりにでもまとめます。

Ctalk 0.0.93a rc 1 Released - PLNews: Programming Language News
Ctalk 0.0.93a rc 1 has been released. Ctalk is an object-oriented extension to C.
amforth 3.2 Released - PLNews: Programming Language News
amforth 3.2 has been released. It is a Forth implementation for the AVR ATmega microcontroller family.
Voodoo v0.2.0 Released - PLNews: Programming Language News
This release includes: the addition of bitwise operators, the replacement of the if conditional with a set of conditionals that compare two values, test cases, documentation updates, bug fixes, and other changes.
Bigloo 3.2a Released - PLNews: Programming Language News
Bigloo 3.2a has been released. Bigloo aims to be a practical Scheme implementation.

脆弱性などの原因に：「最も危険なプログラミングエラー」25種類のリスト発表 - ITmedia エンタープライズこれか。→ SANS Institute - CWE/SANS TOP 25 Most Dangerous Programming Errors



SANS Institute - CWE/SANS TOP 25 Most Dangerous Programming Errors

CATEGORY: Insecure Interaction Between Components
CWE-20: Improper Input Validation
It's the number one killer of healthy software, so you're just asking for trouble if 
you don't ensure that your input conforms to expectations...MORE

CWE-116: Improper Encoding or Escaping of Output
Computers have a strange habit of doing what you say, not what you mean. Insufficient 
output encoding is the often-ignored sibling to poor input validation, but it is at 
the root of most injection-based attacks, which are all the rage these days...MORE

CWE-89: Failure to Preserve SQL Query Structure (aka 'SQL Injection')
If attackers can influence the SQL that you use to communicate with your database, 
then they can...MORE

CWE-79: Failure to Preserve Web Page Structure (aka 'Cross-site Scripting')
Cross-site scripting (XSS) is one of the most prevalent, obstinate, and dangerous 
vulnerabilities in web applications...If you're not careful, attackers can...MORE

CWE-78: Failure to Preserve OS Command Structure (aka 'OS Command Injection')
When you invoke another program on the operating system, but you allow untrusted 
inputs to be fed into the command string that you generate for executing the program, 
then you are inviting attackers...MORE

CWE-319: Cleartext Transmission of Sensitive Information
If your software sends sensitive information across a network, such as private data or 
authentication credentials, that information crosses many...MORE

CWE-352: Cross-Site Request Forgery (CSRF)
With cross-site request forgery, the attacker gets the victim to activate a request 
that goes to your site. Thanks to scripting and the way the web works in general, the 
victim...MORE

CWE-362: Race Condition
Attackers will consciously look to exploit race conditions to cause chaos or get your 
application to cough up something valuable...MORE

CWE-209: Error Message Information Leak
If you use chatty error messages, then they could disclose secrets to any attacker who 
dares to misuse your software. The secrets could cover a wide range of valuable 
data...MORE

CATEGORY: Risky Resource Management
CWE-119: Failure to Constrain Operations within the Bounds of a Memory Buffer
Buffer overflows are Mother Nature's little reminder of that law of physics that says 
if you try to put more stuff into a container than it can hold, you're...MORE

CWE-642: External Control of Critical State Data
There are many ways to store user state data without the overhead of a database. 
Unfortunately, if you store that data in a place where an attacker can...MORE

CWE-73: External Control of File Name or Path
When you use an outsider's input while constructing a filename, you're taking a chance. 
If you're not careful, an attacker could... MORE

CWE-426: Untrusted Search Path
If a resource search path is under attacker control, then the attacker can modify it 
to point to resources of the attacker's choosing. This causes the software to access 
the wrong resources at the wrong time...MORE

CWE-94: Failure to Control Generation of Code (aka 'Code Injection')
For ease of development, sometimes you can't beat using a couple lines of code to 
employ lots of functionality. It's even cooler when...MORE

CWE-494: Download of Code Without Integrity Check
You don't need to be a guru to realize that if you download code and execute it, 
you're trusting that the source of that code isn't malicious. But attackers can 
perform all sorts of tricks...MORE

CWE-404: Improper Resource Shutdown or Release
When your precious system resources have reached their end-of-life, you need to...MORE 

CWE-665: Improper Initialization
Just as you should start your day with a healthy breakfast, proper initialization 
helps to ensure...MORE

CWE-682: Incorrect Calculation
When attackers have some control over the inputs that are used in numeric calculations, 
this weakness can lead to vulnerabilities. It could cause you to make incorrect 
security decisions. It might cause you to...MORE

CATEGORY: Porous Defenses
CWE-285: Improper Access Control (Authorization)
If you don't ensure that your software's users are only doing what they're allowed to, 
then attackers will try to exploit your improper authorization and...MORE

CWE-327: Use of a Broken or Risky Cryptographic Algorithm
You may be tempted to develop your own encryption scheme in the hopes of making it 
difficult for attackers to crack. This kind of grow-your-own cryptography is a welcome 
sight to attackers...MORE

CWE-259: Hard-Coded Password
Hard-coding a secret account and password into your software's authentication module 
is...MORE

CWE-732: Insecure Permission Assignment for Critical Resource
If you have critical programs, data stores, or configuration files with permissions 
that make your resources accessible to the world - well, that's just what they'll 
become...MORE

CWE-330: Use of Insufficiently Random Values
If you use security features that require good randomness, but you don't provide it, 
then you'll have attackers laughing all the way to the bank...MORE

CWE-250: Execution with Unnecessary Privileges
Spider Man, the well-known comic superhero, lives by the motto "With great power 
comes great responsibility." Your software may need special privileges to perform 
certain operations, but wielding those privileges longer than necessary can be 
extremely risky...MORE

CWE-602: Client-Side Enforcement of Server-Side Security
Remember that underneath that fancy GUI, it's just code. Attackers can reverse 
engineer your client and write their own custom clients that leave out certain 
inconvenient features like all those pesky security controls...MORE

■_

書店員の情報交換スレ38
963 マロン名無しさん [sage] Date:2009/01/11(日) 19:30:22 ID:??? Be:
    万引きは、窃盗罪でおｋ。
    どんどん警察に突き出せ。 

964 マロン名無しさん [sage] Date:2009/01/11(日) 20:02:45 ID:??? Be:
    捕まえるたびに名札に撃墜マークつけて怒られたのもいい思い出です
    いいアイディアだと思うんだけどなぁ 

965 マロン名無しさん [sage] Date:2009/01/11(日) 20:06:30 ID:??? Be:
    それはちょっとｗｗｗｗｗ 

986 マロン名無しさん [sage] Date:2009/01/13(火) 08:45:17 ID:??? Be:
    >>964
    キルマークいいな。
    Ｍ．ヴィットマンやＥ．ハルトマン並の戦果になったらどうすんだｗ 

987 マロン名無しさん [sage] Date:2009/01/13(火) 11:54:03 ID:??? Be:
    ハルトマンなんかとっくに越えてますorz 

988 マロン名無しさん [sage] Date:2009/01/13(火) 21:41:15 ID:??? Be:
    >>987
    上に交渉して警備員雇った方がいいぞ、マジで。 

989 マロン名無しさん [sage] Date:2009/01/13(火) 21:46:00 ID:??? Be:
    いや、それを言ったら、状況が北斗の拳冒頭３ページな店舗に６年飛ばされた

おせっかいな解説: エーリッヒ・ハルトマン → 352機撃墜の記録を持つちルフトバッフェ(ドイツ空軍)のちょー大エース。ミハエル・ヴィットマン → タイガー戦車を駆り連合軍の戦車を多数撃破した戦車のエース。

2009年01月12日

■_

・みなみけおかえり　の録画を失敗していてしょぼーんですよあと、そろそろW録のデッキが必要になるような気配に。金ないのに。

・意外?
This Code Goes to Eleven: Graphing Reddit Language Preferences Graphing the "Favorite Language" thread, and some observations. : programming 考察が変だろうというクレームがついてるけどそれはおいといて、 redditで話題に上った言語の内訳を見るとなんか意外な感じがした。

■_ redditに訊け! 2009年の時点で、あなたの好きなプログラミング言語は何で、それはなぜですか?

Proggit: What is your favorite programming language and why, as of 2009? : programming

Proggit: What is your favorite programming language and why, as of 2009? (self.programming)

Still Python. I have yet to find anything as easy and powerful. I've been working with 
Erlang, but that is one ugly language.

What do you think is ugly about it?

Python isn't supposed to be used for that kind of software (shrink-wrapped 
"products"). Python's niches are websites, data processing, rapid 
prototyping, embedded scripting, anything where Python's many disadvantages are 
irrelevant but it's advantages give it an edge.

Anyway, you can distribute bytecode (.pyc/.pyo files) + interpreter packed into an 
executable without the source. It might be easier to decompile than C++, but if you're 
that paranoid write a bytecode obfuscator.

Lisp, because no other language makes me cooler in forums. I have yet to find any 
other language that allows me to be this smug.


Try APL. :)

    * Ruby/Python have a real spec, and can compile to performance within a decimal 
      order of magnitude of Common Lisp
    * Java gets closures, and its libraries get a smidgen of design taste

I like C, Haskell and Scheme.

But my favorite language will always remain Forth even though I don't get to program 
too much in it these days. The combination of speed, incredibly low memory footprint 
and stupefying ability to combine high- and low-level idioms in the same package was 
and is amazing.

Too bad it, like a extremophilic bacteria, has been forced out into ecological niches 
were the environment is far too harsh for mainstream languages to survive.

Depends on what I want to do...

Face it, there is no programming language which is suitable for all tasks.

I do like c, though, because of the low level control it can give me for certain tasks. 
And Erlang is quite elegant for concurrency. Right now I am looking into Python and 
Haskell to see what they can offer.

Python. People gripe about whitespace, but I can't remember when I've cared. On the 
other hand it's very clean and logical and enables me to do a lot with not much code.

Haskell is my favorite language to mess around in. I don't do real work in it, 
though.


Python is my favorite language for real work. Then C/C++ if I need performance... in 
the form of a Python extension.

It's hard to pick a favorite as I'm a pretty big fan of using the right tool for the 
job. I still do full C++ work if size and portability are critical (well, more like C 
with classes, the STL is sometimes not portable enough.) And I will work in Java if 
parsing a language, because ANTLR is awesome and its Java support is leagues better 
than its support for other target languages.

I guess overall, if I really had to nail it down and pick one favorite, I would pick 
Python.

   1. C - because I have always been able to do what I needed in a straightforward
          and portable way.
   2. Scheme - it made me think better

Yup, C and Scheme are two of the most beautiful languages ever created, and they cover 
the two ends of a philosophical spectrum.

Both are very simple, clean, and have a consistent style and philosophy.

This are two languages every programmer should know and love, just like their two 
bibles: K&R and SICP.

That is why Objective C is so brilliant in my mind. Straightforward C and obvious OO.

I've always thought Java was a ripoff of openstep. Today they go head to head iphone 
(openstep derived) vs. Android (java).

OO is evil and stupid.
Note how neither C or Scheme are OO languages, and that is a good thing.

OO has its place. I don't use it everywhere but for GUI and Game development it fits 
the problem space very well. It's all about the right tool for the job.

I still like Assembly.

Objective-C because I do Mac and iPhone work.

I really think it is great though, and a real shame it isn't really supported in more 
places.

C++. I'm not popular for it.

R, because it lets me do scientific analysis easily.

Gawk and python for system work.

C++ and fortran for expensive calculations.

(Colleagues suggest using python for the first in this list, but I find the depth of 
statistical tools in R to be unmatched.)

Still not found anything that lets me work faster than OCaml ...

I prefer SML over OCaml, because it's a far less warty dialect. (IMO) SML is to OCaml 
what C is to C++ (although it's not that extreme in this case)

R, for statistics Python for 90% of things tossed my way Django for a web framework 
(not really a language I suppose)

C# because it's the one I am using.

Javascript

I like Smalltalk and Lisp for their simplicity and uniformity, although I'm not 
actively programming in either one of them.

JavaScript is what I use the most for prototyping because of its Self-inspired 
OOP-implementation.

I use C++ for writing desktop apps and I enjoy it most of the time. I miss closures 
and proper reflection, but I appreciate its expressiveness.

I also occasionally program in PHP (which I hate) and Java (which I think is useful 
but very boring).

I guess I don't have a favorite language.

Haskell, because nothing else gives me the same level of combined real world 
applicibility, safety, and expressiveness.

"Haskell" and "real world" can only be used in a book title.

Criticism is ok, but I'd appreciate it if you elaborated on that, instead of just 
saying that Haskell doesn't have real world applicability.

haskell, because it's elegant, powerful and keeps me humble.


Ruby, because I didn't think programming was particularily fun until I started playing 
with ruby (only had C + Java at university).

The only time I thought of programming as fun was when I had a lecture that involved 
some Lisp and Smalltalk. Never did anything "real" in smalltalk or lisp 
though

c# gets the job done.

    * Limbo: because of its simplicity and C-like flavor while providing the best
      concurrency support of any language I know (only Erlang comes close). As somebody
      described it: the language the creators of C would come up with if they had thirty
      years to polish and improve it.
    * rc: The best language to practice the Unix tool philosophy and glue all your tools
      together, simple, clean and elegant.
    * C: This needs no explanation, other than that I love ken's extensions and
      simplifications of the 'standard' C.

Sorry for providing three, but I'm a firm believer on languages that are simple, are 
really good in one level, and don't try to be everything for everyone.

C, Limbo and rc cover the full range of programing, from the lowest level to the 
highest level. I would add on top of that specialized domain specific languages, but 
that would make the list much longer.

Could you provide a comparison of Limbo and Erlang with regards to concurrency? Thank you.

Haskell, Ruby, C++ and R

Objective-C 4EVA!

Groovy, baby! It's a JVM language, dynamic, with metaprogramming and integrates well 
with Java. It is very good for internal DSLs. The best part is you can drop it in an 
existing java project to make your life easier.

I still like Tcl/Tk the best. I also like Java, Scheme, and Haskell. But I keep coming 
back to Tcl/Tk for its simplicity and power.

For fun and glueing stuff together, Python. But the one that's been paying my bills 
for the last 15 years is Clarion, (sadly) one of the best kept secrets in the 
programming world.

Perl, because it gets things done with little code. Python or Ruby would work but I 
don't like Python style (I hate forced indentation) and Ruby isn't different enough 
from perl to bother.

scheme, because it's minimal, composable and ductile.

まあ適当に抜き出したんですが、ShcemeやHaskell、Python、Rubyあたりが多いのかな。 Rという声もありましたが。

■_ 本日の丸投げ



lions' commentary on unix 練習問題　section3について -OKWave
lions' commentary on unix 練習問題　section3について

困り度：

    * すぐに回答を！

lions' commentary on unix 練習問題　section3の3.1について、「goto文を使わずにすむよう
に手続きschedを書き直せ」という問題の答えが分かりません。分かる方解答お願いします

どんなもんかと調べてみたら、該当のソースコードが見つかった。確かにこれをgoto抜きで記述するのは面倒だなあ。制御の流れが交差している。


UNIX 6th Edition Kernel Source Code
http://www.tom-yam.or.jp/2238/src/

にある

http://www.tom-yam.or.jp/2238/src/slp.c.html

から問題の関数の部分を抜き出し。


1922: /*
1923:  * The main loop of the scheduling (swapping)
1924:  * process.
1925:  * The basic idea is:
1926:  *  see if anyone wants to be swapped in;
1927:  *  swap out processes until there is room;
1928:  *  swap him in;
1929:  *  repeat.
1930:  * Although it is not remarkably evident, the basic
1931:  * synchronization here is on the runin flag, which is
1932:  * slept on and is set once per second by the clock routine.
1933:  * Core shuffling therefore takes place once per second.
1934:  *
1935:  * panic: swap error -- IO error while swapping.
1936:  *      this is the one panic that should be
1937:  *      handled in a less drastic way. Its
1938:  *      very hard.
1939:  */
1940: sched()
1941: {
1942:         struct proc *p1;
1943:         register struct proc *rp;
1944:         register a, n;
1945: 
1946:         /*
1947:          * find user to swap in
1948:          * of users ready, select one out longest
1949:          */
1950: 
1951:         goto loop;
1952: 
1953: sloop:
1954:         runin++;
1955:         sleep(&runin, PSWP);
1956: 
1957: loop:
1958:         spl6();
1959:         n = -1;
1960:         for(rp = &proc[0]; rp < &proc[NPROC]; rp++)
1961:         if(rp->p_stat==SRUN && (rp->p_flag&SLOAD)==0 &&
1962:             rp->p_time > n) {
1963:                 p1 = rp;
1964:                 n = rp->p_time;
1965:         }
1966:         if(n == -1) {
1967:                 runout++;
1968:                 sleep(&runout, PSWP);
1969:                 goto loop;
1970:         }
1971: 
1972:         /*
1973:          * see if there is core for that process
1974:          */
1975: 
1976:         spl0();
1977:         rp = p1;
1978:         a = rp->p_size;
1979:         if((rp=rp->p_textp) != NULL)
1980:                 if(rp->x_ccount == 0)
1981:                         a =+ rp->x_size;
1982:         if((a=malloc(coremap, a)) != NULL)
1983:                 goto found2;
1984: 
1985:         /*
1986:          * none found,
1987:          * look around for easy core
1988:          */
1989: 
1990:         spl6();
1991:         for(rp = &proc[0]; rp < &proc[NPROC]; rp++)
1992:         if((rp->p_flag&(SSYS|SLOCK|SLOAD))==SLOAD &&
1993:             (rp->p_stat == SWAIT || rp->p_stat==SSTOP))
1994:                 goto found1;
1995: 
1996:         /*
1997:          * no easy core,
1998:          * if this process is deserving,
1999:          * look around for
2000:          * oldest process in core
2001:          */
2002: 
2003:         if(n < 3)
2004:                 goto sloop;
2005:         n = -1;
2006:         for(rp = &proc[0]; rp < &proc[NPROC]; rp++)
2007:         if((rp->p_flag&(SSYS|SLOCK|SLOAD))==SLOAD &&
2008:            (rp->p_stat==SRUN || rp->p_stat==SSLEEP) &&
2009:             rp->p_time > n) {
2010:                 p1 = rp;
2011:                 n = rp->p_time;
2012:         }
2013:         if(n < 2)
2014:                 goto sloop;
2015:         rp = p1;
2016: 
2017:         /*
2018:          * swap user out
2019:          */
2020: 
2021: found1:
2022:         spl0();
2023:         rp->p_flag =& ~SLOAD;
2024:         xswap(rp, 1, 0);
2025:         goto loop;
2026: 
2027:         /*
2028:          * swap user in
2029:          */
2030: 
2031: found2:
2032:         if((rp=p1->p_textp) != NULL) {
2033:                 if(rp->x_ccount == 0) {
2034:                         if(swap(rp->x_daddr, a, rp->x_size, B_READ))
2035:                                 goto swaper;
2036:                         rp->x_caddr = a;
2037:                         a =+ rp->x_size;
2038:                 }
2039:                 rp->x_ccount++;
2040:         }
2041:         rp = p1;
2042:         if(swap(rp->p_addr, a, rp->p_size, B_READ))
2043:                 goto swaper;
2044:         mfree(swapmap, (rp->p_size+7)/8, rp->p_addr);
2045:         rp->p_addr = a;
2046:         rp->p_flag =| SLOAD;
2047:         rp->p_time = 0;
2048:         goto loop;
2049: 
2050: swaper:
2051:         panic("swap error");
2052: }
2053: /* ---------------------------       */

sloopやfoundxがなあ。

■_


推薦図書/必読書のためのスレッド 43
793 デフォルトの名無しさん [sage] Date:2009/01/12(月) 13:39:32  ID: Be:
    K&Rってなに？ 

794 デフォルトの名無しさん [sage] Date:2009/01/12(月) 13:41:08  ID: Be:
    金本＆ライガー 

795 デフォルトの名無しさん [sage] Date:2009/01/12(月) 13:49:56  ID: Be:
    プログラマーってなんかオタクっぽくてきもい 

796 デフォルトの名無しさん [sage] Date:2009/01/12(月) 13:50:55  ID: Be:
    >>795
    惜しい

    オタクできもいが正解

ライガーの頭の文字ってLじゃなかったっけ?



【初心者歓迎】C/C++室 Ver.63【環境依存OK】
107 デフォルトの名無しさん [sage] Date:2009/01/12(月) 17:33:03  ID: Be:
    error LNK2019: 未解決の外部シンボル "public: virtual __thiscall CMyClass::~CMyClass(void)" (??1CMyClass@@UAE@XZ) が
    関数 "public: virtual void * __thiscall CMyClass::`scalar deleting destructor'(unsigned int)" (??_GCMyClass@@UAEPAXI@Z) で
    参照されました。

    このエラーはなにがいけないんでしょうか？ 

108 デフォルトの名無しさん [sage] Date:2009/01/12(月) 17:44:20  ID: Be:
    >>107
    ソース内に構文としては正しそうに見える、勘違いによる間違いがある。
    それ以上はソースを見ないとはっきりしないと思う。
    # エスパーならどんな間違いかを推定できそうだけれど。 

109 デフォルトの名無しさん [sage] Date:2009/01/12(月) 17:46:19  ID: Be:
    デストラクタが宣言だけされて実装が書いてないんじゃないの。
    virtualみたいだから、仮想デストラクタで=0でもつけただけだとか。 

110 デフォルトの名無しさん [sage] Date:2009/01/12(月) 18:05:17  ID: Be:
    よくわかるね・・・デストラクタの宣言だけで中身がなかった
    ありがとう！ 

111 デフォルトの名無しさん [sage] Date:2009/01/12(月) 19:39:55  ID: Be:
    >>108-110
    エスパーワラタｗ 

112 デフォルトの名無しさん [sage] Date:2009/01/12(月) 19:42:55  ID: Be:
    コンパイルエラーとリンクエラーの違いが分かっているか、お兄ちゃんは心配だ 

113 デフォルトの名無しさん [sage] Date:2009/01/12(月) 19:44:27  ID: Be:
    いやわかるって。
    リンカが「シンボルが見つからない」って言ってて
    アンマングリングされた名前(デストラクタ)も示してくれてるんだから。

    コンパイル通ってリンクエラーなら、宣言だけで実装がないとしか考えられない。
    あと外部ライブラリでlibを指定してないとかもあるけどね。 

114 113 [sage] Date:2009/01/12(月) 20:04:19  ID: Be:
    相変わらずタイミング悪いな俺。
    >>113は108や111宛てだ。
    質問者(おそらく初心者)はともかく、108がこの程度でエスパーとか言い出すのが不思議過ぎるよ。 

115 111 [sage] Date:2009/01/12(月) 20:20:17  ID: Be:
    流れにﾜﾗﾀ、といえばよかったか



Perlについての質問箱 38箱目
956 デフォルトの名無しさん [sage] Date:2009/01/12(月) 11:30:27  ID: Be:
    無料ホームページでＣＧＩを使ってみたんですが
    ＣＧＩに対しても広告が表示されてしまうので困っています
    なんとかなりませんか？

957 デフォルトの名無しさん [sage] Date:2009/01/12(月) 11:45:06  ID: Be:
    >>1 

958 デフォルトの名無しさん [sage] Date:2009/01/12(月) 13:23:25  ID: Be:
    >956
    言っとくけど、WebProgのPerlスレも違うからな 

959 デフォルトの名無しさん [sage] Date:2009/01/12(月) 17:48:21  ID: Be:
    >>956
    日本語わかる？ 

960 デフォルトの名無しさん [sage] Date:2009/01/12(月) 19:14:51  ID: Be:
    >>956
    スレチだが、完璧な解決方法を教えよう。
    有料ホームページを使え。



スレ立てるまでもない質問はここで 第94刷
577 デフォルトの名無しさん [sage] Date:2009/01/11(日) 21:20:05  ID: Be:
    ふと思ったんですが、MS　ヴィジュアルスタジオ(VS)の
    インテリセンス使うとき一覧の左に変な絵が出てくるじゃ
    ないですか（ピンクの箱ぶん投げマークとか）
    あれってメソッド・クラスとかあらわしてると思うんですが
    意味がでてる一覧表のHPありませんか？ 

578 デフォルトの名無しさん [sage] Date:2009/01/11(日) 21:27:27  ID: Be:
    割れユーザーか？
    製品版ならちゃんと説明あるだろ 

579 デフォルトの名無しさん [] Date:2009/01/11(日) 21:45:38  ID: Be:
    割れユーザー？違法コピーユーザーの意味ですね
    たぶん・・・
    エキスプレスエディションです

580 デフォルトの名無しさん [] Date:2009/01/11(日) 22:11:41  ID: Be:
    エクスプレスエディションってシベリア超特急と関係ある？ 

581 デフォルトの名無しさん [] Date:2009/01/11(日) 22:26:46  ID: Be:
    ねーよ　＾＾ノ



スレ立てるまでもない質問はここで 第94刷 
582 デフォルトの名無しさん [] Date:2009/01/11(日) 23:59:08  ID: Be:
    VB6で質問です。
    ローカル関数内で宣言したdictionaryやcollectionの変数って
    処理が関数から抜けた時点でメモリ領域開放される？
    明示的にnothing入れないと開放されない？

    Cのmallocの感覚だとfreeしないとヒープを食いつぶす気がして
    ならんのですが。

583 デフォルトの名無しさん [sage] Date:2009/01/12(月) 00:06:47  ID: Be:
    実際食いつぶされたの？ 

584 デフォルトの名無しさん [sage] Date:2009/01/12(月) 12:14:02  ID: Be:
    VBがそんなにプログラマに厳しいわけない

    よって大丈夫です　内部でよろしくしてくれます 

585 デフォルトの名無しさん [sage] Date:2009/01/12(月) 13:29:30  ID: Be:
    よろしくしてくれないこともままあるけどな。
    だからVB6は捨てろ。



Pythonについて（アンチ専用）
386 デフォルトの名無しさん [sage] Date:2008/12/24(水) 21:17:49  ID: Be:
    Python系でも後発Booとか見ると結構いい感じなんだよな
    defで匿名関数定義できてPythonのlambdaみたいな制限もねーし
    Lispのマクロみたいなノリでメタプログラミングっぽいことも出来るみてーだし

    後、Pythonは常にselfとか書かせるぐらいなら、束縛と代入で
    :=, =みたいに構文分けるかletとか書かせるようにして欲しかった
    ミスに弱いし、global文とかnonlocal文とか場当たり的で醜いよ 

387 デフォルトの名無しさん [sage] Date:2008/12/25(木) 19:58:12  ID: Be:
    そうだね 

388 デフォルトの名無しさん [sage] Date:2009/01/03(土) 22:49:50  ID: Be:
    Booは名前がなあ
    いくら中身が良くても名前だけでやる気が起こらないって恐ろしい

名前重要。ですか。

この会社辞めたくなった社長の一言 0x01
519 仕様書無しさん [sage] Date:2008/12/30(火) 04:41:54  ID: Be:
    void foobar(hoge)
    {
    double a;
    a=0/0;
    return;
    } 

520 仕様書無しさん [] Date:2008/12/30(火) 04:43:56  ID: Be:
    ありすめてぃっくえくせぷしょーん！！ 

536 仕様書無しさん [sage] Date:2009/01/02(金) 03:27:08  ID: Be:
    >>519
    NaNがどうかしましたか？ 

537 仕様書無しさん [sage] Date:2009/01/03(土) 05:27:07  ID: Be:
    NaNでもありません 

538 仕様書無しさん [sage] Date:2009/01/03(土) 15:35:56  ID: Be:
    NaNだ、ビックリしたNaN、もぅ～ 

539 仕様書無しさん [sage] Date:2009/01/05(月) 02:26:43  ID: Be:
    インド人は0を発明した上にNaNまで食う優れた人種 

540 仕様書無しさん [sage] Date:2009/01/05(月) 22:20:27  ID: Be:
    NaNだ、この流れは。 

541 仕様書無しさん [sage] Date:2009/01/05(月) 23:14:48  ID: Be:
    NaNぃか

■_

2009年01月11日

■_

・名著
Wataru's memo(2009-01-10) で、名著に出会うためには、長きにわたるたゆまぬ探索が必要です。そのほとんどは絶版となり書店に並んでおらず、インターネット上で言及されることもなく、静かに眠りについているからです。とか。自分が一冊だけ挙げるとしたら何があるだろうか。と考えたり考えなかったり。

なんか細々としたことで時間がなくなっていく。

■_ ではあらためて

昨日書けなかった高橋会長のアレに関して。確かに取り上げた冊数が尋常じゃなかったので、どうしても駆け足になってしまったという印象は否めないと思います。ただまあ少数に絞って掘り下げるという方向にしたときにたとえば BSマンガ夜話みたいにするとかどうとかと考えてみたり。んで、そういった印象はほっといて(えー)思いついたことや感じたことなど。

まず、ジュンク堂池袋店の2008年の年間売り上げ順位で、 15位に柴田望洋さんの「明解C言語入門編」(2004年8月刊行)があったのにびっくり。出来がどうとかいう話はおいといて(読んだことないし)、 4年前のCの入門書が年間売り上げ順位で上位に来ているという事実に驚きました月間では4月と7月に上位に入ってきたようです。あと、2008年5月期の10位に「新ANSIC言語辞典」が入ってました。この本、C99(とそれ以降)の内容って反映されてましたっけ? 2002年9月刊行ということらしいですがそれより前に買ってたような記憶が…改訂されたか?

それから、年間の10位に高橋麻奈さんの「やさしいJava第三版」がありました。 Cより上にあるということはそれなりに今の事情が反映されているんでしょうか。この本は4月の月間7位にも入ってました。Javaの入門書で言うと 7月の月間9位に「Javaの絵本」が。

「6月はRubyの月」

「ジェネリックプログラミング」を取り上げたときに話を振られた(乱入した?) artonさんの本に対する感想が良かったです (という表現はなんか変だがほかにいいのが思いつかない)。記憶とメモから再現すると「将来はこの手法(プログラム生成?三四文字くらいの単語で言ってたと思うのですがよく聞き取れなかった) がより広く使われるようになるだろう」「そしてこの本はこれまでと現時点での知見を集めたもの」「プログラマやってるお前らはこれ読んで将来を考えるべき」とかいう感じだったかと。実は出てすぐに買ったのだけど、積読のままです○|￣|＿

そうそう。掟本について「何々するな的なことはじつはあまり書きたくない」という趣旨の発言もありました。

ひらしょーさんの本が11,12月で月間1位。 Real World Haskellは山下伸夫さんが訳してるらしい。今秋? 実践Common Lispの著者は親子二代でLisper? 2008年は関数型言語の年でした。「コンピュータ書」は年間千点くらい刊行されている。などなど。

んで、歴史群像という雑誌があるんですがその前号(2008年11月発売)で「わが闘争」(ヒトラーのアレです)の新訳が上下巻で2009年1月6日に発売されるということが書いてあったので (→ http://opac.ndl.go.jp/articleid/9710840/jpn) 、ジュンク堂の売り場で訊いてみたんですが発売されてないし近刊予定にもないということ。変だなあと思って調べてみると、たしかに学研のサイトで検索しても引っかからないし、Amazonさんにもない。【予約】［完訳］わが闘争　第一巻　決着 [本]　セブンアンドワイヤフー店 - Yahoo!ショッピングオンライン書店ビーケーワン：完訳わが闘争第一巻決着のように「予約」を受け付けているところもあるにあるけどどうなってるんだろう? ドイツでは今でも発禁本扱いらしいけどまさか(ry

■_

タイトル通り。 Perlの能力を活かせばこんなに短く記述できますという的な話。

細かい解説文は原文をあたってもらうとして（えー


Why Perl Complex Code requires less lines | Mind Tree

第一段階レンズマン
while ($line = <STDIN>) {
    print $line;
}

第二段階
while (<STDIN>) {
    print $_;
}

第三段階
while (<STDIN>) {
    print;
}

第四段階
print <STDIN>;

第五段階
print <>;

んで、


When you consider that you can write a working implementation of cat in only eight 
characters, you can see why Perl is considered so powerful. But what if we want to do 
something more significant with the input rather than just echo it back to the screen?

Counting Line Numbers

If we want to process the lines of the input individually then it's not enough to 
just link the file handle to print, let's take a look at a simple program to add line 
numbers to the lines of input:

$num = 0;
while (<>) {
    $num = $num + 1;
    print "$num\t$_";
}

In this example we use the variable $num to keep track of the line number. For each 
line of input we increment this number, then print out the number and the line of 
input together. When we refer to variables inside strings with double quote characters 
(”) the variable name is replaced with the contents of that variable, this makes 
formatted output in Perl a breeze.

Even with these simple programs, it's easy to see how using special variables can 
make your programs smaller and faster to write. If you're interested, information 
about all of Perl's special variables can be found in the perlvar section of the Perl 
manual (http://perldoc.perl.org/perlvar.html).

Leave me a comment and let me hear your opinion. If you've got any thoughts, comments 
or suggestions for things we could add, leave a comment! Also please Subscribe to our 
RSS for latest tips, tricks and examples on cutting edge stuff.

      while(<>) {
      print "$.\t$_";
      }

      perl -pe '$_ = "$. $_"'



Why Perl Complex Code requires less lines : perl
#!/usr/bin/perl -p
s/^/$. /s;

■_

このところ、二回分とか三回分とかまとめてあがってるような気が。



Perl 6 Design Minutes for 31 December 2008 - Rakudo.org

Patrick:

    * 800 passing tests in the past few weeks help
    * things around the house here help
    * running into very few blockers
    * begrudging sleep too

Jerry:

    * ran across a couple of things in S19 development
    * Unicode
    * I'm no expert, being an American
    * there's the encoding of a file you're reading to execute
    * or something typed on the command line to execute via -e
    * then there's setting your standard filehandles for a specific encoding/charset
    * I'm not sure how to address those
    * am I instructing the parser with -e to be Unicode-aware?
    * is this something overall to Perl 6 programs?
    * the same goes for filehandles

Patrick:

    * the encoding specifies how the bytes translate into codepoints
    * the charset maps those to glyphs or graphemes
    * if I use ASCII, my charset only goes up to codepoints 127
    * I use a fixed 8-bit encoding
    * if I use Unicode, my codepoints go up high
    * I have a range of charsets to use
    * people tend to specify an encoding
    * it's ASCII, ISO-8859-1 (Latin-1), or UTF-8
    * most people mean UTF-8 when they say Unicode now
    * that's what web sites tend to use

Jerry:

    * Windows uses UCS-2
    * whether it's long or not, every character takes up that amount of space

Larry:

    * Perl 6 doesn't really care about the encoding
    * we just have to know what it is
    * as soon as things get into the language, everything has "Unicode semantics", whatever that means
    * we have to know how to get into that semantics
    * without metadata, we guess or throw up our hands in despair
    * it comes down to metadata

Jerry:

    * could that fit in a file, directly after a shebang?

Larry:

    * that's probably the least of our worries
    * the filename, the command line, the places where POSIX ought to be shot
    * the problem basically is that POSIX doesn't give you the metadata
    * very weakly, they pretend like locales are sufficient for that purpose

Jerry:

    * for my working draft, should I just say that Perl 6 is a POSIX girl living in a POSIX world?

Larry:

    * assume that you're in a UTF-8 world

Jerry:

    * as far as setting filehandle encodings, that's just pass to Perl 6, the program, and not a specific subcomponent?

Larry:

    * if it needs specification in the program, it's specified to open or as a pragma

Jerry:

    * suppose I'm outputting a text file from the command line
    * I want to tell Parrot that I want a UTF-8 or ASCII encoding

Larry:

    * I don't think you'll go wrong in the future if you assume everything goes into UTF-8, or some BOM-marked UTF-16 or -32
    * let the other people define themselves as departures from that default

Patrick:

    * I agree
    * UTF-8 is well known and capable enough for most things
    * do everything as deltas from that

Larry:

    * this is our chance to do everything right
    * let's not choose the wrong default

Jerry:

    * I'd like to allow intermixed options and values on the command line
    * we can't say perl foo.pl -w

辺りが印象に残った部分。エンコーディング問題は解決を見ることができるのだろうか。しかしこの回の議事録なげー。



Perl 6 Design Minutes for 17 December 2008 - Rakudo.org

Patrick:

    * I don't think it'll slow us down from the people primarily working on it
    * it'll happen around the same time as the move anyway
    * ideally the Rakudo stuff should move before Parrot does

c:

    * I'd like to see instructions on downloading, making local changes, and submitting a patch

Patrick:

    * post-January we could take a week of no features
    * just documentation
    * we need to explain how to get Parrot and such as well

Nicholas:

    * productivity is a concern
    * the Perl 5 conversion has shown that
    * minimizing downtime is important to aim for as well

Jerry:

    * it would be nice to have a champion who isn't Patrick

Patrick:

    * I might be able to find one of the "Git is the second coming" people on the channel to do that

c:

    * I thought it was the first coming

Jerry:

    * that's Obama

c:

    * no, they branch him and commit their own hopes and dreams to him using Git

Patrick:

    * I'll look into that

Nicholas:

    * don't forget the perl.org DNS
    * it's reasonable to have an A record rakudo.git.perl.org
    * you can clone that, but the source can move
    * you decouple the name from the repository

Patrick:

    * now might be the right time to do this
    * because Rakudo is starting to be useful to write useful things
    * I planned to post to Rakudo.org and other places
    * it might be interesting to solve some of the problems from Microsoft's scripting games
    * no one's done Perl 6 solutions for those yet
    * good idea/bad idea/landmines?

Jerry:

    * the consequences will be that people report bugs and make Rakudo better

Patrick:

    * bug reports are highly useful
    * they tend to drive our development better than anything else
    * I hope that people will solve those problems but not run into showstoppers
    * we may be close to that level
    * do I have to worry about any IP concerns?

こっちの回はあまり技術方面の話はなかった?

■_

といいつつあんまり最近Haskellでプログラム書いてないけど。 - 未定
でも言語として好きなのはやはりHaskellとPython。この二つは自分にとってはなんというかしっくりくる。
プログラミング言語としてHaskellを考えるなら抽象化という観点から考えるべき - 未定
型推論の意義について定期的に書きたくなる理由を考えた結果、自分がHaskellに感じる魅力と世間で喧伝されている魅力にずれがあるからだという結論に達した
「Haskellは型推論ができる。型を宣言しなくてもいいから楽でいい」だって？ - 未定
型推論は型を抽象化するためのものだ！Java、C#とかは型推論を名乗るな！
とはいいつつもモナドの理論的背景はわかってなかったりする - 未定
Haskellのモナドが理解できない人が多いのは、型宣言や型クラス等に関する説明が少ないから - 未定
掛け算の理解には足し算の理解が必要。それと同じようにモナドの理解にはまず型宣言や型クラス等の理解が必要。それを簡単に済ませて各種モナドに関する説明をするから理解できない人が多いのですよ。
Haskellが利用されない理由の一つは型宣言や型クラス等に関する説明が少ないこと - 未定
Haskellできちんとしたプログラムを書くには、型宣言や型クラス等に関するきちんとした理解が必要。
Haskellの型宣言や型クラスの実用的な使い方 - 未定
前に書いていたもの。型宣言や型クラスについては日本の書籍できちんと書いたものがないので、独断と偏見で書いておく（←間違っていたときの予防線）。

ほぼ日刊イトイ新聞 - 社長に学べ！
Seamless sequence output in Python 3.0
Hexenkessel - 187 ：呑んべぇさん：2007/06/23(土) 16:12:59...
Hexenkessel - ここで注意すべきは、「15歳から24歳まで」という年齢は就学年齢と相当程度重なるということです。日本で...
ZSFA -- 2009-01-08
ZSFA -- 2009-01-09
N-BASICがあるから今日の僕がある -のら犬兄弟のギョーカイ時事放談！-
Wadler's Blog: Well-typed programs can't be blamed
Haijin Boys Online
error: ‘long long long' is ...
Reading is Writing(2009-01-09)
トラックボールの欠点は、たまに来る友人がマクロスファンだと、必ず「あーん間に合わない～」と言って転がすところだろ。
そのこと自体はうなずけるけどどれだけの人が元ネタがわかるのかとw
sodiumイオンにっき(2009-01-10)
むしろ/bin/shがbashなほうが気持ち悪い
sodiumイオンにっき(2009-01-10)
あとPerlスクリプトを「perl」とか言ってしまうのもかなり気持ち悪いな。「perl」はPerlと言う言語の処理系の1実装(他の実装はしらんけど)で、プログラムの名称なんで、「perlをubuntuに持っていった」っていったら「perlをubuntuに移植してみた」という意味だと思ってしまうわけで。
舵取りを間違えるとカード会社がつぶれる可能性だってある - 脇見運転
Bigloo 3.2a Released - PLNews: Programming Language News
Bigloo 3.2a has been released. Bigloo aims to be a practical Scheme implementation.
LDC 0.9 Released - PLNews: Programming Language News
LDC 0.9 has been released. It is a D compiler that uses the Digital Mars D frontend and LLVM as the backend.
Scala 2.7.3 RC2 Released - PLNews: Programming Language News
SWI-Prolog 5.7.4 Released - PLNews: Programming Language News
This release includes: internal code reorganization, performance improvements, better detection and reporting of undefined predicates, bug fixes, documentation updates, and other changes.
Twitter / Ikegami Daisuke: F# しらないので en.Wikipedia っ ...
Twitter / Ikegami Daisuke: Beautiful Code は Chap. 24 ...
LOTUS NOTES 開発の件 -OKWave

なんか論点がかみ合ってない。あとで書く。かどうかは例によって(ry

■_ 本日のム板から

スレを勃てるまでもないC/C++の質問はここで 6 
25 デフォルトの名無しさん [sage] Date:2009/01/10(土) 18:01:46  ID: Be:
    stdio.h は standard ioの略ですよね
    そういった省略前のものが載ってる書籍、或いはサイトってありませんか？ 

26 デフォルトの名無しさん [sage] Date:2009/01/10(土) 18:22:31  ID: Be:
    略語には違いないけど、あまり気にするものじゃないと思うが・・・

    Solarisならこういうのがあるよ
    http://docs.sun.com/app/docs/doc/816-5173/6mbb8adq6?a=expand

29 デフォルトの名無しさん [sage] Date:2009/01/10(土) 21:18:58  ID: Be:
    関数のデフォルト値って宣言のところに書いておかないと駄目なの？
    定義のところに書いて使おうとすると。「関数に 1 個の引数を指定できません」
    ってエラーが出てきてコンパイルできません。
    いつも宣言ではfunc(int,int)みたいな感じで書いてるから変数書かないといけないの不便に感じる 

34 デフォルトの名無しさん [sage] Date:2009/01/11(日) 09:57:35  ID: Be:
    >>29
    定義の方に書いたって、他のコンパイル単位には伝わらない。
    だからこそ宣言を別ファイルにしてるわけで。 

35 デフォルトの名無しさん [sage] Date:2009/01/11(日) 11:07:23  ID: Be:
    >>34
    それは、「関数呼び出しの仕組み」がある程度わかっている人にはわかるけど
    初心者はそこまで考えが回らないのよ。
    デフォルト引数の仕組みが「呼び出し側で不足する引数を補うものだ」とね。

    つまり、わからないから
    呼び出される側で「引数がない時には補う処理」をしている、と思いがちなわけ。
    なにしろデフォルト引数を含む関数は呼び出される側だから。

    そういう発想を持っているということを前提にすると
    >>34の内容では意図が伝わらないし理解が深まるわけでもないのよ。 

36 デフォルトの名無しさん [sage] Date:2009/01/11(日) 11:15:48  ID: Be:
    あ、そうそう。

    >>29
    宣言で
    void func(int, int = 100);
    と宣言できるよ。


ぐち0x1B ～最も働いている現場の人間から解雇～ 
8 仕様書無しさん [] Date:2009/01/04(日) 17:58:26  ID: Be:
    「正月休みってもう終っちゃったのかなあ」
    「馬鹿、まだ始まってもいねーよ」

あ、これマ板だった。


【C++】STL（Standard Template Library）相談室 10 
988 987 [sage] Date:2009/01/10(土) 21:01:05  ID: Be:
    あ、でもlistじゃなくてmapなら要素の削除も簡単なのか
    スレ汚し失礼、もう一度じっくり考えてみます 

989 デフォルトの名無しさん [sage] Date:2009/01/10(土) 23:34:57  ID: Be:
    >>988
    「簡単」とか言うの禁止。
    ビッグOとかで語れ。 

990 デフォルトの名無しさん [sage] Date:2009/01/10(土) 23:40:42  ID: Be:
    アークション！

ビッグオー ?



【Perl,PHP】LLバトルロワイヤル3【Ruby,Python】 
392 デフォルトの名無しさん [] Date:2009/01/10(土) 18:10:58  ID: Be:
    phpの変数作るときに$を付けるのがめんどくさく、javascriptのようにi=1みたいにできる
    言語を探してます
    そこでrubyとpythonを視野に入れてるのですがどちらがおすすめでしょうか？
    基本的にはwebプログラムを好んでます 

393 デフォルトの名無しさん [sage] Date:2009/01/10(土) 18:24:54  ID: Be:
    好み別れる二択だな。試してみたかい？
    書法の趣味で選んで問題ないと思うよ。

    レン鯖とか考えてるなら対応してるサーバがphpに比べて少ないから、
    その辺から先に調べた方がいいかな 

394 デフォルトの名無しさん [sage] Date:2009/01/10(土) 18:36:34  ID: Be:
    &t;>392
    言語や実装が安定していて、言語要素がシンプルだけど十分に強力で、世界でも
    Perl以上に使われているPython。

    言語や実装は、「こっちの方が良いな」と思ったらコロコロ変えてしまう代わりに、
    強力かつ気持ちの良い言語で、世界ではPythonほど使われていないけど日本では
    Pythonより情報が豊富なRuby。

    どちらを使うかは自分で決めな。 

395 デフォルトの名無しさん [sage] Date:2009/01/10(土) 19:49:54  ID: Be:
    Rubyも変な接頭辞いるじゃん 

399 デフォルトの名無しさん [sage] Date:2009/01/10(土) 22:17:00  ID: Be:
    世界中でpythonが使われてるのにはそれなりの意味があると思うのでpythonがいいかも 

402 デフォルトの名無しさん [sage] Date:2009/01/10(土) 23:27:51  ID: Be:
    >>399
    このスレにふさわしい詭弁ｗ 

403 デフォルトの名無しさん [sage] Date:2009/01/11(日) 01:00:49  ID: Be:
    日本でpythonに軸足移しちゃった企業って、軒並潰れてない?? 

404 デフォルトの名無しさん [sage] Date:2009/01/11(日) 01:03:42  ID: Be:
    pythonに軸足移しちゃった企業ってどれとどれだよ 

405 デフォルトの名無しさん [sage] Date:2009/01/11(日) 01:04:15  ID: Be:
    そりゃ、LLは軸足を移すような物じゃないから……。

    PHPに軸足
    Perlに軸足
    VB.netに軸足
    HSPに軸足
    どれも大差なく頭悪く聞こえますよ。

    Javaに軸足、も頭悪く聞こえるけど、なんかビジネス的なワークフローが出来上がっちゃってるから
    商業的に頭悪いかどうかは判別できないかもしれない

    あったら怖いのは
    今からCOBOLに軸足を移す企業 

406 デフォルトの名無しさん [sage] Date:2009/01/11(日) 04:07:55  ID: Be:
    Pythonには self. という接頭辞があるじゃないか


C++相談室 part65 
293 デフォルトの名無しさん [sage] Date:2009/01/09(金) 00:00:58  ID: Be:
    BCC5.5でテンプレートを使った参照除去をやりたいんですが、通りません。
   あきらめるしかないのか？
    template<typename T>
    struct remove_refference{
    　　typedef T type;
    };
    template<typename T>
    struct remove_refference<T&>{
    　　typedef T type;
    };

295 デフォルトの名無しさん [sage] Date:2009/01/09(金) 00:11:27  ID: Be:
    BCC5.5みたいなウンコンパイラを未だに使っている時点でアウト 

296 デフォルトの名無しさん [sage] Date:2009/01/09(金) 00:12:51  ID: Be:
    >>293
    BCC6.1.0なら通る
    コンパイラが古い 

297 デフォルトの名無しさん [sage] Date:2009/01/09(金) 00:24:44  ID: Be:
    g++でいいのに
    Windowsで開発してる時点で負け組 

298 デフォルトの名無しさん [sage] Date:2009/01/09(金) 00:31:48  ID: Be:
    g++も古いバージョンはテンプレート悲惨だっただろ 

301 デフォルトの名無しさん [sage] Date:2009/01/09(金) 01:00:29  ID: Be:
    g++はC++0x対応が遅そうなのが気がかり 

302 デフォルトの名無しさん [sage] Date:2009/01/09(金) 01:16:35  ID: Be:
    VC++切り捨てVC#のみサポートとかいう時代がきて大差なくなったり 

303 デフォルトの名無しさん [sage] Date:2009/01/09(金) 02:08:37  ID: Be:
    ネイティブを切り捨てるわけが無い 

304 デフォルトの名無しさん [sage] Date:2009/01/09(金) 02:27:21  ID: Be:
    >>296 6.1.0ってタダだっけ・・・？ 

305 デフォルトの名無しさん [sage] Date:2009/01/09(金) 02:34:25  ID: Be:
    >>304
    違うにきまってんだろカス 

326 うどん [sage] Date:2009/01/11(日) 08:49:54  ID: Be:
    こんにちは、最近Ｃ言語と言うものに興味をもって始めようと考えていたのですが

    「苦しんで覚えるＣ言語」というサイトを参照したところ始めるにあたって

    「Borland C++ Compiler」という物が必要らしく　使うには登録も

    必要だったので登録しました。しかしＤＬ画面から何度試みてもＤＬできなくて

    始める前からいきなりの壁にぶつかっていますorz

    どなたか解決方法が分かる方がいましたら　教えて頂けないでしょうか？

    スレのお題からは離れている気もしますが宜しくお願いしますm（_ _）m 

331 デフォルトの名無しさん [sage] Date:2009/01/11(日) 11:17:26  ID: Be:
    >>326
    そんなダメサイトなんか見るからだよ。 

332 デフォルトの名無しさん [sage] Date:2009/01/11(日) 13:10:45  ID: Be:
    >>326
    Cは楽しんで覚えるべきだと思うお。 

333 271 [sage] Date:2009/01/11(日) 17:07:20  ID: Be:
    初心者にBC++勧めるのはどうなのかね。
    とりあえずVC++の無料版使って、本腰入れてアプリとか作るようになったら有料版にするのが
    一番お手軽かね。興味あったらググッて調べなさい >326

    個人的にはKNOPPIXでgcc使うのが勉強になりそうな気もするけど。 

335 デフォルトの名無しさん [sage] Date:2009/01/11(日) 17:35:18  ID: Be:
    VCから入るとほかで使えない人になっちゃうのがそれなりにいるからあんまり勧めたくない。