ときどきの雑記帖ぴゅあ

09 Feb ' 09:47

2012年02月09日

モーニング買うの忘れていたw

絶望的な全館購入特典がようやく

今日買った本に著者からのこんなメッセージが。

■_ I

メールで書き込み主に教えてもらいました。長年(おおげさ)の疑問がついにっ

くだすれFORTRAN（超初心者用）その5 [chaika]

818 デフォルトの名無しさん [sage] 2012/02/08(水) 19:16:27.77 ID: Be:
    FORTRANで整数変数の暗黙宣言がI～Nになっていることの根拠を知りたいと
    いう人がいた気がするが、まだ解決していないなら朕がその謎を解いてやろう。

    John Backus 本人がそのものずばりを質疑で答えている。　
    ちなみに質問は会場の爆笑を誘っているｗ
    J.A.N. Lee. Transcript of question and answer session: "The History of Fortran I, II, and III".
    In in: R. Wexelblat, editor. History of Programming Languages, ACM Monograph Series, Academic Press, 1981, pages 68-71.

    http://www.softwarepreservation.org/projects/FORTRAN/paper/p68-lee.pdf

    LEE: Helen Gigley asks: "Why were the letters I through N chosen to designate integers?"
    [Laughter and applause]

    BACKUS: Well, it just seemed for a while that people always used I, J, and K for subscripts,
    and we thought we'd be generous and add a few more.

    ようするに適当ｗ　
    まぁ数学では記法としてΣ_i^Nとかが一般的で、添え字にO以降は使われないから、
    I～Nまでを整数とするのは適切な気がする。 

819 デフォルトの名無しさん [sage] 2012/02/08(水) 19:19:26.81 ID: Be:
    ついでに言うと、伝説と異なりFORTRAN I で配列のRankが3以下に制限されたのは
    インデックス・レジスタが３個しかないせいではないとも言明している。

配列の次元の上限は以外だった。確かに示されているリンク先にあるPDFの中身をみると、はじめ三次元、後に七次元になったことについてのコメントがあった。

いや実にすっきりしました。ゆっくり眠れます :)

■_ redditに訊け

Python プログラマーなんですが Ruby を始めたいのですけどなにかよい資料などは

I am a python programmer who needs to learn ruby. Any good resources or advice? : ruby

The languages are often compared so I am hoping my knowledge of python will make learning ruby
faster. Maybe the best method is just to read a ruby book and learn from scratch, I am not
sure yet how similar they are. However if anyone has made the switch and knows what a good
starting point would be or if there are resrouces geared toward switching I would apperciate
the advice. Thanks.

Edit: I will be using ruby as a scripting language. Mosly maintaing and updating existing
scripts that put together XML files used for input for other applications and things like
file management and such. So if there are resrouces geared towards scripting rather than
building ruby applications that would be helpful.


Ruby Koans


I can't say enough nice things about the koans approach. It's a really great way to learn all
the gotchas in a language. It shows you how things are done in a idiomatic way. And it's fun.


Here's a comparison of the languages, from a great Python programmer: 
http://groups.google.com/group/comp.lang.python/msg/28422d707512283?pli=1

Also, here's the learn ruby from other languages page: 
http://www.ruby-lang.org/en/documentation/ruby-from-other-languages/


Thanks!

ジュンク堂書店　新宿店　店舗情報
Takuya Oikawa - Google+ - 聴きに行きたかったBj Rollison氏の「How We Test At Microsoft…
１４歳の、アメリカに行ってエンジニアリングを学びたい少年へ
これはPHPです。
編集者の日々の泡:講談社「スティーブ・ジョブズ」、100万部出て「まさかの赤字」。背景は米国の……
Who won the 20th IOCCC
Advent Calendar電子版の提供開始！第一弾は「HTML5 Advent Calendar 2011」！ | Gihyo Digital Publishing
ハッカーの流儀
クリアなコードの作り方: 縦長・横長なメソッドを短くする - ククログ(2012-02-07)
Byteman - JBoss CommunityByteman allows you to insert extra Java code into your application, either as it is loaded during JVM startup or even after it has already started running.
100人のプロが選んだソフトウェア開発の名著君のために選んだ1冊 , Rubyのfor式の失敗 - Journal InTime(2012-02-09)しかし実は、Rubyのfor式はたんなる構文糖よりも少し罪が重い。

Permalink | View Entire Page

08 Feb ' 10:43

2012年02月08日
O'Reilly Media - Tech Books, DRM-Free Ebooks, Videos なんか2冊買うと1冊無料でついてくるって話らしいんですが、欲しいなあってのが Upcoming - O'Reilly Media の辺りにしかなかったりして。ラクダ本マダー?
Upcoming - O'Reilly Media

Programming Perl, 4th Edition
By Tom Christiansen, brian d foy, Larry Wall, Jon Orwant
February 2012 (est.)
Ebook: $39.99
Pre-Order Print: $49.99
↓この辺も早く
Upcoming - O'Reilly Media

Code Simplicity
By Max Kanat-Alexander
February 2012 (est.)
Pre-Order Print: $24.99
Upcoming - O'Reilly Media

Think Complexity
By Allen B. Downey
March 2012 (est.)
Pre-Order Print: $29.99
おや、こんなのが。 Free as in Freedom [Paperback] - O'Reilly Media 確か自分が持っているのはハードカバーだったような (ろくに読んでなかったりする :)。
■_ The History of Rubinius

