ときどきの雑記帖 混迷編


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





LAMYY Pico どっかに落とした ○| ̄|_

■_ Pythonに欲しいこんな機能


bramcohen: Python wish list

Python wish list

Now that the moratorium on Python language features is over, I'll put in my thoughts 
on what new stuff the language could use. I don't have much to suggest, and what I do 
have to suggest is fairly minor. This is because I'm happy with the language.

new on default parameters

    One of the gotchas in python is that default parameters are reused, so if you say:
    Python における gotchas のひとつが再利用されたデフォルトパラメーターです。

    def spam(eggs = []):

    then eggs will get set to the same list every time, and modifications will get
    carried over between calls. This can be hacked like this:
    このようにした場合、eggs は毎回同一のリストに対してセットするので行った変更は

    def spam(eggs = None):
        if eggs is None:
            eggs = []

    This works, but is ugly, and prevents passing in None as a value for eggs. It would
    be better to be able to simply say:

    eggs の値として None を渡すことができません。

    def spam(eggs = new []):

    which should do exactly what you expect.

^ on bytes
バイト列に対する ^

    A strange oversight in Python3 is that bitwise operators don't work on byte arrays.
    The ^, & and | operators should work on bytes of equal length, doing exactly what
    they obviously should. Trying to apply them to bytes of unequal length should probably
    result in an error. It's easy enough to write functions to do these things, but
    they're slow, and there's only one reasonable semantics for what those operators
    should do on byte arrays anyway.

    Python3 では驚くことにビット操作演算子 (bitwise operators) はバイト配列に対しては
    動作しません。^や&、| といった演算子は長さの等しいバイト列に対しても動作すべき

raw binary conversion

    Maybe this has been added to the standard library and I just haven't heard about it, but
    a longstanding annoying missing piece of functionality is simple conversion between ints
    and big or little endian representations of them as bytes. Again, this is easy enough to
    implement, but is slow when done in Python and is hardly an obscure piece of functionality.

    でしょう。けれども、長い間放置されている機能 (a longstanding annoying missing piece of
    functionality。ちと無理筋?) が int と ビッグエンディアンやリトルエンディアンのバイト列
    これを実装するのはとても簡単なのですが、Python で実装した場合は遅いものになってしまい
    また hardly an obscure piece of functionality なのです。

dictionary scrambling
辞書の scrambling

    This might be an obscure piece of functionality, but I'd like the ability to change
    the hashing function which dictionaries use, because I write tests which depend on my
    code behaving the same way every time it's run, and I'd like to be able to test that
    it doesn't have any dependencies on the order of iterating over dictionary keys or

    これは機能の obscure piece かもしれませんが、わたしは辞書で使用するハッシュ関数を
    依存するテストを記述するためであり、また、辞書のキーや値の iterating over の

■_ parrot


Parrot 3.3.0 "Fire in the Sky" Released! - nntp.perl.org

Parrot 3.3.0 News:
- Core
  + The isa and isa_pmc vtables can now be overridden from PIR
  + IMCC has a new improved external interface
  + A new IMCCompiler PMC adds prototype PDD31-alike functionality for the PIR and PASM compilers
  + New --with-llvm option to Configure.pl, which will link to LLVM if it is available
- Community
  + Parrot Virtual Machine was accepted into Google Summer of Code 2011
- Ecosystem
  + Rosella adds a stable "Event" library to implement a publish/subscribe mechanism
- Tests
  + The test coverage of the extend_vtable subsystem was greatly increased

■_ S.O.L.I.D.

頭字語。 オブジェクト指向に関する五つの原則 (principles) の頭文字の組み合わせらしく。 それぞれの文字がどういう原則を指しているのかは元記事へGo!

OO Design Principles ≪ Valuable Opinions

OO Design Principles

This page is a work in progress… a compilation of information about object-oriented
design principles and values.

S.O.L.I.D. Class Design Principles

Collected by Robert C. Martin for his book “Applying Principles and Patterns”
Interesting collection of OO design principles : programming

■_ AA木


AA木 - Wikipedia
AA木(英: AA tree)は、平衡2分探索木の一種であり、順序のあるデータを効率的に格納し検索
する。Arne Andersson が1993年に発表した[1]。名称は考案者の名前のイニシャルに由来する。


1993年かあ。いいたかないけど、この種のものが日本で売られている「入門書」レベルにまで 載せられることってあるんですかね。




Software Design 誌で、Excel VBA の記事の連載が始まっていた。

■_ What Perl 6 (and 5) Have Done Right

Perl 6 (と Perl 5)が正しく行ったこと。でいいのかな。

What Perl 6 (and 5) Have Done Right - House Absolute(ly Pointless)

What Perl 6 (and 5) Have Done Right
By Dave Rolsky on April 18, 2011 12:46 PM 

I was talking this weekend with Matt Mackall about Python 3 and Perl 6. Matt is the 
creator of Mercurial, so he is deeply invested in Python.

この週末にわたしは Python 3 と Perl 6について Matt Mackall と話しました。
Matt は Mercurial の creator であり、Python を使い込んでいる人物です。

He was asking about the relationship between Perl 5 and Perl 6, and we were comparing 
it with the relationship of Python 2 and 3. His main problem with Python 3, as I 
understand it, is the backwards-incompatible change in string handling from 2 to 3. In 
Python 3, all strings are Unicode by default. Byte arrays are now their own thing, no 
longer interchangeable with strings.

彼は Perl 5 と Perl 6 との関係について尋ねてきました。そこでわたしたちはその関係を
Python 2 と Python 3 との関係と比較してみたのです。
わたしの理解しているところでは、Python 3に関して彼の抱えている主たる問題は
Python 3ではすべての文字列はデフォルトでUnicode です。
Python 3でも存在しているバイト配列はもはや文字列とは interchangeable (交換可能)

Meanwhile, Mercurial is still supporting distributions that are running Python 2.4, 
which is over 6 years old at this point. To make matters worse, Mercurial really 
doesn't benefit from the Unicode-is-everywhere changes in Python 3, so there's little 
incentive to migrate.

ところで Mercurial は現在から 6年以上前のものである Python 2.4 を使っているディストリビューション
をまだサポートしています。悪いことに、Mercurial は Python 3 における Unicode-is-everywhere
という変更から恩恵を受けてはいません。ですから、migrate しようという incentive があまりないのです。

I suspect that eventually Mercurial will be stuck with some sort of compatibility layer that
checks what Python it is running on, and loads the appropriate versions of libraries (or
monkey patches them, or whatever Python people do ;).

わたしはMercurial が 実行されている Python がなんであるのを検査しそして適切なバージョンの
ライブラリをロードする互換レイヤーの類が必要になるであろう (あるいはモンキーパッチを行うか、
さもなければPythonユーザーがやっているようにするか :) と予想しています。

This discussion helped me realize that regardless of any problems Perl 6 has, we've done one
thing really right in the overall Perl community. There's no intention to have Perl 6 replace
Perl 5. Perl 6 has been designed to co-exist with Perl 5. The Perl 6 binary will presumably
be called perl6 (or maybe rakudo), not just perl.

この議論はわたしがPerl 6 の抱えているすべての問題とは関係ないことを realize するのを助け、
we've done one thing really right in the overall Perl community.
Perl 5 を Perl 6 で置き換えようという意図は存在しません。
Perl 6 は Perl 5 と共存できるように設計されています。
Perl 6 のバイナリは Perl 6 (あるいは rakudo) から呼び出されることを想定しています。
単に perl からというものではありません。

Meanwhile, Perl 5 has maintained it's strong commitment to backwards compatibility 
while still pulling in cool bits from Perl 6. This commitment can be frustrating in 
many ways, but its also has benefits. The Perl 5 commitment to prototyping new 
features on CPAN has made for a much cleaner upgrade path. Finally, the fact that 
syntax breakage is almost always opt-in (with use feature or use 5.x), means that we 
can safely upgrade one module at a time to new syntax.

さて、Perl 5 は後方互換性に対する strong commitment を保ってきました。
この commitment は色々不満がでる可能性がありますが benefits のあるものでもあります。
新しい機能をプロトタイピングするための Perl 5 commitment はより明確な upgrade path を形にしました。
結局のところ、syntax breakage はほぼ常に(use feature もしくは use 5.x を伴う)オプトインであることは、
新しい構文一つに対して一つのモジュールを安全に upgrade できることになります。

Of course, Python has from __future__ import, but Python 3 doesn't use that to enable Unicode
everywhere. Even worse, there doesn't seem to be a from __past__ import "old string semantics",
so upgrading to Python 3 requires an entire application (and its dependencies) to upgrade all
at once.

もちろん Python には __future__ import がありますが、Python 3 はこれを Unicode をどこ
__past__ import "old string semantics" のようなものも持っていません。
ですから、Python 3 への upgrade はアプリケーション全体(とそれが依存しているもの)を一度にすべて
upgrade することを要求するのです。

