ときどきの雑記帖 濫觴編

■_

・戦力外
【戦力外選手リスト】／11月10日現在 - プロ野球ニュース : nikkansports.com を見ていたら、加藤武治投手（３３）や 那須野巧投手（２９）といった名前が。 加藤先生(教員免許を持っている)もベイスターズに入団して 中継ぎだったりクローザーだったり先発だったりといいように使われてたなあ。 クローザーを務めるには決め球が弱かった。 那須野は……なにもいうまい。

・れびう
Twitter / @kdmsnr: 『The Clean Coder』の翻訳レビューをし ... あ、これジュンク堂で見かけて買おうかどうしようか散々悩んだ本じゃないですか。 つい最近出た本でもなかったのか。 レビューには興味があるけど、むむむ。

■_ bison byacc kmyacc

コンパイラの構文解析（上向き）の習得 | OKWave の話。

実際のコンパイラコンパイラ読めば～ と思って、bison と byacc と kmyacc の大きさを比べたら kmyacc のあまりの小ささにびっくり仰天。 まあ前二つはドキュメントやら configure やらで容量が大きくなっている部分はあるのだけど、 実際の生成部を比べても kmyacc はかなりコンパクトだと思います。

もうちょっと詳しく読んでみますかね。

BYACC - BERKELEY YACC GNU Project Archives kmyacc - 多言語対応LALRパーサー生成系

■_ Why every language should have a glossary

用語集つけれ。という。

■_

で、Scala のそれの用語を抜き出すとこんなん。

Glossary - Scala Documentation

    * algebraic data type
    * alternative
    * annotation
    * anonymous class
    * anonymous function
    * apply
    * argument
    * assign
    * auxiliary constructor
    * block
    * bound variable
    * by-name parameter
    * by-value parameter
    * class
    * closure
    * companion class
    * companion object
    * contravariant
    * covariant
    * currying
    * declare
    * define
    * direct subclass
    * direct superclass
    * equality
    * existential type
    * expression
    * filter
    * filter expression
    * first-class function
    * for comprehension
    * free variable
    * function
    * function literal
    * function value
    * functional style
    * generator
    * generator expression
    * generic class
    * generic trait
    * helper function
    * helper method
    * immutable
    * imperative style
    * initialize
    * instance
    * instantiate
    * invariant
    * invoke
    * JVM
    * literal
    * local function
    * local variable
    * member
    * message
    * meta-programming
    * method
    * mixin
    * mixin composition
    * modifier
    * multiple definitions
    * nonvariant
    * operation
    * parameter
    * parameterless function
    * parameterless method
    * parametric field
    * partially applied function
    * path-dependent type
    * pattern
    * pattern guard
    * predicate
    * primary constructor
    * procedure
    * reassignable
    * recursive
    * reference
    * reference equality
    * reference type
    * referential transparency
    * refers
    * refinement type
    * result
    * result type
    * return
    * runtime
    * runtime type
    * script
    * selector
    * self type
    * semi-structured data
    * serialization
    * shadow
    * signature
    * singleton object
    * standalone object
    * statement
    * static type
    * structural type
    * subclass
    * subtrait
    * subtype
    * superclass
    * supertrait
    * supertype
    * synthetic class
    * tail recursive
    * target typing
    * template
    * trait
    * type
    * type constraint
    * type constructor
    * type parameter
    * type signature
    * uniform access principle
    * unreachable
    * unreferenced
    * value
    * value type
    * variable
    * variance
    * yield

Copyright © 2011 EPFL. All rights reserved.

■_

Mythology in C++: Exceptions are Expensive : programming Mythology in C

■_

• 『スティーブジョブズⅠ・Ⅱ』－誤訳の指摘: Buckeye the Translator
• なぜ絶版本が電子書籍になりにくいのか？ - さぼり記
• Adobeはなぜ失敗したか, Flash-Playerの敗退は歴史の必然だった
• Perl6でマンデルブロ集合さんを描く - 葡萄酒の雑記集 2.0（笑）
  今回ので解ったことは、「Perl6はまだまだ未完成、でも普通に他の言語で出来る事は出来なくもない」ってところですかね。
• ASCII.jp：極小だけど快適!?　イーモバの「Sony Ericsson mini」｜速くて便利！　実測でわかるモバイルデータ通信
• いよいよOffice互換ソフトも「リボン」の時代へ：井上健語「有料ソフトの“優良”度チェック」
• ruby trunk 33685 で hash.c の #define __sun な環境にメモリリーク（？）を見つけた話
• ～～なプログラマが読む(べきとかなんとかな)本のリストはだいたい無意味 - 猫的怠惰Days
• 時代を彩ったかつての名機たち(2)...ビジネス用途を最初から無視した暴れん坊X1 - Amazonの悪魔
• 2012年のLLイベントは8月4日
• 勉強会に参加し始めて変化したいくつかの事 - tmmkrの日記
• 時間城年代記:久々にスクリプトを書いた
  CSVファイルで、100-255までの数をランダムにシャッフルして10進数-16進数-2進数表記を並べて作る。
• PyPyのStringBuilderの処理速度を試す - yattの日記
• ソフトウェアの信頼性を根本的に高める「形式手法（Formal Method）」の本質 | IT Leaders
• Windows ServerからGUIが消える日 － TechTargetジャパン システム運用管理
  誰もがナインファイブ（99.999％）のサーバの可用性を求めているが、それを達成できているWindowsサーバは少ない。
• Five nines - Wikipedia, the free encyclopedia
• 知ったかぶりの先輩技術者への対応 | OKWave
• PEP 405 (proposed): Python 2.8 Release Schedule | Python | Dev
• 「出版、そして書籍の歴史が変わる重要な日」――楽天三木谷氏が明かすKobo買収の意図 - 電子書籍情報が満載! eBook USER

■_

[ruby-core:40863] Re: [ruby-trunk - Feature #5588] add negation flag (v) to Rege...
[ruby-core:40878] [ruby-trunk - Feature #5588] add negation flag (v) to Regexp
[ruby-core:40897] [ruby-trunk - Feature #5588] add negation flag (v) to Regexp
[ruby-core:40899] [ruby-trunk - Feature #5588] add negation flag (v) to Regexp
My current approach is to expand (?v:STUFF) into (?:(?!STUFF).) when the regexp AST is built.

■_

結構面白そうだけど結構量があるな

tour-de-babel - steveyegge2

Tour de Babel 

Stevey's Drunken Blog Rants™

This is my whirlwind languages tour — the one I was going to write for the Amazon 
Developers Journal this month, but couldn't find a way to do it that was... 
presentable.

For one thing, I lapse occasionally into coarseness and profanity here, so it wasn't 
appropriate for an official-ish Amazon publication. Instead, I'm stuffing it into my 
blog, which nobody reads. Except for you. Yep, just you. Hiya.

For another, it's really a work in progress, just a few snippets here and there, not 
polished at all. Another great reason to make it a blog entry. Doesn't have to be good, 
or complete. It's just what I've got today. Enjoy!

My whirlwind tour will cover C, C++, Lisp, Java, Perl, (all languages we use at Amazon), 
Ruby (which I just plain like), and Python, which is in there because — well, no sense 
getting ahead of ourselves, now.

C

You just have to know C. Why? Because for all practical purposes, every computer in 
the world you'll ever use is a von Neumann machine, and C is a lightweight, expressive 
syntax for the von Neumann machine's capabilities.

(略)

C++

C++ is the dumbest language on earth, in the very real sense of being the least sentient.
It doesn't know about itself. It is not introspective. Neither is C, but C isn't
"Object-Oriented", and object orientation is in no small measure about making
your programs know about themselves. Objects are actors. So OO languages need to have
runtime reflection and typing. C++ doesn't, not really, not that you'd ever use.

(略)

The Problem with C++ Templates

The Problem with C++ Templates

C++ has evolved as a language that encompasses many modern programming techniques. In 
this way, C++ has managed to stay relevant, despite the many issues that it may have 
compared to safer languages such as Java or C#. In C++, one can decide the set of 
features that will be used from within a large set of alternatives. If you’re 
inclined to do so, you could use only an strictly object oriented style, or maybe a 
functional oriented style, if that suits you better. Moreover, with the additions 
proposed in C++11, you can even use closures to make your coding style more functional.

(略)

Published on November 10th, 2011

Copyright © Carlos Oliveira · All rights reserved.
Powered by HostGator

■_

届いたーーーっ

…で、Rithcie day に買った pdf をこいつで読むにはどうすればよいの?

■_

• RubyConf Argentina/Uruguay 参戦記 2日目 - I am Cruby!
• 1956年 IBM704 用 FORTRAN I の例題。 - fortran66の日記
• ネット中毒、身近なところで進行中。 - マーケターの失敗録(T_T)
• 自動販売機の補充の方から「ありがとうございます」と言われて思ったこと。：一般システムエンジニアの刻苦勉励：ITmedia オルタナティブ・ブログ
• 岩波書店、ついに電子書籍に乗り出す――「新書」「ジュニア新書」を電子化 - 電子書籍情報が満載! eBook USER
• ギークとスーツの素敵な関係：第1回　ギークはスーツが嫌いで，スーツはギークがわからない？｜gihyo.jp … 技術評論社
• 誠 Biz.ID：防災・防犯ラボ：1年間乗って気付いた自転車の意外な効用 (1/2)
• パソコン甲子園2011 本戦 - aizuzia
• マイクロソフト セキュリティ情報 MS11-083 - 緊急 : TCP/IP の脆弱性により、リモートでコードが実行される (2588516)
• The Codist Am I Too Old To Be A Programmer?
• The Codist 10% Coding and 90% Thinking or Just Code It 10 Times
• Creating a Dynamic Method that uses a Switch | Filip Ekberg's blog
• The Codist Am I Too Old To Be A Programmer?
• Mark Jason Dominus on giving fish - Perlbuzz
• Macro grant accepted :: Strangely Consistent
  I haven't blogged much lately, and I suspect it might be because my blogging plans are too ambitious to fit in my fragmented schedule. So I'll stop here. 時代を彩ったかつての名機たち(1)...6809の良さを素直に味わえた名機FM-7 - Amazonの悪魔

■_

サブルーチンについて調べていたこんな時間に!

■_

寝る

■_

しばちゅーさん怒涛の展開(違)

監督に桑田。ねえ。 コーチ経験もなしにいきなりってのが気になるんだよなあ(やるとしての話だけど)。 落合みたいにこれ以上ないほど結果を出しちゃった人もいますけどね。

■_ フラグの提案

割と面白いと思った。

[ruby-core:40824] [ruby-trunk - Feature #5588][Open] add negation flag (v) to Regexp

Issue #5588 has been reported by Suraj Kurapati.

----------------------------------------
Feature #5588: add negation flag (v) to Regexp
http://redmine.ruby-lang.org/issues/5588

Author: Suraj Kurapati
Status: Open
Priority: Normal
Assignee:
Category:
Target version:


Please add a negation flag (v) to regexps which inverts them:

 "ruby" =~ /perl/v       #=> true   (turn on negation)
 "ruby" !~ /perl/v       #=> false  (turn on negation)
 "ruby" =~ /(?v:perl)/   #=> true   (turn on negation)
 "ruby" !~ /(?v:perl)/   #=> false  (turn on negation)
 "ruby" =~ /(?-v:perl)/  #=> false  (turn off negation)
 "ruby" !~ /(?-v:perl)/  #=> true   (turn off negation)

The flag name "v" comes from the ex(1) command of the same name.

This has beneficial applications where it is sometimes difficult
to construct what you want to match but much easier to construct
what you *do not* want to match.  Having this negation built in
the regexp itself would remove the need for us to change our
Ruby code to process a regexp in a different way.

For example, suppose that you are passing a regexp to the `--name`
command-line option of MiniTest.  This regexp tells MiniTest to
only run those tests whose names match.  If Ruby had a negation
flag on its regexps, then it would be suddenly trivial to make
MiniTest skip certain tests by negating the regexp we pass in.

In this manner, we get a beneficial feature without ever changing
our Ruby code (the codebase of MiniTest in this example).  :-)

Thanks for your consideration.


--
http://redmine.ruby-lang.org

Issue #5588 has been updated by Suraj Kurapati.


Note that I am not asking for the ability to take an arbitrary regexp and construct its
negated form (that is a hard problem).  Instead, I am asking for a flag that simply inverts
how a regexp is treated by the =~ and !~ operators (this is not a hard problem).  The
negation flag should not change the Regexp#source of a regexp.

Thanks for your consideration.

It is not to hard to negate a regexp, though. Simply wrap it as negative look-ahead.

Konstantin

Issue #5588 has been updated by Suraj Kurapati.


Good idea, but negative lookahead isn't the same as negation:

$ irb
## ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-linux]
>> "rubyperl" =~ /(?!perl)/
0
>> "rubyperl" =~ /perl/
4
>> "rubyperl" !~ /perl/
false

Thanks for your consideration.

Issue #5588 has been updated by Yukihiro Matsumoto.


How do you treat positional information with v flag?

Issue #5588 has been updated by Alexey Muranov.


I would suggest to deal with it a new (sub)class instead: arbitrary boolean combinations of
regexps, without regard for positional information.

Issue #5588 has been updated by Suraj Kurapati.

Hello Matz,

What do you mean by positional information:

* anchors (\A, ^, $, \G, etc.) ?
* capture-group numbers ($1, $2, $3, etc.) ?
* MatchData#begin, #end, #offset ?

The v flag should only affect the low-level =~ and !~ operators in the C implementation.
All subsequent processing should be performed as normal.

Thanks for your consideration.

面白いっちゃあ面白いんだけど、どうかなあ。 たとえば正規表現の一部分で (?:v...) とか来たときの動作ってどうなるん?

■_ 御大のお言葉

どこでの発言だろう?

The Codist

Donald Knuth Rocks
Published: 11/07/2011

    As to your real question, the idea of immediate compilation and "unit tests"
    appeals to me only rarely, when I'm feeling my way in a totally unknown environment and
    need feedback about what works and what doesn't. Otherwise, lots of time is wasted on
    activities that I simply never need to perform or even think about. Nothing needs to be
    "mocked up." - Donald Knuth, article

A lot of people today would argue with him on this. I, for one, think Dr. Knuth has a clue.

さすがは Knuth といったところでしょうか。 The Art of Computer Programming でサンプルコード書くのに使っているのも アセンブリ言語(MMIX)だしな!

■_ D

ひょっとして、Dr Dobb's で結構記事書いているのかな＞うぉるたん

Type Qualifiers and Wild Cards | Dr Dobb's

Type Qualifiers and Wild Cards

November 07, 2011


Type qualifiers are modifiers applied to data types. The most useful one in D is the 
immutable qualifier,

(略)
  int func(immutable(int)* p) {
    return *p + 7;
  }

(略)

  int func(const(int)* p) {
    return *p + 7;
  }

(略)

  const(int)* func(const(int)* p) {
    return p;
  }

That doesn't really work. An identity function should return the same type that it was 
given, not that type converted to const. What about using templates? We can write:

これは実際にはうまくいきません。identity 関数は与えられたものと同じ型を返すべきであって
const に変換した型を返すのではありません。
テンプレートを使ってはどうでしょうか?

  T func(T)(T p) {
    return p;
  }

which will solve the problem, won't it? T can take on int*, const(int)*, and 
immutable(int)*. Sure, for that function and similar ones. But template functions:

このように書くことができ、問題を解決するでしょう。違いますか?
T は int*、const(int)+、immutable(int)* を受け付けます。
Sure, for that function and similar ones.
しかしテンプレート関数では

   1. Can't be used for virtual functions
      仮想関数に対しては使えない

   2. Can't be used for a binary interface
      バイナリインターフェースに対しては使えない

   3. Will generate multiple copies of a function that are the same except for the type
      signature (arguably, this should be fixed by better compiler technology)
      同じ型シグネチャを期待する関数の複数のコピーを生成してしまう
      (ただしこれはより優れたコンパイラー記述によって解決できるでしょう)

But worse, consider:

(略)

■_

何年か前のインタビュー記事でなぜか盛り上がる。

Donald Knuth on Open Source, Multicore, and why Literate Programming never took off : programming

Stop giving interviews and get back to writing the next book!

I am, of course, joking. Knuth has an almost monastic dedication to his magnum opus 
and it's good to see he can drag himself away to share a few thoughts. (Although this 
article dates from 2008; hopefully there is newer news somewhere.)

    Although this article dates from 2008; hopefully there is newer news somewhere.

Post a submission to Reddit that is newer than 2008? Only if it was created in the 
last hour. I am already being called a Evil Spammer for reposting things that were 
posted three years ago. God knows what they will do to me if I post something from two 
years ago... :)

インタビュー受けてないでとっとと本を書けとはｗ

■_

• タンブラーとは - Lispが永遠に勝てない理由
• ORGANIZATION PROGRAMMING AND APPLICATIONS (PDP-11） 電脳羊（Android Dream）/ウェブリブログ
• Wataru's memo(2006-06-05)
• PHP vs. RUBY: What’s the Point? » RubySource
• 2011-11-08 - 未来のいつか/hyoshiokの日記
• Open Recursion in scala もしくは関数型もオブジェクト指向も仲良くしようよぉのお話 - ろじかるんるんものがたり
• seekR - 統計分析プログラミング言語 R のための検索エンジン
• Intel64 and IA-32 アーキテクチャ仕様書が改訂 - 教育は参考資料
• Programming With Nothing // Speaker Deck
• RubyConf Argentina/Uruguay 参戦記 1日目 - I am Cruby!
• PyPyのStringBuilderの処理速度を試す - yattの日記

■_

なんかもーぐだぐだっすよー

■_

関数型プログラミング言語Haskell Part16

377 デフォルトの名無しさん [sage] 2011/11/06(日) 02:49:06.58 ID: Be:
    Haskellの変数の有効範囲って何か具体的に決まっているのかな？
    Haskel Reportを読んでもはっきりと書かれていないような。

    以下のように関数(>>?)を定義してvalue1, value2を求めると
    value1は普通に求められるが、value2は\s -> s + aのところで
    aが未定義ですとか言われる。

    括弧があると変数の有効範囲が変わるのかな？

    (>>?) :: a -> (a -> b) -> b
    v >>? f = f v

    value1 = (1, 2) >>? \(a, b) -> b >>? \s -> s + a
    value2 = (1, 2) >>? (\(a, b) -> b) >>? \s -> s + a 

378 デフォルトの名無しさん [sage] 2011/11/06(日) 05:53:55.40 ID: Be:
    >>377
    関数の仮引数の有効範囲はその関数本体というのが基本原則。

    > value1 = (1, 2) >>? \(a, b) -> b >>? \s -> s + a
    は
    value1 = (1, 2) >>? (\(a, b) -> b >>? \s -> s + a)
    と解釈されるのでs + aは\(a,b) -> ...の関数本体内に含まれるが

    > value2 = (1, 2) >>? (\(a, b) -> b) >>? \s -> s + a
    はかっこがあるため含まれない。 

379 デフォルトの名無しさん [sage] 2011/11/06(日) 13:47:42.37 ID: Be:
    >>378 ありがとう。
    メタルールか。なんとなく理解した。 

380 デフォルトの名無しさん [sage] 2011/11/06(日) 16:49:56.15 ID: Be:
    スコープが見て分かるように()つけまくってるとlisp化してしまうという罠 

381 デフォルトの名無しさん [sage] 2011/11/06(日) 18:32:21.28 ID: Be:
    >>380
    そのための＄です
    意外とLisp化食い止められてない気がするけど… 

382 デフォルトの名無しさん [sage] 2011/11/06(日) 18:33:01.25 ID: Be:
    そう？

    少なくとも )))) はだいぶ消えると思うけど。 

