ときどきの雑記帖 濫觴編

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

一つ前へ 2011年9月(上旬)
一つ後へ 2011年9月(下旬)

ホームへ

2011年09月20日

■_

廉価版のDVD-BOXでいいんだがなあ 『MASTERキートン』 BD-BOX 11月23日に発売決定！年末に集中しすぎだろｗ - かくれオタのブログ

イカサマータイムもあと2日

■_

■_ Little ***er

Little MLer って Little Schemer よりも先に出てたんでしたっけ? 

The slow-witted OCamler

The slow-witted OCamler                                   Introduction


TL;DR

I wrote this to explain 'The little MLer' to my slow-witted self.
You can read it and suggest improvements, see email below.

                                * * *

Dear reader,

near the end of 2010 I read Felleisen and Friedman's 'The little MLer'
to learn functional programming in general and OCaml in particular.
Looking back I must say that I could have had it much easier with
another book.  To be honest I had to read it twice to make sense of it
and on some occasions it made me feel dumb, in fact so much so, that
on the second reading I summarized the whole book, just to make sure I
understood every important detail and not to go astray.  I called the
resulting notes 'The slow-witted OCamler' for no other reason than to
remind myself of the Kafkaesque intellectual experience I had gone
through.

以下略

■_ WinRT

C から使えないのーというお悩み? 

visual studio - Using WinRT from C? - Stack Overflow

Using WinRT from C?



Watching the //BUILD stuff, I saw that WinRT API's can be consumed by C code:

enter image description here

I am rather excited about a fresh C API available to Win32 developers.

Where can I find information on the C WinRT API? How is it better than the existing Win32 C API?


WinRT is fundamentally COM, so using WinRT components from C is like using COM components
from C. Like before, you get .idl files for all WinRT components, and also .h files produced
from those .idl files. The .h files include both C++ and C declarations (wrapped in
#ifdef __cplusplus as needed). You can just #include them and start hacking away.

It's not exactly neat, though, e.g. something like this C++/CX:

Windows::UI::Xaml::Controls::TextBlock^ tb = ...;
tb->Text = "Foo";

which is equivalent to this vanilla C++:

Windows::UI::Xaml::Controls::ITextBlock* tb = ...;
HSTRING hs;
hr = WindowsStringCreate(L"Foo", 3, &hs);
// check hr for errors
HRESULT hr = tb->set_Text(hs);
// check hr for errors
tb->Release();

would be written in C as:

__x_Windows_CUI_CXaml_CControls_CITextBlock* tb = ...;
HRESULT hr;
HSTRING hs;
hr = WindowsStringCreate(L"Foo", 3, &hs);
// check hr for errors
hr = __x_Windows_CUI_CXaml_CControls_CITextBlock_put_Text(tb, hs);
// check hr for errors
IUnknown_Release(tb);

Look inside "C:\Program Files (x86)\Windows Kits\8.0\Include\winrt" in Developer
Preview to see the .idl and .h files.

Not the answer you're looking for? Browse other questions tagged c visual-studio winapi
microsoft winrt or ask your own question.

Hello World!

This is a collaboratively edited question and answer site for professional and enthusiast p
rogrammers. It's 100% free, no registration required.


site design / logo © 2011 stack exchange inc; user contributions licensed under cc-wiki with attribution required

C から COM インターフェース経由でごにょごにょはやったことあるけど、 あまりやりたくないw

■_

↑ に対するreddit での反応 

Using WinRT from C - Stack Overflow : programming

Using WinRT from C - Stack Overflow (stackoverflow.com)


;-)

I am normally the guy to put in a good word for COM 'round 'ere.

However, there's no good word I'll utter for C&COM combination. People should have 
a life, which is not possible with C&COM. Do it, and your wife will leave, and 
your kids will die of an unknown disease. It already happened to many-a-good-men.



Amen.

Old-style COM from C++ was painful enough (which flavour of string would you like to 
use today?), but at least you had (stupid variety of) string classes, _com_ptr_t and 
the like, plus the ability to hide HRESULT checks and map them to exceptions, to at 
least allow some of your business logic to poke through the cruft.

Doing COM from C would be like skiing down the Alps on your bare arse.


Is Chris 'Fat Bastard' Sells (presented some coding at BUILD) the same guy as the 
young thin Chris Sells that delivered the Developmentor COM and original .NET courses 
back in ooohh, 2002 or so?

Really really nice guy btw. Highly brainy.

I'm still using my free copy of ATL internals to raise my monitor to a better height...



But COM was always meant to be used from any language, including C. That's why COM was made.



I don't think this is quite true. If memory serves me right, the main purpose of COM 
was C++ component reuse on binary level. This is what Don Box said in his 
"Essential COM" and it is solely based on one obscure C++ spec hack:

    if all superclasses in the inheritance chain have all their methods pure virtual and
    have no data members, then the spec guarantees that all compilers will produce exactly
    same layout of the virtual function table (VTable) of the implementing classes

OK, that might be not exactly verbatim and not quite true (especially about the 
guaranteed VTable layout), I don't have the C++ standard nor the book with me right 
now, but I think this was what was meant.

In any case, it explains why COM interfaces can't have data members for example. And 
in any case, it was base on a hack.

And certainly not for C, although it is possible to use COM interfaces from C, just 
look at some COM headers in Microsoft SDK (MAPI comes to mind).



Yes, that's kinda the idea. However, nothing in C++ spec says anything about vtable or 
anything like that. That's 100% implementation-specific. Just like C, C++ has no ABI 
whatsoever. It looks MS went for "that's how it's done anyhow". (Indeed, 3 
implementations I looked at do the same).


The problem is I cannot use COM without the C++/CX extensions.

If I can, then show me the API that is easy to use that does what you say (hint: WRL, documentation does not exist yet).



    The problem is I cannot use COM without the C++/CX extensions.

Yes you can.

Step 1. Remove the /Zw compiler switch.
Step 2. There is no step 2. Now you just use plain COM like you normally do, in standard ISO C++.

Because it's pre-beta software, there are large sections of WinRT that's missing 
documentation - the WRL is one of them. We'll probably see the documentation later 
once they hit beta. But you don't even have to use the WRL if you don't want to. You 
can just use plain old COM, like people have been doing for years!


You don't. If you want to advertise a C++ API, then write a C++ API. You can't advertise
a C++ API, which is not a C++ API. That's a lame trick by Microsoft. We now have the same
situation as in Java, which lead to J++.

Stroustrup should sue Microsoft for advertising, all over the web, the last few weaks, 
that the new APIs will be C++. They are not.



    You don't.

Oh, how useful.

    Stroustrup should sue Microsoft for advertising, all over the web, the last few weaks,
    that the new APIs will be C++. They are not.

WinRT is COM-callable, thus does not require C++/CLI. Pavel Minaev merely uses C++/CLI 
as an example for the respective .NET call.

■_

2011年09月19日

■_

中の人はそんなに怖くないです(たぶん

田園都市線/半蔵門線/副都心線の渋谷駅はあれだ、宮益坂方向の構造が ほとんどドラクエのダンジョン状態で、行きたいところは見えるのだけど ぐるっと遠回りしないとたどり着けないとか(改札の内側が間に入ってしまう)で わかりづらくなってるんだな。というのを理解。

渋谷の文教堂が1フロアになってて、雰囲気もなんか変わってた。

■_ 謎

質問者が出している情報が不十分手のはそうなんだけど 

正規表現のことです。 | OKWave


今、Javaで正規表現の勉強をしています。
この問題が、どうしても分かりません。

¥(0¥|[+-]?[1-9][0-9]*¥)¥(¥.[0-9]+¥)?

小数点があるのかな？という感じです。
あと、数字しかないことぐらいです。

どなたかよろしくお願いいたします。



ANo.1

「この問題」とありますが、肝心の問題が書かれていません。提示されている正規表現が何を表すのかを答えよと言うのか、その正規表現を基に改造せよと言うのか、それ以外か。

正規表現が何を表しているかという問題だと仮定して、
・一つ目の)までと、その後ろの部分は分けて考える
・?は0回か1回の出現、*は0回以上の出現、+は1回以上の出現を表す
・[]はその中に含まれる文字のどれか1つ

要素要素に分解して一つずつ理解してください。
たとえば [1-9][0-9]* は1から9の文字が一文字ある後ろに、0から9の文字が繰り返される (ただし繰り返し回数が0の場合もあり) ことを表すので、
7
25
309942
などにはマッチしますが、
0
03
8X
などにはマッチしません。

( ) | の前に \ が置かれているのがすげー気になるんですが。 本当にそうだとすると、回答は的外れ。 また、\( \) がグルーピングのためのカッコ対、\| が選択とすると 最初のカッコの直後に 0 があってそのあとが選択になっているから、 0 はマッチする。 さらにいうと、03 の 0 の部分とか 8X の 8 にもマッチする :)

■_

Ruby の規格が ISO にもということで。 

Ruby to be the first Japanese made programming language to become an international standard sometime next year : ruby

This is a translation of an article by 日刊工業新聞 (nikkan) which is a publication 
dedicated to industry news in Japan.