Whatever you think of Perl 6, I think the Perl community can be thankful that Larry had the
foresight to realize that Perl 6 cannot replace Perl 5. Decoupling Perl 6 from Perl 5 has let
the two projects grow at their own pace. If Perl 6 had been officially anointed as the coming
replacement for Perl 5, I doubt we would ever have seen the Modern Perl "movement" emerge,
nor would we have seen the revitalized Perl 5 core development of the past few years.

Perl 6についてあなたがどのように考えているにせよ、
Perl コミュニティは
Larry が Perl 6 は Perl 5を置き換えることはできないことを realize したと公にしたことに

Decoupling Perl 6 from Perl 5 has let the two projects grow at their own pace.
If Perl 6 had been officially anointed as the coming replacement for Perl 5,
I doubt we would ever have seen the Modern Perl "movement" emerge,
nor would we have seen the revitalized Perl 5 core development of the past few years.

Perl 6 と Perl 5 の decoupling はこれら二つのプロジェクトをそれぞれのペースで成長させました。
もし Perl 6 がすでに officially に anointed していたら、
Perl 5 の replacement になるような Modern Perl "movement" の推進や
Perl 5 core development の revitalized を目にすることがあったかどうか

When Perl 6.0 is released, in whatever form that takes, our Perl 5 programs will continue
working for as long as we want. That's a very good thing.

Perl 6.0 がリリースされたとき、それがどのような形式であったとしても、わたしたちが Perl 5 で

This blog is licensed under a Creative Commons License.

Python 2.x と Python 3.x、Perl 5 と Perl 6 ではそれぞれ大きな変化があるけれども その関係はPython のそれと Python とでは違う。という感じなんかな。

■_ Jなんとか


InfoQ: Creating a new JVM language

Last week's announcement of Ceylon brought the focus on JVM-based languages. Ceylon 
isn' the first JVM based language; nor will it be the last. But the general case of 
JVM based languages was proposed in Bruce Tate's Beyond Java in 2005, and has been a 
focus of the Java platform for a significant time, as the list of JVM languages on 
Wikipedia can attest to. Bruce noted that community is the key to success:


There are a number of languages which have been ported to run on top of a JVM runtime, 
including Python (Jython), Ruby (JRuby), Lisp (Clojure) and even Tcl (JTcl). These all 
exhibit the same behaviour as the existing programming languages but run on top of a 
JVM based platform. In most cases, these run faster than their native counterparts; 
but such changes aren't always possible (e.g. see the last flight of the unladen 

JTcl なんてのがあるのか… JTcl: Tcl language interpreter in Java — Project Kenai なにかうれしいことがあるんだろうか?




一応/一様 とか 適用/適応 なんかを混同してたり間違って使ってたりすると ひじょーに気になる。


なんかえらく盛り上がっているのですが結構前の記事だったり。 Some “Developers” Just Can’t Develop : programming

Some “Developers” Just Can’t Develop : Richard Banks - Agile and .NET

Some “Developers” Just Can't Develop
(「開発できない“開発者”もいる」 ってな感じ?)

    * Posted by Richard Banks
    * Aug 25, 2009

I've been interviewing candidates for developer positions for over a decade now.  In 
my early years I was very much hit and miss in terms of finding the right people and 
it wasn't until a horror hire that I realised what I was doing wrong.

This guy was special.  He was listed as being a .NET team lead, he talked about his 
history and skills really well, he was engaging and confident, and his references came 
back glowing with praise so I decided to offer him the job.  This he duly accepted and 
started shortly thereafter.  Now one of the things I was doing with new hires at the 
time was getting them to work on bugs – it helped me knock down the backlog and gave 
them exposure to a variety of areas across the system.  I also gave them plenty of 
time early on to learn the ropes and get up to speed and it would typically take a few 
days to get through the first few bugs and start having some ah-ha! moments with the 

So anyway, this particular person starts and is given his first bug.  Quite a simple 
bug too and yet it took well over a week for him to get it done and even then he 
needed plenty of help and prodding along the way.  I was also getting complaints from 
the other developers that this guy was hopeless and a really bad developer which I 
couldn't quite believe so I decided to take some time, sit down next to him and do 
some pairing.

By doing the fizzbuzz exercise for real, I merely confirmed what I already knew from 
my experiences with the debugging exercise. So, what's the lesson here? I think it's 
simple. Get your candidates to write some code during the interview.  You don't need 
any special tools to do it either – just use a whiteboard and pseudo code if you want 
to.  But whatever you do, make sure they prove to you that they can actually do the 
job, not just talk the job.

Remember: There are plenty of developers that just simply can't develop.  Avoid my 
mistakes and do what you can to avoid hiring the wrong people.

Copyright 2009 | Richard Banks | All Right Reserved


■_ あとでよむ

SIGUSR2 > Parser Combinators Made Simple

SIGUSR2 > Parser Combinators Made Simple

Parsing theory has been around for quite a long time, but it is often thought of as 
magic by the swarms of people who haven't bothered to read about it, and see how plain 
and dry it actually is. Algorithms for parsing LR(k) grammars (meaning Left-to-right, 
Right-most derivation, k tokens lookahead) for instance, normally just traverse a 
state machine that was computed before hand (either by hand, or by using a parser 
generator such as bison or yacc). Sure, there are many things to trip on, tedious to 
track down ambiguities, and other issues, but the general theory of parsing has 
remained unchanged for years—one might say, it is a solved problem.[1]





locale 設定の内容って簡単に確認できましたっけ?

Environment Variables

Environment Variables
    This variable shall determine the locale category for character collation. It
    determines collation information for regular expressions and sorting, including
    equivalence classes and multi-character collating elements, in various utilities
    and the strcoll() and strxfrm() functions. Additional semantics of this variable,
    if any, are implementation-defined.

ここで使うような collating oreder がどうなのか確認したいってのが本題なんですが。




3-5倍ほど速くなったSqueakをぜひともお試しください。 日本語版Squeak 4.2リリース | Umejava's Blog
hello, world レベルで止まってるなあ。他にもあるけど。Erlangとか。

エラーハンドリングについて考える。 - How to disappear completely


pull request とかどんな感じなんだろか。 コードをそういうのがくるところに置いたことがないからわかんないや。

catch phrases - What's the canonical retort to "it's open source, submit a patch"? - Programmers - Stack Exchange

The danger of ever suggesting some feature on a product, especially open source, is 
that you'll get the response, "why don't you do it?".

That's valid, and it's cool that you can make the change yourself. But we know 
practically that products do often improve as programmers listen to the voice of users 
— even if those users are other programmers. And, the efficient way to make those 
changes can include someone who's already working on the project taking up the idea 
and implementing it.

There are some common terms used to refer to software development problems. e.g. 
Bikeshedding. Is there a common term used that essentially replies, "Yes, I know 
that I can change just about anything in the world — even closed source. I could get 
hired, and go write that code. But in this case I'm just making an observation that 
may in fact be useful for another coder already well suited to easily make that change 
— or just generally discussing possibilities."

It's a difficult point: since the user doesn't directly or indirectly pay for a 
product, she cannot ask for a feature to be implemented. It's not as if you were a 
stakeholder or a direct customer who ordered the product, and not even an end user of 
a commercial product.

This being said, "submit a patch" is not a valid answer. It's not polite. 
It's not correct. Even for an open source product. "Submit a patch" is the 
short version of:

    "we don't care if you like our product or not. Go and modify it if you want, 
    but don't bother us with your customer requests."

What about submitting a patch?

Well, it's not so easy. To do it:

    * You must know the language(s) used in the open source project.
    * You must be able to load the source code from the version control to be able to modify it.
    * You must be able to compile this source code, which is not so obvious in some cases. Especially, when a huge project takes a few hours to compile and displays 482 errors and thousands of warnings, you may be courageous to go and search for the source of those errors.
    * You should understand very well how the project is done, what are the coding style to use, if any, how to run unit tests, etc. If the project doesn't have a decent documentation (which is often the case for open source projects), it may be really hard.
    * You must adapt yourself to the project and to the habits of the developers who are participating actively to the project. For example, if you use .NET Framework 4 daily, but the project uses .NET Framework 2.0, you can't use LINQ, nor Code Contracts, nor other thousands of new features of the latest versions of the framework.
    * Your patch must be accepted (unless you do the change only for yourself, without the intent to share it with the community).

If your intention is to actively participate to the project, then you can do all those things and invest your time for it. If, on the other hand, there is just an annoying minor bug or a simple feature which is missing, spending days, weeks or months studying the project, then doing the work itself in a few minutes is just unreasonable, unless you like it.

So is there a canonical retort to "it's open source, submit a patch"? I don't think so. Either you explain to the person that she's impolite, or you just stop talking to her.
    What's the canonical retort to “it's open source, submit a patch”?

There is no reasonable retort that is likely to make any difference. Attempting to 
persuade volunteers to do something that they have no intention of doing is a waste of 
your time ... or worse.