383 デフォルトの名無しさん [sage] 2011/11/06(日) 19:07:40.41 ID: Be:
    最近は()が多少増えても別にいいかなと思うようになってきた。 

384 デフォルトの名無しさん [sage] 2011/11/06(日) 20:02:50.82 ID: Be:
    >>382
    逆に言えば、そこにしか効果ないんよ

385 デフォルトの名無しさん [sage] 2011/11/06(日) 20:50:27.44 ID: Be:
    いいじゃん
    HaskellはLispの飼い猫なんだし 

386 デフォルトの名無しさん [sage] 2011/11/06(日) 20:56:34.75 ID: Be:
    昔、BASICしか知らないガキだったころ、Lispのコードを見てびびったのって
    )))) って何これ、ってことだったので、それが緩和されるというのは俺にとっては
    大きいw 

387 デフォルトの名無しさん [sage] 2011/11/06(日) 22:02:11.57 ID: Be:
    >>385
    飼い猫ちゃう
    Haskellは汎用関数型決戦兵器や
    Lispは・・・深海型やな

388 デフォルトの名無しさん [sage] 2011/11/06(日) 22:02:17.97 ID: Be:
    確かにBASICerにとって$は友達だもんな 

389 デフォルトの名無しさん [sage] 2011/11/07(月) 00:04:02.33 ID: Be:
    っつーかお前らよく結合順序とか読みきれるな
    俺どんな言語で書いても表見ないと安心できない
    そのうち面倒くさくなってきてlisp化しちゃう 

390 デフォルトの名無しさん [sage] 2011/11/07(月) 00:16:22.77 ID: Be:
    >>389
    算数・数学の結合順序とほとんど同じだろ？
    覚えるって程のことかいな。
    微妙に分からんところは（）で明示すればいいし。

391 デフォルトの名無しさん [sage] 2011/11/07(月) 00:29:24.10 ID: Be:
    >>389
    最初はそんなんだったけど慣れた。
    でもちょっと不安な所は、()だらけ。 

392 デフォルトの名無しさん [sage] 2011/11/07(月) 00:31:14.84 ID: Be:
    直感とずれるのは関数合成くらいかな。
    あれだけはいつもかっこつけてる。 

393 デフォルトの名無しさん [sage] 2011/11/07(月) 01:24:33.49 ID: Be:
    迷ったら付ける 

