ときどきの雑記帖'

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

一つ前へ 2013年11月(上旬)
一つ後へ 2013年11月(下旬)

ホームへ

2013年11月20日

■_

朝起きてもまだ暗いせいか、二度寝してちょっと焦る事態が頻発。

■_ 今日の重箱

すみません。まとめきれませんでした ○| ̄|_ 明日にはどうにか…できるかなあ

ちょっと前の記事ですが、今日になって初めて通して読んでみたら気になったので。 規模の大きい本番システムをGo言語で書き直した感想 - ワザノバ | wazanova Volatile and Decentralized: Rewriting a large production system in Go

■_ 今日の重箱 その2

[その2] RubyとPythonの違いからガベージコレクタを理解する - ワザノバ | wazanova Generational GC in Python and Ruby - Pat Shaughnessy

[その2] RubyとPythonの違いからガベージコレクタを理解する - ワザノバ | wazanova

    1) Pythonの循環データ構造と参照カウント

    Pythonは、いくつのポインタがそのオブジェクトを参照しているかを、参照カウントと呼ばれる整数で管理している。
    変数もしくはオブジェクトが、そのオブジェクトを参照しはじめれば数字が増えて、プログラムがそのオブジェクトを
    使うのをやめれば数字が減る仕組み。

    1960年代以来、コンピュータ科学者が気づいているアルゴリズムの問題に循環データ構造がある。参照カウントがゼロ
    にならないパターンがある。

    まず、インスタンス変数にひとつの属性をもつコンストラクタ(Pythonでは、_init_ と呼ばれる。)を用意する。ポイ
    ンタn1とn2が、それぞれABCとDEFを参照する。[図とコード]

    そして、n1.nextとn2.prevという属性を追加する。[図とコード] Rubyと違ってPythonはインスタンス変数やオブジェク
    ト属性をこのように自然に定義できる。(PatはPython開発者でないので用語が違ってるかもしれない言ってます。)
    n1.nextはn2を、n2.prevはn1を参照し、お互いを参照するポインタが追加されることにより、ABCとDEFの参照カウントは
    それぞれ2になる。

    次に、Pythonのプログラムがノードの利用をやめて、n1とn2がnull(PythonではNone)となったとする。PythonはABCと
    DEFの参照カウントを1に下げる。[図とコード]

Generational GC in Python and Ruby - Pat Shaughnessy

Cyclic Data Structures and Reference Counting in Python

We saw last time that Python uses an integer value saved inside of each object, known as the reference count,
to keep track of how many pointers reference that object. Whenever a variable or other object in your program
starts to refer to an object, Python increments this counter; when your program stops using an object, Python 
decrements the counter. Once the reference count becomes zero, Python frees the object and reclaims its memory.

Since the 1960s, computer scientists have been aware of a theoretical problem with this algorithm: if one of
your data structures refers to itself, if it is a cyclic data structure, some of the reference counts will
never become zero. To better understand this problem let’s take an example. The code below shows the same Node 
class we used last week:


We have a constructor (these are called __init__ in Python) which saves a single attribute in an instance
variable. Below the class definition we create two nodes, ABC and DEF, which I represent using the rectangles
on the left. The reference count inside both of our nodes is initially one, since one pointer (n1 and n2,
respectively) refers to each node.

Now let’s define two additional attributes in our nodes, next and prev:

Unlike in Ruby, using Python you can define instance variables or object attributes on the fly like this. This
seems like a bit of interesting magic missing from Ruby. (Disclaimer: I’m not a Python developer so I might
have some of the nomenclature wrong here.) We set n1.next to reference n2, and n2.prev to point back to n1. Now
our two nodes form a doubly linked list using a circular pattern of pointers. Also notice that the reference
counts of both ABC and DEF have increased to two. There are two pointers referring to each node: n1 and n2 as
before, and now next and prev as well.

Now let’s suppose our Python program stops using the nodes; we set both n1 and n2 to null. (In Python null is
known as None.)

Now Python, as usual, decrements the reference count inside of each node down to 1.


Content and UI design © 2013 Pat Shaughnessy — powered 

訳文の「変数もしくはオブジェクトが、そのオブジェクトを参照しはじめれば数字が増えて」 の部分、 「Whenever a variable or other object in your program starts to refer to an object, Python increments this counter;」 だと思うんですが、「『その』オブジェクト」じゃあないような >「refer to an object」 そして原文の 「Once the reference count becomes zero, Python frees the object and reclaims its memory.」 が丸々ない。と。

「Since the 1960s, computer scientists have been aware of a theoretical problem with this algorithm:」 「1960年代以来、コンピュータ科学者が気づいているアルゴリズムの問題に循環データ構造がある。」 ここで 「aware」 が 「気づいている」はないんじゃないかと。 そして 「theoretical problem with this algorithm」の「this」が訳文から抜けてるのは 下手すれば意味が変わりかねないような。

まず、インスタンス変数にひとつの属性をもつコンストラクタ(Pythonでは、_init_ と呼ばれる。)を用意する。ポイ ンタn1とn2が、それぞれABCとDEFを参照する。[図とコード] そして、n1.nextとn2.prevという属性を追加する。[図とコード] Rubyと違ってPythonはインスタンス変数やオブジェク ト属性をこのように自然に定義できる。(PatはPython開発者でないので用語が違ってるかもしれない言ってます。) n1.nextはn2を、n2.prevはn1を参照し、お互いを参照するポインタが追加されることにより、ABCとDEFの参照カウントは それぞれ2になる。 これ、原文もちょっと意味がとりにくいかなという感じはありますが、 .next と .prev という属性が追加されたのは一体なんでしょうか? 表記上は n1.next、n2.prev のようになっているので n1やn2 にくっついたように感じますが これら二つは「ポインター」であり、属性が追加されたのは 「Now let’s define two additional attributes in our nodes, next and prev:」 そのポインターが指している「ノード」ですよね。

「インスタンス変数にひとつの属性をもつコンストラクタ(Pythonでは、_init_ と呼ばれる。)を用意する。」 これもちょっとおかしい? 「We have a constructor (these are called __init__ in Python) which saves a single attribute in an instance variable. 」 ある(ひとつの)インスタンス変数「(の中)で」save a single attribute するコンストラクターじゃないでしょうか。

■_

■_

2013年11月19日

■_

チューリング: 情報時代のパイオニア
チューリング: 情報時代のパイオニア 読み終わった。 ACE はもっと知りたいなあ。なんか良い本ないかしらん。 あとでなんか書くかはわからない。

■_

意外に手こずった○| ̄|_ なんか日本語訳もすぐに見つけられると思ったんだけどだめだー