The Japan based Ruby language is set to become an international standard in 2012 through
the International Organization for Standardization (ISO). Ruby was already standardized
through Japanese Industrial Standards (JIS), and the focus will now be directed towards
its recognition in the global community by becoming an official ISO standard. This would
be the first time a programming language of Japanese origin would become an ISO standard.
The nation of Japan hopes that this will increase its recognition in the primarily
western dominated software field.

Ruby was developed by fellow Yukihiro Matsumoto at the National Applied Communication 
Laboratory (Matsue city). Features such as the ability to architect high level
applications with ease has gained Ruby fast popularity around web development both 
inside and outside the country.

The ISO standardization of Ruby is being pushed by the Information-technology Promotion
Agency (IPA). Domestically Ruby became a JIS standard (JIS X3017) in March from a
proposal by the Ruby Standardization Study Working Group.



It would be good.



Every time I see this, I wonder "why?". RubySpec already works great. I'm 
afraid this move will result in the language mired in bureaucratic committee nonsense.



Genuine question. What difference would it make to ruby devs? I imagine it might be a 
selling point that can help enter the enterprise market or something, but can anyone 
elaborate?


It would make an official specification for the various VMs out there (JRuby, Rubinius, 
Gemstone, YARV) to adhere to. Any stable release can be labeld as 'ISO 5866' (or whatever
the code will be) compliant.



Yeah, basically what skippy said. Previously, there was no official specification, so 
Rubinius actually spent a fair amount of time developing RubySpec so that other 
languages would know if their versions were correct.


IMHO, sadly Rails makes people think ruby is sort of fanboy, which it ain't.

■_ My paradigm is better than your paradigm : programming

本題は My paradigm is better than your paradigm « Luke Palmer なんですが、それに対する反応から。 

My paradigm is better than your paradigm : programming

    So I would say a language is expressive if it allows or enables the programmer to be
    expressive. Languages that restrict expression are not expressive.

This is not the only definition of expressive: one might also say that a language is more
expressive if it allows the programmer to be expressive with less code, since that means
the same amount of code can express more. Thus, although Haskell cannot express as much
as Perl, it requires vastly less code to express various concepts, so one might say it
is more expressive.


Felleisen expressivity



    [Haskell] requires vastly less code to express various concepts [than Perl]

o_O

We are talking about the same Perl, right? Perl is nothing if not terse.



J or APL or K have Haskell and Perl beat.

its not purely about LOC, its a balance between expressivity, power, clarity, and terseness.

A language is expressive if it gets the job done w/o the need for excessive boiler plate.



Arguments 140 characters at a time; it's sure to be a thorough, well reasoned debate.



Japanese programmers probably have pretty intense debates...

なぜに Japanese programmers の話に

元記事は結構興味深いことを書いていると思うので、 余裕のある方は目を通すことをオススメ。

■_

数日前のアナウンスですが、 

What's coming up in September/October | 6guts

What's coming up in September/October

Posted on September 13, 2011 by jnthnwrthngtn	

So, YAPC has come, been great, gone and been recovered from, I'm done with my summer 
visiting, the $dayjob speaking trip has taken place, I've shaken off the obligatory 
start of autumn cold and it's time to get back to hacking on stuff. Actually, I've no 
more workshops or other trips until November and I've got Perl 6 time marked in my 
schedule, so all being well there should be plenty of time to Get Stuff Done. :-) So 
what have I got planned for the next couple of months?

Ship a ”nom”-based Release

(略)

A Basic Rakudo Optimizer

(略)

A Basic NQP Optimizer

NQP is the subset of Perl 6 that we write most of the compiler in. We also implement 
the various built-in meta-objects in it (so we want it to be fast here, and of course 
we want faster compiles!) It currently has no optimizer, a situation I plan to change.
(略)

Bounded Serialization

(略)

Revive the CLR Backend

Running NQP on the CLR got a long, long way. At the time I last touched it, the majority of
the non-regex tests in the NQP test suite were passing, and diakopter++ was making progress
on the regex ones too. It's been dormant for a while, but it's time to get back to work on
it. Getting NQP, and then Rakudo, to run on the CLR is now a vastly more tractable task to
back then, since:

    * Back then, I was in the process of designing 6model and doing an NQP port and working
      out what NQP on 6model would look like. Now I only have to worry about one of those
      things, not all three at the same time.

    * NQP itself is 6model based now. Thus there won't be a need for the “JnthnNQP” fork
      (NQP itself ended up looking much more like JnthnNQP anyway, which was the idea). If I
      do need tweaks that I can't immediately reconcile with NQP on Parrot, they can be done
      just by subclassing NQP::Actions or so and overriding the things in question. Either
      way, it'll be the same ? or a slightly twiddled ? version of NQP, not a vastly different
      one.

    * Rakudo itself is now mostly written in NQP and Perl 6. We used to have a bunch of PIR
      builtins, but they're long gone (along with various ugly issues they caused, like not
      having proper Perl 6 signatures and so forth). I'd guesstimate that about 5% ? at most
      10% ? of the Rakudo code is backend specific. Some of it will be tricky, but a lot of it
      is ? at least if you're familiar with it ? pretty mundane.

(略)