394 デフォルトの名無しさん [sage] 2011/11/07(月) 01:35:26.66 ID: Be:
    >>392
    そうか？
    ＄使えるところは関数合成できるから、ghciでlet使って試し書きする時は、＄使って、
    ソースに書いてghciでテストする時にソースに$を関数合成に変えたものを書いてる。
    (ghci上で直に定義するときは何故か関数合成できない）

397 デフォルトの名無しさん [sage] 2011/11/07(月) 08:10:41.16 ID: Be:
    結合順序間違ってるとたいてい型エラーでるし、
    そしたら:iで確かめたらいいし。 

■_ キャミバさまの嘆き

Twitter / @camloeba: 丁寧に書かれた文章で、訳もまあまあなのに、先入観から ...

丁寧に書かれた文章で、訳もまあまあなのに、先入観から読み違えてる人が多い。
元論文判が出たときもそうだったが。 d.hatena.ne.jp/ymotongpoo/tou…
なぜ次に学ぶ言語は関数型であるべきか

元記事見覚えあるなあと思ったら、9月末頃に Hacker news で話題になってたのを見てたw

• なぜ次に学ぶ言語は関数型であるべきか - YAMAGUCHI::weblog
• OCaml For the Masses - Slashdot
• OCaml for the Masses : programming
• "OCaml For the Masses" article on Slashdot : haskell
• OCaml for the Masses - ACM Queue
• OCaml for the Masses Hacker News

slashdot と reddit でもネタにされてたか。

■_

先を越されたのでボツ。

■_

Twitter / @ShimadaShunsuke: C言語は偉大な発明だと思うけど、それ以前にメモリスタ ...

C言語は偉大な発明だと思うけど、それ以前にメモリスタックを使ってサブルーチンを呼び、
再起を可能にするという手法がすであったはずで、その手法そのものが凄すぎる。
しかし、この手法を発明した人の名前を聞いたことがない。その大偉人の名は伝わっていないのか？

サブルーチンの発明はウィルクス(要確認)だと思うけど、 最初期のサブルーチン呼び出しって、自己書き換えやらなんやらで再帰呼び出しはできなそう。 IBM 704 (Lisp の最初の処理系が載ったアレ)のアーキテクチャってどんなんだっけ (IBMのだからハードウェアスタックはないはず)。

■_

Twitter / @isologue: 高１の息子がCで実装したLISPのインタープリター、 ...

高１の息子がCで実装したLISPのインタープリター、数十秒かかるベンチマークの竹内関数の問題が、
Gaucheだと一瞬で終わる、と実力の差を見せつけられてショックを受けてますなう。

簡単に Gauche レベルのものを書かれても困るけど(^^;、 そのショックを踏み台にして精進して欲しいですね(偉そう)。

このあとのツイートを見るに前向きにやっているみたいですね。

■_

• 【105円】スマホの液晶保護フィルムを、気泡なしで貼る小ワザ：中村昭典の、気ままな数値解析：ITmedia オルタナティブ・ブログ
  嫌が上でも緊張感が高まります
• いやがうえに【弥が上に】の意味 - 国語辞書 - goo辞書
• 【新連載】戦略が確実に実行され、業績が上がる組織の動かし方：戦略は実行しないと意味がない (1/2) - ITmedia エグゼクティブ
• 『ローカリゼーションの視点から日本製品の海外進出戦略を考える』 : ATND
• ブックメンテナンス秋葉原店 - ブックメンテナンス秋葉原店 オフィシャルホームページ　本を断裁・スキャンしての電子化（自炊）、研磨、製本など書籍保全サービスやってます
• ブックメンテナンス秋葉原店のブログ
• 「押井守はいかにすごいのか」を語った希有馬氏が語る「押井守はいかにくだらないか」というお話が語る「押井守はいかにくだらないか」というお話 - Togetter
• 書評：「孫子」　唯一無二の戦略指南書は、とりあえず100回読んで損はない - 書評人(The Reviewers)
• 2011-11-07 - kikairoyaの日記
• “王者IE”に挑み続けた反骨の母 － ＠IT情報マネジメント
• マイクロソフト、「Duqu」に悪用された脆弱性について情報公開 － ＠IT
• Ma.k.ファイアボール アクションモデル BASIC PAINT ver. :おた☆スケ -おたくのスケジュール帳-
  むかーしのホビージャパンにこういうの使った連載があったような
• 再び MagLev と Matz Ruby (Ruby1.8)、YARV（Ruby1.9）を戦わせてみる - Smalltalkのtは小文字です
• Boost.勉強会 #6 札幌で喋ってきた話というか関数が純粋で静的に強く型付けられていることの重要性というかプログラムを計算する話 - 梶本裕介の日記
• Linuxのxargsには--no-run-if-empty付けとけ - あーありがち(2011-11-07)
• RubyConf Argentina/Uruguay 参戦記 0日目 - I am Cruby!
• Perl regex escapes by version of their introduction — Gist
  (*ほげほげ) ってのはないのね。
• wrong, rogue and log : Kindle版Rational Decisionsは読めたものじゃなかった
• ruby-trunk - Feature #5583: Optionally typing - Ruby Issue Tracking System
• Dodgy Coder: StackOverflow's Programming Language Bias
• Ángel Ortega: Unicode, UTF-8 and all that: An intentionally incomplete character set introduction for hasty C programmers
• Java is not the new COBOL | Craig Tataryn's .plan

■_

好きな帯(腰巻き)

こういう煽り文句は大好物なので。

嫌いな帯

表紙の差し替えと大差ないレベル。 というか、ハードカバーのほうで 「ハンニバル戦記」なのに表紙の写真にハンニバルじゃなくて、 スキピオ・アフリカヌスを使った理由書いていたはずなんだけどなあ (ざっと読み返したけど見つからなかった。記憶違いではないと思うんだけど)。
ローマ人の物語〈2〉― ハンニバル戦記

本の帯（腰巻き）について教えてください。 - 書籍・文庫 - 教えて！goo

■_

間に合わなかったので先送り

■_ 続き

とあるはてダを英語に翻訳して…の続き。 今回も結構 reddit で伸びてますね。 Global Voices » Japan's IT Exodus: A Personal Perspective (Part 2) · Global Voices » Print Agile vs Waterfall: A Japanese perspective : programming

■_ 語呂合わせ

これにもあったのか!w

課題ででたのですがやり方が今一わかりませんやり方教えて下さい(__) 16ビットで... - Yahoo!知恵袋

課題ででたのですがやり方が今一わかりませんやり方教えて下さい(__)

16ビットで小数点がMSBの右端にあるとき表現できる数値を数直線で表せ。
32ビット浮動小数点表現で表現て゛きる数値を数直線で表せ。

これってどういうことですか？
解説やり方教えていただけると助かります

ベストアンサーに選ばれた回答

(略)

IEEE方式で32ビット浮動小数点数の場合、符号部は1、指数部は8、仮数部は23ビットで表されています。
そこで、正の最大値の内部表現は

0 11111110 11111111111111111111111

となります。指数部が11111111はオーバーフローしたことを表すのでそれより１つ小さい数までしか入りません。
指数部は、1111111 つまり16進数なら7F、10進数なら127ゲタをはいた（一律に127を足した）数になっています。
また、仮数部は、1.XXXXXX…X の形に正規化すれば先頭ビットは必ず1になるので、その1は隠れビットとして
仮数部には含めません。XXXXXX…X の部分の頭から23ビットが仮数部に入ります。

そこで、正の最大値は

1.111…1×2^(FE-7F)≒2×2^127≒3.402823×10^38

になります。0.0 でない正の最小値は、

1.000…0×2^(1-7F)≒1×2^(-126)≒1.175494×10^(-38)

になります。そこで数直線には、

-3.402823×10^38, -1.175494×10^(-38), 0.0, 1.175494×10^(-38), 3.402823×10^38

の５つの点を明記すればよいということになるでしょう。

ちなみに、私は次のごろ合わせでこれらの数を記憶しています。
3.402823×10^38：見てよれ、にやけた兄さん。爺さん婆さん
1.175494×10^(-38)：ひどいな強欲よ。爺さん婆さん

Copyright (C) 2011 Yahoo Japan Corporation. All Rights Reserved.

知らなかったw ＞にやけた兄さんとか

■_ 課金

「無料の携帯ゲーム、アイテム課金などで毎月１０万、計３００万円使った」…課金したことある人は約４割 : SIerブログ

「無料の携帯ゲーム、アイテム課金などで毎月１０万、計３００万円使った」…課金したことある人は約４割 : SIerブログ

6 ：名無しさん＠１２周年：2011/11/04(金) 11:03:50.79 ID:QV4P2JEdP



「課金したことある人は約４割」

？？？

課金されたことがある人じゃないのか？


41 ：名無しさん＠１２周年：2011/11/04(金) 11:48:13.18 ID:ggPmSn940

>>6

だよね

この前月２万払ってる人がTV出てたけど

その人も「今課金しました」って言ってたな

スレッドのほかの人の反応見ると、自分がお金取られるのを課金「する」と いう人やっぱり多いのね。すげーきになるのだけど。

課金 - Wikipedia

備考 [編集]

    * 料金を課す、つまり「費用や支払いを引き受けさせる」のであり、ユーザーが料金を支払った
      意味で使用するのは誤りであるが、黎明期のオンラインゲーム利用料金決済を発端として誤用
      が広まり、今もって正しくない言葉のまま使う人が多い。さらに近年では、事ある毎に利用者
      の射幸心を煽り、納金させようとする悪徳企業によるソーシャルゲームの台頭により、利用者
      どころかサービス運営者、ゲームコンテンツ提供者までもが誤用しているケースが多々見られ
      ている。

    * Blu-ray課金やiPod課金は、私的録音録画補償金制度のうちBlu-rayやiPodを対象としたものの
      俗称であり、サービスの対価として料金を課すわけではないため一般的な意味での課金とは異
      なる。

かきん【課金】の意味 - 国語辞書 - goo辞書

きっとつらつらぐさの中の人が何か書いてくれるだろう。 DirectWrite対応: つらつらぐさ

■_ ↑

そんな都合のいいものないと思うけどどうなんでしょ。

コンパイラの構文解析（上向き）の習得 | OKWave

コンパイラの仕組みについて興味があり勉強しています。

構文解析について下向きの再帰降下法についてはコンパイラの入門書などにも説明があり、
簡単なものであれば自分でコードを書けるレベルになりました。

次にyaccなどに使用されているという上向きの構文解析法（LR/SLR/LALR等）を学びたい
と思いましたが、良い資料が見つかりません。

具体的には理論の説明（集合の式等が理解しにくいです）だけではなくて、簡単な式な
どを評価するソースコードや実際の動作が解説されているものがあれば嬉しいです。

ネット上あるいは市販の3000円台程度の書籍で良いものがありましたらご紹介いただけ
ると嬉しいです。

よろしくお願いします。

ANo.1

1. GNUによるyacc実装のbisonのドキュメントには
　　簡単な電卓や関数電卓の完全な例があります。
　　ソースコードはringサーバーやGNU本家から自由に入手できます。

2. あとは、青木峰郎さんの『Rubyソースコード完全解説』第2部が
　　Rubyの構文解析について扱っています。参考URLで公開されています。

3. 同じく、青木さんのRubyによるyacc実装のraccも参考になるかと。
　　古書で探せばraccの256倍本も手に入るかもしれません。
　　これはかなりカジュアルなyacc入門書です。

4. 青木さんの『ふつうのコンパイラをつくろう』はJavaで
　　Cのサブセットを実装しています。

5. 今のところ日本で出版されたHaskell関係の本では
　　全てで何らかの構文解析を扱っているように思います。

お礼

ご回答ありがとうございます。

念のための確認なのですが私の質問の趣旨は、yacc(racc)の使用方法ではなくて、yacc等で採用
されているらしい上向き構文解析（LR法など）の仕組みの理解です。

ご提示いただいた項目でその理解は可能でしょうか？

『raccの256本』や『ふつうのコンパイラをつくろう』では、コンパイラ・コンパイラの内部動
作についての解説は無かった様に記憶しております。

たしかにyaccやbisonのソースを見て理解という方法もありますが、今の私には敷居が高いです。

kmyacc のソースなんかいいんじゃないかな。コードを読むなら。 「yacc」のソースってどの yacc のことを言ってるのかよくわからんけど。

■_

The Code Dump » Blog Archive » Stepping Up: Do the Pre-Commit Skim - A place a coder rants at…

The Code Dump

Stepping Up: Do the Pre-Commit Skim

I'm always looking for the easiest way to make my code better, or to train myself to 
pay more attention to the quality of the code I produce. My latest find is quite 
obvious yet so very powerful I had to share. Simply put, it's just going over your 
code once more before a commit.

常にわたしは自分のコードをよりよくする一番簡単な方法や
自分が書いたコードの質に対してもっと注意を払うようになる方法といったものを探し求めています。
わたしが最近見つけ出したものはとても明確でありながら非常に強力なものであるので
共有しければなりません。
Simply put, it's just going over your code once more before a commit.


Every once in a while, I commit code and forget to add a file. Even worse, I sometimes 
leave around dead code that I really hate. I've found out that simply making a mental 
note to go over every file I changed before making a commit makes a big difference. It 
seems like the Boy Scout Rule from Clean Code is a special case of this rule.

コードをコミットしてもファイルの追加を忘れてしまう
死んでいるコード (dead code) を放置してしまうこともある


The trick is to simply go over every file you've changed and look for common pitfalls:

Unused code – Are there methods your changes just made obsolete? Maybe a conditional 
with an “else” clause that can no longer happen? Delete code! It's the best code 
you'll write today!

使われていないコード
時代遅れにしただけの変更をしたメソッドがありませんか?
もはや起こりえない "else" 節を伴った条件判定はありませんか?
コードを削りましょう!
あなたが今日書くコードがベストなコードなのです!

Zombie code – Did you start with something that was too complex and is no longer 
needed? Often in retrospect you can see how to simplify something and spare your 
colleagues the woes of zombie code.

ゾンビコード
複雑すぎでもう必要のないなにかから始めていませんか?
振り返り (retrospect) をすると、頻繁に単純にする方法や
spare your colleagues the woes of zombie code
を見つけ出せるでしょう。

Overdue refactoring – Look at your changes. Are you pushing a method too far? Maybe 
making a class too bloated? Maybe it's time to for some cleaning.

行き過ぎたりファクタリング
変更点に注目してください。
ひとつのメソッドに押し込めすぎてはいませんか?


Do you have a better name for it now? Sometimes when you start with something you 
don't have a great name for it. After finishing it, you might be able to slap a better 
name on that class that will make it more obvious to everyone.

もっといい名前がありますか?


Any dangling TODOs? I hate committing TODOs unintentionally.

Make sure it's all coherent in class-level – Some changes make sense when you're 
knee-deep in a change. But step back and make sure it all still makes sense.

© 2011. The Code Dump. All rights reserved. Powered by WordPress & SimpleX theme.

■_ 銘

誤字だと思うけどなんか気に入ったw ＞無銘関数

【訃報】LISP言語とA.I.の父 ジョン・マッカーシー（John McCarthy）博士
152 名無しのひみつ [sage] 2011/11/05(土) 03:04:52.83 ID:QgGfAblZ Be:
    分かり辛いので一回しか使わないちっこい関数をdefunで作りまくったら手続き型言語に毒されてると言われた。
    ちっこい関数一個ずつデバッグした方がいいと思うんだけどLISP使いには気に入らない模様。
    LISPらしいコーディングってみんなCでいう変態一行プログラムのような異形だと思う。 

153 名無しのひみつ [sage] 2011/11/05(土) 06:47:28.91 ID:7XcBh8qR Be:
    >>152
    関数プログラミングとしてあなたが正当だよ。そのLispの経験がある人
    はLisperとは言えないと思ったかな。少なくともセンスはない人だから
    無視すればいい。 

154 名無しのひみつ [sage] 2011/11/05(土) 06:51:40.68 ID:7XcBh8qR Be:
    clにはtraceが用意されていて、それを使って効率よくデバッグするとなると
    152のような方法が一番いい。更に最適化するときはインライン化させること
    も後で可能なので。この辺はhyperspecでtrace,inlineを調べてみてね。 

155 名無しのひみつ [sage] 2011/11/05(土) 15:06:46.35 ID:SSgRy9kJ Be:
    >>152
    ちっこい関数が無銘関数ならいいんじゃないかな
    汎用性のあるちっこい関数ってあんまりないっしょ？
    ＣＬならネームスペース内ローカル関数だと思うけど、大きくなりがちな関数を眺望しやすく
    するために名前つけてるだけだったりするじゃん。

■_

• .NET系のソケット通信の件 <4> [今までの経緯] <3> http://detail.chiebukur... - Yahoo!知恵袋
• .NET系のソケット通信の件 [今までの経緯] <1> http://detail.chiebukuro.ya... - Yahoo!知恵袋
• .NET Socket クラスの非同期送受信について - Yahoo!知恵袋
• C#とTCP/IPを利用したサーバープログラム（複数クライアント対応） - Yahoo!知恵袋
• さよならWindows XP：Windows XPが招く「最悪のシナリオ」 - ITmedia エンタープライズ
• Lock-freeデータ構造で使用されるABA避けカウンタについて - Togetter
• サイエンスの楽しみ方 | 今日も脳天気
• 続・サイエンスの楽しみ方 | 今日も脳天気
• 第二回Scala会議 - [PARTAKE]
• 電子書籍のＤＲＭで誰が困る事になるのか: この電子書籍ください
• PHP のよいところとよくないところ - id:k-z-h
• Python のリストをソートするアルゴリズムを実装し、標準で用意されているソートと速度比較をしてみた - 集中力なら売り切れたよ
• Debugging the Linux kernel with JTAG（翻訳） 電脳羊（Android Dream）/ウェブリブログ
• ハンニバル・やる夫・バルカスがローマに喧嘩を売るようです 第一章 ハンニバル・やる夫・バルカス - 私撰やる夫まとめブログ
• Ｃ言語とかでよく標準入出力とか聞きますが、この標準とは何のことですか？ 何に対... - Yahoo!知恵袋
• Agile vs Waterfall: A Japanese perspective : programming
• practicing-programming - steveyegge2
• hirax.net::「Wolfram CDF PlayerをMathematicaとして使う方法」をRubyでもっと簡単にしてみた
  しかし、そんなMathematicaの「玉にキズ」な点が「お値段」です。Mathematica を趣味で使う人たちのために 295ドルで「Mathematica ホームエディション」が発売されています。今の円相場なら295ドルは２万３千円ほどになり そうなものですが、残念ながら、日本では（消費税を含めて）７万３５０円とかなりのお値段になってしまいます。
• [Start] (スタート) 画面についていただいたコメントを振り返る - Building Windows 8 - Site Home - MSDN Blogs

■_

入門書
なんのかんの言って、「プログラミングの入門書」で使っている言語は C が減ってきて Java が増えている? まあ、Java でも文句言う人はいるんだろうけど (実際どうなのか検証したいなあ)。

某大型書店に行ったら、ジョブズ関連で棚一つ埋めててちょっとびっくりしたのですが、それはそれとして、

が面白そうだなあと思って買おうとしたのですが、 棚に置かれたそれは4500円くらいの値段がついていたのに対して Amazonさんだと3200円。 実物を見られる場所はないと困るということで買っていきたかったのですが この差を見てはにんともかんとも。 つーことで、差額くらいの本を一冊余計に買って帰りました。

歴史群像
いや、今回も面白かった。 隔月刊なのが残念だけど、月刊じゃあこの質と量は無理だろうなあ。 一時期季刊だったことを考えれば、隔月刊でもありがたい。 1ページものの連載で「信長の独断」というのがあるのですが、 これがなかなか良いです。毎回戦国武将を一人とりあげて、 その人に「似ている何か」を当てはめるといった感じのコラムなのですが たとえられるのが人に限られてなくて、 確か過去にはカワサキのバイクに喩えられた武将もいたはず(思い出せないけど)。 今回とりあげられた武将は上杉景勝。 何に喩えられえたかは…

■_ Dennis Ritchie and John McCarthy

エコノミストの記事になるというのはすごいなあと素直に関心。 Dennis Ritchie and John McCarthy | The Economist

Dennis Ritchie and John McCarthy | The Economist

(略)

C fundamentally changed the way computer programs were written. For the first time it 
enabled the same programs to work, without too much tweaking, on different machines; 
before, they had to be tailored to particular models. Much of modern software is 
written using one of C's more evolved dialects. These include objective C (which Apple 
favours), C# (espoused by rival Microsoft) and Java (the choice for a host of internet 
applications). Mr Ritchie and his life-long collaborator, Ken Thompson, then used C to 
write UNIX, an operating system whose powerful simplicity endeared it to the operators 
of the minicomputers which were starting to proliferate in universities and companies 
in the 1970s. Nowadays its iterations undergird the entire internet and breathe life 
into most mobile devices, whether based on Google's Android or Apple's iOS.

Mr McCarthy has had less direct impact. That is partly because he believed, wrongly, 
that minicomputers were a passing fad. In the early 1950s, while at the Massachusetts 
Institute of Technology (MIT), he pioneered “time-sharing”, by which multiple users 
could work on a single mainframe simultaneously. Mr Ritchie, who moonlighted as a 
mainframe operator at MIT while a graduate student at nearby Harvard, also dabbled in 
time-sharing. Yet unlike his younger colleague, whose UNIX spurred the development of 
mini- and later microcomputers, Mr McCarthy always argued that the future lay in 
simple terminals hooked up remotely to a powerful mainframe which would both store and 
process data: a notion vindicated only recently, as cloud computing has spread.

