# ときどきの雑記帖 混迷編

### 2011年04月20日

#### ■_

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

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.

OO Design Principles ≪ Valuable Opinions

OO Design Principles

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分探索木の一種であり、順序のあるデータを効率的に格納し検索

ならない。結果として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.

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) から呼び出されることを想定しています。

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 のあるものでもあります。

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" のようなものも持っていません。

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 で






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日

#### ■_

なんかえらく盛り上がっているのですが結構前の記事だったり。 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
codebase.

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

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
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日

#### ■_

・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."

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

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

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"


#### ■_ 読んだ

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

(略)



ううむ。またも 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.

チームを率いていることをアナウンスしました。(リンクの案内)
それを行ったことの動機というのは、彼らは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 の心配をしているの?」と思われるかもしれません。

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で整数ランダムにだすにはどのようにすればいいのでしょうか？

よろしくお願いします。


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

重複しない乱数の作成－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での処理

あるtxtファイルが存在したとして、txtファイルの中身は以下のようになっているとします。

もしOUTの次にOUTがきていたら、現在行のOUTの行を削除するとしたいです。

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

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


ANo.1

0909union

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 }


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

２行目の$1から１行目の$1を引き算しようとしていて、

OUTとINの順番でならんでない行は削除するとしたかったのです。。。

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 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) のようなものはないのです。 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. 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日 #### ■_ #### ■_ 掛け算 今でも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月13日 #### ■_ JavaScript「に」コンパイル(変換)する言語ってのを見ていると、 Guile の初めの頃の Stallman の言っていたアイデアもそれほど捨てたもんじゃなかったのかなあ などと思ったり。 #### ■_ 今日のお題 OKWaveから。 grepでの抽出箇所のみ置換して上書き | OKWave 例えば find ./ -name file_name -exec grep -B 2 "earth" {} \; -print | grep "moon" というコマンドを実施し、出力が planetkind moon だったとします。 このfile_nameファイルの一部にある 『 planetkind moon』 という箇所を 『 planetkind taiyo』 に変更したいのですが、 find ./ -name file_name -exec grep -B 2 "earth" {} \; -print | grep "moon" | xargs sed -i "s/moon/taiyo/" とすると、ファイル中の全てのmoonがtaiyoになってしましまいます。 このgrepでの抽出箇所のみ置換して元ファイルを上書きする方法は有りますか？ 以上、宜しくお願いいたします。  ANo.1 そりゃそうだ. sed "s/moon/taiyo/" って, 「moon を taiyo に置き換える」ってことでしょ? 「planetkind moon」を「planetkind taiyo」に変更するなら, そのように書かないと.  補足 言葉が足らずすみません。 質問はearthという文言が存在する行の2行上にある planetkind moon を planetkind taiyoに変えたいのです。 他の行にもplanetkind moonという行は存在するのです。  Perl あたりで書けばいいような…。 #### ■_ やっぱりお金の話だと伸びますねー The Programmer Salary Taboo : programming The Programmer Salary Taboo The Programmer Salary Taboo 2011-04-12 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 example.  それにつけても以下略 #### ■_ 空中リプライはもう無視することにしよう(謎 ### 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


#### ■_ あとで読む

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



#### ■_

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.

を使います。“カルデシアン圏”を見たときはいつでも“インターフェース”と置き換えて考え
てよいです。これらはとてもよく似ているもの同士です。現実には、Category interface を実

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

* 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 VM の組み込みメソッドを使った実装があり、

(the machine in silicon and electrons での) 物理的な実装があります。

これらの関手すべての composite は {\rm Set} への単一の関手のように振る舞うことが仮定されます。

We end up approximating many of these sets:
わたしたちは結局のところ多くのこういった集合の

すべてのアプリケーションにおいて“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.
モノイドは結合可能なものの集合であることを思い出してください。

あるいは二つの double を乗じて一つの double にしたり

なにかと結合したときに何の効果も持たないような特別な要素が存在します。

So, for example,

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 に対して前のものと同じ

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} は

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:

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

© 2010 topdesignmag.com some rights reserved.


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=$?

looks great to me.


C# ?



リンクはご自由にどうぞ

メールの宛先はこちら