ときどきの雑記帖混迷編2011年4月(中旬)

2011年04月20日

■_ 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
    values.

    これは機能の 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]。名称は考案者の名前のイニシャルに由来する。

赤黒木とは異なり、AA木では右の子ノードだけが赤となる。逆に言えば、左の子ノードは赤には
ならない。結果として2-3-4木ではなく2-3木に相当したものとなり、操作時の処理が大幅に簡略
化される。赤黒木では、平衡を保つために以下のような木構造の断片をそれぞれ異なるものとし
て扱う必要がある。

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

2011年04月19日

■_

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に関して彼の抱えている主たる問題は
文字列の取り扱いについて2から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 
swallow).

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

2011年04月18日

■_

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

■_ あとでよむ

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]

以下略

や、パーザーコンビネーターとか、PEGとかあまりまじめに読んだりしてないので(^^;

■_

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

Environment Variables

Environment Variables
LC_COLLATE
    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 がどうなのか確認したいってのが本題なんですが。

2011年04月17日

■_

戦国鍋TVの放映時間が変わって視聴しづらい。

・3倍速い
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
debate?

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"? 
(programmers.stackexchange.com)

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"

■_

Marco ArmentがFacebookのOpen Compute Projectを斬る（Facebook's Open Compute Project 日本語訳）
すべてをラムダ計算で
sleepとwakeup関数 - Plan9日記
仕事の生産性を上げるには適度な「インターネットブレイク」が効果的 : ライフハッカー［日本版］
台湾HTC社、快進撃の理由：Googleと組むスマートフォンメーカー | WIRED VISION
eブックの伸びと紙の本の落ち込み?その差がますます拡大
想像してみてほしい。「Java (.NET でも) の各ライブラリリファレンスを紙の本で持ち歩く」たぶんだけど、ほとんどの人がうんざりすると思う。
産地偽装クラウド - ベテランIT営業が教える「正しいITの使い方、営業の使い方」 - ZDNet Japan
Amazon.co.jp：できるプログラマになる!”伝える”技術: 梅津信幸: 本
Amazon.co.jp：情報数学の基礎 - 例からはじめてよくわかる: 幸谷智紀, 國持良行: 本
SnowClust　 C言語中学校2011年度入試問題
Lions' Commentary on UNIX 読書会メモ#6 - やる気のないはてだ
二重焼き、その地方の呼び方
宮城県七ケ浜：アニメ「かんなぎ」の“聖地”が震災被害ファンが復興に協力 - MANTANWEB（まんたんウェブ）
wrong, rogue and booklog - (via This Is A Great Book ≪?Cheap Talk) “In...
組み込み系と業務系のイメージのギャップ - きままな日記帳
大阪歴史博物館特別展「幕末・明治の超絶技巧」：技術の継承について考えさせられた: 組み込み技術者の単身赴任日記
技術の伝承というのはそういうものである。美術品だけでなく産業分野でもあり得ることだ。
なぜ奈良先端大で人材は育つか - 生駒日記
パブリック･クラウドがエンタープライズ市場を制する理由 ≪ Agile Cat ? in the cloud with openness
【震災】東北大、770億円被害--28棟・7千機器損壊、研究活動に大きな支障 : SIerブログ
楽天のマスコット、カラスコに大アクシデント！宙返りの着地に失敗…けん断裂で今季絶望 : ガハろぐNewsヽ(･ω･)/ｽﾞｺｰ
Ichi Kanaya's Blog: Z80/68000
「さよなら絶望先生全書」はとてつもない厚さになる模様 :おた☆スケ -おたくのスケジュール帳-
時代の風：サマータイム制は論外＝東京大教授・坂村健 - 毎日ｊｐ(毎日新聞)
恩 - なるだけ日刊！竹橋で働く元社長日記全国技術系勉強会マップ！
STLをマルチスレッドで使いたい | OKWave
この記事を鵜呑みにしないこと。コメントに記事の欠陥が指摘されています。

■_ 読んだ

そいやこの本、高橋会長も買ったというのをついったで見かけた覚えがあるなあ。それはさておき。タイトルにもある「イシュー」(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!

Js_of_ocaml

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 
(JFLA).

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: あれ、バイトコード出力するものだったのだっけ。

2011年04月16日

■_

ベイスターズを「ベイス」って略されるとなんか違和感ががががが。

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

買った

「日本ハムに学ぶ～」は面白かった。終わりのほうで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 言語を作っている
チームを率いていることをアナウンスしました。(リンクの案内)
それを行ったことの動機というのは、彼らはJavaが非常に好きであるのに
Javaにはそのキーとなる領域において進歩を妨げているような欠陥があって
その欠陥に対して“欲求不満”といった感情を抱いているということでした。
彼らはまだ完全なコンパイラーを手にしていませんが、作業中であり
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 
annotation.

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.

わたしが何かを見落としている可能性はありますが、
それはScalaの操舵室(?)に存在している問題でしょう。
おそらくそれは今日満足行く形で解決できるものではないのでしょうが、
新しい言語(と新しい標準ライブラリ、新しいツールチェイン)を丸ごと作ることに
比べればはるかに少ない労力で実行できるでしょう。
この人たちが 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.

「そんなにScalaがいいと思っているのなら、Scalaを使えばシアワセになれるんじゃないの?
なんだって 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相談箱

Excelで整数ランダムにだすにはどのようにすればいいのでしょうか？
整数　1～50　同じ整数を重複しない
よろしくお願いします。

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

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

（B1:B5セルに1～5の乱数を作成する例）
A1:A5セルに「=RAND()」という数式を入力
　↓
B1セルに「=RANK(A1,$A$1:$A$5,)」という数式を入力
　↓
B1セルの数式をB2:B5セルにコピー

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

■_ 今日の丸投げ

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

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

awkでの処理 | OKWave

awkでの処理

環境はHP-UX,UNIXです。

あるtxtファイルが存在したとして、txtファイルの中身は以下のようになっているとします。
基本思想としては現在行と次の行を比較して、現在行がＯＵＴ次の行がINだったら処理実行、
もしOUTの次にOUTがきていたら、現在行のOUTの行を削除するとしたいです。

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

sh内で実装するとしたらどうやったらできますでしょうか
ご教授願います。

ANo.1

0909union

結局何をしたいのか、ようわからん。

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

http://docs.hp.com/en/B2355-90680/uniq.1.html
http://docs.hp.com/en/B2355-90680/sort.1.html?jumpid=reg_R1002_USEN

それで標準入力から渡せば、同じ行は存在しないで、処理ができると思います。

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

順番が大事だったら、フィールド管理して、先頭か、最後尾に番号つける（sortなどだと、比較位置きめられたはず）

言葉足らずで失礼しました。

結局こういう感じになってるファイルがあってOUTとINの順番になってたら
２行目の$1から１行目の$1を引き算しようとしていて、

引き算の前にチェックして、
OUTとINの順番でならんでない行は削除するとしたかったのです。。。
以下のように重複行を削除する sort- uとかuniq　文字列指定は使えないのですよ。正直


awkの得意な人に聞いても結構難しいといっていたので、
質問させて頂きました。


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"

ANo.3

No2です。すいません。訂正。

/OUT/{save=$0;next}
{if(save!=""){print save;save=""};print}
END{if(save!="")print save}

OUTがない行が連続しないなら、たまたまさっきのでも良いのですが。

補足


丁寧にありがとうございます。
今こちら30000stepぐらいのshを組んでいて大変なのです。。。。

お二方に助けて頂いた感じでちょっと動かしてみます。
少々お待ち下さい。

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

そして

awkでの処理 | OKWave
お礼

0909unionさん

No2さんのロジックでいこうと思います。
0909unionさんから教えて頂いた内容も実現できましたので
お礼申し上げます。

また勉強させて下さい！！

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

■_ Lispの呪い

誰か全文訳すような気がする。

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
momentum.

このエッセイでは、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の呪いが引き起こされます:

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) のようなものはないのです。

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

■_ Lisp Is Not An Acceptable Java

もうひとつ Lisp ネタ。

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.

Conclusion

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
programming!

■_

2011年04月15日

■_

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

■_ 掛け算

今でもCASLで組めとかいう問題が出たりするのだっけか＞掛け算

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.

あなたは16ビットマシンを与えられ、任意の大きさの整数の乗算を実装するように指示されました。
レジスターは16ビット長の数値しか保持することができず、最も大きな数値を扱える掛け算命令
は二つの8ビットを入力として16ビットの積を得るものです。

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:

あなたの作るプログラムは、任意の大きさの正の値を二つ入力とし、その積を出力と
するものです。入力値は一行に一つずつ、バイトごとに2桁の十六進になっている
リトルエンディアンのバイト配列としてエンコードされています。
プログラムの出力は同様のフォーマットでなければなりません。
実際に例を出すのが良いでしょう:

input

1f 4a 07
63 a3

output

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) はゼロであってはなりません。
いずれの入力も100バイトを超えることはありません。

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!