前後のページとの関連がよくわからない(^^:
Razzle Dazzle | 1: Origin Story | The History of Rubinius

The History of Rubinius
As Told by Its Creator
by Evan Phoenix

During the winter of 2006, I got interested in the implementation of the Smalltalk language.
Following discussion with Ryan Davis about Ruby and Smalltalk, I decided to order the Blue
Book from Powell's Books online. The Blue Book is the holy bible of Smalltalk, containing
not only a complete introduction to the language, but also a sample implementation of the
language itself in the last few chapters. The intention of these chapters was to provide
the interested reader some details into how Smalltalk works at the lowest level, so they
could use the language well. To my eyes though, it was like opening the face of a watch to
see the gears turning. It was amazing, and proved to be the initial spark of life for
Rubinius.

(以下略)
幸いまだこの辺で苦しんだことはない。たぶｎ
getaddrinfo() edge case behavior on Windows, Linux and OS X – klickverbot.at by David Nadlinger

getaddrinfo() edge case behavior on Windows, Linux and OS X

(略)

Host 	Port 	Flags 	Windows 	Linux 	OS X
null 	null 	- 	NONAME 	NONAME 	NONAME
  	AI_PASSIVE 	NONAME 	NONAME 	NONAME
  	"" 	- 	loopback 	loopback 	NONAME
  	AI_PASSIVE 	catchall 	catchall 	NONAME
  	"0" 	- 	loopback 	loopback 	loopback
  	AI_PASSIVE 	catchall 	catchall 	catchall
  	"80" 	- 	loopback 	loopback 	loopback
  	AI_PASSIVE 	catchall 	catchall 	catchall
"" 	null 	- 	public 	NONAME 	NONAME
  	AI_PASSIVE 	public 	NONAME 	NONAME
  	"" 	- 	public 	NONAME 	NONAME
  	AI_PASSIVE 	public 	NONAME 	NONAME
  	"0" 	- 	public 	NONAME 	loopback
  	AI_PASSIVE 	public 	NONAME 	catchall
  	"80" 	- 	public 	NONAME 	loopback
  	AI_PASSIVE 	public 	NONAME 	catchall
"localhost" 	null 	- 	loopback 	loopback (v4) 	loopback
  	AI_PASSIVE 	loopback 	loopback (v4) 	loopback
  	"" 	- 	loopback 	loopback (v4) 	loopback
  	AI_PASSIVE 	loopback 	loopback (v4) 	loopback
  	"0" 	- 	loopback 	loopback (v4) 	loopback
  	AI_PASSIVE 	loopback 	loopback (v4) 	loopback
  	"80" 	- 	loopback 	loopback (v4) 	loopback
  	AI_PASSIVE 	loopback 	loopback (v4) 	loopback
hostname 	null 	- 	public 	loopback (v4) 	public
  	AI_PASSIVE 	public 	loopback (v4) 	public
  	"" 	- 	public 	loopback (v4) 	public
  	AI_PASSIVE 	public 	loopback (v4) 	public
  	"0" 	- 	public 	loopback (v4) 	public
  	AI_PASSIVE 	public 	loopback (v4) 	public
  	"80" 	- 	public 	loopback (v4) 	public
  	AI_PASSIVE 	public 	loopback (v4) 	public

getaddrinfo() behavior on Windows Server 2008 R2, Arch Linux (Kernel 3.1.4, glibc 2.14.1), and OS X 10.7.2 (Lion).
reddit で500overの反応があった記事
Dear Boss: For a programmer, 10 minutes = 3 hours - edw519


Dear Boss: For a programmer, 10 minutes = 3 hours

10:48

Boss: Hey Ed, Sue in Detroit says that sometimes, the wrong Invoice Part Number is showing
      up on the Product History Screen. Can you help us figure this out.

Ed: I'm busy with something else at the moment. Put the ticket in my queue.

Boss: This will only take 10 minutes.

Ed: Are you sure about that?

Boss: Yes. I'll just set up a web conference. Sue can show you right away, then you can
      look into it when you have time.

Ed: OK.

Boss: Great. Check your Outlook for an invite.

(略)

1:48

Boss: OK, this sounds like a problem. It looks like I'll have to escalate this to the
      Steering Committee. I'm glad you had 10 minutes to spare. Thanks.

(Ed continues to read Hacker News in another tab.)
ちゃんちゃん。詳しい顛末は元記事をどうぞ
Dear Boss: For a programmer, 10 minutes = 3 hours : programming

Crucially, when the boss first says "This will only take 10 minutes", he 
means 10 minutes of his time, not yours
"This is just a simple feature to add in; we're only changing 3 fields. Shouldn't 
take more than 30 minutes."

... and running items on a 3rd party database with no API provided, changing the data 
that is being sent, and turning that into 3 service calls instead of 1, to "speed 
things up a bit".

2 hours later: "Why isn't this done yet?! Don't bill for more than 30 minutes; I 
already told the client that's how long it would take."
My running joke at work when someone asks how long it would take to get a minor change done.

    1 minute to make the change
    1 hour to test
    1 day to get it into QC
    1 week to get someone to sign off on UAT
    1 month to get someone to sign off on PROD

An exaggeration that isn't too far off from reality.
■_ こーどれびゅー

こういうのは全文きっちりやったのほうが良いのかな
ShipSolid - Software Consulting
You Need a Code Review (あなたにはコードレビューが必要だ)

Alex Bartlow 

2012-02-05 
 
On many of my projects, I have the pleasure of working with a team of highly skilled 
developers and designers to deliver a working, finished application. Many of these 
developers are shocked when I often ask for code reviews, or use a pull-request on 
github to deliver a feature, instead of just pushing it into master. It seems that I'm 
regarded as a senior developer, that should be above such formalities that prevent 
junior developers from making a build-breaking change, and as such, I should resent 
the idea of someone else auditing my changes. 
 
I don't resent it. I need it. I need a code review, on every significant commit. 
Code Reviews Create Quality

Code Reviews Prevent Mistakes

Code Reviews Transfer Knowledge

Code Reviews Teach
■_ 温故知新

Simula - Wikipedia INTRODUCTION TO SIMULA Cim for Windows An Introduction to Programming in Simula

なんか動く処理系があるっぽいのでやってみようかという気になりつつある
Twitter / @y_shindoh: grep vs. Awk: http://t.co/ ...Hena Hena Nikki ～悔い倒れの日々～(2012-02-08)
Twitter / @y_shindoh: grep vs. Awk: http://t.co/ ...

grep vs. Awk: quruli.ivory.ne.jp/diary/?date=20… 「GNU grepよりGNU Awkの方が速い!」
という噂を聞いて試してみた。 ちなみに、この結果と正反対の結果が手元のGnuWin32環境では出
たので、環境によってかなり違うと見た方が良さそうだ。
バージョンによって正規表現ライブラリが入れ替わったり(grep)、インタープリターがバイトコード形式になったり(gawk)でその辺の条件を明確にしないと同じ比較ができないような。
■_ 百万の

Clang: Defending C++ from Murphy's Million Monkeys | GoingNative 2012 | Channel 9 Clang: Defending C++ from Murphy's Million Monkeys : programming Murphy's とあるのは何か深い意味があるんだろうかそれはともかく、音声のみのダウンロードもできるっぽいのでそれを聴いてみよう。初日のキーノートやらも含めると聴くための時間がとんでもなくかかるけど。
Clang: Defending C++ from Murphy's Million Monkeys | GoingNative 2012 | Channel 9

Were we to craft a Lenox Globe of programming languages, C++ might be followed by a famous
cautionary phrase: Here Be Dragons. The language can be complex and daunting to programmers
who are often shouldered with the task of writing large, complex programs. Those millions of
code monkeys need help to resist Murphy's siren song and navigate C++'s treacherous waters
of memory corruption and concurrency bugs.

(略)
code monkey と Murphy's siren song やらからでてきたのかな＞百万匹の猿

初日のキーノート。 Day 1 Keynote - Bjarne Stroustrup: C++11 Style | GoingNative 2012 | Channel 9
Day 1 Keynote - Bjarne Stroustrup: C++11 Style | GoingNative 2012 | Channel 9

We know how to write bad code: litter our programs with casts, macros, pointers, naked new
and deletes, and complicated control structures. Alternatively (or additionally), we could
obscure every design decision in a mess of deeply nested abstractions using the latest
object-oriented programming and generic programming tricks. Then, for good measure, we
might complicate our algorithms with interesting special cases. Such code is
incomprehensible, unmaintainable, usually inefficient, and not uncommon.

わたしたちはひどいコード (bad code) の書き方を知っています。
自分たちのプログラムを、キャストやマクロ、ポインター、素の new や delete、それに
複雑な制御構造であふれさせること。です。
■_

アメリカに行ってエンジニアリングを学びたい中学生 - Togetter

某アメリカに行きたい中学生を見て - blog.sorah.jp

結婚しよう！に@を返したら結婚する事になった - 酢ろぐ(ch3cooh.jp)

国内の開発者が使っている言語、1位C、2位VB、3位Java。アジャイル開発は2割が採用、半数以上がウォーターフォール。IDC調べ－ Publickey

地政学を英国で学んだ : 創造性を上げるには「孤独」になれ

Pythonのsplat演算子 - brainstorm

朝日新聞デジタル：ＩＴ漬けが会社をダメに。「断食」を

Apple’s great GPL purge | mathew

Effective Scala

Rust 言語のモジュールシステム - uasi:ウアシー

ビル・ゲイツ：オープンソース・ソフトを変えた男（その1）[ #cbajp ] | CBA – Cloud News Japan

Linux Daily Topics：2012年2月8日　理由は"ビジネスにつながらないから" ─Canonical，Kubuntuのサポート停止へ｜gihyo.jp … 技術評論社

セマンティックウェブ・ダイアリー : これでPAIPによるLisp入門を終わります

What is the meaning of life?

返却後も使い続けられるレンタルCDの特異性：IT's my business：ITmedia オルタナティブ・ブログ

Reference in Perl - Linux Stall

Permalink | View Entire Page

07 Feb ' 11:10
2012年02月07日

昨年大晦日に手に入れられなかったアイツが委託されたので COMIC　ZIN　通信販売/商品詳細インフラエンジニア双六買ってきました。いけね。証拠写真撮ってないw

■_ 配列(リスト)の添字

PowerShell でリストスライスを取り出そうと $ary[5..-1] として予想外の動作をしてびびる。

Ruby、Python もこれとそれぞれ違って混乱したり。どれがいい、他はだめということではないのだけど悩みの種ではある (複数使うほうが悪い?)

PS > $ary="a b cd e f g".split(" ") PS > $ary a b c d e f g PS > $ary[0..7] a b c d e f g PS > $ary[4..7] e f g PS > $ary[-4..-1] d e f g PS > $ary[4..-1] e d c b a g

減少方向もいけるのね。

PS > 4..-1 4 3 2 1 0 -1 PS > -4..-1 -4 -3 -2 -1

■_ "Programmer" is an Overgeneralization

一般化されすぎということ? ＞ Overgeneralization

Erik McClure: "Programmer" is an Overgeneralization February 5, 2012 "Programmer" is an Overgeneralization "Beware of bugs in the above code; I have only proved it correct, not tried it." - Donald Knuth Earlier today, I came across a post during a google-fu session that claimed that no one should use the C++ standard library function make_heap, because almost nobody uses it correctly. I immediately started mentally ranting about how utterly ridiculous this claim is, because anyone whose gone to a basic algorithm class would know how to properly use make_heap. Then I started thinking about all the programmers who don't know what a heap is, and furthermore probably don't even need to know. 今日わたしは、それを正しく使える人がほとんどいないのだから C++ の標準ライブラリ関数にある make_heap は誰も使うべきではないという主張を google-fu session の間に post しました。 basic algorithm class を理解しているような人であれば make_heap の適切な使い方を知っているでしょうから、わたしは即座にこの主張がまったくばかげているものであることを mentally ranting しました。それからわたしは、ヒープがなんであるかも知らず、それが何のためにあるのかすらも知らないであろうプログラマーすべてについて考えはじめました。 Then I realized that both of these groups are still called programmers. そうして、プログラマーにはそういった二つのグループがあるのだということを認識するにいたりました。

Copyright ©2011 Erik McClure. Powered by Blogger.

Four Levels of Idea Theft Four Levels of Idea Theft アイデアの剽窃の4レベル Imagine you've just seen a tremendously exciting piece of software--a mobile app, a web app, a game--and your immediate reaction is "Why didn't I think of that?!" With your mind full of new possibilities, you start on a project, a project enabled by exposure to the exciting software. What happens next is up to you. How far do you let your newfound motivation take you?

Borrowing specific features. General inspiration. Using the existing product as a template. Wholesale borrowing of the design.

Appleで人材の流出相次ぐ - 今度はiPhone/iPodエンジニアリング担当VPら | パソコン | マイナビニュース

帽子の色あてパズルを Alloy で解く - PB memo

Coding Horror: Farewell Stack Exchange

Amazon.co.jp： SciPy and NumPy: Eli Bressert: 洋書

やっと理解できた！JSオブジェクト指向プログラミング再入門 | ゆっくりと…

アジャイルが失敗する本当の理由 - 神様なんて信じない僕らのために

Rが使えるフリをするための1冊の本「R言語逆引きハンドブック」を読んだ - あらびき日記

IOCCC 入賞！ - inaniwa3の日記

はじめてのにき(2012-02-07) IOCCC

セマンティックウェブ・ダイアリー : Lisp で作る Scheme

wrong, rogue and log : 近況: 第三子誕生

らいおんの隠れ家 : Ｂ美のコンピュータ本案内　第２回　「アジャイルサムライ　－達人開発者への道－」 - livedoor Blog（ブログ）

ジョジョ超像可動「第二部ワムウ」可動フィギュアが4月発売 :おた☆スケ

Firefoxダークマター、残り部分の解明進む | エンタープライズ | マイナビニュース

Colorful Pieces of Game::ハドソンがファミコンに参入するまで（３）
2012年02月06日

Amazon さんから Kindle touch 買わない? と販促メールが

■_

続編。 code examples ということでそういう話でした。

Why I love Common Lisp and hate Java, part II – code examples « Piece of mine Why I love Common Lisp and hate Java, part II – code examples Writing programs that write programs.This is a sequel to my previous post where I urged those who gave up on programming — probably because of the spoon-fed association with Java and stress — to give coding another chance with a whole “new” (read: different) approach: Common Lisp. The purpose of this sequel is to address the open-minded skeptic, unconvinced yet unafraid of paradigm-shifting change. Common Lisp is not just another language, it is a different way of coding. While I tried to make a point that the REPL completely alters the experience of coding — which can only be experienced and not by reading a blog post — this time I will try to showcase Common Lisp's powerful meta-programming through some example code. Writing programs to write programs is mind-boggling if you come from the imperative world of Java. Simply because it is not possible in Java, therefore not taught, hence not even considered as a powerful way of abstraction and code reduction. We write methods and functions to abstract away reoccurring computational patterns. Why not write functions that take the abstraction level even higher and abstract away coding patterns? (以下略)

■_

NSApplication プログラムの作成 XO: 再：CarbonかCocoaか？

Cocoa での hello, world 的プログラムってどんなんだろうと疑問に思いつつちと調べた。 Windows、昔の Mac OS のように自分でディスパッチするのではないのね。 X のメッセージはどう処理してたっけ?

■_

見やすいコード表記について | タコブネ開発者ブログ

10年前から（愛ちゃんよりも、）四元派: ごみため(ー日ー膳！)

関数合成のススメ～オブジェクト指向プログラマへ捧げる関数型言語への導入その1 - ゆろよろ日記

関数適用のススメ～オブジェクト指向プログラマへ捧げる関数型言語への導入その2 - ゆろよろ日記

COMIC　ZIN　通信販売/商品詳細インフラエンジニア双六

OSC2012 Tokyo/Springでしゃべることになりました | オープンソース・ライセンスの談話室

卜部昌平のあまりreblogしないtumblr - 「来年度からプログラムを書く仕事をすることになってしまった不幸なおまえらの道標となるべき書籍十冊」みたいなエントリは読むな。職業プログラマに山形浩生みたいな完膚なきまでの英語理解は不要ですのでその点はご安心いただきたいですけれども、かといってあなたがもし何を学んでよいか分からないほど五里霧中なのであれば、まず必要なのは知識そのものではなくて知識を得るためのツール、つまり言語ですよ。

完膚なきまで:日本語はおもしろい

調査 : 開発者が最も使用している言語、「C」と「Visual Basic」がツートップ……IDC調べ | RBB TODAY (エンタープライズ、ソフトウェア・サービスのニュース)

日経プレスリリース

Why, oh WHY, do those #?@! nutheads use vi?

Haskell「そう、ぼくはApplicativeを手に取った。」 - 技術欲男

こうして Scala プログラマが増えてゆくのです - Togetter

開発に必要な力は二つしかない - 神様なんて信じない僕らのために

見やすいコードのために出来るたった一つのこと - 日々常々

■_

仕込みの時間が欲しい…
Permalink | View Entire Page

05 Feb ' 12:38

2012年02月05日

■_

文庫化
結構いろいろな本が文庫化されてたようです。ハードカバーでは…という人もどうでしょうか
アレやらアレは文庫化されるんだろか。

昨日買った本やら

■_

Amazon.co.jp：貧乏人の経済学: 貧困削減をもういちど根っこから考える: エスター・デュフロ, アビジット・バナジー, 山形浩生: 本
新領域：なぜ感染で死ぬのか？「利他的死による感染防御」の検証
関数合成のススメ～オブジェクト指向プログラマへ捧げる関数型言語への導入その1 - ゆろよろ日記
The Little Book on CoffeeScript
アセンブリ言語でフィボナッチ数 - sileの日記
デバッグする人にやさしいコードはあるけれど - カレーなる辛口Javaな転職日記
開発チームと品質保証チームの反目と、解決への道 - 虎塚
2012年に流行するプログラミング言語: ニュースの社会科学的な裏側
Rが使えるフリをするための14の知識: ニュースの社会科学的な裏側
Monadの利点？ - Yahoo!知恵袋
Rが使えるフリをするための14の知識: ニュースの社会科学的な裏側
Rの特色だが、C言語やJavaの静的スコープと異なり、Perlのような辞書的スコープが用いられる。
「辞書的スコープ」って初めて見たような気がするんですが、どこかに使用例ありますか?
#110 OOPとF# - 継承やインターフェイスなんていらんかったんや « F# « C# « Gab_kmのブログ
Rubyist Magazine - 0037 号巻頭言
そもそも「たのしさ」というのは指標たりうるのだろうか。
Long Tail World: 津波後シリコンバレーで起業する日本人が増加：Post-tsunami, Japanese techies flock to Silicon Valley for startups
コンビニの店長が見た本屋の陳列 - G.A.W.
本を手にとりたくなる売場の演出について - Togetter
コンピュータに支配される日 | OKWave
文房具一新するんだが、アドバイス頼む

■_ 翻訳むずい

大英帝国海軍の戦艦あたりの命名規則はなかなか理解しがたいものが (彼らにしてみれば、日本海軍の駆逐艦なんかはなんじゃそらだろうなあ)

ジャック・キャンベル ～彷徨える艦隊～ 2番艦c

623 名無しは無慈悲な夜の女王 [sage] 2012/01/09(月) 02:28:08.28 ID: Be:
    ７巻表紙の女性は誰？
    デシャーニ大佐だよね？
    副題がドレッドノートだからジェーン・ギアリー大佐？ 

624 名無しは無慈悲な夜の女王 [sage] 2012/01/11(水) 13:22:58.35 ID: Be:
    ドーントレス以外だと作中の活躍とリンクしてない名前だよね
    ヴィクトリアスってなんかやったっけ 

625 名無しは無慈悲な夜の女王 [] 2012/01/12(木) 15:39:15.58 ID: Be:
    日尼見ると、8巻のハードカバーとペーパーバックが同じ月に出ることになってるがおかしいな。

    翻訳の質はともかく、刊行中のシリーズに追いつきピッタリマークしてるなんてなかなかないな。 

626 名無しは無慈悲な夜の女王 [sage] 2012/01/12(木) 19:23:27.12 ID: Be:
    >>624
    戦艦の名前じゃなくてただの形容詞 

627 名無しは無慈悲な夜の女王 [sage] 2012/01/13(金) 01:36:41.43 ID: Be:
    >>626
    何が形容詞だって？

    彷徨える艦隊　旗艦ドーントレス
    彷徨える艦隊　２　特務戦隊フュリアス
    彷徨える艦隊　３　巡航戦艦カレイジャス
    彷徨える艦隊　４　巡航戦艦ヴァリアント
    彷徨える艦隊　５　戦艦リレントレス
    彷徨える艦隊　６　巡航戦艦ヴィクトリアス
    彷徨える艦隊　７　戦艦ドレッドノート

628 名無しは無慈悲な夜の女王 [sage] 2012/01/13(金) 01:59:52.75 ID: Be:
    帰還によって初期の目標を達成し勝利を得たではないか。
    艦名とその意味を掛けてるんじゃない？と思うのだが。

    1.Dauntless　　不屈の
    2.Furious　　　　怒り狂った
    3.Courageous　勇敢な
    4.Valiant　　　　 雄々しい
    5.Relentless　　冷酷な
    6.Victorious　　勝利を得た
    7.Dreadnought 恐れ知らず 

629 名無しは無慈悲な夜の女王 [sage] 2012/01/13(金) 03:26:47.16 ID: Be:
    >>628
    いや、そうじゃなくて >>626 は、
    >戦艦の名前じゃなくてただの形容詞
    と言った 

630 626 [sage] 2012/01/13(金) 04:16:59.38 ID: Be:
    形容詞だろ
    戦艦の名前とかけてるけどそれ自体はただの形容詞だろ 

631 名無しは無慈悲な夜の女王 [sage] 2012/01/13(金) 06:18:27.32 ID: Be:
    >>627
    原書のサブタイには「旗艦」だの「特務戦隊」だの「戦艦」だのといった単語は付いてません
    日本語版のタイトル付けた奴のチョンボ 

632 名無しは無慈悲な夜の女王 [sage] 2012/01/13(金) 08:35:51.55 ID: Be:
    「戦艦の名前とかけてる」のはみな理解してる。
    >>624 がいってるのは、
    「ドーントレス以外だと作中の活躍とリンクしてない」

    活躍じゃないけど撃沈されたのはあったと思う。

635 名無しは無慈悲な夜の女王 [sage] 2012/01/13(金) 22:33:50.60 ID: Be:
    まぁ軍艦の名前ってのは最重要な要素だと思うが、
    本の内容と関わってるのはその意味の方だ罠
    原書は読んだことないので俺には分からんけど、艦名の冠にH.M.Sみたいなのが付いてたら
    副題はもう純粋に形容詞だがｗ 

636 名無しは無慈悲な夜の女王 [sage] 2012/01/13(金) 22:37:30.20 ID: Be:
    書き込んでから気付いたが、theが付いてないから形容詞の方が主か 

637 名無しは無慈悲な夜の女王 [sage] 2012/01/14(土) 00:42:41.95 ID: Be:
    >>628
    故郷への生還で始まり凱旋で終わる第６巻に「Victorious」とつけるあたり、
    作中での艦の活躍よりは「形容詞」重視っぽいね。 

638 名無しは無慈悲な夜の女王 [] 2012/01/14(土) 05:37:30.61 ID: Be:
    普通にストーリー上のタイトルロールの艦と形容詞的用法上のダブルミーニングを狙ってるんだろ。
    タイトルロールの艦の活躍がちょびっとorほぼ見当たらない巻もあるし、
    それほど各巻ごとに大きな変化があるストーリーでもないけど。

    さて、これから巻名になりそうな艦名を拾ってみると
    Vengeance　復讐
    Vanguard　前衛
    Revenge　復讐
    Triumph　勝利

    次点で
    Majestic　堂々とした
    Brilliant　光り輝く

    こりゃなんじゃ？
    Intemperate　不摂生な

642 名無しは無慈悲な夜の女王 [] 2012/01/14(土) 13:29:57.81 ID: Be:
    >638
    やり過ぎ、の方が良いかも。
    呑んだくれって意味の方も捨てがたいがｗ

    異星人の脅威が明らかになると
    Redoubtable　恐るべき
    とか

    最終巻は
    Glorious　栄光ある
    だろうなぁ 

781 名無しは無慈悲な夜の女王 [] 2012/02/01(水) 13:11:25.95 ID: Be:
    ついでに

    艦隊が与えた損害をギアリーが見積もらなければならないが、今の時点では大虐殺としかいいようがない。

    now he had to figure out how much damage they had done. All he could tell at the moment was that the damage hadn't been the massacre it might have been.

    翻訳の無免許運転としか言いようがない。 

782 名無しは無慈悲な夜の女王 [] 2012/02/01(水) 13:44:58.81 ID: Be:
    逆だね。 

789 772 [sage] 2012/02/01(水) 17:02:38.63 ID: Be:
    >>781
    そこも「？」と思ったところだった。
    大した損害がないのに“大虐殺”とはこれ如何にと・・・

    >>778兄，>>779兄のおかげでスッキリしたよ。 

790 777 [sage] 2012/02/01(水) 20:36:13.73 ID: Be:
    やっぱり誤訳かよ！
    チェック体制とかどうなってんだ……返金ものだろ…… 

791 名無しは無慈悲な夜の女王 [] 2012/02/01(水) 20:54:33.96 ID: Be:
    景気悪い
    　->出版社: 経費節減
    　　->翻訳のチェック無し(翻訳者まかせ)
    　　　翻訳料も下げ
    　　　->翻訳者: 見直し最低限(細かいことやっとれん、出版社でやれよ)
    　　　　下訳料金も下げ(or 翻訳ソフトでもいいか)
    　　　　->下訳者: 雑でもいいな(金に見合うし)、
    　　　　　ついでに間違いも入れといたろ

    まさか、こんなじゃないだろうな...

■_ Sorting algorithms used in the CL implementations

Sorting algorithms used in the CL implementations « Jorge Tavares weblog

Sorting algorithms used in the CL implementations

(略)

What sorting algorithms do the major open source CL implementations actually implement?
I was curious about it and went to check the source for ABCL, CCL, CLISP, CMUCL, ECL and
SBCL. Not surprising, we find some differences between the implementations. What it was
more unexpected to discover is that some implementations also use different sorting
algorithms according to the sequence type. A quick survey of the findings is summarized
in the following table (if anythings is incorrect, please tell me). The links for the
source code are in the implementation name (careful, in CCL and SBCL there are two links).

Implementation 	sort 	stable-sort
ABCL 	merge sort (lists) / quicksort 	merge sort
CCL 	merge sort (lists) / quicksort 	merge sort
CLISP 	tree sort 	tree sort
CMUCL 	heapsort 	merge sort
ECL 	merge sort (lists) / quicksort 	quicksort (strings + bit vectors) / merge sort
SBCL 	merge sort (lists) / heapsort 	merge sort

 
In terms of the implementation of sort, quicksort is the most used algorithm, followed by
heapsort. The choice for these algorithms is expected. Both have an average-case
performance of O(nlgn) and heapsort guarantees a worst-case performace of O(nlgn) too.
Quicksort has a worst-case performance of O(n2) but it can be optimized in several ways
so that it also gives an expected worst-case performance of O(nlgn). However, it seems
that the quicksort implementations are not completely optimized. In ECL (and ABCL)
quicksort implements a partition scheme which deals better with duplicate elements
(although is not the three-way partitioning) but it always picks as pivot the first
element. CCL chooses the pivot with a median-of-3 method and always sorts the smaller
partition to ensure a worst-case stack depth of O(lgn).

(略)

使われている度合いではクイックソートが一番というのはともかく、続いてヒープソートってのは意外な気が。

わたなべさんのところから辿った元記事。 Re: テキストファイルをソートするときに頻繁に使うUnixコマンド - jarp, → [O] テキストファイルをソートするときに頻繁に使うUnixコマンドで、 sort するときは LC_ALL=C sort を使わないと、環境によって結果が変わってしまう場合があるし、一定量以上のファイルをsortする際には、sort処理自体の速度もLC_ALL=Cありの方が速いです。 locale が C でない場合に処理速度ががた落ちになってしまうというのはおいといて (ありゃあ実装が以下略なところもあるような気がしないでもない。といってきちんとしたコードを書くのも大変だろうなあ)、 sort するのに collating order 無視というのはどうなんだろうねえ。まあ、基本的に文字コード順で不自由ないんだろうけど。

LC_ALL. LANG, LC_COLLATE その他の役割(とか影響範囲)ってあまり理解されてない? いやまあメッセージ出力のエンコーディングがどうこうはわかってるんだろうけど。

■_

600近くのコメントが → Dear Boss: For a programmer, 10 minutes = 3 hours : programming

■_

紀伊国屋書店新宿南店の洋書売り場も模様替えやらなんやらでCSの棚がだいぶ寂しく…

Permalink | View Entire Page

04 Feb ' 16:07

2012年02月04日

GoingNative 2012 | Channel 9

codermetrics 洋書のスペースがさらに狭くなったジュンク堂で発見。去年の8月に出ているもの (Codermetrics - O'Reilly Media) だったのか。今までぜんぜんアンテナに引っかかってこなかったw 家に帰って確かめるまで、ずっと「codemetrics」と思い込んでました。こんなサイトも → Codermetrics.org

んで、裏表紙にはこういう一文が Codermetrics is the Moneyball for software teams. Who would have thought that sports and software development had so much in common? The book is purposeful and thought-provoking -- a great read for any software team participant.

容量が4GBってのだけでもいいなあ Kindle Touch WiFi モデルが日本からも購入可能に、139ドル -- Engadget Japanese

■_ チャート

これは自分も疑問に思ったことがあるんですが、なんでなんでしょうね。

スレ立てるまでもない質問はここで 116匹目

868 デフォルトの名無しさん [sage] 2012/02/04(土) 09:01:26.61 ID: Be:
    何で日本はチャートの事をグラフって教えるんだろうか。 

869 デフォルトの名無しさん [sage] 2012/02/04(土) 09:02:46.27 ID: Be:
    図のことをフィギュアとは言わないなあ。 

870 デフォルトの名無しさん [sage] 2012/02/04(土) 09:41:08.80 ID: Be:
    マならチャートとフィギュアを使うのは当然だよな。
    グラフなんて言ったら紛らわしいし。

■_ 丸投げ

C言語での桁落ちの以下のプログラムを教えてください | OKWave

C言語での桁落ちの以下のプログラムを教えてください

C言語の本の問題で答えが書いてなく困っております。


f(x)=xの5乗-ルート（1+xの10乗)+1/{2×ルート（1+xの１０乗）}の式が与えられ

ｘ＝0,1,2・・・50 における f(x) の値を求める場合のプログラムを教えてください。

注＊＊そのまま計算した場合と式を変形して正確に計算した場合を比較せよ（一つのプログラムで両方計算）．


何が分からないと?

補足

C言語での桁落ち：：：　f(x)=xの5乗-ルート（1+xの10乗)+1/{2×ルート（1+xの１０乗）}の式
が与えられていてｘ＝0,1,2・・・50 における f(x)のプログラムです。

丸投げっぷりは脇に置いといて、R は↓こーゆーことができるので好き :)

