# ときどきの雑記帖 再起編

### 2012年02月10日

#### ■_

まんがライフオリジナル連載の「ういういDAYS」も次回が最終回とか (最後のページの柱にそうあった)。

グラフ(チャート)色々
パイチャートとか棒グラフとか色々ありますよね。 あれってどこかにカタログのようなものないでしょうか。 本でも何でも良いのですが、このグラフ(チャート)はこういった用途に向いている といった解説もあるとなおよし。

で、それと関連して「プロジェクトの状態の可視化」でいい表現方法はないものでしょうか? 進捗(の度合い)ではなく、ある時点で切り取った状態。 進捗を関数で表せるとしたならその微分を求めるとか (自分で書いててよくわからなくなってきたw)。 ジュンク堂でプロジェクト管理やらなんやらの本をいくつか見てみたけど これというのには遭遇せず。 みなさんどうやってプロジェクト管理してるんでしょう (ってその本通読すればいいんだろうか)?

#### ■_ 20周年

MicrosoftのC++コンパイラーが最初のリリースから20年だそうで。 MS-C/C++ 7とかVisual C++ 1.0って確か買ってたよな (今よりよほど余裕があったらしいw)。 さすがにマニュアルの類は処分しちゃったけど (この頃は分厚い紙のマニュアルが何冊もついてきた)、 インストールメディアは残しているはずだな。どこだろ。

The Microsoft C++ Compiler Turns 20! - Visual C++ Team Blog - Site Home - MSDN Blogs

The Microsoft C++ Compiler Turns 20!
3 Feb 2012 8:30 AM

Microsoft C/C++ 7.0

This month, we enter the third decade of C++ at Microsoft.

It was twenty years ago, in February of 1992, that we released our first C++ compiler:
Microsoft C/C++ 7.0. Before then, we already worked with several of the C++ “preprocessor”
compilers that took C++ and converted it to C before our compiler then created the executable
program. But starting in 1992, Microsoft's premier native compiler supported C++ directly,
and has done so ever since.

20年昔、1992年の2月にわたしたちの C++ コンパイラーである Microsoft C/C++ 7.0 を
わたしたちはリリースしました。それ以前にわたしたちはすでに
C++ の入力を C へと変換してからわたしたちのC コンパイラーで実行ファイルを生成する
ような C++ "プリプロセッサー" コンパイラーをいくつか使っていました。
しかし1992年のはじめ、Microsoft の premier native compiler は直接 C++ をサポートしました
#has done so ever since って･･･そうだっけ?
#英文の意味を取り違えてるか

C/C++ 7.0 shipped in a box that was over two feet long and produced MS-DOS, Windows
and OS/2 applications. It also sported the last of the character oriented development
environments for C that we ever shipped – the following product was Visual C++, which
built on what we had learned from delivering QuickC. Since those early days, we have
shipped eleven major releases of C/C++ products (ignoring small point upgrades) for
both Windows and embedded development.

C/C++ 7.0 は2フィートを超える長さの箱に詰められて出荷されており、
MS-DOS、Windows、OS/2 のアプリケーションを生成するものでした。
このコンパイラーはまた、わたしたちが出荷した最後の character oriented な  C 向け開発環境
でした。このあとの製品は Visual C++ で、これはわたしたちが QuickC の delivering から

そういった時代から始めて、わたしたちは11個の major リリースを
Windows 環境向けおよび組み込み環境向けの C/C++ 製品で行ってきました
(小さなアップグレードは無視しています)。

(略)

    © 2012 Microsoft Corporation.


しかし「20年前」が「1992年」という事実に改めてショックを受けた(謎)

#### ■_ Betrayed by a bitfield (ビットフィールドの裏切り?)

コメント欄がだいぶ賑やか

Betrayed by a bitfield [LWN.net]

Betrayed by a bitfield
By Jonathan Corbet

February 1, 2012

Developers tend to fear compiler bugs, and for good reason: such bugs can be hard to find
and hard to work around. They can leave traps in a compiled program that spring on users
at bad times. Things can get even worse if one person's compiler bug is seen by the
compiler's developer as a feature - such issues have a tendency to never get fixed. It is
possible that just this kind of feature has turned up in GCC, with unknown impact on the
kernel.

developer はコンパイラーのバグを恐れる傾向があって、それには理由があります:
そういったバグは見つけるのが難しく、回避するのも難しいからです。
developer はコンパイル済みのプログラムにある罠を放置できます
#that 以下のこれなに…
ある人にとってのコンパイラーバグが、コンパイラーの開発者によって機能だとみなされた
りすると事態はさらに悪化します。そういったものは決して修正されない傾向があるのです。

One of the many structures used by the btrfs filesystem, defined in fs/btrfs/ctree.h, is:

struct btrfs_block_rsv {
u64 size;
u64 reserved;
struct btrfs_space_info *space_info;
spinlock_t lock;
unsigned int full:1;
};

Jan Kara recently reported that, on the ia64 architecture, the lock field was occasionally
becoming corrupted. Some investigation revealed that GCC was doing a surprising thing when
the bitfield full is changed: it generates a 64-bit read-modify-write cycle that reads both
lock and full, modifies full, then writes both fields back to memory. If lock had been
modified by another processor during this operation, that modification will be lost when
lock is written back. The chances of good things resulting from this sequence of events are
quite small.

Jan Kara は最近 ia64 アーキテクチャ上においてこの lock フィールドがときおりおかしくなる
(corrupted) ことを報告しました。多少の調査の結果、GCC がビットフィールド full が変更された
ときにおかしな振る舞いをしていることがわかりました。

One can imagine that quite a bit of work was required to track down this particular surprise.
It is also not hard to imagine the dismay that results from a conversation like this:

I've raised the issue with our GCC guys and they said to me that: "C does not provide
such guarantee, nor can you reliably lock different structure fields with different locks
if they share naturally aligned word-size memory regions. The C++11 memory model would
guarantee this, but that's not implemented nor do you build the kernel with a C++11 compiler."

Unsurprisingly, Linus was less than impressed by this response. Language standards are
not written for the unique needs of kernels, he said, and can never "guarantee"
the behavior that a kernel needs:

#Linus のおことば
#言語の標準というものはカーネルのためだけに作られたものじゃないし
#カーネルが必要とする振る舞いを“保証”することはできない
# でいいのかな

So C/gcc has never "promised" anything in that sense, and we've always had to
make assumptions about what is reasonable code generation. Most of the time, our assumptions
are correct, simply because it would be *stupid* for a C compiler to do anything but what
we assume it does.

But sometimes compilers do stupid things. Using 8-byte accesses to a 4-byte entity is
*stupid*, when it's not even faster, and when the base type has been specified to be 4 bytes!

しかし時としてコンパイラーがばかげた動作をすることがあります。
そうすることでそれほど速くならないときや
その base type が4バイトであることを指定しているときに
4バイト長のエンティティのために 8バイト長のアクセスをすることは *馬鹿げています*。

As it happens, the problem is a bit worse than non-specified behavior. Linus suggested
running a test with a structure like:

Linus は次のような構造体を使ったテストの実行を提案しました

struct example {
volatile int a;
int b:1;
};

In this case, if an assignment to b causes a write to a, the behavior is clearly buggy:
the volatile keyword makes it explicit that a may be accessed from elsewhere. Jiri Kosina
gave it a try and reported that GCC is still generating 64-bit operations in this case.
So, while the original problem is technically compliant behavior, it almost certainly
results from the same decision-making that makes the second example go wrong.

この場合、b に対する代入で a に対して書き込みが行われるとその動作は明らかにバグです。
volatile キーワードはどこからでもアクセスされる可能性があることを明示します。
Jiri Kosina はこれを試し、これに引っかかるような 64ビットオペレーションをGCCが

Knowing that may give the kernel community more ammunition to flame the GCC developers
with, but it is not necessarily all that helpful. Regardless of the source of the
problem, this behavior exists in versions of the compiler that, almost certainly, are
being used outside of the development community to build the kernel. So some sort of
workaround is likely to be necessary even if GCC's behavior is fixed. That could be a
bit of a challenge; auditing the entire kernel for 32-bit-wide bitfield variables in
structures that may be accessed concurrently will not be a small job. But, then,
nobody said that kernel development was easy.


Linux is a registered trademark of Linus Torvalds


#### ■_ Zen プログラマーの十個のルール

The 10 rules of a Zen programmer « Grobmeier on Dart, Java, Struts, PHP and more

The 10 rules of a Zen programmer

On a rainy morning I found myself sitting on the desk thinking about efficient working.
Before I started as a freelancer I had some days were I worked lots but could look
only back on a worse outcome.

I started with Zen practice back in 2006. What clearly came to my mind before a good
while was: the old Zenmasters alredy knew before hundreds of years, how today
programmers should work. Even when I don't like these “be a better programmer” posts,
I want to outline some of my thoughts from that morning. It shall serve me as a
reminder, but if you have some ideas about it, feel free to comment.

1. Focus (集中する)

If you have decided to work on a task, do it as good as you can.
(略)

2. Keep your mind clean (心をクリーンに保つ)

Before you work on your software, you need to clean up your memory.
(略)

3. Beginners mind. (初心者の視点を忘れない)

Remember the days were you were a beginner. Or memorize, if you still are one.
(略)

4. No Ego. (自儘に振舞わない)

Some programmers have a huge problem: their own ego. But there is no time for developing an
ego. There is no time for being a rockstar.
(略)

5. There is no career goal. (キャリアに終わりはない)

lost the game. Just act as good as you can, without looking at the goal you might
reach after a long time.

(略)

6. Shut up. (黙る)

If you don't have anything to say, don't waste the time of your colleagues.
(略)

7. Mindfulness. Care. Awareness.

Yes you are working. But at the same time you are living and breathing.
(略)

8. There is no Boss (ボスはいない)

Yes, there is somebody who pays you. There is somebody who tells you what needs to be
done. And he can fire you. But this is no reason to give up your own life or to become
sick of your work. Finally your Boss has no control about you. It can even be doubted
that you have control about you – but don't lets go down this path.

(略)

9. Do something else (ほかのことをする)

A programmer is more than a programmer. You should do something which has nothing to
do with computers. In your primetime, go sailing, fishing, diving. Do meditation,
martial arts or play Shakuhachi.
(略)

10. There is nothing special. (特別なものはない)

A flower is beauty. But it's just a beauty flower – nothing more. There is nothing special
around it. You are a human who can program. Maybe you are good. There is nothing special
around you. You are of the same kind as I am or all the others on this planet.

(略)

Disclaimer (おことわり)

I am not a Zen monk. I am just practicing and learning. Please ask your local Zen monk
if you feel there is something you need to understand deeper. Of course I can try to
comment and if you would send a tweet with this pages url if you liked this post.

Posted on Friday, February 3rd, 2012 at 8:52 pm


ちと意訳に過ぎたかも＞見出し

#### ■_ LL.next

fogus: Where is LL.next?
Where is LL.next?
Feb 10, 2012