あれ、NQP ってなんだったか混乱してきた(^^；

■_

2011年09月18日

■_

ついったで、とある洋書(だけじゃないけど) の新刊情報を流してくれる bot をフォローしている のですが、見ているとまあ欲しくなるタイトルがごろごろと。 買う金も読んでる時間もないのですけどね ○|￣|＿

こんな番組があったとは BS-TBS THEナンバー2 ～歴史を動かした影の主役たち～ BS-TBS でやってる番組なんですが、今日初めて知った。 これまで取り上げてきた人物を見てみると BS-TBS THEナンバー2 ～歴史を動かした影の主役たち～ ぐはっ。前回が松永彈正ではないか ○|￣|＿ (彼をどう見ると「ナンバー2」なのかはよくわからんけれども) しかし、日本史でナンバー2といえば真っ先に名前が挙がりそうな 羽柴秀長はまだなのね。最後にとってるのかも知れんけど。

ハマの裏番　もつ鍋屋になる
ちょっと前に名前を出した元ベイスターズの中野渡の本。 面白かった いちばん興味を引かれたエピソードは、 もつ鍋やを開くにあたって仕入先を決めなければならないのだけど伝手がない。 高校時代の先輩に肉屋の息子がいたのでどっか紹介してくれと相談してみると、 ここになければどこでも扱ってないというような卸の社長がお前のファンのはずだろ なんで知らないんだと言われてしまった。 半信半疑でその会社に行ってみると確かに自分の書いたサイン色紙があったし 社長と会ってみて確かにサインした覚えもあった。 ということでもつの仕入先も問題なく決まったんだけど、 やはり日頃の行いは大切だお前らもたかがサインと馬鹿にせずにきちんとやれと 後輩に説教しても馬耳東風だったというお話(細かいところは違ってても見逃して)。

入団して最初の監督のときは「似たタイプのピッチャーがすでに一軍にいるから上げる気はない」 とか言われ、次の監督のときに大活躍したものの故障してしまい 復帰したときにはさらに次の監督になっててまた干される。で、退団。 最後の監督(山下大輔だよね、たぶん)のときに使われなかった理由はよくわからないけど、 権藤さんのときの「同じタイプがすでにいるから～」 ってのは厳しい世界なんだと改めて感じました。

電子書籍端末
相変わらず悩んでいるわけですが ;) たとえば技術書なんかだと版型大きいのありますよね。 そういうのを考えると A4 を原寸大で表示できるといいよなあと思うのですが、 さすがにそりゃ大きすぎるだろうと。 とはいえ、7インチあたりのスクリーンに収まるように縮小して読むとすると それってどうなのよと。スクロールしながら読むのもなんだかなあという気はするし、 スクリーンにあわせて「適切」に組版(といっていいんだろうか)することって できるんでしょうか? 一台何か買ってみますかねえ(って金がないよ ○|￣|＿

■_ 

★★Java質問･相談スレッド147★★ 

847 デフォルトの名無しさん [] 2011/09/17(土) 01:04:41.05 ID: Be:
    配列よりArrayListの方が便利なんですが
    性能的にはどうなんですか？ 

849 デフォルトの名無しさん [sage] 2011/09/17(土) 09:45:24.61 ID: Be:
    >>847
    読んで字のごとく内部で配列使ってるんだから素の配列使うより遅いに決まってるだろ。
    javaの配列自体遅いから気にする程でもないが。 

850 デフォルトの名無しさん [sage] 2011/09/17(土) 11:54:15.98 ID: Be:
    要素がオブジェクトなら言うほど遅くないが
    IntegerとかDoubleとかでボックス化しまくるととんでもなく遅くなる 

851 デフォルトの名無しさん [sage] 2011/09/17(土) 12:06:32.35 ID: Be:
    名詞じゃないんだからBOX化ってへんじゃないか？ 

852 デフォルトの名無しさん [sage] 2011/09/17(土) 12:13:31.87 ID: Be:
    >>851
    autoboxingのboxは名詞が動詞化したものだろうけど、
    ボックス化の"ボックス"は普通に名詞だろう。

    というか一般的な用語だと思うけど。
    http://ja.wikipedia.org/wiki/%E3%83%9C%E3%83%83%E3%82%AF%E3%82%B9%E5%8C%96 

858 デフォルトの名無しさん [sage] 2011/09/17(土) 12:53:11.87 ID: Be:
    Java5より前にboxって言葉使われてたっけ?
    .NETだとボックス化は公式用語だけど、それ由来? 

863 デフォルトの名無しさん [sage] 2011/09/17(土) 13:12:09.69 ID: Be:
    イギリス在住で
    「Boxing Day」を、人を殴りまくっていい日かなんかと
    勘違いする日本人は多いらしい。 

898 デフォルトの名無しさん [sage] 2011/09/17(土) 17:59:46.63 ID: Be:
    >>852
    javaだとそのままカタカナ英語にしてオートボクシング/アンボクシングだし基本値とオブジェクト型のラップを勝手にやるjavascriptじゃ名前すら無い。
    C#でしか聞いたこと無いしググってもDVD-BOXかwikipediaかC#しかでてこなかった。文法はあってんだけど感覚的に変な訳だな。 

899 デフォルトの名無しさん [sage] 2011/09/17(土) 18:15:25.87 ID: Be:
    まあボックス化っていうとboxalizeの訳語か？みたいにみ聞こえるのは確か。

む。うぃきぺにあるのか。 ボックス化 - Wikipedia

それはそれとして box って動詞でもあるんだがねえ 

Box | Define Box at Dictionary.com
box

verb (used with object)

23. to put into a box: She boxed the glassware before the movers came.
24. to enclose or confine as in a box (often followed by in  or up ).
25. to furnish with a box.
(以下略)

なんだから、boxing → ボックス化 とするのはまずいでそ。 

ボックス化 - Wikipedia
ボックス化（boxing）とは、プログラミング言語において値型をオブジェクト型（参照型）に変
換すること。逆に、ボックス化されたオブジェクトを値型に戻すことをボックス化解除（
unboxing）と呼ぶ。

Javaや.NET Frameworkなどの近代的な環境においては、値型（Javaでは原始型がこれに相当する）
と参照型という根本的に異なる二種類の型が存在する。参照型のインスタンスはヒープ上の独立
した領域に確保される。値型は文脈によって確保される場所は異なるものの、いずれにせよメモ
リ上に連続的に確保される（例えば、ローカル変数として宣言された場合はスタック上に確保さ
れ、参照型のメンバとして宣言された場合は参照型の一部として確保される）。


Object type (object-oriented programming) - Wikipedia, the free encyclopedia

Boxing is the process of placing a primitive type within an object so that the 
primitive can be used as a reference object. For example, lists may have certain 
methods which arrays might not, but the list might also require that all of its 
members be dynamic objects. In this case, the added functionality of the list might be 
unavailable to a simple array of numbers. For a more concrete example, in Java, a 
LinkedList can change its size, but an array must have a fixed size. One might desire 
to have a LinkedList of ints, but the LinkedList class only lists references to 
dynamic objects — it cannot list primitive types, which are value types.

Boxing is the process of placing a primitive type within an object so that the primitive can be used as a reference object. (boxing とはある primitve type をオブジェクトの中に置くことによってその primitive を reference object として 使えるようにする process である お粗末) は ボックス化（boxing）とは、プログラミング言語において値型をオブジェクト型（参照型）に変換すること。 とは違うと思うのだけどねえ。 この訳語にしたやつは(ry

■_ 砂糖たくさん

Causes Tech: Seven Programming Languages in Seven Weeks: Ruby の 3枚目。 

Week 1: Ruby - Background

    * Born in 1993 by Matz
    * Made popular in 2006 by Rails


    * Built for comfort, not for speed
          o Optimized for programmer productivity, not execution time
          o Syntax has more sugar than a can of Coke
          o Strongly typed, dynamic, interpreted, object oriented
          o Mixins, metaprogramming, dynamic function definitions
          o ^^^ the stuff that makes it hard to ack/lint

「缶コーラよりも砂糖にまみれた構文」 (超訳) て。

24枚目。長所。 

Week 1: Ruby -- Conclusion: the Good

    * Community: blogs, documentation, Github, gems, etc
    * Blocks
          o Good way to pass functions to functions
    * Mixins/metaprogramming
          o Good for stubbing functions for testing purposes
          o Good for clean organization of model methods
          o Good for creating domain-specific languages
    * Method chaining
          o my_list.sort.uniq.map {|x| x *2}.length
    * Pretty Code
          o Good code tends to look pretty
          o Ugly code means you're probably not being idiomatic

次は短所。 

Week 1: Ruby -- Conclusion: the Bad

    * Blocks
          o `yield` is misleading
    * Mixins/metaprogramming
          o Makes acking for some functions or variables impossible
          o 1.adam WHERE IS THIS DEFINED???
    * Loquacity
          o map, collect
          o reduce, inject
          o find, detect
    * "Too ambitious" (i.e. not lazy)
          o map creates the resulting list in memory
    * Lack of true keyword function arguments
    * Hash literal syntax (should be JSON-like)[1]

yield が misleading ってのはなんだろう

26枚目には1.9で改善されたのが欠点としてあったり。 でもまあ 1.8 死んだって言い切れないしなあ。

■_

■_

こういうの視聴用の端末が欲しい Writing modern C++ code: how C++ has evolved over the years | BUILD2011 | Channel 9

2011年09月17日

■_

函数プログラミングの集い 2011 in Tokyo - [PARTAKE] に行ってきました。まとめを書くのは面倒なので 函数プログラミングで集いに来ました - a geek born in Tomakomai あたりを(手抜きモード)。

プログラミング Coq を書いている人が実在の人物とは思わなかった。

ふと思った疑問。Emacs カラー表示っていつぐらいからできるようになったんでしょ? キーワードの色つけ表示が入った頃? 最初に実装したエディターは?

■_

ボツ。

■_ 重箱の隅

InfoQ: C#、ScalaのシンタックスをベースにしたJavaのラムダ式 


C#、ScalaのシンタックスをベースにしたJavaのラムダ式

Java 8において最も期待されている新機能の一つがラムダ式だ。ラムダ式とは、データのように
引数や変数に渡すことのできる匿名関数のことだ。ラムダ式のシンタックスは確定していなかっ
たが、人々が最も精通しているシンタックスは何なのか、調査が行われた。

lambda-devメーリングリストに最近投稿されたメールによると、Javaのラムダ式はC#ベースのシ
ンタックスになる予定であるとのことだ。C#ベースのシンタックスは既に広く知られ、利用され
ている(C#では、バージョン1.0でデリゲートが、バージョン2.0で匿名メソッドが、バージョン
3.0でラムダ式がサポートされた)。

訳文だと「ラムダ式」でまとめちゃってるけど、 原文を見ると「Lambda expression」というのはわりと限定されているものを 指しているような。

それと、 the syntax for these wasn't widely decided, with polls asking for input on what would be most familiar to others. を ラムダ式のシンタックスは確定していなかったが、人々が最も精通しているシンタックスは何なのか、調査が行われた。 とするのも違和感が。精通ってここで意図するような意味を持つのかも疑問があります。 慣れ親しんでるといったこととは違いますよね? 

InfoQ: Java Lambda Syntax based on C#, Scala

Java Lambda Syntax based on C#, Scala

Posted by Alex Blewitt on Sep 09, 2011

One of the most anticipated new features of Java 8 is the introduction of Lambdas, which
are anonymous functions that can be passed around like data in arguments and variables.
However, the syntax for these wasn't widely decided, with polls asking for input on what
would be most familiar to others.

A recent posting on the lambda-dev mailing list announced the conclusion that the Java 
Lambda syntax will be based on C# syntax. This is already widely known and used (as C# 
had delegates back in 1.0, support for delegate functions in 2.0 and lambda expressions
in 3.0).

「式」について、たとえばこの部分でもintroduction of Lambdas, which ～ とかJava Lambda syntax となっていて、expression はついてないのですよね。 それは list comprehension 訳が「リスト内包表記」となっているように 日本語にするときに補ったものではないか、原語でも隠されていたものではないか と考えられなくもないのですが、最後まで読むとどうも違うような気がしたのです。 

BGGAのような他の候補もあったが、調査では他に比べて圧倒的に優れているものはないという結
果が得られた。加えて、C#やScalaで使われている既存のシンタックスは、より多くのプログラ
マに慣れ親しまれている(C#スタイルとScalaスタイルの匿名関数の主な違いは、引数の型の指定
方法である。C#では“int foo”と指定するが、Scalaでは“foo: int”のように指定する。つま
り両者に大きな差はない。Java 8では、通常のメソッドの引数の型を指定するやり方にあわせて、
C#が採用している“int foo”というスタイルを採用する予定だ)。

    大規模な調査を行ったにも関わらず、どの候補がよりよいのかは、はっきりとしませんでした(それ
    ぞれのシンタックスには、よい部分とよいとは言いきれない部分があり、他に比べてはっきりとよ
    いと言えるものはありませんでした)。それで、我々は最もJavaに似た二つの言語(C# とScala)で既
    に使われているシンタックスを採用するのが、新しいシンタックスを作り出すよりもベターであると
    思ったのです。

「匿名」はまあおいといて。 

InfoQ: Java Lambda Syntax based on C#, Scala

Other alternatives were available (such as BGGA) but the response to the survey suggested
that there wasn't a huge advantage of one over the other; in addition, the pre-existing
experiences of those using C# and Scala mean that there are likely to be many more
programmers familiar with the general type of syntax. (The key difference between the C#
and the Scala style of anonymous function is with how arguments are typed; C# uses
“int foo” while Scala uses “foo: int” － a difference that will be fairly easy to move
between. Java will adopt C#'s style of “int foo” in deference to the way types are
represented in Java.)

    Despite extensive searching, there was no clear winner among the alternatives (each form
    had some good aspects and some really not very good aspects, and there was no form that
    was clearly better than the others). So, we felt that it was better to choose something
    that has already been shown to work well in the two languages that are most like Java －
    C# and Scala － rather than to invent something new. 




式とブロックの両方が使えるようになる予定だ。式はブレースなしで表現され、評価されると値
を返すというものだ。ブロックはブレースで囲んで表現され、returnキーワードが指定されない
限り値を返さない。例えば

    x => x + 1
    (x) => x + 1
    (int x) => x + 1
    (int x, int y) => x + y
    (x, y) => x + y
    (x, y) => { System.out.printf("%d + %d = %d%n", x, y, x+y); }
    () => { System.out.println("I am a Runnable"); }


ラムダ式の主要な利点の一つは、引数の型の推測である。いくつかのケースでは、コンパイラは
正しい型を推測することができない(特にオーバーロードされた演算子のケースである。“(x,y) 
=> x+y”は、xとyがlongなのかdoubleなのか、あるいはObjectなのかということを知らなけ
れば、全くコンパイルすることができない)。ほとんどのケースでは、型推測エンジンは正しい
コードを生成するだろう。しかし、もし必要であれば、開発者が型情報を常に明示的に指定する
ことも可能だ。

新しいシンタックスをサポートしたコンパイラは、実験目的のため、近いうちに利用できるよう
になるだろう。

http://twitter.com/InfoQJapan InfoQ Japan and all content copyright © 2011 C4Media Inc. & Component Square, Inc.
InfoQ Japan hosted at Contegix, the best ISP we've ever worked with.








InfoQ: Java Lambda Syntax based on C#, Scala

Both expressions and blocks will be permitted. An expression is represented without 
the curly braces {} and will, when evaluated, return the result. Blocks of statements 
are surrounded with {} and will not return a result unless the return keyword is used. 
The examples given in the mail are:

    x => x + 1
    (x) => x + 1
    (int x) => x + 1
    (int x, int y) => x + y
    (x, y) => x + y
    (x, y) => { System.out.printf("%d + %d = %d%n", x, y, x+y); }
    () => { System.out.println("I am a Runnable"); }

One key advantage of the lambda expressions is that they will infer the types of the 
arguments if not specified. In some cases, the compiler may not be able to infer the 
correct types (especially in the case of overloaded operators; the “(x,y) => x+y” 
is highly unlikely to compile if Java doesn't know whether the x and y are long or 
double (or even Object). In most cases the type inference engine is likely to generate 
the correct code, although if further assistance is needed then the developer can 
always explicitly add the typing information.

A compiler which understands the new syntax will be made available in the near future 
for experimentation purposes.


http://twitter.com/infoq InfoQ.com and all content copyright c 2006-2011 C4Media Inc.
InfoQ.com hosted at Contegix, the best ISP we've ever worked with.







  ここで、expression と block という二つのものがでてきます。
  ここまで読むと、少なくとも Lambda expression というのはブレースを伴わない
  Lambda の表記を指しているように思えます。




  One key 以下のパラグラフも原文と訳文でずれがあるように思います。
  訳文は文の流れもおかしい感じがしますし。



このラムダ式の key advantage のひとつは引数の型が指定されていないときに
それを推測するというものです。しかし一部のケースではコンパイラーは
正しい型を推測できないかもしれません(特にオーバーロードされた演算子が
ある場合。“(x,y) => x+y”は x や y が long なのか double なのか
あるいは Object ですらあるかどうかをJava が決定できなければ、
とてもコンパイルできそうにありません)。手助けが必要となったときには
developer が型情報を陽に指定することがいつでも可能ですが
型推測エンジンは大半のケースで正しいコードを生成するでしょう。




  んー、いまいち。

■_ reduce/reduce conflict

yacc の場合は、先に出現したルールで reduce するんじゃなかったけか? ＞ reduce/reduce conflict 

Ambiguity and conflicts
When there are shift-reduce or reduce-reduce conflicts, yacc still produces a parser. 
It does this by selecting one of the valid steps wherever it has a choice. A rule 
describing the choice to make in a given situation is called a disambiguating rule.

yacc invokes two default disambiguating rules:

   1. In a shift-reduce conflict, the default is to do the shift.

   2. In a reduce-reduce conflict, the default is to reduce by the earlier grammar 
      rule (in the yacc specification). 

Rule 1 implies that reductions are deferred in favor of shifts when there is a choice. 
Rule 2 gives the user rather crude control over the behavior of the parser in this 
situation, but reduce-reduce conflicts should be avoided when possible.

こんな感じ。 とはいえその場合に全体として期待通りに動くものになるかは… 

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

658 デフォルトの名無しさん [] 2011/09/17(土) 01:07:28.10 ID: Be:
    ttp://www.geocities.co.jp/SiliconValley-Oakland/3432/man/bison/bison-ja_8.html#SEC69
    で
    「最後のn個のトークンとグループが文法規則に当てはまる場合には、
    それらは規則に従って組み合わされます。これを、還元（reduction）と呼びます。」
    とあるのですが、最後のn個というのは複数通りの文法規則があてはまる場合
    長い方と短いほうどちらになるのでしょうか？ 

「コンパイラ・スクリプトエンジン」相談室15

120 デフォルトの名無しさん [sage] 2011/09/17(土) 00:56:25.04 ID: Be:
    ttp://www.geocities.co.jp/SiliconValley-Oakland/3432/man/bison/bison-ja_8.html#SEC69
    で
    「最後のn個のトークンとグループが文法規則に当てはまる場合には、
    それらは規則に従って組み合わされます。これを、還元（reduction）と呼びます。」
    とあるのですが、最後のn個というのは複数通りの文法規則があてはまる場合
    長い方と短いほうどちらになるのでしょうか？ 

121 デフォルトの名無しさん [sage] 2011/09/17(土) 09:05:52.81 ID: Be:
    還元/還元コンフリクト

続きの質問がw 

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

670 デフォルトの名無しさん [] 2011/09/17(土) 19:34:07.75 ID: Be:
    bisonの
    a: /*空*/ |
    ...
    っていうような
    /*空*/ってどういうときマッチするんでしょうか？
    一回以上の繰り返しとかを終わらせるとかくらいしかないです？ 

「コンパイラ・スクリプトエンジン」相談室15

122 デフォルトの名無しさん [sage] 2011/09/17(土) 17:05:32.36 ID: Be:
    >>121
    どうもです。
    あとbisonの
    a: /*空*/ |
    ...
    っていうような
    /*空*/ってどういうときマッチするんでしょうか？
    一回以上の繰り返しとかを終わらせるとかくらいしかないです？

ruby なんかの行末にあるセミコロンであるとか 実引数がないかもしれない引数リストなんかだと 空にもできるようにしておかないと大変なことに。

■_ どちらも人名

もいっこム板から。 

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

639 デフォルトの名無しさん [sage] 2011/09/17(土) 12:35:08.81 ID: Be:
    機械語はナウマン式コンピューターだと全部一緒。
    ソロバンや指を折って数えるやり方も同じ。
    高級言語って い+ろ をAと、は+に をBと置きかえて
    さらにA+Bを Δと置き換えてって繰り返してるだけだし
    置き換え方式や細かいルールが違うからソースを変えないと動かないけど、やってることは一緒 

644 デフォルトの名無しさん [sage] 2011/09/17(土) 12:56:51.87 ID: Be:
    Naumann
    Neumann

    最初の標本は明治時代初期に横須賀で発見され、ドイツのお雇い外国人ハインリッヒ・エドムント・ナウマン
    （Heinrich Edmund Naumann: 1854年-1927年）によって研究、報告された[2]
    ナウマンゾウ - Wikipedia

    ノイマン型の名は、最初にこれを広めたEDVACに関する報告書 First Draft of a Report on the EDVAC
    の著者がジョン・フォン・ノイマン（ひとり）になっていることに由来
    ノイマン型（-がた、von Neumann architecture）
    ノイマン型 - Wikipedia

でもまあひょっとしたらカタカナ表記が間違っているのかも

■_

2011年09月16日

■_

んーむ。今週もうちょっといろいろやってるはずだったんだがなあ(ありがち)。 まあ初日(月曜)にちとアクシデントがあったりはしたけれども。

・数学記号
mapsto とかいう記号 ↦ がありまして、 これがまた TAPL でやたらたくさんでてくるんですけど どうやって入力したものやら(上にあるのは文字コード表からコピペしました)。 んで、よくわからんけど ↦ ↤ ↥ ↧ と四方向そろってるんですよね。いったいナニモノなのこいつら。 ⊢ というのもやはりTAPLでよく出てくる 記号なのですが、これも四方向分コード表にはあったり。 数学記号の表 - Wikipedia 目的別LaTeXガイド - [数式]数学記号 数学記号 [物理のかぎしっぽ]

<

■_ C++11 Features in Visual C++ 11

本文はどうでもよくて、 コメント欄から。 

C++11 Features in Visual C++ 11 - Visual C++ Team Blog - Site Home - MSDN Blogs

Comments 
 
 No range-based for-loop? That's a shame. :( 
 
 Was looking forward to start using it, G++ supports it already.
  

 @Stephan, I'm sorry but if I understand correctly what this article/table is saying 
there will be 3 (three)!!! new core features implemented in VS.next compared to what 
we have in VS10 and not even full concurrency? Is this some kind of joke? 
  

 arhhhh ,Still no support for Variadic templates 
  
 
 I appreciate all the hard work going into VC11, including all the library and 
compiler efforts. Still, as others have noted the changes in the support of new C++11 
features are rather disappointing. At this rate I'm not sure even VC12 would be 
feature complete. Does it mean we'll have to wait till 2016~17 before we can begin to 
use full C++11 with Windows' core C++ compiler? 
  
 The VC team has 10 years to implement C++11 :-) What would they add to VC12... if 
everything was in VC11 ;-) Good job team!! When can we put our hands on all these 
niceties? 
 
  
 It's obviously great to see support for new C++11 features, but it sounds like I'm not
 the only one who's a bit underwhelmed with the number of new features. 
 
 At this rate, you'll have support for *most* new core language features at some point 
 around 2020. 
 
 If Microsoft isn't willing to fund the necessary man-hours to maintain a C++ compiler 
 and keep up with the standard and the competition, perhaps you should just ditch 
 cl.exe and start working on integrating Clang or GCC into the IDE instead. 
 
 It's starting to sound like that's the only way you're ever going to support C++11. 
  
 
 This is the virtual "Like" button for jalf's opinion on the matter 
 (meta.stackoverflow.com/.../105901). I can't wait for 2020. 
  
 
 "only MS dev working on the STL" -- That pretty much completely undermines
Diegum's assertion that MS cares about C++ 
  

I as a C++ developer more than anything need a good standard conforming C++ compiler. 
No fancy shmancy IDE, no hours and hours of your EMPTY talks, no so called silly
“improvements to the IDE and productivity” in form of syntax highlighting, code 
snippets etc. All I need is a good standard conforming compiler. And what do we (C++ 
devs) have (not even at this moment but what is being prepared for future release)? 
Nothing! Microsoft once again by its actions proves that C++ means absolutely nothing 
to this company. 

Sir, while employed at Microsoft you did nothing in order to represent C++ community, 
nothing in order to fight for us and *with* us and nothing in order to protect and 
give a breeding space to C++. Being in your position and a person who you were (not 
ARE anymore, but about that in a short while) you could have made an impact on how C++ 
compiler from Microsoft would look in a future release of Very Slow 2012. But you did 
NOTHING. Absolutely nothing… Yes, of course you talked a lot but that’s just about 
it. Nothing else. Results are pathetic, catastrophic, you name it… no! you don’t 
have the right anymore to talk about C++. Unless you’re begging for forgiveness. 
 
How can you look in Bjarne’s eyes? How can you look and do nothing seeing how his 
child is being mistreated, humiliated, ignored and abused? 
 
For all this today, on 14th of September of 2011, I officially declare you as a 
TRAITOR TO C++ AS A LANGUAGE AND A TRAITOR TO C++ COMMUNITY. From now on you are 
non-existing non entity. 
 
C++ Rules and Rocks! 
 
Forever! 
 
  
 
 > Microsoft once again by its actions proves that C++ means absolutely nothing to this company. 
 
 Seems you haven't seen yet WinRT and new syntax extensions. 
  

 © 2011 Microsoft Corporation.

いやひどい言われようだこと。

■_ WinRT

もうひとつMicrosoftネタ 

WinRT demystified - Miguel de Icaza

WinRT demystified

Posted on 15 Sep 2011 by Miguel de Icaza

(略)

COM Interop allows using C or C++ APIs directly from C# by importing the COM type 
libraries and having the runtime provide the necessary glue. This is how Mono talked 
with OpenOffice (which is based on COM), or how Mono talks to VirtualBox (which has an 
XPCOM based API).

There are many ways of creating bindings for a native library, but doing it by hand is 
bound to be both tedious and error prone. So everyone has adopted some form of "contract"
that states what the API is, and the binding author uses this contract to create their
language binding.

WinRT

WinRT is a new set of APIs that have the following properties:
WinRTは以下のような性質を持ったあたらしいAPI群です:

    * It implements the new Metro look.
      WinRT はあたらしい Metro の外見を実装しています

    * Has a simple UI programming model for Windows developers (You do not need to learn
      Win32, what an HDC, WndProc or LPARAM is).
      WinRT はWindows developers のための単純なUIプログラミングモデルを有しています
      (Win32 を学習する必要はなく、HDC や WndProc、LPARAM といったものがなんであるのかを
      学ぶ必要もありません)。

    * It exposes the WPF/Silverlight XAML UI model to developers.
      develpers のための WPF/Silverlight XAML UI モデルを表現します

    * The APIs are all designed to be asynchronous.
      API はすべて非同期であるように設計されています

    * It is a sandboxed API, designed for creating self-contained, AppStore-ready
      applications. You wont get everything you want to create for example Backup Software
      or Hard Disk Partitioning software.

      サンドボックス API であり、self-containd で AppStore-ready なアプリケーションを
      作るために設計されています。これまでと同様に、望むものすべて、たとえば
      バックアップソフトウェアやハードディスクのパーティショニングソフトウェアを作るのに
      必要なものも手に入ります。
      #自信ない

    * The API definitions is exposed in the ECMA 335 metadata format (the same one that
      .NET uses, you can find those as ".winmd" files).
      API 定義は ECMA 335 メタデータフォーマットを使って expose されています

WinRT wraps both the new UI system as well as old Win32 APIs and it happens that this 
implementation is based on top of COM.

WinRT demystified - Miguel de Icaza : programming

■_

■_

2011年09月15日

■_

都立中央図書館行った あとで書く

■_

APL。 あとで(ry

APL ユーザー会報のとある号に、 月刊 ASCII で一年くらいの連載をするという記述があったので ASCII のバックナンバーを調べてみることにしました。 が、しかし、国会図書館所蔵分のものはデジタル化作業中ということで残念ながら閲覧できません (来年4月くらいまでには完了させたいとかなんとか) でした。 そりゃあ困ったと頭を抱えていると相談窓口の係の方が調べてくれて、 都内では国会図書館のほかに二ヶ所所蔵しているところがあるということがわかりました。 ひとつが都立中央図書館で、もう一ヶ所が東京都立多摩図書館ということでしたが、 後者は立川にあるということで移動の手間やらを考えてとりあえず近いほうの都立中央図書館へ。 東京都立多摩図書館のトップページ)

つづく

■_

2011年09月14日

■_

船の科学館行った。 あとで書く ちょっと書いた


本当にゆりかもめの「船の科学館駅」のすぐそばなんですよね。 ゆりかもめ使って来たのは初めて(通過したことは何度か)。


展望塔から宗谷と羊蹄丸を望む


同じく展望塔からビッグサイト方面をみる


刻まれている文字がなんとなく昭和っぽい

■_

スライドを書く暇に原稿を書いてはどうか（とか）: つらつらぐさ

あとで書く

■_

2011年09月13日

■_

気がついたら国会図書館にきていました(謎) 今日は今月いっぱいで休館するという船の科学館へいくつもりだったのになぜ… bit 電子化 コピー

bit やら インターフェース、アイオー、マイコンといった古くからある (というかかつて発行されていた) 雑誌の創刊あたりのものから調べてみようということで国会図書館に出向いたのですが、 デジタル化作業の対象になっているらしく、bit、インターフェースは閲覧できませんでした ○|￣|＿

それはそれとしても、いろいろと面白いものを見つけられました。

■_

Amazon.co.jp： APL-プログラミング言語 (1975年): イバーソン, 内山 昭, 長田 純一: 本 という本を国会図書館で発見。 以下あとで書く 

  まえがき
  応用数学の主要関心事はいろいろな関数の正確な値や近似値を計算する具体的な手順の計画解析である。
  このような具体的手順は算法とかプログラムと呼ばれる。プログラムを能率よく記述する記号法の構造は
  きわめて文章論的なので、この記号法はプログラミング言語と呼ばれる。

  応用数学の多くは、特に古くからある分野で最近計算機が関係するようになった部分では、
  この適当なプログラミング言語を適用したときの記述力解析力はそれをマスターするのに費やした
  努力を償って余りあるということである。
(略)
                                                                          1962年5月
                                                 ニューヨーク州マウント・キスコにて
 
                                                                Kenneth E. Iverson

訳者まえがき

 A Programming Language は当時ハーバード大学にいた Kenneth E. Iverson 教授を中心とする
ごく少数のグループによって研究され、1962年に出版された本書となって一般に紹介された。
以来十数年の歳月をへたが、その間、この言語はその頭文字をとってAPL、またはIversonランゲージ
として広く普及されてきた。

(略)

 このようなわけで原書が出版されてから相当期間たった今になって翻訳をしたのであるが、
内容が数学と電算機に両方にまたがるため訳語の選択には苦心した。というのは、もとが
同じ英単語でも数学で用いられる訳語と計算機関係で用いられる訳語が多くの場合
全く異なっているからである。数学用語については文部省で編さんした「学術用語数学編」を
主とし、その他各種の数学辞典を利用した。電算機用語にはJIS用語を尊重して作られた
「IBM情報処理用語対訳集」を基準にとった。しかしたとえば、数学で backward は多くの場合
「後退」と訳しているが(backward diffrence, backward steps など)、
電算機の方では「逆方向」と訳す(backward read など)。また、implicit, explicit は
計算機の方では半ば機械的に「暗黙的」「明示的」と訳すことになっているが、数学では
だいたい「陰に」「陽に」と訳す(implicit function = 陰関数など)。このような相違が
各所にみられるので、その場その場で適当な訳語を使えばよいが、定義された述語については
そうもいかない。それで選択規則として数学に多く関係する語は数学用語、計算機に多く関係する
語は計算機用語、両者に等分にまたがる語はどちらか一方または全く別の語を使うことにした。
この点をはっきりさすため巻末に「用語対訳表」をつけた。活用されたい。

1974年9月 内山  昭
          長田純一

追記: 最後の日付にあるように、1974年の本なのですが このころはもう implicit → 暗黙的 explicit → 明示的 って訳がそれなりに定着していたのですね。 さて、ここからさらにどのくらいさかのぼれるだろう?

■_ APL

APLのユーザー会の会報ってのを国会図書館で見つけたのですが この内容がなかなか熱い。

喜多:今回の会議でも銀行・保険・証券等の金融関係の人がわりと多かったんだけど、 中でも10人もの参加者で気を吐いていたのがモルガン・スタンレーで、朝一番の講演でも 次のような大変エキサイティングなものでした。 8:30- 9:15 Tony Lants (Morgan Stanley) Winning with APL モルガン・スタンレーではIBM 3090-200 でSharp APLを IBM 3090-400(VF) でIBM APL およびSTSC APLを使用し、各種のレポートティング等に活用していて大変成功している というサクセスストーリの報告でした。 詳細について、ここでは述べませんが数学的サポートに、APLによる電子メールを 使用しているとか、各種のパフォーマンス・モニタを作成したとか、単にAPLを金融 シミュレーションの道具としてだけではなく Production System としてフルに活用している 様子がわかりました。

喜多:どうせ わい は屈折した性格やがな。 あっそうそう、そうこうしとるうちに今度はフランス人が『おやおや、これは日本人じゃないか。 日本人にもAPLを使っているやつがいたのか?!』といちゃもんをつけてきよったわけや。 弥次:あらら、こりゃだめだ。なんで急に関西弁になるわけ?。 そもそも英語もろくに話せない人がフランス人と喧嘩をしたの?。 喜多:もちろん、いくら高慢ちきなフランス人でもここでは世界の公用語 English を使いよったで…。 そこでわいは ポンポンゆうたったがな、なにゆうとんねん日本は米国に次ぐAPLのビッグ・ユーザ国で IBMと日立のメインフレーム・ユーザだけで数百社にのぼる企業が利用していて、さらには……と 突然ひとの言葉をさえぎって『そうだろう、なのに何故日本人は誰もISO APL WGに来てAPLの標準化作業に 参加しようとしないのか理解に苦しむ』と言うんだよね。 弥次:なるほど、そのフランス人は一枚も二枚も上手であなたの返答を予想したうえでここに 日本人がいたぞって声をかけてきたわけね。 喜多:なんでも数年前に日本人が一度きたきりで、その後全くVootingもしないけど日本はいったい どうなってんだってことなんだよね。 その場で僕は返答に困ってしまったんだけど、とにかく日本に帰ったら伝えますとは言ったものの いったい誰に伝えればいいんだろうね。 ほっとけば誰かが重い腰を上げるかね。

あとで

これが記載された号が80年代終盤だったと思いますが なんというかまあどうしたものか。 元の分ではこのあと日本人のボランティアに対する姿勢はとか続くのですが、 批判の方向がちょっと違うかなという気も。 この辺はまた改めて書く…かもしれません。

■_

InfoQ

■_

■_

■_

2011年09月12日

■_

今月はまた面白そうな本がいろいろと。 Amazon.co.jp： ファンクション+アクション=プログラム: 金谷 一朗: 本 Amazon.co.jp： Excel環境下でのシステム開発への挑戦　第2版 -データベース機能の活用-: 西荒井 学, 小林 久恵: 本 O'Reilly Japan - Making Software

割と伸びた 1-indexed arrays in Python : programming

■_

この article を知ったのは昨日なのだけど、URL見ると8月中に書かれたものらしいですね。 

(think) - A peek at Emacs 24

A peek at Emacs 24

Overture

Recently I've decided to have a look at the current development version of Emacs - 
namely Emacs 24. I was quite impressed with the work done by the development team so 
far so I decided to share some of the cool things I've found in Emacs 24.

It seems to me that this will be the most important Emacs release in quite some time.

Installation changes in Emacs 24

There are a couple of new build flags support in Emacs 24 - most notably there is GTK 
3.0 support present. You can enable it by passing the –with-x-toolkit=gtk3 flag to 
configure. There is also built-in support for selinux (that can be disabled at build 
time) and the installed info and man pages are now compressed by default.

All in all - nothing major has changed with the installation process.

(略)

Epilogue

Emacs 24 brings quite a lot to the table. I've barely scratch the surface as far as 
the new features are concerned. There is so much more - improvements to lots of the 
existing modes (most notably much better support for distributed VC systems such as 
Git, Mercurial and Bazaar), internal cleanups and improvements, etc.

I truly feel that Emacs 24 will be the most important Emacs release in a long long 
time and I commend the new dev team leads for their passion and resolve to modernize 
Emacs.

Expect future blog posts dedicated to specific new features and improvements.

P.S. Btw The Emacs Dev Kit already makes use of some the new features from Emacs 24. 
In due time it will make use of much more of them.

Posted on 19 Aug 2011 by Bozhidar. Filed under Emacs.

コード規模の増加具合を Emacs 18 辺りからメジャーバージョンごとに比べてみたいもんだな

■_ reddit の プログラミングカテゴリ

Reddit directory » Programming 知らなかったのが結構あるな(休眠状態のも含めてだけど)。 

Reddit directory » Programming

1 	programming
342,704 subscribers with 864 new, created 5 years ago
programming	

2 	linux
58,343 subscribers with 910 new, created 3 years ago
The Linux Subreddit.	

3 	netsec
37,519 subscribers with 795 new, created 4 years ago
/r/netsec - Network Security News & Discussion	

4 	web_design
37,079 subscribers with 766 new, created 3 years ago
web_design	

5 	Python (Languages)
23,814 subscribers with 445 new, created 3 years ago
Python	

6 	compsci (Computer Science)
23,791 subscribers with 745 new, created 3 years ago
Computer Science: Theory and Application	

7 	software
18,249 subscribers with 247 new, created 3 years ago
software	

8 	coding
16,515 subscribers with 61 new, created 1 year ago
coding	

9 	opensource
15,937 subscribers with 217 new, created 3 years ago
Open Source on Reddit	

10 	learnprogramming
13,641 subscribers with 687 new, created 1 year ago
learn programming	

11 	javascript (Languages)
13,368 subscribers with 283 new, created 3 years ago
JavaScript	

12 	gamedev
13,207 subscribers with 776 new, created 3 years ago
gamedev - game development, programming, math, art, collaboration	

13 	carlhprogramming
10,522 subscribers with 16 new, created 1 year ago
Free Programming Classes : Learn How to Program	

14 	PHP (Languages)
9,869 subscribers with 198 new, created 3 years ago
PHP: The latest news in the PHP world	

15 	ReverseEngineering
8,557 subscribers with 275 new, created 3 years ago
Reverse Engineering	

16 	ruby (Languages)
8,511 subscribers with 70 new, created 3 years ago
reddit for ruby hackers	

17 	hackers
8,456 subscribers with 4 new, created 3 years ago
hackers	

18 	webdev
8,160 subscribers with 345 new, created 2 years ago
webdev: reddit for web developers	

19 	haskell (Languages)
7,371 subscribers with 88 new, created 3 years ago
Haskell :: Reddit	

20 	cpp (Languages)
7,110 subscribers with 32 new, created 3 years ago
C++	

21 	linux4noobs
7,077 subscribers with 138 new, created 2 years ago
linux 101 stuff. questions are encouraged. So is answering it yourself and posting your methods.	

22 	MachineLearning (Artificial Intelligence)
5,615 subscribers with 135 new, created 2 years ago
Machine Learning	

23 	vim
5,482 subscribers with 138 new, created 3 years ago
vim	

24 	startups
5,471 subscribers with 280 new, created 3 years ago
Startups	

25 	java (Languages)
5,421 subscribers with 97 new, created 3 years ago
java	

26 	lisp (Languages)
5,112 subscribers with 38 new, created 3 years ago
Lisp	

27 	perl (Languages)
4,545 subscribers with 20 new, created 3 years ago
Perl	

28 	django (Frameworks)
4,434 subscribers with 106 new, created 3 years ago
Django	

29 	csbooks
4,196 subscribers with 13 new, created 2 years ago
Free (and legal) computer science textbooks	

30 	talesfromtechsupport
4,024 subscribers with 578 new, created 5 months ago
Tales From Tech Support

新しいのを開拓してみるかw

■_ 紺屋の?

from マ板。 

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

92 仕様書無しさん [] 2011/09/11(日) 14:43:56.67 ID: Be:
    おまえら工程書くのExcelでやってるの？
    Project使ってないの？ 

93 仕様書無しさん [sage] 2011/09/11(日) 14:47:23.67 ID: Be:
    excelなんて使えませんって人のほうが 

94 仕様書無しさん [sage] 2011/09/11(日) 15:01:25.01 ID: Be:
    Excelを使えるの判別が今いち分らない。 

95 仕様書無しさん [sage] 2011/09/11(日) 15:04:10.93 ID: Be:
    スーパマリオを作れる、とかじゃね？ 

97 仕様書無しさん [sage] 2011/09/11(日) 15:08:53.94 ID: Be:
    >>93
    むしろ、組み込み業界はExcelしかつかえませんって人ばかり。 

101 仕様書無しさん [sage] 2011/09/11(日) 15:19:56.32 ID: Be:
    >>97
    え？そうなの？
    普通にProject使って工程管理してるけど？ 

104 仕様書無しさん [sage] 2011/09/11(日) 16:02:08.72 ID: Be:
    >>92
    projectなんて使ってるのか？　フリーソフトで十分だろ
    工程管理に金だしてまでソフト買う必要ないだろ 

105 仕様書無しさん [sage] 2011/09/11(日) 16:07:37.84 ID: Be:
    中小零細は比較的自由なところが多いかも知れないけど、
    ある程度の規模のところ（もしくは、経営者が気持ちだけ大企業のつもりで
    コンプライアンス等にうるさいところ）はフリーソフト使えない場合が多いんじゃない？

    っていうか、そういう「お前そんなの使ってるのか」自慢はいかにもガキっぽい。 

106 仕様書無しさん [sage] 2011/09/11(日) 21:38:29.12 ID: Be:
    >>96 予定書くだけのためにソフト買えるかバカ
    というのがうちの会社の答え 

107 仕様書無しさん [sage] 2011/09/11(日) 21:58:22.05 ID: Be:
    ソフト屋がソフト買うなんて、大工が人に家建ててもらうようなもんだろ。 

109 仕様書無しさん [sage] 2011/09/11(日) 22:08:24.11 ID: Be:
    >>107
    ソフト屋だからって0から9まで全部自前で作るなんてアホなことはしないだろフツー 

110 仕様書無しさん [sage] 2011/09/11(日) 22:08:58.14 ID: Be:
    >>106 プロジェクト管理なめてるだろその会社 

111 仕様書無しさん [sage] 2011/09/11(日) 22:10:50.00 ID: Be:
    >>109
    おまいなんで添字１から始めないんだよw

112 仕様書無しさん [sage] 2011/09/11(日) 22:36:24.24 ID: Be:
    通は、0からFまでって言うけどな。 

119 仕様書無しさん [sage] 2011/09/12(月) 07:01:12.03 ID: Be:
    >>111
    組み込みは０からがデフォ。
    １から始めるやつは文系。 

120 仕様書無しさん [sage] 2011/09/12(月) 08:15:04.29 ID: Be:
    てめぇFortranバカにしてるのか？ 

124 仕様書無しさん [sage] 2011/09/12(月) 18:41:43.84 ID: Be:
    >>119
    社交ダンスでリズムの取り方を 「０，１，２，３、 ０，１，２，３、・・・」
    ってとるオッサンがいて、 ああこれが職業病かと思ったわ

125 仕様書無しさん [sage] 2011/09/12(月) 18:54:58.05 ID: Be:
    プログラマラジオ体操を作るべきだな 

126 仕様書無しさん [sage] 2011/09/12(月) 21:20:23.04 ID: Be:
    >>124
    それはアート引越センターでは？ 

127 仕様書無しさん [] 2011/09/12(月) 23:34:15.90 ID: Be:
    >>122
    楽しそう 

128 仕様書無しさん [sage] 2011/09/12(月) 23:36:54.89 ID: Be:
    >>124
    ちなみにオッサンは　　イチ　ニー　サン　シー　　でもなく　　ワン　ツー　スリー　フォー　　でもなく

    ワン　ツー　サン　シー　　と言うんだぜ

0 から 9 までにうけたw

■_

■_

交通案内 / ホーム - :: 船の科学館 -Museum of Maritime Science- :: ゆりかもめの「船の科学館駅」って、船の科学館がなくなっちゃったら名前どうするんだろう?

2011年09月11日

■_

電人ザボーガーの映画の公開初日(10/15)が YAPC::Asiaと被っていて、 しかも出勤日(前の週三連休だしね)に設定されている土曜日だということに今頃気づく。

■_ How do you learn good program design?

本日の redditに訊け 

How do you learn good program design? (How to split it into the most sensible objects, how to set up the file hierarchy, etc.) : ruby

I'm a self-taught programmer that wishes I was majoring in Computer Science rather 
than Finance because I feel like I lack fundamentals, especially when it comes to 
making a non-trivial program or gem. I have the confidence to code just about anything 
I want to, but I quickly lose steam when my code reminds me that I have no real vision 
of how to design a program. No real "boilerplate" to conceptually follow. 
Rarely more than one or two objects.

Looking at anyone else's code on Github reminds me how simplistic my concept of 
programming is. Especially when I look at gems that do such simple things. A lot of 
them are so cleverly set up in ways I would've never natively considered. So, I've 
been spending time studying well-known programmers' ruby code on Github. But I feel 
like I'm just trying to sniff out patterns in their commonalities and then guess at 
the reasoning behind them rather than actually educating myself.

Can anyone recommend any good books/resources that may help, particularly on the issue 
of how to design a program? I particularly like Ruby books since Ruby's minimal OO 
syntax makes it even easier to focus on the concepts of program design, but I'm sure 
the fundamental resources on this kind of stuff are written in other languages.



Don't study just Ruby. Study compiled languages, study functional languages, study 
assembly. Study design patterns and algorithms. Most importantly though is to write 
lots and lots of code. Write procedural code as well as OO, write an application that 
follows the concepts of the MVC framework without actually using a specific MVC 
framework. And don't, don't for fuck's sake ever think you now just get it, there is 
always room for improvement.



    Most importantly though is to write lots and lots of code.

I think this is the most important part of learning how to program in general. Most of the
advanced concepts you won't pick up until you have a problem that can be solved by them.



Books on refactoring can be very helpful. They not only give you a good idea of how to 
structure things; they show you how to transform existing programs to become that.

Good program design is not so much about coming up with the "grand design" 
for your system at the outset, but rather refactoring as you go, so your code is both 
manageable and readable.


   1. Keep reading code.
   2. Keep writing code.
   3. Learn a lot of programming languages
   4. GOTO 1


Then, learn structured programming ;-)



I'll recommend the RSpec Book. The reason is that it is a fantastic introduction to 
BDD (which is the biggest reason I love Cucumber). And the real point isn't even BDD, 
it's a technique that BDD formalizes: Starting with interface, not implementation.

That general idea has dramatically changed how I program, both in terms of being able 
to complete difficult problems, and in terms of having elegant APIs. I do it all the 
way down until there is nothing left to abstract. I call methods that don't exist, 
then when I go to write them, they in turn call methods that don't exist, and so forth, 
until the implementation is obvious. I found that patterns and APIs emerged without 
much effort. Of course, I am very familiar with the basics of the language, so I was 
able to focus very intently on the process without being sidetracked by the syntax or 
magic.

Anyway, since that's had such a profound impact (the paradigm behind BDD, not the 
RSpec Book in and of itself -- you don't even need these tools, they just make it 
easier to apply), I figure it's worth recommending.



