ときどきの雑記帖 迷走編

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

一つ前へ 2011年4月(下旬)
一つ後へ 2011年5月(中旬)

ホームへ

2011年05月10日

■_

カードの引き落としがきつかった。

■_

■_ 

Starting with Haskell.. for Begginers. : haskell

Hello.. with my day to day increasing passion for programming, i have finally decided 
to start with some language. i have already learnt programming in C of basic level. 
After some amount of research on net and talking to people... i have finally decided 
to start with Haskell first and then move to Python.

こんにちは。わたしは日を追うごとにプログラマーになろうという情熱が増してきて、
結局行くつかの言語を始めることにしました。すでに基本的なレベルのCプログラミングを
学んでいます。
ネットで調べたりほかの人と話してみて、Haskellを最初にやって、それからPythonに
移ろうと決めました。

So, is Haskell good for begginers.. or is it better to continue my learning C and C++.

そこで質問なのですが、Haskellは初心者に向いているものでしょうか?
あるいは、C や C++ の学習を続けた方が良いのでしょうか?

■_ 

The myth 
of the Lisp genius ― The Endeavour
The myth of the Lisp genius

by John on April 26, 2011

I'm fascinated by the myth of the Lisp genius, the eccentric programmer who 
accomplishes super-human feats writing Lisp. I'm not saying that such geniuses don't 
exist; they do. Here I'm using “myth” in the sense of a story with archetypical 
characters that fuels the imagination.  I'm thinking myth in the sense of Joseph 
Campbell, not Mythbusters.

Richard Stallman is a good example of the Lisp genius. He's a very strange man, 
amazingly talented, and a sort of tragic hero. Plus he has the hair and beard to fit 
the wizard archetype.

Richard Stallman は Lisp genius の good example です。彼は

Let's assume that Lisp geniuses are rare enough to inspire awe but not so rare that we 
can't talk about them collectively. Maybe in the one-in-a-million range. What lessons 
can we draw from Lisp geniuses?

Lisp genius が rare enough to inspire awe であってもその人たちと collectively に会話も
できないほど rare ではないとしましょう。たぶん、百万人に一人くらいの割合ではないでしょ
うか。


One conclusion would be that if you write Lisp, you too will have super-human 
programming ability. Or maybe if Lisp won't take you from mediocrity to genius level, 
it will still make you much more productive.

結論の一つは、あなたもまた super-human programming ability を手に入れるだろうというも
のです。


Another possibility is that super-programmers are attracted to Lisp. That's the 
position taken in The Bipolar Lisp Programmer. In that case, lesser programmers 
turning to Lisp in hopes of becoming super productive may be engaging in a bit of 
cargo cult thinking.

もう一つの可能性は、super-programmer たちは Lisp に attract されるというものです。
これは Bipolar Lisp Programmer を受け入れる position です。この場合、
卓越した生産性を持つプログラマーになるという希望を持って Lispに 飛び込んだ
劣ったプログラマーたちはおそらくカーゴカルト思考に囚われてしまうでしょう。
#わかんね


I find the latter more plausible, that exceptional programmers are often attracted to 
Lisp. It may be that Lisp helps very talented programmers accomplish more. Lisp 
imposes almost no structure, and that could be attractive to highly creative people. 
More typical programmers might benefit from languages that provide more structure.

Lisp は structure をほとんど impose しませんが、それはhighly creative people をひきつ
けるのかもしれません。より typical なプログラマーたちはもっと多くの structure を提供し
ている言語から恩恵を受けるかもしれません。

I'm skeptical when I hear someone say that he was able to program circles around his 
colleagues and it's all because he writes Lisp. Assuming such a person accurately 
assesses his productivity relative to his peers, it's hard to attribute such a vast 
difference to Lisp (or any other programming language).

Programming languages do make a difference in productivity for particular tasks. There 
are reasons why different tasks are commonly done in different kinds of languages. But 
I believe talent makes even more of a difference, especially in the extremes. If one 
person does a job in half the time of another, maybe it can be attributed to their 
choice of programming languages. If one does it in 1% of the time of another, it's 
probably a matter of talent.

プログラミング言語は、特定のtaskに対する productivity において差ができます。異なる 
task は一般には異なる種類の言語で行われるのにはいくつか理由があります。しかしわたしは
才能がより大きな差を作るものだと信じていますし、especially in the extremes.ある人が他
の誰かの半分の時間である仕事を成し遂げたなら、それは選択したプログラミング言語によるも
のかもしれません。もし誰かが他の人の1%の時間でそれを成し遂げたなら、その差はたぶん才能
によるものでしょう。

There are genius programmers who write Lisp, and Lisp may suit them well. But these 
same folks would also be able to accomplish amazing things in other languages. I think 
of Donald Knuth writing TeX in Pascal, and a very conservative 
least-common-denominator subset of Pascal at that. He may have been able to develop 
TeX faster using a more powerful language, but perhaps not much faster.

Lisp で書く genius programmer たちがいて、Lisp は彼らを良く suit しているかもしれませ
ん。けれどもその人たちは他の言語であっても驚くようなことをやってのけられた(accomplish 
amazing things) でしょう。Donald Knuth は TeX をPascal で、しかもその very conservative
で最小公倍数的なサブセットで書いたとわたしは記憶しています。もっと強力な言語を使っていた
ら彼はさらに早く TeX を開発できたでしょうが、おそらくそれほど大きな差は生じなかったで
しょう。

Related posts:

Lisp and the anti-Lisp 
http://www.johndcook.com/blog/2010/11/23/lisp-and-the-anti-lisp/

Doing good work with bad tools 
http://www.johndcook.com/blog/2009/12/16/good-work-with-bad-tools/

Why programmers are not paid in proportion to their productivity 
http://www.johndcook.com/blog/2009/12/23/why-programmers-are-not-paid-in-proportion-to
-their-productivity/

■_

あとでよむ 

Not 
Invented Here and New Programmers - Macha

The general consensus is that the one of the best ways to learn how to program better, 
beyond learning the basic syntax is to just go ahead and write some programs on your 
own. Another consensus is that the best type of program to write is one that scratches 
your own itch. Yet another consensus is that it is best to avoid the "Not 
Invented Here" syndrome of writing everything from scratch and instead reuse as 
much code as possible.

2011年05月09日

■_

自転車に轢かれそうになった(携帯電話操作しながら運転してやがった)。

■_ その後

なんか locale の一件が glibc のところまで行ったような。 

Re: Case insensitivity seems to ignore lower bound of interval
Re: Case insensitivity seems to ignore lower bound of interval
From: 	Eric Bischoff
Subject: Re: Case insensitivity seems to ignore lower bound of interval
Date: 	Wed, 4 May 2011 09:43:45 +0200

Le vendredi 29 avril 2011 09:55:23, Aharon Robbins a écrit :
> Davide Brini states:
> > You seem to think this is gawk-specific, but in fact any locale-aware
> > tool that uses regular expressions behaves the same (try eg with sed or
> > grep).
> 
> And this too is correct.

It isn't. See the result of tests that followed: sed, awk and grep just don't 
behave the same, at least in the versions shipped with distributions.

> POSIX locales (in my not-so-humble opinion) are
> a total and utter botch.

On that we all agree ;-).

> [[:lower:]], [[:upper:]] and so on exist to mitigate this issue. They are
> not perfect solutions.

Yes.

> > Collation [...]
> 
> Collation has to do with sorting order, and less so with regular expression
> matching.  Gawk doesn't support [[=e=]] which is supposed to match all
> versions of the letter 'e'.

OK, did not know.
 
> I agree, which is why I've clarified the doc and changed the code, but
> again, this is not a gawk-specific issue but a general locale issue.

Have the library writers been contacted? Since the problems seem to rely 
there, wouldn't that the logical thing to do?
 
> > One technical possibility would be to simply use Unicode code positions.
> 
> Unfortunately, no.  Gawk is used in many parts of the world where Unicode
> is not the standard character set (Japan, China, etc.)

I was suggesting to convert internally to Unicode from other character sets 
before doing anything else. I'm not sure this is a good idea though in the 
case of awk. But it's a common technique to work internally in unicode.

Also, Unicode is becoming standard everywhere in the world, replacing all 
older encodings. That includes China and Japan.

> and restricting gawk to just Unicode would not be a good idea. 

That was not what I suggested. Sorry if I wasn't clear.

> If you still disagree, then I'm sorry, there's nothing else I can do
> to help.

I'm sorry I did not understand in the first place you initial message, saying 
it was already solved. Please accept my apologies for that.


Re: Case insensitivity seems to ignore lower bound of interval
Re: Case insensitivity seems to ignore lower bound of interval
From: Aharon Robbins
Subject: Re: Case insensitivity seems to ignore lower bound of interval
Date: 	Wed, 04 May 2011 22:49:41 +0300

Hi.

> > I agree, which is why I've clarified the doc and changed the code, but
> > again, this is not a gawk-specific issue but a general locale issue.
>
> Have the library writers been contacted? Since the problems seem to rely 
> there, wouldn't that [be] the logical thing to do?

Yes it would be.  I am 110% certain that the answer will be that the lib
implements POSIX.  You can try to open a bug on glibc though.

> > > One technical possibility would be to simply use Unicode code positions.
> > 
> > Unfortunately, no.  Gawk is used in many parts of the world where Unicode
> > is not the standard character set (Japan, China, etc.)
>
> I was suggesting to convert internally to Unicode from other character sets 
> before doing anything else. I'm not sure this is a good idea though in the 
> case of awk. But it's a common technique to work internally in unicode.

Truth to tell, it's a lot of work to do things this way, since you have
to convert on input and again on output, and do everything in wide characters.

Worse - the two regexp engines that gawk uses don't provide interfaces
for working with wide characters!  That is the biggest problem.

Essentially, while it's a good idea in theory, for gawk it wouldn't work.

> Also, Unicode is becoming standard everywhere in the world, replacing all 
> older encodings. That includes China and Japan.

But it hasn't happened yet.  That's why I said that in maybe 10 years
I could work just with Unicode.

> I'm sorry I did not understand in the first place you initial message, saying 
> it was already solved. Please accept my apologies for that.

No problem at all.  Reasonable conversations with understanding users
are quite pleasant, actually.

Thanks,

Arnold


Re: Case insensitivity seems to ignore lower bound of interval
Re: Case insensitivity seems to ignore lower bound of interval
From: 	Eric Blake
Subject: Re: Case insensitivity seems to ignore lower bound of interval
Date: 	Wed, 04 May 2011 13:59:59 -0600

On 05/04/2011 01:49 PM, Aharon Robbins wrote:
> Hi.
> 
>>> I agree, which is why I've clarified the doc and changed the code, but
>>> again, this is not a gawk-specific issue but a general locale issue.
>>
>> Have the library writers been contacted? Since the problems seem to rely 
>> there, wouldn't that [be] the logical thing to do?
> 
> Yes it would be.  I am 110% certain that the answer will be that the lib
> implements POSIX.  You can try to open a bug on glibc though.