Some time in late 2001 MIT held an event called the Lightweight Languages Workshop or LL1 for
short. While I'm certain the event itself was influential to those in attendance, the truly
magnificent byproduct of the workshop was the associated LL1 mailing list. Scanning down the
messages to that mailing list reads like a roster for the programming languages hall of fame.
The topics on display, from historical recollections to bleeding edge to wholly new topics
(that we've yet to catch on to in many cases), are of a ridiculously high quality that almost
any random thread puts every current outlet of rampant opinion to shame.

2001年の終わりごろ、MIT で Lightweight Languages Workshop 、短い名称では LL1 と

#でそのイベント(ワークショップ)は影響力があって云々
#ワークショップに関してメーリングリストがあって

And that's a problem. There is a true gap in the computing ecosystem since the LL1 mailing
list went silent. Certainly there are other important mailing lists and message boards in
operation today, including Fundamentals of New Computing, Squeak-dev, and (at times)
Lambda The Ultimate, but none of them have the same mix of breadth of conversation and tone
of respectfulness of LL1.

そしてそれが問題なのです。
LL1 メーリングリストが沈黙してからの computing ecosystem には true gap が存在しています。

Fundamentals of New Computing, Squeak-dev, Lambda The Ultimate のような
メッセージボードもありはします。しかしそのどれひとつとして
the same mix of breadth of conversation and tone of respectfulness of LL1
というものを持っていないのです。

The world needs a new LL1. But it's not as simple as just putting together a mailing list
and calling it LL.next. Any LL.next mailing list would need most (if not all) of the
following to garner even a hint of the magic in the old:

しかしそれはただ単にひとつのメーリングリストに集めてそれを LL.next と呼べばよい
という単純なものではありません。すべの LL.next メーリングリストは

hint of the magic in the old (旧世界の魔法のヒント?) でさえも

Supplemented with a bevy of open-minded and respectful enthusiasts

A general desire to push the collective envelope as opposed to individual agenda

Thoughtfulness

An enthusiasm for the new, with a deference to the past

No sacred cows

Invite only (maybe — depending on the following)

Fair but firm moderation

A clear focus on the goals of said list

Where is this LL1.next, and who are the right people to get it started?



くー微妙に訳しにくいぞ(わたしの実力では) ＞項目

### 2012年02月09日

モーニング買うの忘れていたw

#### ■_ I

メールで書き込み主に教えてもらいました。 長年(おおげさ)の疑問がついにっ

くだすれFORTRAN（超初心者用）その5 [chaika]

818 デフォルトの名無しさん [sage] 2012/02/08(水) 19:16:27.77 ID: Be:
FORTRANで整数変数の暗黙宣言がI～Nになっていることの根拠を知りたいと
いう人がいた気がするが、まだ解決していないなら朕がその謎を解いてやろう。

John Backus 本人がそのものずばりを質疑で答えている。
ちなみに質問は会場の爆笑を誘っているｗ
J.A.N. Lee. Transcript of question and answer session: "The History of Fortran I, II, and III".
In in: R. Wexelblat, editor. History of Programming Languages, ACM Monograph Series, Academic Press, 1981, pages 68-71.

http://www.softwarepreservation.org/projects/FORTRAN/paper/p68-lee.pdf

LEE: Helen Gigley asks: "Why were the letters I through N chosen to designate integers?"
[Laughter and applause]

BACKUS: Well, it just seemed for a while that people always used I, J, and K for subscripts,
and we thought we'd be generous and add a few more.

ようするに適当ｗ
まぁ数学では記法としてΣ_i^Nとかが一般的で、添え字にO以降は使われないから、
I～Nまでを整数とするのは適切な気がする。

819 デフォルトの名無しさん [sage] 2012/02/08(水) 19:19:26.81 ID: Be:
ついでに言うと、伝説と異なりFORTRAN I で配列のRankが3以下に制限されたのは
インデックス・レジスタが３個しかないせいではないとも言明している。


いや実にすっきりしました。 ゆっくり眠れます :)

#### ■_ Vim anti-patterns

よーするにカーソル移動やらを「最適化」せいと

Vim anti-patterns | Arabesque

Vim anti-patterns

Posted on February 7, 2012

The benefits of getting to grips with Vim are immense in terms of editing speed and
maintaining your “flow” when you're on a roll, whether writing code, poetry, or
prose, but because the learning curve is so steep for a text editor, it's very easy to
retain habits from your time learning the editor that stick with you well into mastery.
Because Vim makes you so fast and fluent, it's especially hard to root these out
because you might not even notice them, but it's worth it. Here I'll list some of the
more common ones.

Moving one line at a time

If you have to move more than a couple of lines, moving one line at a time by holding
down j or k is inefficient. There are many more ways to move vertically in Vim. I find
that the two most useful are moving by paragraph and by screenful, but this depends on
how far and how precisely you have to move.

{ — Move to start of previous paragraph or code block.
} — Move to end of next paragraph or code block.
Ctrl+F — Move forward one screenful.
Ctrl+B — Move backward one screenful.

(以下略)



#### ■_

IT Software Community - John W. Verity - LISP Is Back, and It's Baaaaad!

LISP Is Back, and It's Baaaaad!
John W. Verity, Editor in Chief, 1/25/2012

Functional programming, as embodied in a new version of LISP, is finding growing use
across the mainstream, enterprise landscape.

In 1958, MIT computer scientist John McCarthy invented a new programming language
called LISP, and it changed the world of computing. From that moment on, this
"list processing language" has been the tool for exploring the frontiers of
computer science, for writing programs that were thought to be impractical or even
impossible.

In the early 1980s, LISP had a brief moment in the commercial spotlight when
artificial intelligence (AI) suddenly looked promising. Specialized computers were
created just to run LISP programs. But AI failed to deliver on its promises, the long
"AI winter" set in, and LISP slunk back to the research lab.

But now, it appears, LISP is back, reappearing on the commercial, enterprise stage and
making waves again. In particular, a new dialect called Clojure is tackling some of
the most demanding programming tasks faced by companies in industry after industry.
Startups and established enterprises alike are scrambling to hire from the growing
ranks of Clojurists. User groups are forming everywhere from Hamburg to Silicon Valley
and beyond.

(略)


IT Software Community - John W. Verity - LISP Is Back, and It's Baaaaad!

Re: Clojure resources

@jan: I've worked on Ruby extensively and each time I use it, I'm really impressed by
it's simplicity in design as well as ease of use. You have to give credit to the
Japanese for it.


Re: Clojure resources

But the Japanese could not have done it without some work by crafty Americans!



このコメント二つのやり取りがなぜかツボにはいった。

#### ■_ redditに訊け

Python プログラマーなんですが Ruby を始めたいのですけどなにかよい資料などは

I am a python programmer who needs to learn ruby. Any good resources or advice? : ruby

The languages are often compared so I am hoping my knowledge of python will make learning ruby
faster. Maybe the best method is just to read a ruby book and learn from scratch, I am not
sure yet how similar they are. However if anyone has made the switch and knows what a good
starting point would be or if there are resrouces geared toward switching I would apperciate

Edit: I will be using ruby as a scripting language. Mosly maintaing and updating existing
scripts that put together XML files used for input for other applications and things like
file management and such. So if there are resrouces geared towards scripting rather than
building ruby applications that would be helpful.


Ruby Koans



I can't say enough nice things about the koans approach. It's a really great way to learn all
the gotchas in a language. It shows you how things are done in a idiomatic way. And it's fun.



Here's a comparison of the languages, from a great Python programmer:

Also, here's the learn ruby from other languages page:
http://www.ruby-lang.org/en/documentation/ruby-from-other-languages/



Thanks!



### 2012年02月08日

#### ■_

O'Reilly Media - Tech Books, DRM-Free Ebooks, Videos なんか2冊買うと1冊無料でついてくるって話らしいんですが、 欲しいなあってのが Upcoming - O'Reilly Media の辺りにしかなかったりして。 ラクダ本マダー?

Upcoming - O'Reilly Media

Programming Perl, 4th Edition
By Tom Christiansen, brian d foy, Larry Wall, Jon Orwant
February 2012 (est.)
Ebook: $39.99 Pre-Order Print:$49.99


↓この辺も早く

Upcoming - O'Reilly Media

Code Simplicity
By Max Kanat-Alexander
February 2012 (est.)
Pre-Order Print: $24.99  Upcoming - O'Reilly Media Think Complexity By Allen B. Downey March 2012 (est.) Pre-Order Print:$29.99



おや、こんなのが。 Free as in Freedom [Paperback] - O'Reilly Media 確か自分が持っているのはハードカバーだったような (ろくに読んでなかったりする :)。

#### ■_ The History of Rubinius

Razzle Dazzle | 1: Origin Story | The History of Rubinius

The History of Rubinius
As Told by Its Creator
by Evan Phoenix

During the winter of 2006, I got interested in the implementation of the Smalltalk language.
Following discussion with Ryan Davis about Ruby and Smalltalk, I decided to order the Blue
Book from Powell's Books online. The Blue Book is the holy bible of Smalltalk, containing
not only a complete introduction to the language, but also a sample implementation of the
language itself in the last few chapters. The intention of these chapters was to provide
the interested reader some details into how Smalltalk works at the lowest level, so they
could use the language well. To my eyes though, it was like opening the face of a watch to
see the gears turning. It was amazing, and proved to be the initial spark of life for
Rubinius.

(以下略)


#### ■_

getaddrinfo() edge case behavior on Windows, Linux and OS X – klickverbot.at by David Nadlinger

getaddrinfo() edge case behavior on Windows, Linux and OS X

(略)

Host 	Port 	Flags 	Windows 	Linux 	OS X
null 	null 	- 	NONAME 	NONAME 	NONAME
AI_PASSIVE 	NONAME 	NONAME 	NONAME
"" 	- 	loopback 	loopback 	NONAME
AI_PASSIVE 	catchall 	catchall 	NONAME
"0" 	- 	loopback 	loopback 	loopback
AI_PASSIVE 	catchall 	catchall 	catchall
"80" 	- 	loopback 	loopback 	loopback
AI_PASSIVE 	catchall 	catchall 	catchall
"" 	null 	- 	public 	NONAME 	NONAME
AI_PASSIVE 	public 	NONAME 	NONAME
"" 	- 	public 	NONAME 	NONAME
AI_PASSIVE 	public 	NONAME 	NONAME
"0" 	- 	public 	NONAME 	loopback
AI_PASSIVE 	public 	NONAME 	catchall
"80" 	- 	public 	NONAME 	loopback
AI_PASSIVE 	public 	NONAME 	catchall
"localhost" 	null 	- 	loopback 	loopback (v4) 	loopback
AI_PASSIVE 	loopback 	loopback (v4) 	loopback
"" 	- 	loopback 	loopback (v4) 	loopback
AI_PASSIVE 	loopback 	loopback (v4) 	loopback
"0" 	- 	loopback 	loopback (v4) 	loopback
AI_PASSIVE 	loopback 	loopback (v4) 	loopback
"80" 	- 	loopback 	loopback (v4) 	loopback
AI_PASSIVE 	loopback 	loopback (v4) 	loopback
hostname 	null 	- 	public 	loopback (v4) 	public
AI_PASSIVE 	public 	loopback (v4) 	public
"" 	- 	public 	loopback (v4) 	public
AI_PASSIVE 	public 	loopback (v4) 	public
"0" 	- 	public 	loopback (v4) 	public
AI_PASSIVE 	public 	loopback (v4) 	public
"80" 	- 	public 	loopback (v4) 	public
AI_PASSIVE 	public 	loopback (v4) 	public

getaddrinfo() behavior on Windows Server 2008 R2, Arch Linux (Kernel 3.1.4, glibc 2.14.1), and OS X 10.7.2 (Lion).



#### ■_

reddit で500overの反応があった記事

Dear Boss: For a programmer, 10 minutes = 3 hours - edw519

Dear Boss: For a programmer, 10 minutes = 3 hours

10:48

Boss: Hey Ed, Sue in Detroit says that sometimes, the wrong Invoice Part Number is showing
up on the Product History Screen. Can you help us figure this out.

Ed: I'm busy with something else at the moment. Put the ticket in my queue.

Boss: This will only take 10 minutes.

Ed: Are you sure about that?

Boss: Yes. I'll just set up a web conference. Sue can show you right away, then you can
look into it when you have time.

Ed: OK.

Boss: Great. Check your Outlook for an invite.

(略)

1:48

Boss: OK, this sounds like a problem. It looks like I'll have to escalate this to the

(Ed continues to read Hacker News in another tab.)



ちゃんちゃん。 詳しい顛末は元記事をどうぞ

Dear Boss: For a programmer, 10 minutes = 3 hours : programming

Crucially, when the boss first says "This will only take 10 minutes", he
means 10 minutes of his time, not yours


"This is just a simple feature to add in; we're only changing 3 fields. Shouldn't
take more than 30 minutes."

... and running items on a 3rd party database with no API provided, changing the data
that is being sent, and turning that into 3 service calls instead of 1, to "speed
things up a bit".

2 hours later: "Why isn't this done yet?! Don't bill for more than 30 minutes; I
already told the client that's how long it would take."