忘れてならないのは、あなたが使うことを許されている最大の掛け算は
1バイト×1バイトで、2バイトを越える大きさの整数は使えないということです!

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

Caveats

    * 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 のあとに余計なスペースが出力されます。

Explanation
説明

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

説明は少々長くなってしまうのですが、ほとんどの人はここに興味を持つだろうとわたしは
考えています。

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 を考えました。
二つの任意の正の数をこのやり方でもって乗算できます。
これを、13×47を例に使って説明します。
最初の数値13を書いて、それを1になるまで2で割り続けます
(端数は毎回切り捨てます)。

13
 6
 3
 1

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

さて、今度はもう一つの数値の47を書きます。そしてそれに2を掛け続けます。

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:

今度は左側の数値が偶数である行をすべて消します。
この例の場合は6の行だけが対象です
(コードでは打消しができないので単に取り除くことで対処します)。
最後に、右側の列で残った数字すべてを加算します。

13     47
 3    188
 1    376
     ----
      611

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:
さてこれを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(@)=List.map
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
!=10;m++,l){}t=x(n,1);q=x(m,1);r=x(n,1);p=d;a=n;i=0;f(;*p!=10;i++,l){if(*p==32){
g(a);}t[i]=E;t[i]<<=4;l;t[i]|=E;}a/=2;b=m;i=0;l;f(;*p!=10;i++,l){if(*p==32){g(b)
;}q[i]=E;q[i]<<=4;l;q[i]|=E;}b/=2;f(k=0;k<8*b;k++){if(q[0]&1){o=0;f(i=0;i<n;i++)
{s=o+t[i]+r[i];o=s>>8;r[i]=s&255;}}f(i=n;i;i--){o=t[i-1]>>7&1;t[i-1]*=2;if(i!=n)
t[i]|=o;}f(i=0;i<m;i++){o=q[i]&1;q[i]/=2;if(i)q[i-1]|=(o<<7);}}k=(r[a+b-1]==0)?a
+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;
}