> fx <- function(x){x**5 - sqrt(1+x**10) + 1/(2*sqrt(1+x**10))}
> fx(1:50)
 [1] -6.066017e-02 -3.810975e-06 -8.711305e-09 -1.164152e-10 -4.150059e-12 -4.044512e-13 -7.689121e-13
 [8] -7.105427e-15  2.710343e-12  5.583029e-12  1.370892e-11  1.197672e-12  1.113648e-11 -2.059970e-11
[15] -8.846262e-12 -2.168404e-19  1.082057e-10  1.151358e-10 -1.664620e-10 -2.121925e-10 -4.295505e-11
[22]  1.614090e-10  3.840912e-10  3.947581e-10  9.085810e-10 -7.581706e-10 -5.443981e-10 -7.500674e-10
[29] -1.700046e-09 -1.775610e-09 -1.161735e-09 -6.617445e-24 -2.125002e-09  3.554049e-09  2.069262e-09
[36]  8.185052e-10  7.210434e-09  6.310329e-09  5.541751e-09  4.882813e-09  4.315695e-09  3.825811e-09
[43]  3.401165e-09  3.031842e-09  2.709614e-09  2.427621e-09  2.180122e-09  1.962293e-09  1.770067e-09
[50]  1.600000e-09
> gx <- function(x){1/(2*sqrt(1+x**10))-sqrt(1+x**10)+x**5}
> gx(1:50)
 [1] -6.066017e-02 -3.810975e-06 -8.711311e-09 -1.164153e-10 -4.092726e-12  0.000000e+00  0.000000e+00
 [8]  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00
[15]  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00
[22]  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00
[29]  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00
[36]  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00
[43]  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00
[50]  0.000000e+00
> (function(x){1/(2*sqrt(1+x**10)) - sqrt(1+x**10) + x**5})(1:20)
 [1] -6.066017e-02 -3.810975e-06 -8.711311e-09 -1.164153e-10 -4.092726e-12  0.000000e+00  0.000000e+00
 [8]  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00
[15]  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00

式を変形して正確な値を求めるというのはこういうことですよね。三つ目のはお遊び :)

■_ 生産性が十倍ならば

As a software development manager I have seen productivity vary up to 10x between developers, should pay also vary up to 10x depending on productivity? : programming が結構な伸び。

その話題の元

10x Productivity Myths: Where's the 10x Difference in Compensation? - 10x Software Development

10x Productivity Myths: Where's the 10x Difference in Compensation?

In response to my recent blog post on the research support for 10x productivity differences
among programmers, Pete McBreen made the following comment:

"One point in his article that McConnell did not address--programmer compensation
does not vary accordingly. This is a telling point--if the difference is productivity
can be 10X, why is it that salaries rarely fall outside the 2X range for experienced
developers?" [emphasis in original]

This is a good question. It's timely because the Software Engineering Productivity group
on LinkedIn has recently had a 130-comment discussion on the question of “Should pay be
tied directly to productivity?” It's also a question that I wrestled with personally for
about the first 10 years of my career. Indeed, it's part of the original reason I decided
to became self employed back in 1989 and eventually founded my own company in 1996.

The Intuitive Version of the Question

I started my personal “10x compensation quest” from the point of view of, “I know
I'm 3-5x as productive as the guy sitting next to me. Why am I not making 3-5x as much
money?” Over a period of many years I found that this formulation of the question
embodied several assumptions that were naïve or just plain wrong from a business
perspective.

Six Myths of 10x Compensation

Let's look at each of these myths of 10x compensation.

Myth 1. The guy next to me is getting paid what he's worth.
略
Published Jan 22 2011, 05:42 PM by Steve McConnell

■_ 問題

t1: Expressing integers using four nines :: Strangely Consistent

3 Feb, 2012
by Moritz Lenz

t1: Expressing integers using four nines

(This is a guest post by Moritz Lenz. If you're wondering what this is all about, it's 
the aftermath of The 2011 Perl 6 Coding Contest. If you're not wondering, it's still 
about that.)

Let's consider the first task from the Perl 6 Coding Contest 2011.

Here is the description of the task once more:

What non-negative integers can you write as expressions containing exactly four occurrences
the number 9, and any of the binary operators *, /, %, +, -, prefix negations, and any
number of matching pairs of parentheses you care to use?

9 が四つと二項演算子 *, /, %, +, -、前置の negation、任意個のカッコ対を使った
式として記述できる非負の整数
#よくわからん

The program should accept an upper limit N as a command-line argument. It should then print
all integers 0..N in increasing order, along with an expression with four nines, if any
such was found.

この問題はコマンドライン引数として上限値 N を受理すべきである。
0 から N までのすべての4つの9で表現できる整数を昇順に出力する。
#でいいのかな

It was probably the easiest of all tasks, and the one we got the most submissions for. Yet
there were still some things that could go wrong, and some submissions got some of them wrong:

    non-negative implies that we start at 0 = 9 + 9 - 9 - 9, not at 1
    1 からではなく 0 から開始

    integers means that the result must be an integer; it does not mean that intermediate
    results are automatically rounded or truncated
    結果は整数でなければならない。中間結果は自動的に丸められたり切りめられたりしない

    the expressions must consist of four times the number 9, not the digit nine. Thus 99
    is not a valid expression of two nines.

    式では数字の 9 ではなく、数値の9 を4つ含んだものでなければならない。
    したがって 99 は二つの9を使った vaild な式ではない


略

Amazon.co.jp：インターフェースZERO (ゼロ) No.1 2012年 03月号 [雑誌]: 本
インターフェースZEROとは｜インターフェースZERO
SciPy and NumPy - O'Reilly Media
Firefoxのextensions内確認コマンド | OKWave
Jun Mukai's blog: 電子書籍強化月間のまとめ
「絶対便利じゃないですか」――本の内容まとめて公開「ブクペ」の狙いと“著作権” (1/3) - ITmedia ニュース
転身・未経験からのテスト業務 — ありえるえりあ
技術の継続性：世の中の流行を追っていては30年続かない－スーパーコンピュータ「京」開発者インタビューで思ったこと: 組み込み技術者の単身赴任日記
2012-02-01 - 大島芳樹のカリフォルニア日記
JavaScript equlity tests (==) among confusing values
Clojureの名前空間の複数のファイルへの分割 - Yoshito Komatsu's Blog
Success is a Journey, not a Destination: Red-Black Tree の balance 処理の最適化 (をしても速くならない・・・)
Success is a Journey, not a Destination: LeftistHeap in Haskell
英文履歴書のススメ、或いは@taromatsumuraさんのLinkedIn本 - umitanuki日記
2.6との後方互換性を保つための4種のTips - None is None is None
Bit Of Cheese: Another small sampler to finish the weekBeautifulSoup for Python 3!
仕事流儀で紹介されたGoogleのハッカーは誰？ | OKWave
vallog: 熊本市の慶徳校前にあるトルタコスで恵方ブリトー食べてきた
どうやら毎週のように週末このトルタコスというお店でプログラミング談義が行われているらしい。
ScalaっぽいパターンマッチをRubyで実装する - 継続にっき(2012-02-04)
パターンマッチは時々欲しくなるのでRuby 3.0あたりで言語仕様に取り込まれないかなぁと思うんだけど、あまりパターンマッチについて議論されているところを見た記憶がない。

しかし池袋のジュンク堂、CS関連の洋書の棚をあそこまで削るとは… ○|￣|＿紀伊國屋書店も以前よりは面積減ってるしなあ。どうすべえ。

2012年02月03日

カッコの対応をリアルタイムに強調表示やらしてくれるエディターってどれが最初?

■_ ××戦略

例によって日本語版と英語版とでだいぶ違う

評価戦略 - Wikipedia

値渡し

値渡し（Call-by-Value）評価は、C言語からSchemeまで多くの言語で採用されている典型的な評
価戦略である。値渡しでは、引数の式を評価し、結果として得られた値で関数内の対応する変数
を束縛する（通常、捕獲回避置換か新たなメモリ領域への値のコピーをする）。その関数が引数
となっている変数に値を代入しても、それは局所的なコピーへの代入であり、呼び出した側から
見れば、その関数に渡したものは何も変化していない。

値渡しは一種類ではなく、関数に渡す前に引数を評価する戦略全般を指す。多くの言語（Eiffel 
や Java）は値渡しの際に引数と左から右の順序で評価するが、中には右から左の順序で評価す
る場合もあり、言語によっては（Scheme、OCaml、C）順序を明示していない。

評価戦略 - Wikipedia

参照渡し

参照渡し（Call-by-Reference）評価とは、関数に対して引数の値そのものではなく、引数の参
照を暗黙のうちに渡すことをいう。その関数が引数を変更すると、呼び出し側からもその変化が
観測できる。引数の式が左辺値であれば、そのアドレスが使われる。そうでない場合、呼び出し
側で一時的オブジェクトを構築し、そのオブジェクトへの参照が渡される。そのオブジェクトは
関数から復帰した際に捨てられる。

言語によっては、参照を第一級オブジェクトとしている。例えば、MLには "ref" コ
ンストラクタがある。C++でも参照は明示的に生成できる。これらの言語では、関数の引数とし
て値への参照を渡すことを参照渡しと呼ぶこともある。

C言語のようにポインタを持つ言語では、参照渡しではなく「アドレス渡し（Call-by-Address）」
と呼ぶこともある。

最後の一文、Cに call by reference があると読めるような気がしないでもないんですが。

こっちが英語版。訳はいいっすよね?w

Evaluation strategy - Wikipedia, the free encyclopedia

Call by value

Call-by-value evaluation (also referred to as pass-by-value) is the most common evaluation
strategy, used in languages as different as C and Scheme. In call-by-value, the argument
expression is evaluated, and the resulting value is bound to the corresponding variable in
the function (frequently by copying the value into a new memory region). If the function or
procedure is able to assign values to its parameters, only its local copy is assigned — that
is, anything passed into a function call is unchanged in the caller's scope when the
function returns.

Call-by-value is not a single evaluation strategy, but rather the family of evaluation 
strategies in which a function's argument is evaluated before being passed to the function.
While many programming languages (such as Eiffel and Java) that use call-by-value evaluate
function arguments left-to-right, some evaluate functions and their arguments right-to-left,
and others (such as Scheme, OCaml and C) leave the order unspecified (though they generally
require implementations to be consistent).