My running joke at work when someone asks how long it would take to get a minor change done.

1 minute to make the change
1 hour to test
1 day to get it into QC
1 week to get someone to sign off on UAT
1 month to get someone to sign off on PROD

An exaggeration that isn't too far off from reality.



#### ■_ こーどれびゅー

こういうのは全文きっちりやったのほうが良いのかな

ShipSolid - Software Consulting

You Need a Code Review (あなたにはコードレビューが必要だ)

Alex Bartlow

2012-02-05

On many of my projects, I have the pleasure of working with a team of highly skilled
developers and designers to deliver a working, finished application. Many of these
developers are shocked when I often ask for code reviews, or use a pull-request on
github to deliver a feature, instead of just pushing it into master. It seems that I'm
regarded as a senior developer, that should be above such formalities that prevent
junior developers from making a build-breaking change, and as such, I should resent
the idea of someone else auditing my changes.

I don't resent it. I need it. I need a code review, on every significant commit.


• Code Reviews Create Quality
• Code Reviews Prevent Mistakes
• Code Reviews Transfer Knowledge
• Code Reviews Teach

#### ■_ 温故知新

なんか動く処理系があるっぽいのでやってみようかという気になりつつある

#### ■_

Twitter / @y_shindoh: grep vs. Awk: http://t.co/ ...

grep vs. Awk: quruli.ivory.ne.jp/diary/?date=20… 「GNU grepよりGNU Awkの方が速い!」
という噂を聞いて試してみた。 ちなみに、この結果と正反対の結果が手元のGnuWin32環境では出
たので、環境によってかなり違うと見た方が良さそうだ。


バージョンによって正規表現ライブラリが入れ替わったり(grep)、 インタープリターがバイトコード形式になったり(gawk)で その辺の条件を明確にしないと同じ比較ができないような。

#### ■_ 百万の

Clang: Defending C++ from Murphy's Million Monkeys | GoingNative 2012 | Channel 9 Clang: Defending C++ from Murphy's Million Monkeys : programming Murphy's とあるのは何か深い意味があるんだろうか それはともかく、音声のみのダウンロードもできるっぽいのでそれを聴いてみよう。 初日のキーノートやらも含めると聴くための時間がとんでもなくかかるけど。

Clang: Defending C++ from Murphy's Million Monkeys | GoingNative 2012 | Channel 9

Were we to craft a Lenox Globe of programming languages, C++ might be followed by a famous
cautionary phrase: Here Be Dragons. The language can be complex and daunting to programmers
who are often shouldered with the task of writing large, complex programs. Those millions of
code monkeys need help to resist Murphy's siren song and navigate C++'s treacherous waters
of memory corruption and concurrency bugs.

(略)


code monkey と Murphy's siren song やらからでてきたのかな＞百万匹の猿

Day 1 Keynote - Bjarne Stroustrup: C++11 Style | GoingNative 2012 | Channel 9

We know how to write bad code: litter our programs with casts, macros, pointers, naked new
and deletes, and complicated control structures. Alternatively (or additionally), we could
obscure every design decision in a mess of deeply nested abstractions using the latest
object-oriented programming and generic programming tricks. Then, for good measure, we
might complicate our algorithms with interesting special cases. Such code is
incomprehensible, unmaintainable, usually inefficient, and not uncommon.



### 2012年02月07日

#### ■_ 配列(リスト)の添字

PowerShell でリストスライスを取り出そうと $ary[5..-1] として予想外の動作をしてびびる。 Ruby、Python もこれとそれぞれ違って混乱したり。 どれがいい、他はだめということではないのだけど悩みの種ではある (複数使うほうが悪い?) PS >$ary="a b cd e f g".split(" ")
PS > $ary a b c d e f g PS >$ary[0..7]
a
b
c
d
e
f
g
PS > $ary[4..7] e f g PS >$ary[-4..-1]

d
e
f
g
PS > \$ary[4..-1]
e
d
c
b
a
g


PS > 4..-1
4
3
2
1
0
-1
PS > -4..-1
-4
-3
-2
-1

#### ■_ "Programmer" is an Overgeneralization

Erik McClure: "Programmer" is an Overgeneralization

February 5, 2012
"Programmer" is an Overgeneralization

"Beware of bugs in the above code; I have only proved it correct, not tried it." - Donald Knuth

Earlier today, I came across a post during a google-fu session that claimed that no one
should use the C++ standard library function make_heap, because almost nobody uses it
correctly. I immediately started mentally ranting about how utterly ridiculous this claim
is, because anyone whose gone to a basic algorithm class would know how to properly use
make_heap. Then I started thinking about all the programmers who don't know what a heap
is, and furthermore probably don't even need to know.

post しました。
basic algorithm class を理解しているような人であれば make_heap の適切な使い方を

mentally ranting しました。
それからわたしは、ヒープがなんであるかも知らず、
それが何のためにあるのかすらも知らないであろう
プログラマーすべてについて考えはじめました。

Then I realized that both of these groups are still called programmers.

そうして、プログラマーにはそういった二つのグループがあるのだということを認識するにいたりました。


Copyright ©2011 Erik McClure. Powered by Blogger.



#### ■_

Four Levels of Idea Theft

Four Levels of Idea Theft
アイデアの剽窃の4レベル

Imagine you've just seen a tremendously exciting piece of software--a mobile app, a
web app, a game--and your immediate reaction is "Why didn't I think of
that?!" With your mind full of new possibilities, you start on a project, a
project enabled by exposure to the exciting software. What happens next is up to you.
How far do you let your newfound motivation take you?


Borrowing specific features.

General inspiration.

Using the existing product as a template.

Wholesale borrowing of the design.



### 2012年02月06日

#### ■_

Amazon さんから Kindle touch 買わない? と販促メールが

#### ■_

Why I love Common Lisp and hate Java, part II – code examples « Piece of mine

Why I love Common Lisp and hate Java, part II – code examples

Writing programs that write programs.This is a sequel to my previous post where I urged
those who gave up on programming — probably because of the spoon-fed association with Java
and stress — to give coding another chance with a whole “new” (read: different) approach:
Common Lisp. The purpose of this sequel is to address the open-minded skeptic, unconvinced
yet unafraid of paradigm-shifting change. Common Lisp is not just another language, it is a
different way of coding.

While I tried to make a point that the REPL completely alters the experience of coding
— which can only be experienced and not by reading a blog post — this time I will try
to showcase Common Lisp's powerful meta-programming through some example code.

Writing programs to write programs is mind-boggling if you come from the imperative world
of Java. Simply because it is not possible in Java, therefore not taught, hence not even
considered as a powerful way of abstraction and code reduction. We write methods and
functions to abstract away reoccurring computational patterns. Why not write functions
that take the abstraction level even higher and abstract away coding patterns?

(以下略)



#### ■_

Cocoa での hello, world 的プログラムってどんなんだろうと疑問に思いつつちと調べた。 Windows、昔の Mac OS のように自分でディスパッチするのではないのね。 X のメッセージはどう処理してたっけ?

### 2012年02月05日

#### ■_

アレやらアレは文庫化されるんだろか。

#### ■_ 丸め

を丸投げ。 洒落になっとらんな。

javaでの金額の丸めについて（至急、お願いします | OKWave

javaでの金額の丸めについて（至急、お願いします

わかりませんでした。教えていただけないでしょうか。

100円単位の切捨て、切上げ、四捨五入
1000円単位の切捨て、切上げ、四捨五入

どなたかご教授願います。


ANo.2

class Q7283233 {
public static void main(String[] args) {
int c = 100;

int n = 113;
System.out.println((int)Math.floor((double)n / c) * c);
System.out.println(Math.round((double)n / c) * c);
System.out.println((int)Math.ceil((double)n / c) * c);

n = 355;
System.out.println((int)Math.floor((double)n / c) * c);
System.out.println(Math.round((double)n / c) * c);
System.out.println((int)Math.ceil((double)n / c) * c);

n = -113;
System.out.println((int)-Math.floor((double)-n / c) * c);
System.out.println(-Math.round((double)-n / c) * c);
System.out.println((int)-Math.ceil((double)-n / c) * c);

n = -355;
System.out.println((int)-Math.floor((double)-n / c) * c);
System.out.println(-Math.round((double)-n / c) * c);
System.out.println((int)-Math.ceil((double)-n / c) * c);
}
}

ANo.1

100円単位なら、元の金額を100.0で割ってから切り捨て・切り上げ・四捨五入の操作を行い、その結果を100.0倍する。