You'll learn the fundamentals of CS if you major in CS. You won't necessarily learn 
good program architecture or design. The worst programs I've seen so far have come 
from CS students. Trailing fairly closely behind that is code that came from 
professors. A CS degree doesn't seem to be a great indicator of programming ability, 
in my experience, with good and shitty programmers coming from both the formal and 
self-taught camps.

The problem with CS programs (or at least the one I graduated from) is that you never 
do anything of any real scale. Architecture doesn't really matter much if you're 
writing something that's around 100 lines. You probably won't have to maintain it, 
either, so writing shitty code never bites you that badly in class. When you have to 
spend several years maintaining the same code base, suddenly architecture shifts to a 
higher priority.

The best advice I can give you, which echoes the opinions of several other commenters, 
is to write code. Lots of it. Rewrite code. Refactor code. Release something and get 
people to use it so you're forced to maintain it. Don't just write small applications. 
The bigger it is, the more obvious poor architecture becomes. Think about some gems 
and libraries you've used. Pick out some good ones and some not so good ones. What 
made one good and the other bad?

There's absolutely no substitute for experience. There's no book you can read or video 
you can watch that will show you how to make the right decisions most of the time [1]. 
So write code, learn from your mistakes, and repeat. In 10 years, you might be halfway 
decent at it.

■_ 0 or 1?

数え始めは 0 からか 1 からか。

訳は…どーしましょ 

[Python-ideas] List Revolution

[Python-ideas] List Revolution
Christopher King g.nius.ck at gmail.com
Fri Sep 9 23:12:21 CEST 2011

The first element in a list is element zero, the second is one, the third it
two, and so on. This some times confuses newbies to the language or
programming in general. This system was invited when single bits where
precious. It's time to update. Keep in mind this is something for version 4,
since its not reverse compatible. I say we make the first element 1, second
2, third 3, and so on. Other languages would follow. We are python, made for
easiness and readability, and we are in the age where you can't even get
something as small as a kilobyte USB. We must make first one, second 2, and
third 3, like it is supposed to be. I give this:
*+1*

リストの最初の要素はゼロ番目の要素です。二つ目の要素は1番目の、三つ目は
2番目のという具合になっています。これはそのプログラミング言語やプログラミング
一般における新米にとって、混乱を招くことがあります。
この体系は single bits が高価であった時代に作られたものです。
もう更新すべきときです。
これは互換性をなくすものであるので、version 4 では考慮してください。
わたしは最初の要素が要素 1、二つ目が element 2、三つ目が element 3 のように
すべきであると主張します。他の言語もこれに従うでしょう。
#このあとの文ちょっとわからん。We must ～は訳さんでもわかるでしょう(^^: 



[Python-ideas] List Revolution

[Python-ideas] List Revolution
Guido van Rossum guido at python.org
Fri Sep 9 23:22:56 CEST 2011

On Fri, Sep 9, 2011 at 2:12 PM, Christopher King <g.nius.ck at gmail.com> wrote:
> The first element in a list is element zero, the second is one, the third it
(略)

Consider it done.

-- 
--Guido van Rossum (python.org/~guido)



[Python-ideas] List Revolution


[Python-ideas] List Revolution
David Blaschke dwblas at gmail.com
Fri Sep 9 23:42:09 CEST 2011

On Fri, Sep 9, 2011 at 2:12 PM, Christopher King <g.nius.ck at gmail.com> wrote:
> The first element in a list is element zero, the second is one, the third it
> two, and so on.

Those are not element numbers, but offsets.  What is confusing is
calling them element numbers.  Back in the days of dinosaurs, you
would write the access to containers yourself, so you if you wanted to
access the first element, the memory offset is zero from the
beginning.  If you want the second element the memory offset is 1 X
length of element from the beginning, etc.  This has carried forward
as languages have moved forward.  A dictionary would be the choice for
indexing by 1, 2, 3, etc.

-- 
Unless your heart is open and serene, with nothing touching your
feelings, how can you respond completely without error,,,,,Yuanwu


[Python-ideas] List Revolution

[Python-ideas] List Revolution
Guido van Rossum guido at python.org
Sat Sep 10 04:08:13 CEST 2011


On Fri, Sep 9, 2011 at 6:32 PM, Matt Joiner <anacrolix at gmail.com> wrote:
> Recommended reading:
> http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html

Nice one! Reminds me of these two lines from the zen of Python:

    There should be one-- and preferably only one --obvious way to do it.
    Although that way may not be obvious at first unless you're Dutch.

-- 
--Guido van Rossum (python.org/~guido)


[Python-ideas] List Revolution

[Python-ideas] List Revolution
Carl Matthew Johnson cmjohnson.mailinglist at gmail.com
Sat Sep 10 06:10:41 CEST 2011

On Sep 9, 2011, at 3:32 PM, Matt Joiner wrote:

> Recommended reading:
> http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html

The reasoning in this letter is so terrible. Why do people quote this whenever this 
comes up? "We should start lists at 0 because when writing for-loops the <= 
look goofy otherwise." Why on earth should Pythonistas care what the for-loops 
are like when we only have for-each loops! It's crazy.

Look, EWD was a good computer scientist (=MATHEMATICIAN), but he was terrible when it 
comes to the ART of programming language design. There's no reason to think that being 
a good mathematician would make one also good at designing a user interface, and 
that's what a programming language is--a user interface for highly advanced users. 
Other than "Go To Considered Harmful" everything I've read of his about 
programming has been wrong. (Correctness proofs, really?) And much of that wrongness 
stems from EWD's false belief that programming should be the same as math.