In some cases, the term "call-by-value" is problematic, as the value which is passed
is not the value of the variable as understood by the ordinary meaning of value, but an
implementation-specific reference to the value. The description "call-by-value where
the value is a reference" is common (but should not be understood as being
call-by-reference); another term is call-by-sharing. Thus the behaviour of call-by-value
Java or Visual Basic and call-by-value C or Pascal are significantly different: in C or
Pascal, calling a function with a large structure as an argument will cause the entire
structure to be copied, potentially causing serious performance degradation, and mutations
to the structure are invisible to the caller. However, in Java or Visual Basic only the
reference to the structure is copied, which is fast, and mutations to the structure are
visible to the caller.

最後のパラグラフによく議論になるアレに関係することが書かれてますね

Evaluation strategy - Wikipedia, the free encyclopedia

Call by reference

In call-by-reference evaluation (also referred to as pass-by-reference), a function 
receives an implicit reference to a variable used as argument, rather than a copy of its
value. This typically means that the function can modify (i.e. assign to) the variable
used as argument- something that will be seen by its caller. Call-by-reference therefore
has the advantage of greater time- and space-efficiency when the argument is a large
datatype (since arguments do not need to be copied), as well as the potential for greater
communication between a function and its caller (since the function can return
information using its by-reference arguments), but the disadvantage that a function must
often take special steps to "protect" values it wishes to pass to other functions.

Many languages support call-by-reference in some form or another, but comparatively few use
it as a default; Perl and Visual Basic are two that do, though Visual Basic also offers a
special syntax for call-by-value parameters. A few languages, such as C++, PHP, and
REALbasic, default to call-by-value, but offer special syntax for
call-by-reference parameters. C++ additionally offers call-by-reference-to-const. In purely
functional languages there is typically no semantic difference between the two strategies
(since their data structures are immutable, so there is no possibility for a function to
modify any of its arguments), so they are typically described as call-by-value even though
implementations frequently use call-by-reference internally for the efficiency benefits.

Even among languages that don't exactly support call-by-reference, many, including C and ML,
support explicit references (objects that refer to other objects), such as pointers (objects
representing the memory addresses of other objects), and these can be used to effect or
simulate call-by-reference (but with the complication that a function's caller must
explicitly generate the reference to supply as an argument).

そして日本語版にはないこれ。

Evaluation strategy - Wikipedia, the free encyclopedia

Call by sharing

Also known as "call by object" or "call by object-sharing" is an evaluation
strategy first named by Barbara Liskov et al. for the language CLU in 1974.[1] It is used by
languages such as Python,[2] Iota, Java (for object references),[3] Ruby, Scheme, OCaml,
AppleScript, and many other languages. However, the term "call by sharing" is not
in common use; the terminology is inconsistent across different sources. For example, in
the Java community, they say that Java is pass-by-value, whereas in the Ruby community,
they say that Ruby is pass-by-reference[citation needed], even though the two languages
exhibit the same semantics. Call-by-sharing implies that values in the language are based
on objects rather than primitive types.

The semantics of call-by-sharing differ from call-by-reference in that assignments to 
function arguments within the function aren't visible to the caller (unlike by-reference
semantics)[citation needed], so e.g. if a variable was passed, it is not possible to
simulate an assignment on that variable in the caller's scope. However since the function
has access to the same object as the caller (no copy is made), mutations to those objects,
if the objects are mutable, within the function are visible to the caller, which may
appear to differ from call-by-value semantics. For immutable objects, there is no real
difference between call-by-sharing and call-by-value, except for the object identity.

Although this term has widespread usage in the Python community, identical semantics in
other languages such as Java and Visual Basic are often described as call-by-value, where
the value is implied to be a reference to the object.

こいつくらいは訳つけといたほうが良いのかしらん。

■_ 名前で呼んで