Your options are:

    * Do what the response suggests; i.e. implement the feature and submit it as a patch. It is
      called "giving something back".

    * Find someone who would be willing to implement the feature for you for real money. It
      could be the project itself (e.g. in return for sponsorship), someone associated with
      the project, or some random "coder for hire".

    * Find an alternative product.

If you received this response when you made a "helpful" suggestion, consider 
how you might have responded if you were in his shoes. For instance, how would YOU 
respond if you thought that the suggestion wasn't worthwhile / well-thought-out / 
intelligible / etc, but didn't have the time or patience to engage in a protracted 

I've been involved in a long running open source OS project, and one of the most 
annoying things is people who sit in the "peanut gallery" and pepper you 
with a stream of suggestions about doing things "better" that:

    * are incomplete, unintelligible or downright nonsensical,
    * are untried ideas with an objectively low chance of success,
    * would require a huge amount of effort to implement, and / or
    * are counter to the stated goals of the project.

Often the best response is to pointedly challenge the person to get involved in the 
project ... and hope that they take the hint. Unfortunately, the most annoying ones 
don't even take a hint.

Of course, the other response to such people is to not respond at all, or completely 
ignore them.
site design / logo © 2011 stack exchange inc; user contributions licensed under cc-wiki with attribution required


reddit から。

What's the canonical retort to "it's open source, submit a patch"? : programming

What's the canonical retort to "it's open source, submit a patch"? 

Only after:

    * finding where the code is
    * obtaining a copy using some mechanism
    * Attempting to compile the code
    * Decoding build errors
    * Discovering you need an additional tool to build the source
    * Finding and obtaining and installing the tool
    * Decoding build errors
    * Discovering you need to install/obtain an additional library
    * Finding and obtaining and building the additional library
    * Repeat previous steps until it builds successfully
    * Attempt to run program/library and find it crashes
    * Debug it to find the misconfiguration you introduced in the build
    * Finally get a working copy
    * Finding the code that controls the behavior that you want to change
    * Discover it's hidden behind N+1 layers of abstraction (where N is a sufficiently discouragingly large number)
    * Hack up the patch
    * Search the internet for _DD development to find the philosophy you should've been coding against
    * Rewrite the code to that standard
    * Crying in frustration
    * Arguing about merits of patch with code owners
    * Give up unsatisfied or Fork

"Shut the fuck up you idiot"


■_ 読んだ


そいやこの本、高橋会長も買ったというのをついったで見かけた覚えがあるなあ。 それはさておき。 タイトルにもある「イシュー」(issue) がこの本のポイントなんですが、 どう説明したものか。最重点項目…というのも違うような気がする。 単なるハウツー本(○○をすればよいといった書き方をしていない点で)ではないのですが、 いざ実践となると手が進まない人も少なくないような気がします。 ってそれオレだよ(苦笑)。


OCamlもhello, world レベルなんですが、それはさておき(こればっか)

Camel Spotting in Paris

I'm at the 2011 OCaml Users Group in Paris, reporting on some splendid talks this 
year. It looked like around 60-70 people in the room, and I had the pleasure of 
meeting users all the way from Russia to New York as well as all the Europeans!