Now, as it happens, I don't think we should change to using 1 (although I do note that 
Lua gets along fine with it). But the reason not to change is because 0 is a well 
entrenched standard so most programmers are more used to it than to 1. In other words, 
it's the standard because in UI design you stick with what your users will expect. It 
has nothing to do with some arcane mathematician's gobbledygook writings about greater 
than and less than signs. Programming language design is the art of making something 
that helps humans work more efficiently, not some pure mathematics descended from 
Platonic heaven.

Sorry to rant, but that article always comes up and so I have grudge against EWD.


[Python-ideas] List Revolution


[Python-ideas] List Revolution
Guido van Rossum guido at python.org
Sun Sep 11 03:40:30 CEST 2011

On Sat, Sep 10, 2011 at 6:26 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
(略)

EWD points out the power of half-open intervals, which I independently
discovered when I considered the issue of indexing and slicing in
Python. If you consider that arcane mathematics I'm not sure I really
want to use any code you wrote...

-- 
--Guido van Rossum (python.org/~guido)


[Python-ideas] List Revolution


[Python-ideas] List Revolution
Christopher King g.nius.ck at gmail.com
Sun Sep 11 00:11:48 CEST 2011

I think there is some confusion about my idea (I didn't intend it as a joke,
but I was unsure, I was really surprised when Guido endorsed. I think people
have been thinking that my idea was as follows:
>>> items=['a', 'b', 'c']
>>> items.first
'a'
>>> items.second
'b'
>>> items.third
'c'
It is *not* that. I would not want it to be in words. That would be dumb
what my idea was was this:
>>> items=['a', 'b', 'c']
>>> items[1]
'a'
>>> items[2]
'b'
>>> items[3]
'c'
I'm not sure if this one is good, but if not, I'm sure you we come up with
another line of jokes (I like jokes, so its alright.)


[Python-ideas] List Revolution


[Python-ideas] List Revolution
Guido van Rossum guido at python.org
Sun Sep 11 00:34:45 CEST 2011

On Sat, Sep 10, 2011 at 3:11 PM, Christopher King <g.nius.ck at gmail.com> wrote:
> I think there is some confusion about my idea (I didn't intend it as a joke,
(略)

I understood that. -- I think others did too but found the proposal so
preposterous that they started posting nonsensical "solutions" based
on an intentionally literalistic misreading of your original post. (If
you think this is odd, realize that Python was named after Monty
Python's Flying Circus -- we occasionally like to show off our warped
sense of humor. :-)

Anyway, the reason your proposal is not going to fly, quite apart of
whether it would be a good idea for a brand new language design(*), is
that there is over 20 years of existing Python code that would have to
be changed, not to mention the brains of millions of users, and
hundreds of books about Python. Plus pretty much every other language
in widespread use today (C, C++, Java, C#, JavaScript, Ruby, to name a
few; presumably also Objective C given its C inheritance) agrees that
indexes start at zero. It is a cultural battle that  has been fought
and won long ago (all the old languages used 1-based indexing:
Fortran, Algol, Pascal) and it's really not that important in the
grand scheme of things, so the status quo wins.

(*) I personally think 0-based indexing is better, and the referenced
EWD expresses why better than I could. But I'm sure that if we lived
in a world where 1-based indexing was the norm I'd get by just fine.

-- 
--Guido van Rossum (python.org/~guido)

ダイクストラ先生の E.W. Dijkstra Archive: Why numbering should start at zero (EWD 831) は日本語訳もあったような気が。 近代科学社から出てるどれかだったかなあ。

■_

一つ前へ 2011年9月(上旬)
一つ後へ 2011年9月(下旬)

ホームへ

リンクはご自由にどうぞ

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