ドナルド・ラムズフェルド - Wikipedia you go to war with the army you have---not the army you might want or wish to have at a later time. (Remembering Rumsfeld: "You go to war with the army you have---not the army you might want or wish to have at a later time. | Crooks and Liars) 意外に最近の人だった(名前は知ってたけど顔を覚えてなかった)。

カール・フォン・クラウゼヴィッツ - Wikipedia War is the realm of uncertainty; three-quarters of the factors... 戦争論 日本語版だとこのどうなってたっけなあ。ここまで詳細に場所を書かれても手元にないのでわからん。

レフ・トロツキー - Wikipedia Leon Trotsky - Wikiquote によると

Leon Trotsky - Wikiquote

Misattributed

    You may not be interested in war, but war is interested in you.

        This was attributed to Trotsky in an epigraph in Night Soldiers: A Novel (1988) by Alan Furst but it
        may actually be a revision of a statement earlier attributed to Trotsky: "You may not be
        interested in the dialectic, but the dialectic is interested in you." Only a very loose translation
        of "the dialectic" would produce "war."

        In a later work, Just and Unjust Wars: A Moral Argument with Historical Illustrations (2000) by Michael
        Walzer, the author states: War is most often a form of tyranny. It is best described by paraphrasing
        Trotsky's aphorism about the dialectic: "You may not be interested in war, but war is interested
        in you."

        This statement on dialectic itself seems to be a paraphrase, with the original in In Defense of Marxism
        Part VII : "Petty-Bourgeois Moralists and the Proletarian Party" (1942) — where Trotsky
        publishes a letter to Albert Goldman (5 June 1940) has been translated as "Burnham doesn't
        recognize dialectics but dialectics does not permit him to escape from its net." More discussion
        on the origins of this quotation can be found at The Semi-Daily Journal of Economist Brad DeLong: Fair
        and Balanced Almost Every Day

ということで日本語では見つからず。 レフ・トロツキー - Wikiquote トロツキーの名言

ウィンストン・チャーチル - Wikipedia Quote Details: Sir Winston Churchill: Never, never, never believe... - The Quotations Page

Quote Details: Sir Winston Churchill: Never, never, never believe... - The Quotations Page

Never, never, never believe any war will be smooth and easy, or that anyone who embarks on the strange
voyage can measure the tides and hurricanes he will encounter. The statesman who yields to war fever must
realize that once the signal is given, he is no longer the master of policy but the slave of unforeseeable
and uncontrollable events.

これも日本語のが見つからなかった。第二次世界大戦の時の演説かとも思ったんだけど外れ。 チャーチル名言・格言集(英語・英文と和訳) | 名言+Quotes

ルートヴィヒ・ウィトゲンシュタイン - Wikipedia Nowadays it is the fashion to emphasize the horrors of the last war. I didn't find it so... - Ludwig Wittgenstein at BrainyQuote ルートヴィヒ・ウィトゲンシュタイン - Wikiquote 哲学者・ウィトゲンシュタインの発言・格言・名言集【論理哲学論考】 - NAVER まとめ

ジョン・アダムズ - Wikipedia Great is the guilt of an unnecessary war. - John Adams at BrainyQuote Quote by John Adams: Great is the guilt of an unnecessary war. John Adams - Wikiquote

孫武 - Wikipedia The supreme art of war is to subdue the enemy without fighting. - Sun Tzu at BrainyQuote これは この故に百戦百勝は善の善なるものにあらず。戦わずして人の兵を屈するは善の善なるものなり。 (孫子3)。 の後半だと思うんだけど英文が Hence to fight and conquer in all your battles is not supreme excellence; supreme excellence consists in breaking the enemy's resistance without fighting. 微妙に違うんだよなあ。

ガイウス・ユリウス・カエサル - Wikipedia これはもう 来た、見た、勝った - Wikipedia

しかし向こうの参加者は顔写真と 改変した名言だけ見てパッと誰が言ったなんと言う言葉だかわかるんすかね。 すぐに分かったの3人だけ(チャーチル、クラウゼヴィッツ、カエサル。孫武は絵がなんか違う気がした)だったわ○| ̄|_

どれも良くできてると思うんだけど、 「The supreme art of programming is to solve problem without code」 は某氏辺りも好きそうな言い回しじゃなかろうか。

■_

なんかその1とのブックマーク数の差が…w はてなブックマーク - [その2] RubyとPythonの違いからガベージコレクタを理解する - ワザノバ | wazanova.jp

■_ 30行計画(違)

Breakout in 30 lines of JavaScript | Hacker News 最近よく30行のJavaScriptで~を見かける気がしたので調べてみると HNSearch - Hacker News Search

■_

2013年11月18日

■_

わーすーれーてーたー ○| ̄|_ イデオンリーからトミケットへ

なんかすげーありがたいものも。 Software reliability に関するものもあるし。 15 Free eBooks On Algorithm! 25 Free eBooks For Software Engineers!

■_ Scala war stories

Oracle Releases Videos and Slides from the 2013 JVM Language Summit にあったリンクの一つ「Scala war stories」のスライドがなかなか。 その一部を。

答え合わせは(たぶん)明日

■_ Java 8

Java SE 8 lambdaで変わるプログラミングスタイル - きしだのはてな Java 8 の lambda といえばこういう本が Manning: Java 8 Lambdas in Action まだ MEAP ですけどね。 ちょっと見たところなかなか面白そう。

■_

2013年11月17日

■_

忘れないように録画設定と。 Twitter / tokyometro_info: 11月18日(月)24時20分から放送予定のお願い!ランキン ...

電脳空間カウボーイズZ、 インドの携帯電話メーカーの話も興味深かった と言うのを書くのを忘れていた。

なんか最寄り駅の近くにコワーキングスペースがあったらしい。 ちょっと寄り道して見つけたんだけど どんな感じなんだろか。

■_

Willa's World: The Six Most Common Species Of Code うーむ。メインのプログラム6本画像でやんの…

Willa's World: The Six Most Common Species Of Code

    SubhrajitNovember 10, 2013 at 11:51 AM

    so no one gives a sh!t about the computational complexity. All the recursive implementations have exponential complexity. And I seriously have no clue what the author tried to prove with the totally gibberish large company or math PhD code.

    How about the following:
    int fibonacci(int x){
    if (x <= 2)
    return 1;
    else {
    int sum = 1, oldsum = 1, tmpsum;
    for (int a = 3; a <= x; a++) {
    tmpsum = sum;
    sum = sum + oldsum;
    oldsum = tmpsum;
    }
    return sum;
    }
    }

    It has linear complexity.
    UnknownNovember 10, 2013 at 12:36 PM

    A database specialist would write

    SELECT Value FROM dbo.Fibonacci WHERE n = @n;
    acNovember 11, 2013 at 6:25 AM

    is missing the kernel guy code:

    int fib(int n) {
    if (n < 0) {
    #ifdef HAVE_ERRNO
    errno = EDOM;
    #endif
    return -1;
    }

    return n == 0
    ? 0
    : (n == 1
    ? 1
    : (n == 2
    ? 2
    : fib(n - 2) * fib(n-1)
    )
    );
    }
    tsndiffoperaNovember 11, 2013 at 7:08 AM

    Phew! Then who'd write a O(lg(n)) algorithm using matrix exponentiation ? Only me? :P

    [{1 1},{1 0}]^n = [{F_(n+1) F_n},{F_n F_(n-1)}]

    Also, x^n = x^(n/2)*x^(n/2)

    which has O(lg(n)) ;)
    Welcome to KarnaNovember 11, 2013 at 10:13 PM

    Code as written by a hacker:

    public int fib(int n) { return (n > 2) ? fib(n-1)+fib(n-2):0; }

    Code as written as a seasoned: developer


    import org.apache.commons.math;
    public int fib(int n) {
        return Math.fibonacci(n);
    }
    Simon Richard ClarkstoneNovember 12, 2013 at 10:04 AM

    Code written by a type theorist. (It calculates Fibonacci numbers in the Haskell type system.)


    {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, FlexibleInstances, UndecidableInstances #-}
    data Zero
    data Succ n
    class Add a b c | a b -> c
    instance Add Zero b b
    instance Add a b c => Add (Succ a) b (Succ c)
    class Fibb a b | a -> b
    instance Fibb Zero Zero
    instance Fibb (Succ Zero) (Succ Zero)
    instance (Fibb a r1, Fibb (Succ a) r2, Add r1 r2 b) => Fibb (Succ (Succ a)) b


    To calculate, you need to create placeholder values with appropriate types, and ask the interpreter what type the combination of the two would have.

    *Main> let fibb = undefined :: (Fibb a b) => a -> b
    *Main> let six = undefined :: Succ (Succ (Succ (Succ (Succ (Succ Zero)))))
    *Main> :t fibb six
    fibb six
    :: Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ Zero)))))))