Result:

$ ./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"

具体的には計算機のようなプログラムを作っています。
SomeFuncはVBのCDecをラップしたものです(ただし、Decimalでオーバー・アンダーフロー・桁落ちしたら変換しない)。
数値リテラルが入力されたら、文字列リテラルにしてからCDecに渡すことで、Double以上の桁数で計算させたいです。

文字列リテラル内の数値を除いた、数値リテラルに該当する正規表現を教えていただけないでしょうか。

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

あー、まてよ。入力は一回だけ読むのではなくて変換しながら何度も読むようにすればできなくはないか?

■_

■_ ブートストラップ

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 
different.

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 で実装しようというものだというのなら、その最初の処理系は…という話。たぶん。まあ最初のコンパイラーはどうやって、的な話ですね。

2011年04月14日

■_

グラゼニが週刊連載かあ。

■_ R

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

share/make/basepkg.mk

mkR:
       @$(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上の言語というあたりで)。

■_

2011年04月12日

■_

落し物したらしい ○|￣|＿

■_ 電卓

知恵袋から。

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

将来プログラマーになりたいんですけど、電卓くらいのプログラムは、つくれるようになれるよ
うな説明がかいてあるサイトをさがしてます。

(略)

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

■_ このスクリプトは

ないわー

awkを使用して整形 | OKWave
awkを使用してデータを整形しようとしているのですが
うまくいきません・・・

元データは
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

の様に2列目の項目数がdisk1～4まで不足部分が埋まるようにし
不足していた部分の1列目には時間、3列目には0で埋めたいとおもっています。

数万行を処理する必要があり、手作業では不可能なのですが
awkの知識が乏しく実現出来かねている次第です。

どなたかご教示頂けると助かります。よろしくお願いします。

1回じゃ難しいですね。2回に分けてみました。

cat data.txt | awk \
'BEGIN { strTIME="00:00:00" }
{
num=split($0,ARY," ")
if (num==3) {
strTIME=ARY[1]
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])
strDATA[strDISK]=""
}
}
strTIME=$1
strDATA[$2]=$3
}
END {
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])
strDATA[strDISK]=""
}
}'

ディスク番号の最大値を求めるために二回読みをしてるのかと思ったらそうじゃないし。

フォーマットの仕様が明確でないところがあるけど

BEGIN {
	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
}
END {
	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)

■_ あとで読む

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
(Javaプログラマーのための圏論)


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,
	                              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 であり、また、
なにかと結合したときに何の効果も持たないような特別な要素が存在します。
加算における0、乗算における1.0、連結における空文字列などはすべて何も行いません。

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日

■_

あららー。 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:
HAI
CAN HAS STDIO?
VISIBLE “HAI WORLD!”
KTHXBYE

2.Befunge

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:

++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++
..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.

4位以下は元記事を見てのお楽しみ。

で、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# ?

ときどきの雑記帖 混迷編

ときどきの雑記帖混迷編