ついでに。これも英語版だと(ry

Evaluation strategy - Wikipedia, the free encyclopedia

Call by name

In call-by-name evaluation, the arguments to a function are not evaluated before the 
function is called — rather, they are substituted directly into the function body (using
capture-avoiding substitution) and then left to be evaluated whenever they appear in the
function. If an argument is not used in the function body, the argument is neverevaluated;
if it is used several times, it is re-evaluated each time it appears. (See Jensen's Device.)

(以下略)

Jensen's Device ってのがわからなかったのですが、リンクがあるので折角だから辿ってみる。

■_ Jensen's Device

Jensen's Device - Wikipedia, the free encyclopedia

Jensen's Device is a computer programming technique devised by Danish computer scientist
Jørn Jensen, who worked with Peter Naur at Regnecentralen, particularly on the GIER Algol
compiler, one of the earliest correct implementations of ALGOL 60.[1]

The following program was proposed to illustrate the technique. It computes the 100th 
harmonic number by the formula H_{100}=\sum_{i=1}^{100} \frac{1}{i}:

  begin
     integer i;
     real procedure sum (i, lo, hi, term);
        value lo, hi;
        integer i, lo, hi;
        real term;
        comment term is passed by-name, and so is i;
     begin
        real temp;
        temp := 0;
        for i := lo step 1 until hi do
           temp := temp + term;
        sum := temp
     end;
     comment note the correspondence between the mathematical notation and the call to sum;
     print (sum (i, 1, 100, 1/i))
  end
  
The above exploits call by name to produce the correct answer (5.187...). It depends on the
assumption that an expression passed as an actual parameter to a procedure would be
re-evaluated every time the corresponding formal parameter's value was required. Thus,
assignment of a value to i in the sum routine as a part of the for statement changes the
value of the original i variable, and when the code of the for loop requires the value of
term, the expression 1/i is evaluated and with the new value of i. If the last parameter to
sum had been passed by value, and assuming the initial value of i were 1, the result would
have been 100 × 1/1 = 100, though actually, it is not initialised.

So, the first parameter to sum, representing the "bound" variable of the summation,
must also be passed by name, otherwise it would not be possible to compute the values to be
added. On the other hand, the global variable does not have to use the same identifier, in
this case i, as the formal parameter.

ですから、summation で“束縛された”変数を表す sum の第一パラメーターは by name で渡されな
ければなりません。さもなければ加算のための値を計算することができないでしょう。
他方、大域変数では formal parameter と同じ識別子、この例では i を使ってはいけません。

Usage

The Sum function can be employed for arbitrary functions merely by employing the 
appropriate expressions. If a sum of integers were desired the expression would be 
just sum(i,1,100,i);, if a sum of squares of integers, then sum(i,1,100,i*i);, and so 
on. A slight variation would be suitable for initiating a numerical integration of an 
expression by a method very similar to that of sum. In the absence of this 
pass-by-name facility, it would be necessary to define functions embodying those 
expressions to be passed according to the protocols of the computer language, or to 
create a compendium function along with some arrangement to select the desired 
expression for each usage.

Because every mention of term within the procedure re-evaluates the original 
expression, making a local copy of the value of term as appropriate may be worthwhile, 
as when the procedure might compute the product of the terms as well as their sum.


Compatibility: The new language will have to talk with older languages. Types will 
have to be translated; memory models will need to be aligned and compilers will need 
to 'play nice' together. This is not just as the compiled object level but at the ABI 
level during linking etc. I've spent more time solving issues with memory models in 
C++ than I have in any other language because C++ has no ABI - I've had patches to 
MSVC change the memory layout of objects and cause breakage which is just as bad as 
you get with any sort of language interop scenario.

(略)
Let us think about the big ideas behind Go: [snip] Well, one can write simple clean 
C++ and use share_ptr. Just because C++ can be super complex does not mean it has to 
be. Unless, say, you're writing a DLL (another fun fact: not only can your API not 
have STL, exceptions also can't cross DLL boundaries), or you're using DLLs written by 
other poor souls who were consigned to writing DLLs with a C++ API.

This is not to say that C++ has no place in software development (I use it daily at 
work), but I'm of the opinion that unless you have a really good reason, avoid it like 
the plague. New languages taking over more niches C++ used to occupy is a good trend.

As a finishing note, one of my favorite articles on the subject of complexity in 
programming: http://www.joelonsoftware.com/items/2009/09/23.html

Permalink | View Entire Page

04 Feb ' 01:47

2012年02月02日

例の、Smalltalk 特集号の BYTE の記事をPDFにしたものが公開されているとかいう情報を知ってさっそくダウンロードしてみました。最初のところだけちょっと読んだのですが、APL という名前が登場していてちとびっくり。ってまあ名前が出てただけなんですけどね。他には Lisp とか FORTHとか。

■_ 比較

F# と Scala。 TechNeilogy: F# vs. Scala, My Take at Year Two

■_ C++11 は

競争相手を以下略

C++11 Makes Competitors Go Rusty | Nerds Central

C++11 Makes Competitors Go Rusty

Rust is breaking free, but does it have any real world value?

C++11 is out (has been for a while) and brings many things from Tr1 into the standard.
Things like managed memory (shared_ptr) and lambdas and template meta programming (TMP)
bring new paradigms to the beating heart of C++. So much so, I would argue, that C++11
makes some of the 'new kids on the block' (think Go and Rust) look pretty pointless.

少し前に C++11は正式なものとなり、Tr1 の多くの事柄が標準のものとなりました。
メモリー管理 (shared_ptr) やラムダのようなもの、それにテンプレートメタプログラミング
(template meta programming, TMP) は C++ の beating heart に新しいパラダイムを
持ち込みました。それはとても大きなものなので、
C++11 は 'new kids on the block' の一部 (think Go and Rust) を
ほとんど意味のないものにしてしまったとわたしは主張します。

'Go Rusty' as in go old, look old, corrode and otherwise become less good. This is
really just a play on words because both Google and Mozilla have been playing the 'new
object oriented native language' game recently. I can really see the motivation,
especially from organisations which want to create highly stable, performant,
cross-platform systems like browsers. The issue I see with both Go and Rust is that
they are solving yesterday's problems. C++/Tr1 has also solved many of the same
problems without needing a new compiler, for teams to learn a new language and
introducing all those compatibility issues with existing code.

So Boost and Tr1 are cool, but not part of the standard... Well, no longer, a large
proportion (if not all) of what Go and Rust are trying to do with a complete new
language C++ has done by adding to an existing one via the 2011 standard.

Boost や Tr1 は cool なものですが、標準のものではありません。

From Wikipedia:
"
Rust is an experimental, concurrent, multi-paradigm,compiled programming language
developed by Mozilla Labs.[1] It is designed to be practical, supporting pure-functional,
concurrent-actor,imperative-procedural, and object-oriented styles. The main developer is
Graydon Hoare, who began work on the system in 2006; Mozilla became involved in 2009.[2]
In 2010, work shifted from the initial compiler, written in OCaml, to the self-hosted
compiler written in Rust itself.[3] It successfully compiled itself the following
year.[4] The self-hosted compiler uses LLVM as its backend. Version 0.1 of the Rust
compiler was completed in January 2012.[5] Mozilla described it as an alpha release,
suitable for early adopters and language enthusiasts.
"

Go is a compiled, garbage-collected, concurrentprogramming language developed by
Google Inc.[6] The syntax of Go is broadly similar to that of C: blocks of code are
surrounded with curly braces; common control flow structures include for, switch, and
if. Unlike C, line-ending semicolons are optional; variable declarations are written
differently and are usually optional; type conversions must be made explicit; and new
go and select control keywords have been introduced to support concurrent programming.
New built-in types include maps, Unicode strings, array slices, and channels for
inter-thread communication.
"

I can totally get why people want to write new programming languages. Sometimes it
becomes very annoying dealing with some seemingly stupid, repetitious and just plain
awkward aspects of many main stream languages. However, I learned from Robert Sales
and Micro Focus that a much more productive solution to annoying syntax is to make the
compiler able to work out what you mean with better syntax and leave in the old syntax
as well. Why is this better? Here are some (but not all) the issues created by
introducing a new language into an existing echo-system (which all projects are these
days):

わたしはようやく、なぜ皆が新しいプログラミング言語を使いたがるのかを理解できました。

Massive but ineffective - lots of engineering does not make something worth while or
work well. Normally the reverse is the case!

Compatibility: The new language will have to talk with older languages. Types will
have to be translated; memory models will need to be aligned and compilers will need
to 'play nice' together. This is not just as the compiled object level but at the ABI
level during linking etc.

互換性:
新しい言語は古い言語と対話をしなければなりません、
型は変換されなければならないし、メモリーモデルをそろえる必要があって
コンパイラーは 'play nice' together しなければならないでしょう。
これはコンパイルされたオブジェクトのレベルの話ではなく、
リンクの際の ABI レベルでの話です。

Performance: This new language is super fast. Great, but it will have to work with
existing systems. The interface between the two will slow stuff down a lot. Either
that interface will have to be messy (see Compatibility above and/or JNI) or via a
marshalling system (Protocol Buffers, Avro etc). The problem with marshalling between
dissimilar systems is that it is really slow. It might seem like a good idea (just
like the steam gun right) but it is a stupidly expensive and complex way to solve a
problem of one's own invention. Such protocols are great for clustering, cloud
processing and client-server work; they are just wrong headed for gluing systems
together to work around using different languages in one system. Keep it simple.

性能:

Build: Build system complexity has been one of the biggest headaches in all the major
projects I have seen over the last few years. Build systems are getting more and more
complex as the demands of heterogeneous programming and dependency management push
technology beyond the sane. Frameworks like maven, msbuild and even good old make work
fine if a project uses one language; they generally degenerate into a big ball of mud
otherwise.

ビルド:

Debugging: Debugging across languages is really tricky. I should know, I have spent a
lot of time doing it over the last few years. For example, even debugging from COBOL
into Java and back on the same JVM is tricky because a Java debugger does not
understand COBOL and the same is the case in reverse. Jumping between native languages
can be even harder when their internal data structures, interpretations of
indirections (pointers etc) and (shudder) interpretations of thread state are
completely different.

デバッグ:

Team Training: Assembling a team of people who know one language well is hard enough;
doing so across multiple languages is extremely challenging. Some people will be
prepared to learn new stuff but not all will. Time pressure, as we all know and love
it now, generally does not leave time to learn a language up front in a project.

チームのトレーニング:

Team Embedded Knowledge: It is very hard to keep the knowledge of a multi-language
project spread throughout a team. It is even harder to keep that knowledge 'live' as
team members leave and join. Because language interoperation patterns are less well
known and less standardised that intraoperation patterns, unique embedded knowledge
tends to build up in teams.

Version Management (language/runtime): Different languages frequently have slightly
different life-cycles and dependency management issues. These accumulate to cause
challenges in revision control.

バージョン管理:
別々の言語はしばしば大きく異なるライフサイクルと dependency management を
持っています。

Tooling Costs: Good tooling can be expensive. Tools like profilers, code complexity
analysis systems and test coverage checkers can all be pretty costly to buy. Whilst
some have good open source alternatives, these have the embedded cost of maintenance
and installation. Again, multiple languages usually means that a team needs more tools
and hence more cost.

Licensing Of Runtimes And Libraries: We often get complacent thinking all libraries
and runtimes will be free. This in not the case. Even if they are 'free' as in they
cost no money, their licensing requirements might complicate commercial arrangements.
If they are commercial and have enforced licensing this introduces a whole new level
of complexity. One really nasty situation is when two completely different forms of
code hardening in the licensing systems do not play nicely together. I have seen it
happen and it is not pretty.

Lifespan And Sundown: All things come to an end. Support for a language or, more often,
a version of a language will come to an end. Managing these life cycle events can be
challenging in a single language environment. When more than one language enters the
picture, the cycles will almost certainly not coincide. The less common a language is,
the more likely that is will be sundowned whilst the products using it are still
current. It is fairly easy to get into a situation when one can never actually release
on a completely stable, current set of components.

Startup And Shut-down Sub-Systems: A programming language is just the code right? Wrong -
generally there is a lot more to it than that. It can be tricky even to mate up C with C++
projects because C++ has to initialize statically referenced objects before main is called.
Many other languages have even more complex issues to do with threading, signals and
loaders which all get in each other's way when building a mixed language system.

サブシステムのスタートアップとシャットダウン:

Paradigm Contamination: Seeing Java written in the in style of COBOL is quite an eye
opener. I am not a COBOL bigot either way; it is a solid language that is really good
for some things. Java is also a solid language, but it really should not be programmed
in the style of COBOL. However, where the two languages touch the chances are the
COBOL will look like Java and the Java look like COBOL. I have seen exactly the same
thing with C# and C. If a programmer is working in C and writing a bit of Java, the
chances are the Java will be C like. Equally, the natural paradigm of a cross language
API tends to be a hybrid of both languages. Whilst these things are to be expected,
they are horrid. The code looks bad, smells bad and is hard to test or maintain.

パラダイムの Contamination:
COBOL のスタイルで書かれたJavaを見ることはかなりの eye operner です。
I am not a COBOL bigot either way;
COBOL は soolid な言語で、一部の事柄に対してはとても優れた代物です。
Java もまた solid な言語ですが、COBOL スタイルでプログラムされるべきものではありません。

Brain Strain (the bilingual problem): Children which are brought up from babyhood as
bilingual usually learn to speak more slowly than their monoglot contemporaries. Can
the analogy be brought over to programming? In the absence of hard evidence from
psychologists, it seems at least likely and reasonable to assume that coding progress
will be slowed down by the extra cognitive burden of working in more than one language.

... and so on ...

So what am I saying?

I hope I have established that in modern environments, introducing new languages
carries with it a lot of down sides. To put it another way - there has to be an
overwhelming need before there is an overall benefit in introducing a new language
rather than using a well established general purpose language. Go and Rust are
compiled straight to native and so the existing candidate as an alternative is C++.
C++ has huge pre-existing libraries and is (with the possible exception of C) the most
likely language in which other native code will be written. Even if there is a large
legacy C library set, C++ to C is a well know interoperation with some issues from the
list above but not too bad.

So, is there an overwhelming need to replace C++ with Rust or Go?

I would definitely say NO! Simple paradigm following within the pantheon of C++ allows
this language to behave just as well as Rust or Go - or at least that is what I fully
expect.

Let us think about the big ideas behind Go: It is simple, clean and has garbage
collection. Well, one can write simple clean C++ and use share_ptr. Just because C++
can be super complex does not mean it has to be.

Let us think about the big ideas behind Rust: Type inference, static assertions
(checks), simple constant rules to facilitate reasoning about multi-threaded execution.
These are nice things indeed. However, using lambda's correctly along with other
templating techniques makes C++ straightforward for multi-threaded reasoning. Template
Meta Programming should be able to perform most of the type reasoning which the
compile time checks are performing in Rust. C++11 has type inference. It does not use
clever code branch analysis like Rust, but it is there (auto and decltype).

The ideas in Rust are definitely more tricky to implement in C++ than those in Go;
however, the effort required to do so is , IMHO, trivial compared to creating, using
and maintaining a new language. Further, the effort to replicate Rust's good features
in a C++ paradigm is much less than the effort of dealing with a new language (as
described above).

Rust におけるこのアイデアは C++ で実装するには Go よりも格段にトリッキーなものです。
しかし、わたしの見るところでは実装するのに要求される労力は
新しい言語を作って、それを使って、メンテナンスをすることに比べれば
たいしたことがないものです。
加えて、C++ のパラダイムで Rust の good features を replicate するための
労力は新しい言語を扱うための労力と大差ありません。

Here is a very trivial bit of C++ with which I was playing this morning:

// VSPL.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <boost/spirit/include/qi.hpp>
#include <iostream>
#include <iterator>
#include <algorithm>

namespace client
{
namespace qi = boost::spirit::qi;
namespace ascii = boost::spirit::ascii;
template <typename Iterator>
bool parse_numbers(Iterator first, Iterator last)
{
using qi::double_;
using qi::phrase_parse;
using ascii::space;

bool r = phrase_parse(
first,
last,
double_ >> *(',' >> double_),
space
);
return first == last;
}
}

int main()
{
typedef std::istream_iterator<int> in;
std::string code = "1,2,3,4,5,6";
std::cout << (client::parse_numbers(code.begin(), code.end())?"All is well":"It barfed") << std::endl;
auto exiter = [] (const int v) { if(v==123)exit(0); } ;
for_each(in(std::cin),in(),exiter);
}

Here we can see a lambda being used as an immutable first order entity. The for_each
could be parallel or serial, it really does not matter. We can also see type inference
where the type of the lambda is inferred from its internal code (in this case void).

I did not include this here because it is a clever bit of code; Indeed, my motivation
is quite the opposite! I am working on a parser for my research language VSPL using
the Spirit library in Boost. The above was just a play thing to make sure the project
was set up correctly. However, easy features like type inference, lambdas, name spaces
and internal DSLs are so accessible in C++ now that they are just natural in the most
trivial coding example. I just don't see a strong enough argument for new languages to
replace C++.

↑に対する反応から。

C++11 Makes Competitors Go Rusty | Hacker News

Compatibility: The new language will have to talk with older languages. Types will 
have to be translated; memory models will need to be aligned and compilers will need 
to 'play nice' together. This is not just as the compiled object level but at the ABI 
level during linking etc. I've spent more time solving issues with memory models in 
C++ than I have in any other language because C++ has no ABI - I've had patches to 
MSVC change the memory layout of objects and cause breakage which is just as bad as 
you get with any sort of language interop scenario.

Performance: This new language is super fast. Great, but it will have to work with 
existing systems. The interface between the two will slow stuff down a lot... Seeing 
as C++ has no ABI, there's no non-hacky way to provide a C++ binary shared library 
that doesn't end up using a very small subset of C++ (for example, no STL, since it's 
all templated, meaning the code your compiler generates won't interoperate with the 
code the client's compiler), which means people end up wrapping their C++ code with C 
APIs.

Build: ... #include is a broken piece of legacy that everyone will be happy to see 
disappear - give us real modules instead of a compilation model which pastes file 
contents inside other files. Also, C++ compile times are ridiculously long compared to 
a modern CFG-based language (that's disregarding the fact that compilers often 
disagree as to what's valid code because of the extremely complicated syntax of the 
language).

Debugging: ... Debugging modern code that uses shared_ptr, bind, etc. is such a 
massive pain in the ass because you end up mixing the code you care about with those 
plumbing details - "step into " becomes useless. Add the fact that there is 
no ABI and you find yourself unable to introspect objects at runtime when compiled in 
release mode (where all the nasty memory issues tend to show up)

Team Training: ... C++ is, as I've been ranting, complicated. I've been using it for a 
long time, and there's still no language in which I fear making subtle mistakes 
that'll cause hard-to-diagnose bugs (for example, exceptions are often treated as an 
anti-pattern because it's so hard not to make such mistakes using them)

Team Embedded Knowledge: ... This is a valid point. I don't think it's worth the price 
you pay for using C++...

[Ecosystem complaints - tooling, licensing, lifespan] Beyond the fact that tooling for 
managed languages is often superior to C++ (because of the better-controlled memory 
layout and execution model), these are valid points.

Startup And Shut-down Sub-Systems: ... This is also broken in C++ - in what order are 
static objects initialized (definition order inside a cpp file, file sequences are 
random)? What happens if one wants to refer to another? I know these are solvable 
issues, but every single one of them requires thought and effort on the programmer's 
side, and these aren't the sort of issues that a programmer should be wasting his time 
on.

Paradigm Contamination: ... Yes, writing in a language and writing idiomatically in a 
language are two different things, but modern, idiomatic C++ is both something I've 
seen few people who know (compared to out-dated and dangerous practices), and it still 
requires more effort to keep in mind than, say, writing idiomatic python, or C#, or 
java.

Brain Strain (the bilingual problem): ... This isn't really an argument - it's 
speculation. I could say that perhaps the fact that C++ is so varied that different 
subsets of it end up looking like different languages, and all of them with more 
details you have to keep in mind to make sure you aren't breaking stuff subtly. Also, 
being bilingual also provides cognitive advantages, so even that flawed analogy might 
not be proving the point.

Let us think about the big ideas behind Go: [snip] Well, one can write simple clean 
C++ and use share_ptr. Just because C++ can be super complex does not mean it has to 
be. Unless, say, you're writing a DLL (another fun fact: not only can your API not 
have STL, exceptions also can't cross DLL boundaries), or you're using DLLs written by 
other poor souls who were consigned to writing DLLs with a C++ API.

This is not to say that C++ has no place in software development (I use it daily at 
work), but I'm of the opinion that unless you have a really good reason, avoid it like 
the plague. New languages taking over more niches C++ used to occupy is a good trend.

As a finishing note, one of my favorite articles on the subject of complexity in 
programming: http://www.joelonsoftware.com/items/2009/09/23.html


Stroustrup is right, but that doesn't prove your point. Every language will have 
detractors, but not every language will be the target of every particular complaint. 
Lua, for example, is a useful language and it has largely avoided being a ball of mud.

Naturally, that minimalism brings its own set of issues and complaints. But the point is,
you don't need to be as much of a ball of mud as C++ in order to be useful or successful.
I think a lot of language partisans, and C++ partisans in particular, point to Stroustrup's
quote as an excuse for their language's warts. It's true that no language can ever be
perfect, but that doesn't mean that all complaints are without merit and unworthy of
attention and consideration.

■_ ネタ

アワーズの連載でネイが登場したのでこういうやりとりが

【ナポレオン】長谷川哲也34【陣借り平助】

619 名無しんぼ＠お腹いっぱい [sage] 2012/02/02(木) 14:52:56.43 ID:VFCbwGB30 Be:
    まあネイの真骨頂はロシア退却戦なわけで
    マリー・テレーズ(マリー・アントワネットの娘)すら感動させて死刑に1票投じた事を後悔するぐらいだからな。 

620 名無しんぼ＠お腹いっぱい [] 2012/02/02(木) 14:58:32.01 ID:6GToE1QU0 Be:
    退き佐久間みたいなもんか 

621 名無しんぼ＠お腹いっぱい [sage] 2012/02/02(木) 22:07:23.49 ID:hLc7fcfT0 Be:
    かかれマッセナに退きミシェル。米ベルティエに木綿ダブーってとこかい？ 

622 名無しんぼ＠お腹いっぱい [sage] 2012/02/02(木) 22:17:08.83 ID:zh2ELWM40 Be:
    鬼武蔵は、誰なんですか

男子バレーボールが強くならない理由 | Selfkleptomaniac
「ストラウストラップのプログラミング入門」を読みました | ありえるえりあ時間のない人に、本書の中で読むべき章を選べと言われたら、第6章を挙げます。
The Developers Channel | Programming Tutorials
100人が選ぶソフトウェア開発の名著選　デブサミ10周年を記念して2月21日に刊行：CodeZine
同書では、過去デブサミに登壇した開発者を中心としたIT業界に関わる100名の執筆陣が、ソフトウェア技術者に贈りたい書籍を選定、その内容を紹介する。
Colorful Pieces of Game::ゲーム史について思ったこと
ところで、ゲーム史に関する本格的な研究や記録は日本ではほぼない。これは世界のゲーム史から見たとき、恐ろしく不幸なことだ。
怒鳴る上役への備えは「ティラノの原理」で - 林浩一のITアーキテクトの視点：ITpro
The Icon Implementation Book
ソフトウェアテストの30年前と30年後（前編）～テストの根幹は30年前に書かれた JaSST'12 Tokyo － Publickey
ソフトウェアテストの30年前と30年後（後編）～30年後のテスト技術、期待を込めた予想 JaSST'12 Tokyo － Publickey

あー毒吐きてえ

■_


Why Lua
January 30, 2012 at 12:19 PM | 32 Comments

Posted by: ktr

Disclaimer: this article is intended for those familiar with programming languages 
(Lua in particular).

In this article, I would like to discuss why you should use Lua. This all started with 
a message that recently popped up on the Lua mailing list regarding why isn't Lua more 
widely used? The answers went from randomness to lack of libraries to a variety of 
other things, but the one that resonated with me most was that there are fewer people 
who enjoy the do it yourself approach, which Lua fully embraces. I've come to think of 
Lua as the Arch Linux of programming languages. Which, almost by definition, means 
fewer people will enjoy Lua rather than more. So then why would you want to use Lua? 
In no particular order, here are some of the reasons why we use Lua to develop our 
product:

1. Integration with C (and C++ for that matter)

I have used a lot of languages during my short career as a programmer. Lisp, Scheme, 
Python, Perl, Bash, VBA, SQL, etc. etc. etc. There is no other language that I have 
ever used that even comes close to Lua when trying to commingle C code. The C API is 
so clean and so intuitive that I would argue that you could get up to speed on its use 
in an afternoon. Check out PIL's section on the C API if you are interested in 
learning more.

Why is this important? Well, for one this means that if you have an existing C (or C++) 
library, it is usually not very difficult to expose the API to Lua. Nor is it 
difficult to write a script in Lua and get something running on the C side. This also 
means that speed problems are rarely an issue in Lua programs. You can write something 
in Lua and truly rewrite it in C if it is a speed problem. It is always possible to 
rewrite something in C in other languages, but Lua is the only language in which I 
have found it easy to do so.

(以下略)

Permalink | View Entire Page

02 Feb ' 02:23

2012年02月01日

Firefox を 10 に。入れていたアドオンが結構未対応だったような気がする。

InfoQ いやまあそのなんというか

■_ Lua

その1

Wikipedia:Wikipedia Signpost/2012-01-30/Technology report - Wikipedia, the free encyclopedia

Why "Lua" is on everybody's lips, and when to expect MediaWiki 1.19
By Jarry1250, January 30, 2012
Lua chosen as new template scripting language

Reducing the inefficient complexity of complicated templates has long been on the wishlists
of those who design and maintain them. It is a complexity that can put a significant drain
on server resources, not to mention one that makes accurate duplication of templates
between wikis incredibly time consuming and error prone. This complexity is caused by a
number of factors, but it has long been recognised that the introduction of certain
constructions found in full programming languages (among them loops, arrays and a full
range of string functions) would drastically simplify matters.

複雑なテンプレートの非効率的な複雑さを軽減することは、それらを設計したり保守している
人たちによるウィッシュリストに長いこと載っていました。
その複雑さはサーバーのリソースを目だって食いつぶしてしまう可能性のあるもので、
not to mention one that makes accurate duplication of templates between wikis incredibly time consuming and error prone.
この複雑さは数多くの要因によるものですが、full programming languges にある
いくつかの constructions (ループや配列、full range の文字列関数といったもの)
の導入によって劇的に事態が単純になるであろうと認識されていました。


Of course, the introduction of a programming language would bring with it a number of other
problems, particularly with regards to privacy, security and memory footprint. As a result,
the long term consensus was that the introduction of a programming language would be a major
undertaking, including time for discussing which languages would work best in a heavily
sanitised environment. The project as a whole has been discussed at regular intervals, but
it was only this week that a consensus seemed to emerge in favour of Lua, a lightweight but
relatively unheard-of language generally regarded as being "easy to learn"
(wikitech-l mailing list).

もちろん、プログラミング言語の導入は、特にプライバシーやセキュリティ、メモリーの使用量に関して
別の問題を数多く持ち込むことでしょう。
結果として、long term での consensus はプログラミング言語の導入は major undertaking でした。
including time for discussing which languages would work best in a heavily sanitised environment.
プロジェクト全体としては通常のインターバルで議論されていましたが、
a lightweight but relatively unheard-of language generally regarded as being "easy to learn"
である Lua を推すという合意は今週だけの議論でした
#違うよなあ、正直わからん


The preferred implementation at this time is via a separate namespace for scripts, perhaps
augmented by the overloading of the double-curly-brace notation to incorporate both Script
and Template namespaces. Work is expected to start after the release of 1.19 and could well
centre around the Berlin Hackathon, held annually in May.

■_ Lua

その2 ↑に対する reddit での反応

Wikipedia chooses *Lua* as its new template/macro language : programming

A language with no baked-in unicode or I8N support at all. For an international wiki. 
That's gonna be interesting.


Internationalization ("i18n") is the design and development of a product, 
application or document content that enables easy localization ("L10n" = the 
adaptation of software for a specific locale).


Indeed. I doubt JavaScript's UTF-16 surrogates would be handled properly in practice 
though, had they gone w/ JS.


JS has really broken Unicode support http://98.245.80.27/tcpc/OSCON2011/gbu/gbu.html


Honestly, most languages and platforms have broken Unicode support.


Yeah but really, does Lua have support for anything "baked-in"? I mean I 
figure that's kind of the point. It and TCL have this thing going on of being like, 
language templates. You get an interpreter and the absolute core syntax to make 
procedural programming usable, batteries are your problem.


Heh - a whole thread of replies promoting languages with half-baked i18n support and 
no mention of Tcl.

Please, do tell.


Tcl was designed to be a lightweight scriptable layer on top of any C library for 
scripting purposes also. It has had real i18n support since about 2005 or so. I don't 
think Tcl could compete with the size or speed of Lua though. Then again, does Lua 
have a standard GUI library (ala tk) currently? You can whip out stuff wicked fast in 
Tcl/Tk once you are even halfway proficient. I'm seeing Lua not just mentioned 
everywhere but implemented in things I use, time to start from lesson 1 on 
projecteuler with a fresh language!


    Then again, does Lua have a standard GUI library (ala tk) currently?

Lua doesn't really have a standard anything, that's kinda the point of it; it's 
brilliant for writing complex configuration/glue stuff (think AI state machines for 
video games, etc) that needs too hook into a bunch of custom APIs. Very little Lua 
code would need to define a GUI, and if it did, the host application probably already 
has a framework to do so.

That said, there's a ton of bindings to GUI frameworks on the wiki page.


Tcl has had full unicode support since 8.1, released in 1999 (!). It's a very stable, 
simple yet powerful language. EIAS (actually, everything has a string representation) 
seems to make it particularly suited as a templating language. You can create safe 
interps and extend the language with new control constructs or even syntax. There are 
other reasons to like it.

訳をつけていく余裕がない。

その3

The Data Mules Blog

Why Lua
January 30, 2012 at 12:19 PM | 32 Comments

Posted by: ktr

Disclaimer: this article is intended for those familiar with programming languages 
(Lua in particular).

In this article, I would like to discuss why you should use Lua. This all started with 
a message that recently popped up on the Lua mailing list regarding why isn't Lua more 
widely used? The answers went from randomness to lack of libraries to a variety of 
other things, but the one that resonated with me most was that there are fewer people 
who enjoy the do it yourself approach, which Lua fully embraces. I've come to think of 
Lua as the Arch Linux of programming languages. Which, almost by definition, means 
fewer people will enjoy Lua rather than more. So then why would you want to use Lua? 
In no particular order, here are some of the reasons why we use Lua to develop our 
product:

1. Integration with C (and C++ for that matter)

I have used a lot of languages during my short career as a programmer. Lisp, Scheme, 
Python, Perl, Bash, VBA, SQL, etc. etc. etc. There is no other language that I have 
ever used that even comes close to Lua when trying to commingle C code. The C API is 
so clean and so intuitive that I would argue that you could get up to speed on its use 
in an afternoon. Check out PIL's section on the C API if you are interested in 
learning more.

Why is this important? Well, for one this means that if you have an existing C (or C++) 
library, it is usually not very difficult to expose the API to Lua. Nor is it 
difficult to write a script in Lua and get something running on the C side. This also 
means that speed problems are rarely an issue in Lua programs. You can write something 
in Lua and truly rewrite it in C if it is a speed problem. It is always possible to 
rewrite something in C in other languages, but Lua is the only language in which I 
have found it easy to do so.

2. Speed and Simplicity

The standard Lua implementation performs extremely well compared to most other 
languages, even without writing anything in C. Perhaps this is because Lua uses a 
register based virtual machine rather than a stack based machine. Or it could simply 
be due to the fact that the programmers behind Lua are just very talented. Whatever 
the reason, you are rarely going to be overly concerned with performance when writing 
Lua code.

But, if you are not getting the results you would hope or expect, you can get an 
almost drop in replacement for the standard Lua implementation with LuaJIT. From the 
overview page:

    LuaJIT is widely considered to be one of the fastest dynamic language 
implementations in existence ... with an unmatched low memory footprint: less than 
125K for the VM plus less than 85K for the JIT compiler (on x86).

LuaJIT speeds can rival code written in C. And if you are still not getting the speed 
you want, see my 1st point above.

3. Education

While not necessarily a language feature, I have found that using Lua has improved my 
general computer science knowledge over time. For example, this writeup on the 
implementation of Lua 5.0 gave me a very good overview of how virtual machines are 
implemented. Reading the very accessible source code, while following the recommended 
reading order suggested by Mike Pall (author of LuaJIT) has been eye opening as well. 
I don't think any of this would be possible except for the methodical manner in which 
Lua has evolved over time. This has allowed Lua to remain "Clean C" which 
means that it is easier for you to understand as a user of the language.

4. Functional

Lua provides you with functional programming constructs that make programming more 
enjoyable. Examples include anonymous functions, higher order functions, lexical 
closures, proper tail calls, etc. And this is not some superficial gloss applied on 
top of the language - it represents some of the fundamental underpinnings of the 
language itself. For example, all functions in Lua are values (like the number 2 or 
the string "ktr") - and this means that every function in Lua is anonymous. 
You simply attach a name to it so that you can reference it later. Thus, like Roberto 
describes in his book, you can reassign print with:

print = math.sin

This type of functionality also enables you to build sandboxes if you need them. If 
printing were a dangerous operation, you could replace it with your own print function 
or simply remove it from the global environment.

5. Everything is a Table

Everything in Lua is a table. Arrays, hashes, "modules", the global 
environment, etc. They are all tables. This means that you can require some module 
(similar to Python's import statement) and treat the resulting value just like you 
would any other table. In Python, you might __import__('...')' some module and then 
the variables of the return value would be accessed like vars(module). Not very 
difficult, but also not very Pythonic. In Lua, you would access the variables in that 
module just like any other table (module[var]). I only mention Python to highlight 
differences - simply showing that it may be easier to "hold Lua in your head" 
due to such consistencies.

This has the added benefit of allowing you to learn the full Lua syntax faster than 
you could in most other languages. Without needing to worry about how lists are 
written versus how dictionaries, packages, etc. are written, you can "assume" 
you already know how they are written because you only need to know the one construct.

6. Consistent

If you haven't figured it out already, Lua is a very consistent language. A lot of 
time has gone into each and every feature to make sure that it was done "just 
right". For example, Lua didn't have a for loop until Lua 4.0 - 7 years after the 
first release. This was because

    while loops were more general. ... Also, we could not agree on a good syntax.

(See page 6 of this document). And since the authors of the language have remained 
relatively unchanged and rather limited (the Lua team does not like to accept patches), 
the language has evolved somewhat slowly and quite coherently. So you know features 
are well planned. (However, this also means you shouldn't expect to have a lot of your 
pet features implemented anytime soon.)

7. Portable

I won't go into a lot of detail, but rest assured that Lua runs on almost everything 
you can think of. The code is written as "Clean ANSI C", so if you have a 
compliant C runtime, you will likely be able to get Lua running without much fanfare.

All in all, a very powerful, yet simple language.

その4．↑に対して

Why Lua? | Hacker News

I took some Visual Basic programming courses in high school, some PASCAL courses in 
college, and then didn't program anything other than basic HTML/CSS for the next eight 
years. Last year I programmed an iPhone game in Lua (using the Corona SDK) and it was 
easy as Tau. Sure a better programmer would have finished the programming aspects in a 
quarter the time it took me, but I started by looking at Objective-C and I'm not sure 
I ever would have picked it up without some kind of formal training. Contrast with 
Corona/Lua, where I watched a few eight minute videos on YouTube and could turn around 
and make simple but complete programs, and more importantly completely understand what 
was going on within them. Reading the Lua documentation was a revelation, reading 
Apple's was a headache.


Why Lua? http://itunes.apple.com/us/app/beat-boxes/id460798042


Doesn't Apple forbid applications built using things like this?

As long as you are not running code that is downloaded after app install (e.g. either 
embedded in the app itself or entered by the user from the keyboard) you are good to 
go. This mod to the previously ominous app store policies is used by quite a lot of 
applications.


The more I learn about Lua's design and implementation, the more impressed I am. It's 
very rare to see software that does so much with so little code. The design is 
extremely clean and the code is extremely fast.

The C API is easy to use and gives good performance, and yet encapsulates enough of 
the VM's implementation that C modules are source and binary compatible with both Lua 
and LuaJIT, two very different implementations of Lua. Note that the C API was 
designed before LuaJIT was even written, so this API was designed without the benefit 
of seeing how different implementations of Lua might vary.

The source is very readable for the most part; my only stumbling block is that their 
naming of types and variables is extremely terse at the cost of readability sometimes, 
and the extensive use of macros can sometimes can require a lot of jumping around. But 
Lua is an impressive achievement that I frequently refer to for design inspiration.


Lua has great C integration, but LuaJIT's is even better. You can natively interface 
with C code without a recompile, just by defining the C function prototype in Lua, and 
using it like you would any normal lua function. Better still, LuaJIT can frequently 
inline the calls to C code, so there's no cross-language marshaling penalty.

Check out http://luajit.org/ext_ffi_tutorial.html

Not criicizing lua, but worth comparing to guile.

> Integration with C (and C++ for that matter)

Guile does it better. You can use shared memory threads in guile without any penalty. 
Atmost you have to allow for the garbage collector to run when inside FFI functions. 
But that is a small price to pay in case you need to use multiple parallel-concurrent 
threads with a single heap.

Guile was built with FFI in mind and has an impressive history. Just take a look at 
guile gnome bindings.

> Speed and Simplicity

Guile 2 is extremely fast. Not as fast as LuaJIT, but it no reason it won't get there. As for simplicity, take a look at the partial evaluator in trunk of guile 2.

> Education

Guile is good old scheme.

> Functional

Can't get more functional than scheme :)

> Everything is a Table

Well, almost everything is a pair in guile. Vectors and hash-tables are trivially 
available. Though I recommend to sticking to functional programming in scheme style.

> Consistent

As before, can't get more consistent than scheme.

> Portable

Guile is available on n900. So there.

To continue, guile has continuations (delimited or otherwise), and macros (hygienic or otherwise), both of which are effectively missing in lua.

And guile offers all of this while supporting native threading with a single heap. Sweeet.


Not sure if I'd agree that Guile's FFI bindings are better than LuaJIT's FFI. It's 
certainly easier to declare a function in LuaJIT - you can take the definition 
directly from the header file, rather than transcoding it into s-exps.

Compare:

  (define memcpy
	       (let ((this (dynamic-link)))
	         (pointer->procedure '*
	                             (dynamic-func "memcpy" this)
	                             (list '* '* size_t))))

vs.

  ffi.cdef [[
	void * memcpy ( void * destination, const void * source, size_t num );
  ]]

You also get the ability to add metamethods and finalizers to returned C objects (so 
you can use Lua's built-in GC to clean up after, for example, your FILE*).

As for the speed, there's no reason that a lot of dynamic languages couldn't be as 
fast as LuaJIT. But none of them are even close. I wish LuaJIT was still up in the 
computer language shootout. The LuaJIT interpreter (with JIT turned off) is 3x faster 
than V8 on the PC, and faster than Java on Android. And that's the interpreter - the 
JITed code is way faster.

Of course, macros are awesome, and a huge point in Guile's favor. On the plus side, 
Lua is very easy to understand, especially if you're coming from Javascript.

なんでこう盛り上がるんだろう。

同じ元記事に対して reddit では

Why Lua : programming

Lua is amazing for embedding. You can even easily overload its memory allocator or 
default data type. I needed to do this for a project where we were running on a 
processor without native support for double or without a standard C library.

That is just amazing stuff.

When I first started playing with Lua, I found myself repeatedly saying of its features
"You can't do that! That sounds like a great idea but you can't do that because it
will, well because... I'm pretty sure this is a design mistake in the long run because...
", and then failing to come up with compelling arguments against them.

Take for example the "..." syntax for variadic functions. You can't do that, 
right? I distinctly recall being frustrated with C's clunky va_list and va_start etc., 
and the fact that you can't easily wrap variadic functions, and it's just a whole mess. 
I distinctly remember justifying that to myself and thinking that it couldn't be any 
other way. But Lua comes along with its "...", like it just doesn't give a 
fuck.

So things like that certainly have had an effect on how I think about programming.

I'm not a big fan of some of the ways I've seen people use Lua. For example, people 
want classical inheritance, so you have all these libraries out there that either roll 
their own classes, or rely on other libraries for classes. So now if you want to use 
four third-party libraries, you're liable to find yourself juggling four slightly 
different inheritance models from class libraries with overlapping namespaces – 
suddenly JavaScript's choice of having class as an unused reserved word seems 
extremely wise.

Then of course there's the commonly-seen-as-brilliant practice of serialization by 
emitting Lua code. It's just like JSON but without any regard for security!


Python's variable length arguments syntax is probably the best out of any language.

This article is just what I have been looking for. I have started with Lua two weeks 
ago but there still were so many questions. Good article with good links in it. I am 
sure it will help me alot in the future.

Thanks for sharing!

Check out my language, http://moonscript.org

It compiles into Lua, but does a lot of what CoffeeScript did for JavaScript and more. 
Classes, comprehensions, cleaner syntax, etc.

Here's the reference manual: http://moonscript.org/reference

いつにも増して日本語の部分が少ないものになってしまったw

Permalink | View Entire Page

31 Jan ' 14:38

2012年01月31日

行ってしまった一月

積読の山を眺めつつ、どうしたものかと。

たぶんついったー経由で知った、Emacs の正規表現に対するパッチ。先読みやら戻り読みを追加するもの。

Index: src/regex.c
===================================================================
RCS file: /sources/emacs/emacs/src/regex.c,v
retrieving revision 1.236
diff -u -r1.236 regex.c
--- src/regex.c	8 Jan 2009 03:15:54 -0000	1.236
+++ src/regex.c	3 Jun 2009 22:35:17 -0000
@@ -735,7 +735,14 @@
   syntaxspec,
 
 	/* Matches any character whose syntax is not that specified.  */
-  notsyntaxspec
+  notsyntaxspec,
+
+  lookahead,
+  lookahead_not,
+  lookbehind,
+  lookbehind_not,
+  lookaround_succeed,
+  lookaround_fail
 
(略)
@@ -3389,13 +3482,40 @@
 		/* If we've reached MAX_REGNUM groups, then this open
 		   won't actually generate any code, so we'll have to
 		   clear pending_exact explicitly.  */
+                lookaround = COMPILE_STACK_TOP.lookaround;
 		pending_exact = 0;
 
 		/* We're at the end of the group, so now we know how many
 		   groups were inside this one.  */
 		if (regnum <= MAX_REGNUM && regnum > 0)
 		  BUF_PUSH_2 (stop_memory, regnum);
-	      }
+                else if (lookaround)
+                  {
+                    if (lookaround > 0)
+                      {
+                        /* Positive/negative lookahead assertion.  */
+                        GET_BUFFER_SPACE (3);
+                        INSERT_JUMP (lookaround == 1 ? lookahead : lookahead_not, laststart, b + 4);
+                        b += 3;
+                      }
+                    else
+                      {
+                        /* Positive/negative lookbehind assertion.  */
+                        int count = exact_chars_in_pattern_buffer (bufp, laststart, b);
+                        if (count == -1) /* variable length */
+                          FREE_STACK_RETURN (REG_BADPAT);
+
+                        GET_BUFFER_SPACE (5);
+                        INSERT_JUMP2 (lookaround == -1 ? lookbehind : lookbehind_not, laststart, b + 6, count);
+                        b += 5;
+                      }
+                    
+                    /* Negative form.  */
+                    if (lookaround > 1 || lookaround < -1)
+                      BUF_PUSH (lookaround_fail);
+                    BUF_PUSH (lookaround_succeed);
+                  }
+              }
 	      break;
 
(略)

glibc のものを使っているのかと思ったけどどうもそれとは違う感じがするし、それでいて見覚えがあるような雰囲気。ということで、regex.c といういかにもなファイルをみてみると

/* Extended regular expression matching and search library, version
   0.12.  (Implements POSIX draft P1003.2/D11.2, except for some of the
   internationalization features.)

   Copyright (C) 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001,
                 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011
                 Free Software Foundation, Inc.

   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; either version 3, or (at your option)
   any later version.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program; if not, write to the Free Software
   Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
   USA.  */

/* TODO:
   - structure the opcode space into opcode+flag.
   - merge with glibc's regex.[ch].
   - replace (succeed_n + jump_n + set_number_at) with something that doesn't
     need to modify the compiled regexp so that re_match can be reentrant.
   - get rid of on_failure_jump_smart by doing the optimization in re_comp
     rather than at run-time, so that re_match can be reentrant.
*/

ああ、やっぱり以前のやつだ。＞ 0.12 merge with glibc's regex.[ch] なんてのも

しかし、これって Ruby では戻り読みをサポートできないってことになってそれで鬼車が作られたという流れがあったような。このパッチはどういうロジックになっているんだろう? ざっとは見たけど把握できたかあまり自信がない…

■_ アイスコーヒー

IcedCoffeeScript

IcedCoffeeScript

Welcome to IcedCoffeeScript!

IcedCoffeeScript is a fork of CoffeeScript. It is superset of the CoffeeScript language.
The iced interpreter is a drop-in replacement for the standard coffee interpreter since
it will interpret all existing CoffeeScript programs.

IcedCoffeeScript (ICS) adds two new keywords: await and defer. These additions simply and
powerfully streamline asynchronous control flow, both on the server and on the browser.
Say goodbye to callback pyramids; say adios to massive code rewrites when synchronization
requirements change slightly. Say hello to clean, readable, maintainable control flow for
network and asynchronous operations! See the Iced Features tab for more details.

The golden rule of CoffeeScript was: "It's just JavaScript". ICS is doing 
something deeper. It's selectively running code through a continuation-passing style 
conversion. Original-style CoffeeScript will compile as before, but code using the new 
ICS features will be less recognizable. Still, the compiled output is readable and 
pretty-printed, passes through JavaScript Lint without warnings, will work in every 
JavaScript implementation, and tends to run as fast or faster than the equivalent 
handwritten JavaScript.

Latest Version: 1.2.0j

ICS is doing something deeper と。

貸会議室とZusaarで安心して勉強会を開催 #zusaar #twtr_hack - 侍ズム
3月5日開催：SEA Forum March 2012：実用期を迎えた関数プログラミング-SEA HomePage
BASE of UGSF-WESTアーケードゲーム博物館計画より緊急のお知らせです！！
書物を手に取る喜びと、地方都市の未来（第193回）：青木恵美「信州発 ITライターの憂鬱」
Rust のインターフェース - uasi:ウアシー

2012年01月30日

買った

Moonlight Mile は最初の頃を考えるとえらい違いが。

■_ Lisp 1.5

modern OS で動く Lisp 1.5 求む。

Is a Lisp 1.5 available for modern OSs? : lisp

I'm wondering if Lisp 1.5 is available on a modern Linux system


This lisp is based on 1.5 IIRC: http://www.aviduratas.de/lisp/prolisp.html


http://www.softwarepreservation.org/projects/LISP/lisp1.5 has various resources. One approach
might be to figure out the simulated environment Paul McJones used to create lisp.lst and run
it there. (It looks like he was able to get a clean assembly run on the sources of the IBM
704/709 version. (Or on one of the other architectures it was ported to.)

What is your real goal? Run a historic piece of Lisp code? Find out how Lisp hackers lived in
the 1960s?

It is hard to separate the language from the environment. You really want character 
I/O to be done in the style of punched cards? With a 48-character character set? You 
want to interact with a 1960s mainframe job control system?

More fundamentally, Lisp 1.5 has the warts of dynamic scoping and FEXPRs that were 
discovered to be bogus in the same process that led to Scheme. Common Lisp borrowed 
the real advances made in lexical scoping (while not making other choices that the 
Scheme community did.)

Dynamic scoping is certainly a wart, although it was good enough for the first generation,
and although elisp got by with it for another generation.

But FEXPRs are not; it just simplifies the world to have only just QUOTE.

As for 48-character, my memory is fuzzy about the 704, so I'll take your word for it, 
but certainly there were plenty of 1.5s on 18- and 36-bit machines, where the 
character width was a choice of either 7 or 9 bits.

I also seem to recall that interactive LISP was more the rule than the exception, even 
prior to the advent of timeshare systems (in which Lisp and McCarthy played a part, 
although that's a different topic).

1.5 did on the other hand have a variety of data structures beyond sexprs, despite the 
common misunderstanding to the contrary. (I'm sure you know that; I'm just saying.)

Interesting topic, actually. I meant to do a 1.5 clone years ago (minus the most 
absurd of warts such job control) but of course never got around to it.


Well, that's sort of the Ur-lisp. I'm referring to Lisp 1.5.
http://www.softwarepreservation.org/projects/LISP/book/LISP%201.5%20Programmers%20Manual.pdf

■_ for

なんで Ruby に for 文があるの? という疑問。

Why is there for-statement in Ruby? : ruby

Even I have just only few experiences of Ruby, I just become aware of there is for in Ruby
(I saw that when I learned Ruby first). Most of Ruby codes seem to use just Enumerable#each
method instead of for statement, but why? Is there any reason to prefer Enumerable#each
method over for statement?

for doesn't introduce a new scope. Consider this:

  foo = :bar

  [1, 2, 3, 4].each do |foo| # should be 4.times, but for the sake of example...
    puts foo
  end

  puts foo #=> :bar, not changed because Enumerable#each has a new scope

  for foo in [1, 2, 3, 4]
    puts foo
  end

  puts foo #=> 4, because `for` changes the variable

There are some specific use cases for for, but you'll almost always prefer 
Enumerable#each. One use case might be the following:

  for user in users
    break if user.valid?
  end

  # ... access user

But more idiomatic Ruby might be something like:

  user = users.select(&:valid?).first
  # ... access user

If there is I'd say it's negligible, in the use case above (selecting a valid user) 
there may be a performance improvement if the first valid user in a sufficiently large 
list isn't at the end, the code using for will stop as soon as it finds a valid user, 
whereas Enumerable#select will iterate over the entire collection regardless and then 
you have to pick the first item out of that set.

So there could be performance benefits from using for, but I only see it in fringe 
cases and if you get that much of a benefit from using for over the Enumerable methods 
then there might be better ways to handle things elsewhere in your code (not always 
though).

EDIT: Actually, as threedaymonk posted in another comment, you could use 
Enumerable#detect to select and stop at the first result, this should have the same 
performance as the for statement (minus the extra call to convert the symbol to a proc).

I don't use for, because of the following reasons:

    for loops doesn't introduce a new scope, as nilved explained

    for loops just delegate to each anyway

    using each makes my code look more consistent: it's blocks everywhere, it doesn't matter if it loops or not.

    you cannot use for loops functionally, like passing lambdas: users.each(&:save)

    you're tempted to miss the other enumerable methods when using for, like select, reject,
    find, map, all?, any?, and dozens more that you really should learn, use and love.

I've been working with Ruby for 2 years, and for loops are very rare.

I grepped through the Rails codebase, and found that there's only 28 for loops, versus 1163 uses of .each.

EDIT: I would say that for loops are more readable when dealing with ranges. Consider the following:

  (1...developers.size).each do |i|
  (3..10).each do |digit|

or

  for i in 1...developers.size
  for digit in 3..10


I often use the for-loop. Here's why:

1) Iteration is such a primitive operation that I think it's more intention-revealing to use
   the syntax designed specifically for it.

2) It's easier to type and easier to read.

3) The difference in the scope of variables in the two constructs should not be an issue in
   any well-written program. It's of academic interest only. If it trips you up, you're not
   doing it right.

4) Ryan Bates uses the for-loop.