あんま面白くなかったかな

■_

放送大学、なんか面白そうな特別講義が。ちょっと先だけど テレビ番組表|特別講義一覧表 自然科学 (33) 江戸に咲いた和算の夢 ~数学者・関孝和物語~ (40) 情報セキュリティ ~デジタル社会を守る技術と制度~ とか テレビ番組表|特別講義一覧表 社会科学 (28) 江戸時代のからくり文化 ~座敷からくりに見る日本のエンジニアの源流~ あたり。

■_

2013年11月16日

■_

アキバ系!電脳空間カウボーイズZ 「さらばアスキー!!」の後編。面白かったけど 2時間ちょい…w 「ネットでは代替できない(できていない)記事」とか ハイパーカードであれとか。

今日見かけたんだけどこれ欲しいなあ。 オルドビス紀・シルル紀の生物 (生物ミステリー (生物ミステリープロ)) エディアカラ紀・カンブリア紀の生物 (生物ミステリー (生物ミステリープロ)) つっても置き場に困るか。 そうするとこういうのも…と Kindle Fire HD 7 8GB タブレット

2学期が始まってたんだわねそういえば。 「ソフトウェア工学」の講座はFMで「聴く」よりないっぽい。 テレビ番組表|放送授業期間

■_

「プログラマー」と答えて困ったことはない。かな?

組み込みプログラマー雑談スレッド その27

901 仕様書無しさん [sage] 2013/11/16(土) 06:05:26.81 ID: Be:
    周りに仕事何やってるか聞かれたら何て答えてる?

    「ソフトウェア開発やってます」⇒「IT系ですか?SE?」⇒「うーん、まぁそうだけど、SEとは若干違うかな」
    「組込みやってます」⇒「組込みって何ですか?」
    「○○(製品名)の開発やってます」⇒「へぇ・・・よくわからない」
    「○○(製品名)のソフトウェア開発やってます」⇒「○○のソフトウェア??」 

902 仕様書無しさん [sage] 2013/11/16(土) 06:07:09.62 ID: Be:
    組込みはシステムエンジニアじゃなくてソフトウェアエンジニアだからな。
    そこをわかってない奴が多い。技術者も非技術者も。 

903 仕様書無しさん [sage] 2013/11/16(土) 07:12:21.82 ID: Be:
    なんちゃってSEには、
    組み込みこそシステムエンジニア
    ってのが理解できないんだね。 

904 仕様書無しさん [sage] 2013/11/16(土) 08:25:57.75 ID: Be:
    SLCPとかで用語統一しようとしてたけど、未だにシステム設計って場所によって意味が違うからね 

905 仕様書無しさん [sage] 2013/11/16(土) 08:50:08.10 ID: Be:
    >>901
    俺もそんな風に答えるんだが親戚は誰も理解できなかった 

906 仕様書無しさん [sage] 2013/11/16(土) 09:28:42.42 ID: Be:
    家電の中身作ってますとかなら説明しやすそうかなぁと思ったけどどうなんだろ。 

907 仕様書無しさん [] 2013/11/16(土) 09:37:33.65 ID: Be:
    トランジスタ技術読んでいます、と返答すればよかったんでないの
    最近「広告がすっかりなくなってしまってねー」とかやる
    若松通商とか千石電子の広告。秋月行ったら、店舗小さかった 

908 仕様書無しさん [sage] 2013/11/16(土) 09:44:02.85 ID: Be:
    俺も秋月のリアルショップに初めて行ったとき
    店舗の小ささに驚いた。

    つーか暗号みたいな不自然な文章の誤爆だな 

909 仕様書無しさん [sage] 2013/11/16(土) 10:37:45.13 ID: Be:
    >>901
    プログラマーって答えるよ
    他に何しようとコーディングしてる限りプログラマーだ 

910 仕様書無しさん [sage] 2013/11/16(土) 11:50:37.58 ID: Be:
    作っている物を答えるよ。
    ソフトもハードもやるからね。 

■_

Regular Expression(正規表現) Part11

763 デフォルトの名無しさん [sage] 2013/11/14(木) 20:12:47.00 ID: Be:
    昔書いたプログラムは他人が書いたプログラムになると思えというけど、
    一ヶ月前に書いたもので正規表現はさっぱりわからなくなるな。 

764 デフォルトの名無しさん [sage] 2013/11/14(木) 21:06:25.16 ID: Be:
    >>763
    正規表現に名前を付けないからそうなる。

    単純に変数に代入するだけでも分かりやすくなるし、
    正規表現を使った比較を関数にすればもっといい。

    正規表現にもコメント入れる。
    なぜか日本で使ってる人が少ないような気がするけど、
    長い正規表現は複数行で書いてコメントを入れなさい。
    そのための機能がちゃんと用意されてるんだから。 

765 デフォルトの名無しさん [sage] 2013/11/14(木) 23:02:26.64 ID: Be:
    historyのワンライナーで何回か使うとコメントつけるけど、その作り途中のが出てくると混乱する。 

766 デフォルトの名無しさん [sage] 2013/11/14(木) 23:03:33.48 ID: Be:
    >>763
    ドキュメント無くても、テストコード書いとくと、後で使い方が分かっていいよ。
    正規表現に限らないけど。 

767 デフォルトの名無しさん [sage] 2013/11/14(木) 23:51:03.43 ID: Be:
    ttp://blog-imgs-29-origin.fc2.com/f/u/n/funcchan/image58.jpg
    俺は↑のソフトで作ってる。>>でコメント行、***でそれ以降の行が無視されるという仕様。
    正規表現が動かないときに正規表現の途中に***を入れて動かせばそこまでちゃんと
    動いてるかどうか確かめられたり。

    ただ完成度が低いのがアレ。\/を認識出来ないバグがある。
    ウインドウの大きさが変えられなくて不便。
    改行を含むテキストへのマッチングが試せない。

    完成度を高くしてくれたら金払ってもいい。 

768 デフォルトの名無しさん [sage] 2013/11/15(金) 08:02:17.63 ID: Be:
    >>764
    正規表現にコメント機能があるのは知ってるけど、改行入れても大丈夫なの? 

769 デフォルトの名無しさん [sage] 2013/11/15(金) 09:12:17.61 ID: Be:
    >>763
    私だけの現象かと、心配していました。少し安心、どうもありがとう。 

770 デフォルトの名無しさん [sage] 2013/11/16(土) 01:40:09.33 ID: Be:
    >>768
    xオプション
    http://d.hatena.ne.jp/perlcodesample/20080414/1208186274

    プログラミング言語で正規表現を使うことが前提の質問にはオプションのことも
    考えて回答する必要がある。

    テキストエディタの正規表現しか触れたことが無い人はこういうオプションの知識が
    無いから適切なオプションのアドバイスが出来ず混乱の元になることがある。 

767 で紹介されてるソフト面白そう。 というか以前自分も作って(だいぶ低機能だったけど)たのだけど 途中で投げたな。 GUI部分が面倒でw

■_ JVM Language Summit

の資料が公開されたとか。 ビデオは観てる余裕ないなー

Oracle Releases Videos and Slides from the 2013 JVM Language Summit

Oracle have published slides and videos of the 2013 JVM Language Summit, held in July this year. The JVM
Language Summit is an opportunity for researchers and language designers who use the JVM to develop
alternative languages or reports from JVM designers as to how to take advantage of the platform.

Since its first release, the Java platform has benefited massively from a standard JVM specification, which
introduced bytecode and a compatibility layer that allowed programs to run whatever the architecture.
Although initially interpreted, since the very early days the JVM has had a JIT optimiser to improve the
speed of execution and increase the performance of the overall platform. These days the JVM is the power
workhorse that allows Java applications to run at near C speeds.

資料へのリンクは元記事をどうぞ

■_ き電ちょう架

鉄道トリビア (229) 電車に電気を届ける架線が進化し続けている | マイナビニュース

鉄道トリビア (229) 電車に電気を届ける架線が進化し続けている | マイナビニュース

JR東日本の首都圏の在来線では、カテナリー式を進化させたコンパウンドカテナリー式やツインシンプルカテナリー式へ
付け替えられていったが、最近はシンプルカテナリー方式に戻りつつある。ただし旧式ではなく、改良型の
「き電ちょう架式」だという。トロリー線の素材が進化し、電流を供給する線と吊架線を共通化するなど工夫されている。
架線全体の部品や線の数を減らし、保守の簡易化や景観に配慮しているそうだ。

ひらがな交じりだと意味がよくわからんなーと調べてみると、 「饋電吊架式」と書くものらしい。「饋電」が読めなかったのでさらに調べると 饋電線 とは - コトバンク 給電線の旧称 だとか。しかしこっちはとにかく「吊」もひらがなにしちゃうもんなの?

架空電車線方式 - Wikipedia

饋電吊架式

カテナリー式の吊架線を、太く電流が流れやすい線条として「饋電線」と兼用させたものを饋電吊架式(フィーダーメッ
センジャー)と呼ぶ。例として、中央本線などの狭小トンネルで使用される π 架線方式がある。饋電吊架式の大きな利点
として、線条数や部品点数を削減できることから、地下区間のほか、明かり区間でも適用が進んでおり、東日本旅客鉄道
(JR東日本)の「インテグレート架線」、西日本旅客鉄道(JR西日本)の「ハイパー架線」などの開発名称がつけられて
いる例がある。

■_ 国際ロボット展

こんなのやってたのかー アニメの世界が現実に? 三段変形飛行ロボも登場!!ロボ好き大興奮の出展をチェック!「2013 国際ロボット展」 (1) アニメ系ロボで異彩を放った姫路ソフトワークス | マイナビニュース 11月6日~9日、東京ビッグサイトで「2013 国際ロボット展(iREX2013)」が開催された。同展は日本ロボット工業会/日刊工業新聞社の主催で2年に一度開催される業界最大の展示会で、東ホール1~3をフルに使った会場は多彩なロボットたちで埋め尽くされた。

■_

■_

2013年11月15日

■_

RubyConf での高橋会長の発表資料を見ていて、 結構ハードウェアよりの人なんだなあと再認識。 Raspberry Piを使わないのはナゼかという下りがあって、 「Raspberry PiだとへーきでLinux 載っちゃうからCRuby使えるじゃない。それじゃ面白くないでしょ?」 てな感じのアオリがあって大いにうけました。 職場で。こっそりと。

というわけで GreenArrays, Inc. この辺使ってなんかやりたいんですが

■_ TOYOTA case

なんか今日になって、 ビジネスニュース 企業動向:トヨタの急加速事故は欠陥だらけのファームウェアが原因?――原告側調査の詳細 (1/3) - EE Times Japan への言及が目立った気がしたんだけど吉岡さんのツイートが原因かしらん? (1) Twitter / 検索 - http://eetimes.jp/ee/articles/1311/11/news072.html はてなブックマーク - ビジネスニュース 企業動向:トヨタの急加速事故は欠陥だらけのファームウェアが原因?――原告側調査の詳細 (1/3) - EE Times Japan それはそれとして、 見た目に派手な? グローバル変数の数がとかバグトラッキングシステム使ってない とかいうのに対する言及のツイートが目立ってなんだかなあという気はした。 ↑の検索ではあまりうまく引っかかってないけどw

ビジネスニュース 企業動向:トヨタの急加速事故は欠陥だらけのファームウェアが原因?――原告側調査の詳細 (3/3) - EE Times Japan の、結論の部分まで読んだ人は少ないんだろうねえ…

ビジネスニュース 企業動向:トヨタの急加速事故は欠陥だらけのファームウェアが原因?――原告側調査の詳細 (3/3) - EE Times Japan

ソフトウェアの欠陥が明らかになった今回の問題から、われわれは何を学べるだろうか。

    全てはエンジニアリングの文化から始まる。品質を実現するには、適切な相互評価、文書化されたルールの実施、コード
    品質のツールや基準の使用などに取り組む文化が必要となる

    複雑なシステムでは、ハードウェアやソフトウェアによって引き起こされる可能性のある故障のシナリオを、全てテスト
    するのは不可能だ。欠陥のないコードを作成するには、考えられるあらゆる最善策を施し、使えるツールは全て利用する
    くらいの心構えで設計しなくてはならない

    適切なところにはモデルベース設計を用いる

    異なるエンジニアリングチームで、徹底的にシステムをテストする必要がある。自分で設計したものを、自らテストする
    という間違いを犯してはならない(トヨタがどのようにテストを行ったのかは、特に説明されていない)。

    基本となるハードウェアは、ファームウェアと連携して信頼性を実現する必要がある。例えば、SPOFは回避しなければ
    ならない。タスクを完全に分離し、保護するために、ロックステップCPU、EDACメモリ、適切なウォッチドッグ、MMU
    (メモリ管理ユニット)といった技術で、信頼性を向上しなければならない。さらに、故障モードを決定し、設計の改
    善に結び付けるために、FMEA(Failure Mode Effect Analysis:故障モード影響解析)を徹底的に実施する必要がある。


 安全性が最重視されるデバイスの開発に携わっている人は、トヨタの設計工程やBarr氏の調査結果についてどう思うだろうか。自分が行ってきた、あるいは行っている設計工程で、本当に安全性が実現できるのかをもう一度考えてみてほしい。

HN からもひとつ

As I mentioned in another recent thread https://news.ycombinator.com/item?id=66... | Hacker News

As I mentioned in another recent thread

https://news.ycombinator.com/item?id=6615457

engineers are often not aware of basic principles of fail safe design. I mentioned Toyota, and this article
confirms it.

Not mentioned in this article is the most basic fail safety method of all - a mechanical override that can be
activated by the driver. This is as simple as a button that physically removes power from the ignition system
so that the engine cannot continue running.

I don't mean a button that sends a command to the computer to shut down. I mean it physically disconnects power
to the ignition. Just like the big red STOP button you'll find on every table saw, drill press, etc.

Back when I worked on critical flight systems for Boeing, the pilot had the option of, via flipping circuit
breakers, physically removing power from computers that had been possessed by skynet and were operating
perversely.

This is well known in airframe design. As previously, I've recommended that people who write safety critical
software, where people will die if it malfunctions, might spend a few dollars to hire an aerospace engineer to
review their design and coach their engineers on how to do fail safe systems properly.

セーフウェア 安全・安心なシステムとソフトウェアを目指して (IT Architects’Archive)
セーフウェア 安全・安心なシステムとソフトウェアを目指して (IT Architects’Archive) まだ買ってない(読んでない)んだよなあ。これ。