この回答者さんたちはわかってて質問者をからかっているのかそれとも(ry

#### ■_ 翻訳むずい

ジャック・キャンベル ～彷徨える艦隊～ 2番艦c

623 名無しは無慈悲な夜の女王 [sage] 2012/01/09(月) 02:28:08.28 ID: Be:
７巻表紙の女性は誰？
デシャーニ大佐だよね？
副題がドレッドノートだからジェーン・ギアリー大佐？

624 名無しは無慈悲な夜の女王 [sage] 2012/01/11(水) 13:22:58.35 ID: Be:
ドーントレス以外だと作中の活躍とリンクしてない名前だよね
ヴィクトリアスってなんかやったっけ

625 名無しは無慈悲な夜の女王 [] 2012/01/12(木) 15:39:15.58 ID: Be:
日尼見ると、8巻のハードカバーとペーパーバックが同じ月に出ることになってるがおかしいな。

翻訳の質はともかく、刊行中のシリーズに追いつきピッタリマークしてるなんてなかなかないな。

626 名無しは無慈悲な夜の女王 [sage] 2012/01/12(木) 19:23:27.12 ID: Be:
>>624
戦艦の名前じゃなくてただの形容詞

627 名無しは無慈悲な夜の女王 [sage] 2012/01/13(金) 01:36:41.43 ID: Be:
>>626
何が形容詞だって？

彷徨える艦隊　旗艦ドーントレス
彷徨える艦隊　２　特務戦隊フュリアス
彷徨える艦隊　３　巡航戦艦カレイジャス
彷徨える艦隊　４　巡航戦艦ヴァリアント
彷徨える艦隊　５　戦艦リレントレス
彷徨える艦隊　６　巡航戦艦ヴィクトリアス
彷徨える艦隊　７　戦艦ドレッドノート

628 名無しは無慈悲な夜の女王 [sage] 2012/01/13(金) 01:59:52.75 ID: Be:
帰還によって初期の目標を達成し勝利を得たではないか。
艦名とその意味を掛けてるんじゃない？と思うのだが。

1.Dauntless　　不屈の
2.Furious　　　　怒り狂った
3.Courageous　勇敢な
4.Valiant　　　　 雄々しい
5.Relentless　　冷酷な
6.Victorious　　勝利を得た

629 名無しは無慈悲な夜の女王 [sage] 2012/01/13(金) 03:26:47.16 ID: Be:
>>628
いや、そうじゃなくて >>626 は、
>戦艦の名前じゃなくてただの形容詞
と言った

630 626 [sage] 2012/01/13(金) 04:16:59.38 ID: Be:
形容詞だろ
戦艦の名前とかけてるけどそれ自体はただの形容詞だろ

631 名無しは無慈悲な夜の女王 [sage] 2012/01/13(金) 06:18:27.32 ID: Be:
>>627
原書のサブタイには「旗艦」だの「特務戦隊」だの「戦艦」だのといった単語は付いてません
日本語版のタイトル付けた奴のチョンボ

632 名無しは無慈悲な夜の女王 [sage] 2012/01/13(金) 08:35:51.55 ID: Be:
「戦艦の名前とかけてる」のはみな理解してる。
>>624 がいってるのは、
「ドーントレス以外だと作中の活躍とリンクしてない」

活躍じゃないけど撃沈されたのはあったと思う。

635 名無しは無慈悲な夜の女王 [sage] 2012/01/13(金) 22:33:50.60 ID: Be:
まぁ軍艦の名前ってのは最重要な要素だと思うが、
本の内容と関わってるのはその意味の方だ罠
原書は読んだことないので俺には分からんけど、艦名の冠にH.M.Sみたいなのが付いてたら
副題はもう純粋に形容詞だがｗ

636 名無しは無慈悲な夜の女王 [sage] 2012/01/13(金) 22:37:30.20 ID: Be:
書き込んでから気付いたが、theが付いてないから形容詞の方が主か

637 名無しは無慈悲な夜の女王 [sage] 2012/01/14(土) 00:42:41.95 ID: Be:
>>628
故郷への生還で始まり凱旋で終わる第６巻に「Victorious」とつけるあたり、
作中での艦の活躍よりは「形容詞」重視っぽいね。

638 名無しは無慈悲な夜の女王 [] 2012/01/14(土) 05:37:30.61 ID: Be:
普通にストーリー上のタイトルロールの艦と形容詞的用法上のダブルミーニングを狙ってるんだろ。
タイトルロールの艦の活躍がちょびっとorほぼ見当たらない巻もあるし、
それほど各巻ごとに大きな変化があるストーリーでもないけど。

さて、これから巻名になりそうな艦名を拾ってみると
Vengeance　復讐
Vanguard　前衛
Revenge　復讐
Triumph　勝利

次点で
Majestic　堂々とした
Brilliant　光り輝く

こりゃなんじゃ？
Intemperate　不摂生な

642 名無しは無慈悲な夜の女王 [] 2012/01/14(土) 13:29:57.81 ID: Be:
>638
やり過ぎ、の方が良いかも。
呑んだくれって意味の方も捨てがたいがｗ

異星人の脅威が明らかになると
Redoubtable　恐るべき
とか

最終巻は
Glorious　栄光ある
だろうなぁ

781 名無しは無慈悲な夜の女王 [] 2012/02/01(水) 13:11:25.95 ID: Be:
ついでに

艦隊が与えた損害をギアリーが見積もらなければならないが、今の時点では大虐殺としかいいようがない。

now he had to figure out how much damage they had done. All he could tell at the moment was that the damage hadn't been the massacre it might have been.

翻訳の無免許運転としか言いようがない。

782 名無しは無慈悲な夜の女王 [] 2012/02/01(水) 13:44:58.81 ID: Be:
逆だね。

789 772 [sage] 2012/02/01(水) 17:02:38.63 ID: Be:
>>781
そこも「？」と思ったところだった。
大した損害がないのに“大虐殺”とはこれ如何にと・・・

>>778兄，>>779兄のおかげでスッキリしたよ。

790 777 [sage] 2012/02/01(水) 20:36:13.73 ID: Be:
やっぱり誤訳かよ！
チェック体制とかどうなってんだ……返金ものだろ……

791 名無しは無慈悲な夜の女王 [] 2012/02/01(水) 20:54:33.96 ID: Be:
景気悪い
->出版社: 経費節減
->翻訳のチェック無し(翻訳者まかせ)
翻訳料も下げ
->翻訳者: 見直し最低限(細かいことやっとれん、出版社でやれよ)
下訳料金も下げ(or 翻訳ソフトでもいいか)
->下訳者: 雑でもいいな(金に見合うし)、
ついでに間違いも入れといたろ

まさか、こんなじゃないだろうな...



#### ■_ Sorting algorithms used in the CL implementations

Sorting algorithms used in the CL implementations « Jorge Tavares weblog

Sorting algorithms used in the CL implementations

(略)

What sorting algorithms do the major open source CL implementations actually implement?
I was curious about it and went to check the source for ABCL, CCL, CLISP, CMUCL, ECL and
SBCL. Not surprising, we find some differences between the implementations. What it was
more unexpected to discover is that some implementations also use different sorting
algorithms according to the sequence type. A quick survey of the findings is summarized
in the following table (if anythings is incorrect, please tell me). The links for the
source code are in the implementation name (careful, in CCL and SBCL there are two links).

Implementation         sort         stable-sort
ABCL         merge sort (lists) / quicksort         merge sort
CCL         merge sort (lists) / quicksort         merge sort
CLISP         tree sort         tree sort
CMUCL         heapsort         merge sort
ECL         merge sort (lists) / quicksort         quicksort (strings + bit vectors) / merge sort
SBCL         merge sort (lists) / heapsort         merge sort

In terms of the implementation of sort, quicksort is the most used algorithm, followed by
heapsort. The choice for these algorithms is expected. Both have an average-case
performance of O(nlgn) and heapsort guarantees a worst-case performace of O(nlgn) too.
Quicksort has a worst-case performance of O(n2) but it can be optimized in several ways
so that it also gives an expected worst-case performance of O(nlgn). However, it seems
that the quicksort implementations are not completely optimized. In ECL (and ABCL)
quicksort implements a partition scheme which deals better with duplicate elements
(although is not the three-way partitioning) but it always picks as pivot the first
element. CCL chooses the pivot with a median-of-3 method and always sorts the smaller
partition to ensure a worst-case stack depth of O(lgn).

(略)


#### ■_ LANG=

わたなべさんのところから辿った元記事。 Re: テキストファイルをソートするときに頻繁に使うUnixコマンド - jarp,[O] テキストファイルをソートするときに頻繁に使うUnixコマンド で、 sort するときは LC_ALL=C sort を使わないと、環境によって結果が変わってしまう場合があるし、一定量以上のファイルをsortする際には、sort処理自体の速度もLC_ALL=Cありの方が速いです。 locale が C でない場合に処理速度ががた落ちになってしまうというのはおいといて (ありゃあ実装が以下略なところもあるような気がしないでもない。 といってきちんとしたコードを書くのも大変だろうなあ)、 sort するのに collating order 無視というのはどうなんだろうねえ。 まあ、基本的に文字コード順で不自由ないんだろうけど。

LC_ALL. LANG, LC_COLLATE その他の役割(とか影響範囲)ってあまり理解されてない? いやまあメッセージ出力のエンコーディングがどうこうはわかってるんだろうけど。

### 2012年02月04日

#### ■_

codermetrics

んで、裏表紙にはこういう一文が Codermetrics is the Moneyball for software teams. Who would have thought that sports and software development had so much in common? The book is purposeful and thought-provoking -- a great read for any software team participant.

#### ■_ チャート

これは自分も疑問に思ったことがあるんですが、なんでなんでしょうね。

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

868 デフォルトの名無しさん [sage] 2012/02/04(土) 09:01:26.61 ID: Be:
何で日本はチャートの事をグラフって教えるんだろうか。

869 デフォルトの名無しさん [sage] 2012/02/04(土) 09:02:46.27 ID: Be:
図のことをフィギュアとは言わないなあ。

870 デフォルトの名無しさん [sage] 2012/02/04(土) 09:41:08.80 ID: Be:
マならチャートとフィギュアを使うのは当然だよな。
グラフなんて言ったら紛らわしいし。



#### ■_ 丸投げ

C言語での桁落ちの以下のプログラムを教えてください | OKWave

C言語での桁落ちの以下のプログラムを教えてください

C言語の本の問題で答えが書いてなく困っております。

f(x)=xの5乗-ルート（1+xの10乗)+1/{2×ルート（1+xの１０乗）}の式が与えられ

ｘ＝0,1,2・・・50 における f(x) の値を求める場合のプログラムを教えてください。





補足

C言語での桁落ち：：：　f(x)=xの5乗-ルート（1+xの10乗)+1/{2×ルート（1+xの１０乗）}の式
が与えられていてｘ＝0,1,2・・・50 における f(x)のプログラムです。


> fx <- function(x){x**5 - sqrt(1+x**10) + 1/(2*sqrt(1+x**10))}
> fx(1:50)
[1] -6.066017e-02 -3.810975e-06 -8.711305e-09 -1.164152e-10 -4.150059e-12 -4.044512e-13 -7.689121e-13
[8] -7.105427e-15  2.710343e-12  5.583029e-12  1.370892e-11  1.197672e-12  1.113648e-11 -2.059970e-11
[15] -8.846262e-12 -2.168404e-19  1.082057e-10  1.151358e-10 -1.664620e-10 -2.121925e-10 -4.295505e-11
[22]  1.614090e-10  3.840912e-10  3.947581e-10  9.085810e-10 -7.581706e-10 -5.443981e-10 -7.500674e-10
[29] -1.700046e-09 -1.775610e-09 -1.161735e-09 -6.617445e-24 -2.125002e-09  3.554049e-09  2.069262e-09
[36]  8.185052e-10  7.210434e-09  6.310329e-09  5.541751e-09  4.882813e-09  4.315695e-09  3.825811e-09
[43]  3.401165e-09  3.031842e-09  2.709614e-09  2.427621e-09  2.180122e-09  1.962293e-09  1.770067e-09
[50]  1.600000e-09
> gx <- function(x){1/(2*sqrt(1+x**10))-sqrt(1+x**10)+x**5}
> gx(1:50)
[1] -6.066017e-02 -3.810975e-06 -8.711311e-09 -1.164153e-10 -4.092726e-12  0.000000e+00  0.000000e+00
[8]  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00
[15]  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00
[22]  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00
[29]  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00
[36]  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00
[43]  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00
[50]  0.000000e+00
> (function(x){1/(2*sqrt(1+x**10)) - sqrt(1+x**10) + x**5})(1:20)
[1] -6.066017e-02 -3.810975e-06 -8.711311e-09 -1.164153e-10 -4.092726e-12  0.000000e+00  0.000000e+00
[8]  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00
[15]  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00


#### ■_ 生産性が十倍ならば

その話題の元

10x Productivity Myths: Where's the 10x Difference in Compensation? - 10x Software Development

10x Productivity Myths: Where's the 10x Difference in Compensation?

In response to my recent blog post on the research support for 10x productivity differences
among programmers, Pete McBreen made the following comment:

"One point in his article that McConnell did not address--programmer compensation
does not vary accordingly. This is a telling point--if the difference is productivity
can be 10X, why is it that salaries rarely fall outside the 2X range for experienced
developers?" [emphasis in original]

This is a good question. It's timely because the Software Engineering Productivity group
on LinkedIn has recently had a 130-comment discussion on the question of “Should pay be
tied directly to productivity?” It's also a question that I wrestled with personally for
about the first 10 years of my career. Indeed, it's part of the original reason I decided
to became self employed back in 1989 and eventually founded my own company in 1996.

The Intuitive Version of the Question

I started my personal “10x compensation quest” from the point of view of, “I know
I'm 3-5x as productive as the guy sitting next to me. Why am I not making 3-5x as much
money?” Over a period of many years I found that this formulation of the question
embodied several assumptions that were naïve or just plain wrong from a business
perspective.

Six Myths of 10x Compensation

Let's look at each of these myths of 10x compensation.

Myth 1. The guy next to me is getting paid what he's worth.

Published Jan 22 2011, 05:42 PM by Steve McConnell


#### ■_ 問題

t1: Expressing integers using four nines :: Strangely Consistent

3 Feb, 2012
by Moritz Lenz

t1: Expressing integers using four nines