First up was Pierre Chambart talking about the js_of_ocaml compiler. It compiles OCaml 
bytecode directly to Javascript, with few external dependencies. Since the bytecode 
format changes very rarely, it is simpler to maintain than alternatives (such as Jake 
Donham's ocamljs) that require patching the compiler tool-chain. Javascript objects 
are mapped to dynamic OCaml objects via a light-weight ## operator, so you can simply 
write code like:


OCaml on a PIC (OCAPIC)

Next up Phillipe Wang presented something completely different: running OCaml on tiny 
8-bit PIC microcontrollers! These PICs have 4-128Kb of flash (to store the code), and 
from 256 bytes to 4 kilobytes. Not a lot of room to waste there. He demonstrated an 
example with a game with 24 physical push buttons that beat humans at a conference 

It works by translating OCaml bytecode through several stages: ocamlclean to eliminate 
dead code in the bytecode (which would be very useful for native code too!), a 
compression step that does run-length encoding, and then translation to PIC assembly. 
They have a replacement stop-and-copy GC (150 lines of assembly) and a full collection 
cycle runs in less than 1.5ms. Integers are 15-bits (with 1 bit reserved) and the 
block representation is the same as native OCaml. Very cool project!


OCaml Future

Xavier “superstar” Leroy then gave an update of OCaml development. Major new 
features in 3.12.0 are first-class modules, polymorphic recursion, local module opens, 
and richer operations over module signatures. Version 3.12.1 is coming out soon, with 
bug fixes (in camlp4 and ocamlbuild mainly), and better performance on x86_64: turns 
out a new mov instruction change improves floating point performance on x86_64.

OCaml 3.13 has no release date, but several exciting features are in the pipeline. 
Firstly, more lightweight first-class modules by permitting some annotations to be 
inferred by the context, and it introduces patterns to match and bind first-class 
module values. Much more exciting is support for GADTs (Generalised Algebraic Data 
Types). This permits more type constraints to be enforced at compile time:


Copyright © 2003-2010 by Anil Madhavapeddy. All rights reserved.

ううむ。またも JavaScript へのコンパイラー。 PIC にOCmalコンパイラーの出力したコードを乗せるってのも面白そう。 It works by translating OCaml bytecode through several stages: あれ、バイトコード出力するものだったのだっけ。




COMIC ZIN という同人誌やら扱っている本屋(といっていいのだろうか?)さんがあって (店舗情報 - COMIC ZIN -)、 その新宿の店舗のほうに長いこと GA 芸術科アートデザインクラス の巨大ポップ(アニメ放映開始のお知らせのやつ)が 入り口付近にあったのですが、今日行ったら撤去されていてがっくし。 まあ二年前だしなあ。

僕らのナムコ80'sトリビュートコミック (CR COMICS DX) 日本ハムに学ぶ 勝てる組織づくりの教科書 (講談社プラスアルファ新書) Rパッケージガイドブック Perl CPANモジュールガイド
「日本ハムに学ぶ~」 は面白かった。 終わりのほうで12球団全部の補強について数ページずつ割いて書かれているのですが、 ベイスターズのそれはいいところついていると思いました。 村田と内川(現ホークス)を FA で出しても~とか (が、そういう意見を言うとmixiの某コミュでは袋叩きだろうなw)。 ファイターズにしても、ただ単に北海道に移転したから優勝できたってわけじゃないんですよね。 勝つための努力をフロント陣もやっていたと。 しかし、ダルビッシュって一本釣りだったんだよなあドラフト。 今から思い返すと信じられないというかなんというか。 この本についてはもうちょっと書こう。

■_ Ceylon


Ceylon: Interesting for the Wrong Reasons - lockster's posterous

April 15, 2011

Ceylon: Interesting for the Wrong Reasons

A couple of days ago, Gavin King announced that he is leading a team at RedHat that's 
creating a new JVM language called Ceylon. See here for most of what is known so far. 
The stated motivation, in a nutshell is that they like Java very much, but it has 
deficiencies that are preventing progress in key areas, and they are generally feeling 
“frustrated”. They don't have a complete compiler yet, but they're working on it, 
and I get the impression RedHat is pretty serious about it.

二日ほど前に、Gavin King は彼が Red Hat の Ceylon と呼ばれている新しいJVM 言語を作っている
Red Hatはとても真剣にそれに取り組んでいるという印象をわたしは受けました。

Gavin King's slides provide a fascinating insight into the kind of thinking that 
remains so dominant in the Java community. Gavin King is well known in the Java world 
as the inventor/leader of Hibernate and various other JBoss projects. He certainly 
knows Java inside out, and his list of “frustrations” is astute, if incomplete. 
While I haven't dug into all the details so far revealed about Ceylon, but it seems 
likely that they'll succeed in their goal of creating “a better Java”. If given the 
choice between using Java and Ceylon, I could certainly see myself choosing Ceylon. 
But Ceylon is a terrible idea. The problem is that they are treating the symptoms, not 
the disease; and they're repeating exactly the same mistakes that resulted in them 
finally hitting a dead-end with Java.


Scala aims to be compatible with Java, but it's about much more than just “a better 
Java”. Ironically, it seems as though Ceylon will not interoperate with Java as 
seamlessly as Scala does (e.g. Scala keeps null and type erasure). It'll be 
interesting to see how that works out. To get an idea of how serious the Scala team is 
about powerful but practical abstractions, look at how they handle the tensions that 
crop up between abstraction and performance. Great examples of this are how Scala 
deals with the unpleasantness of arrays on the JVM, and also the @specialized 

Scala は Java との互換となることを目指していますが、単なる“a better Java”
を越えるものです。皮肉なことに、Ceylon はScala とは違ってJavaとの
interoperate を持たないように見受けられます(たとえば Scala は null と
type erasure を残しています)。
It'll be interesting to see how that works out.
この greate example が、Scala ではどのように
JVM 上の配列の unpleasantness と @specialized アノテーションを扱っているか

Scala is by no means perfect. The trade-offs it makes will not suit everyone fully. 
But I cannot help but scratch my head over statements like this (Gavin King, again):

Scala は完璧ではなく、そこにあったトレードオフはすべての人を満足させるものでは
ないでしょう。とはいっても、Gavin King が言っているような
statmentes には scratch my head せざるを得ません。

But I guess I should mention that the number one technical problem that we simply 
can't solve to our satisfaction in Java – or in any other existing JVM language – is 
the problem of defining user interfaces and structured data using a typesafe, 
hierarchical syntax.

とはいえ、Java 、あるいは既存のJVM言語ではではわたしたちが満足できるような形で
それはユーザーインターフェースの定義の問題と、typesafe を使い

I could very well be missing something, but this would seem like a problem that is 
right in Scala's wheelhouse. Perhaps it may not be solved satisfactorily today, but it 
could done with far less effort than creating a whole new language (and new standard 
library, and new tool chain…). It is depressing to think of what these guys could 
achieve working with Scala instead of pouring resources into Ceylon.

この人たちが Ceylon にリソースをつぎ込むのではなく
Scala に注力するかもしれないと考えるのは気の滅入ることです。

You may wonder, “if you think Scala is so good, then use it and be happy, why worry 
about Ceylon?” Well, I worry because I think Ceylon is worse than Scala, but it could 
win anyway. That actually seems to be the more common outcome in these situations. I 
would much prefer a world with Scala jobs in demand than one with Ceylon jobs in demand.
So, yes, it's all about me being selfish. I would say to all Scala fans: don't be
afraid to be a little selfish and evangelise for the better outcome.

なんだって Ceylon の心配をしているの?」と思われるかもしれません。
確かに気にかけていますが、それは Ceylon が Scala よりもひどいものであるのに
That actually seems to be the more common outcome in these situations.
わたしは  Ceylon での仕事が求められる世界よりもScalaでの仕事が求められる世界のほうが
So, yes, it's all about me being selfish.
すべての Scala ファンに少々利己的になることを恐れずよりよい outcome を evangelise しようと

■_ シャッフル


Excelで整数ランダムにだすには - 質問・相談ならMSN相談箱

整数 1~50 同じ整数を重複しない

まあ、シャッフルだよねえと思ってたら 回答のひとつで紹介されていたものに興味深いものが。

重複しない乱数の作成-RAND関数・RANK関数:Excel エクセルの使い方-関数/計算式-数学


なるほどこれなら Excel のセル関数だけでできますわな。

■_ 今日の丸投げ

どう考えても丸投げだよなあ。この辺と併せて。 awkで行ごとの計算について | OKWave awkでのsh処理について | OKWave

awkの得意な人に聞いても結構難しいといっていたので、 どーこーがー

awkでの処理 | OKWave




~OUT   ★ここを削除したいです。





単に同じ行があったら削除するなら、uniq or sortコマンドで同行は表示しないオプションがあったと思います。HP-UXでもあったのでは・・・



sort|uniq -[忘れた。上記URL確認] xxxx.txt | awk { xxxx }




以下のように重複行を削除する sort- uとかuniq 文字列指定は使えないのですよ。正直


13001234 "性能情報:20110412000455278_02OUT"
13001234 "性能情報:20110412000455283_02_IN"
13001234 "性能情報:20110412000502719_01OUT"
13001234 "性能情報:20110412000502724_01_IN"
13001234 "性能情報:20110412000832155_01OUT"
13001234 "性能情報:20110412000832159_01_IN"
13001234 "性能情報:20110412001243737_01OUT"
13001234 "性能情報:20110412001243742_01_IN"
13001234 "性能情報:20110412001347455_06OUT"
13001234 "性能情報:20110412001347459_06_IN"
13001234 "性能情報:20110412001652405_01OUT"
13001234 "性能情報:20110412001652410_01_IN"
13001234 "性能情報:20110412001844606_01OUT"
13001234 "性能情報:20110412001844612_01_IN"
13001234 "性能情報:20110412002258567_05OUT"
13001234 "性能情報:20110412002258572_05_IN"
13001234 "性能情報:20110412002410587_01OUT"
13001234 "性能情報:20110412002410591_01_IN"
13001234 "性能情報:20110412002505697_04OUT"
13001234 "性能情報:20110412002505701_04_IN"
13001234 "性能情報:20110412002911876_01OUT"
13001234 "性能情報:20110412002911881_01_IN"
13001234 "性能情報:20110412003125409_01OUT"
13001234 "性能情報:20110412003125414_01_IN"
13001234 "性能情報:20110412003148432_07OUT"★
13001234 "性能情報:20110412003148451_01OUT"
13001234 "性能情報:20110412003148456_01_IN"
13001234 "性能情報:20110412003719949_01OUT"
13001234 "性能情報:20110412003719954_01_IN"
13001234 "性能情報:20110412003857663_01OUT"
13001234 "性能情報:20110412003857668_01_IN"
13001234 "性能情報:20110412004020388_01OUT"
13001234 "性能情報:20110412004020393_01_IN"
13001234 "性能情報:20110412004353569_01OUT"
13001234 "性能情報:20110412004353573_01_IN"
13001234 "性能情報:20110412004553447_01OUT"
13001234 "性能情報:20110412004553452_01_IN"
13001234 "性能情報:20110412004614347_01OUT"
13001234 "性能情報:20110412004614352_01_IN"
13001234 "性能情報:20110412005335553_01OUT"



{if(save!=""){print save;save=""};print}
END{if(save!="")print save}





なんだ 3000ステップの sh て。


awkでの処理 | OKWave




そのまま使えるスクリプトがある方を指して、~のロジックで。と来たもんだ。 また勉強させて下さい!! (ぴーっ)

■_ Lispの呪い


The Lisp Curse

The Lisp Curse

by Rudolf Winestock

This essay is yet another attempt to reconcile the power of the Lisp programming 
language with the inability of the Lisp community to reproduce their pre-AI Winter 
achievements. Without doubt, Lisp has been an influential source of ideas even during 
its time of retreat. That fact, plus the brilliance of the different Lisp Machine 
architectures, and the current Lisp renaissance after more than a decade in the 
wilderness demonstrate that Lisp partisans must have some justification for their 
smugness. Nevertheless, they have not been able to translate the power of Lisp into a 
movement with overpowering momentum.

In this essay, I argue that Lisp's expressive power is actually a cause of its lack of 

このエッセイでは、Lisp の expressive power というものが実際には
momentum (勢い、慣性)が欠如しているためだということを主張します。

The power of Lisp is its own worst enemy.
Lisp のパワーというものそれ自身が最悪の敵を抱えています。

Here's a thought experiment to prove it: Take two programming languages, neither of 
which are object-oriented. Your mission, if you choose to accept it, is to make them 
object-oriented, keeping them backward-compatible with the original languages, modulo 
some edge cases. Inserting any pair of programming languages into this thought 
experiment will show that this is easier with some languages than with others. That's 
the point of the thought experiment. Here's a trivial example: Intercal and Pascal.

Now make this thought experiment interesting: Imagine adding object orientation to the 
C and Scheme programming languages. Making Scheme object-oriented is a sophomore 
homework assignment. On the other hand, adding object orientation to C requires the 
programming chops of Bjarne Stroustrup.

The consequences of this divergence in needed talent and effort cause The Lisp Curse:

才能と努力を必要とするようなこの divergence (相違、逸脱)の結果として

Lisp is so powerful that problems which are technical issues in other programming 
languages are social issues in Lisp.

Lisp は他の言語では技術的な issue となるような問題が social な issue になってしまう

So why don't the Lisp hackers put the Smalltalk guys in their proper place? Why don't 
they make a free development system that calls to mind some of the lost glories of the 
LispM, even if they can't reproduce another LispM?

The reason why this doesn't happen is because of the Lisp Curse. Large numbers of Lisp 
hackers would have to cooperate with each other. Look more closely: Large numbers of 
the kind of people who become Lisp hackers would have to cooperate with each other. 
And they would have to cooperate with each other on a design which was not already a 
given from the beginning. And there wouldn't be any external discipline, such as a 
venture capitalist or other corporate master, to keep them on track.

Every project has friction between members, disagreements, conflicts over style and 
philosophy. These social problems are counter-acted by the fact that no large project 
can be accomplished otherwise. "We must all hang together, or we will all hang 
separately." But the expressiveness of Lisp makes this countervailing force much 
weaker; one can always start one's own project. Thus, individual hackers decide that 
the trouble isn't worth it. So they either quit the project, or don't join the project 
to begin with. This is the Lisp Curse.

スタイルや哲学についての意見の相違があり、confilict があります。
こういった social な問題は accomplissed otherwise できない
大規模プロジェクトが存在していないという事実によって counter-acted されます。
"We must all hang together, or we will all hang separately."
しかし Lisp の expressiveness はこの countervalling force を格段に弱めてしまい、
This is the Lisp Curse.

One could even hack Emacs to get something that's good enough. Thus, the Lisp Curse is 
the ally of Worse is Better.

The expressive power of Lisp has drawbacks. There is no such thing as a free lunch.
Lisp の expressive power には drwabacks (欠点、短所)があります。
ただ飯 (free lunch) のようなものはないのです。

Copyright © (2011) Rudolf Winestock, All Rights Reserved.

This essay was published on Friday, April 15, 2011.

■_ Lisp Is Not An Acceptable Java

もうひとつ Lisp ネタ。

Lisp Is Not An Acceptable Java

Lisp Is Not An Acceptable Java

2011-04-01 08:34

Every once in a while, some kid discovers Lisp and thinks, “hey, that's actually a pretty neat language, why not use it for more than just school?” Well, there are reasons not to do that. Lots of them, actually. That's because Lisp just can't compete with Java in almost any imaginable way.

Lisp is not Web-ready

First of all, since Lisp has only one data structure—lists—it has no way of representing XML or HTML data. Since XML is the basis of the Web, you cannot provide enterprise-ready web services using Lisp as you can in Java. So what are you going to do with it? Exactly. You might as well stop at this point.
Lisp does not support enterprise features

In Lisp, there is built-in support for neither SOAP nor CORBA. This alone makes the language impossible to use in an enterprise setting, since there is no way of accessing cloud-computing or multi-tenancy services without being able to encode requests in enterprise-ready cloud communication formats.

Lisp is slow

You would think that with electrical energy becoming more expensive each day, people cared about efficiency and scalability. Not so—anyone using Lisp is using an interpreted language with huge memory requirements. Also, you can't use Lisp in an interactive application, since garbage collection can kick in at any time and stop your program for a couple of seconds at a time.

In contrast, Java and C# programs are compiled into efficient bytecode and run on an advanced, highly optimized virtual machine. Also, specialized CPUs like ARM Jazelle grant Java applications native performance—Lisp just can't compete with this because it is much too complex to implement on the metal.

Lisp is too old to be useful

Did you know that Lisp is from the 50s? It hasn't changed a bit since then. It's still the same academic parenthesis mess lacking any kind of consistency or reasonable design, and it's still all based on lists. This is in contrast to C# and Java, which are much more modern designs based on real-world experience with enterprise C++ application programming.

Lisp does not have any advantages

I know, I know, Lisp was innovative for its time. That time is long over, though. Other languages have a GC, other languages have slow interpreters, and other languages have a REPL. Get over it.
Lisp is inappropriate for teams

Granted, there is one thing that Lisp has which other languages still lack: macros. But really, using macros in production code is a disaster waiting to happen. With functions, you at least know what the evaluation rules are. But what if you call a macro like the following?

(with-open-file (file "test.txt" :direction :output)
  (print "hello" file))

This might open a file called “test.txt” and write “hello” into it—or it might reformat your hard drive! How are you to know?

Things like this make Lisp impossible to use in a team setting. Give people too much freedom, and they will do stupid things with it, annihilating any hope of documenting the resulting mess or, God forbid, making it maintainable. Enterprise languages like Java abort compilation even when dead code is detected. This makes debugging much easier.

Lisp's features have become obsolete

As can be seen in enterprise C++ applications, garbage collection is pretty much an obsolete feature, since data is practically never managed manually within the program. Instead, everything is stored in highly optimized XML databases, which gives you more flexibility and scalability. Other features, like CLOS and the condition system, have similarly become obsolete by advancing technology.
Face it: Noone cares about “interactive programming”

Then there's this neverending talk about “interactive programming,” as if that was something desirable. In Lisp, you apparently type stuff into the REPL instead of writing it into files. Great! Except... you can't store the code in files that way. Lispers tend to learn their lesson the hard way, as all code is lost when you need to reboot your computer. But then again, noone bears to write Lisp code more than 100 lines long anyway, so it probably doesn't matter much.

Tool support is stuck in the '70s

Whenever you see a misguided newbie ask on an online forum which IDE they should use for Lisp, the answer is always the same: Emacs. Really. These guys prefer an editor from the 70s over an enterprise-class IDE like Netbeans or Microsoft Visual Studio with innovative features like syntax highlighting and documentation lookup. Masochism is the only valid reason for this, but since you need to be a masochist to program in Lisp in the first place, that's not surprising.

Practically all Lispers are Smug Lisp Weenies that are a bitch to deal with

Really, the most annoying aspect of Lisp is that its followers are smug weenies. Every single one of them. You can see this on Usenet: Whenever someone writes an objective article about the benefits and disadvantages of Lisp (like this one, for example), the trolls come out and hammer you with flames. How can a community expect to garner support for its cause if it reacts so hostilely to constructive criticism?

The fact that so much of the Lisp community is centered around Usenet is a bad sign in and of itself. Do you think that successful companies like Google or Amazon ask Usenet for support? Get a grip on reality here for a moment. Real programmers don't rely on net punks for support. They have learned to buy commercial-grade enterprise support, and so should you. Good luck finding a Lisp support company, though—they've gone extinct around 30 years ago.

Lisp is used by noone

Because of all of the above, nobody actually uses Lisp for anything that approaches real-world programming. In contrast, lots of people have made real money using Java and .NET. Everyone knows that swimming against the tide is equivalent to doom. Therefore, it would be prudent to do it like the big ones and avoid Lisp like the plague.

Noone can read Lisp syntax

Finally, just look at the following typical piece of Lisp code:

((lambda([])((lambda(|| |()| |(| |)|)(+ || |(| 1 |)| |()| |(| |(| |(|)) [] [] [] [])) 0)

It's true, that's completely valid, real-world code! Can you guess what it does? Yeah, me neither. And did you notice that the parentheses aren't even balanced? Simple syntax—yeah, right.


You can draw your own conclusions based on the points above. However, before you do 
that, I advise you to take a close look at this article's publishing date. Happy 




よんまんえんかあ。 パルコ、『攻殻機動隊 S.A.C.』に登場する"笑い男"のジャケットを商品化 | ホビー | マイコミジャーナル

■_ 掛け算


code golf - Long multiply, 8 bits at a time - Programming Puzzles & Code Golf - Stack Exchange

You are given a 16-bit machine and told to implement multiplication of arbitrary-sized 
integers. Your registers can only hold 16-bit numbers, and the biggest multiply 
instruction takes two 8-bit inputs and generates a 16-bit result.


Your program must take as input two arbitrary-sized positive numbers and output their 
product. Each input number is encoded on its own line as a little-endian byte array 
where each byte is a 2-digit hex number. The output must be similarly formatted. 
Perhaps best explained with an example:



1f 4a 07
63 a3


fd 66 03 a7 04

which encodes the multiplication 477727*41827=19981887229.
これは 477727*41827=19981887229 をエンコードしたものです。

You can assume that the last (most significant) byte of each input number is nonzero, 
and the last chunk of the number you output must be nonzero. Both input numbers will 
be at most 100 bytes long.

また、出力する数値の最後の塊 (chunk) はゼロであってはなりません。

Smallest code wins.

Remember, the biggest multiply you are allowed to use is 1 byte * 1 byte, and no 
integer types bigger than 2 bytes!

Perl, 137 characters

($x,$y)=<>;while($x=~s/.. *//s){$e=hex$&;$i=0;$s=$r[$i]+=$e*hex,$r[$i]&=255,$r[++$i]+=$s>>8 for$y=~/.. */gs;$y="00$y"}printf'%02x 'x@r,@r


    * Sometimes prints an extra 00 byte at the end of the result. Of course the result is
      still correct even with that extra byte.

      結果の最後に余計な 00 のバイトが出力されることがあります。

    * Prints an extra space after the last hex byte in the result.

      結果の最後の hex byte のあとに余計なスペースが出力されます。


The explanation is going to be a bit long, but I think most people here will find it 


First of all, when I was 10 years old, I was taught the following little trick. You 
can multiply any two positive numbers with this. I will describe this using the 
example of 13 × 47. You start by writing the first number, 13, and dividing it by 2 
(round down each time) until you reach 1:

わたしが十歳の頃のことですが、これから説明するような little trick を考えました。


Now, next to the 13 you write the other number, 47, and keep multiplying it by 2 the 
same number of times:


13     47
 6     94
 3    188
 1    376

Now you cross out all the lines where the number on the left is even. In this case, 
this is only the 6. (I can't do strike-through in code, so I'll just remove it.) 
Finally, you add all the remaining numbers on the right:


13     47
 3    188
 1    376

And this is the right answer. 13 × 47 = 611.

そしてこれが正しい答えで、13 × 47 = 611 となります。

Now, since you are all computer geeks, you will have realised that what we're 
actually doing in the left and right columns is x >> 1 and y << 1, 
respectively. Furthermore, we add the y only if x & 1 == 1. This translates 
directly into an algorithm, which I'll write here in pseudocode:


input x, y
result = 0
while x > 0:
    if x & 1 == 1:
        result = result + y
    x = x >> 1
    y = y << 1
print result

We can re-write the if to use a multiplication, and then we can easily change this so 
that it works on a byte-by-byte basis instead of bit-by-bit:

input x, y
result = 0
while x > 0:
    result = result + (y * (x & 255))
    x = x >> 8
    y = y << 8
print result

This still contains a multiplication with y, which is arbitrary-size, so we need to 
change that into a loop too. We'll do that in Perl.

Now translate everything to Perl:

    * $x and $y are the inputs in hex format, so they have the least significant byte first.

    * Thus, instead of x >> 8 I do $x =~ s/.. *//s. I need the space+star because the
      last byte might not have a space on it (could use space+? too). This automatically puts
      the removed byte (x & 255) into $&.

    * y << 8 is simply $y = "00$y".

    * The result is actually a numerical array, @r. At the end, each element of @r contains
      one byte of the answer, but halfway through the calculation it may contain more than one
      byte. I'll prove to you below that each value is never more than two bytes (16 bits)
      and that the result is always one byte at the end.

So here is the Perl code unravelled and commented:

# Input x and y
($x, $y) = <>;

# Do the equivalent of $& = x & 255, x = x >> 8
while ($x =~ s/.. *//s)
    # Let e = x & 255
        $e = hex $&;

    # For every byte in y... (notice this sets $_ to each byte)
    $i = 0;
    for ($y =~ /.. */gs)
        # Do the multiplication of two single-byte values.
        $s = $r[$i] += $e*hex,
        # Truncate the value in $r[$i] to one byte. The rest of it is still in $s
        $r[$i] &= 255,
        # Move to the next array item and add the carry there.
        $r[++$i] += $s >> 8

    # Do the equivalent of y = y << 8
    $y = "00$y"

# Output the result in hex format.
printf '%02x ' x @r, @r

This concludes a wonderful and exciting challenge. Thanks a lot for posting it!
OCaml + Batteries, 362 characters

A standard O(n*m) schoolboy multiplication algorithm. Note that in order to meet the 
challenge requirements, the operations are done on the bytes of strings, which in 
OCaml are (conveniently, in this case) mutable. Note also that the accumulator s never 
overflows 16 bits, since 2(2^8 - 1) + (2^8 - 1)^2 = (2^8 - 1)(2^8 + 1) = 2^16 - 1.

let m a b=Char.(String.(let e s=of_list(((^)"0x"|-to_int|-chr)@nsplit s" ")in
let a,b=e a,e b in let m,n=length a,length b in let c=make(m+n)'\000'in
iteri(fun i d->let s,x=ref 0,code d in iteri(fun j e->let y=code e in
s:=!s+code c.[i+j]+x*y;c.[i+j]<-chr(!s mod
256);s:=!s/256)b;c.[i+n]<-chr!s)a;join" "((code|-Printf.sprintf"%02x")@to_list c)))

For example,

# m "1f 4a 07" "63 a3" ;;
- : string = "fd 66 03 a7 04"

# m "ff ff ff ff" "ff ff ff ff" ;;
- : string = "01 00 00 00 fe ff ff ff"

C Solution

This solution does no input validation. It's also only lightly tested. Speed was not 
really a consideration. Malloc's memory, and isn't particularly clever about how much 
it grabs. Guaranteed to be enough, and more than necessary.


m() accepts a string, expects two newlines in the string, one after each number. 
Expects only numbers, lowercase characters, spaces, and newlines. Expects hex digits 
to always be a pair.

No multiply operation is ever used (knowingly). Shifting is performed on 8-bit 
variables. One 16-bit addition is performed. No 32-bit data types.

Shrunk by hand, and only mildly. edit: more obfuscation, fewer chars :D Compiles with 
warnings with gcc.

Characters: 675

typedef unsigned char u8;
#define x calloc
#define f for
#define l p++
#define E *p>57?*p-87:*p-48
#define g(a) --i;--a;continue
void m(u8*d){short n=0,m=0,a,b,i,k,s;u8*t,*q,*r,*p=d,o;f(;*p!=10;n++,l){}l;f(;*p
+b-1:b+a;f(i=0;i<k;i++){printf("%02x ",r[i]);}putchar(10);}

You can test with this:

int main(void){
  m("1f 4a 07\n63 a3\n");
  m("ff ff ff ff\nff ff ff ff\n");
  m("10 20 30 40\n50 60 70\n");
  m("01 02 03 04 05 06\n01 01 01\n");
  m("00 00 00 00 00 00 00 00 00 00 00 00 01\n00 00 00 00 00 00 00 00 02\n");
  return 0;


$ ./long 
fd 66 03 a7 04 
01 00 00 00 fe ff ff ff 
00 05 10 22 34 2d 1c 
01 03 06 09 0c 0f 0b 06 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 


■_ 電卓プログラム


数値リテラルの正規表現 | OKWave

VB6でMicrosoft Script ControlとMicrosoft VBScript Regular Expressions 5.5を使っています。

Script Controlに入力するVBScript文字列において

(1.234 * -.324e+34) & "5,678" & (6.553 / 2.456) & "abc9.876def"
(SomeFunc("1.234") & SomeFunc("-.324e+34")) & ("5,678") & (SomeFunc("6.553") / SomeFunc("2.456")) & "abc9.876def"



正規表現の使い方を間違っているような… もちろん、対象を取り出すのに使うのはいいんだけど トークン列を切り出す形で解析したほうがいいと思うのだけど。



■_ ブートストラップ

reddit に投げられていた質問。

A question about pypy : Python

I'm not exactly a Python noob but I haven't used it in a while and I have zero 
experience with hacking Python, writing modules in C, really doing much of anything 
with C.

So my question: I know that pypy is implemented in Python and I understand what the 
goals of the project are. What I get tripped up over is the "Python implemented 
in Python" bit. Does this mean that it's Python implemented in pure CPython? It 
would seem like it would have to be (OK, it could be implemented in Iron Python or 
Jython I guess). This is sort of a prime mover problem - Python can't just run on its 
own i.e. it's not machine code.

On the pypy Wikipedia page, it discusses the interpreter and translator which pypy is 
built upon but this just sounds like regular CPython to me. I don't see how the 
interpreter could be implemented in pure Python (I don't think it is). In other words, 
I feel like pypy is just using a different interpreter than CPython and isn't all that 

If anyone can explain this to me, I'd appreciate it.

EDIT: thanks for all of the replies, I think I get it now.

pypy はPython 処理系を Python で実装しようというものだというのなら、 その最初の処理系は…という話。たぶん。 まあ最初のコンパイラーはどうやって、的な話ですね。




■_ R

なんとかビルドには成功。 なぜか途中で /tmp でディレクトリを掘れないといって ビルドが中断しちゃう現象がでてたんだけど


       @$(MKINSTALLDIRS) $(top_builddir)/library/$(pkg)/R
       @(f=$${TMPDIR:-/tmp}/R$$$$; \
         if test "$(R_KEEP_PKG_SOURCE)" = "yes"; then \
           $(ECHO) > "$${f}"; \
           for rsrc in $(RSRC); do \
             $(ECHO) "#line 1 \"$${rsrc}\"" >> "$${f}"; \
             cat $${rsrc} >> "$${f}"; \
           done; \
         else \
           cat $(RSRC) > "$${f}"; \
         fi; \
         $(SHELL) $(top_srcdir)/tools/move-if-change "$${f}" all.R)

環境変数 TMPDIR を適当に設定してやったらビルドが通るようになった。 Vista以降だと、ルートに一時ファイル作ったりが(Administratorあたりでないと) できなくなってるけどこの現象はなんだろう。

が、まだライブラリが足りなかったりするのかオプション指定が悪いのか 日本語メッセージがでてこない(笑)

■_ プログラミング言語を作るには


Questions on the making of programming lanuages. - Stack Overflow

I'm new to programming.. But I would like to know how programming languages begin; I'm 
a Windows os user, and everything seems so vast. So, my question is, how do 
programmers get from that blank screen, to building their own programming language.

Also, are many new languages made? And are any made home-brewed?


Red Hat発の新言語とか。 スライドから適当に抜き出し。 Introducing the Ceylon Project

About this session 
  I'm going to talk about why we started work on this project 
  I'm going to cover some basic examples at a very shallow level 
  I'm not going to get into the details of the type system 
  If you're interested, come to my second presentation: “The Ceylon Language” 
  This project is not yet available to the public and has not even been officially announced 
  QCon China is getting a special sneak preview - the first time I'm talking about the project in public! 

Why we're (still) fans of Java (Javaのどこがいいと思っているのか)

  Java was the first language to feature the following “perfect” combination of features:
  Java は以下のような“完全な”機能の組み合わせを持つ最初の言語でした

  virtual machine execution, giving platform independence 
  automatic memory management and safe referencing 
  static typing 
  lexical scoping 
  readable syntax 

  Therefore, Java was the first language truly suitable for large team development, and 
  large-scale deployments of multi-user applications.

  したがって、Java は大規模チームによる開発や
  に対して真に suitable である最初の言語であったのです

  It turns out that large teams developing multi-user applications describes the most
  interesting class of project in business computing 
Why we're frustrated (何を不満に感じているのか)

  After ten often-frustrating years developing frameworks for Java, we simply 
  can't go any further without a better solution for defining structured data and 
  user interfaces

  Java is joined at the hip with XML, and this hurts almost every Java 
  developer almost every day

  There is simply no good way to define a user interface in Java, and that is 
  a language problem

  Java にはユーザーインターフェースを定義する単純で優れた方法がありません

  Lack of a language-level modularity solution resulted in the creation of 
  monstrous, over-complex, harmful technologies like Maven and OSGi.

  Maven や OSGi のような巨大で複雑極まりない有害な技術を生み出すことになりました

  Instead of modules, Java has multiple platforms, which has divided the 
  developer community

  Lack of support for first-class and higher-order functions results in much 
  unnecessary verbosity in everyday code

  関数が first-class でないことや高階関数が欠如していることはその結果として

  Meta-programming in Java is clumsy and frustrating, reducing the quality of 
  framework and other generic code 

  Java におけるメタプログラミングは不恰好で不満が残るものであり、フレームワークや

抜いた部分も結構面白いので一読をオススメ。 Scala や Clojure とかと比べてどうなんだろか(JVM上の言語というあたりで)。





JavaScript「に」コンパイル(変換)する言語ってのを見ていると、 Guile の初めの頃の Stallman の言っていたアイデアもそれほど捨てたもんじゃなかったのかなあ などと思ったり。

■_ 今日のお題


grepでの抽出箇所のみ置換して上書き | OKWave

find ./ -name file_name -exec grep -B 2 "earth" {} \; -print | grep "moon"
planetkind moon
『 planetkind moon』
『 planetkind taiyo』

find ./ -name file_name -exec grep -B 2 "earth" {} \; -print | grep "moon" | xargs sed -i "s/moon/taiyo/"




sed "s/moon/taiyo/"
って, 「moon を taiyo に置き換える」ってことでしょ?
「planetkind moon」を「planetkind taiyo」に変更するなら, そのように書かないと.



planetkind moon を planetkind taiyoに変えたいのです。

他の行にもplanetkind moonという行は存在するのです。

Perl あたりで書けばいいような…。


やっぱりお金の話だと伸びますねー The Programmer Salary Taboo : programming

The Programmer Salary Taboo

The Programmer Salary Taboo


Salary is an interesting topic. It's certainly one everyone has an opinion on. It's 
also a uniquely taboo subject among members of the working public. Since I'm about a 
month away from being done with University and entering the programmer workforce, I've 
taken to asking my classmates what type of starting salaries they're getting at their 
first jobs. The first thing I discovered is that not everybody is very comfortable 
with this question, and many companies are even less so. Microsoft requests very 
firmly that recipients of their offers keep their salary offers confidential, for 







落し物したらしい ○| ̄|_

■_ 電卓


将来プログラマーになりたいんですけど、電卓くらいのプログラムは、つくれるよう... - Yahoo!知恵袋



yacc やら bison のマニュアルでもいいんだろうかw

■_ このスクリプトは


awkを使用して整形 | OKWave

10:00:00 disk1 10
disk2 15
disk4 14
10:00:05 disk1 13
disk3 20
10:00:10 disk1 30


10:00:00 disk1 10
10:00:00 disk2 15
10:00:00 disk3 0
10:00:00 disk4 14
10:00:05 disk1 13
10:00:05 disk2 0
10:00:05 disk3 20
10:00:05 disk4 0
10:00:10 disk1 30
10:00:10 disk2 0
10:00:10 disk3 0
10:00:10 disk4 0




cat data.txt | awk \
'BEGIN { strTIME="00:00:00" }
num=split($0,ARY," ")
if (num==3) {
printf("%s %s %s\n",strTIME,ARY[2],ARY[3])
if (num==2) {
printf("%s %s %s\n",strTIME,ARY[1],ARY[2])
END { }' | awk \
'BEGIN { strTIME="" }
if (strTIME!="" && strTIME!=$1) {
for (i=1;i<5;i++) {
strDISK="disk" i
if (strDATA[strDISK]=="") strDATA[strDISK]="0"
printf("%s disk%d %s\n",strTIME,i,strDATA[strDISK])
for (i=1;i<5;i++) {
strDISK="disk" i
if (strDATA[strDISK]=="") strDATA[strDISK]="0"
printf("%s disk%d %s\n",strTIME,i,strDATA[strDISK])



	prevtime = time = "00:00:00"
	diskmax = 4
	prev = 0
NF == 3{
	prevtime = time
	time = $1
	number = disk = $(NF-1)
	count = $NF
	sub(/^[^0-9]*/, "", number)
	sub(/[0-9]*$/, "", disk)
	#print "number=", number, "prev=", prev

	if (number <= prev) {
		for (i=prev+1; i<=diskmax; i++)
			print prevtime, (disk i), 0
	else if (number > prev+1) {
		for (i=prev+1; i<number; i++)
			print time, (disk i), 0

	print time, (disk number), count
	prev = number
	if (prev == diskmax)
		prev = 0
	for (i=prev+1; i<=diskmax; i++)
		print time, (disk i), 0


■_ それは土曜日の読書会で散々見た…

shiro さんのところの4/11づけのものから。本文はおいといて

Island Life - グラフ指向理解
     Γ, x:T1 ⊢ t2 : T2
     Γ ⊢ λx:T1.t2 : T1 → T2 

先週土曜日のTAPL読書会で悪戦苦闘した式ではありませんか(^^; あれ、Tree だっけ? (かばんにしまったまま>TAPL)

Types and Programming Languages

■_ あとで読む

What is the PDP-8 instruction set?

The PDP-8 word size is 12 bits, and the basic memory is 4K words.  The
minimal CPU contained the following registers:

	PC - the program counter, 12 bits.
	AC - the accumulator, 12 bits.
	L  - the link, 1 bit, commonly prefixed to AC as <L,AC>.

It is worth noting that many operations such as procedure linkage and
indexing, which are usually thought of as involving registers, are done
with memory on the PDP-8 family.

Instruction words are organized as follows:


Last Update February 04 2011 @ 07:23 AM

Some parts © 2011 Advameg, Inc.  |   Terms of Use


Category Theory for the Java Programmer ≪ reperiendi

Category Theory for the Java Programmer

4. Cartesian

A cartesian category has lists as its objects. It has a way to put objects together
into ordered pairs, a way to copy objects, and an object that's “the empty” object.

カルデシアン圏は複数のオブジェクトを orderd pair に押し込む手段と、

It's time to do the magic! Recall the interface Category:
Category インターフェースを思い出してみましょう:

	interface Category {
	  interface Object {}
	  interface Morphism {}
	  class IllegalCompositionError extends Error;
	  Object source(Morphism);
	  Object target(Morphism);
	  Morphism identity(Object);
	  Morphism compose(Morphism, Morphism)
	    throws IllegalCompositionError;

Now let's change some names:

	interface Interface {
	  interface InternalInterfaceList {}
	  interface ComposableMethodList {}
	  class IllegalCompositionError extends Error;
	  InternalInterfaceList source(ComposableMethodList);
	  InternalInterfaceList target(ComposableMethodList);
	  ComposableMethodList identity(InternalInterfaceList);
	  ComposableMethodList compose(ComposableMethodList,
	    throws IllegalCompositionError;

Category theory uses cartesian categories to describe structure; Java uses interfaces.
Whenever you see “cartesian category,” you can think “interface.” They're pretty
much the same thing. Practically, that means that a lot of the drudgery of implementing
the Category interface is taken care of by the Java compiler.

圏論ではカルデシアン圏を構造を記述するために使っていますが、Java ではインターフェース
てよいです。これらはとてもよく似ているもの同士です。現実には、Category interface を実
装する際の苦労 (drudgery) の大部分は Java コンパイラーが面倒を見ています。

For example, recall the directed graph G above. We can get effectively the same
implementation of the graph by using this interface:

たとえば、前述した有効グラフ G を考えてみましょう。以下のインターフェースを使ってグラ
フの同一実装 (same implementation) を効率的に得られます:

	interface G {
	  interface A;
	  interface B;
	  interface C;
	  B f(A);
	  C g(B);
	  C h(A);

That's it! We're considering the free category on G, so there are no tests. We can
compose lists of methods: g(f(a)). The compiler will give us an error if we try to
compose methods whose source and target don't match: h(g(b)) doesn't work.

G の free category を対象としているので、テストはありません。g(f(a)) のようにメソッド
ようとしたときにはエラーを報告するでしょう。h(g(b)) は doesn't work です。

Because the objects of the cartesian category Interface are lists, we can define
methods in our interfaces that have multiple inputs.


	interface Monoid {
	  interface M;
	  M x(M, M);
	  M e();
	void testX(M a, M b, M c) {
	  assertEqual(x(a, x(b, c)),
	              x(x(a, b), c));
	void testE(M a) {
	  assertEqual(a, x(a, e()));
	  assertEqual(a, x(e(), a));

Here, the method x takes a two-element list as input, while e takes an empty list.

ここで、メソッド x はその入力として二要素のリストを受け取りますが、e は空リストをとります。

Exercise: figure out how this definition of a monoid relates to the one I gave earlier.

Implementation as a functor

Cartesian categories (interfaces) provide the syntax for defining data structures. The
meaning, or semantics, of Java syntax comes from implementing an interface.

カルデシアン圏 (インターフェース) はデータ構造を定義する構文を与え (provide) ます。
Java の構文の meaning 、あるいは semantics といったものは

In category theory, functors give meaning to syntax. Functors go between categories
like functions go between sets. A functor F:C \to D

関数 (functions) が集合と集合 (between sets) の間にあるように、
関手 (functors) は圏と圏 (between categories) の間にあるのです。

    * maps objects of C to objects of D and
      C のオブジェクトを D のオブジェクトに map し
    * maps morphisms of C to morphisms of D such that
      C の morphisms を D の morphisms に map する
    * identities and composition are preserved.

There are several layers of functors involved in implementing a typical Java program.
First there's the implementation of the interface in Java as a class that defines
everything in terms of the built-in classes and their methods; next, there's the
implementation of the built-in methods in the Java VM, then implementation of the
bytecodes as native code on the machine, and finally, physical implementation of the
machine in silicon and electrons. The composite of all these functors is supposed to
behave like a single functor into {\rm Set}, the category whose objects are sets and
whose morphisms are functions between sets. We end up approximating many of these sets:
instead of integers, we use ints and hope that they don't overflow. Instead of real
numbers, we use doubles and are surprised when we lose precision. In category theory,
we ignore this and say that in any practical application, we'll use datatypes that are
“big enough.”

典型的な Java プログラムの実装においては involve された関手のいくつかの階層があります。
第一にクラスとして組み込みクラスとそのメソッドを使ってすべてを定義しているJava のイン
ターフェースを使った実装があります。次に Java VM の組み込みメソッドを使った実装があり、
(the machine in silicon and electrons での) 物理的な実装があります。

これらの関手すべての composite は {\rm Set} への単一の関手のように振る舞うことが仮定されます。
集合であるオブジェクトと、関数と関数の間の集合である morphisms を持つ圏

We end up approximating many of these sets:

整数の代わりに int を使ってそれがオーバーフローしないことを願っていて、
実数値の代わりにわたしたちは double を使いそして精度を失ったときに驚くのです。
すべてのアプリケーションにおいて“big enough”なデータ型を使うだろうと主張しています。

The upshot of all this is that a Java class F implementing an interface X can be
thought of as a functor F:X \to {\rm Set}. The class definition assigns to each inner
interface a set of values and to each method a function mapping between those sets.

The upshot of all this はインターフェース X を実装している関手 F:X \to {\rm Set} とみ
なせる Java のクラス Fです。このクラス定義では各 inner インターフェースを値の集合に 
assign し、また、各メソッドをそれらの集合の間の function mapping に assign しています。

Here's an example of three different classes that implement the Monoid interface from
the last subsection. Recall that a monoid is a set of things that we can combine; we
can add two integers to get an integer, multiply two doubles to get a double, or
concatenate two strings to get a string. The combining operation is associative and
there's a special element that has no effect when you combine it with something else:
adding zero, multiplying by 1.0, or concatenating the empty string all do nothing.

Here's an example of three different classes
that implement the Monoid interface from the last subsection.
二つの integer を加算して一つの integer にできますし、
あるいは二つの double を乗じて一つの double にしたり
結合演算 (combining operation) は associative であり、また、

So, for example,

	class AddBits implements Monoid {
	  enum Bit implements M { Zero, One }
	  M x(M f, M g) {
	    if (f == e()) return g;  // 0+g=g
	    if (g == e()) return f;  // f+0=f
	    return Zero;             // 1+1=0
	  M e() { return Zero; }

Here, the functor {\rm AddBits}:{\rm Monoid} \to {\rm Set} assigned the set \{0, 1\}
to the object M, assigned the function XOR to the morphism x, and assigned the
constant function returning {0} to the morphism e.

ここで、関手 {\rm AddBits}:{\rm Monoid} \to {\rm Set} は
オブジェクト M に集合 \{0, 1\} を assign し、
XOR 関数を morphism x に
{0} を返す constant fucntion を morphism e に assign しています。

	class MultiplyBits implements Monoid {
	  enum Bit implements M { Zero, One }
	  M x(M f, M g) {
	    if (f == e()) return g;   // 1*g=g
	    if (g == e()) return f;   // f*1=f
	    return Zero;              // 0*0=0
	  M e() { return One; }

Here, the functor {\rm MultiplyBits}:{\rm Monoid} \to {\rm Set} assigned to M the same set
as before, \{0, 1\}, but assigned the function AND to the morphism x and the constant
function returning 1 to the morphism e.

ここで関手 {\rm MultiplyBits}:{\rm Monoid} \to {\rm Set} は M に対して前のものと同じ
集合 \{0, 1\} を assign していますが、AND 関数を morphism x に、
1 を返す constant function を e に assign しています。

	class Concatenate implements Monoid {
	  class ConcatString implements M {
	    ConcatString(String x) {
	      this.x = x;
	    String x;
	  M x(M f, M g) {
	    return new ConcatString(
	        f.x + g.x);
	  M e() {
	    return new ConcatString("");

Here, the functor {\rm Concatenate}:{\rm Monoid} \to {\rm Set} assigned the set of
strings to M, assigned the string concatenation function to the morphism x and the
constant function returning the empty string to the morphism e.

ここでは関手 {\rm Concatenate}:{\rm Monoid} \to {\rm Set} は
文字列の集合を M に、文字列連結関数を morphism x に、
空文字列を返す constant function を morphism e にそれぞれ assign しています。

5. Equalizers




あららー。 2011-04-11 - みねこあ 予想通りというかなんというか。 お部屋が.....。 こんなのってないよ。もう何も片さない...orz

■_ Top 13 Most Absurd Programming Languages


Top 13 Most Absurd Programming Languages | Top Design Magazine - Web Design and Digital Content

Top 13 Most Absurd Programming Languages

An esoteric programming language (sometimes shortened to esolang) is a programming 
language designed as a test of the boundaries of computer programming language design, 
as a proof of concept, or as a joke. There is usually no intention of the language 
being adopted for mainstream programming, although some esoteric features such as 
visuospatial syntax have inspired practical applications in the arts. Such languages 
are often popular among hackers and hobbyists. This use of esoteric is meant to 
distinguish these languages from more popular programming languages.

I'm a programmer, I know my way through many languages from ASM and all the way to PHP. 
Learning a new programming language takes a lot of time and effort, but making a new 
one takes even more. Yeah, I do have a good sense of humor but why in the name of 
Pascal would you waste your time inventing something like Brainfuck or ZOMBIE? Anyway, 
at least they make us laugh. In this article you will see the most absurd, useless and 
hilarious 13 esoteric programming language that I know.


1. Lolcode

Lolcode was inspired by the language expressed in examples of the lolcat Internet meme. 
The language was created in 2007 by Adam Lindsay, researcher at the Computing 
Department of Lancaster University.

    “Hello World” example:


Befunge and its ilk allow the instruction pointer to roam in multiple dimensions 
through the code. For example the following program displays “Hello World” by 
pushing the characters in reverse order onto the stack, then printing the characters 
in a loop which circulates clockwise through the instructions [>], [:], [v], [_], 
[,], and [^].

    “Hello World” example:
    "dlroW olleH">:v

3. Brainfuck

Brainfuck is designed for extreme minimalism and leads to obfuscated code, with 
programs containing only 8 distinct characters.

    “Hello World” example:


© 2010 topdesignmag.com some rights reserved.


で、reddit での反応

Top 13 Most Absurd Programming Languages : programming

I don't see Ruby listed.

I don't see Perl listed.

The only fault I have with Perl is it is a patch work of bubblegum and duct tape. They 
really should have started it over at a few points in time, but given people's 
investment they weren't willing.

no.14 -> C++

    * Java
    * COBOL
    * "XML"
    * "UML"
    * VBA
    * PHP
    * C++
    * APL
    * Prolog
    * Bash
    * Javascript
    * SQL
    * Perl
Why bash?

    RESULT=$($FUNCTION "$@" "$(echo "$URL" | strip)") || DRETVAL=$?
    { read FILE_URL; read FILENAME; read COOKIES; } <<< "$RESULT" || true

looks great to me.

C# ?



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



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