これもバイク小屋の議論の類ですかね

■_ awkの挙動

Twitter / @hi_saito: いやいや、awk で FS を ¥t にすれば大丈夫 ... ということで

bash の read に関するイマイチな仕様 - ritchiekotzenの日記

2012-01-30 bash の read に関するイマイチな仕様

■bash の read で空文字のカラムがある場合、そのカラムの存在は無視され、右から詰められてしまう。
例えば、

while read col1 col2 col3
・・・

のようなスクリプトが標準入力から

hoge\t\tfuga

のようなレコードを受け取った場合、
　col1="hoge", col2="", col3="fuga"
ではなく、
　col1="hoge", col2="fuga", col3=""
となってしまう。

awkやsortコマンドでも同じような挙動をしてしまうらしい。
cut コマンドはちゃんと空白文字でもカラムとして認識してくれるみたい。
対処としては、perl等で処理するしかなさそう・・・

NULLが入る可能性のあるカラムを処理で使用しないのなら、cut コマンドでそういったカラムを除いてから処理するというのも手。

■デフォルトの区切り文字はタブとスペース

いつもタブ区切りファイルをインプットに使うので忘れいていたが、実はスペースも区切り文字として扱われる。
よって、文字列の中にスペースがあると、別々なカラムとして認識されてしまう。
IFS=" " <- ctl+v,tab でタブ文字を入力
としておけば、タブだけを区切り文字として扱ってくれる。