(This is a guest post by Moritz Lenz. If you're wondering what this is all about, it's
the aftermath of The 2011 Perl 6 Coding Contest. If you're not wondering, it's still

Let's consider the first task from the Perl 6 Coding Contest 2011.

Here is the description of the task once more:

What non-negative integers can you write as expressions containing exactly four occurrences
the number 9, and any of the binary operators *, /, %, +, -, prefix negations, and any
number of matching pairs of parentheses you care to use?

9 が四つと二項演算子 *, /, %, +, -、前置の negation、任意個のカッコ対を使った

#よくわからん

The program should accept an upper limit N as a command-line argument. It should then print
all integers 0..N in increasing order, along with an expression with four nines, if any
such was found.

この問題はコマンドライン引数として上限値 N を受理すべきである。
0 から N までのすべての4つの9で表現できる整数を昇順に出力する。
#でいいのかな

It was probably the easiest of all tasks, and the one we got the most submissions for. Yet
there were still some things that could go wrong, and some submissions got some of them wrong:

non-negative implies that we start at 0 = 9 + 9 - 9 - 9, not at 1
1 からではなく 0 から開始

integers means that the result must be an integer; it does not mean that intermediate
results are automatically rounded or truncated
結果は整数でなければならない。中間結果は自動的に丸められたり切りめられたりしない

the expressions must consist of four times the number 9, not the digit nine. Thus 99
is not a valid expression of two nines.

式では数字の 9 ではなく、数値の9 を4つ含んだものでなければならない。
したがって 99 は二つの9を使った vaild な式ではない



#### ■_

しかし池袋のジュンク堂、CS関連の洋書の棚をあそこまで削るとは… ○|￣|＿ 紀伊國屋書店も以前よりは面積減ってるしなあ。 どうすべえ。

### 2012年02月03日

#### ■_

カッコの対応をリアルタイムに強調表示やらしてくれるエディターってどれが最初?

#### ■_ ××戦略

評価戦略 - Wikipedia

を束縛する（通常、捕獲回避置換か新たなメモリ領域への値のコピーをする）。その関数が引数
となっている変数に値を代入しても、それは局所的なコピーへの代入であり、呼び出した側から

や Java）は値渡しの際に引数と左から右の順序で評価するが、中には右から左の順序で評価す
る場合もあり、言語によっては（Scheme、OCaml、C）順序を明示していない。

評価戦略 - Wikipedia

ンストラクタがある。C++でも参照は明示的に生成できる。これらの言語では、関数の引数とし
て値への参照を渡すことを参照渡しと呼ぶこともある。

と呼ぶこともある。


#### ■_

こっちが英語版。 訳はいいっすよね?w

Evaluation strategy - Wikipedia, the free encyclopedia

Call by value

Call-by-value evaluation (also referred to as pass-by-value) is the most common evaluation
strategy, used in languages as different as C and Scheme. In call-by-value, the argument
expression is evaluated, and the resulting value is bound to the corresponding variable in
the function (frequently by copying the value into a new memory region). If the function or
procedure is able to assign values to its parameters, only its local copy is assigned — that
is, anything passed into a function call is unchanged in the caller's scope when the
function returns.

Call-by-value is not a single evaluation strategy, but rather the family of evaluation
strategies in which a function's argument is evaluated before being passed to the function.
While many programming languages (such as Eiffel and Java) that use call-by-value evaluate
function arguments left-to-right, some evaluate functions and their arguments right-to-left,
and others (such as Scheme, OCaml and C) leave the order unspecified (though they generally
require implementations to be consistent).

In some cases, the term "call-by-value" is problematic, as the value which is passed
is not the value of the variable as understood by the ordinary meaning of value, but an
implementation-specific reference to the value. The description "call-by-value where
the value is a reference" is common (but should not be understood as being
call-by-reference); another term is call-by-sharing. Thus the behaviour of call-by-value
Java or Visual Basic and call-by-value C or Pascal are significantly different: in C or
Pascal, calling a function with a large structure as an argument will cause the entire
structure to be copied, potentially causing serious performance degradation, and mutations
to the structure are invisible to the caller. However, in Java or Visual Basic only the
reference to the structure is copied, which is fast, and mutations to the structure are
visible to the caller.


Evaluation strategy - Wikipedia, the free encyclopedia

Call by reference

In call-by-reference evaluation (also referred to as pass-by-reference), a function
receives an implicit reference to a variable used as argument, rather than a copy of its
value. This typically means that the function can modify (i.e. assign to) the variable
used as argument- something that will be seen by its caller. Call-by-reference therefore
has the advantage of greater time- and space-efficiency when the argument is a large
datatype (since arguments do not need to be copied), as well as the potential for greater
communication between a function and its caller (since the function can return
information using its by-reference arguments), but the disadvantage that a function must
often take special steps to "protect" values it wishes to pass to other functions.

Many languages support call-by-reference in some form or another, but comparatively few use
it as a default; Perl and Visual Basic are two that do, though Visual Basic also offers a
special syntax for call-by-value parameters. A few languages, such as C++, PHP, and
REALbasic, default to call-by-value, but offer special syntax for
call-by-reference parameters. C++ additionally offers call-by-reference-to-const. In purely
functional languages there is typically no semantic difference between the two strategies
(since their data structures are immutable, so there is no possibility for a function to
modify any of its arguments), so they are typically described as call-by-value even though
implementations frequently use call-by-reference internally for the efficiency benefits.

Even among languages that don't exactly support call-by-reference, many, including C and ML,
support explicit references (objects that refer to other objects), such as pointers (objects
representing the memory addresses of other objects), and these can be used to effect or
simulate call-by-reference (but with the complication that a function's caller must
explicitly generate the reference to supply as an argument).



そして日本語版にはないこれ。

Evaluation strategy - Wikipedia, the free encyclopedia

Call by sharing

Also known as "call by object" or "call by object-sharing" is an evaluation
strategy first named by Barbara Liskov et al. for the language CLU in 1974.[1] It is used by
languages such as Python,[2] Iota, Java (for object references),[3] Ruby, Scheme, OCaml,
AppleScript, and many other languages. However, the term "call by sharing" is not
in common use; the terminology is inconsistent across different sources. For example, in
the Java community, they say that Java is pass-by-value, whereas in the Ruby community,
they say that Ruby is pass-by-reference[citation needed], even though the two languages
exhibit the same semantics. Call-by-sharing implies that values in the language are based
on objects rather than primitive types.

The semantics of call-by-sharing differ from call-by-reference in that assignments to
function arguments within the function aren't visible to the caller (unlike by-reference
semantics)[citation needed], so e.g. if a variable was passed, it is not possible to
simulate an assignment on that variable in the caller's scope. However since the function
has access to the same object as the caller (no copy is made), mutations to those objects,
if the objects are mutable, within the function are visible to the caller, which may
appear to differ from call-by-value semantics. For immutable objects, there is no real
difference between call-by-sharing and call-by-value, except for the object identity.

Although this term has widespread usage in the Python community, identical semantics in
other languages such as Java and Visual Basic are often described as call-by-value, where
the value is implied to be a reference to the object.


こいつくらいは訳つけといたほうが良いのかしらん。

#### ■_ 名前で呼んで