■_ RAII is Overrated

ぺた。

RAII is Overrated


Software & Engineering

by Carlos Oliveira

RAII is Overrated
RAII は過大評価されている

In most discussions of the advantages of C++, an item that is frequently raised is the 
support for automatic destruction. This mechanism, which is used to reclaim resources 
used by a single object at the end of its scope, is the basis for a programming style 
popularly known among C++ users as RAII (resource acquisition is initialization).

C++ の advantages に関する議論のほとんどにおいて、頻繁に話題となるのが自動破棄 (automatic
destruction) のサポートです。このスコープの最後終端で単一のオブジェクトによって使用された
オブジェクトを reclaim するのに使われている仕組みは、C++ ユーザーの間で RAII (resource
acquisition is initialization) として広く知られているプログラミングスタイルに基づいています。


The main point of this article is to show that, while RAII is a useful idiom in a 
complex language such as C++, it really doesn't provide much help in other, simpler 
languages. Even in C, which is a lower level language, the automatic destruction 
mechanism doesn't provide much that couldn't be supported by the programmer itself, 
sometimes with less surprises and higher performance.

本 article の main point は RAII が C++ のような複雑な言語において有用なイディオムである一
方で、他のもっと単純な言語でも大いに手助けになるようなことを提供してなどいなことを明確にす
ることです。より (ハードウェアよりで) 低水準の言語である C においてさえ、
the automatic destruction mechanism doesn't provide much that couldn't be supported by the
programmer itself, sometimes with less surprises and higher performance.


Is Automatic Destruction Necessary?
自動破棄は必要なのでしょうか?

The first issue that needs to be answered is if automatic destruction is a necessary 
feature in general. One of the ways we can answer this questions is looking at the 
decisions made by the designers of more recent languages. This may not give us a 
complete answer, but it shows at least an indication of usefulness for a particular 
feature.

回答する必要のある issue で最初に取り上げるのは自動破棄が一般的に必要な機能かどうかと
いうものです。この疑問に対して回答する方法の一つが、より新しい言語の設計者たちの判断が
どうであったかを見るというものです。これはわたしたちに完全な回答を与えてはくれませんが、
少なくとも特定の機能に対する有用性の指針を show します。


In fact, there are many languages such as Java, Python, Javascript, and Rubi that don't
have an idiom for RAII. Moreover, among the communities of users for these languages 
there is no feeling that there is a particular need to add such a feature. This 
includes both older languages such as Smalltalk as well as languages more recent than 
C++, such as Javascript.

事実、Java や Python、JavaScript、Ruby などのように RAII のためのイディオムを持っていない
言語はたくさんあります。加えて、これらの言語のユーザーによるコミュニティの間では RAII の
ような機能を追加しようという機運はありませんでした。これには Smalltalk のように古くからあ
る言語と、JavaScript のように C++ よりも新しい言語との両方が含まれます。


The main reason most languages don't require a RAII idiom is that they don't need to 
manage memory manually. Memory is the single most common resource guarded by C++ 
classes, a resource that needs to be released every time an object is discarded.

ほとんどの言語が RAII イディオムを必要としていない主な理由は手作業によるメモリ管理が不要
だということです。メモリーは C++ のクラス群によって guard される single most common resource
であり、オブジェクトが破棄 (discard) される度に解放の必要がある resouce です。


Another reason for having automatic destruction in C++ is that is provides a decentralized
way to manage resources for any number of classes. Compared to C, a C++ program needs to
define a lot more user defined data types (classes) in order to do its work. The
interaction between features such as the STL and the inheritance mechanism require that a
lot of classes be created to represent programmatic concepts — no wonder why C++ programs
feel the need to have a mechanism for cleaning up the resulting mess.

C++ で automatic destruction を持つもう一つの理由は、任意個のクラスのためのリソースを
管理する decentralized way を提供するためです。C と比較したとき、C++ のプログラムはそ
の動作のために格段に多くのユーザー定義型(クラス)の定義を必要とします。STL のような機能
と継承機構の間の interaction はプログラム的なコンセプトを表現するために作り出されたた
くさんのクラスを要求します。
C++ のプログラムが resulting mess をクリーンナップするための
機構を持つ必要があると感じられるのに不思議はありません。


Disadvantages of Destructors
デストラクターの欠点


One of the problems with automatic destructors in C++ is that they require a lot of 
run-time overhead. Every object in every class needs to call a destructor, even if it 
does nothing (which is often the case). It is true that an optimized compiler can 
eliminate the call to the destructor in some cases. However, when we have virtual 
destructors this becomes very difficult, since the compiler has no way to know exactly 
what destructor will be called through the virtual table.

C++ における自動破棄に伴う問題のひとつが実行時のオーバーヘッドが避けられないということ
です。デストラクターで何もすることがなかったとしても、すべてのクラスのすべてのオブジェ
クトはデストラクターを呼び出さなければなりません。最適化コンパイラーが一部のケースにお
いてデストラクターの呼び出しを削除する可能性があるのは本当です。しかしながら、仮想デス
トラクターを持っていた場合、そのような最適化は非常に難しいものとなります。なぜなら、コ
ンパイラーはデストラクターが仮想テーブルを通じて呼び出されることを正確に知る手段を持っ
ていないからです


When a system has a large number of objects with virtual destructors, which is a common
case on object oriented systems, the result is that destructors are called all the time
for no good reason.

オブジェクト指向システムでは一般的なケースですが、あるシステムに仮想デストラクターを持った
大量のオブジェクトがあったときの結果はすべてのデストラクターが good reason を持たずに呼び
出されるというものです

A more subtle problem with the RAII idiom is that, while it solves some of the issues 
of resource management, it doesn't address the most difficult cases. The only 
instance where RAII works well is when objects are allocated in the stack. For these 
allocations, destructors are guaranteed to be called at the end of the scope, even if 
an exception happens before the end of the scope is reached.

RAII イディオムに関連するより微妙な問題は、それがリソース管理の問題の一部を解決する一方で
もっとも困難なケースに対処していないというものです。RAII がうまくいく唯一の事例はオブジェ
クトがスタックに割り当てられているときです。これらの割り当てに対しては、スコープの終端に
到達する以前に例外が発生したとしてもデストラクターがそのスコープの終端で呼び出されることが
保証されています。


However, C++ has two more memory allocation models: static-allocated and 
heap-allocated memory. Static memory can be a problem for the implementation of the 
singleton pattern. It is well known that objects created on static memory will not be 
destructed correctly. Even when they may be destructed, there are no guarantees. 
Therefore, static allocation of objects should be dealt with special care, and 
destructors cannot be of much help in this case.

しかし、C++ にはこれに加えて static-allocated memory と heap-allocated memory というさらに
二つのメモリー割り当てモデルがあります。static memory は singleton パターン実装の際に問題と
なる可能性があります。static memory 上に生成されたオブジェクトが正しく destruct されないの
はよく知られています。それらは destruct されたとしてもなんの恩恵もありません。したがってオ
ブジェクトの static allocation は特別なケースとして扱うべきであり、デストラクターはこのケー
スにおいてそれほど助けになりません。


The other, much more important case of memory allocation is heap-based allocation. It 
is important because in an object oriented language the objects use have distinct life 
times. Therefore, one should be able to allocate them and pass references around until 
they are not needed anymore. The standard way of doing this is allocating memory on 
the heap and returning that memory to the pool only when the object is done.

そのほかの、ずっと重要なメモリー割り当てのケースとはヒープベースの割り当てです。これが重要
なのは、オブジェクト指向言語においてオブジェクトはそれぞれが異なる生存期間を持つようになっ
ているからです。したがって一度オブジェクトを割り当てたならば、そのリファレンスをオブジェク
トがもはや必要なくなるまで持ちまわれるようになっているべきなのです。これを行う標準的な方法
が、ヒープ上のメモリーに割り当ててそのメモリーを返すというものです。


Now, the problem with heap allocated memory is that destructors will be of no help in 
that case. They will not be called automatically when an object is not needed. If a 
programmer doesn't take care of cleaning heap-allocated memory, it will just leak 
when no more references to it exist in memory.

さて、このヒープに割り当てられたメモリーについての問題とはデストラクターがこういったケースの
手助けをしないということです。あるオブジェクトが必要なくなったときにデストラクターが自動的に
呼び出されたりはしません。プログラマーがヒープに割り当てられたメモリーに対して注意を払わなか
ったりしたら、メモリーに存在しているものに対する参照がなくなった時点でリークが起きます。


To avoid this, programmers are required to call delete (or delete[]) to make sure that 
the object is properly cleaned. Thus, programmers are ultimately the ones responsible 
for this difficult task. If you think of the implementation in terms of C (and other 
lower level code), in this case the destructor is just a function that needs to be 
called in the object. There is nothing special in it other then the syntax, which uses 
the keyword delete.

リークを起こさないよう、確実にオブジェクトを完全に消去するためにプログラマーは 
delete (もしくは delete[]) を呼び出すことを要求されています。したがって、プログラマーはこの
困難な task に対して resposible な ultimetely the ones なのですもし C の環境 (あるいはより
低水準のコード) でこの実装を考えるのならば、デストラクターとはオブジェクト中で呼び出す必要の
ある関数に過ぎません。delete というキーワードを使っている構文以外は特に特殊なものでもありま
せん。


In fact, the destructor itself is a non-impressive function, with some serious 
drawbacks. First, it receives no arguments and returns no value. So, for example, 
there is no way to signal an error condition other than throwing an exception. And we 
already know that a destructor shouldn't throw exceptions, which means that it cannot 
do anything very reliably.

実際、デストラクターそれ自身はいくつかの深刻な drawbacks を抱えた non-impressive な関数です。
第一に、デストラクターは引数を取らないし、また値を返しません。
一例を挙げると、このために例外を送出する以外にエラー状態を知らせる手段がありません。
また、デストラクターは very reliably なことは一切できないことを意味するような
例外を送出すべきでないことをわたしたちはすでに理解しています。


What this amounts to is a system that is far less powerful than necessary to maintain 
a first class object oriented system.

what this amounts to は
a first class object oriented system を扱うのに必要なものよりも
far less powerful なシステムです。


Conclusion
結論

RAII is preached by some as the most important feature of C++ for resource handling. 

RAII は一部の人たちが最も重要な C++ 向けのリソースハンドリングの機能として主張 (preached)
しています。


However, as we have seen above, it has lots of problems that make it much less appealing
than initially thought.

しかしこれまで見てきたように、RAII には当初考えていたよりも多くの問題があります。


For example, destructors work well only when the memory class used by the object is stack
based. Other allocation classes will result in memory leaks and in manual work for programmers.

たとえば、デストラクターはオブジェクトが使っているメモリークラスがスタックベースのとき
にのみうまく動作します。他のアロケーションクラスでは結果としてメモリーリークを起こし、
プログラマーの manual work が行われることになります。


Even the work performed on behalf of stack allocated objects is nothing more than syntactic
sugar. While tedious, it is not hard to add a matching clean up procedure at the end of the
scope where an object is used, when necessary. If no exceptions are used in code (which is
a common case even on C++), this is all one needs to have correct programs.

スタックに割り当てられたオブジェクトのために行っている作業は構文糖 (syntactic sugar) 以
上のものではありません。退屈なものではありますが、必要なときにオブジェクトが使われたそ
のスコープの終端で clean up の手続きのマッチングを追加するのは難しいことではありません。
コード中で例外が使われていなければ (これは C++ でもよくあることです)、これこそが正しい
プログラムを得るために必要なことなのです。


Published on June 15th, 2011

Copyright © Carlos Oliveira · All rights reserved.

■_In Praise of Non-Alphanumeric Identifiers

名前。

prog21: In Praise of Non-Alphanumeric Identifiers

In Praise of Non-Alphanumeric Identifiers

Here's a common definition of what constitutes a valid identifier in many programming languages:

多くのプログラミング言語において、vaild な識別子の構成でよくある定義はこういったものです。

    The first character must be any letter (A-Z, a-z) or an underscore. Subsequent characters,
    if any, must be a letter, digit (0-9), or an underscore. 

    最初のキャラクターは文字 (A-Z と a-z) かアンダースコアでなければならず、
    それに続くキャラクターは文字か、数字 (0-9) かアンダースコアでなければならない。

Simple enough. It applies to C, C++, ML, Python, ML, most BASICs, most custom 
scripting languages (e.g., Game Maker Language). But of course there's no reason for 
this convention other than being familiar and expected.

十分に単純で、C や C++、ML、Python、ML、大部分のBASIC、カスタムスクリプティング言語
(たとえば Game Maker Language) の大半がこれを使っています。
しかし、当然ながら慣れ親しんでいるので expected である以外にこの convention に
理由はありません。

One of my favorite non-alphanumeric characters for function names is "?". 
Why say is_uppercase (or IsUppercase or isUppercase) when you can use the more 
straightforward Uppercase? instead? That's standard practice in Scheme and Forth, and 
I'm surprised it hasn't caught on in all new languages.

関数名に使う alphanumeric でないキャラクターでわたしが好きなもののひとつが "?" です。
Uppercase? というもっと straightforward なものが使えるのであれば、どうして
is_uppercase (もしくは IsUppercase だとか isUppercase) という名前を使うでしょうか?
これは Scheme や Forth で使われている標準の practice で、
新しい言語すべてでこれが使えないと知ったときには驚きました。

(As an aside, in Erlang you can use any atom as a function name. You can put 
non-alphanumeric characters in an atom if you remember to surround the entire name 
with single quotes. It really does work to have a function named 'uppercase?' though 
the quotes make it clunky.)

Scheme's "!" is another good example. It's not mnemonic, and it doesn't 
carry the same meaning as in English punctuation. Instead it was arbitrarily 
designated a visual tag for "this function destructively updates data": set!, 
vector-set!. That's more concise than any other notation I can think of ("-m" 
for "mutates"? Yuck).

Scheme の "!" はもうひとつの良い例です。これはニーモニック (mnemonic) ではなく、
英語の punctuation と同じ意味を持ち込んだものではありません。
Scheme ではこれは "this function destructively updates data":
(この関数はデータを破壊的に更新する) という visual tag に割り当てられています。
set! や vector-set! がその例です。
わたしが考えつくほかのどんな記法よりも一貫性のあるものです
("-m" for "mutates"? Yuck)。