whitespace の連なりを一つの区切りと見るのでそうなるわけですが、これって割とよく見られる既定の動作だと思うけどなあ。わざわざ cut で前処理しなくても、さいとうさんがツイートしていたように FS に設定してやればOK。

Man page of GAWK

フィールド

入力レコードを読み込むごとに、 gawk はそのレコードを フィールド に分割しま す。分割す
る際には、変数 FS の値がフィールドセパレータとして参照されます。 FS の値が1文字なら、
その 文字を境にフィールドが分割されます。 FS が空文字列の場合、個々の文字がフィールド
セパレータとなります。 いずれでもない場合、 FS は完全な正規表現である と解釈されます。
特殊な場合として FS が単一の空白のときには、フィールドは 連続した空白・タブ・改行によ
り分割されます。

このような規定値が設定されているものは他にもあってたとえばperlのsplit

split 【perldoc.jp】

split /PATTERN/,EXPR,LIMIT
split /PATTERN/,EXPR
split /PATTERN/
split

    文字列 EXPR を文字列のリストに分割して、リストを返します。 デフォルトでは、行頭の空白は
    保存され、末尾の空白は削除されます。 (全てのフィールドが空の場合、これらは末尾であると
    して扱われます。)

    スカラコンテキストでは、見つかったフィールドの数を返します。

    EXPR を省略すると、文字列 $_ を split します。 もし、PATTERN も省略すると、 (先頭の空白
    文字をスキップした後) 空白で split します。 PATTERN にマッチするものは、フィールドを分割
    するデリミタとして扱われます。 (デリミタは、1 文字とは限りません。)

(略)

    特別な場合として、PATTERN にスペース (' ') を指定すると、 引数なしの split のように空白で
    split を行ないます。 つまり、split(' ') は awk のデフォルトの動作をエミュレートするために
    使うことができ、split(/ /) は行頭のスペースの数に応じた空フィールド (空文字列)ができます。
    split /\s+/ は split(' ') と同様ですが、 先頭の空白は先頭の空フィールドとなります。 引数な
    しの split は内部的には split(' ', $_) を実行します。

gawk で -F'\t' とやったときにタブがFSに設定されるのは GNU 拡張だったりするのだけど GNU のであれば他のツールも大抵こうなってんじゃなかろうか。

で、タイミング良くこういう記事が

Know split’s special cases | The Effective Perler

Effective Perl Programming – write better, more idiomatic Perl

Know split's special cases

Posted by brian d foy on November 27, 2011

Perl's split has some special cases and some perhaps surprising cases. The empty pattern,
zero width match, the special argument ' ', and the /^/ act differently than you might
expect from the general rule.

Perl の split にはいくつかの特別なケースと、いくつかの驚きをもたらすであろう
ケースがあります。空のパターン、zero width なマッチ、特別な引数 ' '、
さらに /^ / といったものの振る舞いはあなたが一般的なルールから類推するものとは
異なるものでしょう。

The empty pattern, //