技術者倫理とリスクマネジメント―事故はどうして防げなかったのか?
技術者倫理とリスクマネジメント―事故はどうして防げなかったのか? パーフェクトソフトウエア
パーフェクトソフトウエア

■_

■_

うーアウトプットが目詰まり…

2013年11月14日

■_

powershell でごにょごにょ $excelobject.workbook.worksheets.item(1).chartobjects().item(1).chart.seriescollection(1).values $excelobject.workbook.worksheets.item(1).chartobjects().item(1).chart.seriescollection(1).fomula こんな感じで(数字の部分はとりあえずの例)Excelのブックに張り付いている グラフを片っ端から列挙して、その元データや範囲オブジェクトを取れると。

■_

Rasmus あいかわらずだ

Why the father of PHP doesn’t like programming | VentureBeat

PHP‘s creator Rasmus Lerdorf did not intend to create an entirely new programming language.

Over 20 years ago, the Danish software engineer was looking for a better way to fix what he described as a
“young problem.” The PHP project kicked off in 1995 and would eventually become a server-side scripting
language and general-purpose programming language used by tech giants like Facebook, Yahoo, and Etsy.

Lerdoff, who is a contributor to many open source projects, worked as an infrastructure architect at Yahoo for
more than seven years and joined Etsy in 2012.

In an Ask me Anything (AMA) session at our DevBeat conference, developers asked Lerdoff a series of tough
questions about how he developed the language and what his future holds.

If you could change one fundamental thing about PHP, what would it be?
もしPHPの根本的な部分をひとつ変えられるとしたらどうしますか?

Lerdoff: Case sensitivity in PHP —  the question of whether it should be lower case or upper case. Back then
[when I started PHP] there were huge arguments, and I didn’t want to take sides in this religious argument.
It’s more painful to make changes now, as much as people criticize pieces of PHP. There were semi-intelligent
reasons for doing this at the time though.

大小文字の区別 (case sensitivity) ですね。
PHP を作り始めたときに激しい論争があったのですが、わたしはその宗教的な言い争いに関わりたくはなかったのです。
今となっては、PHP の一部分を批評する人が増えたので、今その変更をするのは一層 painful なものに
なってしまいました。
There were semi-intelligent reasons for doing this at the time though.


Do you continue to code? 
コードは書き続けてますか?

Lerdoff: I spend more time on the infrastructure and keeping the project afloat. I do occasionally write code.
I do have some commits on Github now and again; generally, bug tracking. My time is usually better spent
motivating others to write code. I used to code 20 hours a day.

(コーディングよりは) インフラだとかプロジェクトの(順調な)運営に時間をかけています。コードを書くのはたまにですね。
Github のあちこちへのコミットをいくつか持っていますがたいていはバグトラッキングです。
ほかの人のコードを書くモチベーションのために時間を使っています。
I used to code 20 hours a day.
(一日20時間コーディングしている?)

Do you intend to create a new programming language? 

Lerdoff: PHP wasn’t written because I wanted to write a language. It was to solve a problem. No one had come
up with the right tools yet. Honestly, I am passionate about solving problems — I don’t like programming. It’s
tedious. I’m an engineer who will use whatever tools I have [and] if I don’t have a tool, I’ll make a new
one. There is no mission to write another language.

PHP はプログラミング言語を作りたくて書いたものではありません。問題を解決するために書いたものです。
正しいツールはまだ誰も作っていません。
正直なところを言うと、わたしは問題を解くことに passionate なのであって、
プログラミングは退屈で好きではないのです。
わたしは自分の持っているツールを何でも使うエンジニアです。
もしツールがないのなら、新しいツールを作るでしょう。
別のプログラミング言語を書くという mission はそこにはありません。


What’s your favorite programming language? 
好きなプログラミング言語はなんですか?

Lerdoff: C. I’m more of a C developer than PHP.
Cですね。わたしはPHP developer というよりは C developer なんですよ。

以下略

© Copyright 2013 VentureBeat. All rights reserved. Powered by WordPress.com VIP

■_ stack ranking

マイクロソフト、スタックランキング制度を廃止か--チームワーク重視の評価に - CNET Japan マイクロソフト、不評のスタック・ランキング制度を廃止 - WSJ.com ついったで「スタックランキング」がどうとか流れてきて よく知らなかったのでぐぐった。

2013/8 の記事 マイクロソフトはなぜ衰退したのか?「スタックランキング」という人事評価システムを考える - BusinessNewsline

2012のこれの紹介で触れてる部分があるんだけど、コメントでは特にない模様。 Microsoft がトップから転落したのは、「共食い」文化のせい | スラッシュドット・ジャパン

某社も似たようなことをやっているようないないような。 良いか悪いかは良くわからん。

■_

Nemerle の作者がどうとか。 An Introduction to Nitra | JetBrains Company Blog

An Introduction to Nitra | JetBrains Company Blog

What is Nitra

Take a look at the following

Can you tell what that is (the name is a spoiler)? It’s a syntax module for Gherkin, a language used in
Cucumber, a framework for defining executable specifications.

This syntax module is defined using Nitra. Add it to a project, and combined with a parser that also ships
with Nitra, you can now parse Cucumber files, obtaining an Abstract Syntax Tree. This means that simply
defining some grammar you get parsing capabilities.

But there’s more…

This is not just another parser generator

Nitra is not merely just another parser generator. There are a few key characteristics that make Nitra
different and much more powerful.

Nitra is about extensibility

Nitra provides the ability to extend existing grammar either statically or dynamically. By not using scanning
techniques it dramatically increases extensibility. This in essence allows us to not only define new
languages but also extend existing ones. For instance, here’s an example of extending C# with a new
.? operator.

おもしろそうではあるんだけど。

■_

2013年11月13日

■_

夕食後ほとんど時間取れず

顕微鏡本。 興味のある章を飛ばし飛ばしに読んでるんですが、この本良いです。 きっと日本語訳も出るんだろうなあw Ruby Under a Microscope: An Illustrated Guide to Ruby Internals
Ruby Under a Microscope: An Illustrated Guide to Ruby Internals kindle版はこちら。表紙の色が違うのね Ruby Under a Microscope: An Illustrated Guide to Ruby Internals とはいえ電書を買うならたぶん blackfriday のセールがあるでしょうから そこでO'Reillyのサイトから買うのが良いんじゃないかと思います。 Ruby Under a Microscope - O'Reilly Media

■_

日本語記事がようやく。時間がないので詳しくはまた。 ビジネスニュース 企業動向:トヨタの急加速事故は欠陥だらけのファームウェアが原因?――原告側調査の詳細 (1/3) - EE Times Japan

■_

新プログラミング言語「Leaf」 | マイナビニュース で、 [LLVMdev] Announcing Leaf v0

[LLVMdev] Announcing Leaf v0

I'm proud to announce Leaf <http://leaflang.org/>, a soon to be great
new programming language. I've been working over a year on it now,
though it's nowhere near completion. Consider this a pre-alpha prototype
stage announcement.  ;)

A lot of my progress is due entirely to LLVM. So while Leaf has a host
of features <http://leaflang.org/features/index.html>, I'd like to point
out some things that highlight my use of LLVM.

- Multiple execution models: building libraries, executables, or even
running the JIT. I'm trying to stay very flexible here and LLVM is
making it easy.

- Optimization: So far I've done nothing, LLVM is doing a great job
cleaning up my rather underwhelming IR. This lets me focus entirely on
my language at the moment.

- Arbitrary bit-size integers: I really like having these in the IR. I
dislike fretting at the high-level about exactly what size an integer
is, thus I've directly exposed LLVM's ability to have arbitrary bit
sizes. (I just need a large-integer division routine now to fully
support > 128bits.)

- Exception handling: The landing pads and the ExceptionDemo got me a
lot of the way to implementing exception handling.

- Clang: Having a C and C++ compiler which can emit IR has been
extremely helpful in deconstructing features of those languages.

Slowly I'm working my way through every instruction and will soon find
my way into the attributes (I'll start with debugging symbols). Soon
I'll also start using multiple targets -- right now I support only
x86_64 on Linux. I'll make another announcement when I can show
something more.

Though still early in its development, there is room to get involved
now. If anybody is interested then just let me know and I'll welcome you
to the project.

Leaf
http://leaflang.org/

Features — Leaf 何を目論んでという気がするのでちょっと見てみよう

■_

■_

今日一番のニュース Apple II DOS Source Code Released : programming Apple II DOS source code released by Computer History Museum | Hacker News Apple IIのDOSソースコードが30年以上の時を経て公開される - GIGAZINE Apple II DOS source code released by Computer History Museum | 9to5Mac

Microsoft も昔のBASICのソースコードとか公開してくれないすかね。 他には インベーダーゲームのソースコードとか。 何年か前(十年以上前か)に上野の国立博物館であったイベントで一部だけ見られたけど 歴史的遺産といえなくもないんじゃないでしょうか。

2013年11月12日

■_

しばちゅーさんが次回最終回なんて!

昨日の True/False の訳を追加してたら今日の分のための時間が…w

■_

The History of Python: The history of bool, True and False

The history of bool, True and False

Writing up the reasons why True and False, when introduced, weren't reserved words, I realized there's another
interesting lesson in the history of Python's bool type. It was formally introduced in Python 2.3, as a new
type with two constants, and the type was introduced in PEP 285 ("Adding a bool type").

bool type は形式的には Python 2.3で、二つの定数を持った新しい型として導入されました。
また、この型は PEP285 ("Adding a bool type") で導入されています

But bool, True and False were also introduced in Python 2.2.1 (a bugfix release!). The Misc/NEWS file said:
しかし、bool、True、False はどれも Python 2.2.1 (バグフィックスリリースです!) で
導入されていました。
Misc/NEWS ファイルにはこうあります:

    What's New in Python 2.2.1 final?
    Release date: 10-Apr-2002
    =================================

    Core and builtins

    - Added new builtin function bool() and new builtin constants True and
      False to ease backporting of code developed for Python 2.3.  In 2.2,
      bool() returns 1 or 0, True == 1, and False == 0.


This was the last (and the most criticized) time we added a new feature in a bugfix release -- we'd never do
that these days. Also note that bool/True/False in 2.2.1 were different from 2.3: in 2.3, bool is a new type;
in 2.2.1, bool() is a built-in function and the constants are just ints.

これはわたしたちがバグフィックスリリースで新機能を追加した最後の(そして最も批判された)ものです。
これ以降はそういったことはしていません。
また、2.2.1 における bool/True/False についての記述も2.3のそれとは異なるものでした。
2.3 ではbool は新しい型ですが、2.2.1 では bool() は組み込み関数であり、その定数は単なる int でした。

The chronology is also interesting: the proper new bool type was introduced in 2.3a1, released on Dec 31 2002,
well after the above-mentioned 2.2.1 release. And the final 2.3 release didn't come out until July 29 2003.
And yet, the above comment talks about backporting from 2.3 to 2.2.1. PEP 285 was created on March 8, 2002,
accepted on April 3, and declared final on April 11 (i.e. after Python 2.2.1 was released). I'm assuming that
by then the proper bool implementation had landed in the 2.3 branch. That's a breakneck pace compared to how
we do things a decade later!

■_

2013年11月11日

■_

一気に寒くなった

■_

だめだやっぱ時間たりねー

The History of Python: The story of None, True and False (and an explanation of literals, keywords and builtins thrown in)

The story of None, True and False (and an explanation of literals, keywords and builtins thrown in)

I received an interesting question in the mail recently:

最近、メールで興味深い質問を受けました

    What is the difference between keywords and literals? Why are True and False keywords rather than literals
    in python3? 

    キーワードとリテラルの違いとはなんでしょうか?
    なぜ、Python3 では True や False はリテラルではなくキーワードなのでしょうか?

    I was horrified recently to find that assigning to True/False works in python2. So I went digging, and
    found that True and False were created to be 'constants' like None in PEP 285. Assignment to None was
    disallowed in 2.4, but not to True/False until python3. Was there a reason None was originally built as a
    variable rather than a literal?

    わたしはつい最近、python2 では True/False に対する代入 (assigning) が有効であったことに気がついて
    びっくりしました。さらに調べてみたところ、PEP 285 では True と False は None と同様に「定数」
    ('constants') として生成されていたことを発見しました。None に対する代入は 2.4 で禁止されたのですが、
    True/False については python3 まで禁止されていなかったのです。None がリテラルではなく変数として
    originally built されていたのにはなにか理由があったのでしょうか?
    

Let's start with the first question: keywords and literals.

では最初の質問、キーワードとリテラルについてから話を始めましょう。


A keyword, in the context of defining the syntax of a language, also known as a reserved word, is something
that looks like an identifier in the language, but from the parser's point of view act like a token of the
language. An identifier is defined as a sequence of one or more letters, digits and underscores, not starting
with a digit. (This is Python's definition, but many languages, like C or Java, use the same or a very similar
definition.)

キーワードは言語の構文の定義というコンテキストでは予約語 ('reserved word') という呼び方も知られています。
このキーワードは言語において識別子 (identifier) のように見えるものですが、言語のパーザーの視点では
トークンのように振る舞うものです。識別子は一つ以上の文字 (letter) 、数字 (digit)、アンダースコアが
並んだものです。ただし、数字が先頭に来ることは許されません (これは Python での定義ですが、C や Java を
初めとした多くの言語で同じか、非常に似た定義を使っています)。


The important thing to remember about keywords is that a keyword cannot be used to name a variable (or
function, class, etc.). Some well-known keywords in Python include 'if', 'while', 'for', 'and', 'or'.

キーワードについて忘れてはいけない重要なことは、キーワードが変数 (もしくは関数、クラスなど) の名前として
使うことができないという店です。Python でのよく知られたキーワードには
'if'、'while'、'for'、'and'、'or' といったものがあります。

A literal, on the other hand, is an element of an expression that describes a constant value. Examples of
literals are numbers (e.g. 42, 3.14, or 1.6e-10) and strings (e.g. "Hello, world"). Literals are
recognized by the parser, and the exact rules for how literals are parsed are often quite subtle. For example,
these are all numeric literals in Python 3:

一方リテラルは、定数値 (constant value) を記述している式の要素です。
リテラルの例には数値 (e.g. 42, 3.14, or 1.6e-10) や文字列 (e.g. "Hello, world")があります。
リテラルはパーザーによって認識されますが、
リテラルがどのように解析されるかという exact な規則はしばしばとても微妙なものとなります。
たとえば以下に挙げたものはすべて Python 3 における数値リテラルです:

    123
    1.0
    1.
    .01e10
    .1e+42
    123.456e-100
    0xfffe
    0o755

but these are not:
しかし以下のものは違います:

    . (dot)
    e10 (identifier)
    0y12 (the literal 0 followed by the identifier y12)
    0xffe+10 (the literal 0xffe followed by a plus sign and and the number 10)

Note the distinction between a constant and a literal. We often write code defining "constants", e.g.
ここで定数とリテラルの違いについて注意を。
わたしたちは「定数」を定義するコードをしばしば次のように記述します。

    MAX_LEVELS = 15

Here, 15 is a literal, but MAX_LEVELS is not -- it is an identifier, and the all-caps form of the name suggests
to the reader that it is probably not changed anywhere in the code, which means that we can consider it a
constant -- but this is just a convention, and the Python parser doesn't know about that convention, nor does
it enforce it.

ここで、15はリテラルですが、MAX_LEVELS はリテラルではなく識別子です。
そしてすべてが大文字である名前 (all-caps form of the name) は読み手に対して
それがコードのどこかで変更されることはおそらくないことを suggest しています。
つまり、わたしたちがそれを定数であるとみなしているということを意味しています。
しかしこれは単なる規約 (convention) に過ぎず、Python のパーザーはそんな規約は知りませんし
強制することもできません。

On the other hand, the parser won't let you write
その一方で、パーザーは次のような記述を許しません

    15 = MAX_LEVELS

This is because the left-hand side of the assignment operator (=) must be a variable, and a literal is not a
variable. (The exact definition of variable is complex, since some things that look like expressions are also
considered to be variables, such as d[k], (a, b), and foo.bar -- but not f() or () or 42. This definition of
variable is also used by the "del" statement.)

これは代入演算子 (=) の左辺は変数でなければならず、リテラルは変数でははないからです
(変数の正確な定義は複雑です。なぜなら式のように見えるけれども変数とみなされる d[k]、(a, b)、foo.bar
のようなものがあるからです。そして f() や ()、42 は変数ではありません。
変数の定義は del 文でも使用されます)。

Now on to None, True and False.

Let's begin with None, because it has always been in the language. (True and False were relatively recent
additions -- they first made their appearance in Python 2.1.3, to be precise.) None is a singleton object
(meaning there is only one None), used in many places in the language and library to represent the absence of
some other value. For example, if d is a dictionary, d.get(k) will return d[k] if it exists, but None if d has
no key k. In earlier versions of Python, None was just a "built-in name". The parser had no special
knowledge of None -- just like it doesn't have special knowledge of built-in types like int, float or str, or
built-in exceptions like KeyError or ZeroDivisionError. All of these are treated by the parser as identifiers,
and when your code is being interpreted they are looked up just like any other names (e.g. the functions and
variables you define yourself). So from the parser's perspective, the following are treated the same, and the
parse tree it produces (<name> = <name>) is the same in each case:

まずは言語に常に存在していた None から始めましょう (True や False は None より後に追加されたものです。
これらが最初に登場したのは Python 2.1.3 で、precise であるためでした)。
None はシングルトンオブジェクト (ただひとつしか None が存在していない) であり、
言語やライブラリの多くの場所でなにかの値が存在していないことを表すために使われました。
たとえば d が辞書であったとき、d.get(k) はk というキーが存在していれば d[k] を返しますが
d に k がない場合はNone を返します。初期の Python では None は単なる「組み込みの名前」(built-name) でした。
パーザーは None について特別な知識はもっていません。
それはちょうど、パーザーが int や float、str のような組み込み型や
KeyError や ZeroDivisionError のような組み込み例外についての特別な知識を
こういったものすべてはパーザーによって識別子として扱われ、
あなたのコードが解釈されたときに (あなた自身が定義した関数や変数のような)
他の名前すべてと同様に look up されます。
ですからパーザーの視点では、以下のものは同じものとして扱われ、
生成される解析木も同じもの (<name> = <name>) になります。

    x = None
    x = int
    x = foobar

On the other hand, the following produce different parse trees (<name> = <literal>):
一方、以下のものは異なる解析木(<name> = <literal>)が生成されます:

    x = 42
    x = 'hello'

because the parser treats numeric and string literals as different from identifiers. Combining this with the
earlier MAX_LEVEL examples, we can see that if we swap the left and right hand sides, the first three will
still be accepted by the parser (<name> = <name>), while the swapped version of the second set
will be rejected (<literal> = <name> is invalid).

これはパーザーが数値リテラルや文字列リテラルを識別子とは異なるものとして扱うからです。
これを先の MAX_LEVELS の例と組み合わせることで、左辺と右辺を交換したときにパーザーが最初の三つは
(<name> = <name> として) 受理するのに
二番目のグループは(不正な<literal> = <name>として)拒絶するのも理解できるようになるでしょう。

The practical consequence is that, if you really want to mess with your readers, you can write code that
reassigns built-ins; for example, you could write:

The practical consequence is that,
もし読み手を本当に混乱させたいのなら、built-in に対して再代入するコードを書けるのです。
たとえば次のようなコードが書けます

    int = float
    def parse_string(s):
        return int(s)
    print(parse_string('42'))    # Will print '42.0'

Some of you may respond to this with "So what? Reasonable programmers don't write such code." Others
may react in the opposite way, saying "Why on earth does the language allow assignment to a built-in name
like 'int' at all?!"

読者の中には、「それがどうしたの? 分別のあるプログラマーはそんなコードを書いたりしないよ」
という反応をする方もいるでしょうし、それとは正反対に
「なんだって'int'みたいな組み込みの名前への代入を許しちゃってるの?!」
とリアクションする人もいるでしょう。


The answer is subtle, and has to do with consistency and evolution of the language. I bet that without looking
it up you won't be able to give a complete list all built-in names defined by Python. (I know I can't.)
Moreover, I bet that many of you won't recognize every single name on that list. (To see the list, try typing
dir(__builtins__) at the Python command prompt.)

それに対する回答は微妙で、Python という言語の consistency (一貫性) と evolution (進化) に
触れなければなりません。
I bet that without looking it up you won't be able to give a complete list all built-in names defined by Python.
(I know I can't.)
Moreover, I bet that many of you won't recognize every single name on that list.
(このリストを確認するには Python のコマンドプロンプトで dir(__builtins__) とタイプします)

Take for example the weird built-ins named copyright, credits or license. They exist so that we can mention
them in the greeting shown when you start Python interactively:

    Python 3.4.0a4+ (default:0917f6c62c62, Oct 22 2013, 10:55:35)
    [GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.28)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> credits
    Thanks to CWI, CNRI, BeOpen.com, Zope Corporation and a cast of thousands
    for supporting Python development.  See www.python.org for more information.
    >>> 

In order for this to work, we made them built-ins. But does this mean you shouldn't be allowed to use
'credits' as a variable or parameter name? I think not. Certainly many people don't realize that these
esoteric built-ins even exist, and they would be surprised if they were prevented from using them as variable
names. From here, it's just a gradual path. Many people write functions or methods with arguments named str
or len, or with names like compile or format. Moreover, suppose you wrote some Python 2.5 code where you used
bytes as a variable name. In Python 2.6, we added a built-in function named 'bytes' (it's an alias for str,
actually). Should your code now be considered invalid? There's no reason for that, and in fact your code will
be fine. (Even in Python 3, where bytes is one of the fundamental types.)

これが動作するようにするためにわたしたちはそれらを built-in にしたのです。
しかし、それを行ったことはあなたが 'credits' を変数やパラメーターの名前に使うことは
許されるべきではないという意味になるでしょうか? わたしはそうは思いません。
多くのユーザーがこのような esoteric built-ins が存在していることなど思いもよらないでしょうし、
それらを変数の名前として使えないようにしてしまったらそのことに驚くでしょう。
From here, it's just a gradual path。
多くのユーザーがstrだとかlen、あるいは compile や formatという名前の引数を持つ関数やメソッドを記述しています。
さらに言えば、あなたがbytes という名前の変数を使っている Python 2.5のコードを書いていたとしましょう。
Python 2.6 において、わたしたちは 'bytes' という名前の組み込み関数を追加しました
(実際にはこれは str の別名です)。
あなたの書いてきたコードをここで invalid なものとみなすべきでしょうか?
そうすべき理由はありませんから、in fact your code will be fine.
(Python 3でも bytes は fundamental types のひとつです)


On the other hand, you cannot have a variable named 'if' or 'try', because these are reserved words (keywords)
that are treated special by the parser. Because you cannot use these as variable or function names anywhere,
ever, in any Python program, everyone using Python has to know about all the reserved words in the language,
even if they don't have any need for them. For this reason, we try to keep the list of reserved words small,
and the core developers hem and haw a lot before adding a new reserved word to the language.

一方、'if' や 'try' といった名前の変数を定義することはできません。
なぜならそれらは予約語(キーワード)で、パーザーによって特別扱いされるものだからです。
予約語は一切の Python プログラムのあらゆる場所で変数名や関数名として使うことのできないものですから、
そのつもりがないとしても、Python を使うすべての人は Python におけるすべて予約語について知っておかな
ければなりません。このことが理由で、わたしたちは予約語のリストを小さくし続けようとしていますし、
core developer たちは hem and haw a lot before adding a new reserved word to the language.

In fact, many proposed new features have been killed because they would require a new keyword; others have
been modified to avoid that need. Also, when we do decide to add a new keyword, we start a deprecation
campaign at least one release before the new keyword is introduced, warning developers to choose a different
name for their variables. (There's also a trick to allow developers to choose to use the new keyword right
away; this is why we have e.g. "from __future__ import with_statement".)

事実、提案された多くの新機能はそれが新しいキーワードを必要とするという理由で却下されていますし、
その他には新キーワードが必要ないように修正されたものもあります。また、キーワードの追加を決めた場合には、
そのキーワードの導入前に deprecation campaign を少なくとも一リリース行って developer たちに変数の名前を
違うものにするように警告します(developer たちに新しいキーワードを即座に使うという選択をするのを許す
trick もあります。それが "from __future__ import with_statement" をわたしたちが
持っていた理由です)。


There's no such concern for built-ins. Code that happens to use the name of a new built-in as a variable or
function name will continue to function (as long as you don't also try to use the new built-in in the same
function). While we still try to be conservative with the introduction of new built-ins, at least we don't
have to worry about breaking working code by merely adding something to the language. The (small) price we
pay for this is the possibility that some joker intentionally redefines a built-in just to confuse others. But
there are tons of other ways to write unreadable code, and I don't see this as a particularly bad problem.

nuilt-in にはそのような影響はありません。
新しい built-in の名前を変数や関数の名前として使ってしまっていたコードは、同一の関数の中で
その新たな built-in を使おうとしない限りは機能し続けました。
わたしたちは新しい built-in の導入に対して慎重であろうとしていた一方で、
単純に何かを Python に追加することで動作していたコードを壊してしまうことを心配しなければ
ならないことはありませんでした。The (small) price we pay for this は、
他の人を混乱させるためだけに some joker が intentionally に built-in を再定義してしまう可能性です。
しかし unreadble なコードを書くための方法は他にもたくさんありますから
殊更にこれを問題だとは思いませんでした。

So, after this long detour about built-ins vs. keywords, back to None. Why did we eventually make None a
reserved word? Frankly, the reasons were perhaps mostly social. Unlike some built-ins and many exceptions,
None is so central to using Python that you really can't be using Python without knowing about None. So people
were (like our question-asker) "horrified" when they found that assignment to None was actually
allowed at all. Worse, there was the concern (whether founded or not) that the way name lookup in Python works,
"evaluating" the expression None is slow, because it requires at least two dictionary lookups (all
names are looked up in the globals dict before being looked up in the built-ins dict).

さて built-in とキーワードについての寄り道はこのくらいにして None の話に戻るとしましょう。
わたしたちはなぜNone を予約語にしたのでしょうか? 率直に言えば、
その理由はおそらく mostly social でした。
一部の built-in や多くの例外とは違って None はそれについて知ることなしには Python を本当に使うことが
できないほどの central to using Python でした。
ですから、ユーザーは(元の質問主がそうだったように) Noneへの代入が許されていた
ことを知ったときに「びっくりした」のです。
Worse, there was the concern (whether founded or not) that the way name lookup in Python works,
"evaluating" the expression None is slow,
because it requires at least two dictionary lookups
(すべての名前に対して globals dict を検索した後で built-ins dict を検索していました).


In the end we decided that there was no downside to making None a keyword (there is no code that actually
assigns to it) and it might make some code a tiny bit faster, or catch rare typos. There was still a one-time
cost to the developer community (changes to the parser and documentation) but this was small enough that we
din't hesitate very long.

最終的にわたしたちは None をキーワードにすることには downside がないと判断しました
(結局 None に代入しているようなコードはありませんでした)。
そして、それは一部のコードをほんの少し速くしたり
rare な typo を捕捉できるようにしたかもしれません。
developer community に対してはまだ (パーザーやドキュメントを変更するという) one-time cost が
残っていましたが、これは small enough that we din't hesitate very long でした。

The situation for True/False is a little different. They weren't always part of the language, and many people
had invented their own convention. People would define constants named true and false, True and False, or TRUE
and FALSE, and use those consistently throughout their code. I don't recall which spelling was most popular, 
but when we introduced True and False into the language, we definitely did not want to break any packages that
were defining their own True and False constants. (One concern was that those packages would have to have a
way to continue to run on previous Python versions.)

True/False のsituation は少々異なるものでした。True/False は常に言語の一部であったというわけではなく、
多くのユーザーは独自の規約を発明していました。
ユーザーは true/false、True/False、TRUE/FALSE のような定数名を定義して自分たちのコードで
それらを一貫性を持って使っていました。これらのうちのどれが最大多数であったのかを思い出せないのですが、
Python に True と False を持ち込んだときに、わたしたちはユーザーが独自の True/False を定義している
パッケージをすべて壊さずにいたいと望んでいました
(一つの影響はそういったパッケージは以前のバージョンのPython でも実行できる手段を持っていなければ
ならないということでした)。

So, essentially our hand was forced in this case, and we had to introduce True and False as built-in constants,
not as keywords. But over time, code defining its own versions of True and False (by whichever name) became
more and more frowned upon, and by the time Python 3 came around, when we looked at opportunities for cleaning
up the language, we found that it was logical to make True and False keywords, by analogy to None.

And there you have it. It's all completely logical, once you understand the context. :-) Sorry for the long
response; I hope it's been educational.

UPDATE: I still forgot to answer whether None/True/False are literals or keywords. My answer is that they are
both. They are keywords because that's how the parser recognizes them. They are literals because that's their
role in expressions and because they stand for constant values. One could argue about whether things like 
{'foo': 42} are literals; personally I'd prefer to give these some other name, because otherwise what would
you call {'foo': x+1}? The language reference calls both of these "displays".

更新
None/True/False がリテラルなのかキーワードなのかの回答するのを忘れていました。
わたしの回答はそのどちらでもあるというものです。
これらはパーザーがどのように認識するかということで考えればキーワードであり、
式の中でどのような役目を果たしているかや定数値を表していることから考えればリテラルです。



Posted by Guido van Rossum at 2:40 PM

■_


一つ前へ 2013年11月(上旬)
一つ後へ 2013年11月(下旬)

ホームへ


リンクはご自由にどうぞ

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