ついでに。 これも英語版だと(ry

Evaluation strategy - Wikipedia, the free encyclopedia

Call by name

In call-by-name evaluation, the arguments to a function are not evaluated before the function
is called — rather, they are substituted directly into the function body (using capture-avoiding
substitution) and then left to be evaluated whenever they appear in the function. If an argument
is not used in the function body, the argument is neverevaluated; if it is used several times,
it is re-evaluated each time it appears. (See Jensen's Device.)

(以下略)


Jensen's Device ってのがわからなかったのですが、リンクがあるので折角だから辿ってみる。

#### ■_ Jensen's Device

Jensen's Device - Wikipedia, the free encyclopedia

Jensen's Device is a computer programming technique devised by Danish computer scientist
Jørn Jensen, who worked with Peter Naur at Regnecentralen, particularly on the GIER Algol
compiler, one of the earliest correct implementations of ALGOL 60.[1]

The following program was proposed to illustrate the technique. It computes the 100th
harmonic number by the formula H_{100}=\sum_{i=1}^{100} \frac{1}{i}:

begin
integer i;
real procedure sum (i, lo, hi, term);
value lo, hi;
integer i, lo, hi;
real term;
comment term is passed by-name, and so is i;
begin
real temp;
temp := 0;
for i := lo step 1 until hi do
temp := temp + term;
sum := temp
end;
comment note the correspondence between the mathematical notation and the call to sum;
print (sum (i, 1, 100, 1/i))
end

The above exploits call by name to produce the correct answer (5.187...). It depends on the
assumption that an expression passed as an actual parameter to a procedure would be
re-evaluated every time the corresponding formal parameter's value was required. Thus,
assignment of a value to i in the sum routine as a part of the for statement changes the
value of the original i variable, and when the code of the for loop requires the value of
term, the expression 1/i is evaluated and with the new value of i. If the last parameter to
sum had been passed by value, and assuming the initial value of i were 1, the result would
have been 100 × 1/1 = 100, though actually, it is not initialised.

So, the first parameter to sum, representing the "bound" variable of the summation,
must also be passed by name, otherwise it would not be possible to compute the values to be
added. On the other hand, the global variable does not have to use the same identifier, in
this case i, as the formal parameter.

ですから、summation で“束縛された”変数を表す sum の第一パラメーターは by name で渡されな
ければなりません。さもなければ加算のための値を計算することができないでしょう。

Usage

The Sum function can be employed for arbitrary functions merely by employing the appropriate
expressions. If a sum of integers were desired the expression would be just sum(i,1,100,i);,
if a sum of squares of integers, then sum(i,1,100,i*i);, and so on. A slight variation would
be suitable for initiating a numerical integration of an expression by a method very similar
to that of sum. In the absence of this pass-by-name facility, it would be necessary to define
functions embodying those expressions to be passed according to the protocols of the computer
language, or to create a compendium function along with some arrangement to select the
desired expression for each usage.

Because every mention of term within the procedure re-evaluates the original expression,
making a local copy of the value of term as appropriate may be worthwhile, as when the
procedure might compute the product of the terms as well as their sum.


### 2012年02月02日

#### ■_ C++11 は

ちまちまと訳を加えてます

C++11 Makes Competitors Go Rusty | Nerds Central

C++11 Makes Competitors Go Rusty

Rust is breaking free, but does it have any real world value?

C++11 is out (has been for a while) and brings many things from Tr1 into the standard.
Things like managed memory (shared_ptr) and lambdas and template meta programming (TMP)
bring new paradigms to the beating heart of C++. So much so, I would argue, that C++11
makes some of the 'new kids on the block' (think Go and Rust) look pretty pointless.

(shared_ptr) やラムダのようなもの、それにテンプレートメタプログラミング(template meta
programming, TMP) は C++ の beating heart に新しいパラダイムを持ち込みました。それはと
ても大きなものなので、C++11 は 'new kids on the block' の一部 (think Go and Rust)  を
ほとんど意味のないものにしてしまったのだとわたしは主張します。

'Go Rusty' as in go old, look old, corrode and otherwise become less good. This is
really just a play on words because both Google and Mozilla have been playing the 'new
object oriented native language' game recently. I can really see the motivation,
especially from organisations which want to create highly stable, performant,
cross-platform systems like browsers. The issue I see with both Go and Rust is that
they are solving yesterday's problems. C++/Tr1 has also solved many of the same
problems without needing a new compiler, for teams to learn a new language and
introducing all those compatibility issues with existing code.

'Go Rusty' as in go old, look old, corrode and otherwise become less good.
になって 'new object oriented native language' ゲームをプレイしているからです。わたし
は動機、とりわけ highly stable で高性能でブラウザーのようにクロスプラットフォームなも
のを望む組織からの同期をわたしは理解できます。わたしが Go と Rust の両方で見つけた問題
は、これら二つの言語が過去の問題を解決しようとしていることです。C++/Tr1 はすでに同じ問

So Boost and Tr1 are cool, but not part of the standard... Well, no longer, a large
proportion (if not all) of what Go and Rust are trying to do with a complete new language
C++ has done by adding to an existing one via the 2011 standard.

ですから Boost や Tr1 は cool だけど標準のものではないという意見はもはや当てはまりませんし、
Go と Rust が完全に新しい言語でもって試みたことの大部分は
C++ が2011年の標準を通じて追加された既存のものによって成し遂げました。

From Wikipedia:
"
Rust is an experimental, concurrent, multi-paradigm,compiled programming language
developed by Mozilla Labs.[1] It is designed to be practical, supporting pure-functional,
concurrent-actor,imperative-procedural, and object-oriented styles. The main developer is
Graydon Hoare, who began work on the system in 2006; Mozilla became involved in 2009.[2]
In 2010, work shifted from the initial compiler, written in OCaml, to the self-hosted
compiler written in Rust itself.[3] It successfully compiled itself the following
year.[4] The self-hosted compiler uses LLVM as its backend. Version 0.1 of the Rust
compiler was completed in January 2012.[5] Mozilla described it as an alpha release,
suitable for early adopters and language enthusiasts.
"

Go is a compiled, garbage-collected, concurrentprogramming language developed by
Google Inc.[6] The syntax of Go is broadly similar to that of C: blocks of code are
surrounded with curly braces; common control flow structures include for, switch, and
if. Unlike C, line-ending semicolons are optional; variable declarations are written
differently and are usually optional; type conversions must be made explicit; and new
go and select control keywords have been introduced to support concurrent programming.
New built-in types include maps, Unicode strings, array slices, and channels for
"

I can totally get why people want to write new programming languages. Sometimes it becomes
very annoying  dealing with some seemingly stupid, repetitious and just plain awkward
aspects of many main stream languages. However, I learned from Robert Sales and Micro Focus
that a much more productive solution to annoying syntax is to make the compiler able to work
out what you mean with better syntax and leave in the old syntax as well. Why is this better?
Here are some (but not all) the issues created by introducing a new language into an
existing echo-system (which all projects are these days):

わたしはようやく、なぜ皆が新しいプログラミング言語を使いたがるのかを理解できました。
Sometimes it becomes very annoying  dealing with some seemingly stupid,
repetitious and just plain awkward aspects of many main stream languages.
しかしながらわたしは、 Robert Sales と Micro Focus から、
annoying syntax に対するより一層 productive な solution は
コンパイラーがあなたがより良いと考えている構文を cut したり

なぜこれが better なのでしょうか?
Here are some (but not all) the issues created by
introducing a new language into an existing echo-system
(which all projects are these days):

Massive but ineffective - lots of engineering does not make something worth while or
work well. Normally the reverse is the case!

Compatibility: The new language will have to talk with older languages. Types will
have to be translated; memory models will need to be aligned and compilers will need
to 'play nice' together. This is not just as the compiled object level but at the ABI

リーモデルをそろえる必要があってコンパイラーは  'play nice' together しなければならな
いでしょう。これはコンパイルされたオブジェクトのレベルの話ではなく、リンクの際の ABI
レベルでの話です。

Performance: This new language is super fast. Great, but it will have to work with
existing systems. The interface between the two will slow stuff down a lot. Either
that interface will have to be messy (see Compatibility above and/or JNI) or via a
marshalling system (Protocol Buffers, Avro etc). The problem with marshalling between
dissimilar systems is that it is really slow. It might seem like a good idea (just
like the steam gun right) but it is a stupidly expensive and complex way to solve a
problem of one's own invention. Such protocols are great for clustering, cloud
processing and client-server work; they are just wrong headed for gluing systems
together to work around using different languages in one system. Keep it simple.

この新しい言語は super fast で Great ですが、既存のシステムと動作しなければなりません。
それら二つの間のインターフェースは大幅にスローダウンさせる要素となるでしょう
Either that interface will have to be messy (see Compatibility above and/or JNI)
or via a marshalling system (Protocol Buffers, Avro etc).
dissimilar systems 間でのマーシャリングの問題はそれが本当に遅いということです。
It might seem like a good idea (just like the steam gun right)
but it is a stupidly expensive and complex way to solve a problem of one's own invention.
Such protocols are great for clustering, cloud processing and client-server work;
they are just wrong headed for gluing systems together
to work around using different languages in one system. Keep it simple.

Build: Build system complexity has been one of the biggest headaches in all the major
projects I have seen over the last few years. Build systems are getting more and more
complex as the demands of heterogeneous programming and dependency management push
technology beyond the sane. Frameworks like maven, msbuild and even good old make work
fine if a project uses one language; they generally degenerate into a big ball of mud
otherwise.

ビルド:
ビルドシステムの複雑さは過去数年わたしが見てきたすべての主要なプロジェクトにおいて
dependency management push technology beyond the sane
に伴ってビルドシステムはますます複雑になってきています。
maven や msbuild のようなフレームワークであるとか、あるいはgood old な make でさえも
ひとつのプロジェクトでひとつの言語しか使っていないのであれば問題なく働きます。
they generally degenerate into a big ball of mud otherwise.

Debugging: Debugging across languages is really tricky. I should know, I have spent a lot
of time doing it over the last few years. For example, even debugging from COBOL into Java
and back on the same JVM is tricky because a Java debugger does not understand COBOL and
the same is the case in reverse. Jumping between native languages can be even harder when
their internal data structures, interpretations of indirections (pointers etc) and
(shudder) interpretations of thread state are completely different.

デバッグ:

たとえば
even debugging from COBOL into Java and back on the same JVM is tricky
なぜならJava のデバッガーはCOBOLを理解しないし
その逆にCOBOLのデバッガーはJavaを理解しないからです
Jumping between native languages can be even harder
when their internal data structures,
interpretations of indirections (pointers etc)
and (shudder) interpretations of thread state are completely different.

Team Training: Assembling a team of people who know one language well is hard enough;
doing so across multiple languages is extremely challenging. Some people will be
prepared to learn new stuff but not all will. Time pressure, as we all know and love
it now, generally does not leave time to learn a language up front in a project.

チームのトレーニング:
ひとつの言語をよく知る人たちでチームを組むことはとても困難なことです。

Some people will be prepared to learn new stuff but not all will.
Time pressure, as we all know and love it now,
generally does not leave time to learn a language up front in a project.

Team Embedded Knowledge: It is very hard to keep the knowledge of a multi-language
project spread throughout a team. It is even harder to keep that knowledge 'live' as
team members leave and join. Because language interoperation patterns are less well
known and less standardised that intraoperation patterns, unique embedded knowledge
tends to build up in teams.

Version Management (language/runtime): Different languages frequently have slightly
different life-cycles and dependency management issues. These accumulate to cause
challenges in revision control.

(言語とランタイムの) バージョン管理:

These accumulate to cause challenges in revision control.

Tooling Costs: Good tooling can be expensive. Tools like profilers, code complexity
analysis systems and test coverage checkers can all be pretty costly to buy. Whilst
some have good open source alternatives, these have the embedded cost of maintenance
and installation. Again, multiple languages usually means that a team needs more tools
and hence more cost.

Licensing Of Runtimes And Libraries: We often get complacent thinking all libraries
and runtimes will be free. This in not the case. Even if they are 'free' as in they
cost no money, their licensing requirements might complicate commercial arrangements.
If they are commercial and have enforced licensing this introduces a whole new level
of complexity. One really nasty situation is when two completely different forms of
code hardening in the licensing systems do not play nicely together. I have seen it
happen and it is not pretty.

ランタイムやライブラリーの Licensing:

Lifespan And Sundown: All things come to an end. Support for a language or, more often,
a version of a language will come to an end. Managing these life cycle events can be
challenging in a single language environment. When more than one language enters the
picture, the cycles will almost certainly not coincide. The less common a language is,
the more likely that is will be sundowned whilst the products using it are still
current. It is fairly easy to get into a situation when one can never actually release
on a completely stable, current set of components.

Lifespan And Sundown:
すべてのものごとには終りがあります。ある言語に対するサポートもそうですし、もっと頻繁に
あるのが言語のあるバージョンのサポートが終了することです。これらの life cycle events
を管理することはsingle language environment において challengig となる可能性があります。

となるでしょう。
The less common a language is, the more likely
that is will be sundowned whilst the products using it are still current.
It is fairly easy to get into a situation
when one can never actually release on a completely stable,
コンポーネントの current set

Startup And Shut-down Sub-Systems: A programming language is just the code right? Wrong -
generally there is a lot more to it than that. It can be tricky even to mate up C with C++
projects because C++ has to initialize statically referenced objects before main is called.
Many other languages have even more complex issues to do with threading, signals and
loaders which all get in each other's way when building a mixed language system.

サブシステムのスタートアップとシャットダウン:
A programming language is just the code right?
Wrong - generally there is a lot more to it than that.
C++ では main が呼び出されるよりも先に静的に参照されているオブジェクトの初期化を行わなけ
ればならないのでC++を含むCプロジェクトでさえ混乱を招くほどtrickyとなる可能性があります。

mixed language system を構築するときに
all get in each other's way するローダーを扱うときに
もっと複雑な問題を抱えさせします。

Paradigm Contamination: Seeing Java written in the in style of COBOL is quite an eye
opener. I am not a COBOL bigot either way; it is a solid language that is really good
for some things. Java is also a solid language, but it really should not be programmed
in the style of COBOL. However, where the two languages touch the chances are the
COBOL will look like Java and the Java look like COBOL. I have seen exactly the same
thing with C# and C. If a programmer is working in C and writing a bit of Java, the
chances are the Java will be C like. Equally, the natural paradigm of a cross language
API tends to be a hybrid of both languages. Whilst these things are to be expected,
they are horrid. The code looks bad, smells bad and is hard to test or maintain.

パラダイムの汚染:
COBOL のスタイルで書かれた Java を見ることはかなり衝撃的なことです。わたしはいずれにし
ても COBOL bigot ではありませんが、COBOL は soolid な言語で、一部の事柄に対してはとて
も優れた代物です。Java もまた solid な言語ですが、COBOL スタイルでプログラムされるべき
ものではありません。わたしは C# と C とでのこれとまったく同じことを見たことがあります。
あるプログラマーがCを使っていて、ちょっとだけJavaで書くことをしたら
その Javaコード は C で書いたもののようになることでしょう。

Whilst these things are to be expected, they are horrid.
そのコードは見た目も悪く、悪臭を放ち、テストや保守が困難です。

Brain Strain (the bilingual problem): Children which are brought up from babyhood as
bilingual usually learn to speak more slowly than their monoglot contemporaries. Can
the analogy be brought over to programming? In the absence of hard evidence from
psychologists, it seems at least likely and reasonable to assume that coding progress
will be slowed down by the extra cognitive burden of working in more than one language.

... and so on ...

So what am I saying?

I hope I have established that in modern environments, introducing new languages carries
with it a lot of down sides. To put it another way - there has to be an overwhelming need
before there is an overall benefit in introducing a new language rather than using a well
established general purpose language. Go and Rust are compiled straight to native and so
the existing candidate as an alternative is C++. C++ has huge pre-existing libraries and
is (with the possible exception of C) the most likely language in which other native code
will be written. Even if there is a large legacy C library set, C++ to C is a well know
interoperation with some issues from the list above but not too bad.

So, is there an overwhelming need to replace C++ with Rust or Go?

I would definitely say NO! Simple paradigm following within the pantheon of C++ allows
this language to behave just as well as Rust or Go - or at least that is what I fully
expect.

Let us think about the big ideas behind Go: It is simple, clean and has garbage collection.
Well, one can write simple clean C++ and use share_ptr. Just because C++ can be super
complex does not mean it has to be.

Let us think about the big ideas behind Rust: Type inference, static assertions (checks),
nice things indeed. However, using lambda's correctly along with other templating
techniques makes C++ straightforward for multi-threaded reasoning. Template Meta
Programming should be able to perform most of the type reasoning which the compile time
checks are performing in Rust. C++11 has type inference. It does not use clever code branch
analysis like Rust, but it is there (auto and decltype).

The ideas in Rust are definitely more tricky to implement in C++ than those in Go; however,
the effort required to do so is , IMHO, trivial compared to creating, using and maintaining
a new language. Further, the effort to replicate Rust's good features in a C++ paradigm is
much less than the effort of dealing with a new language (as described above).

Rust におけるこのアイデアは C++ で実装するには Go よりも格段にトリッキーなものです。し
かし、わたしの見るところでは実装するのに要求される労力は新しい言語を作って、それを使っ
て、メンテナンスをすることに比べればたいしたことがないものです。加えて、C++ のパラダイ
ムで Rust の good features を replicate するための労力は新しい言語を扱うための労力と大

Here is a very trivial bit of C++ with which I was playing this morning:

// VSPL.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <boost/spirit/include/qi.hpp>
#include <iostream>
#include <iterator>
#include <algorithm>

namespace client
{
namespace qi = boost::spirit::qi;
namespace ascii = boost::spirit::ascii;
template <typename Iterator>
bool parse_numbers(Iterator first, Iterator last)
{
using qi::double_;
using qi::phrase_parse;
using ascii::space;

bool r = phrase_parse(
first,
last,
double_ >> *(',' >> double_),
space
);
return first == last;
}
}

int main()
{
typedef std::istream_iterator<int> in;
std::string code = "1,2,3,4,5,6";
std::cout << (client::parse_numbers(code.begin(), code.end())?"All is well":"It barfed") << std::endl;
auto exiter = [] (const int v) { if(v==123)exit(0); } ;
for_each(in(std::cin),in(),exiter);
}

Here we can see a lambda being used as an immutable first order entity. The for_each
could be parallel or serial, it really does not matter. We can also see type inference
where the type of the lambda is inferred from its internal code (in this case void).

Here we can see a lambda being used as an immutable first order entity.
The for_each could be parallel or serial,
it really does not matter.
We can also see type inference
where the type of the lambda is inferred from its internal code (in this case void).

I did not include this here because it is a clever bit of code; Indeed, my motivation is
quite the opposite! I am working on a parser for my research language VSPL using the Spirit
library in Boost. The above was just a play thing to make sure the project was set up
correctly. However, easy features like type inference, lambdas, name spaces and internal
DSLs are so accessible in C++ now that they are just natural in the most trivial coding
example. I just don't see a strong enough argument for new languages to replace C++.

I did not include this here because it is a clever bit of code;
わたしはここではこれを含みません。
なぜならこれは clever bit of code だからです。
Indeed, my motivation is quite the opposite!
I am working on a parser for my research language VSPL using the Spirit library in Boost.
The above was just a play thing to make sure the project was set up correctly.
However, easy features like type inference, lambdas, name spaces and internal
DSLs are so accessible in C++ now that they are just natural in the most trivial coding example.
I just don't see a strong enough argument for new languages to replace C++.



#### ■_

↑に対する反応から。

C++11 Makes Competitors Go Rusty | Hacker News

Compatibility: The new language will have to talk with older languages. Types will
have to be translated; memory models will need to be aligned and compilers will need
to 'play nice' together. This is not just as the compiled object level but at the ABI
level during linking etc. I've spent more time solving issues with memory models in
C++ than I have in any other language because C++ has no ABI - I've had patches to
MSVC change the memory layout of objects and cause breakage which is just as bad as
you get with any sort of language interop scenario.

(略)

Let us think about the big ideas behind Go: [snip] Well, one can write simple clean
C++ and use share_ptr. Just because C++ can be super complex does not mean it has to
be. Unless, say, you're writing a DLL (another fun fact: not only can your API not
have STL, exceptions also can't cross DLL boundaries), or you're using DLLs written by
other poor souls who were consigned to writing DLLs with a C++ API.

As a finishing note, one of my favorite articles on the subject of complexity in programming:
http://www.joelonsoftware.com/items/2009/09/23.html



Stroustrup is right, but that doesn't prove your point. Every language will have detractors,
but not every language will be the target of every particular complaint. Lua, for example, is
a useful language and it has largely avoided being a ball of mud.

Naturally, that minimalism brings its own set of issues and complaints. But the point is,
you don't need to be as much of a ball of mud as C++ in order to be useful or successful.
I think a lot of language partisans, and C++ partisans in particular, point to Stroustrup's
quote as an excuse for their language's warts. It's true that no language can ever be
perfect, but that doesn't mean that all complaints are without merit and unworthy of
attention and consideration.


#### ■_ ネタ

アワーズの連載でネイが登場したのでこういうやりとりが

【ナポレオン】長谷川哲也34【陣借り平助】

619 名無しんぼ＠お腹いっぱい [sage] 2012/02/02(木) 14:52:56.43 ID:VFCbwGB30 Be:
まあネイの真骨頂はロシア退却戦なわけで
マリー・テレーズ(マリー・アントワネットの娘)すら感動させて死刑に1票投じた事を後悔するぐらいだからな。

620 名無しんぼ＠お腹いっぱい [] 2012/02/02(木) 14:58:32.01 ID:6GToE1QU0 Be:
退き佐久間みたいなもんか

621 名無しんぼ＠お腹いっぱい [sage] 2012/02/02(木) 22:07:23.49 ID:hLc7fcfT0 Be:
かかれマッセナに退きミシェル。米ベルティエに木綿ダブーってとこかい？

622 名無しんぼ＠お腹いっぱい [sage] 2012/02/02(木) 22:17:08.83 ID:zh2ELWM40 Be:
鬼武蔵は、誰なんですか


あー毒吐きてえ

### 2012年02月01日

#### ■_

Firefox を 10 に。 入れていたアドオンが結構未対応だったような気がする。

InfoQ
いやまあそのなんというか

#### ■_ Lua

その1

Wikipedia:Wikipedia Signpost/2012-01-30/Technology report - Wikipedia, the free encyclopedia

Why "Lua" is on everybody's lips, and when to expect MediaWiki 1.19
By Jarry1250, January 30, 2012
Lua chosen as new template scripting language

Reducing the inefficient complexity of complicated templates has long been on the wishlists
of those who design and maintain them. It is a complexity that can put a significant drain
on server resources, not to mention one that makes accurate duplication of templates
between wikis incredibly time consuming and error prone. This complexity is caused by a
number of factors, but it has long been recognised that the introduction of certain
constructions found in full programming languages (among them loops, arrays and a full
range of string functions) would drastically simplify matters.

たちによるウィッシュリストに長いこと載っていました。その複雑さはサーバーのリソースを目
だって食いつぶしてしまう可能性のあるもので、
not to mention one that makes accurate duplication of templates
between wikis incredibly time consuming and error prone.
この複雑さは数多くの要因によるものですが、full programming languges にある
いくつかの constructions (ループや配列、full range の文字列関数といったもの)
の導入によって劇的に事態が単純になるであろうと認識されていました。

Of course, the introduction of a programming language would bring with it a number of other
problems, particularly with regards to privacy, security and memory footprint. As a result,
the long term consensus was that the introduction of a programming language would be a major
undertaking, including time for discussing which languages would work best in a heavily
sanitised environment. The project as a whole has been discussed at regular intervals, but
it was only this week that a consensus seemed to emerge in favour of Lua, a lightweight but
relatively unheard-of language generally regarded as being "easy to learn"
(wikitech-l mailing list).

もちろん、プログラミング言語の導入は、特にプライバシーやセキュリティ、メモリーの使用量
に関して別の問題を数多く持ち込むことでしょう。結果として、long term での consensus は
プログラミング言語の導入は major undertaking でした。
including time for discussing which languages would work best in a heavily sanitised environment.
プロジェクト全体としては通常のインターバルで議論されていましたが、
a lightweight but relatively unheard-of language generally regarded as being "easy to learn"
である Lua を推すという合意は今週だけの議論でした
#違うよなあ、正直わからん

The preferred implementation at this time is via a separate namespace for scripts, perhaps
augmented by the overloading of the double-curly-brace notation to incorporate both Script
and Template namespaces. Work is expected to start after the release of 1.19 and could well
centre around the Berlin Hackathon, held annually in May.

それはおそらく、二重カーリーブレース記法のオーバーロードによって



#### ■_ Lua

その2 ↑に対する reddit での反応

Wikipedia chooses *Lua* as its new template/macro language : programming

A language with no baked-in unicode or I8N support at all. For an international wiki.
That's gonna be interesting.



Internationalization ("i18n") is the design and development of a product,
application or document content that enables easy localization ("L10n" = the
adaptation of software for a specific locale).


Indeed. I doubt JavaScript's UTF-16 surrogates would be handled properly in practice
though, had they gone w/ JS.



JS has really broken Unicode support http://98.245.80.27/tcpc/OSCON2011/gbu/gbu.html



Honestly, most languages and platforms have broken Unicode support.



Yeah but really, does Lua have support for anything "baked-in"? I mean I
figure that's kind of the point. It and TCL have this thing going on of being like,
language templates. You get an interpreter and the absolute core syntax to make
procedural programming usable, batteries are your problem.


Heh - a whole thread of replies promoting languages with half-baked i18n support and
no mention of Tcl.


Please, do tell.



Tcl was designed to be a lightweight scriptable layer on top of any C library for
scripting purposes also. It has had real i18n support since about 2005 or so. I don't
think Tcl could compete with the size or speed of Lua though. Then again, does Lua
have a standard GUI library (ala tk) currently? You can whip out stuff wicked fast in
Tcl/Tk once you are even halfway proficient. I'm seeing Lua not just mentioned
everywhere but implemented in things I use, time to start from lesson 1 on
projecteuler with a fresh language!



Then again, does Lua have a standard GUI library (ala tk) currently?

Lua doesn't really have a standard anything, that's kinda the point of it; it's
brilliant for writing complex configuration/glue stuff (think AI state machines for
video games, etc) that needs too hook into a bunch of custom APIs. Very little Lua
code would need to define a GUI, and if it did, the host application probably already
has a framework to do so.

That said, there's a ton of bindings to GUI frameworks on the wiki page.



Tcl has had full unicode support since 8.1, released in 1999 (!). It's a very stable,
simple yet powerful language. EIAS (actually, everything has a string representation)
seems to make it particularly suited as a templating language. You can create safe
interps and extend the language with new control constructs or even syntax. There are
other reasons to like it.



#### ■_

その3

The Data Mules Blog

Why Lua
January 30, 2012 at 12:19 PM | 32 Comments

Posted by: ktr

(Lua in particular).

In this article, I would like to discuss why you should use Lua. This all started with
a message that recently popped up on the Lua mailing list regarding why isn't Lua more
widely used? The answers went from randomness to lack of libraries to a variety of
other things, but the one that resonated with me most was that there are fewer people
who enjoy the do it yourself approach, which Lua fully embraces. I've come to think of
Lua as the Arch Linux of programming languages. Which, almost by definition, means
fewer people will enjoy Lua rather than more. So then why would you want to use Lua?
In no particular order, here are some of the reasons why we use Lua to develop our product:

This all started with a message that recently popped up on the Lua mailing list
regarding why isn't Lua more widely used?
The answers went from randomness to lack of libraries to a variety of other things,
but the one that resonated with me most was that there are fewer people
who enjoy the do it yourself approach, which Lua fully embraces.
わたしは Lua を Arch Linux of programming languages と考えるようになりました。
Which, almost by definition, means fewer people will enjoy Lua rather than more.
So then why would you want to use Lua?
わたしたちの product を開発するためにLua を使う理由をいくつか順不同で挙げます。

1. Integration with C (and C++ for that matter)
C (と C++) との統合

I have used a lot of languages during my short career as a programmer. Lisp, Scheme,
Python, Perl, Bash, VBA, SQL, etc. etc. etc. There is no other language that I have ever
used that even comes close to Lua when trying to commingle C code. The C API is so clean
and so intuitive that I would argue that you could get up to speed on its use in an
afternoon. Check out PIL's section on the C API if you are interested in learning more.

Python、Perl、Bash、VBA、SQL、などなど。C のコードをコンパイルしようと試みたときに、Lua
ほど密着するほど使った言語は他にはありませんでした。Lua の C API はとてもきれいなもので、
また intuitive で、半日あれば使えるほどのものといえるでしょう。
もしもっとこれについて知りたいと思うのなら、C API の PIL セクションを読んでみてください。

Why is this important? Well, for one this means that if you have an existing C (or C++)
library, it is usually not very difficult to expose the API to Lua. Nor is it
difficult to write a script in Lua and get something running on the C side. This also
means that speed problems are rarely an issue in Lua programs. You can write something
in Lua and truly rewrite it in C if it is a speed problem. It is always possible to
rewrite something in C in other languages, but Lua is the only language in which I
have found it easy to do so.

なぜそれが重要なのでしょうか?
Well, for one this means that if you have an existing C (or C++) library,
it is usually not very difficult to expose the API to Lua.
Nor is it difficult to write a script in Lua and get something running on the C side.
このことは Lua のプログラムにおいてはスピードが問題になることはほとんどないことも意味します。
あなたは Lua で何かしら書くことができるし、それでスピードに問題があれば C で丸ごと書き直すこともできるのです。
これは他の言語で書かれたものをCで書き直すときには常にいえることではありますが、
わたしがこれまで見てきた中で Lua はそれがとても簡単にできる唯一の言語なのです。

2. Speed and Simplicity
速度と単純さ

The standard Lua implementation performs extremely well compared to most other languages,
even without writing anything in C. Perhaps this is because Lua uses a register based
virtual machine rather than a stack based machine. Or it could simply be due to the fact
that the programmers behind Lua are just very talented. Whatever the reason, you are
rarely going to be overly concerned with performance when writing Lua code.

スターベースの virtual machine を使っているからでしょう。あるいは Lua の背後にいるプロ
グラマーたちがとても才能豊かな人たちだからかもしれません。いずれにしても、Lua でプログ
ラムを書いているときに性能を気にしなければならないことはほとんどないでしょう。

But, if you are not getting the results you would hope or expect, you can get an almost
drop in replacement for the standard Lua implementation with LuaJIT. From the overview page:

But,
if you are not getting the results you would hope or expect,
you can get an almost drop in replacement for the standard Lua implementation with LuaJIT.
From the overview page:

LuaJIT is widely considered to be one of the fastest dynamic language implementations
in existence ... with an unmatched low memory footprint: less than 125K for the VM plus
less than 85K for the JIT compiler (on x86).

LuaJIT speeds can rival code written in C. And if you are still not getting the speed
you want, see my 1st point above.

LuaJIT のスピードは C で書かれたコードに匹敵するものです。
And if you are still not getting the speed you want, see my 1st point above.

3. Education
教育

While not necessarily a language feature, I have found that using Lua has improved my
general computer science knowledge over time. For example, this writeup on the
implementation of Lua 5.0 gave me a very good overview of how virtual machines are
implemented. Reading the very accessible source code, while following the recommended
reading order suggested by Mike Pall (author of LuaJIT) has been eye opening as well.
I don't think any of this would be possible except for the methodical manner in which
Lua has evolved over time. This has allowed Lua to remain "Clean C" which
means that it is easier for you to understand as a user of the language.

4. Functional

Lua provides you with functional programming constructs that make programming more
enjoyable. Examples include anonymous functions, higher order functions, lexical
closures, proper tail calls, etc. And this is not some superficial gloss applied on
top of the language - it represents some of the fundamental underpinnings of the
language itself. For example, all functions in Lua are values (like the number 2 or
the string "ktr") - and this means that every function in Lua is anonymous.
You simply attach a name to it so that you can reference it later. Thus, like Roberto
describes in his book, you can reassign print with:

print = math.sin

This type of functionality also enables you to build sandboxes if you need them. If
printing were a dangerous operation, you could replace it with your own print function
or simply remove it from the global environment.

5. Everything is a Table
すべてがテーブルである

Everything in Lua is a table. Arrays, hashes, "modules", the global
environment, etc. They are all tables. This means that you can require some module
(similar to Python's import statement) and treat the resulting value just like you
would any other table. In Python, you might __import__('...')' some module and then
the variables of the return value would be accessed like vars(module). Not very
difficult, but also not very Pythonic. In Lua, you would access the variables in that
module just like any other table (module[var]). I only mention Python to highlight
differences - simply showing that it may be easier to "hold Lua in your head"
due to such consistencies.

Lua におけるすべてがテーブルです。配列、ハッシュ、“モジュール”、グローバル環境等々
これらすべてがテーブルです。
これは、いくつかのモジュールを (Python の import 文と同様) require して
その結果を別のテーブルのように扱うことができるということです。
Python では、いくつかのモジュールを __import__('...') とすると
そのモジュールにある変数に  vars(module) のようにアクセスできます。
これはとても難しいというものではありませんが、とても Python 的であるとも言えません。
Lua ではそういったモジュールにある変数にアクセスすることは

I only mention Python to highlight differences
- simply showing that it may be easier to "hold Lua in your head"
due to such consistencies.

This has the added benefit of allowing you to learn the full Lua syntax faster than
you could in most other languages. Without needing to worry about how lists are
written versus how dictionaries, packages, etc. are written, you can "assume"
you already know how they are written because you only need to know the one construct.

このことは大部分の他言語の場合よりも短い時間で Lua の構文全体を学習できるという benefit を付加しました。
リストや辞書、パッケージといったものがどのように記述されているかを心配する必要はなく

それらがどのように記述されているのかすでに知っていると “仮定”できるのです。

6. Consistent
一貫している

If you haven't figured it out already, Lua is a very consistent language. A lot of time has
gone into each and every feature to make sure that it was done "just right". For
example, Lua didn't have a for loop until Lua 4.0 - 7 years after the first release. This
was because

If you haven't figured it out already, Lua は非常に一貫性のある言語です。
A lot of time has gone into each and every feature to make sure
that it was done "just right".
たとえば最初のリリースから7年、Lua は 4.0 になるまで for ループを持っていませんでした。
なぜならそれはこのような理由があったからです

while loops were more general. ... Also, we could not agree on a good syntax.

(See page 6 of this document).
And since the authors of the language have remained relatively unchanged and rather limited
(the Lua team does not like to accept patches), the language has evolved somewhat slowly and
quite coherently. So you know features are well planned. (However, this also means you
shouldn't expect to have a lot of your pet features implemented anytime soon.)

(See page 6 of this document).
この言語の author たちは比較的変更を行わないし、変更も限定しさえするので
(Lua チームはパッチを受け付けるのを好みません)、
the language has evolved somewhat slowly and quite coherently.
So you know features are well planned.
(とはいえ、このことは
a lot of your pet features がすぐに実装されるようなことは期待すべきでないことも意味します)

7. Portable
移植性

I won't go into a lot of detail, but rest assured that Lua runs on almost everything
you can think of. The code is written as "Clean ANSI C", so if you have a
compliant C runtime, you will likely be able to get Lua running without much fanfare.

のソースコードは "クリーンな ANSI C" で記述されているので、あなたが C のランタイムに従
うのなら、大げさな移植作業をしないでもLua を実行できるようにさせられるでしょう。

All in all, a very powerful, yet simple language.



#### ■_

その4．↑に対して

Why Lua? | Hacker News

I took some Visual Basic programming courses in high school, some PASCAL courses in
college, and then didn't program anything other than basic HTML/CSS for the next eight
years. Last year I programmed an iPhone game in Lua (using the Corona SDK) and it was
easy as Tau. Sure a better programmer would have finished the programming aspects in a
quarter the time it took me, but I started by looking at Objective-C and I'm not sure
I ever would have picked it up without some kind of formal training. Contrast with
Corona/Lua, where I watched a few eight minute videos on YouTube and could turn around
and make simple but complete programs, and more importantly completely understand what
was going on within them. Reading the Lua documentation was a revelation, reading

Why Lua? http://itunes.apple.com/us/app/beat-boxes/id460798042



Doesn't Apple forbid applications built using things like this?


As long as you are not running code that is downloaded after app install (e.g. either
embedded in the app itself or entered by the user from the keyboard) you are good to
go. This mod to the previously ominous app store policies is used by quite a lot of
applications.



The more I learn about Lua's design and implementation, the more impressed I am. It's
very rare to see software that does so much with so little code. The design is
extremely clean and the code is extremely fast.

The C API is easy to use and gives good performance, and yet encapsulates enough of
the VM's implementation that C modules are source and binary compatible with both Lua
and LuaJIT, two very different implementations of Lua. Note that the C API was
designed before LuaJIT was even written, so this API was designed without the benefit
of seeing how different implementations of Lua might vary.

The source is very readable for the most part; my only stumbling block is that their
naming of types and variables is extremely terse at the cost of readability sometimes,
and the extensive use of macros can sometimes can require a lot of jumping around. But
Lua is an impressive achievement that I frequently refer to for design inspiration.



Lua has great C integration, but LuaJIT's is even better. You can natively interface
with C code without a recompile, just by defining the C function prototype in Lua, and
using it like you would any normal lua function. Better still, LuaJIT can frequently
inline the calls to C code, so there's no cross-language marshaling penalty.

Check out http://luajit.org/ext_ffi_tutorial.html


Not criicizing lua, but worth comparing to guile.

> Integration with C (and C++ for that matter)

Guile does it better. You can use shared memory threads in guile without any penalty.
Atmost you have to allow for the garbage collector to run when inside FFI functions.
But that is a small price to pay in case you need to use multiple parallel-concurrent

Guile was built with FFI in mind and has an impressive history. Just take a look at
guile gnome bindings.

> Speed and Simplicity

Guile 2 is extremely fast. Not as fast as LuaJIT, but it no reason it won't get there. As for simplicity, take a look at the partial evaluator in trunk of guile 2.

> Education

Guile is good old scheme.

> Functional

Can't get more functional than scheme :)

> Everything is a Table

Well, almost everything is a pair in guile. Vectors and hash-tables are trivially
available. Though I recommend to sticking to functional programming in scheme style.

> Consistent

As before, can't get more consistent than scheme.

> Portable

Guile is available on n900. So there.

To continue, guile has continuations (delimited or otherwise), and macros (hygienic or
otherwise), both of which are effectively missing in lua.

And guile offers all of this while supporting native threading with a single heap. Sweeet.



Not sure if I'd agree that Guile's FFI bindings are better than LuaJIT's FFI. It's
certainly easier to declare a function in LuaJIT - you can take the definition
directly from the header file, rather than transcoding it into s-exps.

Compare:

(define memcpy
(pointer->procedure '*
(dynamic-func "memcpy" this)
(list '* '* size_t))))

vs.

ffi.cdef [[
void * memcpy ( void * destination, const void * source, size_t num );
]]

You also get the ability to add metamethods and finalizers to returned C objects (so
you can use Lua's built-in GC to clean up after, for example, your FILE*).

As for the speed, there's no reason that a lot of dynamic languages couldn't be as
fast as LuaJIT. But none of them are even close. I wish LuaJIT was still up in the
computer language shootout. The LuaJIT interpreter (with JIT turned off) is 3x faster
than V8 on the PC, and faster than Java on Android. And that's the interpreter - the
JITed code is way faster.

Of course, macros are awesome, and a huge point in Guile's favor. On the plus side,
Lua is very easy to understand, especially if you're coming from Javascript.


なんでこう盛り上がるんだろう。

#### ■_

Why Lua : programming

Lua is amazing for embedding. You can even easily overload its memory allocator or
default data type. I needed to do this for a project where we were running on a
processor without native support for double or without a standard C library.

That is just amazing stuff.


When I first started playing with Lua, I found myself repeatedly saying of its features
"You can't do that! That sounds like a great idea but you can't do that because it
will, well because... I'm pretty sure this is a design mistake in the long run because...
", and then failing to come up with compelling arguments against them.

Take for example the "..." syntax for variadic functions. You can't do that,
right? I distinctly recall being frustrated with C's clunky va_list and va_start etc.,
and the fact that you can't easily wrap variadic functions, and it's just a whole mess.
I distinctly remember justifying that to myself and thinking that it couldn't be any
other way. But Lua comes along with its "...", like it just doesn't give a
fuck.

So things like that certainly have had an effect on how I think about programming.

I'm not a big fan of some of the ways I've seen people use Lua. For example, people
want classical inheritance, so you have all these libraries out there that either roll
their own classes, or rely on other libraries for classes. So now if you want to use
four third-party libraries, you're liable to find yourself juggling four slightly
different inheritance models from class libraries with overlapping namespaces –
suddenly JavaScript's choice of having class as an unused reserved word seems
extremely wise.

Then of course there's the commonly-seen-as-brilliant practice of serialization by
emitting Lua code. It's just like JSON but without any regard for security!


Python's variable length arguments syntax is probably the best out of any language.


This article is just what I have been looking for. I have started with Lua two weeks
ago but there still were so many questions. Good article with good links in it. I am
sure it will help me alot in the future.

Thanks for sharing!


Check out my language, http://moonscript.org

It compiles into Lua, but does a lot of what CoffeeScript did for JavaScript and more.
Classes, comprehensions, cleaner syntax, etc.

Here's the reference manual: http://moonscript.org/reference



#### ■_

いつにも増して日本語の部分が少ないものになってしまったw

リンクはご自由にどうぞ

メールの宛先はこちら