The empty pattern is a special case that's designed to give you a list of characters. 
This pattern specifically has nothing in it and is different than a pattern that 
matches an empty string (that's next). For this, split returns a list of characters:

空のパターンは文字のリストを得るために設計された特別なケースです。

そして空文字列(次の項目です)にマッチするパターンとは異なるものです。
このパターンでは split は文字のリストを返します:

	use utf8;
	 
	use Data::Printer;
	my @characters = split //, 'Büster';
	 
	p( @characters );

The output shows a list of characters:

	[
	    [0] "B",
	    [1] "ü",
	    [2] "s",
	    [3] "t",
	    [4] "e",
	    [5] "r"
	]

This is specifically characters, not grapheme clusters. Depending on the normalization 
of your source code or input, you can get different results:
	use utf8;
	 
	use Data::Printer;
	use Unicode::Normalize qw(NFD);
	 
	my @characters = split //, NFD( 'Büster' );
	 
	p( @characters );

以下略

2012年2月(上旬)

Permalink | View Entire Page

29 Jan ' 10:51

2012年01月29日

読み終わったClean Coder プロフェッショナルプログラマへの道さっくり読了。原著で読むスピードもっと上げないとなあ。感想やら書評やらは他にいろいろ書く人がいるでしょうからパスw。とはいえコノ職業の人であれば大抵の人は読んでおいていい本じゃないでしょうか。

んで、

という本がありまして。

とどういう関係があるのかと思って買ってざっと見てみると、後者がCで書かれているのに対して、前者(今回出たほう)はC++を使っているというのが一番の違いのようです。でまあ後者には「コンパイラー」ってのもありますがこの辺はソースコードを変換したものがファイルとして残るか残らないかといった違いでしょう。「コンパイラー」のほうは実行するためには別のプログラムでそれを解釈させてましたし (ネイティブコードを吐くものではなかった)。

Javaセキュアコーディングスタンダード CERT/ Oracle版Fred Long Dhruv Mohindra Robert C. Seacord Dean F. Sutherland David Svoboda 歌代和正

も買おうかどうしようか悩んだのだけど大型本縛りに負けて(個人的事情ですが)、ペンディング的スルー。あんまり Java いぢらないしね。
ちょっと前に、こういう話題が掘り返されているのをいつものところ (Hacker NewsとかStackOverflowとかreditとか)で見かけまして Good Ideas, Through the Looking Glass | Lambda the Ultimate
5.5. Using wrong tools

Using the wrong tools is obviously an intrinsically bad idea. The trouble is that often
one discovers a tool's inadequacy only after having invested a substantial amount of
effort to 24 build and understand it, and the tool thus having become “valuable”.
This happened to the author and his team when implementing the first Pascal compiler
in 1969. 

The tools available for writing programs were an assembler, a Fortran and an Algol compiler.
The latter was so poorly implemented that we did not dare rely on it, and work with
assembler code was considered dishonorable. There remained only Fortran.  

Hence our naïve plans were to construct a compiler for a substantial subset of Pascal
using Fortran, and when completed, to translate it into Pascal. Afterwards, the classical
bootstrapping technique would be employed to complete, refine, and improve the compiler. 

(略)

-- From N. Wirth - Good Ideas, Through the Looking Glass, 2005
なんとヴィルト先生の論文(エッセイ?)だったと。上記のリンク先にあるのは本の一部分らしく、いろいろ探してみるとまずは感想を書いているものがいくつか。
最近の話題 2006年2月4日

３．Niklaus Wirth先生のGood Ideas, through the Looking Glass

  IEEE Computer誌の2006年1月号にPascalやModulaなどで有名なNiklaus Wirth先生がGood Ideas,
through the Looking Glassと題する文章を書いておられます。題名はGood Ideasですが，中身は
Bad Ideasのリストに近く，過去のBad Ideaの失敗に学ぼうという書き方です。

(略)
Good Ideas through the Looking Glass - $ cd ./.

2006-03-15
Good Ideas through the Looking Glass

IEEE Computer Jan / 2006 の記事。

http://doi.ieeecomputersociety.org/10.1109/MC.2006.20

過去を振り返ってその時点ではよかったアイデアをけなす、というコラム。いろいろ槍玉にあが
っているのだけど、かなり首をかしげるところもあった。まあ、このコラム自体が軽いネタみた
いなものなので、マジレスもよくないのだが、そういうことは考えずに全力で攻撃。

(略)
どうにかして全文読めないものかとさらに探してみたところ、 pdf になっているものを発見。ということでこれから読みます。

2000 年頃に引退されたとか聞いたけどこのごろはどうされているんだろう＞センセ
海外記事紹介シリーズ(嘘
Jay Fields' Thoughts: Lessons Learned while Introducing a New Programming Language

Tuesday, January 24, 2012

Lessons Learned while Introducing a New Programming Language

I've used a lot of languages (professionally) over the years: (off the top of my head) 
Cold Fusion, HTML, Javascript, php, SQL, CSS, ASP(classic & .net), C#, Ruby, Flex, 
Java, & Clojure. Each language has pros and cons. Being a programmer, it's easiest 
to discuss the cons - and in general I believe it was best said:

    I hate all programming languages - Matt Foemmel

I think it's important to start with this in mind. At some point you're going to hate 
what you're advocating, so imagine how other people feel about it.

In 2008 I introduced Clojure into a DRW codebase. This blog entry focuses on the 
adoption lessons I've learned in the past few years.
■_

今月の Rakudo
This month's Rakudo Star release – and what's coming next | 6guts

(略)

Here's some of the things I'm happiest about in the release.

    The performance improvements in many areas. Yes, we've plenty of work to do here – but
    this is a solid step forward for a wide range of scripts, and in some cases an order
    of magnitude improvement.

    That 6model – something I started designing a year and a half ago – has not only
    cleanly supported all of the things we needed to do in Rakudo, but also opened up so 
    many other doors. For example, the new NativeCall module uses its representation 
    polymorphism support to great effect.

    Protoregexes doing real NFA-driven Longest Token Matching rather than the cheating 
    version we had before that only operated on literals.

    The optimizer, along with the various extra compile time error reporting it gives. 
    This will be an important future area for Rakudo.

    Initial native type support, and bigint semantics for the Int type.

    The POD6 support, thanks to tadzik++'s Google Summer of Code grant in summer.

So, what's next? Currently I'm working hard on getting true bounded serialization support in place.
(略)
そろそろバイナリパッケージの新しいのも出る時期?
■_ Rakudo Star 2012.01 released

これか
Rakudo Star 2012.01 released | rakudo.org
Rakudo Star 2012.01 released
Posted on 2012.01.28 by jnthn	

On behalf of the Rakudo and Perl 6 development teams, I’m happy to announce the January
2012 release of “Rakudo Star”, a useful and usable distribution of Perl 6.  The tarball
for the January 2012 release is available from http://github.com/rakudo/star/downloads.

In the Perl 6 world, we make a distinction between the language (“Perl 6″) and specific
implementations of the language such as “Rakudo Perl”.  This Star release includes
release #48 of the Rakudo Perl 6 compiler [1], version 3.11 of the Parrot Virtual
Machine [2], and various modules, documentation, and other resources collected from the
Perl 6 community.

(略)
■_

全ての大学は職業教育の場です！ - None is None is None

(1) 全てのページにcanonicalを！

Common Lisp書籍ツイートまとめ - はてなまとめ（仮）

個性と常識の間：Google社内の様子とSONYの就活: 組み込み技術者の単身赴任日記

真夏のアスファルトで干からびるミミミズ。窒息しそうなほど溢れかえる窒素。あるいは、文明の寿命。『土の文明史』 - あおぎみれば、空

ハーバードの確率の授業が凄い件 - what_a_dudeの日記

Ruby Gold Programmer になりました - あーありがち(2012-01-28)
Rubyインタプリタを自分の頭の中に作り上げられれば合格する

「木口古兵は死んでもラッパを離しませんでした」とは - BIGLOBEなんでも相談室

Ideone.com | Online Ruby Interpreter & Debugging Tool

Ideone.com | Online Ruby Interpreter & Debugging Tool

旧いダンプリストから - Togetter
MSX-BASICのソースってのが本で出てたんですよ。2万円くらいで…。
値段はさておき、そんなのあったんだ

tse - Text Stream Editor in Python - atsuoishimotoの日記

だれでもわかるそうです。 | OKWave

真・自然言語プログラミングの"the"演算子をClojureで - athosの日記

[Python-Dev] A new dictionary implementation

Permalink | View Entire Page

28 Jan ' 18:25

2012年01月28日

・電脳書房技術書BAR : ATND 行ってきました。

高橋会長とは入れ違いでした。他の参加者と話もしたかったんですが、バーのカウンターでしたんで離れた席の人には話しかけづらいしといって席を立って近寄るというのも…w 隣の人はちと話しかけづらかったんだよな(^^; 満席な状態が続いてたので席空けなきゃなあと考えて 18時ちょっと前に退散しました。

日曜日(29日)もあるのでお近くの人は行ってみてはいかがでしょうか (なんとなく今日に集中しちゃったような気もする)。

・ベイスターズこの辺の話を見聞きするとやっぱり上がどうしようもなかったという気になりますね (親会社が、じゃないよ?w) 【スギのみぞ知る】尾花前監督が初めて明かす“横浜の実像” - スポーツ - ZAKZAK 【スギのみぞ知る】尾花前監督が初めて明かす“横浜の実像” - スポーツ - ZAKZAK

んでまあ、ラミレスにしても全盛期は過ぎているしあれとかあれとかありますが、ホエールズからベイスターズになったときの駒田のような効果があればいいなという気はします。監督は…どうしたもんかw。どうにかしようという意欲は買えるんですがどうも
■_ 23 or 24?

clean code 原著で読んだときに気がつかなかったのは読みが甘いということだよなあと反省しつつ
Chapter I
Know Your Field

Here is a minimal list of the things that every software professional should be conversant with:

・Design patterns. You ought to be able to desribe all 24 patterns in the GOF book and
have a working knowledge of many of the patterns in the POSA books.

  
訳書でも同じで、「24個」のパターンとあるんですけど GoF のパターンって23個じゃなかったでしたっけ?
Design Patterns - Wikipedia, the free encyclopedia

Design Patterns: Elements of Reusable Object-Oriented Software is a software engineering
book describing recurring solutions to common problems in software design. The book's
authors are Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides with a foreword
by Grady Booch. The authors are often referred to as the Gang of Four, or GoF.[1] The
book is divided into two parts, with the first two chapters exploring the capabilities
and pitfalls of object-oriented programming, and the remaining chapters describing 23
classic software design patterns. The book includes examples in C++ and Smalltalk.

The original publication date of the book was October 21, 1994 with a 1995 copyright, 
and as of July 2010, the book was in its 38th printing. The book was first made 
available to the public at OOPSLA meeting held in Portland, Oregon, in October 1994. 
It has been highly influential to the field of software engineering and is regarded as 
an important source for object-oriented design theory and practice. More than 500,000 
copies have been sold in English and in 13 other languages.
とりあえず翻訳のほうでひとつ。原文の
Acknowledgments

My career has been a series of collaborations and schemes.
Though I've had many private dreams and aspirations,
I always seemed to find someone to share them with.
In that sense I feel a bit like the Sith, "Always two there are."
  
この「Sith」を訳書ではシス卿としてたんですが、卿はいるのかなあと思うのですけどどうなんでしょうか。でも詳しい人がレビューに参加してただろうしなあ (わたしはSWには詳しくありません)。

Sith - Wookieepedia, the Star Wars Wiki Sith Lord - Wookieepedia, the Star Wars Wiki
■_ GNU
関数型プログラミング言語Haskell Part17

416 デフォルトの名無しさん [sage] 2012/01/27(金) 12:06:04.37 ID: Be:
    ここで問われているのは、
    長年GNUがやってきたように、
    過去の他人の成果を丸パクリして、
    それでも使われるレベルになるのかどうか？
    ということだよな 
んーむそういう見方が多いのかなあ。最近は。
例の Emacs を Common Lisp で～の人の新しい記事。
The Cliffs of Inanity › Difficulties of elisp


Difficulties of elisp
Emacs Lisp の難しさ

The thesis that underlies my project to translate the Emacs C code to Common Lisp is that
Emacs Lisp is close enough to Common Lisp that the parts of the Emacs C code that implement
Lisp can be dropped in favor of the generally superior CL implementation.  This is
generally true, but there are a few difficult bits.

(以下略)
なんて一文が長いんだっw ＞最初のいくつ関係代名詞があるんだか
■_ \

Perl 6 の話。
WITCH hack / Perl 6

WITCH hack

Mnemonics

"backslash", "escape", "hack"

        used to "back out" of a syntax to a character's original meaning
        used to "hack" around, or "escape", special characters

When used inside a regular expression
正規表現中で使ったとき

\ in front of any character will change it from a metacharacter to a literal, or visa versa.
メタキャラクターをリテラルにしたりその逆をしたり

When used in a Signature
シグネチャーで使ったとき

\ before a name is a parcel binding.


Operators containing this character
バックスラッシュを含む演算子

Modifying a reduction operator such as [\+] (modification of [+]) creates a lazy feed of intermediary results..

[\+] のように (この場合は [+] の) reduction 演算子を修飾して
中間結果の lazy feed を作り出す

Other Uses

unary \ as a noun in front of an argument or arguments creates a Capture

\ in front of whitespace creates an unspace which is used to jam spaces in where they don't belong.

\o \c \x and \d used inside an interpolated string introduce literal characters

interpolate された文字列の内側にリテラルキャラクターを持ち込むのに使われる
[ ] の中の演算子に前置するとそういうことになるのかあ。って散々作例で見てきたような?
■_ Why I love Ruby (Part 1)

とりあえず Part I
Why I love Ruby (Part 1)

Why I love Ruby (Part 1)

So, it occurred to me that so far, my posts (both of them) have been pretty negative. So
I thought today, instead of ranting about something I detest, I’d rave about something I
love. And that something is Ruby. I looooove Ruby. I got into Ruby because of the Rails
web application framework, but my love of Ruby goes so far beyond Rails. Let’s start
with a quote from Yukihiro Matsumoto (Matz), the creator of Ruby:
■_ Why I love Common Lisp and hate Java

こっちは hate つき
Why I love Common Lisp and hate Java « Piece of mine

(略)

People say Common Lisp is difficult to learn, but I had more trouble learning Java. My 
first few spoons of Java were to memorize “public static void main(String args[])”, 
before I could start playing with some code. Oh and I forgot, you have to declare your 
class first. What is a class, and why so many lines, just to produce a simple “Hello 
World”? Programming sucks!
皆は Common Lisp が学ぶのには難しいものだと主張しますが、わたしは Java を学んだときに
もっとひどい目にあいました。わたしの first few spoons of Java は、
ちょっとしたコードでもって遊べるようになるよりも前に
“public static void main(String args[])” を覚えることでした。
おっと忘れていました。
最初にクラスを宣言しなければなりませんでした。
クラスとはいったいどういったものであり、
単に “Hello World”とするだけのためになぜあんなにたくさんの行があるのでしょうか。
Programming sucks!
■_ 七つのルール

ちょっと前の記事ですが
7 Rules for Writing Clojure Programs « Two Guys Arguing

#1 – Your brain will think in steps. It can't help it

#2 – loop/recur is not a code smell, but be suspicious of it

#3 – Transformations of lists, not recursion is key
     再帰ではなくリストの変形がカギ

#4 – Don't be lazy
     lazy であってはいけない

#5 – One liners are hard to read
     一行野郎は読むのが難しい

#6 – Use -> and ->> to make one liners easier to read
     一行野郎を読みやすくするために -> や ->> を使おう

#7 – Don't use -> or ->>
      -> も ->> も使ってはいけない
本文は見てのお楽しみ。
R をどうこうというときに名前の挙がる Numpy。
PyPy Status Blog: Py3k and Numpy First Stage: Thanks to all who Gave

Last year was quite successful for PyPy fundraising through the Software Freedom 
Conservancy, and Conservancy and PyPy are very excited to announce that enough was 
raised to begin the first stages on the Py3k and Numpy grant proposals.

As of the end of 2011, 135 different individuals gave to the Py3k campaign, and 114 to 
the Numpy campaign. We thank each of you who donated to help make this work possible. 
Meanwhile, if you haven't given to support these projects, we do hope you'll give 
generously now to help fund their second stages later this year!
■_ New implementation of Python regex

わたしは現状のも結構好きなんですが(速度的にはちと難があるみたいだからそれが動機?)、置き換えを狙ったものが
mrab-regex-hg - New implementation of Python regex - Google Project Hosting

A new regex implementation intended eventually to replace Python's current re module implementation.

For testing and comparison with the current 're' module, the new implementation is in the
form of a module called 'regex'.

Also included are the compiled binary .pyd files for Python 2.5-2.7 and Python 3.1-3.2 on 32-bit Windows. 
ML名古屋 - [PARTAKE]

Electric Magic | Portfolio | Smalltalk in Byte Magazine, August 1981

2012-01-28 - きしだのはてなネットワークに自信のない人は東大講義の情報工学概論Ａを見よう

この黒くて巨大な物体がまさか、4キロバイトのメモリーとは...！ : ギズモード・ジャパン

OSに付属するシェルスクリプトを読んで技術を盗む（1/2）－＠IT

Colorful Pieces of Game::ハドソンがファミコンに参入するまで（２）

「割込み」の名付け親 - Plan9日記

Innovation “D”: 「呪いの時代」のIT技術者

Enhancements to /GS in Visual Studio 11 - The Security Development Lifecycle - Site Home - MSDN Blogs

A Decades-Old Technique to Improve Programming Languages - Modern Perl Books for modern Perl programming

DVCSもBTSも知らない人達とScrumをやってみた。 - うさぎ組

【コラム】『MSDN』の歩き方 (67) 検索に頼らないセミナー情報の集め方 | エンタープライズ | マイナビニュース

Permalink | View Entire Page

Search the Site

Custom Search

09 Feb ' 09:47

08 Feb ' 10:43

07 Feb ' 11:10

05 Feb ' 12:38

04 Feb ' 16:07

04 Feb ' 01:47

02 Feb ' 02:23

31 Jan ' 14:38

29 Jan ' 10:51

28 Jan ' 18:25

Search the Site

Subscribe to Feed:

Webmaster Tools: