■_
朝起きてもまだ暗いせいか、二度寝してちょっと焦る事態が頻発。
一つ前へ
2013年11月(上旬)
一つ後へ
2013年11月(下旬)
朝起きてもまだ暗いせいか、二度寝してちょっと焦る事態が頻発。
すみません。まとめきれませんでした ○| ̄|_ 明日にはどうにか…できるかなあ
ちょっと前の記事ですが、今日になって初めて通して読んでみたら気になったので。 規模の大きい本番システムをGo言語で書き直した感想 - ワザノバ | wazanova Volatile and Decentralized: Rewriting a large production system in Go
[その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 するコンストラクターじゃないでしょうか。
今日は明日から開催される RubyWorld Conference のため松江から更新です。
チューリング: 情報時代のパイオニア
読み終わった。
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
Breakout in 30 lines of JavaScript | Hacker News 最近よく30行のJavaScriptで~を見かける気がしたので調べてみると HNSearch - Hacker News Search
Below I describe the results of a performance comparison between capnproto-rust and the definitive C++ implementation.
先月 mg というコマンドを Unicode 対応しましたが、その後全面的に見直してオプション体系も新しくなったので、greple という名前に変更してリリースすることにしました。
lint(1)はCのソースコードを処理するパーサ部はpccと同一コードベースです、 READMEにもその旨書いてありますな。
Haskell lets you write beautiful, modular code. Rather than waffle generally, I’ll use this talk to look at a particular example, Edward Kmett’s lovely lens library.
わーすーれーてーたー ○| ̄|_ イデオンリーからトミケットへ
なんかすげーありがたいものも。 Software reliability に関するものもあるし。 15 Free eBooks On Algorithm! 25 Free eBooks For Software Engineers!
Oracle Releases Videos and Slides from the 2013 JVM Language Summit にあったリンクの一つ「Scala war stories」のスライドがなかなか。 その一部を。
答え合わせは(たぶん)明日
Java SE 8 lambdaで変わるプログラミングスタイル - きしだのはてな Java 8 の lambda といえばこういう本が Manning: Java 8 Lambdas in Action まだ MEAP ですけどね。 ちょっと見たところなかなか面白そう。
きしださん、嫌なことでもあったんやろか・・・。
忘れないように録画設定と。 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) 江戸時代のからくり文化 ~座敷からくりに見る日本のエンジニアの源流~
あたり。
アキバ系!電脳空間カウボーイズZ 「さらばアスキー!!」の後編。面白かったけど 2時間ちょい…w 「ネットでは代替できない(できていない)記事」とか ハイパーカードであれとか。
今日見かけたんだけどこれ欲しいなあ。 つっても置き場に困るか。 そうするとこういうのも…と
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
の資料が公開されたとか。 ビデオは観てる余裕ないなー
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をフルに使った会場は多彩なロボットたちで埋め尽くされた。
SUBROUTINE および FUNCTION は、1958年に FORTRAN II で導入されましたが、
RubyConf での高橋会長の発表資料を見ていて、 結構ハードウェアよりの人なんだなあと再認識。 Raspberry Piを使わないのはナゼかという下りがあって、 「Raspberry PiだとへーきでLinux 載っちゃうからCRuby使えるじゃない。それじゃ面白くないでしょ?」 てな感じのアオリがあって大いにうけました。 職場で。こっそりと。
というわけで GreenArrays, Inc. この辺使ってなんかやりたいんですが
なんか今日になって、 ビジネスニュース 企業動向:トヨタの急加速事故は欠陥だらけのファームウェアが原因?――原告側調査の詳細 (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)
まだ買ってない(読んでない)んだよなあ。これ。
うーアウトプットが目詰まり…
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
マイクロソフト、スタックランキング制度を廃止か--チームワーク重視の評価に - 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.
おもしろそうではあるんだけど。
突然のお知らせで恐縮なのですが、HackerJapan誌が諸般の事情により現在販売されている2013年11月号を最後に休刊することとなりました。
さて、「世」って言う奴いるのか?いや、「麿」や「小生」もそうなんだけど、今言ってる奴いるのか?そして、将来、言う奴は出てくるのか?
夕食後ほとんど時間取れず
顕微鏡本。
興味のある章を飛ばし飛ばしに読んでるんですが、この本良いです。
きっと日本語訳も出るんだろうなあw
Ruby Under a Microscope: An Illustrated Guide to Ruby Internals
kindle版はこちら。表紙の色が違うのね
とはいえ電書を買うならたぶん 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のソースコードとか公開してくれないすかね。 他には インベーダーゲームのソースコードとか。 何年か前(十年以上前か)に上野の国立博物館であったイベントで一部だけ見られたけど 歴史的遺産といえなくもないんじゃないでしょうか。
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!
一気に寒くなった
だめだやっぱ時間たりねー
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
Ruby 開発陣がブランチのメンテナンスに割けるリソースは限界がある。具体的には2本 (+trunk) が限界。
一つ前へ
2013年11月(上旬)
一つ後へ
2013年11月(下旬)
リンクはご自由にどうぞ
メールの宛先はこちら