Forth goes much further, not only allowing any ASCII character in identifiers, but 
there's a long history of lexicographic conventions. The fetch and store 
words--"@" and "!"--are commonly appended to names, so color@ is 
read as "color fetch." That's a nice alternative to "get" and 
"set" prefixes. The Forthish #strings beats "numStrings" any day. 
Another Forth standard is including parentheses in a name, as in (open-file), to 
indicate that a word is low-level and for internal use only.

Forth はもっと徹底的で、識別子においてすべての ASCII 文字を許すだけではなく
lexicographic conventions (辞書的変換?) の長い歴史を持っています。
フェッチ "@" やストア "!" は名前に良く使われていて、
color@ は "color fetch." のように読みます。
これは prefix に "get" と "set" を使うことに対する
nice な alternative です。
The Forthish #strings beats "numStrings" any day. 


Another Forth standard is including parentheses in a name, as in (open-file), to 
indicate that a word is low-level and for internal use only.

もうひとつ Forth の標準では (open-file) のように 名前にカッコを含められます。
これはそのワード(訳注 Forthでいうところの関数みたいなもの) が低水準なものであり
internal use のためにのみあることを示しています。


And then there are clever uses of characters in Forth that make related words look 
related, like this:

Forth における賢い文字の使い方には、関連しているワード群を関連しているように見せる
というものがあります。例を挙げましょう。

  open{ write-byte write-string etc. }close

The brace is part of both open{ and }close. There no reason the braces couldn't be 
dropped completely, but they provide a visual cue about scope.

このブレースは開きと閉じの両方ともそれぞれ open{ と }close の一部になっています。
このブレースを取り除けない理由はありませんが、それらはスコープに関して
visual cue を与えているのです。

"-" を使わせてくれと思うことはままあるな。

そこ、Lisp ならとか云わない!w (COBOLでも使えるな)

■_ エスケープ過多

正規表現道場 

807 nobodyさん [] 2011/10/14(金) 09:47:43.56 ID:+/AP5o7r Be:
    htmlのソースからタグを除外するのに挑戦してて以下のようにしたんですが
    もっと効率いいやり方あるでしょうか？

    \<[a-zA-Z0-9\"\<\>\ \=\;\:\/\.\_\-\(\)\#\!\'\&\%]+ 

808 nobodyさん [sage] 2011/10/14(金) 15:25:07.10 ID:??? Be:
    どんだけ円がすきなのかとｗ 

文字クラスの中で必要以上にエスケープするの好きじゃないんだよねえ(^^;

■_ reddit に訊け

What language should I learn to complement Python? (Python を補うためにわたしが学んだほうが良いプログラミング言語は何?)

What language should I learn to complement Python? : Python

What language should I learn to complement Python? (self.Python)


I've been programming with Python at work and on pet projects for a couple of years 
now and I feel that it is time to get into a second langauge. I want something that 
will be useful, challenging, and forces me to think in a different way than Python 
does.

I guess some relevant stuff is, I'm a physics undergrad, and I write (relatively 
simple) code for the lab I work in, mod Mount&Blade (a game written in Python) 
occasionally and do small projects for funsies. I like algorithms. I'm strongly 
considering going after an MS in compsci before a PhD in something.

Thanks to anyone who'll help!

EDIT: Wow, thanks for all the replies. Looks like C and Lisp are winning. I've noodled 
around with Haskell before and couldn't wrap my head around it, might give that one a 
look too.

Seconding C for something useful. Try Scheme for something that will expand they way 
you think about programming: http://mitpress.mit.edu/sicp/

Seconding Scheme here for the same reasons. It was the first language I learned and 
I've always been glad I did.

If the question was for Ruby, Japanese would actually be a good idea.

どうして？

Because Ruby is amazingly popular in Japan (I'm there at the moment, and the existing 
code I am using is a mixture of C, C++ and increasingly more Ruby) and Japanese tend 
to dislike speaking english, so by learning Japanese you can profit from the Japanese 
Ruby community.

That has changed since Rails, but before it got so popular it was actually hard to get 
useful english ressources on Ruby.

C is good to know from an engineering perspective. It uses physical addresses to 
structure data. That's great if you want it to run on a specific device, but like most 
languages, that physical memory management is handled pretty well by an interpreter.

Programmers should learn C at some point in their life, and they should also learn assembly
and how C compiles into assembly. They should also learn about the Von Neuman architecture
in computer systems and how a program counter interacts with a data bus.

Honestly, I don't see how any of that complements Python except for the fact that 
CPython was written in C.

Try GO

How I would teach university languages:

   1. Python - Learn programming though process, algorithms
   2. C - Learn memory management, hardware interaction
   3. ASM - Learn what compiled code is doing
   4. Haskell - Learn how to think about problems differently

erlang :)

Fortran. No joke.

Haskell

■_

• 「戻り値」ですか？「返り値」ですか？ | OKWave
• qsortの先頭のqの意味 | OKWave
• エンジニアライフ in a northern town: 銀行員の丸め方
  父さん、ぼくは間違っていますか……。
• 広島｜株式会社バグ（BUG）｜トップページ
• スポーツナビ | サッカー｜コラム｜日本サッカーの未来は本当に明るいのか？（２／２）
  子どもが自らの発想で模倣した技術は成長につながりますが、大人が型にはめたプレースタイルを教え込んではいけません
• 虐殺器官 - 脇見運転
• ASCII.jp：「花咲くいろは」の経営術【前編】｜渡辺由美子の「誰がためにアニメは生まれる」
  キーワードは“社員から職人へ”、そして“顔の見える評価”だ。
• 「○○する」を意識する ― 肯定表現が生み出す行動力：竹内義晴の、しごとのみらい：ITmedia オルタナティブ・ブログ
• I, Cringely . The Pulpit . The Puppet Master | PBS
• カンファレンスは、若い人ばかり？：柴田 芳樹 (Yoshiki Shibata)：So-netブログ
• 東北を巡った - jkondoの日記
• IronPythonでpyをEXE(.NET Assembly)にコンパイルする。 | OPC Diary
• 「dis」や「disる」の意味と使い方　ー 　英語のスラングか？　和製英語のスラングか？ | 英語 with Luke
• 今時なC言語は何で学べば良いかしら #C - Qiita
• void (日下部陽一) 氏、半角ｶﾀｶﾅの置換をし忘れる - Togetter
• LINQと他言語のリスト処理ライブラリの対比(Scheme編) - TIM Labs
• ブログテーマ[Appe II コンパチ手作り]｜西田ラヂオのブログ
• NumPyで行列を各column単位でイテレートするには - 西尾泰和のはてなダイアリー
  で、疑問なのは、なんでこれがarrayのメソッドになってないのかということ。
• 左から適用される合成関数 - 水底で思うこと
• The Codist
  Am I Too Old To Be A Programmer?
• Officeのリボン、使いにくくないですか？(1/2) | OKWave
• なぜ次に学ぶ言語は関数型であるべきか - YAMAGUCHI::weblog

■_

さてベイスターズ。 正式な調印?はまだのようですが、まあ決まりでしょうと。

まずは TBS にお礼を言いたい。 前回のごたごた(ニッポン放送所有の株やら)でおそらくは「押し付けられた」と思っているのだけど、 TBS の名前を球団名に入れないでいてくれたし (世界陸上の宣伝をヘルメットに入れたのはまあご愛嬌だ :)、 佐々木の日本球界復帰のときの年俸もどうにかしてくれたのは TBS らしいので。

本来球団の運営というのは独立採算できるようにすべきであって、 「親会社からの支援」があってどうにかこうにか運営できるというのは歪でしょう。 とはいえ、そうできるようにするためにはこれまたいろいろ障害があるわけなんですが、 それは今回の本題ではないので割愛。

んでまあ、 べつに「モバゲー」って入っても良かったんですけどね。 商品名(サービス名)と企業名とで大差ないだろうと思ってます:)

そういや、応援歌どうするんだ? 熱き星たちよ - YouTube ホークスも(ダイエー→ソフトバンクで)結構無理やりな歌詞変更してたようなw

いずれにしても、「横浜ベイスターズ」でなくなったベイスターズにはあまり興味はありません。 これから変わるかもしれないけれど。

■_ アレ

JavaScript を有効にしていないと見られない (有効にしててもとことん見づらい状態)ってのは知ってたけど、 最新版の Reader で読めないってなに…

んで、高い金だして買ったところで似たような状況なんざんんしょ?

C言語なら俺に聞け（入門編）Part 91 

659 デフォルトの名無しさん [sage] 2011/11/04(金) 18:42:46.77 ID: Be:
    うーん…
    だめだ、完了点とかよくわかってないからな

    JIS規格読んでこようと思ったら見れなかったでござる。 

662 デフォルトの名無しさん [sage] 2011/11/04(金) 18:52:51.98 ID: Be:
    >>659
    買うと8万だかするんだよね。
    JIS規格には著作権ないはずなのに著作権を主張してコピーさせないし。
    挙句に最新のAdobe Readerだと見れない。

    さすがは巨大な天下り団体。仕事しなさ加減は世界最高レベル。 

670 デフォルトの名無しさん [sage] 2011/11/04(金) 19:17:40.45 ID: Be:
    >>662
    見ようとしたら
    X3010_01.pdf
    15.9 MB (16,748,724 バイト)
    MD5:9723FF3B1BD26AF5D5109BF57EC09E44
    と普通に保存できたので
    いったんローカルに保存してから
    適当なビューワーで見ればいんじゃない？ 

672 デフォルトの名無しさん [sage] 2011/11/04(金) 19:20:06.93 ID: Be:
    >>670
    よし、そのブラウザと詳しいダウンロード方法を教えるんだ。
    いや、教えてください。お願いします。(´・ω・｀) 

678 デフォルトの名無しさん [sage] 2011/11/04(金) 19:33:59.51 ID: Be:
    >>670
    適当なビューアで見れる？ 

681 デフォルトの名無しさん [sage] 2011/11/04(金) 19:58:41.71 ID: Be:
    >>672
    勘違いしてたみたい
    落とせたつもりになってたけど前に落としたファイル見てたわ


683 デフォルトの名無しさん [sage] 2011/11/04(金) 20:01:28.35 ID: Be:
    >>681
    うん。そのファイル、最新版Adobe Readerじゃ読めないからｗ 

693 デフォルトの名無しさん [sage] 2011/11/04(金) 20:46:11.10 ID: Be:
    >>670
    昔はキャッシュから引っ張ってこれたけど今はロックが掛かってて
    ローカルコピーを見ても見れないよ

    これと同じでC++11のJIS版も買うしかない 

694 デフォルトの名無しさん [sage] 2011/11/04(金) 20:53:59.42 ID: Be:

    悪徳商法だとしか思えないよね。 

■_ 書き手は誰?

C++11のコーディング変更点まとめ | エンタープライズ | マイコミジャーナル

次世代のC++規格「C++11」が国際標準として発行された。多くのC++デベロッパは、この新しい
C++規格で提供される新機能に関心があると思うが、仕様書を読むのは骨が折れるとためらって
いる方も少なくないだろう。

そんなデベロッパの皆さんに朗報だ。C++11の登場で通常のC++コーディングとライブラリデザイ
ンなどに強く影響を与えるとみられる変更がBjarne Stroustrup氏の記事「Elements of Modern 
C++ Style」にまとめられている。C++98と比べて特に見た目の変更が大きく、かつ、今後広く使
われ新しいコーディングスタイルになりそうなものが紹介されており、C++11新機能を知るため
の導入ドキュメントとして役に立つ。

(略)

最初に「Bjarne Stroustrup」とあるのは 引用している“C++11 feels like a new language.”の発言主だってことで、 記事全体は blog 主の Herb Sutter じゃなかろうか? 記事があるのも herbsutter.com だし、Sutter's Mill に投稿されたものだし。

Elements of Modern C++ Style « Sutter's Mill

Elements of Modern C++ Style

  “C++11 feels like a new language.” – Bjarne Stroustrup
    C++11 は新しい言語のようなもの

The C++11 standard offers many useful new features. This page focuses specifically and 
only on those features that make C++11 really feel like a new language compared to 
C++98, because:

C++11 標準では多くの有用な新機能を提案しています。このページでは、C++98 と比較して
C++11 を本当に新しい言語のように感じさせる機能に絞っています。
なぜならば

    * They change the styles and idioms you'll use when writing C++ code, often including
      the way you'll design C++ libraries. For example, you'll see more smart pointer
      parameters and return values, and functions that return big objects by value.

      そういった新機能が、C++ライブラリを設計するときの方法も含んで
      C++でコードを書くときにに使うであろうスタイルやイディオムを変えるから。
      たとえば、スマートポインターを使ったパラメーターや戻り値、
      by value で大きなオブジェクトを返す関数といったものを目にする機会が
      増えるでしょう。

    * They will be used so pervasively that you'll probably see them in most code examples.
      For example, virtually every five-line modern C++ code example will say “auto”
      somewhere.

      新機能は大部分のコード例で目にするほど広範囲で使われるようになるでしょう。
      たとえば、事実上5行の mnodern な C++ コードのサンプルではすべて
      "auto" をどこかで使うことになるでしょう。

Use the other great C++11 features too. But get used to these ones first, because these
are the pervasive ones that show why C++11 code is clean, safe, and fast – just as clean
and safe as code written in any other modern mainstream language, and with C++'s traditional
to-the-metal performance as strong as ever.

ここで取り上げていないそのほかの great な C++11 の機能も使われるでしょう。
しかし、このページで挙げたものがまず使われます。
なぜなら、それらは C++11 のコードがきれいで、安全で、高速である理由を示している
普及したものであるからです。
ほかの modern な mainstream の言語を使って書かれたものと同じくらいきれいで安全なもので、
同時に、これまでの強みである C++ の traditional な to-the-metal perfrormance も
持っています。
#ちとむりやり

(略)

■_ sandbox

ニュースサイトで取り上げてるところもありましたが

The Codist

 the codist - programmerthink

Apple to Require Sandboxing in Mac App Store Apps As of March 2012

Published: 11/02/2011

Apple sent an email to registered developers today telling us that sandboxing will be 
required for all applications in the Mac App Store as of March next year.

Sandboxing basically requires you to engineer your application to live in isolation 
and only access anything outside of what you are given via entitlements. Some 
temporary entitlements will be granted for a limited time to aid in the transition.

(略)

The end result might be where my OSX computer becomes more like a mainframe, where I 
have little control of how it works other than how Apple wants me to use it. Of course 
thats the iPad/iPhone world. But those are not where I live every day. I write 
software and I wonder if tools will be as restricted as everything else, meaning I 
have to go through hoops and pain to do anything but plain Xcode coding.

(略)

Copyright © 2007-2011 Andrew Wulf Mail 

どうなるんでしょうねえ。 こういう「縛り」が入るのは(仕方のない一面があるにせよ)どうにも受け入れがたい。

■_

名前を知っている人あまりいなかった ○|￣|＿

fogus: In the Shadow of John McCarthy

In the Shadow of John McCarthy

Nov 3, 2011

John McCarthy was a genius of the highest order. Much is known about his contribution 
to Lisp as its inventor, but he was also the mind behind much of early AI research, 
the progenitor of much of computer chess, and the initiator of time-sharing. As a Lisp 
advocate I have many thanks due to John McCarthy and it saddens me that I will never 
have the chance to give them. However, like many geniuses McCarthy was surrounded by 
likewise brilliant creators and thinkers. This post is devoted to some of the 
brilliant minds that influenced, provoked, and in one case defied McCarthy for the 
betterment of the early LISP history spawning the Lisp world that we now enjoy. So 
goes the history of monumental minds that their likewise monumental shadow engulfs 
those whose help was critical to the larger historical significance.

John McCarthy は genius of the highest order でした。
彼は Lisp の発明者としての貢献でよく知られていますが、
彼は初期の人工知能研究の mind behind であり、コンピューターチェスの progenitor であり、
時分割の initiator でもありました。
Lisp 贔屓としてわたしは、John McCarthy に深く感謝するとともに、
彼にお礼を述べることがもうできないことは残念でなりません。
#give them の them が
しかし、多くの天才たちがそうであったように、McCarthy は brilliant な Creator たちや thinker
たちに囲まれていました。
この投稿では、
This post is devoted to some of the brilliant minds that influenced, provoked,
and in one case defied McCarthy for the betterment of the early LISP history
spawning the Lisp world that we now enjoy.
So goes the history of monumental minds that their likewise monumental shadow engulfs 
those whose help was critical to the larger historical significance.


Steve Russell

That Steve Russell created the first LISP evaluator is fairly well known, so to include his
name on this list is questionable. However, it's important to note that has it not been for
his effort the history of LISP as a language might have never occurred and if it had then it
would have manifested very differently. In early 1959, Steve Russell took the theoretical
idea that was LISP devised by his advisor John McCarthy and hand-compiled the “Universal
LISP Function” to operate on the IBM 704. In a survey of one, I suppose the lesson is to
never listen to your advisor.

The implementation was novel in that it utilized the machine capabilities to maximum effect.
However, unbeknownst to Russell, and early decision would “haunt” LISP even up to today:

    Because of an unfortunate temporary lapse of inspiration, we couldn't think of any 
    other names for the 2 pointers in a list node than “address” and “decrement,” so 
    we called the functions CAR for “Contents of Address of Register” and CDR for
   “Contents of Decrement of Register.”

As a contributor to Clojure it always brings a smile to my face when people deride its lack
of car and cdr. What seems a priceless nostalgic gem to some is but the leavings from a lack
of inspiration some 50+ years ago.


Dan Edwards

Dan Edwards (gc) during June/July of 1959 wrote the garbage collector that would serve up
to the 1.5 release of LISP. (McCarthy 1962) According to McCarthy, the garbage collector
worked as such:

Dan Edwards (gc) は
during June/July of 1959 
ガーベジコレクターを書きました


    At any given time only a part of the memory reserved for list structures will actually
    be in use for storing S-expressions. The remaining registers (in our system the number,
    initially, is approximately 15,000) are arranged in a single list called the free-storage
    list. A certain register, FREE, in the program contains the location of the first
    register in this list. When a word is required to form some additional list structure,
    the first word on the free-storage list is taken and the number in register FREE is
    changed to become the location of the second word on the free-storage list. No provision
    need be made for the user to program the return of registers to the free-storage list.

Edwards, Michael Levin, and Hart (below) also proved the equivalency between the alpha-beta
and minimax search algorithms, (Edwards 1961) that was also overshadowed by McCarthy given
that he seemingly invented alpha-beta out of thin air in 1955.


Timothy Hart

Macros are a ubiquitous element for any Lisp language in use today, but the fact is 
that they were not part of the early LISP implementations. Instead, LISP macros were 
invented years after Russell's first implementation by Hart and were described in a 
scrawled 3-page document called MACRO Definitions for LISP published as an MIT memo. 
(Hart 1963) This short but epic document described an extension to the original 
seven-function LISP eval that looked effectively like the following:

マクロは ubiquitous element for any Lisp language in use today
ですが


  ((eq (caar expr) (quote macro))
   (cond
     ((eq (cadar expr) (quote lambda))
      (eval (eval (car (cdddar expr))
                  (cons (list (car (caddar expr)) 
                              (cadr expr)) 
                        binds))
            binds))))

I've extended my Lithp interpreter with Hart-style macros if you'd like to play with 
such a beast.


Nathaniel Rochester and Herbert Gelernter

It's hard to imagine how Rochester, the creator of the first assembler, could be 
overshadowed by McCarthy, but from a LISP perspective he certainly is. The influence 
of Rochester and Gelernter are likely deeper than I know, but in one instance their's 
is a negative influence. That is, McCarthy at one point was considering an extended 
version of Fortran with list processing capabilities for his AI research, of which 
such a system was developed by Rochester and Gelernter. However, McCarthy realized 
that such a library did not adequately serve his needs which led him to explore the 
creation of a language more suited to his AI explorations and LISP was the result.

Alan R. Kotok

Alan Kotok, one of the designers of the PDP-10 was driven to design a machine that 
could effectively host a LISP system. The PDP-10 is, at its core, is built with an eye 
toward LISP. Indeed, the 36-bit word size is there because LISP implementations 
benefited from two 18-bit pointers per word (the elements of a cons cell). It's 
unclear how the PDP-10 influenced LISP, if at all,1 but I thought that this was a 
great story and a preview of the Lisp Machines that would come years later.

Others and Inaccuracies?

Did I misrepresent something here? Please let me know.

Additionally, there are many others involved with the early days of LISP whose contributions
were not easy to find, including:

    * Paul W. Abrahams
    * Robert K. Brayton
    * Saul Goldberg
    * David Luckham
    * Michael Levin
    * More…

If you have any information about these pioneers, or are the pioneers themselves, then please
comment here with pointers to more information and I will add it to the main post body.

References

    * Dan Edwards and Timothy Hart. 1961. The Alpha-Beta Heuristic.
    * Dan Edwards. The LISP II Garbage Collector (PDF).
    * Timothy Hart and Michael Levin. MACRO Definitions for LISP
    * John McCarthy, Paul W. Abrahams, Daniel J. Edwards, Timothy P. Hart, and Michael Levin. 1962. LISP 1.5 Programmer's Manual.

■_

• AKIBA PC Hotline! : 2TB HDDの最安値推移グラフ
• Hexenkessel, 353 名前：名無し三等兵[sage] 投稿日：2008/10/09(木) 21:51:56...
• Hexenkessel, CC's goals and those of our affiliate community...
• wrong, rogue and booklog - 自民党長期政権の政治経済学
• SnowClust　 OOP みんなでやめれば 怖くない
• プログラミングの学習に写経ってあんま意味ないんじゃないかなぁ - mizchi log
• 恐怖なしに生きる: わたしが知らないスゴ本は、きっとあなたが読んでいる
• The Codist
  The iPad Revolution is Just Getting Started
• MapReduce as a monad transformer « JP Embedded Solutions
• Hexenkessel, さて、期待できないことの筆頭は、長期間の保存だと私は思います。デジタルデータだから劣化しない、みたいな...
• Hexenkessel, 　虚心坦懐に、Kindleのヘビーユーザである一読者としては、とっとと黒船アマゾンが上陸し、日本の出版...
• Neil Mitchell's Haskell Blog: Calling Haskell from R
• 【連載】出社前に。日常生活ですぐに使える！　英語クイズ (25) 「今回はやめとく」ってなんて言う？ | ライフ | マイコミジャーナル
• 自炊：電子書籍化 | OKWave
  揚げ足とられているような言い方で、・・・・。
• 電子ブック。自炊 | OKWave
• ネットワークエンジニアの将来性に関して | OKWave

■_

Powershell 結構面白い。

■_

とりあえず I を読み終えた
スティーブ・ジョブズ I

NeXT に関連して書かれている量がすくねーっ

■_ ->→.

perl5.git.perl.org Git - perl.git/commit Perl 5 で -> を使っているところを . でアクセスできるようにしてみました! ってな話なんですが、結構無茶しててMLでの反応も…w

New "dot" feature

    * From: Leon Brocard 
    * To: Perl 5 Porters 
    * Date: Wed, 2 Nov 2011 20:57:24 +0000
    * Message-ID: <20111102205724.GA27352@gmail.com>

Hello Porters,

I had a dream that Perl 5 had moved from using -> to using . like most 
modern languages. And moved the existing . for concatenation to ~ like 
Perl 6. Then I wrote the code and was shocked how tiny it was.

I have this in the leonbrocard/dot branch, but is is really one commit:

  http://perl5.git.perl.org/perl.git/commit/0c1fbeee

It's a very small tokenizer patch which interacts with a new "dot" 
feature. Then you can do things like:

  use feature qw(say dot);
  use CGI;
  my $q = CGI.new;
  say ref($q);
  say $q.blockquote(
    "Many years ago on the island of",
    $q.a({href=>"http://crete.org/"},"Crete"),
    "there lived a Minotaur named",
    $q.strong("Fred.") ,
  ),
  $q.hr;

  my $arrayref = [1,2,3,4,5];
  say $arrayref.[-1];
  my $hashref = {a => 1, b => 2};
  say $hashref.{b};

  say "Hello" ~ "world";

I think this is quite a cute example of how features can do neat little 
tricks. There may be complicated interactions which break things in 
ways I haven't thought about, but it seems like a tiny patch that 
doesn't seem to slow parsing down. I'm not entirely sure that I'm 
proposing this seriously, but...

What do you think?

Cheers, Leon.

文中にある github へのリンクから辿って、差分をみてくんなまし。 って、Perl のソースをある程度読んだことのある人でないとわからんか

reddit での反応から。

Dot dereference operator in Perl! : perl

C now:

my_ptr->thing = 1;

perl5 now:

$my_ref->{'thing'} = 1;

perl with this proposal:

$my_ref.{'thing'} = 1;

WTF?

It's an interesting novelty, but it's just importing Perl 6's squigglies without the 
underlying semantic reasoning behind them (and seems to break bitwise negation as a 
result).

BTW that last line there would be valid in Perl 6, since everything's an object and 
{...} is a method on the hash object, but the preferred form is $my_ref{'thing'} (or 
$my_ref<thing>). I imagine that'll need a lot more than a 5 line diff...

The main impetus was that Perl 6 does it like that.

...why?

Because unlike perl<6 which was a masterwork forged by a handful of geniuses, perl6 was
designed by committee.

What?

Perl is not C. Congratulations on your discovery. :)

For a second I thought it was going to link to this

I don't like it (I think "->" is far clearer and more Perlish than "."),
but I admire how easily it was implemented :)

■_ このネタ何度目だ

そしてそれで500オーバーの盛り上がりを見せるとか、いったいなに。

"C++ is a horrible language" ~ Linus Torvalds : programming

"C++ is a horrible language" ~ Linus Torvalds (article.gmane.org)

I respect the work of Linus Torvalds a lot. I never understood people who comes after 
the war is over to ask :"what did you not do this or that" ? I find this 
kinb of behaviour quite stupid, if it matters so much to this guy to have GIT written 
on C++, he should have just fucking do it himself. Somebody wrote a piece of software 
in a language of his / her choice, what's the matter ?

That being said I find the character of Linus quite detestable.

I mean he has the means and the experience to actually states his opinions in a 
constructive manner yet he choses to fuel the never ending useless debate : C vs C++ 
and I must say in a poor style.

I mean statement like this :

"inefficient abstracted programming models where two years down the road you 
notice that some abstraction wasn't very efficient, but now all your code depends on 
all the nice object models around it, and you cannot fix it without rewriting your 
app."

Kind of makes me wonder why he even bother to reply to the question.

STL and Boost not portable ? Really ? Seriously ?

I mean of course, it is true that they cause "infinite amounts of pain when they 
don't work" but quite frankly what doesn't ? It's the job of a programmer to make 
sure it works no ? So what's the point saying things like that ?

Boost can be hard to set up on certain platforms that is true but that still doesn't 
make the statement true enough to be a valid reason.

All that being said, I will personally stick to C++ and hope that one day I will have 
enough experience in that language to state my opinion in a useful manner. I don't 
hate C, I just like abstraction and I am conviced that C++ makes the trade off between 
abstraction and performance quite well, which btw is also the opinion of many area of 
our industry ...

    STL and Boost not portable ? Really ? Seriously ?

I seriously used C++ about 5 years ago, so things might have changed, but at that time 
they weren't portable. You should use certain version of STL with certain compiler, 
and each particular library of Boost requires certain versions of compiler with 
certain patches.

It takes some effort to design language such complex that pretty much all compilers 
are broken in one way or another.

Borland C++ Builder 6 (released in 2002) barely supported even STL version it was 
bundled with.

Remember there was no C++11 standard in 2007, so many features these libraries relied 
upon were not standardized, they were like consensus among compiler makes.

    I mean of course, it is true that they cause "infinite amounts of pain when they
    don't work" but quite frankly what doesn't ? It's the job of a programmer to 
    make sure it works no ?

It is a job of a programmer to make sure COMPILER and LIBRARIES he uses work? Really?

As a seasoned C++ programmer, I'd say C++ is a pretty horrible language, but it's the 
least horrible for certain niches. I'm actively looking for replacements; something 
among the likes of decac, Rust, Clay, or ATS.

D is a pretty cool language but I feel it doesn't quite go far enough. It had the 
chance to do some serious restructuring since it ditched compatibility with C++ but 
ended up being just C++ with a facelift. Things like built-in algebraic data types 
(i.e. built-in tagged unions and tuples with built-in destructuring syntax), 
typestate/linear types/otherwise more sophisticated type systems etc could definitely 
be used in the low-level tasks that C++ is meant for.

■_