No need.  It's already been attempted in the past.
http://sourceware.org/bugzilla/show_bug.cgi?id=12045
http://sourceware.org/bugzilla/show_bug.cgi?id=12051


Re: Case insensitivity seems to ignore lower bound of interval

Re: Case insensitivity seems to ignore lower bound of interval
From: 	Eric Blake
Subject: Re: Case insensitivity seems to ignore lower bound of interval
Date: 	Thu, 05 May 2011 11:11:27 -0600

On 05/05/2011 10:59 AM, Aharon Robbins wrote:
>> No need.  It's already been attempted in the past.
>> http://sourceware.org/bugzilla/show_bug.cgi?id=12045
>> http://sourceware.org/bugzilla/show_bug.cgi?id=12051
> 
> The first one looks like the main one. Has Ulrich responded to it?

12045 is a documentation request (to at least mention why CEO [collation
element ordering] appears screwy for different locales, and how to
properly write a locale file so that CEO does what you normally expect),
which, to my knowledge, Uli hasn't responded to.

12051 is a request to change away from CEO to any other scheme, and Uli
flat out rejected that, even though POSIX no longer requires CEO.  In
other words, Uli says that the burden is on the locale file writer, and
not on glibc.

But without good documentation on how to write a proper locale file, and
without prods to all of the owners of broken locale files, it's an
uphill battle to get CEO ordering to consistently be useful.  And that
only covers you if you are on a system with glibc which uses CEO
semantics, rather than on any other system where the libc semantics of
range expressions has who-knows-what behavior.

Yes, it would really be nice if all four of bash, gawk, sed, and grep
could agree on the same interpretation of non-C range semantics, and
implement that regardless of the underlying libc behavior.  But what
semantics should we settle on?

It's an age-old problem, with no nice solutions.

Uli says that the burden is on the locale file writer, and not on glibc. ま、うるりっひならこう答えるだろうなあ(^^;

■_

なんかここにきて Groovyの名前をまた見るようになった気が。 ちょっと量があったので頭のところだけ。 

(think) - Java.next() - The Groovy Programming Language

Java.next() - The Groovy Programming Language

In a series of articles labeled “Java.next()” I'll be discussing modern alternatives 
to the Java programming language for use with the Java Platform. This is the first 
installment of the series - “The Groovy Programming Language”.

“Java.next()” と題のついた一連のシリーズで、わたしは Java Platform で使用する
modern な Java の代替プログラミング言語について論じます。今回はシリーズの最初の回で、
Groovyを取り上げます。

Overture (序論)

We all know and love the Java platform(note the emphasis on platform) for a couple of 
obvious reasons. Most notably it features a huge high quality standard library and a 
legendary execution environment - the Java Virtual Machine(JVM). The JVM is known to 
posses the following qualities:

わたしたちはJavaを知っていて、いくつかの明確な理由によってJava プラットフォームを
好んでいます。最も notably なJavaプラットフォームの機能は、巨大で高品質の標準ライブラリと
legendary execution environment 、つまりは Java Virtual Machine (JVM) です。
この JVM は以下の qualities を持っています:

    * Runs on all major platforms
      主要なプラットフォームのすべてで走る

    * Enterprise ready
      Enterprise 向けに使える

    * Extremely stable
      とても安定している

    * Extremely fast
      とても高速である

    * Highly customizable - many aspects of its work can easily be adjusted such as GC 
      settings, heap settings, etc.
      カスタマイズの自由度が高い

There is a terrific community around the Java platform that has contributed an immense 
amount of high quality software vital to the success of Java. Hibernate, Spring, 
Eclipse, NetBeans, the myriad of Apache projects are all community efforts.

So far so good, but it's not all rainbows and unicorns in the land of Java. The Java 
programming language is a common source of gripe amongst many developers for various 
reasons. I'll list here some of the more notable of them:

    * It's not a pure OOP language(there is a difference between primitive and 
      reference data types)

      Javaは純粋なオブジェクト指向プログラミング言語ではない
      (プリミティブデータ型と参照データ型の違いが存在している)

    * It uses static typing(highly subjective topic, but commonly brought up)
      静的型付けを採用している

    * It doesn't have support for closures(which instantly kills half of functional's 
      programming ideas such as higher order functions)
      クロージャをサポートしていない(これは高階関数のような関数的プログラミングの
      考え方の半分を即座に殺してしまうようなものです)

    * It has limited meta programming capabilities(compared to Ruby and Lisp for instance)
      (RubyやLispと比較した場合に) 限定されたメタプログラミング機能しか持っていない

    * There is no concept of top-level procedures(outside of class definitions)(this 
      makes Java unsuitable for creating “script” programs)

      top-level の手続きというコンセプトがない。

    * Its syntax is too verbose

    * It's not suitable for the creation of DSLs
      DSL を作るのには向いていない

    * Its development is sluggish and restrained by the corporate promise of backward compatibility

    * It's an imperative language
      Java は命令型言語である

    * Its parallel programming model is revolving mostly around locks and threads
      Java の並行プログラミングモデルはほとんどロックとスレッドを使って解決するものである

あ。Groovyの紹介のところに届いてない。

次の回では Scala を取り上げるらしい。

■_

■_

資料作ってる時間がががが。

2011年05月08日

■_

Land of Lisp どーすっかねえ。

Corders at Work の原書と日本語版の表紙の差にびっくり。 誰の仕業w

Coders at Work プログラミングの技をめぐる探求 Coders at Work: Reflections on the Craft of Programming

同じタイトルのがあるなと思ったら、ドイツ語版か! Amazon.co.jp： Coders at Work: Peter Seibel: 洋書

■_ ビットシフト

このスレでは定期的に(釣りで)ビットシフトネタが投下されてるのですが 今回のやり取りはなんとなく面白かったので。 

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

609 デフォルトの名無しさん [] 2011/05/08(日) 01:49:18.23 ID: Be:
    C言語をはじめたばかりであまりわからないのですが、
    ビットシフトはなんの役に立つのでしょうか？ 

610 デフォルトの名無しさん [sage] 2011/05/08(日) 02:15:28.43 ID: Be:
    世界の為に 

611 デフォルトの名無しさん [sage] 2011/05/08(日) 02:24:16.38 ID: Be:
    >>609
    ・普通にビット処理に使う
    ・ビットを使ったフラグ処理で、フラグをクリアするのに使う
    ・2 で割るより shift を 1 回した方が速い事を利用した高速化に使う

    等々、最初の内は気にしなくてオケ
    必要になったら思い出せる程度で理解しておけばオケ
    それでオケ 

612 デフォルトの名無しさん [sage] 2011/05/08(日) 02:28:14.51 ID: Be:
    >>609
    bit単位の演算が必要になるデータ構造がある
    bit n～m番目は、こういう情報が入るみたいな
    別のbitにはまた違う情報が入るみたいな

    例えばRGBを16bitで表す場合
    ttp://msdn.microsoft.com/ja-jp/library/cc371597.aspx

    16bitのデータで、赤、緑、青をそれぞれ5bit(もしくは5,6,5bit)で表している。
    この16bitの色情報から、赤要素のみ取り出すとか、
    逆に赤要素のみ変更するとか計算するときにビットシフトを使う
    構造体のビットフィールド使ったほうがいいんじゃね？と思わないこともないが。

    他には1bitに一つのフラグを割り当てるとかやるな 

613 デフォルトの名無しさん [sage] 2011/05/08(日) 05:44:12.27 ID: Be:
    >>610-612
    10年ROMってろカス 

614 デフォルトの名無しさん [sage] 2011/05/08(日) 05:49:45.13 ID: Be:
    >>610は別にいいだろ。
    他はマジレスしちゃったんだなぁと思うが。 

615 デフォルトの名無しさん [sage] 2011/05/08(日) 06:13:12.59 ID: Be:
    荒らしに反応するものも荒らし 

616 デフォルトの名無しさん [sage] 2011/05/08(日) 06:18:56.90 ID: Be:
    そのコピペ2003年くらいからあるのな 

617 デフォルトの名無しさん [sage] 2011/05/08(日) 07:18:37.29 ID: Be:
    むしろマジレスしない>>610と>>613-614が「役立たず」で「不要」なんですが。 

618 デフォルトの名無しさん [sage] 2011/05/08(日) 07:19:43.18 ID: Be:
    新参は死ね 

619 デフォルトの名無しさん [sage] 2011/05/08(日) 08:42:21.80 ID: Be:
    入門スレが新参を拒むとかｗｗｗ 

625 デフォルトの名無しさん [sage] 2011/05/08(日) 11:38:32.68 ID: Be:
    >>619
    え？ここのスレって回答する人も入門者なの？ 

626 デフォルトの名無しさん [sage] 2011/05/08(日) 11:45:08.40 ID: Be:
    え？もちろんそうだけど知らなかったの？ 

627 デフォルトの名無しさん [sage] 2011/05/08(日) 12:17:26.41 ID: Be:
    自分のこと上級者だとでも思ってたのか？ｗ

■_ WinC++

ZDNet の記事なんですが、これ翻訳されるんだろか。

“putting some muscle”って力を入れるとかかな? 

What is WinC++ and how does it figure in Microsoft's bid to make tools a $2 billion business? | ZDNet

What is WinC++ and how does it figure in Microsoft's bid to make tools a $2 billion business?

By Mary Jo Foley | May 4, 2011, 11:23am PDT

Summary

Microsoft is putting some muscle behind its C++ products and strategy with the coming 
WinC++. Here are some bits and pieces I’ve unearthed so far about what’s going on.

略

How is Microsoft planning to do grow beyond its established developer base?

One way seems to be to put some muscle behind the company's native dev tools, like 
Visual C++. I noticed a brief mention in Somasegar's e-mail of “WinC++.” It turns 
out that the new name for Visual C++ is going to be WinC++ — something confirmed by a 
Microsoft job posting which mentions the “Windows C++ a.k.a. Visual C++ team.”

I wondered: Is WinC++ nothing more than a new (and obviously Windows-centric name) for 
an old compiler?

以下略


© 2011 CBS Interactive. All rights reserved. Privacy Policy | Ad Choice | Terms of Use

で、reddit での反応からいくつか。C99のサポートは～という声が。 

Microsoft thinks native C++ has big future : programming

Fine, now how's for some C99 support?



Better get used to C89 :)



MSVC is the only reason my code is C89. I code in C99 and then fixup to something like 
C89 to make MSVC happy.



    Hi: unfortunately the overwhelming feadback we get from the majority of our users is
    that they would prefer that we focus on C++-0x instead of on C-99. We have "cherry-picked"
    certain popular C-99 features (variadic macros, long long) but beyond this we are
    unlikely to do much more in the C-99 space (at least in the short-term).

    Jonathan Caves

    Visual C++ Compiler Team.

If you are really tied to Visual Studio, try sticking the Intel C Compiler in it. 
Honestly, I've stopped caring about keeping my code C89-compliant, especially since 
C1X is due out reasonably soon (GCC 4.6.0 supports a lot of the drafted features).



I see no problem if it wouldn't be backward compatible (business wise), Maybe it is 
even better.

MFC should die, Everybody loves to hate it but remind me what other framework is that 
old! (I still have code from win95 that can run on windows 7). They should put it to 
sleep and create something new from scratch.


There's always been a strong current inside Microsoft's tools group in favor of native 
compiled languages over VM-based languages. Witness the CLR's lack of an interpreted 
mode, for example.

I think the success Apple has had using Objective C as their "native" language
for desktop and mobile, as well as the failure of "managed" languages to extend
their reach into Microsoft's own core applications business has started to push the
tools strategy back to where they wanted it to be in the first place, pre-Java/COOL.

But I'm not sure this strategy will work. For one thing, Apple essentially "owns"
Objective C, both the language specification and the only implementation in widespread use.
When they wanted block support for Grand Central Dispatch, they just added it. Ditto
garbage collection. Microsoft can't innovate like that without hearty complaints from the
rest of the C++ community about "embrace and extend".

For another, Objective C is popular because the iPhone is popular (and a resurgent OS 
X user base doesn't hurt, either). I think it has some nice advantages as a language, 
for sure, but if NeXTStep had been built on Oberon or something, that's probably be 
what we'd be writing iPhone applications in.

Regardless, it's interesting to see the pendulum start to swing back when for so long 
it seemed as if managed/interpreter+JIT languages were the inevitable future. Instead, 
it looks like for many applications (and whole languages!), a sufficiently 
"cleaned up" and optimized foundation of the LLVM sort will keep native 
static compilation viable for a good long while.

MFC should die, Everybody loves to hate it but remind me what other framework is that old! (I still have code from win95 that can run on windows 7). love to hate it ってなんか面白い言い回しだなあ。

Apple の成功の一因は Objective-C を彼らの native language にしたことにある。かな。

if NeXTStep had been built on Oberon or something のOberon ってヴィルト先生のあれだろうか。

■_

■_ 読む

2011年05月07日

■_

月に一度の脳みそを酷使する読書会。 会議室情報(10人前後くらい向け)ありませんかね。 東京 - IT勉強会会場リスト にあるのはもっと大規模向けの会議室ばかりで。 いやまあ、ルノアールなどの貸し会議室でもいいんですが、 プロジェクターが使いづらい(有料で貸し出ししてますが)とかいろいろあるし比較したいなと。 (これまで候補になってたところを)片っ端から試してみるかｗ

■_

■_

あれもこれも面倒くせー

2011年05月06日

■_

歴群。
歴史群像 2011年 06月号 [雑誌]

そいや、歴史街道で松永弾正久秀の特集があったりしたたからこっちも買うか。
歴史街道 2011年 06月号 [雑誌]

■_ 

：【ナポレオン】長谷川哲也32【笑う殺し屋】

356 名無しんぼ＠お腹いっぱい [sage] 2011/05/05(木) 23:39:14.56 ID:N+/S7WJN0 Be:
    アウステルリッツまでには横浜優勝してほしい 

357 名無しんぼ＠お腹いっぱい [sage] 2011/05/05(木) 23:44:54.02 ID:gmHI6CM+0 Be:
    無茶言うなｗ

    ゴルゴの最終回読むぐらいの意気込みで待てばいいよ 

358 名無しんぼ＠お腹いっぱい [sage] 2011/05/06(金) 00:30:13.19 ID:dVLUC+Ll0 Be:
    ゴルゴとこち亀とベルセルクの最終回は俺が死ぬまでに見れないだろうな 

359 名無しんぼ＠お腹いっぱい [sage] 2011/05/06(金) 00:50:17.19 ID:KwL++bJM0 Be:
    ゴルゴとこち亀は作者が大抵の読者より歳上だから、いずれ死をもって終わるんだろう 

360 名無しんぼ＠お腹いっぱい [sage] 2011/05/06(金) 02:50:25.72 ID:KiOMvyvL0 Be:
    ゴルゴは作者死んでもクレしんみたいに続くだろｗ 

361 名無しんぼ＠お腹いっぱい [sage] 2011/05/06(金) 10:46:20.71 ID:e5mK3rcj0 Be:
    ガイバーは・・・ 

362 名無しんぼ＠お腹いっぱい [sage] 2011/05/06(金) 12:22:55.21 ID:gGLnH5Qg0 Be:
    ガイバーの場合は、掲載誌が遠からず廃刊・休刊になるから
    まずそっちの心配が先 

363 名無しんぼ＠お腹いっぱい [sage] 2011/05/06(金) 14:09:24.11 ID:Vqo51vnj0 Be:
    お隣の超人ロック忘れちゃあかん

もう二度と見られないかもなあ ○|￣|＿

■_

せめて回答のほうも文字に起こされてればねえ。 質問文そのものが口語的? でよく意味の取れないものが。 

Conversation with Herb Sutter: Perspectives on Modern C++(0x/11) | Going Deep | Channel 9

I was lucky enough to catch up with Herb Sutter not too long after the FDIS 
announcement (Final Draft International Standard is complete).

As usual when talking to Herb, the conversation is all about C++ (well, we do talk 
about C# for a little while, but in the context of C++. Why?).

略

It's always great to talk to Herb and get a glimpse of what goes on in the C++ 
Standards Committee (which Herb chairs). In this specific conversation, it's uplifting 
to see how excited Herb is for the future of one of the world's most capable and 
widely used general purpose programming languages. C++ is a modern programming 
language for power and performance, but it's also a highly abstracted general purpose 
language for building user mode applications, mobile apps, etc. The amazing part is 
how C++ can provide rich general programming abstractions and also ensure that your 
code can run at machine speeds. We talk about this, of course.

Tune in. Learn. Go native!

1:37 -> What were the goals of the C++0x standard, at a high level?
           C++0x 標準の目標はなんだったのでしょうか?

2:40 -> Language and Library abstractions and performance (how high can you go and still be fast as possible?)...

5:23 -> C++ as an application development language (in addition to the traditional C++ is a systems programming language meme)...
           アプリケーション開発言語としてのC++について
           (伝統的なC++はシステム開発言語であるというmemeに加えて)

07:17 -> C++0x or can we now call it C++11?
            C++0x それとも C++11 と呼んでよいの?

09:21 -> Standards committees and real world user representation...

10:39 -> Who comes up with the new features that get standardized (or not...)?

13:01 -> What were the goals of the C++0x standard (non-canned answer)?
            C++0x 標準の目標とは何だったのでしょうか?

14:21 -> What does Bjarne mean by C++0x being a better C++ for novice programmers?
            Bjarne の C++0x は novice programmer たちにとってのよりよい C++ だという発言の意図は?

15:51 -> Why can't C++ look more like C#?
            C++ はなんでもっと C# のようにできないのでしょう?

18:50 -> At the end of the day, everything(in terms of programmer-controlled computing) boils down to memory, right?

23:12 -> What are some of the most significant new features in C++0x?
            C++0x においてもっとも重要な機能にはどういったものがありますか?

25:05 -> What can VC++ developers expect to see in terms of C++0x implementation in Visual C++ next?
            VC++ developer が次の Visutal C++ の実装で期待できるものは?

27:09 -> C++ and type safety...
            C++ と型安全性について

29:05 -> C++0x and backwards compatibility: any big breaking changes?
            C++0x と後方互換性について。なにか後方互換性を壊す大きな変更がありますか?

34:16 -> C++0x in the Standard Library...

37:01 -> Any thinking in the Committee about doing much more frequent experimental releases of C++?
            委員会にはもっと頻繁に C++ の experimental リリースを行うという考えはありますか?

39:04 -> Are their features that didn't make it into the standard that you really wanted to be standardized?
            あなたが標準化して欲しいと思っているけれども標準に入れられなかった機能はありますか?

41:45 -> Are you comfortable with C++'s current state? Is it modern enough?
            C++の現状に満足していますか? 十分 mondern といえますか?

43:22 -> Conclusion (or Charles doesn't end the conversation when his farewell begins - where does it go from there? Smiley )
            結論

■_

■_ これは

ちょっとひどくないか?

Twitter / @Yusuke Ando: 和訳した。 PHPプロジェクトの80-90％は巨大な ... → Twitter / @Yusuke Ando: ゲットーって言われてもピンと来ないのでタイトルは釣り ... → Twitter / @Yusuke Ando: @_kennyk_ BTW I translated ...

誤用のほうの確信犯であのタイトルにしたわけね。

2011年05月05日

■_

なんで 9種類もありがやるですか＞オライリーのクリアファイル O'Reilly Japan for Bookstores

■_ Perl 5.x

5.8、5.10、5.12 だと三系列になるものなあ。5.8 のサポートも切れようというものか。 

Why use perl > 5.8? : perl

I wonder if anyone has any compelling reason to use versions of Perl newer than 5.8. I 
currently have 5.12 installed but I still write code as though I were using 5.8; my 
CentOS web server has 5.8 and so I can use the package manager to install precompiled 
Perl modules without having to build them myself, and, reading through perl5100delta 
and 5120delta, I can't find any compelling reason to change my ways.

5.8 よりも新しいバージョンの Perl を使うように薦める理由を、誰か説明してもらえませんか?
わたしは現在 5.12 をインストールしているのですが、5.8でも動くようにコードを書いています。
自分の使っている CentOS web サーバーには 5.8 があって、自分ではビルドをせずにパッケージ
マネージャを使ってコンパイル済みのモジュールをインストールしています。また、
perl5100delta や 5120delta を読んでも、このやり方を変えなければならない理由が
思い浮かばないのです。

Perl 5.10 added say, which saves you an entire two keystrokes over print "...\n";
(EDIT: counting the \n keys, not the difference in length between print and say). they
added given/when, but the old for($foo) trick does the same job and is backwards
compatible; the defined-or operator just saves you a little bit of typing; these aren't
compelling reasons for me to upgrade my coding style to 5.10 at the expense of time spent
making sure everybody has 5.10 to be able to run my code. There's the new state
variables which look useful, but there have been ways to work around the lack of this
variable for years.

Perl 5.10 では  print "...\n"; とするよりも打鍵を二つ節約する say が追加されました
(追記: \n だけを数えていて、キーワードそのものの長さは無視しています)。
このバージョンでは given/when も追加されていますが、古い for($foo) のtrick でも同じことを
行えて、かつこちらは後方互換があります。defined-or 演算子はほんのちょっとだけタイプを
節約するだけですし、わたしの書いたコードを実行できるようにするために
皆に5.10をインストールさせ、コーディングスタイルを5.10にあげるための確たる理由がありません。
新規の state 変数は便利なように見えますが、
この変数がなくてもそれをなんとかするための回避策はあったのです。

Perl 5.12 added package NAME VERSION which saves me having to type a couple more 
characters (our $VERSION) at the expense of making sure my module won't compile on ANY 
version of Perl older than 5.12. The yadda-yadda operator doesn't seem very useful 
either, when you can just as easily write sub to_do {} that doesn't do anything, or 
just type confess in it if you're worried about empty functions being called that you 
forgot about.


It just seems to me that a lot of the new features are "nice-to-have" but 
not "must-have"; users today may be running any version of Perl from 5.8 to 
5.12 and so far code written for 5.8 runs everywhere. So, why 'use feature'?

これら新機能の多くは、"nice-to-have" ではあっても "must-have";
ではないように思われるのです。今日のユーザーは 5.8 から 5.12 のいずれかのバージョンを
使っているでしょうから、




Perl 5.8.9 reached the end of its life years ago. Perl 5.10 will reach the end of its 
life very soon. This means no new minor versions, no bug fixes, and no support. This 
also means that CPAN distributions have free rein to use features from modern versions 
of Perl 5, such that they won't run on older versions of Perl 5.

Perl 5.8.9 はその end of life に到達しました。
Perl 5.10 もすぐに end of lief に到達するでしょう。
これは、新しいマイナーバージョンがリリースされることもないし
バグフィックスもなく、サポートもされないことを意味しています。
これはまた CPAN distribution が Perl 5の modern version にあって、
古いバージョンでは実行できないような機能を自由に使えるようになることでもあります。

It's nice, I suppose, that Red Hat (and by extension CentOS) like Perl 5.8 so much 
that they're willing to "support" it for the next several years, but don't 
confuse their support with anything other than making sure that it compiles even when 
Perl 5.22 is the current version.


(Also for does not do smart matching, for example.)



In this talk, Jacinta gives a number of very good reasons to be using 5.10.1 or newer.

http://ontwik.com/perl/perl-programming-best-practices/

Those features aren't just sugar, but invaluable tools to make your code more bug-free, 
robust, scalable, and maintainable.

ここで挙げられている機能は単なる砂糖(構文糖の?)ではなく、あなたのコードをより bug-free で
頑健で、スケーラブルで、メンテナンスしやすいものにする非常に貴重なツールです。



The reason to not stick with 5.8 is that you are part of a community, you're not alone 
on an island. Before too long, CPAN authors will stop testing their modules against 
5.8 (if they haven't already) which means you'll get all sorts of weird bugs and 
inconsistencies and their response will be 'tough shit.' Eventually they will flat out 
fail to work with 5.8 altogether, so you're going to have to deal with this one way or 
another. Perhaps if you're entirely reliant on your distro's packages for modules you 
will just continue using ancient versions of modules to go with your ancient version 
of perl and be oblivious.

Frankly I am totally baffled why anyone would consider "having to build them myself"
to be an issue. Maybe you haven't learned about o conf prerequisites_policy follow or
cpanminus, but in my world installing a module is the most hassle free part of my day
-- to install Foo::Bar I just run cpanm Foo::Bar and all the rest is taken care of
automatically without me having to do anything. If I were shackled to the CPAN packages
that my distro had available I would tear my hair out, as there are at least a dozen
that I use that are not packaged. CPAN is the best thing about perl and artificially
limiting yourself to only those few popular ones that have packages seems like pure 180
proof insanity.

By the way, I happen to like 5.10's state keyword and \K regex escape. Yes, you can 
replicate the effect of both with more verbiage, but readability is important.



Is cpanm different than cpan? Perhaps I should start a different post, but cpan almost 
never works for me.

One example in particular when cpan had no reason to fail me was when I wanted to cpan 
Tk. It would keep failing with Won't install without force. I had all the prereqs 
installed already (libX11-devel, gcc, make), and when I downloaded the tarball and ran 
perl Makefile.PL; make; make test; make install it all went by without a hitch. Not 
sure what CPAN's problem was.

The only modules the cpan command could ever install for me are super simple, pure 
perl modules that have no dependencies besides built-in pragmas (strict and warnings). 
I like when I can yum install things for this reason. Last time I tried to install 
SDL-Perl "by hand", half the time was spent trying to Makefile.PL various 
modules and going back to CPAN to download the next dependency on the list and so-on.



cpanm is cpanminus which is a play on CPANPLUS. But regardless of which of the CPAN 
interfaces used, module dependencies should be taken care of. CPAN.pm by default asks 
you if you want to do this for each module, which you can disable by setting 
prerequisites_policy to follow, but otherwise it's just a matter of hitting enter each 
time.

If module installation is failing it sounds like something is wonky on your system. 
Maybe if you post the entire output when it fails someone will be able to tell you 
what's wrong. "Won't install without force" just means that make test exited 
with non-zero status, and the default policy is not to continue unless tests pass. So 
the real issue is whatever happened before that message.

I just tried both of your examples (cpanm Tk and cpanm SDL) and both worked fine, 
installing a bunch of stuff without any further action on my part.




Personally I'd upgrade purely for 'say'. That and // so that jerks (hopefully not me) 
stop misusing ||=.

Oh, and getting the name of that damn undefined variable in an interpolated string in 
an the error message is nice too.



The new stuff I use most: smart matches and given when, named captures, say.



I use smart matching and named regex variables.

スマートマッチングと named regex 変数



Umm, because 5.10 FINALLY has a CASE statement, even though its called "given".

スマートマッチング人気高いのね。

■_ 

F# for game development: The myths about the risks of introducing F# in your development team

Tuesday, May 3, 2011

The myths about the risks of introducing F# in your development team
あなたの開発チームに F# を持ち込むリスクについての神話 (myths)

At work we are a couple people who have been using F#. All people who have used it are 
enthusiastic, yet I was surprised today when I heard a project leader had asked to 
limit the use of F#.

There is a question on programmers' stack exchange which touches the subject titled 
"Real world pitfalls of introducing F# into a large codebase and engineering team".
I'm quoting:

    1) Everyone has to learn F#, and it's not as trivial as switching from, say, Java to C#.
       Team members that have not learned F# will be unable to work on F# parts of the codebase.

       全員が F# を学ぶ必要があり、それは Java から C# への移行のように trivial なものではない。
       チームで F#を学んでいないメンバーはコードベースの F# で書かれた部分の作業をすることが
       できなくなってしまう。

    2) The pool of hireable F# programmers, as of now (Dec 2010) is non-existent. Search
       various software engineer resume databases for "F#", way less than 1% 
       of resumes contain the keyword.

       F# プログラマーの人材プールが現時点(2010年12月)では存在しない。
       さまざまなソフトウェアエンジニアの resume データベースで "F#" を検索しても
       該当するキーワードが含まれる resume は1%もない。

The fear is that maintaining F# code might be difficult because current employees and 
job applicants lack functional programming skills.

F# で書かれたコードのメンテナンスが難しいかもしれないという懸念 (fear) は
現状の employee たちや aplicant たちに関数プログラミングのスキルが欠けているからです。

It seems some decision makers are still stuck at the time when C# 1.0, C++ and Java 2 
were the languages of choice. Since then, a few things have happened.

これは、一部の decision maker たちが C# 1.0 の時代に languages of choice として
C++ や Java 2 にこだわったことに似ています。
そしてそれから、あまりたくさんのことは起きていません。

Firstly, Python has become hugely popular. Although many were horrified by its use of 
white space to delimit blocks, it would be difficult to take seriously a programmer 
who claims he can't adjust to Python's syntax. Some love it, some hate it, but all can 
write Python code.

まず、Python が hugely popular になりました。
多くの人がブロックを空白で区切るやり方にショックを受けてはいるものの、
Pythonの構文に adjust できないと不満を訴えるプログラマーの言い分を
深刻に受け取るのは難しいでしょう。
それを愛する人たちも嫌う人たちもいますが、誰もがPython でコードを書けます。
#あー、だめだめだ

Why would the syntax of F# be any harder to adopt?

Secondly, C# has introduced a number of functional programming and other high-level 
concepts in each new version that has come out. Modern C# programmers are expected to 
master LINQ to objects, lambdas and yield return. The next version will introduce a 
specific syntax for asynchronous programming. Would you consider hiring a programmer 
would admits he knows nothing about these features and is unwilling to learn about 
them?

第二に、C# は新しいバージョンがリリースされるたびに、数多くの関数プログラミングのコン
セプトや high-level なコンセプトを持ち込んできました。modern なC#プログラマーは
LINQ to objects や、lambda、yield return をマスターしているものと期待できます。
次のバージョンでは非同期プログラミング (asynchronous programming) のための
specific syntax が導入されるでしょう。あなたはこれらの新機能を知らず、また、
それを学ぶ気もないというプログラマーを雇う気になりますか?

F#'s higher order functions, functions as first-class citizen, sequence expressions 
and asynchronous workflows match directly the modern features of C#. Why would these 
be harder to use in F# than in C#?

F# の高階関数や first-class citizen としての関数、sequence 式、asynchronous workflows
はC#の modern features に直接マッチします。なぜ、F#でこれらの機能を使うことが
C#よりも難しいということになってしまうのでしょうか?

Dear reader, if you are a decision maker, I hope these two simple remarks dissipated 
your fears. You may be wondering why adopt F# when C# is evolving? You won't hear it 
from Microsoft, but the fact is that C# is breaking at the seams in its attempts to 
bring in new constructs. I won't give an exhaustive list, but here are a few examples 
of the limits of C#:

親愛なる読者の皆様、もしあなたが decision maker であるのなら、
この二つの単純な remark があなたの懸念を消したことを期待しています。
C#が進化しているのに、なぜF#を受け入れなければならないのかと疑問に思われるかもしれません。
あなたは Microsoft から聞いていないかもしれませんが、現実には C# は
新しい constructs を持ち込むためにほころびが生じているのです。
exhaustive list を出すことはしませんが、C#にある制限のいくつかの例を挙げます:

   1. Limits of iterator blocks (yield return). No such restriction in F#.
      イテレーターブロック (yield return) の制限。
      F# にそのような制限はありません。

   2. Closures capture variables, not values. In F#, closures capture values, which is in my
      opinion a much saner design decision.

      クロージャーは値ではなく変数を caputure します。
      F# のクロージャーは値を capture します。わたしの意見ではこれは
      とても saner (健全な、良識のある) な設計上の決断です。

   3. Language-integrated queries are nice, but they don't sound as generic as they actually
      are. F#'s notion of quotation is more elegant, and makes it easier to see the 
      applicability of LINQ beyond SQL.

      言語に統合された query は nice ですが、実際にはそれほど generic なものに見えません。
      F# での quotation の記法はより elegant で、SQL を超える LINQ の appkicability の理解を
      簡単にしています。

   4. Although it's nice that C# is "stealing" async from F#, why not introduce the
      more general concept of custom workflows?

      C# は、async を F# から「盗んだ」点はよいのですが、なぜより一般的な
      カスタムワークフレームのコンセプトを取り入れなかったのでしょうか?

Moreover, F# supports a few data-types that somehow got forgotten when class-based OOP 
became dominant, namely records and discriminated unions. Together with pattern-matching,
they are doing their come-back in the main stream and I have no doubt they will shortly
become tools top programmers are expected to master.

さらに、F# はクラスベースのOOPが支配的になったときに忘れ去られていた、
namely recoreds だとか dicriminated unions (判別共用体。だっけ?) といった
いくつかのデータ型をサポートしています。
パターンマッチングと一緒に用いることで、これらのデータ型は main stream へと復帰し、
近いうちにトッププログラマーがマスターしていることを期待されるツールになるであろう
とわたしは確信しているのです。

Now, I'm not saying you should ditch C# and replace it "en masse" by F#. C# 
has better tooling support, features implicit conversions and a lighter syntax for 
implicit interface inheritance. I don't think these features are a must-have in all 
situations, but they can be handy at times.

Now, I'm not saying you should ditch C# and replace it "en masse" by F#.
C# にはより良いツールのサポートがあり、implicit conversion の機能や
わたしはこれらの機能があらゆる局面でなければならないものだとは思いません。
しかし、それが便利な場合もあるでしょう。

Adopting all new hyped technologies has its dangers, but if you refrain from getting 
on with the times because of a few dinosaurs among your developers, your business will 
eventually go the way of the dinosaurs.

すべての新しい hyped technologies (大げさに宣伝された技術?) は受け入れることに危険性があります。
しかしもし、あなたがあなたの抱える開発者たちの中にいる少数の恐竜が原因で
新しい技術の受け入れを控えているのであれば、あなたのビジネスは恐竜たちと同じ
運命を辿ることになるでしょう。

■_ inner function

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

387 デフォルトの名無しさん [sage] 2011/05/05(木) 19:59:51.31 ID: Be:
    どうしてGCCは関数内で関数を定義できるようにしたの？
    他にある？ 

388 デフォルトの名無しさん [sage] 2011/05/05(木) 20:04:42.55 ID: Be:
    >>387
    C++なら別に普通だけどCでもいけちゃうの？ 

389 デフォルトの名無しさん [sage] 2011/05/05(木) 20:35:24.97 ID: Be:
    >>388
    C++でもだめでしょ。 

390 デフォルトの名無しさん [] 2011/05/05(木) 20:37:43.30 ID: Be:
    >>389
    http://codepad.org/tNQUFdwu

Pascal のサポートを追加するときに Pascal では inner function が使えるからそのため。 じゃあなかったかなあ。

■_

2011年05月04日

■_

きりょくぜろー。

■_ キーワード

else if のバリエーションは else if / elseif / elsif /elif くらい? 

【Perl,PHP】LLバトルロワイヤル16【Ruby,Python】

883 デフォルトの名無しさん [sage] 2011/05/04(水) 09:35:24.87 ID: Be:
    何で例外処理のキーワードって言語ごとに違うんだろ
    全部 try catch finally にしとけばいいのに
    else if を elsif だの elif だのにするのは
    構文解析のためにキーワードを作るにあたってぶれたってのはわかるんだが
    catch を rescue だとか except にした理由って何? 

884 デフォルトの名無しさん [sage] 2011/05/04(水) 10:10:37.96 ID: Be:
    もちろん、後世で「何で違うんだ？同じにしろよ！」と
    ドヤ顔で言い出す奴の自己満の為です。 

885 デフォルトの名無しさん [sage] 2011/05/04(水) 12:16:13.16 ID: Be:
    >>883
    ＞構文解析のためにキーワードを作るにあたってぶれた
    これはどういうことですか？
    elseifにすると何がまずいのでしょうか？ 

886 デフォルトの名無しさん [sage] 2011/05/04(水) 12:20:09.46 ID: Be:
    dangling elseの話かな 

887 デフォルトの名無しさん [sage] 2011/05/04(水) 13:11:22.91 ID: Be:
    単に趣味の問題とか、変わった先祖を持ってるからとかじゃないの？

    RubyはCLUなんじゃない？ 

888 デフォルトの名無しさん [sage] 2011/05/04(水) 13:16:17.89 ID: Be:
    >>883
    else if と elseif が両方共正しくて意味の異なる構文になることを避けたのかなと
    思ったが、前者はコロンが要るから別にそんなこと無いな。
    単に elseif だと音節が長いとかそういう理由な気がする。ここらへんはPython1系の
    時代からあるんだろうし、わざわざ変える必要がある部分でもないから残ってるだけ
    じゃないかな。

例外を投げる文を書こうとして、あれ、この言語は raise で投げるんだっけ throw だっけ? と悩むことがあったりなかったり。

■_ to_proc

to_proc を使ったコードはなかなか思うようには書けないレベル。＞わし 

Ruby 初心者スレッド Part 42 

287 デフォルトの名無しさん [sage] 2011/05/04(水) 13:03:29.52 ID: Be:
    これ便利だな &:symbol
    File.open('text', &:readlines) 

288 デフォルトの名無しさん [sage] 2011/05/04(水) 13:54:13.10 ID: Be:
    >>287
    なにこれ 

291 デフォルトの名無しさん [sage] 2011/05/04(水) 14:19:19.20 ID: Be:
    >>288
    :sym.to_proc
    は
    Proc.new {|arg| arg.__send__(:sym)}
    こういうものを返すらしい。

    それからメソッド呼び出しの&objによるブロック渡しは
    obj.to_procしてからブロックとして渡すらしい。

    つまり
    File.open('a', &:read) は
    File.open('a', &(:read.to_proc)) であり
    File.open('a'){|f| f.__send__(:read)} で
    File.open('a'){|f| f.read } ということ。

    collectとかsort_byみたいなのにも便利かも。 

293 デフォルトの名無しさん [sage] 2011/05/04(水) 14:58:31.77 ID: Be:
    >>291
    なんか直感的じゃなくてヤな書き方だなぁ。
    ストリームがちゃんと閉じられてますよ感が無い。 

295 デフォルトの名無しさん [sage] 2011/05/04(水) 15:02:27.66 ID: Be:
    >>293
    File.openだと微妙だけど
    array.sort_by(&:length) とかだと個人的にはこっちの方が直感的に読める。 

296 デフォルトの名無しさん [sage] 2011/05/04(水) 15:12:06.08 ID: Be:
    >>295
    array.sort_by{|e|-e.length}の場合はどう書くのっと。
    やめようよ、こんなの絶対おかしいよ。 

298 デフォルトの名無しさん [sage] 2011/05/04(水) 15:28:33.08 ID: Be:
    array.map(&:length).sort_by(&:-)
    :-) 

304 デフォルトの名無しさん [sage] 2011/05/04(水) 16:31:13.29 ID: Be:
    >>296
    個人的にはマイナスでソートするの嫌いだから
    array.sort_by(&:length).reverse 

310 デフォルトの名無しさん [sage] 2011/05/04(水) 18:15:10.29 ID: Be:
    >>304
    ぐぬぬ…

sort_by で逆順にソートしたいときってみんなどうやってんだろう?

■_

もういっこ。

ポイントフリースタイルはいまだによくわからん。 いや、ここでは関数合成か。 

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

361 デフォルトの名無しさん [sage] 2011/05/04(水) 16:43:48.23 ID: Be:
    素直な人 f (g (h arg))
    普通の人 f $ g $ h arg
    性格が捻じ曲がった人 f . g . h $ arg 

362 デフォルトの名無しさん [sage] 2011/05/04(水) 17:14:10.03 ID: Be:
    >>361
    :(；ﾞﾟ'ωﾟ'）: 

363 デフォルトの名無しさん [sage] 2011/05/04(水) 17:26:17.44 ID: Be:
    >>361
    なんでｗ
    f.g.hを一つの関数に見立ててargを渡してるわけでしょ。
    性格曲がってないし、普通だし。 

364 デフォルトの名無しさん [sage] 2011/05/04(水) 17:27:17.32 ID: Be:
    (\x -> f.g.h x) arg 

365 デフォルトの名無しさん [sage] 2011/05/04(水) 17:28:25.75 ID: Be:
    >>361
    あと、f$g$h argだと再利用性が悪いじゃん。 

366 デフォルトの名無しさん [sage] 2011/05/04(水) 17:33:23.01 ID: Be:
    arg が IO とかついていた場合だと
    f . g . h <$> arg
    ってほぼそのままいける
    f <$> g <$> h <$> arg
    はちょっとしつこい 

367 デフォルトの名無しさん [sage] 2011/05/04(水) 17:50:49.49 ID: Be:
    >>364 がツッコんで欲しそうにこちらを見てるんだが、どうしようか 

368 デフォルトの名無しさん [sage] 2011/05/04(水) 18:31:09.87 ID: Be:
    始対象厨: f . g . h . const arg $ ()
    プログラム全体を定数にするとなんか嬉しかったりすんのかな？

■_ へじたんに質問

答えのほうも文字に起こしといて欲しい ○|￣|＿ 

Anders Hejlsberg: Questions and Answers | | Channel 9

Anders wanted to hear from you to get a sense of what's on your mind with respect to 
C#. We asked you for questions and, as usual, you delivered -> this is your 
interview, Niners. Smiley Thanks for the great questions. Special thanks to Anders for 
taking an hour out of his insanely busy schedule to answer your questions.

Anders Hejlsberg: Questions and Answers 


03:16 exoteric -> When is Async not appropriate to use?

05:29 exoteric -> How long before the Async "virus" permeates all of .NET?

07:23 rhm -> Did you consider implementing a more general language facility to implement Async?

12:24 felix9 -> The TouchStudio guys have discovered that the touch UI or NUI has unique tooling needs, any thought on that front?

14:10 AdamSpeight2008 -> Will vb.net and C# ever have the ability to discriminate methods with the same input type signature but different return types?

16:10 SteveRichter -> What do you think about dependency properties in WPF (and in general...)?

19:18 mikebmcl -> Has the C# language team ever considered or would they consider adding a way to use custom logic with automatically implemented properties?

21:16 ktr -> With the future addition of "compiler as a service" are there any plans for possible support for metaprogramming?

23:13 felix9 -> How could Roslyn serve us 'coders' better directly?

26:10 Charles -> How much can you do with CaaS?

27:37 felix9 -> Programming language design, Delphi's impact on .NET, etc.

29:42 Bas -> My two questions would be: why the beef with optional parameters when they
      so elegantly bring that whole block down to the essence of it, and more in general,
      what ways does he see to reduce the amount of ceremony in future versions of C#?

31:47 Richard.Hein -> Thoughts on C# higher kind types?

33:52 Ian2 -> Can you conceive of a time when you don't have to write code to build software?

36:55 JoshRoss -> .NET on x86 versus ARM...
x86 上の .NET と ARM 上の .NETについて

38:48 Richard.Hein -> Are there features in other languages that make you jealous?
他の言語で良いなあと思う機能はありますか?

40:15 Charles -> What do you think about JavaScript, from a language designer's perspective?
言語設計者の視点で、JavaScirpt をどのように思いますか?

45:10 Dr Herbie -> As C# grows and ages do you miss the simplicity of first version?
C# が成長し時間を経るについて最初のバージョンにあった単純さを失ったとお考えですか?

47:07 Dr Herbie -> Do you think C# is a complete language or do you spend time thinking about what's missing?
C# が完全な言語だとお考えですか? あるいは欠けているものについて時間をかけていますか?

49:00 Charles -> What do you think about C++?
C++ についてどのように考えてますか?

51:32 Steve Richter -> Difference between explicit type casting and the as operator?
explicit な型キャストと as 演算子との違いとは何でしょうか?

53:39 exoteric -> What inspires you?
あなたを inspire したものはなんですか?

56:38 aL -> What do you think about expanding the c# event syntax for better composability/interop with things like Async/Rx?

1:00:00 aL -> What features would you like to remove from C# as it is today?


1:02:41 Charles -> why did you choose "unsafe" for the name of unsafe block?
なぜ unasafe block の名前に “unsafe”を選んだのですか?

ぐはっ。また beef がっ

■_

2011年05月03日

■_

boxing を「ボックス化」と訳すのはおかしいんじゃね? と思ってたのですが、 考えてみたら encapsulation を「カプセル化」ってのも変ですね。

■_ 二題

やってて楽しいプログラミング言語は？ 2言語

416 デフォルトの名無しさん [sage] 2011/04/30(土) 22:14:18.75 ID: Be:
    人の役に立ちたいならC/C++
    人を食い物にしたいならJavaScript、Perl、CSS等々
    人との関係を絶ちたいならHaskell、Prolog、APL等々 

ふらっとC#,C♯,C＃（初心者用） Part74

78 デフォルトの名無しさん [sage] 2011/05/03(火) 14:54:22.39 ID: Be:
    後知恵はいつも素晴らしいw

だよなあ＞後知恵

■_ look-ahead

「幅」ってのは、Perl のドキュメントにあった記述を直訳した。のかなあ (自分も片棒担いでたような気がしないでもない)。 ただ、「(マッチング開始位置が)戻る」ってのもちょっと違うんだよね。 どっちかというと「進まない」のほうが実動作に近い。 

Ruby 初心者スレッド Part 42

214 デフォルトの名無しさん [sage] 2011/05/03(火) 10:02:24.47 ID: Be:
    正規表現の先読みが理解できない。
    >>> /(?=foo)bar/ =~ "foobar"
    => nil
    なんでこれがマッチしないん？ 

215 デフォルトの名無しさん [] 2011/05/03(火) 10:24:00.49 ID: Be:
    この手の記法は基本的に、幅がなく、位置(文字と文字の境界)にマッチする。
    (?=foo) の場合は、「直後にfooのある位置」("foobar" の場合、fの左)にマッチする。
    その位置から bar にマッチせよ、ということ。

216 デフォルトの名無しさん [sage] 2011/05/03(火) 10:25:03.24 ID: Be:
    「幅を持たない」って書いてあるじゃん

    /(？=foo)/ で "foo" までマッチはするんだけど、位置は動いてないんだ
    動いてないってことは、直後の正規表現 /bar/ はまた "foo" の先頭からマッチを試される
    もちろんマッチしない
    結果は nil

    /(?=foo)bar/ は
    「文字列fooと文字列barが同じ開始位置から存在する」という必ず失敗する正規表現
    先読みはマッチ記号入れないと思い通りには動作しない 

217 デフォルトの名無しさん [sage] 2011/05/03(火) 10:26:26.20 ID: Be:
    それは(foo)かつb,a,rと続く文字
    /(?<=foo)bar/ 

218 デフォルトの名無しさん [sage] 2011/05/03(火) 10:35:40.71 ID: Be:
    >>215-217
    あーわかった、
    /(?=foo)bar/ =~ 'foobar'
    だと、いったん先頭から foo にマッチしたあと、開始場所がまた先頭に戻るわけね。
    それが「幅を持たない」って言う意味か。なるほど。ありがと。

    「ruby 正規表現 先読み」でぐぐったら
    ttp://www.ruby-lang.org/ja/man/html/_C0B5B5ACC9BDB8BD.html
    のページがでてくるんだけど、このページを見てもさっぱりわからかったんだよね。
    「幅を持たない」というのがどういう意味か、まるで書いていないし。マッチング開始場所が戻ると書いてほしいな。

    あとこれも。
    > (?=re1)re2
    > という表現は、re1 と re2 両方にマッチするものにマッチする正規表現で す。
    こうじゃなくて、「re1とre2の両方に、同時にマッチする正規表現」と書いてくれればいいのに。
    「マッチするものにマッチする」ってなんだよ。 

219 デフォルトの名無しさん [sage] 2011/05/03(火) 10:37:12.27 ID: Be:
    先読みとか戻り読み駆使した正規表現読み書きしてるとだんだん脳みそ溶けてくるよね。 

220 デフォルトの名無しさん [sage] 2011/05/03(火) 10:44:14.31 ID: Be:
    93%くらいの用途は正規表現のマッチメソッドを && や || で繋げて処理すれば済むんだが
    人はなぜか正規表現の先読み戻り読みを使って一発で表現しようとする
    正規表現オブジェクトいっこでマッチさせたい需要は理解はするがw 

221 デフォルトの名無しさん [sage] 2011/05/03(火) 10:44:13.83 ID: Be:
    正規表現をマスターするには1つの言語を習得するぐらいの時間が必要だよね 

222 デフォルトの名無しさん [sage] 2011/05/03(火) 11:04:13.59 ID: Be:
    正規表現の先読みって、どんなときに必要なの？
    用途がさっぱりわからない。 

223 デフォルトの名無しさん [sage] 2011/05/03(火) 11:11:37.28 ID: Be:
    >>222
    if /re1/ =~ str && /re2/ =~ str then
    のかわりに
    @re = /(=?re1)re2/
    if @re =~ str then
    と書けるようになる 

224 デフォルトの名無しさん [sage] 2011/05/03(火) 11:16:39.97 ID: Be:
    ぶっちゃけ、どこに条件を押し込むかという問題に過ぎない

    スクリプト構造を単純にするかわりに、正規表現に条件を押し込む
    正規表現を単純にするかわりに、スクリプト構造側で条件を増やす 

225 デフォルトの名無しさん [sage] 2011/05/03(火) 12:00:23.82 ID: Be:
    >>223
    if /re1|re2? =~ str
    でよくね？ 

226 デフォルトの名無しさん [sage] 2011/05/03(火) 12:01:04.30 ID: Be:
    まちがえた
    if /re1|re2/ =~ str
    でよくね？
    それとも速度に違いがあるんかな 

227 デフォルトの名無しさん [sage] 2011/05/03(火) 12:04:19.90 ID: Be:
    >>223
    ん、
    /(?=re1)re2/ =~ str
    と
    /re1/ =~ str && /re2/=~str
    は全然違うぞ。勘違いしてない？

    str = 're1re2'
    p (/(?=re1)re2/ =~ str) #=> nil
    p (/re1/ =~ str && /re2/=~str) #=> 3 

228 デフォルトの名無しさん [sage] 2011/05/03(火) 12:28:18.73 ID: Be:
    >>226
    /re1|re2/ =~ str
    どこかにre1かre2の少なくとも一方あればマッチ、どっちでもいいから最初のマッチ位置が返る

    /re1/ =~ str && /re2/ =~ str
    どこかにre1があって、かつre2もどこかにあればマッチ。re2のマッチ位置が返る

    /(?=re1)re2/ =~ str
    re1でマッチするか確かめ、そのマッチ位置(≠re1のうしろ)でre2にマッチすればre2の位置が返る。

    全部違うお 

229 デフォルトの名無しさん [sage] 2011/05/03(火) 12:52:15.79 ID: Be:
    /(?=re1)re2/ がマッチする例ってあるの？ 

230 デフォルトの名無しさん [sage] 2011/05/03(火) 12:58:20.26 ID: Be:
    >>229
    そっくりそのまま/(?=re1)re2/なら絶対に失敗。

    []とか.とか?とか+とか*とか|とか、なんでもいいけど、
    複数の状態にマッチする先読みならマッチすることもある。 

231 デフォルトの名無しさん [] 2011/05/03(火) 13:08:13.57 ID: Be:
    無理やり考えた。

    文字列中、年月日を表す数値だけ漢数字表記にする。

    kansuuji = {
    "0"=>"〇", "1"=>"一", "2"=>"二", "3"=>"三", "4"=>"四",
    "5"=>"五", "6"=>"六", "7"=>"七", "8"=>"八", "9"=>"九"
    }

    text = '1989年4月1日に3%の消費税が導入された'.
    text.gsub!(/(¥d+)(?=[年月日])/) { $1.chars.map {|c| kansuuji[c] }.join }

    まぁこの程度だと先読みを使わなくても後続パターンを記憶すれば出来るか。
    text.gsub!(/(¥d+)([年月日])/) { $1.chars.map {|c| kansuuji[c] }.join + $2 }

232 デフォルトの名無しさん [sage] 2011/05/03(火) 13:16:23.73 ID: Be:
    subとかgsubみたいに「マッチした部分」を取り扱うメソッドだと先読み使うこともある。

■_

没。

■_

2011年05月02日

■_

アカギは相変わらずだなあ。

■_

■_

ちょっと前に PHPプロジェクトの80-90％は巨大なクソの山であるという事実 : candycane development blog と題された翻訳記事が発表されました。 この記事には 100を超えるはてなのブックマークがついていて (はてなブックマーク - PHPプロジェクトの80-90％は巨大なクソの山であるという事実 : candycane development blog)、 結構注目されたようです。 元記事は“PHP was Ghetto”というタイトルだったのですが、 訳者の意向によって先のものに変えられたようです。 

PHPプロジェクトの80-90％は巨大なクソの山であるという事実 : candycane development blog

それにしても”PHP infected brain”なんてPHP脳の恐怖といって良い言葉が英語でもあったと
はねぇ。。。「ゲットー」という言葉が日本語としては象徴的な意味が薄いのでタイトルは箇条
書きから抜粋しました。

この翻訳記事のタイトルのせいか、ブックマークのコメントを見ても記事の内容が PHPをこき下ろしているものであると受け取った人も多いようです(ほとんど?)。 でも、本当にそうなんでしょうか?

○○はゲットー(Ghetto) だというフレーズですぐに思い浮かぶのは、 Rails Is A Ghetto ですが、 これは「is」なのに今回のこの記事では「was」なのが気になりました。 また、失礼な物言いですが、翻訳記事を読んでいると日本語の言い回しとしておかしいと思われる箇所が いくつかあり、元記事ではどのように書かれているのか見てみることにしました。

すると、実はこの記事はPHPをこき下ろす記事ではなくて、 その反対のことを主張しているように思えたのです。

ということで、自分なりに訳してみました。 単語などでしっくりくる日本語が見つからなかった(思いつかなかった)ものは英語のまま放置してたりします。 反対に、意訳のようなことをしてたりもします。 

Why PHP Was a Ghetto

By Kenny Katzgrau | Published: April 5, 2011

Note: I wrote this over a month ago, but decided not to publish it until now.

I was talking with the Co-founder of a pretty cool start-up in DUMBO the other day 
about why the non-PHP development world generally has such disdain for PHP and the 
community surrounding it. He brought up an interesting point that stuck with me, 
largely because I hadn’t heard it before.



先日、わたしは DUMBO にあるとても cool なスタートアップ企業の副創業者(Co-founder)と、PHP
以外の開発者たちがなぜ PHP やそれを囲むコミュニティを蔑むのかについて話す機会がありまし
た。そこで彼はそれまでわたしが耳にしたことのない、印象に残る指摘をしたのです。

If you're unaware of the usual beef most developers have with PHP, it tends to revolve around:



 (usual beef な) 大部分の開発者たちが PHP に対して抱いている不満をご存じないのなら
大部分の開発者たちがPHPに対して抱くよくある不満をご存じないのなら、
概ね以下のような傾向にあります:
#usual beef とかなに → 口語で使われるような用法で、あまりよろしくない意味のようです :)

1.	Ugly syntax
2.	Lack of some necessary features that other languages have (prior to 5.3, namespacing, closures)
3.	Inconsistent function naming, usage, and other quirks
4.	Mix of procedural and OO-ness
5.	The fact that 80-90% of PHP projects are probably gigantic piles of shit


   1. 醜い構文
   2. 他の言語にはあるような(5.3以前の名前空間やクロージャのような)いくつかの必須機能の欠如
   3. 関数についての、一貫性のない命名や使用法、あるいはその他の quirks。
   4. 手続き指向とオブジェクト指向のごった煮ごたまぜ
   5. PHPプロジェクトの80-90％は、おそらく巨大なクソの山であるという事実

#quirks って互換を保つためのしかけ。とかでいいんでしょか。

 
But his problem with PHP was a little different. He didn’t say the actual language 
was poor — he said it was the general culture surrounding the language, which is 
usually iconified by a language’s founder, that seems to encourage bad practices. 
That is, PHP code bases tend to be hacky and unmaintainable.


彼は PHP という言語それ自身が poor であるとは言いませんでした。彼は、PHPという言語の作成
者(founder)に象徴されるBad practice を奨励するかのような文化一般に問題があると指摘した
のです。要するに、PHP のコードベースは hacky で 保守不能 (unmaintainable) になりがちだ
ということです。

 
The concept that the community surrounding a language or framework embodies an author’
s philosophy seems to be true. He brought up Ruby and Matz. Matz wanted a language 
that was easy to read and write, and enhanced programmer productivity. Don’t Ruby 
developers seem to harp on rapid application development and the elegance of their 
language?



言語やフレームワークを取り囲むコミュニティの concept は、言語作者の (seems to be true
な) 哲学というものを embody (具体的に表現) します。彼は Ruby and Matzを例として挙げました。
Matz は読み書きしやすくそれでいてプログラマーの生産性を向上させる言語を望んでいました。
Don't Ruby developers seem to harp on rapid application development and the elegance 
of their language?
# Don't 以下の一文はどうにもそれなりに自信に持てる訳ができませんでした。
#ただ、翻訳記事では「共鳴」とあるのですが、Harp on は「（批判をこめて）繰り返し言う」
#といった感じなので、ニュアンスがおかしい気がします。

Then DHH and the Rails came up. Then Guido and Python. So I thought: What about Rasmus?



そうして DHH and Rails が登場し、さらに Guido and Python が続きました。そこでわたしは
考えたのです。Rasmus についてはどうなのだろうか。と。

#DHH and Rails の and  を 「と」としてしまうと全体として文章がうまくない気がするので
#そのままにしています。

Rasmus Lerdorf is an interesting figure. He created the original version of PHP, 
continues to contribute, is widely considered a demigod in the community and the 
authority on almost anything PHP. He steals masses of attendees at conferences, gets 
hired by big internet places, and garners the respect of everyone despite one glaring 
property: Rasmus represents what most non-PHP developers hate about PHP.



Rasmus Lerdorf は興味深い人物で、PHP の大元を作りそして貢献し続けたことでコミュニティに
おいては demigod (神のごとく。くらい?) として扱われており、PHP に関するほぼすべての権威とみなされています。
Rasmus はカンファレンスにおいて出席者の多く(masses of attendees) を steal して
big internet places に雇われれました。また、PHP 開発者以外の大部分は PHP を嫌っていると
Rasmus が表現する glaring property があるにも関わらず彼は皆の respect を集めています。

Rasmus generally promotes abstention from using frameworks, and the use of PHP as more 
of a templating language. To him, this translates to raw speed and scalability 
(load-wise). To everyone else, this translates to piles of procedural spaghetti code, 
and unmaintainable projects. For roughly 10 years following the birth of PHP in 1995, 
this was how PHP projects were written.



Rasmus はフレームワークの使用を避け、テンプレート言語として PHP を使うのを一般に推奨し
ています。彼にしてみればこれは、
raw speed and scalability (load-wise) ということになりますが、
フレームワークによる邪魔のない、そのままのスピードと(load ごとの?)スケーラビリティということになりますが、
その他の人にとっては procedural spaghetti code (手続き型で書かれたスパゲッティコード) と unmaintainable projects (保守が不可能なプロジェクト) の 
山 ということになります。1995年の PHP の誕生からおおおよそ10年間はこれが PHP プロジェ
クトでの書き方だったのです。

But another issue cropped up:  In it's pizza-faced adolescent years (pre-5.0), PHP 
gained a serious following among novices. The language has a fantastically low barrier 
to entry, so anyone could get started in 2 minutes by downloading some self-extracting 
*AMP stack for Windows. Additionally, the acceptance of the MVC paradigm hadn’t 
really occurred yet in web development. What do you get when you mix n00bs and a lack 
of best practices? Unmaintainable garbage. And that’s what proliferated.


PHPは(5.0以前の)その pizza-faced adolescent years に、初心者の熱心な支持を獲得しました。
PHP は素晴らしく低い barrier to entry しかなく、Windows 向けの自己展開型 *AMP stack を
いくつかダウンロードすれば2分で使い始められました。さらに、web 開発においては MVC パラ
ダイムは実際にまだ受け入れられていませんでした。ベストプラクティスがないところに新米
(n00bs) を放り込んだら何ができるでしょうか? 手のつけようがないゴミ (unmaintainable
garbage) です。そしてそれが増殖するのです。


Don't get me wrong — there were some great PHP developers around, even back then. But 
like I said, unrefined n00b-sauce was all around. When cowboy PHP developers with no 
standards got together to build a project, it came out looking like PHPbb, PHPNuke, or 
some other gnarled mash of .php3 files. But can you singularly blame PHP developers? 
No! The other web language giants, ASP and Perl, were also gross as hell and promoting 
the same spaghetti-code practices.



誤解しないでもらいたいのは、過去に遡ってさえ 卓越した PHP 開発者も中にはいたということ
です。しかしわたしが既に述べているように、unrefined n00b-sauce (refine されていない未熟
なソース) にあふれていたのです。標準を持たない Cowboy PHP 開発者たちが一つのプロジェクト
の遂行のために集合したのなら、その結果は PHPbb や PHPNuke、 あるいは拡張子が .php3 のフ
ァイルの gnarled mash のようなものになるでしょう。ですが、PHP開発者たちをsingularly に
責めることができるでしょうか? できはしません! ASP や Perl といった他の web 言語の巨人た
ちにしても gross as hell であり、PHP と同じような spaghetti-code practices を奨励して
いたのです。

#gnarled mash きちんとすりつぶされていない塊が残っているとかそんな感じ?


So why does PHP get a bad rap? Because of its legacy. And most old-time PHP devs who 
have fled to Python, Ruby, and Java haven’t really looked back to see what kind of 
development has happened in the language since the introduction of MVC on the web. 
Additionally, there were super-outspoken critics like “Ruby guy” Zed Shaw 
complaining of developers with “PHP-Infected Brains”, and the distribution of stuff 
like this on RubyInside.



ではなぜ、PHPは bad rap を受けるのでしょうか? それは PHP 自身の legacy によるものです。
また、Python や Ruby あるいは Java へと逃げだした古くからの PHP 開発者たちのほとんどは、
web  に MVC が持ち込まれてから後に PHP に起こった kind of development を確かめるために
振り返ったりはしませんでした。加えて、“Ruby guy” Zed Shaw のように
“PHP-Infected Brains”な開発者に対する苦痛を訴えたり、RubyInsideで “こんなもの”
をばら撒いた super-outspoken critics がいました。

#「恐怖」ってどこからでてきたんだろう…
#例の画像を作ったのって Zed だったっけ?

PHP was a ghetto.

PHP はゲットーだった。

But the development of frameworks like Zend and CodeIgniter have greatly pushed the 
language development into the right direction. In fact, it’s been pushed in the 
opposite direction of where Rasmus would probably like to see it. Check out the Zend 
or CodeIgniter frameworks and tell me it’s not some of the best documented, most 
well-written code you’ve seen.



Zend や CodeIgniter のようなフレームワークの開発は言語の開発を正しい方向へと強力にプッ
シュしましたが、実際にはそれは Rasmusが 望んでいるであろう方向とは反対方向へプッシュす
るものでした。Zend かCodeIgniterのフレームワークをチェックアウトして、それが
and tell me it's not some of the best documented, most well-written code you've seen.

#tell 以下はなんか特別な言い回しのような気がする

 
When most developers learned Ruby, they were learning Rails and MVC  at the same time. 
PHP was in use for a full 10 years before that. So there really wasn’t a period of 
time when heinous Ruby was being written by novices. There was an established standard 
in place for Rails, and the barrier to entry was a much higher, typically keeping less 
experienced developers out.



Ruby を学んだ開発者たちのほとんどは、同時にRailsとMVCとを学んでしました。PHPはそれより
十年も前から使われていました。そのため、novices によって heinous Ruby が書かれた時期が
ありません。Railsのために establishされた standard がありましたが、barrier to entry が
とても高かったので経験の少ない開発者を大方を締め出していたのです。

# When most developers learned Ruby, をどうすべきかよくわからん
# ほとんどの開発者が～とすると、開発者全体のなかでRubyに手を出したのがかなり(ぜんぶ?)
#ということになるだろうし。

The fact is, a PHP applications can be as well-written as an application in any other 
language, and probably have the additional advantage of speed. The widespread use of 
MVC-style development in the PHP world is a relatively recent phenomena though, and 
admittedly, we can probably thank Rails for it.



実際には他のすべての言語と同様、PHP アプリをきちんと書くことは可能ですし、それに加えて
PHP にはおそらく速度面でのアドバンテージがあります。PHP世界における開発でＭＶＣスタイル
が広く使われるようになったのは他の言語に比べれば最近の現象ではあっても明らかなことです。
Rails のおかげかもしれません。

#最後の一文はよくわからん。
 
So what does PHP have going for it now?


さて、現時点で PHP がユーザーに提供できるウリとはなんでしょうか?

1.	Standards (not universal, but generally a flavor of MVC for most projects, and little procedural crap)
2.	A very low barrier to entry
3.	Speed & Scalability (maybe the best among script-based languages)
4.	A great unit testing framework
5.	Arguably the best documentation for any language

   1. 標準 (universal ではないが、generally に大部分のプロジェクトには MVC の flavor で、ちょっと
      procedural crap のある)
   2. 非常に低い参入障壁
   3. (おそらくスクリプトベース言語の中で最高の)速度とスケーラビリティ
   4. 優れたユニットテスト用フレームワーク
   5. すべての言語に対するおそらくは最良のドキュメント


 
Additionally, it's behind some of the internet's most influential websites and tools, 
like Facebook, Digg, Wikipedia, WordPress, Drupal, etc. I'd bet that having a solid 
understanding of it opens more doors for a developer than any other.



それに加えて、Facebook や Digg、Wikipedia、WordPress、Drupal などの
もっとも影響力を持った Web サイトやツールの背後に PHP は隠れています。
きちんと PHP を理解することがほかの何よりも開発者に対してより多くの機会を
もたらすものであると、賭けてもいいでしょう。

 
If you don’t agree with the above, comment on this post, or email me — I’d like to 
hear why you don’t think so.



上記の記述に賛成できないのなら、この記事のコメント欄かメールでわたしに教えてください。
なぜあなたが賛成できないのかを知りたいです。

I'm no PHP fanboy — in fact, I’m very language-agnostic. I write PHP more often 
because, you guessed it, people pay me to. So it all comes down to this:


わたしは PHP fanboy ではありません。実際のところとても language-agnostic です。
わたしはかなり頻繁に PHP で書いていますが、それはあなたもお察しの通り
それで糧を得ているからです。ですから、結論はこうなります:

If you are capable of making wise software design decisions, PHP is a great choice to 
build your web application with.



あなたが capable of making wise software design decisions であるなら、PHP は web アプリケ
ーションを構築するのに great choice です。
 

By the way, if I just convinced you to build your next webapp in PHP, check out CodeIgniter.
It's the lightweight, no magic, ultra fast framework for PHP. When it comes to CodeIgniter,
I am a fanboy.


ところで CodeIgniter をチェックアウトしましょう。これは軽量で、魔術を使ってない(no magic)、
とんでもなく高速な PHP 向けのフレームワークです。CodeIgniter のこととなると
わたしは fanboy となってしまうのです。

お粗末さま。

確かに“The fact that 80-90% of PHP projects are probably gigantic piles of shit” という一文が文中に出てきますが、これを全体を現すタイトルとして抜き出し、 さらに強調するのは誤ったやり方ではないでしょうか。

「お前のほうが間違っておるわボケ」というブーメランは喜んでお受けいたしまする ○|￣|＿

■_

疲れた。

2011年05月01日

■_

群論とエニグマ暗号とチューリング
ついったで知ったのですが、エニグマ暗号のあの操作も群論で説明できるらしいですね。 どんだけすごいんだ群論。 

エニグマ (暗号機) - Wikipedia
エニグマ解読には5つの方法、そしてモチベーションが必要とされた。どれもが重要な役割を果
たし、タイムリーな解読のために相互に補完した。

学理的な解読 

    * 群論によるローター配線解析の成功。これは解読者に数学よりも語学のセンスを要求した英国の方針を転換させた。

機械による解読 

    * アラン・チューリングが開発した多数の暗号解読機「ボンベ (Bombe)」による総当り攻撃。

エニグマ暗号解読の話はいろいろ読んだはずなんだけどなあ。 群論のぐの字も覚えてなかった ○|￣|＿ そしてチューリングといえば、長いこと放置している本が二冊ほど (洋書。技術書と違って小説仕立てのものはなかなか)。

抽象代数の歴史
昨日買った本。帯に「群・環・体はどのように誕生したのか」みたいなアオリがあったので そういうのに弱いわたしは一撃で○|￣|＿

・ぼのぼの
連載300回とか。長いねーこれも。 この300回って数字はまんがくらぶだけの数字なんだろうか? (まんがくらぶの最新号に書かれていたものなので)

■_

■_ Vector products

Perl 6 のコードがすごかったので。 

Vector products - Rosetta Code

Vector products is a draft programming task. It is not yet considered ready to be 
promoted as a complete task, for reasons that should be found in its talk page.

(仕様などはさっくり略)

J
Based on j:Essays/Complete Tensor:

CT=: C.!.2 @ (#:i.) @ $~
ip=: +/ .*    NB. inner product
cross=: ] ip CT@#@[ ip [

An alternative definition for cross (based on finding the determinant of a 3 by 3 
matrix where one row is unit vectors) could be:

cross=: [: > [: -&.>/ .(*&.>) (<"1=i.3) , ,:&:(<"0)

Implementation:

a=:  3 4 5
b=:  4 3 5
c=: -5 12 13
 
A=: 0 {:: ]    NB. contents of the first box on the right
B=: 1 {:: ]    NB. contents of the second box on the right
C=: 2 {:: ]    NB. contents of the third box on the right
 
dotP=: A ip B
crossP=: A cross B 
scTriP=: A ip B cross C
veTriP=: A cross B cross C

Required example:

   dotP a;b
49
   crossP a;b
5 5 _7
   scTriP a;b;c
6
   veTriP a;b;c
_267 204 _3


Perl 6

sub infix:<⋅> { [+] @^a »*« @^b }
 
sub infix:<⨯>([$a1, $a2, $a3], [$b1, $b2, $b3]) {
    [ $a2*$b3 - $a3*$b2,
      $a3*$b1 - $a1*$b3,
      $a1*$b2 - $a2*$b1 ];
}
 
sub scalar-triple-product { @^a ⋅ (@^b ⨯ @^c) }
sub vector-triple-product { @^a ⨯ (@^b ⨯ @^c) }
 
my @a = <3 4 5>;
my @b = <4 3 5>;
my @c = <-5 -12 -13>;
 
say (:@a, :@b, :@c).perl;
say "a ⋅ b = { @a ⋅ @b }";
say "a ⨯ b = <{ @a ⨯ @b }>";
say "a ⋅ (b ⨯ c) = { scalar-triple-product(@a, @b, @c) }";
say "a ⨯ (b ⨯ c) = <{ vector-triple-product(@a, @b, @c) }>";

Output:

("a" => ["3", "4", "5"], "b" => ["4", "3", "5"], "c" => ["-5", "-12", "-13"])
a ⋅ b = 49
a ⨯ b = <5 5 -7>
a ⋅ (b ⨯ c) = 6
a ⨯ (b ⨯ c) = <-267 204 -3>

J もまあ。

■_ あとで読む

prog21: Impressed by Slow Code

Impressed by Slow Code

At one time I was interested in--even enthralled by--low-level optimization.

Beautiful and clever tricks abound. Got a function call followed by a return statement? 
Replace the pair with a single jump instruction. Once you've realized that "load 
effective address" operations are actually doing math, then they can subsume 
short sequences of adds and shifts. On processors with fast "count leading zero bits"
instructions, entire loops can be replaced with a couple of lines of linear code.

I spent a long time doing that before I realized it was a mechanical process.

以下略

■_ あとで読む

その2．Land of Lisp のレビュー。 そいやまだ買ってないな。これ。 

brainwagon » Blog Archive » Book Review: Land of LISP, by Conrad Barski

Book Review: Land of LISP, by Conrad Barski

I learned to program as a teenager back in the 1980s, starting as most of a generation 
of future computer professionals did. I had an Atari 400 at home, and learned to 
program using the most popular language of the day: BASIC. There were lots of 
magazines like COMPUTE! and Creative Computing that included program listings for 
simple games that you could type in and experiment. The interaction was very hands on 
and immediate.

Sometimes I feel like we've lost this kind of “hobbyist programming”. Because 
programming can be lucrative, we often concentrate on the saleability of our skills, 
rather than the fun of them. And while the computers are more powerful, they also are 
more complicated. Sometimes it feels like we've lost ground: that to actually be a 
hobbyist requires that you understand too much, and work too hard.

以下略

■_ あとでよむ

みっつめ。 

Lisp: the anti-fashion language - A blog by Pavel Penev

Pavel is using Posterous to post everything online. Shouldn't you?

On my quest for mastery

    *  Lisp: the anti-fashion language

      Do you love learning new languages? Do you embrace new technologies and ideas like
      NoSQL, do your tweets look just like the ones from @hipsterhacker, but not a parody?
      I'm not saying that these things are bad, but I'm here to present to you a point of
      view I picked up while learning Common Lisp, that might make you question some of
      your believes about the new hot shit you read about on Hacker News all the time.

      あなたは新しい言語を学ぶのが好きですか?

      I have a question, would you ever program in a language that hasn't changed at 
      all since 1994? No new fancy syntax, no new language built-ins, other than new 
      libraries, no incompatible changes for 16 years. Ugh, thats a language gone stale, 
      you'll think immediately. Thats what I and almost anybody who's looked at Common Lisp 
      recently has thought. For some reason we've convinced ourselves that if a language 
      doesn't have a new version every 6 months, its outdated.

      ひとつ質問があります。あなたは、1994年からぜんぜん変わっていない言語でプログラミング
      するつもりはありますか? 新しいこじゃれた構文もなく、新しい組み込み機能もなく、
      新しいライブラリ以外の非互換な変更も16年間ありません。
      そんな言語は活気がなくなってしまったのだとあなたは即座に考えることでしょう。
      それはわたしや、Common Lisp を見たほとんどすべての人が考えることに近いでしょう。
      いくつかの理由で、わたしたちはある言語が六ヶ月間新しいバージョンを出していなければ
      その言語は時代遅れになってしまったのだと確信しています。

      Even if you ignore this thinking for a while, and do learn Common Lisp and go searching
      for libraries, you see that a library hasn't been updated since 2009 and you go "Ugh,
      that library isn't maintained". It doesn't matter if its good or not, you just
      refuse to use something that hasn't been updated in two years. Why? Whats wrong with it?
      Isn't it possible that it's a stable and usable piece of code that doesn't need to be
      patched constantly, rewritten every two years and break compatibility?

略


Theme created for Posterous by Obox
Share it your way on Posterous - Create your own site, blog or group for free »

■_

使えるところにも縁がなっしんぐ。 

〓 Mathematica 5 〓 

448 １３２人目の素数さん [sage] 2011/04/30(土) 10:20:13.06 ID: Be:
    mathematica持ってるだけで雲の上の人たちだな、、。日本では。
    考えてみればハードより高いし、、。 

449 １３２人目の素数さん [sage] 2011/04/30(土) 11:46:45.92 ID: Be:
    自分で買わなくたって使えるところに所属していれば

一つ前へ 2011年4月(下旬)
一つ後へ 2011年5月(中旬)

ホームへ

リンクはご自由にどうぞ

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