・クラッキングバイブル 新装版
今度のは箱に入ってないんだ。
・ムック
大洋→横浜で60周年記念だかのムックが出ていた。
ちょっとだけ中を見てみたのだけど屋鋪と高木豊の対談があって、
その中で「俺たちがいくら打って点を入れてもピッチャーがだらしないから
それ以上に点を取られて負けるんだ」みたいなことを言ったら山下大輔に
叱られたとかいう話があった。
山下大輔に叱られたあともぐだぐだいってたということだから、
そりゃあこいつらがいたんじゃダメだったろうなあという認識を新たにした。
屋鋪は好きな選手だったんだけどなあ。
・みつからない
「ぷよぷよのうた」がどの店にも置いてないでござる。
Amazonさんでぽちっとなコースかなあ。
・読んだ
「エコ罪びと」の告白－私が買ったモノはどこから来たのか？ と 大搾取！。
なんというか暗澹たる気分に。
・長崎原爆
本屋で見かけてちょっとだけ中身を見た本で(タイトル失念)、
長崎にも投下された爆心地付近に原爆ドームのような建物(浦上天主堂?)が
あって、戦後も1955年くらい(覚えてない)までは残っていたのだけど、
今はもう撤去されてしまって影も形もない。原爆ドームがある広島とない長崎と…
でいろいろ書かれているようで財布に余裕があれば買ったんだけど。
いや、タイトルとか控えて図書館に行くべきか。
あと、なぜ長崎でそのようなことになったのかということも書かれていて、
なんともやりきれない気持ちに。
On Scala’s future | Zen and the Art of Programming
On Scala’s future
By Antonio Cangiano. Filed under Ruby, Scala
Kenneth McDonald posted the following question about Scala's future in the Scala
mailing list:
I thought it would be interesting to find out people's predictions for how much
of the Java market Scala will eventually penetrate. It's nice to see Scala doing
reasonably well so far, so now’s your chance to make a prediction on the future of
Scala:
a) Scala will remain a niche language, competing with Groovy, JRuby, etc.
ニッチな言語にとどまり続ける
b) Scala will become the dominant “second” language for the JVM.
JVM 上の“第二の”支配的言語となる
c) Scala will actually become big enough to compete with Java in many respects.
Java に比肩しうる存在となる
If none of these fit your outlook, feel free to make up your own answer.
In my opinion, the answer will be A (niche) or B (second language), depending on the
community's ability to:
わたしの意見では、この設問に対する答えは A のニッチか B の第二言語で、コミュニティの
能力によってそのどちらかが決まると思う。
* Promote Scala (and Liftweb);
Scala のプロモーション
* Simplify the process of switching from Java (e.g., by providing familiar tools)
as much as possible;
Java からの移行プロセスの単純化
* Provide worthy reasons to switch (e.g., killer apps). People rarely go to the
trouble of switching just because something is “nicer”, even if in reality it
causes one to write more robust code that takes advantage of higher order
abstractions and a “safe and coherent” type system. Liftweb and concurrency
through the Actor model / Akka are definitely two examples of a step in the
right direction, as they do a particularly good job of solving a specific
problem and showcase the value of adopting Scala as a user, as well as a tool
to implement libraries and reusable components.
The software development community is embracing dynamically typed languages like
Python and Ruby, as well as functional programming. Languages like Python and Ruby
simplify the development process for a beginner. They are easy to read, learn and use.
Their adoption is therefore growing quickly. They also offer practical solutions to
web development needs through frameworks like Rails and Django.
The paradigm shift to functional programming is much slower however. Functional
programming done a la Scala, is undoubtedly advantageous for the competent software
engineer, but moving from Java to Scala requires significant commitment and a higher
degree of understanding about how to program, in my opinion. Are Java developers up to
this? Some of them are, but I doubt that a majority of them would be. It should be
noted that Scala has the potential to also attract developers who don’t program in
Java, but rather come from a different background, such as the aforementioned Python
and Ruby. These people may look into Scala as a more functional-oriented, robust and
faster alternative.
This, coupled with the current, limited popularity of Scala, leads me to believe that
option C (let’s say ~50% marketshare) is not a realistic option for the foreseeable
future. We are entering the long tail period of programming, where many lesser known
languages will start gaining some traction. Achieving a “second language” status is
still an ambitious and worthy goal. There are many formidable opponents aiming for
that, including JRuby, Jython, Groovy, and Clojure, and the rewards for doing so would
be substantial for everyone involved.
The real question is not how far Scala is capable of going in terms of adoption, but
rather what can be done to ensure that it will achieve widespread acceptance, however
that may be defined. Paying close attention to the success stories of Ruby and Python
may give the community some insight as to what should be done. To a minor extent,
fellow functional programming languages like Erlang and Haskell are doing a fine job
marketing-wise and are gaining traction. As of 3.30 pm today, there are 147 members in
the irc channel for Scala, and 576 for Haskell. This is not to say that one is better
than the other, or even that Haskell is more popular than Scala in general, but rather
that there may be something to learn from a “similar” language, that poses
compatible challenges for those who intend to approach it.
Being based on the JVM, well integrated with Java, and to a certain extent being
Java-like, are all major advantages that may help Scala’s ability to gain major
popularity. And being ingrained in the Java world, will affect the way Scala’s image
and the ways it can be promoted as well. Whereas Ruby has a somewhat anti-corporate
spirit and image, and is tough to sell to the Enterprise world, Scala doesn’t face
these challenges. As such it may appeal to a much larger category of developers and
companies. However, a lot of work will be required to reach that tipping point. Scala
is already an excellent language, as far as I can see, but it will be a combination of
technical efforts and marketing to really decide Scala’s popularity.
Bookmark and share:
Add to Buzz Add to Del.icio.us Add to digg Add to DotNetKicks Add to DZone Add to
Facebook Add to Google Bookmarks Add to Newsvine Add to reddit Add to Slashdot Add to
Stumble Upon Add to Squidoo Add to SphereIt Add to Technorati Add to Twitter Add to
Yahoo My Web
Copyright © 2005 - 2009 Antonio Cangiano • Powered by WordPress • Using Blue Zinfandel
theme by Brian Gardner.
C の生まれに関して。
C and the AT&T Unix Port -- A Personal History
C and the AT&T Unix Port -- A Personal History
Ｃ言語と AT&T Unix の移植
(略)
To Port a System
Then Dennis said another one of those simple, profound things, "Given the
complexity of some of the applications in the Bell System, it would be easier to port
the operating system to a new machine than to port the application to a new operating
system." The existing operating systems at the time were mostly still punched
card based (or based on card images copied to tape or disc), mass storage organization
and command line syntax was completely unique for each system, interactive and
back-ground jobs had different system calls to accomplish the same tasks, there was
effectively no networking, and word-sizes of 16, 24, 32, 36, 60, and 64 were in use in
the Bell System (not to mention several different byte orders). He didn't actually say
"Unix is just a program", but I got the idea. He asked me if I could help
evaluate machines for a 32-bit port of Unix, and build the compiler for the resulting
port, and I enthusiastically agreed.
その時 Dennis は深遠な事柄を簡単に言い換えました。 「既にあるベルシステムの中のいくつ
かアプリケーションの複雑さを考えれば、 新しいオペレーティング・システムへアプリケーシ
ョンを移植するより、 新しいマシンへオペレーティング・システムを移植する方がより簡単で
あろう」 当時の Bell System の 既存のオペレーティング・システムのほとんどは まだパンチ
カード (あるいはテープやディスクにコピーされたカード・イメージ) に基づいたもので、 大
容量記憶装置の構成やコマンドラインのシンタックスは 各システムごと全く互換性がなく、 同
じタスクを遂行するのでも 対話形式とバックグラウンドジョブでは 異なるシステムコールを使
用し、 役にたつネットワークはなく、 ワードサイズは 16、24、32、36、60、64 が使用されて
いました。 (バイトオーダーが異なっていたことは言うまでもありません) 実際には彼が「Unix
は単にプログラムである」 と言ったわけではありませんが、 私はアイデアを思いつきました。
彼は私に Unix の 32-Bit 版のマシンでの評価を手助けを求めましたし、 その移植の成果とし
てコンパイラを作成することに、 私は熱狂的に同意しました。
(略)
The Impact on C
C に対する影響
Dennis and Ken set to work on the OS, to make it truly portable. It was necessary to
clean up C quite a bit in order to write the OS. In the evolution from B to C, a lot
of old B code had been carried over unchanged. This meant that the uses of types were
very fast and loose, or missing altogether. Before C had the unsigned data type,
people would assign values to character pointers to get unsigned arithmetic, for
example.
Dennis と Ken は OS を本当にポータブルにするための作業に着手しました。 OS を書くために、
かなり多くの C を整理する必要がありました。 B から C へ発展する過程で、多くの古い B の
コードは 変更されることなく繰り越されていました。 これは型の使用が大変いい加減である、
あるいは全く欠落していることを意味していました。 例えば C が符号なしのデータ・タイプを
サポートする以前は、 符号なしの演算を行うために、 文字のポインタに値が割り当てられてい
ました。
(略)
OS 記述のためというのがかなりのウェイトを持っていて Cの設計に影響したというのがうかがえますね。
ひげぽんさん Lisp Scheme スレに登場。
Lisp Scheme Part27
184 ひげぽん ◆Ngzcp/NZpA [sage] 2009/08/08(土) 00:04:50 ID: Be:
Mosh 0.2.0 をリリースしました。
http://mosh-scheme.googlecode.com/files/mosh-0.2.0.tar.gz
http://mosh-scheme.googlecode.com/files/mosh-0.2.0-setup-win32.exe
Mosh は R6RS に準拠した Scheme インタプリタです。
0.2.0 では並列ライブラリなどが追加されています。
リリースの詳細は http://d.hatena.ne.jp/higepon/20090807/1249655156 をご参照ください。
もし良かったら使ってみてください。
185 デフォルトの名無しさん [sage] 2009/08/08(土) 00:13:03 ID: Be:
おっおっ！
188 デフォルトの名無しさん [sage] 2009/08/08(土) 00:44:34 ID: Be:
～準拠とか、きちんとやろうとする人はすごいなあ
191 ひげぽん ◆Ngzcp/NZpA [sage] 2009/08/08(土) 01:11:02 ID: Be:
>>185
>>186
>>187
>>188
ありがとうございます!
>>189
まだ常用には向いていないです。
(mosh shell)というライブラリが付属しているのですが
機能が足りないです。
>>190
試していただいてありがとうございます。
申し訳ないです。Windows XP でしか動作確認できていません。
Windows 2000 では使えないWinSock で関数を使ってしまったみたいですね。
取り急ぎバグとして issue 登録しておきます。
204 デフォルトの名無しさん [sage] 2009/08/08(土) 01:57:54 ID: Be:
充分に使いものになるレベルだと思う。
細かいバグはまだまだあるけど、基本はしっかりしている。
その細かい部分は多くの環境で使ってみないとなんとも言えないので、
このスレで議論するのは意味があると思う。
思うだけだけど。
ところで --loadpath オプションでは複数のパスをコロンで区切って渡せる？
Windows ではコロンはドライブレターの表記に使う。
コロンに特別な意味があると絶対パスを使えないことになる。
修正要。
215 デフォルトの名無しさん [sage] 2009/08/08(土) 05:02:19 ID: Be:
Mosh ver0.2 (Windows)
エラーメッセージがEmacsで拾えなかった。STDERRへの出力に問題があるのでは？
R6RSだとloadが無いけどどうするの？
竹内関数、かなり速かった。
mosh>(time (tak 12 6 0))
;;1.6406230926513672 real 1.625 user 0.0 sys
12
mosh>
gosh> (time (tak 12 6 0))
;(time (tak 12 6 0))
; real 1.390
; user 1.391
; sys 0.000
12
gosh>
216 デフォルトの名無しさん [sage] 2009/08/08(土) 05:17:43 ID: Be:
別に宣伝するのは構わないが、もう少しスレで質問に答えたりすれば
そんなに悪く言う奴もいなくなると思うが。ひげぽん、どうよ？
220 デフォルトの名無しさん [sage] 2009/08/08(土) 07:45:26 ID: Be:
>>215
0x00 が出力されてるな。
内部的には ucs4 を使ってるとかいう話があったので、
変換がうまくいってないのかも。
221 デフォルトの名無しさん [sage] 2009/08/08(土) 07:58:57 ID: Be:
(error "a") だけでも再現する。
(display "a" (standard-error-port)) でもやっぱりおかしい。
stderr への出力全般がダメっぽいな。
222 ひげぽん ◆Ngzcp/NZpA [sage] 2009/08/08(土) 11:08:02 ID: Be:
>>192
>>194
すみません。
>>198
>>200
R6RS にも準拠したし俺俺Lisp を脱したかなと思って宣伝してみたのですが
不愉快だったらすみません。
>>203
方向性は実用です。ライブラリを増やしたり速度を気にしたりするのも実用を目指してのことです。
>>204
ありがとうございます。そういっていただけると助かります。
> ところで --loadpath オプションでは複数のパスをコロンで区切って渡せる？
はい。使えます。
なるほど。Windows の場合は ; を区切り文字とするように修正します。
>>209
そうですね。
ここに対策が載っていたので修正します。
http://yanchde.gozaru.jp/winsock2/freeaddrinfo.html
>>213
Gauche 並はまだまだ遠いです。がんばります。
223 ひげぽん ◆Ngzcp/NZpA [sage] 2009/08/08(土) 11:09:33 ID: Be:
>>215
> エラーメッセージがEmacsで拾えなかった。STDERRへの出力に問題があるのでは？
Windows では標準出力、エラー出力で WriteConsole 関数を使っているのですがそれがまずいのかもしれません。
Emacs は Meadow とかでしょうか？（試してみたいので）
> R6RSだとloadが無いけどどうするの？
REPL から動的にコードをロードしたいという意味でしょうか？
ライブラリ形式で保存しておいて (import library-name) はどうでしょう。
> 竹内関数、かなり速かった。
まだ Gauche より若干遅いですね。がんばります。
> 216
> 別に宣伝するのは構わないが、もう少しスレで質問に答えたりすれば
> そんなに悪く言う奴もいなくなると思うが。ひげぽん、どうよ？
可能な限りがんばります。
224 ひげぽん ◆Ngzcp/NZpA [sage] 2009/08/08(土) 11:12:49 ID: Be:
>>217
いえバグの内容を指摘してもらえるだけで十分ですよ。
>>219
すみません。
どれくらいの段階になったらよいでしょう？
言語処理系は完成の定義が難しいですよね。
>>220
>>221
ありがとうございます。
内部コードは UCS4 でそれを UTF16 にして WriteConsole に渡しています。
cmd.exe でも出力されていないとかだったらかなりまずいですね。
225 デフォルトの名無しさん [sage] 2009/08/08(土) 12:35:58 ID: Be:
>>224
cmd.exe の上ではちゃんと表示される。
>>223
> Emacs は Meadow とかでしょうか？
俺は >>215 じゃないけど、少なくとも GNU Emacs 23.1.1 では再現することを確認した。
具体的には GNU Emacs 23.1.1 (i386-mingw-nt5.1.2600) of 2009-07-30 on SOFT-MJASON
>>215
> R6RSだとloadが無いけどどうするの？
そんなこと言ったらそもそも repl だって R6RS には無いぞ。
Haskell みたいに repl では定義を禁止にしたら意味論の破綻はないかも。
そう考えると R6RS って動的な性質が制限されてて Lisp 系言語っぽくないよね。
とりあえず emacs から使う分にはファイル範囲を全選択して C-c C-r でいいんじゃね？
226 デフォルトの名無しさん [sage] 2009/08/08(土) 12:40:45 ID: Be:
>>224
http://msdn.microsoft.com/ja-jp/library/cc429845.aspx
WriteConsole 関数は、コンソールハンドル以外にリダイレクトされている標準ハンドルを渡すと失敗します。
emacs に限らずリダイレクトしたらダメってことだよな。
使えないなぁ…。
236 デフォルトの名無しさん [sage] 2009/08/08(土) 14:46:56 ID: Be:
>>235
gauche は gauche 使ってるよ。
svn trunk も常に「最も最近のリリース版」を使ってビルドできるようになってる。
237 デフォルトの名無しさん [sage] 2009/08/08(土) 14:47:40 ID: Be:
(たまにミスってるときもあるけど)
237 がなんとなく shiro さんの書き込みのような気がしたんだけどまさかねw
Perlについての質問箱 41箱目
18 デフォルトの名無しさん [sage] 2009/08/07(金) 17:38:40 ID: Be:
PHPのob_start()のように、出力を一時的にバッファリングすることはできますか。
ob_start();
print "aaa\n"; ＃なにも表示されない
$output = ob_get_clean(); # $output eq "aaa\n"
よろしくお願いします。
21 デフォルトの名無しさん [sage] 2009/08/07(金) 18:23:27 ID: Be:
>>18
STDOUTを書き換えればできたと思う。
ソース、おぼろげな記憶。
23 デフォルトの名無しさん [sage] 2009/08/07(金) 18:35:39 ID: Be:
>>18
ファイルに退避させることはできるな。
#!/usr/bin/perl
*TAIHI = *STDOUT;
open(IN, '>/tmp/foo');
*STDOUT = *IN;
print "hello, world!\n";
*STDOUT = *TAIHI;
print "hi, there!\n";
メモリに退避する方法は良く分からん。open2使ったけど
うまくいかんかった。
24 デフォルトの名無しさん [sage] 2009/08/07(金) 18:49:03 ID: Be:
#!/usr/bin/perl
use IPC::Open2;
*TAIHI = *STDOUT;
$pid = open2(\*OUT, \*IN, 'cat');
*STDOUT = *IN;
select STDOUT;
print "hello, world!\n";
*STDOUT = *TAIHI;
close(IN);
print "hi, there!\n";
$output = join("", <OUT>);
print $output;
こうか。結構めんどいな。つーかINとOUTを逆にしてて動かないだけだった。
25 デフォルトの名無しさん [sage] 2009/08/07(金) 18:49:47 ID: Be:
あーselect STDOUTっての要らないから取っといて。
26 デフォルトの名無しさん [sage] 2009/08/07(金) 18:53:10 ID: Be:
5.8.0からin-memoryバッファをopenできるようになったよ
use strict;
my $buffer;
sub ob_start
{
open(MEM, ">", \$buffer) or die;
select(MEM);
}
sub ob_get_clean
{
select(STDOUT);
return $buffer;
}
ob_start();
print "hogehoge\n";
print ob_get_clean();
あまり知られてないか、これは。
C++相談室 part71
330 デフォルトの名無しさん [sage] 2009/08/08(土) 17:58:04 ID: Be:
return で返される値は
返り値
戻り値
など色々呼び名があると思いますが、
C++用語としてはどれが正しいでしょうか？
332 デフォルトの名無しさん [sage] 2009/08/08(土) 18:31:18 ID: Be:
>>330
いちおう、 JIS 規格では「返却値」。
ほとんどの場合はどれでも通じるから、どれが正しいとも正しくないとも思わないけどね。
333 デフォルトの名無しさん [sage] 2009/08/08(土) 18:33:05 ID: Be:
>>332
返却値ですか。
ありがとうございました。
JIS 規格は「バック参照」って謎訳があるしなあw