• [プログラミング][Haskell]Listモナドを勉強してみる - 白帽子研究室(sbwhitecap labs)
• 奥様はVBA - Togetter
• 名古屋F#ディナーミーティング 20111110 - [PARTAKE]
• Windows Phoneのスペックは、初代のXboxよりは上なんです - ＠IT
• vim-jp » Vim 20 周年
• Celebrate 10 Years of Eclipse
• 写経で身につけるプログラミングの基本 - Social Change!
• 驕る平家は久しからず
  「奢っても、奢らなくても同じ結果なら奢ったほうが良い」という論理もなりたちますね。
• 驕る平家は久しからず（おごるへいけはひさしからず）：ことわざデータバンク
• 驕る とは - コトバンク
• 奢る とは - コトバンク
• n_sodaさんによるpthreadを使べき場面について - Togetter

■_

ぐはっ、時間切れ

■_

FaceBook やら Google+ やらはどうしたもんかと。 いろいろ巡ってる時間的余裕はないしさりとて

■_

• igeta's gist: 1330702 ? Gist
• 2011-11-01 - ぱたへね！ Tcl/Tkで使われているカプセル化手法
  Tcl/Tkのソースコードを眺めていたら、面白そうなコードを見かけたので紹介します。
• 「数字混じりソート」さらに改 - 水底で思うこと
• Scalaでパーサーを作ってみる～1:構文定義 - きしだのはてな
• Commit 9eb58d9d42e69bb5ff6699d062ee8b0371aeb8d2 to MagLev/maglev - GitHub
• C++のテンプレートでラムダ計算と型推論 - 貳佰伍拾陸夜日記
• 編集者の日々の泡:出版社「悪者説」から、とりあえず初歩的な誤解ベースだけ書いとこうかな
• Isaac Asimov の Foundation をお勧めされた
• Big Sky :: 実行モジュールだけで持ち歩けるCoffeeScriptコンパイラをv8で書いた。
• Perl5 においてファイルからの読取る場合における Malformed UTF-8 問題 - ”><xmp>TokuLog 改メ tokuhirom's blog
• Haskell＋タグレスな型付きDSLで楽々！C言語コード生成 - keigoiの日記
• 新手のマルウェア「Duqu」、Windowsカーネルの未解決の脆弱性を利用 - ITmedia エンタープライズ
• Khan Academy
• Racism in Tech
• チームワーク 2.0：【第2回】チームにはびこる「社会的手抜き」 (1/2) - ITmedia エグゼクティブ
• 2011年上半期の事例にみる脅威とその対策　第3回 - 日本のセキュリティチーム - Site Home - TechNet Blogs
• Scheme⇔JavaScript対応表
• レポート：今後のIT業界はどうなる？どう乗り切る？「第1回 エンジニアの未来サミット for students 2011」レポート｜gihyo.jp … 技術評論社
  最後に各パネラーが一言ずつコメントする中，まつもと氏が語った「今後は個人の可能性がポジティブ，ネガティブに関わらす拡大していく」という言葉がこの日の結論になったと思います。
• 言語のJITコンパイラをその言語自身で作る事の意義とは - Togetter
• コデラノブログ4 : メルマガ、始めます - ライブドアブログ
• Rubyでifやcaseで頻繁に評価されるものに対して小手先の工夫をしてもあまり意味がなかった - しょんぼり技術メモ
• koie blog : Python pypyでmercurialを動かしてみた
• モチベーションゼロのプログラマ志望者がモヒカンに相談したら実況されたでござるの巻 - Togetter

■_ Niecza Perl 6

Announce: Niecza Perl 6 v11 - nntp.perl.org

    Announce: Niecza Perl 6 v11

This is the eleventh release of Niecza Perl 6, as usual scheduled on
the last Monday of the month, at least in the US west coast time zone.

You can obtain a build of Niecza from [1].  This build contains a
working compiler as a set of .exe and .dll files suitable for use with
Mono or Microsoft .NET.  If you wish to follow latest developments,
you can obtain the source from [2]; however, you will still need a
binary for bootstrapping, so you gain nothing from a "source is
better" perspective.

Niecza is a Perl 6 compiler project studying questions about the
efficient implementability of Perl 6 features.  It currently targets
the Common Language Runtime; both Mono and Microsoft .NET are known to
work.  On Windows, Cygwin is required for source builds only; see the
README for details.

Niecza は、Perl 6 の機能の効率的な実装に関する疑問について学習する
Perl 6 コンパイラープロジェクトです。
現状のターゲットは Common Language Runtime です。
Mono と Micrrosoft .NETがそれとして知られています。
Windows では、ソースビルドのときにのみ Cygwin が必要となります。
詳しくは READMEを参照してください。


(略)

■_ Rust

以前にその名前を見たような覚えもあるんだけど、良く思い出せない。

Introduction


Section 1 of the Rust language tutorial.

Introduction

Scope

This is a tutorial for the Rust programming language. It assumes the reader is 
familiar with the basic concepts of programming, and has programmed in one or more 
other languages before. The tutorial covers the whole language, though not with the 
depth and precision of the language reference.

これは Rust というプログラミング言語のチュートリアルです。
読者としてはプログラミングの基礎的なコンセプトに慣れ親しんでいること、
一つ以上のプログラミング言語でプログラムを作ったことがある。という人を想定しています。
本チュートリアルでは言語全体をカバーしますが、一部はリファレンスに譲っています
# depth and precision はどうすべきか


FIXME: maybe also the stdlib?

Disclaimer

Rust is a language under development. The general flavor of the language has settled, 
but details will continue to change as it is further refined. Nothing in this tutorial 
is final, and though we try to keep it updated, it is possible that the text occasionally
does not reflect the actual state of the language.

First Impressions

Though syntax is something you get used to, an initial encounter with a language can be made
easier if the notation looks familiar. Rust is a curly-brace language in the tradition of C,
C++, and JavaScript.

  fn fac(n: int) -> int {
      let result = 1;
      while n > 0 {
          result *= n;
          n -= 1;
      }
      ret result;
  }

Several differences from C stand out. Types do not come before, but after variable 
names (preceded by a colon). In local variables (introduced with let), they are 
optional, and will be inferred when left off. Constructs like while and if do not 
require parenthesis around the condition (though they allow them). Also, there's a 
tendency towards aggressive abbreviation in the keywords—fn for function, ret for 
return.

C との違いがいくつか見て取れます。型は変数名の前にではなく後に、コロンをはさんで置かれます。
(let を使って導入される) ローカル変数では型は省略可能で、型は left off 時に推測されます。
while や if のような構造では条件を囲むカッコは必須ではありません(もちろんつけても
構いません)。また予約語に関して、function を fn、return を ret とするように
積極的に省略する傾向があります。

You should, however, not conclude that Rust is simply an evolution of C. As will become
clear in the rest of this tutorial, it goes into quite a different direction.

とはいえ、Rust を単純な C の進化形であるとみなすべきではありません。
このチュートリアルをすすめるに従って明らかになりますが、
全く異なる方向を目指しているのです。

■_

reddit での反響

Rust language tutorial (alpha version) : programming

What's special about rust than the slew of other languages that are already out there and mature?

Typestates are interesting. I don't know if they'll pan out, but they're a nice 
concept. And they're used to (as far as I'm concerned) build far safer coroutines than 
Go's, from reading the documents (and again if typestates pan out) they look almost as 
safe as Erlang's.

Also, no null pointers. That's a decision I fully support. Rust is full of 
"small" decisions which I think go in the right direction.

came here to say this, can OP elaborate?

Sure:

    * http://en.wikipedia.org/wiki/Rust_(programming_language)
    * http://lambda-the-ultimate.org/node/4009
    * http://pcwalton.blogspot.com/2010/12/c-design-goals-in-context-of-rust.html
    * http://news.ycombinator.com/item?id=3027777
    * http://news.ycombinator.com/item?id=1498528

For the lazy: http://en.wikipedia.org/wiki/Rust_(programming_language)

I think programming languages are interesting and successfull based on both their 
technical merits and their ecosystem.

For the technical aspects, please refer to the links i've posted below.

For the ecosystem: it is a Mozilla project, people are payed to work on it, it has 
quite some committers and at least on GitHub it has 4-5 times as many followers as e.g. 
the D programming language.

There is quite some interest and potential.

i think it is a bit weird that rust doesn't support 64-bit archs yet. anyone know the reason?

■_ らむだ

C++11 lambda tutorial | Solarian Programmer

C++11 lambda tutorial
Posted on November 1, 2011 by Sol

In my previous tutorials I've presented some of the newest C++11 additions to the language:
regular expressions and raw strings. Another useful language addition is lambda, a lambda
expression allows you to define and use anonymous functions inline (functions with a body
but without a name). You can use a lambada expression instead of a function object, avoiding
the need to create a separate class and a function definition. This is useful for example
when you need a one-line expression to interact with many of the STL algorithms.

Lambda expressions are currently available in g++-4.6.x and Visual Studio 2010, you can not
use lambda with llvm and clang.

lambda 式は現状で、g++4.6.x と Visual Studio 2010 で利用できますが、llvm や clang では使えません。

Let's create a (useless) simple example of lambda expression that will return a number:

数値を返すlambda 式の(役に立たない)例をを書いてみましょう


  []()->int{return 4;}();

Obviously the above code will do nothing visible (actually it will return an integer),
we can use it to print 4 on the console:

上記のコードは visible でないことをやっています (実際には整数を返します)が、
これを使ってコンソールに 4を出力できます。

  int result=[]()->int{return 4;}();
  cout<<result<<endl;

A slightly more useful example that will receive as input an integer and will return twice
this number:

より有用な例として、整数を入力としてそれを2倍にして返すものです

  int result=[](int input)->int{return 2*input;}(10);
  cout<<result<<endl;

From the above examples the syntax of a lambda expression can be written (this is not
the complete syntax of a lambda expression):

上記の例でのlambda 式の構文は次のように書けます
(これは完全な lambda 式の構文ではありません)。

  [](input_paramter_declaration)->returned_type {body_of_the_lambda_expression}(parameters)

A lambda expression that will add two numbers and will return the result can be written as:

二つの数値を加算してその結果を返す lambda 式は次のように書けます

  int result=[](int a,int b)->int{return a+b;}(2,4);
  cout<<result<<endl;

We can use a lambda expression inside another lambda expression, combining the above
examples we can create a slightly more complex example:

ある lambda 式を別の lambda 式の内側で使うこともできます
これまでの例を組み合わせてより複雑な例を作ります

  int result=[](int m,int n)->int{return m+n;}([](int a)->int{return a;}(2),[](int a)->int{return a;}(3));
  cout<<result<<endl;

If you need to use more than once a lambda expression it could be cumbersome to copy
the same piece of code, you can use a pointer to the lambda expression:

  auto func=[](int a,int b)->int{return a+b;};
  cout<<func(2,3)<<endl;

The auto keyword will take care to define func as a pointer to the lambda expression.

予約語 auto を使って lambda 式へのポインターとして func を定義します

Suppose we need to need to sort a vector of integers, using the sort algorithm from
C++98 this can be implemented:

sort アルゴリズムwを使ってinteger の vector をソートする必要があるとしましょう。
C++98 では次のように実装できます

 #include <iostream>
 #include <vector>
 #include <algorithm>

 bool compare(int i,int j){return (i<j);}

 using namespace std;

 int main()
 {
     int n=10;
     vector<int>v(n);
     //initialize the vector with values from 10 to 1
     for(int i=n,j=0;i>=0;i--,j++)v[j]=i;
     //print the unsorted vector
     for(int i=0;i<n;i++)cout<<v[i]<<" ";cout<<endl;
     //sort the vector
     sort(v.begin(),v.end(),compare);
     //print the sorted vector
     for(int i=0;i<n;i++)cout<<v[i]<<" ";cout<<endl;

     return(0);
}

Using a lambda expression we can achieve the same result by avoiding to declare a compare function:

lambda 式を使って、同じ結果を比較関数を宣言することなしに得られます:

 #include <iostream>
 #include <vector>
 #include <algorithm>

 using namespace std;

 int main()
 {
     int n=10;
     vector<int>v(n);
     //initialize the vector with values from 10 to 1
     for(int i=n,j=0;i>=0;i--,j++)v[j]=i;
     //print the unsorted vector
     for(int i=0;i<n;i++)cout<<v[i]<<" ";cout<<endl;
     //sort the vector
     sort(v.begin(),v.end(),[](int i,int j)->bool{return (i<j);});
     //print the sorted vector
     for(int i=0;i<n;i++)cout<<v[i]<<" ";cout<<endl;

     return(0);
 }

For the ones interested in learning the new C++11 syntax I would recommend reading
Professional C++ by M. Gregoire, N. A. Solter, S. J. Kleper 2nd edition:

C++11 の新しい構文に興味を持った人には、
M. Gregoire, N. A. Solter, S. J. Kleper による
Professional C++ 2nd edition を読むことをお勧めします


This entry was posted in Uncategorized and tagged C++11, gcc, lambda.

■_

Sutter's Mill

People keep asking me where to find good information on C++11. Until now I've had to point
them to blogs, and say that we're all working on revising our books but it'l take a while.
It's been an unsatisfying answer.

Finally I have a C++11 “book” I can direct people to: Today Scott Meyers announced that
his fully-annotated C++11 training materials are now up-to-date with the final published
standard.

This is the best overview of C++11 available today, and it's good:

■_

前作と同じく、OP 曲は初回限定版につくというパターンなので買った。
WORKING´!!　1【完全生産限定版】 [Blu-ray]

まだ I の途中なんだけどIIが出てしまった

読み終わってから何か書くかもしれないし書かないかもしれない。

■_ The Book That Every Programmer Should Read

ずらずら何冊も挙げられてるのかと思ったらそうではなかった。

The Book That Every Programmer Should Read » Online Hut

The Book That Every Programmer Should Read
by 10098 Posted on October 31, 2011

No, it's not Knuth's “The Art of Programming”. I'm talking about quite an easy-to-read
(compared to TAoP) book, which, in fact, does not require any engineering or mathematical
background from the reader.

いいえ、Knuth の “The Art of Programming”ではありません。
#あれ 「computer」は
わたしがお話しするのは (TAoPと比較して)読みやすい本についてで、
工学に関する知識だとか数学の知識を必要としないようなものです。


I am talking about C. Petzold's “CODE”. It is a truly remarkable book about how computers
work. Let me explain why I think this book is so awesome.

わたしが紹介するのは C. Petzold の “CODE”です。
これは、コンピューターがどのように動作しているかについて書かれている本当に注目すべき本です。
この本がなぜそんなに価値あるものなのかについて説明させてください。

The book starts from the very beginning, from explaining what code is, bringing 
several examples, like Morse code and Braille's system. It then goes on to explain how 
electricity works and how it can be used to represent information with binary codes.

この本は非常に初歩、コードとはどういったものであるかということの説明から始まり
モールス符号や Braille のシステムなどを例に出しています。
それから電気的にどのように動作しているのかを説明し、
て二進コードを使ってどのように情報を表現できるのかといった説明に進みます。

In later chapters, Boolean algebra is explained and the author shows us how to build 
basic components of circuits (logic gates) with battery, wires and simple relays. 
Those are used later to build an 8-bit adder circuit and a RAM array. Eventually, the 
author describes a computer with a simple instruction set and random-access memory.

あとの章ではブール代数が説明され、著者は電池と wire と単純なリレーとを使って
わたしたちに回路(ロジックゲート)の基本的なコンポーネントがどのように組み立て
られているのかを見せてくれます。
それらはあとで8ビットの加算回路やRAM array を構築するのに使われます。
さらに、著者は簡単な命令セットとランダムアクセスメモリーを持ったコンピュータを
解説します。

This book is so amazing because it shows how simple principles can be combined to 
create the basis of the complex modern technology. You should read it to (at least 
approximately) understand what really goes on behind all the loops, pointers, 
variables, jumps and complex data structures. It won't give you insights about the 
inner workings of Intel's processors, but you will understand the basic things which 
make that pile of plastic and metal do math, display pretty moving pictures and 
download pr0n from the internets. Which is very important.

この本は、単純な原理原則 (principles) が複雑な近代テクノロジーの基礎を作るために
組み合わせることができるのを示していることでとても amazing なものです。
あなたは、ループやポインター、変数、ジャンプ、複雑なデータ構造といったもの
すべての背後に隠れているものを(少なくとも大まかには)理解するためにこの本を読むべきなのです。
この本はインテルのプロセッサーの内部動作についての insight は与えてくれませんが、
計算や pretty な moving pictures の表示、インターネットからのダウンロード
を行うプラスチックと金属の pile が行っている基本的なことがらを理解することでしょう。


P.S.

During my second year at the university we were taught a course which was called “
Computer Architecture”. What we really did during that course can be summarized as 
(painful) memorization of 8086′s instructions and writing a few programs in freaking 
Turbo Assembler (the year was 2008, by the way).

If only instead of all that crap we were taught what was written in Petzold's book, it 
would've been one of the most useful courses ever, because:

    * It would really be about computer architecture and not about memorizing instructions
      or writing programs for a painfully outdated compiler;

    * I would actually learn something.

That is all.

CODE は日本語訳も出ています。 タイトルがレッシグ先生のと被っているので探しにくいかも知れません :)

CODE コードから見たコンピュータのからくり

■_

ちょっと前にこういう話題がありまして(redditでは結構伸びた)。 Don't Call Yourself A Programmer, And Other Career Advice | Kalzumeus Software Don't Call Yourself A Programmer : programming あなたは「プログラマー」ですか？ | スラッシュドット・ジャパン デベロッパー

で、これ I am a programmer | jacquesmattheij.com

I am a programmer | jacquesmattheij.com

I am a programmer

Submitted by administrator on Tue, 11/01/2011 - 04:04.

Admitting that may be career suicide, or possibly it will cost me dearly because 
'software engineers' are raking in the big bucks these days, but the fact of the 
matter is that I'm a programmer. It's what I do best and it is the job title that I 
associate with most because it feels as though the biggest chunk of me will always be 
most likely to blurt that out when people ask me what my job is. That I like to 
program definitely helps.

So instead of choosing some fancy title for what it is that I do because that might 
possibly make me a bit more money I chose to embrace it, and I have yet to regret that 
decision. A job title might make a little bit of difference but it's not going to be a 
huge factor and it is important to keep that in mind. A/B testing your job title is 
focusing on the wrong part of the problem, think of it as premature optimization.

(略)

If you think that 90% of all software is written to power 'the enterprise' or 'the 
web' then you have a very limited view of the incredibly varied world of software. 
Sure, there are lots of people working on enterprise software and building websites, 
but there are also vast legions of people working on much more technical software in 
specialist fields like CAD, bio-informatics, gaming, engineering, embedded systems, 
process control and literally 1000's of other fields. And in my opinion that's where 
the more interesting work is being done. It is harder nowadays to find a field that 
does not have a software component somewhere than one that does. Almost none of that 
software is going to be facing 'the user', most of it is invisible but there are 
virtual oceans full of it.

It is probably best to strive for a balance between job satisfaction and pay, and not 
to worry too much about the titles. Worry about whether or not your work brings you 
pride, whether it is interesting, and whether it brings a smile to your face when you 
think about it, or when you tell others about it. About whether or not what you do is 
meaningful and whether it affects peoples lives in a positive way. If you do feel that 
your title is a major factor in how much you earn or are appreciated you may want to 
ask yourself if you're working in the right place and on the right stuff to begin with.

Pay is important, but above a certain level you'll find that job satisfaction is 
literally priceless.

I am a programmer. And I'm proud of that.

訳すには余裕がなっしんぐ

■_

日本人作家(という表記で良いのだろうか)による C++11の解説本やら入門書が出るのはいつか。 とか考えてみたり。

C++11 / C++0x Documentation « Punch Card


C++11 / C++0x Documentation

You want to improve your “old” C++ code base by allowing new features or bug fixes 
to be enhanced with C++11? The questions you will face on the way are manifold. First, 
what exactly allows me C++11 to do? Where is some documentation? What is the purpose 
of those features. Compared to languages like Ruby or Python the C++ standard library 
and language itself is not too well documented online.

あなたは自分の“古い” C++ のコードベースを新しい機能を使うことで改良したり、
C++11の拡張でバグ修正したいと思いませんか? 
The questions you will face on the way are manifold.
C++11 でわたしにできることってどういうものですか?
ドキュメントはどこにありますか?
新しい機能の目的は何でしょうか。
Ruby や Python のような言語と C++ の標準ライブラリを比較したとき、
言語そのもののドキュメントはネット上にはあまりありません。


As a preparation for a lecture I'm holding in the next semester I was compiling a list 
of links to C++11 / C++0x documentation sites and as some kind of personal archive I 
will post them here:

General C++11 / C++0x FAQ

    * General C++0x FAQ, explains all the features -
      http://www2.research.att.com/~bs/C++0xFAQ.html

New Features (Overview)

    * Modern C++ -
      http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-835T

    * Changes with C++11 / C++0x -
      http://www.softwarequalityconnection.com/2011/06/the-biggest-changes-in-c11-and-why-you-should-care/

    * Modern C++
      http://herbsutter.com/elements-of-modern-c-style/

    * Overview of the most important C++11 features with examples
      http://www.georgeflanagin.com/c++11/

    * Simpler Multithreading in C++11 -
      http://www.devx.com/SpecialReports/Article/38883/0/page/1

Compiler Support

    * GCC – http://gcc.gnu.org/projects/cxx0x.html
    * Clang – http://clang.llvm.org/cxx_status.html

Standard Library Documentation

    * http://en.cppreference.com/w/cpp

I will update this list as I find new sources. If you have any more links you think 
that are missing, please mention them in the comments and I will add them.

新しいソースが見つかるごとにこのリストを更新します。
もしなにか欠けているものがあると思ったら、コメント欄で知らせてください。
それを加えるようにします。

-Martin

■_ Scheme を Python で

Scheme in Python « Blog 4

Scheme in Python

The Scheme in Python project is a port of the Scheme in Scheme project. The goal is to 
implement a small subset of Scheme as an interpreter written in Python.

Scheme in Python プロジェクトは Scheme in Scheme プロジェクトの port です。
その目標はScheme の小さなサブセットのインタープリターを
Pyton を使って実装することです。

There are a number of goals for this project. First, implementing Scheme in Scheme 
allowed us to “cheat” a bit by having access to the Scheme reader and data 
structures. Using Python as the implementation language will force us to code the 
reader by hand and create new data structures where there isn't a one-to-one mapping 
from Scheme to Python.

本プロジェクトの目標はいくつかあって、第一に、
Scheme で Scheme を実装することは、Scheme の reader や data 構造にアクセスすること
による "チート"できてしまいます。
Python を実装言語として使うことで reader を自分の手でコーディングすることが強制され、
Scheme から Python へとマッピングする one-to-one でない新しいデータ構造を
作り出さなければならなくなります。

There are also two auxiliary goals to this project. Using Python should make this more 
accessible to programmers who are interested in language development, but are 
unfamiliar with Scheme. Also I'm using this project as a way to familiarize myself 
with branching and merging in git, so each post will correspond to a branch in the 
repository.

All the code for this project will be hosted on GitHub. The code is licensed under a 
BSD license if you are interested in forking it for any reason.

This series will focus on building a very simple interpreter for the purpose of 
learning the steps involved in building one. For this reason there will be no/very 
little error checking or optimization. This port will be slightly more complicated 
than Scheme in Scheme so if you are interested in an even simpler interpreter look 
here.



Part 0 | Reading from stdin
Part 1 | Numbers
Part 2 | Extending the read layer
Part 3 | Pairs and linked lists
Part 4 | Self-evaluating values
Part 5 | Assignment and define
Part 6 | scheme-syntax macro
Part 7 | Refactor and load
Part 8 | Primitive procedures and apply
Part 9 | Environments
Part 10 | lambda

(以下略)

■_ Cコンパイラー

ET2011_25周年特別座談会「日本の組込み業界の過去・現在・未来を語る」は昔懐かしい話が満載－メーカー側の事情がわかって面白い: 組み込み技術者の単身赴任日記 経由で。

ET2011_25周年特別座談会｜Tech Village （テックビレッジ）　／　CQ出版株式会社

●●●ツールの進化　コンパイラと言語系

～初期のマイコン，組込みはアセンブラ中心だったようですが，Cはどうだったのでしょうか．
山本：インターフェース誌で最初にCの記事をやったのは1981年ですね．

(略)

～半導体メーカではコンパイラは作らないのですか．
河原：16ビット，32ビット系になると，プロセッサの開発過程でコードを調べるためのCコンパ
イラが必要で，何らかのものは作る必要があります．ただ，外販するようなタイプにするのはた
いへんだし，自社のプロセッサのためだけに技術者を丸抱えして，1社内で自社のためだけに全
部やっていくというのは難しくなっていますね．各社でアライアンスを組んでアウトソーシング
できる仕組みを作っておけば良かったのではないかと思いますね．

～海外の半導体メーカもそうなのでしょうか．
河原：アメリカの場合は，そういった言語処理の開発部門は，独立して成り立つようになってい
ると思います．あるいは，成り立っているところを買収したりとかしていますが，いずれにして
も，あくまでもプロフィットを出すというのが前提ですね．利益を出さなくていい，コストセン
ターでいいという考え方はないですね．

　あと，Cコンパイラのパーサと構文解析，これは今一体になっていますが，サポートしている
のは世界でただ1社，Edison Design Groupしか，私は知りません。ほとんどの半導体メーカは同
社からそれを買ってるんですね．もう同じなんです，入り口は．ついでに言いますと，ライブラ
リはDinkumware社（Whitesmiths社を設立したP. J. Plaugerが設立）がメインの提供元です．

Copyright 2001-2011 CQ Publishing Co., Ltd.

CQ出版社

構文解析部分をそういうふうに売ってるのかあ。

九州のほうで、C++はどーなんだとか言ってる声が聞こえるような気がしないでもない(謎)

あるじゃん (03レベルみたいだけど) Edison Design Group

Edison Design Group

What is a "front end", anyway?

A compiler --- a program that translates a source program as written by a programmer 
into the ones and zeroes that a computer understands --- is often broken down into a 
"front end", which translates the source program into some intermediate 
language, and a "back end", which translates the intermediate language into 
machine language. Some compilers also have a "middle end", which does 
optimizations on the intermediate language.

How can EDG get away with selling half a product?

Our front ends are complete products; they're just not end-user products. We sell to 
companies that use our front ends as part of compilers and source analysis tools they 
develop. Those  companies sell to end users.

How well do your front ends conform to the applicable standards? 

Extremely well. As far as we know, no one has better pass rates on the commercial test 
suites, and we have and use almost all of them. We're pleased to be able to say that 
with the 3.8 release of our C++ Front End we have no failures (aside from a handful of 
test cases for which there are pending issues being considered by the standards 
committee) with the Perennial and Plum Hall C++ test suites, when our front end is 

■_

• フリーソフトウェアのインデックスサイトFreshmeat、「Freecode」に名称変更 - SourceForge.JP Magazine : オープンソースの話題満載
• Japan's IT Exodus: A Personal Perspective (Part 1) ・ Global Voices
• Java Developer Workshop #2で『新世代オブジェクト指向言語Scalaの魅力』の発表をします - Onion開発しつつ、PEGEXを開発する日記
• Java Developer Workshop #2
• wrong, rogue and booklog - Why did Quora choose Python for its development?...
  QuoraのファウンダーがQuoraがPythonを選択した理由を語る。
• Use it Better: Secret Easter Eggs: Scientific American
  These days, software engineers' overlords generally don't tolerate true, secret Easter eggs.
• 痛いテレビ : 何故すき家は強盗対策をして来なかったのか
• MagLev
  MagLev 1.0.0 was released on October 31, 2011.
• レポート：開発者の祭典「Google Developer Day 2011 Tokyo」開催―Android，Chrome，App Engine，そしてGoogle+，その先にある未来が見えた1日｜gihyo.jp … 技術評論社
• Cのプログラムに変換(1/2) | OKWave
  どなたかこのプログラムをCに変化してくれる方いませんか？ なんで変換するのとかの質問はいらないです。ただ純粋に変換してくれる方いませんか？
• 祝・販売開始1周年 - 達人出版会日記
• だいありー
  2.0 でやりたいリスト．書かないと忘れちゃう．
• 今までの研究が破綻してしまい、卒業の危機に直面しています。機械との対話がテー... - Yahoo!知恵袋
• ジョブズもゲイツも「ウィンドウ」をまねた？　　ＤＥＣをめぐる伝説と夢物語（上）　：日本経済新聞
• USP友の会、日本 GNU AWK ユーザー会と友好団体に - USP友の会
• 自分自身を削除する-Win32プログラミング日記
• F# Programming - Wikibooks, open books for an open world
• 2012年に注目すべき10のトレンド--IT業界で重要性が高まるテクノロジとは - CNET Japan