ときどきの雑記帖 めぐりあい電脳空間編

最新ページへのリンク
目次ページへのリンク

一つ前へ 2010年10月(上旬)
一つ後へ 2010年10月(下旬)

ホームへ

2010年10月20日

■_

「神」多すぎ。

イデオン劇場版のBlu-rayがでるとかTVの(こっちはDVD?)のボックスが出るとか。 金が。 Twitter / @えーてる: 劇場版IDEONが来年3月、ジャケットとポスターは湖 ...

・ふらげ

新旧揃い踏み
Geekなぺーじ : Scheme手習い - The Little Schemer -

ブラックラグーンのOVAシリーズのリリース予定、延びたなあ。 まあちゃんとしたものが出てくれたほうが。

■_

昭和もーど


組み込みプログラマー雑談スレッド その16 
936 仕様書無しさん [sage] 2010/10/19(火) 18:57:55 ID: Be:
    uITRONレベルの組込みから脱却できなかった39歳の漏れ
    若いときに忙しかった。
    ある余裕ができた32歳のときに再勉強すれば良かったのだが、
    そのときまで忙しかった反動で気が抜けてしまった。
    今更、Linuxカーネルの本とか読んでいるけど、習得できるように思えない。
    英語の再勉強を36歳のときに始めて、38歳のときにTOEIC740取ったけど、話すことはできない。

    もう時代遅れのおっさんってことだろうか。 

937 仕様書無しさん [sage] 2010/10/19(火) 19:07:03 ID: Be:
    Linux のカーネルを習得してる奴など居ない。

938 仕様書無しさん [sage] 2010/10/19(火) 19:36:34 ID: Be:
    >>936
    なにがしたいんだ? 

939 仕様書無しさん [sage] 2010/10/19(火) 19:44:14 ID: Be:
    必要なとこだけ覗けばいいのでは? 

940 仕様書無しさん [sage] 2010/10/19(火) 19:59:54 ID: Be:
    >>939
    それができるようになるにはカーネルの基本部分をかなり理解する必要があると思うが 

941 仕様書無しさん [sage] 2010/10/19(火) 20:00:43 ID: Be:
    >>936
    これからの組込みはLinuxカーネルくらい使えないとね
    と言ってる自分もあまり自信はないが 

942 仕様書無しさん [sage] 2010/10/19(火) 20:32:39 ID: Be:
    ビルド手順とかgitをのぞくとかから、地道にやってけば、そのうちわかるようになると思うけど
    kernelだけ見ててもしょうがないかもしれないしれないけど。
    ま、短期で全部理解しようとすると、廃人になるかもね。 

944 仕様書無しさん [] 2010/10/19(火) 22:30:11 ID: Be:
    >>936 安心しろ。

    μITRONすら わからない しらない つかったことない。

    でも俺はマイコンわかってるって嘯くおっさんなら投網投げれば捕まるぜ
    書棚には入門書がパンパンだ
    ハラモパンパン
    おばはんはパンパンだ

947 仕様書無しさん [sage] 2010/10/19(火) 22:49:48 ID: Be:
    >>944
    でも、OSを使わないアセンブラ世代でハードウェアにアクセスさせていた
    人達は尊敬できるんだ。俺は^^ 

948 仕様書無しさん [sage] 2010/10/19(火) 22:51:54 ID: Be:
    イベントハンドラとタスクマネージャしかない時代だけどなw 

949 仕様書無しさん [sage] 2010/10/19(火) 23:05:21 ID: Be:
    メモリ管理もあったぜ 

950 仕様書無しさん [sage] 2010/10/19(火) 23:09:08 ID: Be:
    と言っても、全部自作するんだけどな。 

954 仕様書無しさん [sage] 2010/10/19(火) 23:41:00 ID: Be:
    >>947
    4bitとか8bitのアセンブラなんて糞
    命令が少ないし、CPUの仕様も簡単だった 

955 仕様書無しさん [sage] 2010/10/19(火) 23:44:51 ID: Be:
    尊敬出来る一番の理由は、5インチフロッピーでガチャガチャ処理してたんだぜ。
    アセンブル終わるまで一服できたし>< 

956 仕様書無しさん [sage] 2010/10/19(火) 23:51:20 ID: Be:
    >>955
    お客さんが、「このパソコンはハードディスクを40Mも積んでるんですよ」って自慢してたなぁ
    1万円/1Mの時代ね。 

957 仕様書無しさん [sage] 2010/10/20(水) 00:42:27 ID: Be:
    16キロバイトの拡張RAMカートリッジをお小遣い貯めて買ったのを思い出した。
    お小遣い2年分使ったはずだから6000円以上はしたはず。 

958 仕様書無しさん [sage] 2010/10/20(水) 01:57:47 ID: Be:
    なんだこの懐かしの昭和横町は 

959 仕様書無しさん [] 2010/10/20(水) 06:31:00 ID: Be:
    カセットテープ知らないんじゃ昭和横丁には入れないだろ。
    カセットテープで「OS」走らせて
    2パスのアセンブラ走らせて
    といった鬼が古にはいたらしいよ。でも。IOCSとかBIOSの概念ぐらいは
    理解していてだね・・・・


    無手勝流スパゲティを書きなぐったじさまは 
    くんな。 

960 仕様書無しさん [sage] 2010/10/20(水) 06:45:19 ID: Be:
    >>959
    テープOSとかIOCSとかシャープ臭い。 

X1 のテープ制御はなかなかすごかったらしいけど見たことはない。

■_

たまには ycombinator から。 Peter Norvig: "I think that language choice is not as important as all the other choices..." : programming

Hacker News | Peter Norvig here. I came to Python not because I thought it was a better/accept...
http://news.ycombinator.com/item?id=1803815

Peter Norvig here. I came to Python not because I thought it was a 
better/acceptable/pragmatic Lisp, but because it was better pseudocode. Several 
students claimed that they had a hard time mapping from the pseudocode in my AI 
textbook to the Lisp code that Russell and I had online. So I looked for the language 
that was most like our pseudocode, and found that Python was the best match. Then I 
had to teach myself enough Python to implement the examples from the textbook. I found 
that Python was very nice for certain types of small problems, and had the libraries I 
needed to integrate with lots of other stuff, at Google and elsewhere on the net.

略

  

Lisp のえらいひとがPythonやってみたけどそれは Python が better/acceptable/pragmatic Lisp であったからではなく、 better pseudocode だったから云々。

実用 Common Lisp (IT Architects’Archive CLASSIC MODER)

■_ gcc

なんか新しいオプションスイッチが増えたとか何とか


nickclifton - October 2010 GNU Toolchain Update

Hi Guys,

  Here are the highlights of this month's merge: 

  * A GCC port to the Xilinx Microblaze architecture has been contributed.

  * A new function attribute - leaf - has been defined for GCC.  This is used to 
    annotate functions that are outside of the current compilation unit and it allows
    the compiler to improve its dataflow analysis.

    新しい関数アトリビュートの leaf がGCC 向けに定義されました。
    このアトリビュートは関数が current compilation unit の外側にあると
    annotate するのに使い、それによりコンパイラーがデータフロー解析を
    改善できるようにします。

    Specifically, calls to functions with this attribute must return to the current 
    compilation unit only by return or by exception handling.  They may not use
    longjmps, or call any function that is exported by the current compilation unit,
    or use a callback function that could end up in the current compilation unit.
    The effect of this restriction is that these leaf functions cannot modify any
    data local the current compilation unit.

    Unlike traditional leaf functions, leaf functions may call other functions, just 
    not ones exported by the current compilation unit.  They may also invoke signals,
    and if a signal handler is defined in the current compilation unit, and it uses
    static variables, then there could be a problem.  The only way to be safe is to
    mark such static variables as volatile.

    伝統的な leaf 関数とは違って、(ここでいう) leaf 関数は current compilatin unit
    によって export されていない別の関数を呼び出しても良い。


    The attribute has no effect on functions defined within current compilation unit.

    このアトリビュートは current compilation unit の中で定義されている関数には
    影響を及ぼさない。
略


Cheers
  Nick

■_ 正規表現

やたらとエスケープを使うパターンもあれば、この例のようにつけるべきときにつけないパターンも。 ってこの場合は正規表現をパラメーターにとっているということがわかってなかったのか。


Strange string split behaviour - Stack Overflow

I'm requesting data from my server and receive a string in the form of 2|bit.ly|1||1| 
and | should be the seperator.

I though the following piece of code should do the work

BufferedReader br = null;
...
br = new BufferedReader(new InputStreamReader(inputStream));
...

String line;
String[] columns;
ContentValues values;

while((line = br.readLine())!=null) {
    columns = line.split("|");
    ...
}

but after the line.split("|"); the colums contains 15 elements instead of 
expected 6. Taking a closer look at it's content reveals that each character in the 
string was stored in one array element.

Anyone having an idea, what's wrong with it? The code coming from server isn't encoded 
in any way in in the example I use only ASCII characters appear.

String.split takes a regular expression as the split string, and the '|' character 
means OR in regex land. You need to escape that character, e.g. 
line.split("\\|");

Note the double backslash: You need to escape the backslash for the Java compiler so 
that the regex engine gets a literal backslash followed by a '|', which is then 
interpreted by the engine as a literal '|'.

PHP には正規表現でなく文字列で分解する explode とかいうのがあったような。

■_ 文字クラスで引き算

もう一個正規表現。


Regex: Match any punctuation character except . and _ - Stack Overflow

Is there an easy way to match all punctuation except period and underscore, in a C# 
regex? Hoping to do it without enumerating every single punctuation mark.


Use Regex Subtraction

[\p{P}-[._]]

Here's the link for .NET Regex documentation (I'm not sure if other flavors support 
it)... http://msdn.microsoft.com/en-us/library/ms994330.aspx

Here's a C# example

string pattern = @"[\p{P}\p{S}-[._]]"; // added \p{S} to get ^,~ and ` (among others)
string test = @"_""'a:;%^&*~`bc!@#.,?";
MatchCollection mx = Regex.Matches(test, pattern);
foreach (Match m in mx)
{
    Console.WriteLine("{0}: {1} {2}", m.Value, m.Index, m.Length);
}

Explanation The pattern is a Character Class Subtraction. It starts with a standard 
character class like [\p{P}] and then adds a Subtraction Character Class like -[._] 
which says to remove the . and _. The subtraction is placed inside the [ ] after the 
standard class guts.
The answers so far do not respect ALL punctuation. This should work:

(?![\._])\p{P}

(Explanation: Negative lookahead to ensure that neither . nor _ are matched, then 
match any unicode punctuation character.)

Java だと && と [^...] を組み合わせたんだっけか。

■_

2010年10月19日

■_

明日(水曜日)あたりは Scheme 手習いフラゲできるだろうか。

■_ 練習問題

まあ、アルゴリズム本なんかの演習問題ならともかく 言語の入門本なんかでの問題はあまり意味なさげだよなあ。 って K & R にもあったか。


推薦図書/必読書のためのスレッド 58 
560 デフォルトの名無しさん [sage] 2010/10/18(月) 19:31:41 ID: Be:
    この流れで言いにくいのですがC++の本で練習問題の豊富な良書の紹介お願いします。 

561 デフォルトの名無しさん [sage] 2010/10/18(月) 19:32:26 ID: Be:
    >>560
    マジレスすると練習問題なんて解くより
    なんか自分で作ってみたほうがためになるよ 

562 デフォルトの名無しさん [sage] 2010/10/18(月) 19:35:11 ID: Be:
    練習問題って何の練習になるのか未だによく分からん 

563 デフォルトの名無しさん [sage] 2010/10/18(月) 19:36:14 ID: Be:
    >>561
    そうなんですけど自分でお題を作るのが難しい。宿題スレの方が良いですかね 

564 デフォルトの名無しさん [sage] 2010/10/18(月) 19:38:49 ID: Be:
    >>563
    何のためにC++勉強してんの?
    何か作りたいから勉強してんなら実際に作れよ
    練習問題とか糞みたいなことしてる暇あったら作れ 

565 デフォルトの名無しさん [sage] 2010/10/18(月) 19:41:49 ID: Be:
    >>564
    分かりました。
    アドバイスありがとうございました。 

566 デフォルトの名無しさん [sage] 2010/10/18(月) 19:43:12 ID: Be:
    お題作るのが難しいなら適当に出してあげよう
    定番の五目並べで
    ネットワーク系の勉強がしたければ通信できるようにすればいいし
    人工頭脳系の勉強がしたければAIを工夫すればいいし
    グラフィカルな部分を勉強したければ・・・良く解らんが3Dにでもすればいい。 

567 デフォルトの名無しさん [sage] 2010/10/18(月) 19:44:22 ID: Be:
    最近はこういう大学受験的な勉強スタイルが流行ってんの? 

568 デフォルトの名無しさん [sage] 2010/10/18(月) 19:46:00 ID: Be:
    >>567
    昔っていうか俺らの時代は創りたいもののためのプログラムだったけど
    今はプログラマーになるためのプログラムになってるね
    新入社員とか見てもプログラムが好きってやつ少ないし 

569 デフォルトの名無しさん [sage] 2010/10/18(月) 20:12:52 ID: Be:
    完全制覇とか独習とかなんか気持ち悪いんだけど
    一般的にはこういうのが受けてるのか? 

570 デフォルトの名無しさん [sage] 2010/10/18(月) 20:16:05 ID: Be:
    リファレンス代わりだろ
    ロベールと一緒 

571 デフォルトの名無しさん [sage] 2010/10/18(月) 20:26:32 ID: Be:
    仕事や部活ならわからんが、趣味なら
    知りたいことができてから調べればいいし、
    練習したいことができてから練習すればいい 

572 デフォルトの名無しさん [sage] 2010/10/18(月) 20:30:26 ID: Be:
    >>568
    分かるわ、俺は中二病を患ったとき誰もがスルように小説を書き漫画を書きしたけど
    両方才能がなかったからプログラムでゲームを作った。
    創りたいものがあってソレを作るためのプログラムってのは楽しいね 

573 デフォルトの名無しさん [sage] 2010/10/18(月) 20:33:48 ID: Be:
    >中二病を患ったとき誰もがスルように小説を書き漫画を書きしたけど

    プログラムは黒歴史化しないよねなんでだろうね 

574 デフォルトの名無しさん [sage] 2010/10/18(月) 20:36:26 ID: Be:
    いや、昔書いたプログラムとか黒歴史だろ 

575 デフォルトの名無しさん [sage] 2010/10/18(月) 20:36:54 ID: Be:
    スパゲティだったりな 

576 デフォルトの名無しさん [sage] 2010/10/18(月) 20:44:27 ID: Be:
    プログラムだけはまだ中二病真っ盛りだから、
    黒歴史の中にいることを自覚できないんだよ 

577 デフォルトの名無しさん [sage] 2010/10/18(月) 20:59:53 ID: Be:
    >>574
    見返すと面白い
    その当時自分が何にはまってたかとかどんな本読んでたかとか思い出すし
    すごく細かく関数わかれてたり無駄に再帰使ってたり
    クラス分けがすごい数だったり、STLハックがしてあったり 

578 デフォルトの名無しさん [sage] 2010/10/18(月) 21:14:39 ID: Be:
    本読む必要ないだろって言うためにこのスレにいるのかよw 

579 デフォルトの名無しさん [sage] 2010/10/18(月) 21:16:36 ID: Be:
    >>573
    何年かまえ、同人製作板を見てたことがあるけど、
    まだ一本も作ってないのにでかい口を叩いてるサークルとか腐るほどいた。

    ディレクターとか総指揮とかバトルシステムアドバイザーとかは何人も
    いるのに、プログラマーやら絵描きとは一人もいなくて募集してるとか、
    「商業レベルを目指してるんで、審査は厳しいです」とか。

580 デフォルトの名無しさん [sage] 2010/10/18(月) 21:22:17 ID: Be:
    バンドメンバー募集
    当方ボーカル他全部募集
    みたいな感じかw 

581 デフォルトの名無しさん [sage] 2010/10/18(月) 21:34:27 ID: Be:
    >>572
    こういう経緯があるせいかプログラマーって音楽とか絵もある程度できる人多い気がする
    俺は全然ダメだけど 

582 デフォルトの名無しさん [sage] 2010/10/18(月) 21:35:39 ID: Be:
    集めてから作りたいゲームを全員で話し合う所もあったそそうだ

    何のために集めたんだよ 

583 デフォルトの名無しさん [sage] 2010/10/18(月) 21:39:33 ID: Be:
    馴れ合いたいんだろう。コミュニケーションに飢えているんだよ。 

584 デフォルトの名無しさん [sage] 2010/10/18(月) 22:13:20 ID: Be:
    必要になるまで本は要らない。 

585 デフォルトの名無しさん [sage] 2010/10/18(月) 22:15:40 ID: Be:
    じゃ必要なときにこのスレにくれば良いだろ 

586 デフォルトの名無しさん [sage] 2010/10/18(月) 22:27:10 ID: Be:
    同人製作板ってどこにあるん? 

587 デフォルトの名無しさん [sage] 2010/10/18(月) 22:48:41 ID: Be:
    ググれ 

588 デフォルトの名無しさん [sage] 2010/10/18(月) 22:49:02 ID: Be:
    >>537
    まじめに話をすれば‥‥‥。

    最初にあたる本が良本である確率なんて、これっぽちもないし、期待してもいけないし、
    そもそも、人によって良本かどうかもかわるだろうし、
    本なんて、総じて中身の価値に比べると安いものだ、とわりきって、
    ぱりぱり読みこなすくらいの勢いが必要だと思うのです。

    このスレで良書をきく人も多いのですが、立ち読みしてよさそうなら買ってしまえば、道はあとから開けてくると思うんです。 

589 デフォルトの名無しさん [sage] 2010/10/18(月) 22:51:34 ID: Be:
    >>560
    独習は解答がついている。あと accelarated c++ は問題が豊富、ただ毛色にあわない、という評価もあるよう。 

590 デフォルトの名無しさん [sage] 2010/10/18(月) 22:52:28 ID: Be:
    アマゾンで本買ってるやつは情弱 

591 デフォルトの名無しさん [sage] 2010/10/18(月) 22:52:58 ID: Be:
    一番最初に買ったのはなんか萌え系のやつだったな
    CDが付いてきて問題とくヤツ 

592 デフォルトの名無しさん [sage] 2010/10/18(月) 22:52:59 ID: Be:
    学生が多いのかな
    給料とかあるととりあえず買ってから考える 

593 デフォルトの名無しさん [sage] 2010/10/18(月) 22:55:14 ID: Be:
    積読が増えるよ! 

594 デフォルトの名無しさん [sage] 2010/10/18(月) 22:56:39 ID: Be:
    1万超えると流石にためらう 

595 デフォルトの名無しさん [sage] 2010/10/18(月) 22:58:43 ID: Be:
    クヌース先生のアルゴリズム本は流石に考えた
    でもよくよく考えたら大した金額じゃないんだよな 

596 591 [sage] 2010/10/18(月) 23:01:13 ID: Be:
    http://amzn.to/dmUxZh
    これだった 

597 デフォルトの名無しさん [sage] 2010/10/18(月) 23:02:27 ID: Be:
    中古6000円ワロタ 

598 591 [sage] 2010/10/18(月) 23:04:57 ID: Be:
    6000円は流石に高いけど
    当時2000位だったから価格の割に分かりやすかったと思う
    #をいげたって読むのは多分これのせい 

599 デフォルトの名無しさん [sage] 2010/10/18(月) 23:08:20 ID: Be:
    最初に読んだのってなんだったかな
    もうおぼえてねーや 

600 デフォルトの名無しさん [sage] 2010/10/18(月) 23:13:36 ID: Be:
    最初に買ったのはベーマガ 

601 デフォルトの名無しさん [sage] 2010/10/18(月) 23:17:21 ID: Be:
    何の目的もないのにC++で何か作るってw
    あんな糞かったるい言語は速度が要求されるか,
    C++そのものが目的になったような人の言語で,
    目的を達成させるのには向いてないでしょ 

602 デフォルトの名無しさん [sage] 2010/10/18(月) 23:20:09 ID: Be:
    ロベールのC++入門講座を読めば大丈夫 

603 デフォルトの名無しさん [sage] 2010/10/18(月) 23:20:58 ID: Be:
    ロベールは冗長で読むのがシンドい 

604 デフォルトの名無しさん [sage] 2010/10/18(月) 23:21:53 ID: Be:
    アンチが出るのはよい本の証拠 

605 デフォルトの名無しさん [sage] 2010/10/18(月) 23:26:14 ID: Be:
    マジでC++はライブラリの呼び出し方くらいまでを覚えて、人が書いたものをうまく利用するのがコスパ高い
    基本的にCで十分

606 デフォルトの名無しさん [sage] 2010/10/18(月) 23:27:20 ID: Be:
    安置しかないの 

607 デフォルトの名無しさん [sage] 2010/10/18(月) 23:33:14 ID: Be:
    >>595
    TAOCPは古典的なアルゴリズムが網羅されているから
    持っていると本当に心強い
    さすがにバイブルと称されるだけのことはあるが、でもやっぱり高いw 

608 デフォルトの名無しさん [sage] 2010/10/18(月) 23:37:42 ID: Be:
    初めて勉強する言語にC++を選んでしまった俺は負け組 

609 デフォルトの名無しさん [sage] 2010/10/18(月) 23:41:36 ID: Be:
    >>608
    まだ負けたときまったわけではない。java は沈没しそう、python もいまいち、
    perl6 や ruby1.9 への移行も進んでおらず、lisp/scheme はオタク臭がとれない。 

610 デフォルトの名無しさん [sage] 2010/10/18(月) 23:42:44 ID: Be:
    そこでhaskellですよ 

611 デフォルトの名無しさん [sage] 2010/10/18(月) 23:44:32 ID: Be:
    TAOCPよりもMITPressのやつの方が個人的には好きだな、俺は 

612 デフォルトの名無しさん [sage] 2010/10/18(月) 23:45:10 ID: Be:
    >>610
    perl6 を混迷に陥れた張本人ですか‥‥‥。 

613 デフォルトの名無しさん [sage] 2010/10/18(月) 23:46:14 ID: Be:
    初めてでC++は無いわ
    最低限簡単にプログラミング出来る言語にすべき
    在りし日のBasicの様な感じのな
    ということで俺はdelphiを推す 

614 デフォルトの名無しさん [sage] 2010/10/18(月) 23:46:49 ID: Be:
    >>608
    じゃあ勝ち組言語って何だよw
    まぁ他の言語より難しい点では負け組か 

615 デフォルトの名無しさん [sage] 2010/10/18(月) 23:48:00 ID: Be:
    C言語が一番書いてて気持ち良いよ 

616 デフォルトの名無しさん [sage] 2010/10/18(月) 23:48:36 ID: Be:
    C++て他の言語より難しいか?
    Prologとかよりもずっと分かりやすいと思うが。 

617 デフォルトの名無しさん [sage] 2010/10/18(月) 23:49:19 ID: Be:
    そこでPrologを引き合いに出す時点で 

618 デフォルトの名無しさん [sage] 2010/10/18(月) 23:49:37 ID: Be:
    >>616
    懐かしいなProlog
    授業で習ったけど結局最後までチンプンカンプンだった 

619 デフォルトの名無しさん [sage] 2010/10/18(月) 23:49:54 ID: Be:
    >>615
    わかる 

620 デフォルトの名無しさん [sage] 2010/10/18(月) 23:50:40 ID: Be:
    C++が難しいってのは、言語使用を一通りおぼえようってときの話だろ。
    入門者向けのテキストに載ってるような2,30行の簡単なコードなら、
    文字列型はあるし、参照はあるし、Cよか簡単にかけるよ。 

621 デフォルトの名無しさん [sage] 2010/10/18(月) 23:50:56 ID: Be:
    better Cで良いじゃんw 

622 デフォルトの名無しさん [sage] 2010/10/18(月) 23:51:12 ID: Be:
    要するにbetter Cだな
    Cよりよほど導入に向いてる 

623 デフォルトの名無しさん [sage] 2010/10/18(月) 23:52:16 ID: Be:
    ねーよw 

624 デフォルトの名無しさん [sage] 2010/10/18(月) 23:53:10 ID: Be:
    >>615
    あー分かる
    業務だとJAVAだのC#だの書いてるけど
    一部の保守でC触ることがあるけど一番癒される

    ところでCマガのコンプリートDVD持っている人っている?
    流石に高くて気軽に手がだせん 

625 デフォルトの名無しさん [sage] 2010/10/18(月) 23:54:33 ID: Be:
    C++はライブラリの山を見た瞬間萎える 

626 デフォルトの名無しさん [sage] 2010/10/18(月) 23:55:01 ID: Be:
    Agdaでいいじゃん 

629 デフォルトの名無しさん [sage] 2010/10/18(月) 23:56:31 ID: Be:
    ここは皆の意見をまとめてC++ではなくPythonにするんだ。 

630 デフォルトの名無しさん [sage] 2010/10/18(月) 23:57:33 ID: Be:
    誰がpython奨めたんだよw 

631 デフォルトの名無しさん [sage] 2010/10/18(月) 23:58:29 ID: Be:
    どうしてそうなったw 

633 デフォルトの名無しさん [sage] 2010/10/19(火) 00:00:38 ID: Be:
    普通にPythonで良いと思う
    GUIもOpenGLも簡単に使えるからちょこっとプログラミングには最適 

634 デフォルトの名無しさん [sage] 2010/10/19(火) 00:01:50 ID: Be:
    ruby楽しくない?
    アンチがいっぱいいるのが理解できん 

635 デフォルトの名無しさん [sage] 2010/10/19(火) 00:03:06 ID: Be:
    わざわざRubyを使う必要性が感じられない
    新鮮味も何も感じられないし 

636 デフォルトの名無しさん [sage] 2010/10/19(火) 00:03:18 ID: Be:
    俺もPythonは嫌いじゃないが、日本だと一向に流行らないよな
    雑誌とかでも国産だけあってかRubyのが表に出てきている感じ 

637 デフォルトの名無しさん [sage] 2010/10/19(火) 00:03:43 ID: Be:
    rubyとpythonがいいよ
    今需要伸びてるし






    俺なら堅実にjavaやるけど 

640 デフォルトの名無しさん [sage] 2010/10/19(火) 00:07:12 ID: Be:
    javaはすでにAndroidとかに限らず将来性は抜群
    だけど悲惨なことにOracleの魔の手に・・・ 

641 デフォルトの名無しさん [sage] 2010/10/19(火) 00:10:15 ID: Be:
    導入にC言語の人多そうだけどあれもどうなんだろ?

642 デフォルトの名無しさん [sage] 2010/10/19(火) 00:13:53 ID: Be:
    別に悪くはないんじゃない
    良くもないけど 

643 デフォルトの名無しさん [sage] 2010/10/19(火) 00:14:05 ID: Be:
    結果的には良いと思う 

644 デフォルトの名無しさん [sage] 2010/10/19(火) 00:14:48 ID: Be:
    ポインタを理解できないような馬鹿をふるい落とすのには役立つ

    とJoelなんとかさんが言ってた 

645 デフォルトの名無しさん [sage] 2010/10/19(火) 00:15:44 ID: Be:
    最近はC#とJavaが多いね 

646 デフォルトの名無しさん [sage] 2010/10/19(火) 00:17:53 ID: Be:
    >>637
    堅実なのが良いなら,C,Java,PHP,Javascriptじゃないのか?
    後はOSによって,awkとかvbaとか.
    >>616
    C++が難しいのは言語仕様と罠の多さと修正のしにくさ
    手続きを並べるだけよりは,prologの方が難しい問題もあるのには同意 

647 デフォルトの名無しさん [sage] 2010/10/19(火) 00:19:22 ID: Be:
    C#を先にやったからC++やるときクラスの使い方おかしいコードがありふれててびっくりした。
    あいつらは何もわかってないとね。
    C#やJavaから始めたら逆につらくなると思う、ああいった言語の考え方は多くの場合相手にされない。 

648 デフォルトの名無しさん [sage] 2010/10/19(火) 00:19:43 ID: Be:
    ポインタはまだしも再帰で引っかかるってのがよく分からない
    数学的帰納法が理解できないっていう層とかぶるのかな
    自分で考えようとすれば池沼じゃない限り理解できると思うんだけどなあ
    思考が本当に停止してるとしか思えない
    そりゃ難しくしようと思えば出来るだろうけど 

649 デフォルトの名無しさん [sage] 2010/10/19(火) 00:20:03 ID: Be:
    C#はラムダ式が楽しすぎる 

650 デフォルトの名無しさん [sage] 2010/10/19(火) 00:21:59 ID: Be:
    >>648
    (たいていループで表現できるから使い道が)わからない
    ってことなんじゃないの?特に例題とかで出るフィボナッチ数列とかだと
    素直にループで書いたほうが分かりやすい 

651 デフォルトの名無しさん [sage] 2010/10/19(火) 00:23:21 ID: Be:
    >>649
    俺は嫌いだけどな
    変数の寿命が伸びるとかなんだよって思う。 

652 デフォルトの名無しさん [sage] 2010/10/19(火) 00:27:08 ID: Be:
    >>648
    多分本当に思考が停止してるんだよ
    理解できないって言うやつもLittle Schemer並にプロセスを細かく追っていったら
    絶対理解できるはずで
    単にそれをめんどくさがってやらないだけなんだよね 

653 デフォルトの名無しさん [sage] 2010/10/19(火) 00:29:48 ID: Be:
    古臭いCのポインタで挫折するぐらいなら導入にJavaを強く押そう 

654 デフォルトの名無しさん [sage] 2010/10/19(火) 00:31:26 ID: Be:
    C++は高級アセンブラでオブジェクト指向するイメージ。
    JavaやC#とは立ち位置が違う。 

655 デフォルトの名無しさん [sage] 2010/10/19(火) 00:31:35 ID: Be:
    再帰って,階乗とかlistを反転させるみたいに単純なのはいいけれど,
    二重とか右の子とか左の子とか,末尾あたりでマスターするの無理って思った
    久々に99 problemでも挑戦しようかしら 

658 デフォルトの名無しさん [sage] 2010/10/19(火) 01:43:40 ID: Be:
    組込みにはC、C++以外いらねえ。 

659 デフォルトの名無しさん [sage] 2010/10/19(火) 01:47:33 ID: Be:
    組込み以外C、C++いらねぇ。 

660 デフォルトの名無しさん [] 2010/10/19(火) 01:54:06 ID: Be:
    組み込みにC++はいらねぇ。 

C マガコンプリートDVDは買ったな。行方不明だけど(笑) ただあれ、画像としてスキャンしたものだから使い勝手は良くないんだよねー。

32bit はともかくとしても、16bit やら 8bitコントローラー向けのバイナリを吐ける C++ コンパイラーってあるの?

■_ これは以下略

Yahoo! 知恵袋から。


このプログラムはどこがおかしいのでしょうか? - Yahoo!知恵袋

先ほど適当にプログラムを作ったんですが、うまく動きません。
どうやらループが終わらないみたいです。
もしかしたら簡単なミスかもしれませんが時間がないので誰かお答えいただけないでしょうか?

コードはこれです↓

#include <iostream>
#include <conio.h>
#include <time.h>
#include <stdlib.h>
using namespace std;

int main()
{
    srand((unsigned)time(NULL));

    int *i;
    i = new int;
    aint m;
    int k = 0;
    for(k < 20000; k += 1;){
        cout << k << '\n'; //ループ確認
        m = rand() % 2;
       if(m == 0){
           (*i)++;
       }
    }

    double *n;
    n = new double;
    *n = *i / k;
    cout << "結果・・・" << *n << '\n';

    delete i,k,n;

    _getch();
    return 0;
}


ちなみに作った目的は擬似乱数が本当に乱数のようになっているか確かめたかったからです。
ポインタを使わなかったらできました。

「ループが終わらないみたいです」まで気づいているのになぜその先にいけなかったのだろうか・

■_ History of Ruby

このスレも方向がなんかあさっての方向へ行ってますがそれはさておき。 いや、バトルの方向にはなっているのか?


【Perl,PHP】LLバトルロワイヤル12【Ruby,Python】 
840 デフォルトの名無しさん [sage] 2010/10/19(火) 03:47:57 ID: Be:
    >>828
    Pythonは言語として読むケースのほうが多いが、Rubyはツールとして書くことが多いな。
    Railsとかその辺で開発言語としての側面が見られるようにはなったけど
    そもそものポジション、目的は随分と違うと思うんだ。

    「開発者」が「開発言語」として用いるものをややライトにした言語がPythonじゃないかな、と俺は思う。
    インデントの強制など、「読み手」を重視した仕様で多人数や長期開発でも読みやすく
    言語仕様は必要充分かつ最低限に抑え、様々なライブラリを標準のセットにしている。
    反面、コードはやや長くなりがちで、コピペだけでもエディタの補助が欲しくなる。
    組み込みライブラリは最低限なので、どうしてもライブラリに頼ることになる。

    Rubyは逆で「ユーザ」が「ツール」として使うのがそもそも根底にあると思う。Perlの次って名前なぐらいだし。
    左から右へと最小限のバックで書き足して行け、DSL的な拡張もしやすいため生産性はそれなりに高い。
    多様な機能を言語に組み込み、標準機能と組み込みライブラリだけでも文字列処理などが出来る。
    反面、DSL的拡張されたコードは長くなればなるほど読み難く、外部ライブラリの選択/利用には手間取ることも多い。
    パースし辛い仕様のため正確なコード解析をしてくれる高機能エディタには滅多にお目に掛かれない。

    もちろん、両者とも一部にあべこべな部分はあるのだけど…基本的にはこんな感じかと。
    結局ね、適材適所だと思うんよ。よく比較される両者だけど、そもそもは全然違う。
    片方の分野だけで語るのは、そこだけで完結する話ならいいんだけど
    それを基準にもう片方をまるで全否定するような話は違うと思うんだよ。 

841 デフォルトの名無しさん [sage] 2010/10/19(火) 04:01:52 ID: Be:
    なるほど、要するにrubyは素人用ホビー言語だ 

842 デフォルトの名無しさん [sage] 2010/10/19(火) 04:25:26 ID: Be:
    masterminds of programmingでそこらへん
    開発者が明確に書くかなーと思ったが、
    Matzの話が短すぎたわ 

843 デフォルトの名無しさん [sage] 2010/10/19(火) 04:30:25 ID: Be:
    Matzはあちこちでちょくちょく話してるイメージ
    そもそも原著にはMatz入ってないし、コードの世界でも読めばいいんじゃね 

844 デフォルトの名無しさん [sage] 2010/10/19(火) 04:37:36 ID: Be:
    matzはまとまった話を書かないからなあ
    っていうか記録自体も苦手らしく、
    たぶんストラウストラップのD&Eみたいな本は書けないだろうw

    まあこれまでの断片的な発言と、
    Rubyの仕様・歴史から読み取っていくしかない 

845 デフォルトの名無しさん [sage] 2010/10/19(火) 05:06:01 ID: Be:
    masterminds of programmingって
    awkの章はでかいのにMatzの話が短すぎ
    なのに日本版表紙はMatzがawkを潰してる

Guido パパが History of Python 書き始めた頃に、それとなく話を振ったことがあるけど そういうのを書くための(書くのに使える形での)資料は残してないので云々とか 逃げられた記憶が。

Ruby が Perl (Pearl)の次(活字の大きさで)ってのは偶然じゃなかったっけ?

■_ 本日の巡回から

2010年10月18日

■_

今回のセンゴク外伝は…んー

ソフトウェアデザイン、先月号買い忘れた。 まあ書泉あたりで買えるだろう。

■_

■_


Eugen Kiss / blog / The Next Big Language

The Next Big Language

Sunday,  17. October 2010

It is already 2010 and one wonders: What's going to be the next big language for this 
decade? A lot of people already tried predicting it and I admit it gets a little bit 
old. Anyways, this post is my take on it.

It is already 2010 and one wonders:
What's going to be the next big language for this decade? 
すでに過去、多くの人がそれを予言しようとしていて
いまそれをすることをはいささか遅れたものであることは認めます。
いずれにしても、このポストは my take on it です。

I won't consider languages that are mostly used in a particular niche like Erlang or 
PHP - even though they are ubiquitous in their respective niche. Instead I'm going to 
focus on general purpose languages. As we all know C, C++, C# and Java are these big 
mainstream languages of today with “recent” additions Python, Ruby, Javascript and, 
especially in the Apple world, Objective-C. These languages are here to stay for quite 
some time. I'd say at least the next 15 years. C might be around even much longer 
than that.

Erlang や PHP のようなニッチな領域で使われることがほとんどな言語は、
それらの言語がその respective niche では ubiquitous であったとしても考慮しません。
そうではなく、わたしは汎用目的の言語にフォーカスをあてようと考えています。
わたしたちすべてが知っているように
C や C++、C#、Java といったものは今日における big mainsteam languages です
especially in the Apple world, Objective-C.
“最近”加わった Python、Ruby、JavaScript、
そして特に Apple World においては Objective-C 
これらの言語はかなりの間その地位に居続けます。
それは少なくとも15年であろうとわたしは主張します。
C might be around even much longer than that.

It is great that productive and fun languages like Python became mainstream. But these 
dynamic languages have their downsides, too. Maybe it won't be speed anymore in the 
future (or in other words: the speed difference will become neglectable for most tasks) 
with projects like LuaJIT, v8, PyPy or Unladen Swallow. Still, the compile time 
correctness of static languages is something that is very convenient for certain tasks. 
As such, most of my predictions are statically typed languages.

Python のような productive で fun な言語が mainstream になったということは great です。
しかし Python のような動的言語は their downsides も抱えています。将来においては
LuaJIT、v8、PyPy、Unladen Swallow といったプロジェクトにより
それ (their downsides) はもはやスピードではありえなくなっているでしょう
(言い換えれば、速度の違いがほとんどの tasks にとっては neglectable になるということです) 。
それでもなお、静的言語のコンパイル時間は
いくつかの tasks にとっては very convenient な something なのです。
As such,
わたしの predictions の大半は statically typed languages です。

I want to add that I don't believe the next big language is a language that edges all 
the others away! There still will be other mainstream languages even if only for 
legacy reasons and there still will be highly specific niche languages. However, 
wouldn't it be great if there was a language which incorporated the flexibility of 
dynamic languages with the speed and the correctnes of statically typed languages and 
had support for a lot of paradigms without being a huge mess?

next big language が、edges all others way な言語であるとはわたしは信じていない
ことを付け加えたい!
legacy reasons に対してのみでさえ他にも mainstream languages があるでしょうし、
highly specific な niche languages もあるでしょう。
とはいえ、動的言語の flexibility を静的型付け言語のスピードと correctness と一緒に
incorporated し、かつ、大きな欠陥を抱えることなしに多くのパラダイムをサポートした
言語がもし存在したら、それは great なことではないでしょうか?



Disclaimer

I only have reasonable experience with Python and Java. I know enough Javascript for 
my needs and other languages which I used for some time without delving deeper are C#, 
C++, PHP, Scala, Groovy, Scheme, Lua and some BASIC Dialects. The impressions and 
opinions I've got from the contender languages are solely based on information about 
these languages on various websites, screencasts, discussions (from others) and code 
snippets I've seen. I haven't tried them in practice so take my opinions with a grain
of salt.

わたしは自分が必要とするのには充分な程度には JavaScript を知っていて、そのほか時々
使っていた言語には、C#, C++, PHP, Scala, Groovy, Scheme, Lua そしていつくかの
BASIC の変種があります。contender となっている言語からわたしが受けた印象と意見とは
ただ単に webサイトや screencast、ディスカッション、わたしが見たコード片などと
いったものから得たものです。
わたしはこれらの言語の practice をしようとはしなかったので、わたしに意見は
話半分に受け取ってください。

What do I expect from a programming language?
わたしがプログラミング言語に期待するものはなにか?

Before naming the predictions I want you to understand my metrics. They are ordered by 
descending priority. A good language should

この predictions に名前をつける前にあなたにはわたしの metrics を理解して欲しいです。
その metrics を優先順位の高い方から並べました。良い言語は

    * be readable  (読みやすくあるべきである)
    * be unambiguous (曖昧さがないようにすべきである)
    * be concise (一貫性を持つようにすべきである)
    * be expressive without heavyweight syntax
      (重苦しい構文を使うことなく expressive であるべきである)
    * have one (canonical) way of doing things
      (何かを行うためのひとつの (canonical な) 方法を持つべきである)
    * be fast (高速であるべきである)

All in all a language should feel like it helps you formalizing your thoughts instead 
of being a hindrance. Busywork code is not important. En passent, the Zen of Python is 
a great guiding principle for what a good language should be like.

言語というものは結局のところ、あなたの思考を邪魔するのではなくはなくて、
その formalizing を助けるようなものに感じられるべきものなのです。
En passent, Zen of Ptyhon は優れた言語はかくあるべしというもののための
great guiding princsiple です。

And now to the contenders:
それでは contenders の紹介といきましょう:

Clojure

    Clojure is a dynamic programming language that targets the Java Virtual Machine (and
    the CLR). It is designed to be a general-purpose language, combining the approachability
    and interactive development of a scripting language with an efficient and robust
    infrastructure for multithreaded programming. […] Clojure is a dialect of Lisp, and
    shares with Lisp the code-as-data philosophy and a powerful macro system. Clojure is
    predominantly a functional programming language, and features a rich set of immutable,
    persistent data structures. Source

    Clojure は動的なプログラミング言語で、Java Virtual Machine (と CLR) を
    ターゲットとしています。この言語は汎用言語であるように設計され、

    Clojure は Lisp の dialect であり、Lisp の code-as-data philosophy (コードとしての
    データ哲学?) と強力なマクロシステムを受け継いでいます。
    Clojure は predominantly な関数プログラミング言語で、

This pretty much sums up Clojure but I still want to add some of my impressions. In my 
opinion the most practically useful feature of clojure for day to day programming *1 are 
the native collection data structures, i.e. lists, vectors, maps, sets, that are all 
consistently abstracted after the idea of a head and a tail. I learnt to love to have 
such data structures available in a language while using Python. It makes you far more 
productive. This blog post comes to the same conclusion.

これは Clojure を pretty much sum up しますが
もう少しわたしの印象を付け加えたいと思います。
わたしの意見では、
day to day programming 向け *1 の
clojure の most practically useful feature は
データ構造のnative collection です。


Another important characteristic of Clojure is its orientation towards concurrency. It 
is important because our computers get more and more cores and using them efficiently 
is a problem. As Clojure is functional *2, which makes reasoning about concurrency 
easier since you don't have shared state and side effects, and has built in 
concurrency features like STM, Agents and Atoms it is a good fit for the “concurrent 
future”.

Clojure のもう一つの重要な characterstic が、その concurrency に対する orientation です。
これは重要です。なぜならわたしたちのコンピューターがそのコアをますます増やしていき
それらを効率よく使うことが問題となってくるからです。

Clojure は共有された状態がなく副作用もないfunctional であるので *2、
concurrency がより容易になっていて、
また STM や エージェント、アトム
のような組み込みの concurrecncy features を持っている



Moreover Clojure is a Lisp and therefore supports Macros, a super easy syntax and 
Metaprogramming. Although this is all nice and good (and powerful) and I came to 
appreciate Lisps when I learnt Scheme in University not everyone likes Lisps - even if 
only because of the “parantheses”. This will be a stumbling block for major adoption.

さらに Clojure は Lisp であり、当然のようにマクロと
非常に簡単な構文、そしてメタプログラミングをサポートしています。



Another double-sided sword is Clojure's attachment to the JVM. On the one hand this 
bootstrapped Clojure's adoption *3 and gave Clojure a variety of libraries to work with. 
On the other hand these Java libraries are not written with Clojure's idioms and thus 
probably feel not very fitting even though Clojure's Java interoperability is great. 
And who knows where Java the platform is heading in the future after Oracle's 
acquisition of Java? But Clojure in Clojure may loose the bound between Java and 
Clojure and make Clojure more independant.

もう一つの double-sided sword は Clojure の JVMに対する attachment です。
これは一方では bootstrapped Clojure の adoption であり、Clojure に variety libraries
to work with を与えます。
その一方で


Concluding, I think Clojure will get even more mindshare and momentum than it has 
already now. It seems to be a well thought out language that builds on proven grounds 
(Lisp, functional) yet still innovates (structural sharing, STM). There are still some 
show stoppers, e.g. editor/IDE support, but they will vanish eventually. Do I think 
that Clojure will become “the next big language”? Frankly, I don't know because 
even though Clojure is a general purpose language it is not the best fit for some 
problems simply because it is dynamical and embraces immutability.

結論としては、
わたしは考えています
Clojure が現在持っているそれよりも多くの mindshare と momentum を獲得するだろうと

まだいくつかの show stoppers が残っています
たとえば エディターやIDEのサポート
しかしそれらは eventualy に解消されることでしょう。



Summing up
概略

Advantages

    * great built in concurrency support
      great な built in された concurrency のサポート
    * strong native datatypes
      強力な native データ型
    * functional
      関数型である
    * it's a lisp
      Lisp である
    * on the jvm + natural interoperability with java

Disadvantages

    * on the jvm
    * it's a lisp
    * not that fast
      それほど速くはない
    * not very beginner friendly
      初心者向けではない

Articles/Links

    * http://www.ibm.com/developerworks/java/library/wa-clojure/index.html
    * http://thecleancoder.blogspot.com/2010/08/why-clojure.html

Screencasts

    * http://clojure.blip.tv/
    * http://channel9.msdn.com/shows/Going+Deep/Expert-to-Expert-Rich-Hickey-and-Brian-Beckman-Inside-Clojure/
    * http://www.infoq.com/interviews/stuart_holloway_clojure
    * http://www.youtube.com/watch?v=zRTx1oGG_1Y
    * http://channel9.msdn.com/posts/Charles/Emerging-Langs-Clojure-and-F/
    * TODO: Add http://confreaks.net/events/elcamp2010

Go

    Go is expressive, concise, clean, and efficient. Its concurrency mechanisms make it
    easy to write programs that get the most out of multicore and networked machines, while
    its novel type system enables flexible and modular program construction. Go compiles
    quickly to machine code yet has the convenience of garbage collection and the power of
    run-time reflection. It's a fast, statically typed, compiled language that feels like
    a dynamically typed, interpreted language. Source

    Go は expressive で concice、 clean かつ efficient なものです。
    Go の concurrency 機構はプログラムの記述を容易にします

    Go は即座にマシンコードへとコンパイルしますが
    さらにガーベジコレクションの convenience と実行時リフレクションの power を有しています。
    Go は高速で、静的型付けを行うコンパイル型でありながら
    動的型付けでインタープリター型の言語のように感じられる言語です


You probably heard about Go the Google sponsored, Rob Pike powered successor to C. I 
certainly like Go's philosophy especially the fact that Go wants to combine the ease 
of use and fun of dynamically typed, interpreted languages with the correctnes and 
speed of statically typed, compiled languages. Also, Go aims for minimalism. In 
contrast to other languages Go has very few keywords4.

あなたもおそらく耳にしたことがあるでしょう
Go は Google が sponsored していて
Rob Pike が powerd している C の successor であると。
わたしは Go の哲学、とりわけ ease of use と dynamically typed、
correctnes つきの interpreted languages と statically typed な compiled languages 
のスピード を combine しようとしていることが
とても好きです。
また、Go は minimalism を志向しています。
他の言語とは対照的に Go は非常に少数のキーワードしか持っていません。*4 

I also like the fact that concurrency is built into the language in the form of CSP. 
In that regard Go is armed for the future just like Clojure. Go's novel, “tolerant” 
type system with it's ad-hoc interfaces seems to by very convenient, too.

concurrency が CSP という形式で言語に組み込みになっているのもわたしは好きです。
これについては、Go はちょうど Clojure のように
armed for the future です。
ad-hoc インターフェースを伴った Go の新しい (Go's novel) 
“tolerant”型システムは seems to by very convenient, too

However I really must say that Go's syntax is somehow ugly. I don't know why but it 
seems hard to read. Maybe it is because I haven't programmed in Go and if I started I 
would accustom to it. But the first impression is not good.

しかしながら、Go の構文は somehow ugly であるといわざるを得ません。
なぜあのような構文になったのかは知りませんが、読みづらいもののように思われます。
それはおそらくわたしが Go でプログラミングしたことがないせいであり
実際に使い始めてみれば accustom してしまうかもしれません。
しかしその第一印象は良いものではありませんでした。

Then there are some questionable design decisions like no generics, defining the 
visibility of a variable/function by writing the first character in lowercase or 
uppercase, no enums5 and no exceptions *6.

さらに、generics がなかったり関数や変数の visibility の定義をその名前の最初のキャラクター
を小文字にするか大文字にするかで決めるとか、
enums も例外もないといったいくつかの設計上の疑問があります。

To conclude I think that Go has the potential to become the next big language but not 
in its current form. I like some things and I don't like others. I'm not yet sold on 
Go. But if it improves some of its design decisions (like adding generics) I believe 
Go's chances to truly become the next big language would more than double.

結論としてわたしが考えたのは、Go は the next big language となる可能性を秘めてはいるけれ
どもそれは current form ではありえないというものです。
Go についてはいくつか気に入ったものもありますがそうでないものもあります。
わたしはまだ Go がそれほど良いものとは思いませんが、
もしその design decisions のいくつか、たとえば generics の追加のような改良がされれば
Go が本当に the next big language になる chances は倍以上になると
確信しています。

Summing up

Advantages

    * relatively small
    * fast compilation
    * ad-hoc interfaces
    * concurrency support baked into the language
    * unconventional

Disadvantages

    * unconventional
    * ugly syntax
    * questionable design decisions

Articles/Links

    * http://blog.hackingthought.com/2010/06/first-impressions-of-golang.html
    * http://sayspy.blogspot.com/2010/10/my-thoughts-on-go.html
    * http://madhav-joshi.posterous.com/lets-go-a-first-look-at-googles-go-programmin
    * http://scienceblogs.com/goodmath/2009/11/googles_new_language_go.php
    * http://go.googlecode.com/hg/doc/ExpressivenessOfGo.pdf

Screencasts

    * http://confreaks.net/videos/115-elcamp2010-go
    * http://www.youtube.com/watch?v=5kj5ApnhPAE
    * http://www.youtube.com/watch?v=jgVhBThJdXc
    * http://www.youtube.com/watch?v=rKnDgT73v8s

D

    D is a systems programming language. Its focus is on combining the power and high 
    performance of C and C++ with the programmer productivity of modern languages like 
    Ruby and Python. Special attention is given to the needs of quality assurance, 
    documentation, management, portability and reliability. The D language is statically 
    typed and compiles directly to machine code. It's multiparadigm, supporting many 
    programming styles: imperative, object oriented, and metaprogramming. It's a member 
    of the C syntax family, and its appearance is very similar to that of C++. Source

    D はシステムプログラミング言語です。
    その focus は C や C++ の power および high performance と
    Ruby や Python のような modern な言語の programmer productivity を combining することです。
    Special attention は
    given to the needs of
    quality assurance,
    documentation, management, portability and reliability. 
    D は statically typed で machine code へ直接 compile します。
    D はマルチパラダイムの言語であり、多くのプログラミングスタイルをサポートしています:
    imperative (命令型), object oriented (オブジェクト指向), and metaprogramming
    (メタプログラミング)。
    構文的には C syntax family の一員でありその見た目は C++ のそれにとてもよく似ています。
    Source

You may remember this sentence from the introduction of this post.
あなたはこのポストの初めにあった次のセンテンスを思い出すでしょう。

    However, wouldn't it be great if there was a language which incorporated the 
    flexibility of dynamic languages with the speed and the correctnes of statically
    typed languages and had support for a lot of paradigms without being a huge mess?

Well, in my humble opinion D seems to take a huge step in that direction. Although Go 
is going in that direction, too, in the sense of combining the flexibility and fun of 
dynamically typed languges with the safety and speed of a statically typed system, it 
seems to me that Go is a bit too simple for its own sake. If you want to read a very 
interesting thread comparing D to Go on the Go Mailing list here you go. But if you 
want to take the short route this sentence pretty much sums up the different 
philosophies behind D and Go:

確かにわたしの見るところでは D は take a huge step in that direction
のようです。Go もまた flexibility と安全性と静的型付け言語のスピードを備えた
fun of dinamically typed language の combining という方向へ進んでいるにも関わらず、
わたしには Go は a bit too simple for its own sake であるように思われれるのです。


    Go seems to aim for simple as possible while being fast, flexible, and featureful
    enough. D seems to aim for fast, flexible, and featureful as possible while being 
    simple enough. Source

I really like the fact that D is featureful although many other point out that it is a 
disadvantage. It is indeed a disadvantage if a feature introduces more complexity than 
it provides productivity (I'm looking at you C++!). Turning the last sentence inside 
out gives: It is indeed an advantage if a feature provides more productivity than it 
introduces complexity (I'm looking at you D!). Let's consider Python. Python 
certainly is not a small language. Nevertheless it is one of the most productive 
languages around. See, that's what I'm talking about. With D you are not bound to 
one paradigm but can choose which paradigm to use for which problem. D has built in 
unit testing support which certainly improves its adaption. To cut a long story short, 
go to the D Website to learn more about D's features.

What shines from the outside is ugly inside. D has a bad reputation. I gathered some 
reasons from various complaints on the internet:

    * compiler bugs
    * no up-to-date open source compiler
    * standard library split (Tango, Phobos)
    * community feels not integrated in the process of developing D
    * backwards incompatible changeover to D2

So the consensus is that D the language is not bad at all but the language ecosystem 
is broken. But what is a language worth without a vivid ecosystem? It's probably nice 
to look at but you can't get anything done with it.

ですから、D は言語としては悪くはないけれどもその language ecosystem は broken である
というのが consensus です。しかし、vivid な ecosystem 抜きの language worth はどうでしょうか?
おそらくそれは nice to look ですがそれを使って何かをするということはできません。

Summing up I think D as a language has the most potential to become the next big 
language. Unfortunately it's ecosystem seems to be broken and unless it is not fixed 
D has a hard time fighting for the throne.

結論として、わたしが考えたのはこういうものです。
言語としての D は the next big language となる most potential を持っている
しかし残念なことにその ecosystem は broken であって、それが fix されない限りは
D は fighting for the throne (王位を巡る闘争) で困難な時間を過ごすでしょう。

Summing up

Advantages

    * real successor to C++
    * featureful
    * fast compilation
    * multi paradigm

Disadvantages

    * featureful
    * gets a lot of hate
    * broken ecosystem (?)
    * not innovative/unconventional enough

Articles/Links

    * http://nwcpp.org/images/stories/nwcpp-2010-09.pdf
    * http://www.informit.com/articles/article.aspx?p=1621867
    * http://www.informit.com/articles/article.aspx?p=1622265
    * http://www.informit.com/articles/article.aspx?p=1623791
    * http://stackoverflow.com/questions/146850/c-versus-d
    * http://stackoverflow.com/questions/3554956/d-versus-go-comparison/
    * http://groups.google.com/group/golang-nuts/browse_thread/thread/f24e7d46091e27ab
          o http://www.reddit.com/r/programming/comments/dohif/go_vs_d_interesting_thread_on_the_go_mailing_list/

Screencasts

    * http://vimeo.com/12941279
    * http://www.youtube.com/watch?v=RlVpPstLPEc
    * http://www.youtube.com/watch?v=XcL0JskdIvs
    * TODO: Add http://confreaks.net/events/elcamp2010

Underdogs

Now, these are languages that don't get a lot of publicity and thus won't take over 
anytime soon in contrast to Go, D and Clojure. Nevertheless it is interesting to see 
some more or less unconvential LWA7.

Rust

I can't say much *8 about Rust other than it is a statically typed programming language 
from Mozilla with a focus on systems programming and some interesting new ideas *9. To 
learn more about Rust have a look at this discussion or this blog post.

Clay

I was tired when I clicked the link to Clay's Homepage but the code snippets kind of 
made me awake again because they looked so good and readable. Clay is a generic 
programming language which aims to be a successor to C. Thus, Clay is as fast as C and 
has the same runtime overhead as C. On the other hand Clay has no garbage collector, 
which is mentionend as an advantage on the homepage. Yes, it is probably (or not?) an 
advantage for systems programming but not for general purpose programming. However, I 
don't think it would be impossible to make Clay have a garbage collector if it ever 
gained much traction. Here are some links/articles about Clay that get you informed.

OOC

I stumbled over a link to OOC on reddit I think. I didn't read information about OOC 
thouroughly but from the outside it looks quite nice. And if nothing else OOC has a 
good looking website ;).

BitC

As far as I understood BitC is a research language that combines low-level C with high 
level functional languages like Haskell or OCAML. Its aim is noble but it seems BitC 
has a long way to go.

わたしの理解した限りでは BitC は
低水準の C と、Haskell や OCAML のような高水準の関数言語とを組み合わせた
研究言語です。
その目指すところは noble ですが BitC には long way to go が待っているようです。


Factor

Whenever I read *10 something about Factor it is praised and it is particularly pointed 
out that Factor has an excellent interactive environment. As an outsider Factor looks 
weird to me but the enthusiats undoubtedly have a reason to like Factor so there must 
be something to it. Maybe someday I'll found out.

わたしが Factor についての何かを読んだときにはいつでも praised していて、
Factor が excellent な対話環境を持っていることをことさらに指摘しています、。
わたしにとってその見てくれは奇妙なものですが
the enthusiats undoubtedly have a reason to like Factor so there must be something to it.
おそらくはいつの日かわたしがそれを見ることもあるでしょう。


Lua

    Lua is a lightweight multi-paradigm programming language designed as a scripting 
    language with extensible semantics as a primary goal. […] Lua has a relatively simple 
    C API compared to other scripting languages. Source

    Lua はその primary goal として extensible semantics を持つスクリプティング言語として
    設計された軽量マルチパラダイムのプログラミング言語です。


Lua's focus is to be an embeddable language. Nonetheless it is very powerful on its 
own since it is built on selected, flexible features. The Wikipedia article about Lua 
says that its design has been influenced by Scheme and I think it shows. To learn more 
about Lua's design you can have a look at this discussion.

Lua の focus は組み込み可能な言語 (embeddable language) であることです。
Nonetheless it is very powerful on its own since it is built on selected, flexible features.
Wikipedia の Lua の記事にはLua の設計はScheme から影響を受けていると書かれています
そしてそれは表面に出ているとわたしは考えています。
Lua の設計についてより一層学ぶにはこの議論を見ると良いでしょう。


Often it is considered a problem by skeptics that Lua does not offer a lot of 
libraries like Python does that are very handy for general purpose programming. While 
it is true that Lua's standard library is small, since Lua's focus is to be 
embeddable, there is a large repository of libraries at LuaForge or Penlight. Still, 
despite being around for a long time Lua has not taken off as a general purpose 
programming language11. There are some opinions and discussions (or here) as to why 
this is the case. On the other hand Python, Javascript and Ruby were around a long 
time, too, until they finally gained traction… Plus, there is Luajit. It makes Lua 
almost as fast as C with considerably less code! If you don't believe me look at this 
benchmark that relates code size and execution speed of a language (implementation). 
Of course Luajit is architecture specific but it's still impressive.

しばしば問題視されます
skeptics によって
Python を general purpose programming のための very handy にしているような
多くのライブラリを
Lua が offer していないこと


In the not so distant future I'm going to get my hands dirty with Lua. Then I can 
blog about my experiences with Lua and check if my impressions on Lua will prove to be 
true.

Who will win?
勝者は誰か?

As you can see all three main contender languages are made by practitioners who saw 
mistakes in the existent languages and who learned from these mistakes. These 
languages are thus made to get work done. Also, they aren't designed with radical and 
untested ideas. Each language has longer roots than it seems. Clojure's roots are 
mostly Lisp and Scheme, D's roots are mostly C++ and dynamic languages in general and 
Go's roots are mostly C and some other languages based on CSP. Obviously their 
philosophies are quite different because of this.

見てわかるように、これら三つの main contender な言語すべてが practitioner によって
作られています
既存の言語の間違い(mistakes)を見ていた
そういった間違いから学んだ
これらの言語はしたがって get work done するように作られています
これらの言語はまた、radical で untested なアイデアを使って設計されています。



The underdog languages, especially Clay, seem to be very nice but unfortunately there 
is a reason why they are underdogs and major adoption in the following years is 
unlikely.

underdog な言語、とりわけ Clay は非常に nice になるように思われますが
残念なことにこれらの言語が underdogs であるのと、
adoption in following years is unlikely には理由があります


As far as I am concerned my fingers are crossed for D although I'd be happy if any of 
these languages gained traction. It's just that I found D's code snippets readable, 
I like D's philosophy and most importantly: there is a need for a successor to C++.

In the end it is of course not solely the language per se which will change the tack. 
Perhaps even more important than the language design is the language ecosystem, e.g. 
the libraries, (company) support, mind share, heroes etc. In this regard Go is ahead 
by a nose (Rob Pike, Google) but D has its stars (Andrei Alexandrescu, Walter Bright), 
too.

And even if none of the contenders will “win” - the programmer will win in any case 
because the innovation, discussion and competition that these languages provoke 
improve our understanding of programming and may even influence existing languages to 
incorporate new features.

Note: I bit off more than I could chew with this blog post so bare with me if I'm not 
that concrete in some places. Besides I still wait for some videos from 
http://confreaks.net/events/elcamp2010 to be uploaded so that I can link them in the 
appropriate places.

   1. functional features, immutability and native concurrency support are all nice,
      but they are not needed for every problem whereas data structures are always needed. 

      関数的機能、immutablity、ネイティブな concurrency のサポートはすべて nice ですが
      data structures が常に必要であるのに対してすべての問題に必要であるというわけでは
      ありません。

   2. although not purely functional
      純粋な関数型ではなかったとしても

   3. especially in corporate environments
      特に corporate な環境において

   4. If I remember correctly that's also the case for Clojure and Lua and probably a
      bunch of other (lesser known) languages. But Clojure and Lua are dynamically
      typed whereas Go is statically typed so it is not really a fair comparison.

   5. though you can almost recreate them with the help of iota

   6. though you can use defer/panic

   7. Languages with attitude ;)

   8. there is no official implementation of the language yet
      言語の公式な実装がまだありません

   9. for instance typestate [PDF]

  10. which is not often

  11. though Lua is widespread as a scripting language especially for games
      Lua は特に game 向けには広く使われているスクリプティング言語であっても
      

Posted in Programming, .

■_

イカ娘を観終わったら活動限界。

2010年10月17日

■_

1/700 日本海軍 工作艦 明石 W37
1/700 日本海軍 工作艦 明石 W37
ぐはっ。アサマシだけ貼っておきながら肝心の本文を書いている時間が~~~っ

■_ ふぉんと


文字コード総合スレ part6
327 デフォルトの名無しさん [sage] 2010/10/15(金) 02:45:20 ID: Be:
    Unicodeのcode chartに載ってる字形をそのままフォントにすれば
    Unicode完全網羅の最強フォントになると思うんだけど何か問題があるんですかね 

328 デフォルトの名無しさん [sage] 2010/10/15(金) 15:42:53 ID: Be:
    >>327
    ダサい 

329 デフォルトの名無しさん [sage] 2010/10/15(金) 15:47:56 ID: Be:
    著作権的にも問題あるけど、そういう話じゃないのかな?

    全ての文字を含めた全部入りフォントを何故作らないのって意味なら、知らん 

330 デフォルトの名無しさん [sage] 2010/10/15(金) 19:14:28 ID: Be:
    とりあえず、あのPDFに埋め込んであるやつをおすそ分けしてほしい 

331 デフォルトの名無しさん [sage] 2010/10/15(金) 23:05:35 ID: Be:
    Unicodeの全文字を入れたフォントって意味なら、残念ながら作れない。
    Truetype/Opentypeは、文字を16ビットで管理してるから65535字までしか入らないのだ。 

332 デフォルトの名無しさん [sage] 2010/10/15(金) 23:37:16 ID: Be:
    まじかー。そんなところに制約があったとは。

    フォントリンク的な機能で補うしかないのかな。
    あるいは、そっちにも同じ制約があったりとか 

333 デフォルトの名無しさん [sage] 2010/10/15(金) 23:55:21 ID: Be:
    フォントの規格から作り直せと。。 

334 デフォルトの名無しさん [sage] 2010/10/16(土) 00:08:40 ID: Be:
    OpenTypeにもサロゲートペア導入の波 

335 デフォルトの名無しさん [sage] 2010/10/16(土) 00:27:46 ID: Be:
    TrueType的にはダメなんだよね。
    OTFでなんとかなんないの? 

336 デフォルトの名無しさん [sage] 2010/10/16(土) 01:00:20 ID: Be:
    Windows自体はフォントリンク機能を持っているんだから、
    コンパネから手軽に設定できるようにしてくれればいいのに。 

337 デフォルトの名無しさん [sage] 2010/10/16(土) 01:04:12 ID: Be:
    素人にいじらせるとろくなことないからな。 

338 デフォルトの名無しさん [sage] 2010/10/16(土) 01:05:32 ID: Be:
    フォントよね~ 

339 デフォルトの名無しさん [sage] 2010/10/16(土) 01:45:21 ID: Be:
    >>331
    まさかUnicodeの2バイトってそこから来たんじゃないよね?
    まさか… 

340 デフォルトの名無しさん [sage] 2010/10/16(土) 02:04:48 ID: Be:
    どう考えても逆 

341 デフォルトの名無しさん [sage] 2010/10/16(土) 03:53:51 ID: Be:
    >336
    Windowsのダイアログはフォントによって表示サイズが変わる仕様になってるから、
    下手にフォントいぢると、多くのアプリでコントロールの位置がずれる等の支障が出る。 

342 デフォルトの名無しさん [sage] 2010/10/16(土) 11:01:46 ID: Be:
    >>335
    CFF Outlineの仕様が追加されただけでTTFとほとんど仕様は変わらないので
    制限も同じ。
    つーかそろそろOS/2テーブルのUnicode rangeも使い切りそうなんだが
    どうするつもりなんだろう 

343 デフォルトの名無しさん [sage] 2010/10/16(土) 12:55:29 ID: Be:
    もう使い切っちゃった。残りはReserved for process-internal usageだって。
    ttp://www.microsoft.com/typography/otspec/os2.htm#ur 

344 デフォルトの名無しさん [sage] 2010/10/16(土) 13:26:26 ID: Be:
    OS/2テーブルもv5になるわけか。
    こりゃWindows 7でのUnicode 6.0対応はますます望めそうにもない 

345 デフォルトの名無しさん [sage] 2010/10/17(日) 00:02:51 ID: Be:
    とりあえずSP1では、Unicode 6の文字が表示できるようにならないと… 

346 デフォルトの名無しさん [sage] 2010/10/17(日) 09:15:53 ID: Be:
    Mac OS X 10.7 では Unicode 6 対応してますように… 

TrueType の内部構造、むかーーーしにちょっとだけ勉強したなあ。 複雑でよくわからなかったような(要するに覚えてない)。

■_ Ruby post-Python: first impressions


skilldrick.co.uk » Ruby post-Python: first impressions

Ruby post-Python: first impressions
July 16th, 2010 

I've been using Python for a while and really like it. I'd heard a lot of good stuff 
about Ruby so decided to have a go to see what all the fuss was about. The list of 
differences between Python and Ruby on ruby-lang.org was useful in writing this post. 
Here are my first impressions:

わたしはこれまで長いことPythonを使ってきていてとても気に入っています。
Ruby がよいという話をたくさん聞いたのでどういったものなのか確かめてみることにしました。
ruby-lang.org にある Python と Ruby との違いの一覧はこのポストを書くのにとても
参考になりました。わたしの第一印象は以下に挙げたとおりです:


    * One of the things that always bugged me about Python is its lack of proper lambdas.
      Sure, you can use a locally defined function instead, but it doesn't give you the
      kind of fluency you can achieve programming in Scheme or JavaScript, say. I haven't
      done much Ruby yet, but it seems there are various ways to do lambdas/closure, in a
      more flexible way than Python. This wouldn't have mattered to me, but since I've 
      been working through SICP and using JavaScript more, I've been thinking in closures.

      Python に関していつもわたしを bugged させるもののひとつが、proper な lambda がない
      ということです。確かに(無名関数の代わりに)関数の局所的な定義を使うこともができますが
      それはあなたが Scheme や JavaScript でachieve できる fluency の類をわたしに
      与えてはくれないのです。わたしはまだそれほど Ruby を使っていませんが、それでも
      Python よりはずっと flexible なやり方の様々な lambda や closure を使う方法があるようです。



    * This doesn't really set it apart from Python, but it does seem to have good consistent
      coding conventions, which I think are important for a language. And I like the fact
      that capitalised class names and lowercase variables are enforced by the language.

    * I used to think it sounded dangerous, but I like the fact that parentheses are
      optional for function calls. I can see how this can make Ruby a very expressive
      language.

    * I've never understood why in Python objects have a __len__() method, but the standard
      way is to use the len() function to access it. Why not treat objects like objects and
      use method calls?

      なぜ Python のオブジェクトは __len__() メソッドを持っているのに、標準的な方法では
      オブジェクトの長さをとるのに len() 関数を使うのか理解できない。
      なぜオブジェクトをオブジェクトらしく扱ってメソッド呼び出しを使わないの?

    * One type of array, not lists and tuples. Minor headache resolved!
      配列はひとつの型であって、リストとタプルに分かれていたりしない。
      ちょっとした頭痛の元がなくなった!

    * Parsed and unparsed strings like in PHP, making use of the distinction between single
      and double quotes. Useful.

      PHP 同様、解析される文字列と解析されない文字列がある。シングルクォートと
      ダブルクォートで違いを持たせている。便利。

    * Private methods – thank you!

    * 0 as a truthy value – not sure about this. Although I suppose it's clearer to say
      if count > 0 rather than if count.

      0 が真偽値の真。これについては確信はもてないけれども、if count とするよりは
      if count > 0 としたほうが明確になると思う。

    * elsif instead of elif. That's going to cause me a lot of typos.

      elif ではなく elsif を使っている。これは大量の typo を生み出すだろう。


   1. Bastien Léonard
      July 31st, 2010 at 14:33 | #1

      len() vs __len__(): http://mail.python.org/pipermail/python-3000/2006-November/004643.html

   2. Skilldrick
      July 31st, 2010 at 21:45 | #2

      Hi Bastien, thanks. Yes, that does make sense.

Copyright © 2010 skilldrick.co.uk

■_ Ruby post-Python: second impressions (or: how I learned to stop worrying and love the implicit)

んで三ヵ月後のエントリ。


skilldrick.co.uk » Ruby post-Python: second impressions (or: how I learned to stop worrying and love the implicit)

Ruby post-Python: second impressions (or: how I learned to stop worrying and love the implicit)

October 17th, 2010 

So, it's three months since I wrote Ruby post-Python: first impressions. I've got a 
few small things to say, and a few bigger things. I'll start with the small things:

    * I was worried before about the change from elif to elsif, but it turns out this 
      hasn't been a problem. Having a decent case statement means I haven't had to write a 
      single elsif since I've been using Ruby.

    * The case statement is AWESOME. Being able to match against ranges, regexes etc. is
      just pure genius.

    * I said about parsed and unparsed strings before – at that point I didn't know about
      string interpolation. More awesomeness.

    * I'm still on the fence with 0 not evaluating to false, but I can see more and more
      why you'd want it. For example, instead of saying if myArray.length you'd use if
      myArray.empty? which is obviously more readable.

    * Question marks in method names are brilliant. I first came across the idea in Scheme,
      and I love it.

Implicitness (implicity?)

So, here's my main second impression. It's all to do with the implicitness of the two 
languages.

さて、わたしの second impression (第二印象?) を述べましょう。
すべては二つの言語の implicitness についてのものです。

In Python, there's a preference for explicitness. Indeed, line two of The Zen of 
Python reads:

Python では explicitness を好む傾向があります。
The Zen of Python の二行目にもこうあります:


    Explicit is better than implicit.


Ruby is very different in this respect. Ruby's syntax is full of implicitness. One 
good example is self in methods. Every method in Python needs self as its first 
argument (I know it's only called self by convention). And when you call a method 
inside an object, you call it on self. In Ruby, the self is implicit, both as an 
argument and as the receiver of the method call.

Ruby はこの respect とはかなり異なるものです。Ruby の構文は implicitness
(暗黙のオヤクソク) の塊です。良い例の一つが、メソッドにおける self です。
Python ではすべてのメソッドは self がその第一引数として必要です (もちろん
self というその名前は規約としてそうなっているだけだというのは知っています)。
そして、オブジェクトの内部でメソッドを呼び出すときには selft をつけた上で
呼び出します。Ruby の場合、この selft は
引数としてもメソッド呼び出しのレシーバーとしても implicit です。

I'm not going to get into an argument here about which is better. My current thinking 
is that requiring self as an argument to every method is completely redundant, but I 
quite like the clarity of using self as the receiver of all internal method calls. It 
still makes me nervous not prepending self. to method calls in Ruby – they look like 
global function calls to me. I'm getting used to it though.

Another example is method invocations. In Python, you need the parentheses. In Ruby 
you don't. This gives an advantage to both languages. On the Python side, it means 
that myObj.meth returns the method, whereas myObj.meth() returns whatever meth() 
returns. That gives handy functional expressivity. I use this all the time in 
JavaScript, where it's essential to know the difference between func and func().

On the Ruby side, the ability to call methods without parentheses has some really nice 
consequences. Coupled with method_missing, it gives the ability to write really nice 
internal DSLs. And because direct access to object attributes is impossible, you're 
able to write code that looks like direct attribute access with all the benefits of 
accessor methods. That is a huge win for me. Nobody likes having millions of getters 
and setters, but if the alternative is having to rewrite all your client code when you 
realise you need to do more than simple assignment they're a necessary evil. Thanks 
Ruby for helping me avoid that!

Something else that's nice with Ruby's implicitness is the fact that arrays and hashes 
don't need brackets and braces. I mean, what else could :a => 5 be other than a hash? 
The syntax is unambiguous, so there's no need to insist.

Special cases
特殊なケース

Here's another line from The Zen of Python:

    Special cases aren't special enough to break the rules.

It strikes me that this is another big philosophical difference between the two 
languages. In Python, whatever you're doing, you'd better be doing it consistently and 
by the rules. It's rare that special syntax is added to do something that could be 
achieved with normal code. Ruby, on the other hand, tends to optimise for the common 
usage, which might mean in certain cases a different syntax may be needed. Eli 
Bendersky, in his excellent blog explained this philosophy in his description of 
Ruby's blocks:

    … there is one common case that stands high above all other cases – passing a 
    single block of code to a method that makes something useful out of it, for example 
    iteration. And as a very talented designer, Matz decided that it is worthwhile to 
    emphasize this special case, and make it both simpler and more efficient.

Is it worth keeping all syntax consistent, or is it OK to introduce special forms for 
certain common circumstances? Before I started using Ruby, I was probably in the 
former camp, but I've been convinced of the advantages of the latter now.

Metaprogramming
メタプログラミング

Every time the question of differences between Ruby and Python come up (or more often, 
the issue of superiority), the Pythonistas insist that all the metaprogramming magic 
possible in Ruby is possible in Python as well. But the fact of the matter is, it's 
just not used that often in Python. With Ruby though, metaprogramming is just what's 
done. In a lot of ways, this goes back to the implicit/explicit divide, in the sense 
that dynamically created methods aren't visible in your source code. Personally, I 
don't see the problem with that, but I can see why this would upset others.

What does Python have?
Python が持っているものって?

It's obvious that I've fallen for Ruby, and Python's lost its shine a bit for me. But 
it's worth acknowledging the bits that Python does well. Interestingly, these all seem 
to be related more to the community than the language (although the language selects 
for the community pretty heavily I guess).

    * Solid libraries, especially NumPy/SciPy. There's not really an equivalent in Ruby.

    * Stable libraries. In Ruby, and especially Rails, the best way to do something today
      will be the old way to do it tomorrow. There's always a better way to do it, and it
      can be difficult to keep up. Because most of my experience in Ruby has been in Rails
      so far, it's hard to say whether this is actually just a feature of the Rails
      community.

    * Mature community. This might be controversial, but it feels to me like the Python
      community likes to just get stuff done, whereas the Ruby community wants to be 
      playing with the newest, shiniest things out there.

    * Decent GUI. By this, I mean PyQt. QtRuby looks like it's miles behind PyQt, and 
      FxRuby doesn't look very advanced. PyQt, however, is great, even if there is a bit
      of impedance mismatch between a C++ framework and Python.

Copyright © 2010 skilldrick.co.uk

残りもがんばって訳します ○| ̄|_

反響→ Ruby post-Python: second impressions (or: how I learned to stop worrying and love the implicit) : programming

■_

この会社辞めようと思ったソースコード#1C 
592 仕様書無しさん [sage] 2010/10/17(日) 00:22:25 ID: Be:
    10年くらい前に emacs 禁止の現場が有ったな
    理由はメモリ消費量だったんだが、あの頃のマシンってどのくらいのメモリ積んでたんだろ? 

593 仕様書無しさん [sage] 2010/10/17(日) 02:35:41 ID: Be:
    unix系マシンのメモリは高価だったので必要最小限しか積んでいなかった筈。

    ヘタすると128MBとか256MBとかだったり…… 

594 仕様書無しさん [sage] 2010/10/17(日) 06:16:07 ID: Be:
    emacs禁止は多かったね。
    vi厨を生んだ原因。 

595 仕様書無しさん [sage] 2010/10/17(日) 07:18:15 ID: Be:
    10年前にはもうemacsぐらい問題にならないぐらいメモリ積んでたろ。
    20年前ぐらいのSun3とかの時代にはemacsの禁止には意味があった。 

596 仕様書無しさん [sage] 2010/10/17(日) 13:08:06 ID: Be:
    >>595
    10年前の時点での最新機種ならば、問題にならなかったろう。
    開発機が、その時点での10年モノだった可能性は?
    ・開発機はコンパイルとテスト実行だけできればよいという観点でメモリをケチるケースが結構あった。

    本番機はそもそもemacsが導入されていないケースが多い。酷い時はviすら入っていない……

597 仕様書無しさん [sage] 2010/10/17(日) 15:35:18 ID: Be:
    >>596
    えっと、Y2K問題まっさかりの頃に、開発機がemacsが動かないスペックだったの?
    それはかなり少数派だと思うよ。 

598 仕様書無しさん [sage] 2010/10/17(日) 15:54:36 ID: Be:
    いや少数派というか偽装ハケンやら3重請負とかそういうところならあるかも。 

599 仕様書無しさん [sage] 2010/10/17(日) 16:28:03 ID: Be:
    >>596-598
    開発マシンは ultra-sparc(スペル正しい?)だったかな、Emacs が動かないスペックでは無いよ
    正にY2K対応の現場だったんだけど、とにかく人数が多い現場で一つのマシンに20人くらいぶら下がってたからかなぁ


600 仕様書無しさん [sage] 2010/10/17(日) 16:36:04 ID: Be:
    >>599
    ultra sparcなんて十分に贅沢なマシンじゃねえかw
    俺の知ってる現場じゃ、68kのsunでemacs普通に使ってたぞ。 

601 仕様書無しさん [sage] 2010/10/17(日) 17:52:39 ID: Be:
    emacs禁止は、シェアしている場合のルール。
    専用ならそんなルールはできない。
    ぶら下がっている奴が多ければ、今でもあり得る。 

602 仕様書無しさん [] 2010/10/17(日) 17:52:42 ID: Be:
    >>600
    CPUの問題じゃないからねぇ

    68000 使った sun なんて何時の話だよ、20年前でも 68020 だった記憶が有るんだけど 

603 仕様書無しさん [] 2010/10/17(日) 19:13:47 ID: Be:
    いま使っているUNIX鯖はemacs入ってないな。viだけ。

    若干修正するには使えるけど、これでコーディングとかは
    無理だなぁ。

68000 使ったSun はさすがに見たことないなあ。 20年前ってえと 1990年か。SPARC 搭載モデルでたのいつだっけ。

■_ 1200p


くだすれPython(超初心者用) その8 
640 デフォルトの名無しさん [hage] 2010/10/16(土) 17:46:01 ID: Be:
    ttp://1-byte.jp/2010/10/15/learning_python_for_a_week/

    自分で目標を立てておいて申し訳ないのですが、自分はステップ1で早速遅れが生じました。
    “初めてのPython“はなかなか手強く、このタスクを消化するのに2週間を使ってしまいました。

    そもそも、この”初めてのPython“に挫折した人も多いはず。
    前回の記事についたはてブのコメントを見てそれを感じました。
    総ページ数が768、付録を抜いても700ページはあります。 

641 デフォルトの名無しさん [sage] 2010/10/16(土) 18:34:01 ID: Be:
    で? 

642 デフォルトの名無しさん [sage] 2010/10/16(土) 19:06:42 ID: Be:
    で? 

643 デフォルトの名無しさん [sage] 2010/10/16(土) 20:48:45 ID: Be:
    ど? 

644 デフォルトの名無しさん [sage] 2010/10/17(日) 02:32:03 ID: Be:
    技術書ってそんなに力んで読むものじゃないと思うんだけどな 

645 デフォルトの名無しさん [sage] 2010/10/17(日) 03:22:40 ID: Be:
    世の中には
    ・隅々までむしゃぶりつくように読み尽くすべき本
    ・必要なときに必要な場所だけ読めばよい本
    ・読まずに捨てたほうが良い本
    がある

646 デフォルトの名無しさん [sage] 2010/10/17(日) 08:39:10 ID: Be:
    >>640
    ワラタ(www

    現実的な計画も立てられないダメな子は、無駄に分厚い糞本を選ぶんだな(ww 

647 デフォルトの名無しさん [sage] 2010/10/17(日) 09:15:04 ID: Be:
    つか、1週間でって言っても、まるまる暇な人とほとんど時間取れない人がいるのに。
    その差を考えずに1週間でできるとか書かれてもねぇ。

    Pythonを使えるようになりたいのなら、どの章も1日で、とか考えなくていいから、
    ・ mutableとimmutableの違い
    ・ iterableなオブジェクトとその使い方
    ・ Pythonにおいて、classがいかに仕事してないか
    あたりは理解できるまでコード書け。 

648 デフォルトの名無しさん [sage] 2010/10/17(日) 09:45:44 ID: Be:
    はじぱいは漬け物付けるのに使った方がいいな。
    おいしい漬け物を食べるとモチベーションが上がる。
    あの無駄な重量は鈍器としても活用可能。
    自分を殴って眠気を吹っ飛ばすのに最適。 

649 デフォルトの名無しさん [sage] 2010/10/17(日) 10:18:57 ID: Be:
    4版は1200ページくらいあるからな。日本語化が楽しみだ 

650 デフォルトの名無しさん [sage] 2010/10/17(日) 12:33:10 ID: Be:
    最低でも2分冊だろ。 

651 デフォルトの名無しさん [sage] 2010/10/17(日) 12:47:43 ID: Be:
    今なら電子版4edが$39.99だよ 

652 デフォルトの名無しさん [sage] 2010/10/17(日) 17:25:10 ID: Be:
    >>640
    1週間でとか、はてなブックマークのためのタイトル釣りみたいなものだろw 

653 デフォルトの名無しさん [sage] 2010/10/17(日) 17:48:34 ID: Be:
    1200ページもあったらマニュアルより詳しく書いてあるの? 

654 デフォルトの名無しさん [sage] 2010/10/17(日) 17:55:45 ID: Be:
    オライリーもいいけど好きな事しながらWebドキュメント読んでりゃ自然学習できるでしょ
    俺は土方的な学習より、哲学本やエッセイ読んでる方が10倍は充実すると思うなあ・・ 

655 デフォルトの名無しさん [sage] 2010/10/17(日) 18:16:28 ID: Be:
    一行目は同意だけど
    二行目は意味が分からない 

どうなるんだろうなあ > Learning Python 4th ed.

■_ 本日の巡回から

■_ どうして

日曜日の夜ってこんなにせわしないんだろう ○| ̄|_

2010年10月16日

■_

あとで貼る



竹迫さんのセッションを聴いている Larry さん。

プログラミングでは数学の力が必要とのことですが どの程度の数学の力が必要になる... - Yahoo!知恵袋 今年のYAPCも楽しかった - a geek born in Tomakomai

■_

色々書いたのですが没に。

■_

■_


この会社辞めようと思ったソースコード#1C 
590 仕様書無しさん [sage] 2010/10/14(木) 01:37:08 ID: Be:
    vi 使えない状況で思い出したが、ls を消してしまったときはどうしようかとオモタよ 

591 仕様書無しさん [sage] 2010/10/14(木) 01:54:19 ID: Be:
    SunOSの 4.1.3 くらいの頃のマニュアルに、非常手段の例として
    ファイル一覧を見るには echo *
    ファイルを作るには echo ... > outfile
    ファイルを表示するには while read ... ... < infile
    みたいなのが載ってた希ガス。

シェルの組み込みコマンドだけでも結構イロイロできるんですよね。

2010年10月15日

■_

・YAPC
いろいろとぐんにょり(イベントが、ではなく)な事態だったので省略(えー

Larry のあれを他の言語に対する dis りってのはちと違う気がするんだけどなあ。

・Lisp 勉強会
第5回ありえるえりあ勉強会 〜「Lisp脳」勉強会 〜 : ATND の、 「Lisp脳とかやめよう」 てのが気になる気になる。

■_

翻訳されるかな。これ。 まあ量的にはそれほどでもないので自力でも。


Oct. 14, 1985: C++ Adds to Programming | This Day In Tech | Wired.com

Oct. 14, 1985: C++ 

(略)

Wired.com: Any advice for young programmers?

Stroustrup: I guess giving advice is easy compared to taking it. Know your 
fundamentals (algorithms, data structures, machine architecture, systems) and know 
several programming languages to the point where you can use them idiomatically.

Know some non-computer field of study well — math, biology, history, optics, whatever. 
Learn to communicate effectively in speech and in writing. Spend an unreasonable 
amount of time on some difficult topic to really master it. Try to do something that 
might make a difference in the world.


Wired.com © 2010 Condé Nast Digital. All rights reserved.

この辺はいつもの主張と変わりませんね。

■_ strlcpy やら


晴 - Note
2010-10-14 晴
■[C] strcpy_sなんて使うな

超今さらですが、C1x?に、セキュア文字列関数群*1が正式に入るみたいですね。

http://www.open-std.org/JTC1/SC22/WG14/www/projects#24731-1

で、google:strcpy_sで検索すると、strcpyなんて使うな。安全でセキュリティの高いstrcpy_s
を使え!という旨の文面がいっぱいでてくるわけですよ。馬鹿だと思いますね。この「セキュア」
文字列関数群を最初に考えた人も、乗せられて使え使え言ってる人達も……。勿論strncpyや
strlcpyも含めて。

確かにバッファオーバーフローは阻止できますよ。スタックが上書きされて暴走したり悪意のあ
るコードが実行されたりするのは阻止できますよ。でも、その結果、データが欠けたまま処理が
進んでしまうわけですよ。規格ではset_constraint_handler_sでオーバーフロー時のハンドラを
設定できたり、VC++ではSEHに乗せてくれたりするのはマシな動作だと思います。落ちたほうが
マシ。
(以下略)

まあ確かにおっしゃるとおりで、strlなんちゃらやら strなんちゃら_s がなくなったから といって問題が雲散霧消するわけはない (たとえば何らかの構造をもった画像ファイルの ヘッダー部分が偽装されたやつとか) んですが、 それでもないよりはましだろうというのがわたしの考えです。

ただ… strncpy はちょーーっとここに含めるのには適度でないものの気が。

■_


kikairoya's ntfmt at master - GitHub

New Type-safe string output formatter safe and compact substitution of printf/iostream 
This project licensed by Boost Software License 1.0.

Features:
* type-safe
* customizable with a few set expressions.
* small object code size (quarter of newlib's printf)
* separated floating-point code * exception-free 

■_

今日もなかなか面白い質問が。


CPUの構造を理解する意味は? | OKWave
CPUの構造を理解する意味は?

よくプログラムの勉強をするときにCPUの内部構造である制御装置、演算装置、レジスタなどの
解説があって、さらにそれらがどういう繋がりがあって、どうお互いを利用しているか、という
ことを説明する本に出会います。

しかし実際アセンブリ言語で開発しようという人間以外に、誰がこの知識を必要とするのか全く
わかりません。

C言語以上の高級言語を使用するのであればこれらの知識は不要ですよね??

※C言語の勉強でメモリーの構造を理解する必要があるのはわかります。

すでに締め切られていますが、自分が回答する立場であったらさてどう答えるか。

■_ フォネティックコード

プログラミングに関係する単語でそろえたらどうなるかなあとか。

ASCII
BASIC
Compile
Digital
Emacs
FORTRAN
Google
Hash
Information
Jump
Kludge
Language
Monitor
Neuman
Octal
Pascal
Queue
Redmond
Spredsheet
Task
Utility
Void
Window
X
Y
Zilog

X と Y が浮かばなかった…

■_ 本日の巡回から

2010年10月14日

■_

むかーーし、dBase III だの IV だのというソフトウェアがありまして (ボーランドによるアシュトンテイトの買収はアレだったよなあ。やっぱり)。 あれってプログラム組んだんだっけ? やっぱそうか。 "dBASE プログラミング言語"

dBASE - Wikipedia
プログラミング例

以下の例では、従業員表("empl")を開き、"filter"をセットしてマネージ
ャー(部下を持つ人)を選択して表示し、給料を10%上げて、結果をプリンターに印刷する。

 USE empl            
 SET FILTER TO supervises > 0
 GO TOP
 IF .NOT.EOF()
   BROWSE
   REPLACE ALL salary WITH salary * 1.1
   GO TOP
   LIST fname, lname, salary TO PRINT
 ELSE
   WAIT "該当がありません"
 ENDIF
 SET FILTER TO
 USE

dBASE は初めて(Perlのずっと以前に)ビジネス向けに文字列評価を実装した。

 i = 2
 myMacro = "i + 10"
 i = &myMacro.
 * i now has the value 12 

"&" は "MyMacro" に格納されている文字列の内容をプログラムコー
ドであるかのように評価する。

へえ。

■_

■_ How to become a programmer

中学生からの質問なのですが

プログラマになるにはどうすれば良いのでしょう? | OKWave
プログラマになるにはどうすれば良いのでしょう?

プログラマになるにはどうすれば良いのでしょう?

はじめまして、プログラマになりたい中学1年生です。
将来はソフトプログラマー(PCソフト系)になりたいと思います。
プログラミングの知識は全くありません。経験もありません。
(関係ないでしょうが、HTMLができるぐらいです)

今回質問したいのは....。

・プログラマとはどういう職業なのか。
・プログラマにはどのような種類があるのか(ゲームプログラマやソフトプログラマなど)
(そして、その種類に属する人達は、主に何をやるのか)
・システムエンジニアとの違いは。
・数学が苦手でもできるか。
・プログラマに必要な知識・資格・心構え・道具はなにか。
・プログラマの平均年収・月収は?
・C言語の活用法

などです。
ちなみに、高校は工業高校に進学したほうが良いのでしょうか?
大学はどのような学校にはいれば良いのでしょうか?
やはり、C言語は覚えたほうが良いのでしょうか?

質問ばかりですいません。
どなたか、詳しい方、ご回答お願いします。

どういう回答したもんですかねえ(笑) いくつか回答がついてはいますが。

■_

YAPC だ。寝よう。

2010年10月13日

■_

なんというか、信条やらなんやらで人を分類したくはないけど (ぴー) な人たちには (ぴー) な人が多いんですかねえ。 やたらと見かけるような気がするんだけど。

■_ VBA

はまった。


       t = Cells(1, i).Value ' ○
       ' = Cells(1, i)         ☓
       If Dict.exists(t) Then
           いろいろ
       End If

ついうっかり、.Value を忘れて代入してしまったら、 辞書(連想配列) の要素チェックに引っかからなくなってしまったという。 実際にはさらに一時変数も使わずにチェックしたんですが。

■_ その1

■_ self

Python の self 必須はあまり気にはならないとは以前書きましたが


ueBLOG | 打者9人が全員イチローだったら?
算出方法

算出方法はメジャーリーグ公式HPから取得してpythonで計算している。

スクレイピングが面倒そうだったので、16ページ分を手でコピーしてテキストに落としてからデータ化している。

来年もやるのでスクレイピング部分を書いてから、どこかにUPしようかと思う。

#! /usr/bin/env python
#! vim: fileencoding=utf8
import csv
import decimal
class Player(object):
       def set_name(self, name):
               self.name = name
               self.key = name
               self.lis = []

       def set_stat(self, lis):
               self.TEAM = lis[0]       #チーム
               self.POS = lis[1]        #ポジション
               self.G = int(lis[2])     #試合数
               self.AB = int(lis[3])    #打数
               self.R = int(lis[4])     #得点
               self.H = int(lis[5])     #ヒット数
               self.B2B = int(lis[6])   #2ベースヒット
               self.B3B = int(lis[7])   #3ベースヒット
               self.HR = int(lis[8])    #ホームラン
               self.RBI = int(lis[9])   #打点
               self.TB = int(lis[10])   #塁打数
               self.BB = int(lis[11])   #四球
               self.SO = int(lis[12])   #三振
               self.SB = int(lis[13])   #盗塁
               self.CS = int(lis[14])   #盗塁失敗
               self.OBP = float(lis[15])#出塁率
               self.SLG = float(lis[16])#長打率
               self.AVG = float(lis[17])#打率
               self.lis += lis
               self.lis.append(self.HBB)
               self.lis.append(".%03d" % (self.AVG2*100))

       def set_stat2(self, lis):
               lis = lis[2:]
               self.SF = int(lis[0])  #犠飛
               self.SH = int(lis[1])  #犠打
               self.HBP = int(lis[2]) #死球
               self.IBB = int(lis[3]) #故意四球
               self.GDP = int(lis[4]) #併殺打
               self.TPA = int(lis[5]) #打席
               self.NP = int(lis[6])  #打者に投げられた投球数
               self.XBH = int(lis[7]) #単打以外の安打
               self.SBper = float(lis[8]) #盗塁成功率 盗塁÷(盗塁+盗塁死)
               self.GO = int(lis[9])  #ゴロアウト
               self.AO = int(lis[10]) #フライアウト
               self.GO_AO = float(lis[11])   #フライ1つに対するゴロ
               self.OPS = float(lis[12]) #出塁率+長打率
               self.lis += lis
               self.lis.append(self.SBD)


       @property
       def HBB(self):
               """ 安打 + 四球 """
               return self.H + self.BB
(略)

ここまで self に溢れているとさすがにどうにかならんのかという 気もしますね(^^; VBA だと with が使えたりしますが。

こういうのは構造体 (とPythonでもそう呼称していたかは知らない) を作って 一気に代入したりすると楽なんだろうか。

■_ regex


blog | Perlgeek.de :: Longest Palindrome by Regex

Sat, 09 Oct 2010
Longest Palindrome by Regex

A few hours ago colomon blogged a Perl 6 solution to the longest palindrome 
programming challenge. It was a bit slow.

An all-regex solution looks like this:
正規表現を使ったsolution はなべて次のようなものです:

for $string.match(:g, /(\w+) \w? <{ $0.flip }> /) {
    # process palindrome match here
    # filter out the longest match
}

It's also very slow, and it's very wasteful. So, can there be a hybrid between manual 
search a regex?

これはとても遅く、かつ非常に効率が悪いものです。
では、manual search と正規表現とのハイブリッドのものというのはあり得るのでしょうか?

The regex engine is quite fast, and using it to find the center of a palindrome is a 
good starting point. From there on we can can move to both sides, and compare 
character by character if moving away from the match still results in a palindrome:

正規表現エンジンはとても速いもので、それを palindrome の中心を見つけるために使っている
ことはとてもよい starting point です。



my $s = 'Fourscoreandsevenyearsagoourfaathers...';

my $solution;
my $longest = 0;
for $s.match(:g, /(\w)\w?$0/) {
    # $_ now holds a Match object,
    my $left = .from - 1;
    my $right = .to;

    # go to left and right while palindromic
    while $s.substr($left, 1) eq $s.substr($right, 1) {
        $left--;
        $right++;
    }

    # we move a bit too far
    $left++;
    $right;

    # and we're only interested in the longest
    # palindromic substring
    my $len = $right - $left;
    if $len > $longest {
        $solution = $s.substr($left, $right - $left);
        $longest = $len;
    }
}
say $solution;

This now runs in under 1.5 seconds on the 1169 characters long example input string.

コメントで、正規表現使ってるから遅いんじゃないの? 正しい答えが求められないケースもあるよ? というのが寄せられています。 まあバックトラック多そうだしなあ。

文字列のメソッドの flip ってなんだっけ。 何かが改名されたやつだった記憶があるんだけど。

■_ FAQ

Revised Pitfall list
From comp.lang.lisp Thu Oct 26 16:06:28 1995
Newsgroups: comp.lang.lisp
Subject: Revised Pitfall list
Message-ID: <DH17Jy.GrH@cogsci.ed.ac.uk>

I've added a number of new items and revised others to make
the presentation clearer or to fix mistakes.  The result is
a bit long, and I'm considering ways to make it easier to deal
with.  Suggestions are welcome.

----------------------------------------------------------------------
Common Lisp Pitfalls
(Common Lisp の落とし穴)

Last updated: Thu Oct 26 00:56:33 1995 by Jeff Dalton

This is a list of "pitfalls": little traps that can catch even
experienced programmers.  They often involve somewhat counterintuitive
aspects of Common Lisp that tend to be revealed only by a careful
reading of CLtL (or of the ANSI standard).  However, pitfalls do not
necessarily represent defects in the language.

The list was written by Jeff Dalton <J.Dalton  ed.ac.uk>.  Please
send suggestions and corrections.  Even the best Lisp books can
fall into pitfalls or get some of these issues wrong.  That makes
it more important for lists like this to be correct, and for that
I need your help.


Another pitfall list, containing parts of this one, can be found in
the "Frequently Asked Questions" list of Comp.lang.lisp.

Contents:
目次
 * Assorted pitfalls             全般的な落とし穴
 * Sort pitfalls                 ソートに関する落とし穴
 * Function vs eq
 * Iteration vs closures
 * Limits
 * Definitions and declarations
 * Packages
 * CLOS
 * Acknowledgments

All references to CLtL are to the 2nd edition.

Assorted pitfalls.
雑多な落とし穴

  * The result of many non-destructive funcions such as REMOVE
    and UNION can share structure with an argument; so you can't
    rely on them to make a completely new list.

    REMOVE や UNION のような多くの非破壊的関数の結果は引数の構造と共有される可能性が
    あります。ですから、それらの関数が完全に新規のリストを作ることに依存することはで
    きません。

  * APPEND copies all of its arguments _except the last_.
    CONCATENATE copies all of its (sequence) arguments.

    APPEND は *最後のものを除く* 引数全てをコピーします。CONCATENATE はその引数 (sequence)
    全てコピーします。

  * SORT is (usually) destructive.

    SORT は (通常) 破壊的です。

    So, for instance, (SORT (REMOVE ...) ...) may not be safe.

    ですから、たとえば (SORT (REMOVE ...) ...) は安全でない可能性があります。

  * Destructive functions that you think would modify CDRs might
    modify CARs instead.  (Eg, NREVERSE.)

    あなたがCDRを変更すると考えている破壊的関数は
    実はCAR 部を変更するものかもしれません(例 NREVERSE)。


  * The value of a &REST parameter might not be a newly constructed
    list.  (Remember that the function might be called using APPLY,
    and so an existing list might be available.)  Therefore it is not
    safe to modify the list, and the following is _not_ equivalent to
    the LIST function: (lambda (&rest x) x).  [See CLtL p 78, which is
    not as clear as it might be.]

    &RESTパラメータは新規に構築されたリストとは限りません (APPLY を
    使って呼び出される可能性のある関数を思い出してください)。したがって
    そのようなリストを変更することは安全ではなく、(lambda (&rest x) x)
    という関数は LIST 関数と等価なものではありません。


  * Many of the functions that treat lists as sets don't guarantee
    the order of items in the result: UNION, INTERSECTION, SET-DIFFERENCE,
    SET-EXCLUSIVE-OR, and their destructive "N" versions.

    リストを集合として見なす関数の多くが、その結果に収められているアイテム
    の順序を保証していません: 
    UNION, INTERSECTION, SET-DIFFERENCE, SET-EXCLUSIVE-OR
    そしてそれぞれの破壊的バージョン。

  * REMOVE- and DELETE-DUPLICATES keep the _later_ (in the sequence)
    of two matching items.  To keep the earlier items, use :FROM-END T.
    Remembering that :FROM-END exists may make it easier to remember
    the default behavior.

    REMOVE-DUPLICATES と DELETE-DUPLICATES は、二つのマッチングアイテムの
    (シーケンスにおける) 後者を保存します。前者を保存するには :FROM-END T
    を使います。
    Remembering that :FROM-END exists may make it easier to remember
    the default behavior.

  * Array elements might not be initialized to NIL.  Eg,

    配列の要素は NIL で初期化されないかもしれません。

       (make-array 10) => #(0 0 0 0 0 0 0 0 0 0)

    Use (make-array 10 :initial-element nil).

  * READ-FROM-STRING has some optional arguments before the
    keyword parameters.  If you want to supply some keyword
    arguments, you have to give all of the optional ones too.

    READ-FROM-STRING にはキーワード引数の前にいくつかの省略可能な引数が
    あります。キーワード引数(の一部)を supply したいのであれば、省略可能
    引数のすべても共に与えてやらなければなりません。

    Other functions with this property: WRITE-STRING, WRITE-LINE,
    PARSE-NAMESTRING.

    この属性を持つそのほかの関数: WRITE-STRING, WRITE-LINE,  PARSE-NAMESTRING。


  * EQUAL compares both vectors and structs with EQ.  EQUALP descends
    vectors and structs but has other properties (such as ignoring
    character case) that may make it inappropriate.  EQUALP does not
    descend instances of STANDARD-CLASSes.

    EQUAL は EQ を使って二つともがベクターであるものや二つともが structs であるものの比較をします。
    EQUALP はベクターや structs を descends しますが make it inapproproate するかもしれない
    (キャラクターの大小文字の違いを無視するような) other propertiesを持っています。
    EQUALP は  STANDARD-CLASSes のインスタンスを descend しません。

  * EQ may return false for numbers and characters even when they seem
    to be provably the same.  The aim is to allow a greater range of
    optimizations, especially in compiled code, by not requiring that
    numbers and characters behave like proper objects-with-identity.
    CLtL p 104 gives an extreme example: (let ((x 5)) (eq x x)) might
    return false.

    同一のものと思われる数値同士やキャラクター同士であってさえ、EQ は
    false を返す可能性があります。広い範囲での最適化を可能にするために、
    特にコンパイル済みのコードにおいて数値やキャラクターは適切な identity
    を持ったオブジェクトのように振る舞うことを要求されてはいません。
    CLtL p 104はその extreme な例です: 
    (let ((x 5)) (eq x x)) は false を返すかもしれません


  * Some Common lisp operators use EQ, rather than the usual EQL,
    in a way that cannot be overridden: CATCH, GET, GET-PROPERTIES,
    GETF, REMF, REMPROP, and THROW.  See table 5-11 on p 5-57 of the
    standard.

    一部の Common Lisp の関数は通常よくある EQL ではなく EQ を使います
    in a way that cannot be overridden:
    CATCH, GET, GET-PROPERTIES, GETF, REMF, REMPROP, and THROW.
    See table 5-11 on p 5-57 of the standard.


  * The function LIST-LENGTH is not a faster, list-specific version
    of the sequence function LENGTH.  It is list-specific, but it's
    slower than LENGTH because it can handle circular lists.

    LIST-LENGTH 関数はシーケンス関数 LENGTH のリスト特化バージョンであり、
    高速ではありません。これはリストに特化したものであり LENGTH よりも低
    速であるものの循環リスト(circular list)を取り扱えます。


  * (FORMAT T ...) interprets T as *STANDARD-OUTPUT*
    All other I/O functions interpret T as *TERMINAL-IO*.

    (FORMAT T ...) は T を *STANDARD-OUTPUT* として解釈します。
    その他のすべてのI/O 関数は T を *TERMINAL-IO* として解釈します。


  * COERCE will not perform all of the conversions that are available
    in the language.  There are good reasons for that, but some cases
    may be surprising.  For instance, COERCE will convert a single-character
    string to a character, but it will not convert a character to a 
    single-character string.  For that you need STRING.

    CORECE はその言語において avairable なすべての変換を perform するわけではありません。
    そうすることのきちんとした理由があるのですが、ときとしてびっくりするようなケースがあります。
    たとえば COERCE はキャラクター一つの文字列 (single-character string) を
    キャラクターに変換しますが、キャラクター一文字を (その一文字だけから構成される)
    文字列に変換はしません。そういった場合にあなたが必要とするのは STRING です。

  * The DIRECTORY function returns the TRUENAME of each item in the
    result, which can be slow.  If you don't need the truenames, on
    some systems it's faster to run "/bin/ls" and read its standard
    output (if your Lisp supports this).

    DIRECTORY 関数はその結果にある各アイテムの TRUENAME を返しますが、これは
    遅くなる可能性があります。もし truenames が不要なら、一部のシステムでは
    "/bin/ls" を実行してその標準出力を読み出す方が速くなります(使っ
    ている Lisp がそれをサポートしていれば、の話ですが)。


  * The following trick for intercepting all unwinds is not portable
    and might not be allowed at all:

    すべての巻き戻し (unwinds) を intercepting するための次のトリックは
    portable でもなくどんな所でも使えるわけでもありません:


     (tagbody (unwind-protect (do-some-stuff)
                ;; Intercept all unwinds, ha ha!
                (go where-I-say))
       where-I-say
        ;; We always get here.
        (do-some-more-stuff))

    Informally: once an unwind to a certain point has begun, it must
    always go at least that far.  [See CLtL pages 189-192.]  Similar
    tricks using THROW or RETURN-FROM suffer the same fate.  I used 
    GO above because I think that makes the intention clearer.

    非公式には、ある特定の場所へのアンワインドが始まってしまうと、
    it must always go at least that far.
    [See CLtL pages 189-192.]
    同様の THROW or RETURN-FROM を使った トリックは suffer the same fate です。
    わたしは上記のGOを使っています。それはこれが意図を明確にするものだと考えているからです。


  * Remember that there are "potential numbers" and that they are
    reserved tokens [CLtL pages 516-520].  Normally, only odd things
    such as 1.2.3 or 3^4/5 are "potnums", but when *READ-BASE* is
    greater than 10, many more tokens are effected.  (For real fun,
    set your read base to 36.)

    "potential numbers" があることや予約されているトークンがあることを
    思い出しましょう [CLtL pages 516-520].
    通常は 1.2.3 や 3^4/5 のような "potnums" だけが odd things ですが、
    *READ-BASE* が10より大きかった場合にはもっと多くのトークンが影響を受けます
    (For real fun, set your read base to 36)。


SORT pitfalls.
(SORTの落とし穴)


  It may seem odd to have a whole section devoted to SORT, but I've
  seen so many erroneous SORT calls that I've decided it's necessary.

  SORTの説明をするのにセクション一つを丸々使うのを奇妙に思われるかもしれませんが、
  わたしはあまりにも多くの erroneous SORT calls を見てきているので、その必要があ
  ると判断しました。


  * As mentioned above, SORT is (usually) destructive and so such
    combinations as (SORT (REMOVE ...) ...) may not do as you expect
    (if what you expect is that REMOVE will produce a new list).

    先に言及したように SORT は(通常は) 破壊的であり、(SORT (REMOVE ...) ...) のような
    組み合わせはあなたの期待通りには動作しないかもしれません
    (if what you expect is that REMOVE will produce a new list)。

  * SORT may not return equal elements in the same order in different
    CL implementations, because different sorting algorithms are used.
    To ensure that you get the same result in all implementations, 
    when that's what you want, use STABLE-SORT (or write your own).

    SORT は実装が異なる CL においては異なるソートアルゴリズムが使われ
    ているために複数の値が等しい要素が同じ順序になっていないかもしれません。
    すべての実装において同じ結果を得ることを保証したいのであれば、
    STABLE-SORTを使いましょう(あるいは自分でソートを書きましょう)。

  * The comparison predicate given to SORT is treated as a strict
    "less than" and so should return NIL when its 1st argument is 
    considered greater than _or equal to_ its 2nd.

    SORT に与えられた comparison predicate は strict な "less than"
    として扱われ、第一引数が第二引数より大きいか第一引数と第二引数が等しいとき
    には NIL をかえすべきものです。

  * If the comparison predicate (strictly speaking, the combination
    of the predicate and the key function) does not consistently express
    a total order on the items being sorted, then the items "will be
    scrambled in some unpredictable way" [CLtL p 408].

    もしこの comparison predicate (厳密に言えば、predicate の combination とその
    キー関数) がソートされたアイテム群の total order について一貫した表現を
    していないのであれば、そのアイテム群は
    "will be scrambled in some unpredictable way"
    (some unpredicable way で scramble される) でしょう。
    [CLtL p 408].
    comparison predicate → 比較のための述語?

    It's easy to go wrong when writing "lexicographic" multi-step
    comparisons and end up with a predicate that says both A < B 
    and B < A for some A and B.  For example:

    これは一部の A と B に対して A < B かつ B < A とするような predicate を使った
    "lexicographic" な multi-step comparisons を書くときに
    間違いやすいものです。
    たとえば:

      (defun fg-lessp (a b)
        (or (< (f a) (f b))    ;first compare f values
            (< (g a) (g b))))  ;then compare g values

    Fg-lessp does the right thing when (f a) is less than (f b):
    it returns true -- and when (f a) is equal to (f b): it goes
    on to compare g values.  But it also compares g values when
    (f a) is _greater than_ (f b), when what it should do is return
    false.

    fg-lessp は (f a) が (f b) よりも小さいときには正しく動作し、true を
    返します。そして (f a) と (f b) が等しいときには g の値を比較しに行き
    ます。しかし、(f a) が (f b) *よりも大きい* ときでも、false を返すので
    はなく g の値を比較してしまうのです。


    Also make sure the predicate is _transitive_.  For instance,
    if you're comparing objects of different types and you decide
    (for example) that numbers are < strings and strings are < symbols,
    make sure the predicate says numbers are < symbols too.

    同様に、predicate を _transitive_ にします。
    たとえばもしあなたが異なる方のオブジェクトの比較をしようとして、
    たとえば数値は文字列よりも小さく文字列はシンボルよりも小さいという決定をしたならば、
    その predicate は数値はシンボルよりも小さいと判定するようにするということです。


  * CLtL suggests that using the :KEY argument to SORT may be more
    efficient than calling the key function inside the comparison
    predicate (p 408).  However, it may well be less efficient.
    Implementations may not take advantage of the separate :KEY
    to extract the keys only once; and the key function might be
    compiled in-line when it appears inside the predicate.

    CLtL は SORT に対する :KEY 引数を 使ったほうが comparison predicate の
    内部で key 関数を呼び出すよりもより効率的であるという提案をしています。
    (p 408). しかしそちらの方が効率が悪い可能性もあります。
    実装は分かれた :KEY のキーへの展開を一度だけ行うというアドバンテージを取らないかもしれません。
    またその key 関数は predicate の内側に現れたときにはインラインにコンパイルされるかもしれません。

続きます。

■_ その2

■_ YAPC

明日からか。

■_

軍オタが好きな名言、名ゼリフ 7 /a>
174 名無し三等兵 [sage] 2010/10/13(水) 00:22:51 ID:??? Be:
    「人間、生きていればショッキングな出来事に遭遇することもある。
    取り返しがつかずどうしても納得のいかないこと、決して消えることも癒えることもない悔しさ、泣き叫びたくなるような惨めさ・・・
    だが人生というものは筋の通らないことの連続なのだ、真の大人ならば誰でも知っているように。」

    ジーン・クランツ空軍少尉

175 名無し三等兵 [sage] 2010/10/13(水) 10:13:10 ID:??? Be:
    >174
    良い言葉だ。  深いな。 

176 名無し三等兵 [sage] 2010/10/13(水) 12:46:16 ID:??? Be:
    いずれ帳尻は合うもんです 

■_

京急線の踏切で女性はねられ死亡、電車遅れ約1千人に影響/横須賀:ローカルニュース : ニュース : カナロコ -- 神奈川新聞社

京急線の踏切で女性はねられ死亡、電車遅れ約1千人に影響/横須賀

2010年10月12日

 12日午前11時25分ごろ、横須賀市追浜本町1丁目の京急線金沢八景第4踏切で、女性が
  三崎口発青砥行きの上り快速特急電車(8両編成)にはねられ死亡した。田浦署は、
  近くに住む無職女性(60)とみて身元の確認を急いでいる。

 京急電鉄によると、電車は7分後に運転を再開、約1千人に影響した。

…7分後?

2010年10月12日

■_

寝落ち。

■_


OK, proggit, let's talk about career paths. : programming

I was talking with a friend who will be graduating in a year with a Mathematics/ 
Computer Science degree. He's going to the same college I went to, taking the same 
program I took. He was asking me about what to expect in the real world, and what his 
career path might look like.

I was able to give him a 5-6 year forecast, as that's how far ahead of him I am. 
However, my question to you is, what does the world look like further out?

Based on my experiences, this is what I was able to tell him:

    * 1st year: You'll have a hard time finding a job, as you don't have any experience, and
      once you do get an offer, you'll probably be making low to mid 30's. Try to learn as
      much as you can about the industry your employer is in, and try to learn from the
      developers around you.

    * 2nd year: You should have a grasp of the business side of things where you work, and
      are leaps and bounds better at programming than you were when you started a year ago
      (Let's hope). Now, try to assess what weaknesses you have in your programming skills.
      At the end of the year you should have seen a decent pay increase from the year before.

    Goals to shoot for for the end of the year:
    この年の目標

       1. mastery of at least one testing suite (JUnit, NUnit,

       2. a good understanding of the GoF design patterns

       3. A clear understanding of why your business is using the languages it is, and 
          what alternatives exist that could replace them

       4. Are you being compensated as well as you think you should? Do you have a balanced
          work:personal life ratio? If you aren't being paid what you feel you should, use
          services like yahoo hotjobs to find out what the average salary is for your 
          position in your geographic location. If your employer won't play ball, you are
          much more marketable than you were as a new grad. You are still pretty green, but
          a developer with two years experience is leaps and bounds more useful than a green 
          graduate.

    * 3rd year: If you don't know a scripting language or two, make this the year to learn two.

          o Find a language that is in a different paradigm from the one you use at work
            every day. Pick a pet project of medium complexity, something you can finish
            in twenty to forty hours of work and do it over no more than a month. Chances
            are you work in an OO language, learn a functional language.

    * 4th year: Do you understand threading? You better. Multi-core hardware and concurrency
      strategies are a real life issue. You can't afford to be ignorant of these skills.
      When you reach the end of this year, think back to where you were 8 years ago, a
      starry-eyed hopeful. You've learned so much since then. Remember what you thought your
      career would be like when you graduated? That kid was so naive, and your professors
      probably fed you all these fairy tales about requirements documents and the software
      life-cycle. Those practices are actually worthwhile, but the reality is business factors
      don't allow you the leisure to follow through on every step of the life-cycle process,
      and budget constraints don't allow your team to have a dedicated business analyst.

    * 5th year: Whoa! A half of a decade! You probably think you're king shit now. Have you
      been using the same technologies for 5 years? Look at how long those technologies have
      been around, and what new up and comers and fighting to take your expertise's market
      share. You don't want to become a dinosaur. Learn, learn, learn. What does the future
      look like for your technology stack? Look at who owns your technology stack, and what
      have they done with their wards in the past? Hopefully you aren't look at the same
      conditions Java developers are looking at now. A monstrous monetizing monolith taking
      over your tech stack, with the threat of future releases no longer being free. Suing
      everyone they think they can wring a buck out of, or bankrupt, or steal from, using
      the strong arm of the law.

    * 6th year: I'm here, it's scary. You should be in a position of influence by this point.
      Maybe you aren't the lead developer on your project, but you should definitely not be
      a code monkey. This is another point in your career where you can look at jumping ship
      and expect it to be fairly painless. Before you take that 40% raise to move to NYC or
      Silicon Valley, look at what the cost of living is there compared to where you are now.
      Will you be getting bumped into a higher tax bracket, only to have your spending power
      reduced by a higher cost of living? At 30 years old, do you want to be having roommates?
      Can you afford to live in a good community, so your kids can go to the good schools?
      Have you been saving up enough to be able to afford to take 6 months of no pay, so you
      can work on that start up?

      今ココ

■_

2010-10-12 - primitive: blog EASTL から垣間見るゲームソフトウェア開発現場の現状 その 1 ゲーム、というか組み込み一般にも言えることが多いと思いますがそこはおいといて、


2010-10-12 - primitive: blog

C++ ゲームプログラマに関して、以下のような懸念もある。

    * C++ は大学では教えられなくなりつつある。C++ を理解している人材は少なく、STL のよ
     うな template を理解している人材となるとさらに少ない

    * 若い開発者にはジェネリックプログラミングは馴染みが薄い。STL のヘッダファイルは込
      み入っており、経験の浅いプログラマがこれを追うのは大変な作業になる。理解しやすい STL 
      の実装を作ることは、熟練者が思っている以上に価値がある。

    * ゲーム開発者は STL のコンテナやアルゴリズムを調査し、トレースできる必要がある。これは
      コンテナ自身だけの問題ではなく、ユーザーのコンテナの使い方のデバッグまで含めた問題で
      ある。

    * C++ の template は「トリッキー」「煩雑」などの理由で嫌われる。あるプログラム言語を使う
      ためにその言語の弁護人になるべきではない。

日本の場合「なりつつある」どころかはなから(教育分野で)使われることはあまりなかった ような気もするんですがどうなんでしょうか。

2010年10月11日

■_

・rssリーダーの登録情報がぶっ壊れた ○| ̄|_

【タートル】LOGO【パパート】 イキナリこんなスレが。 懇親会ではLogoの話題も出たなあ。

・iPhone4
なんか今すぐ買えますとか販売店が宣伝してた。

・ベイスターズ
親会社が変わるのはほぼ決定な感じですねえ。どこがどうなるかはわからんけど。 TBS は嫌いだけど、ベイスターズの親会社としてはかなり感謝している。 「横浜ベイスターズ」のままにしてくれたし、佐々木様が都落ち 凱旋帰国してきたときはその年俸を援助してくれたらしいし (裏を返せばそういうのでもないと出してくれなかったと)。 球団は独立採算で行くのが筋だと思うんだけど、 まあベイスターズに限らず無理なんだろうなあ。 あ、カープ?

■_ self

わたしはそれほどうざったいとかは感じないんですけどねえ。 つか、「気持ち悪い」とか「吐き気がする」という表現をするのが理解しがたい…


くだすれPython(超初心者用) その8 
565 デフォルトの名無しさん [sage] 2010/10/10(日) 03:21:13 ID: Be:
    至る所に付いて回るselfが気持ち悪い。。。吐き気がする。。。 

566 デフォルトの名無しさん [sage] 2010/10/10(日) 03:28:57 ID: Be:
    ここはお前の日記帳じゃねーぞ 

567 デフォルトの名無しさん [] 2010/10/10(日) 03:35:53 ID: Be:
    どこにも宣言されていないthisを使ってるのが気持ち悪い...吐き気がする... 

568 デフォルトの名無しさん [sage] 2010/10/10(日) 03:40:24 ID: Be:
    頭が悪いとしか言いようがない 

569 デフォルトの名無しさん [sage] 2010/10/10(日) 03:40:52 ID: Be:
    selfが嫌ならクラス作らなきゃいいじゃない 

573 デフォルトの名無しさん [sage] 2010/10/10(日) 19:01:04 ID: Be:
    >>565 じゃないのですが、selfをあえて宣言させる理由というか経緯みたいなものってどこかで見られないでしょうか?
    Pythonですし、冗長性よりも利点をとっているだろうし必ず理由があると思うので

    OOPをサポートした言語でこのような言語をあまりしらないだけかもしれないですが、
    こういうのって珍しくないのですかね

574 デフォルトの名無しさん [sage] 2010/10/10(日) 19:32:12 ID: Be:
    冗長でも明示するってのが理由じゃなかろうか。いyまあ第六感じゃがの 

576 デフォルトの名無しさん [sage] 2010/10/10(日) 19:50:51 ID: Be:
    属性にアクセスするときに毎回selfを書くのを問題にしているのか、メソッドの宣言時に
    第一引数にselfを書くのを問題にしているのか、どっちだろう?

    前者については、静的言語と違ってあるシンボルが属性かどうかをコンパイル時に決定
    できないので、「このシンボルは属性から探してね♪」というマークを付けないと探索範囲が
    広くて遅くなったり、ローカル変数と名前が被った時に混乱する元になる。
    他のLLでも $this-> だったり @ だったり何かマークを付けてる。

    関数の第一引数にしているのは、Pythonは関数を後からクラスのメソッドとして追加できるから、
    関数のルールと別にメソッドのルールを作るのではなくて、全部関数で統一しちゃっただけ。
    どうせメソッド定義するときに "self, " の6タイプ長くなるだけだから、「言語自体はなるべく
    シンプルに」なるように設計しているPythonとしてはメソッドの為に専用のルールを追加したくなかった。
    「暗黙より明示」っていうPythonのZen(禅)にも一致するしね。 

577 デフォルトの名無しさん [sage] 2010/10/10(日) 19:52:27 ID: Be:
    >>573
    あえて宣言させてるってより、普通の引数だから。
    class Foo:
     def bar(self):
      pass

    a = Foo()
    a.bar()
    で、
    a.bar()っていうのは
    Foo.bar(a)
    と同じ意味を持つ。
    C++とかJavaに慣れてたらとっつきにくいかもしれないけど、
    そういう意味なんだと受け入れたら、あえて宣言させてるとは思わなくなるよ。 

580 デフォルトの名無しさん [sage] 2010/10/10(日) 23:18:55 ID: Be:
    >>573
    ttp://coreblog.org/ats/translation-of-why-explicit-self-has-to-stay 

581 デフォルトの名無しさん [sage] 2010/10/11(月) 02:12:33 ID: Be:
    >>577
    >>573とは別な人ですが。
    うーん。
    やはり、そういう部分だけピックされても、なんでって疑問は払拭されないんですよね。
    なんてのかな?必要性を感じ無いというか?
    なんだろう…
    Cで、なんかトリッキーなコーディングするのが流行った(もちろん、論理的に練られてるんだろうけどさ。)
    流れでなんかしてる感しか無いかな。
    いや、まぁ、素数求めるのに、偶数排除して偶数以外で割るかテストしていくアルゴリズムは、
    知的では無いけど、じゃあ、それ以上のアルゴリズムでコーディングしたからって、どうよ?
    って感じなのよね。
    だって、もう一台パソコン組んで放置してればイイじゃん?って思っちゃうワケ。
    まぁ、スーパーコンピュータの性能が世界一じゃ無いと、ボクも悔しいと思うけどさ。

    なんか、俺つえぇぇぇ!!だけな感じしかしないんだよね。
    答えだけでれば良いんだって事を無視してる感じしかしない。 

582 デフォルトの名無しさん [sage] 2010/10/11(月) 02:21:45 ID: Be:
    お前は何を言っているんだ 

583 デフォルトの名無しさん [sage] 2010/10/11(月) 02:22:13 ID: Be:
    3行でおk 

584 デフォルトの名無しさん [sage] 2010/10/11(月) 02:26:39 ID: Be:
    >>581
    インスタンスへの参照を第一引数に受け取る素朴でわかりやすい仕様なので
    (それだけに外野から野暮とか言われる)
    俺TUEEEとは正反対だ 

588 デフォルトの名無しさん [sage] 2010/10/11(月) 13:00:49 ID: Be:
    C++でも、メンバ関数内での自身のメンバアクセスとかにわざわざthis->をつける
    ってコーディングする人もいるよな。

    つまり、メンバ変数(関数)と別の変数(関数)と、明示的に区別したい、という要請

    そのために、例えばMFCとかでは、メンバ変数にはm_なんてプレフィックスつけるとか、
    UNIX系のC++ではメンバ変数には_をつけるとか、
    そんなコーディングルールのようなものがあったりする。

    で、Pythonの場合は、そんなプレフィックスより、selfを渡して、全部そこからアクセス
    させれば、明示的でいいじゃん、ってなことなんだよ。

    俺はセンスある選択だと思うし、Pythonicだとも思う。 

言語は何であっても、 Ruby の $ みたいにグローバル変数も一目でわかるようにしてほしいな(笑) まあ既存の言語で今からってのはダメだろうけど。

■_ reddit に訊け!

What is the best scripting language to learn? (スクリプティング言語どれがいい?)


What is the best scripting language to learn? - Stack Overflow

I have been learning C and C++ for sometime now. But, they do not allow me to do a lot 
of things like writing a script/program to get a bunch of files from the Internet 
easily. So, I want to learn a scripting language which is fun and which is useful for 
everyday chores. Which one would you recommend, and why?

Other information that might be useful:

   1. References to tutorials / helpful information on how to learn the language.
   2. References to implementations of the language.
   3. Niches where you have found it to be particularly useful.

One language per response, please.
Python

The reason this question is so subjective is that you didn't say much about what kind 
of scripting you want to do. Of course, you did mention downloading and processing 
files from the Internet, so I'll recommend Python.

Another Stack Overflow user asked a specific question about doing webpage scraping and 
asked which language would be best. The first answer outlines all the Python modules 
in the standard library which help accomplish this sort of thing, so you may find that 
helpful: http://stackoverflow.com/questions/86206/http-clients-programing-language

Since you already know C/C++ and thus are new to Python programming, I recommend the 
book Dive Into Python, which is written for people who already know how to program and 
focuses on how Python makes it easy to perform common tasks. The full text of the book 
is available online at http://diveintopython.org/toc/index.html

The "How to Learn Python" Stack Overflow question might also be helpful, 
since it contains links and descriptions of various Python resources: 
http://stackoverflow.com/questions/17988/how-to-learn-python.
JavaScript

JavaScript (technically, ECMAScript or Standard ECMA-262; also known as JScript). With 
the increasing availability of many fully featured server-side/command-line 
implementations, it is becoming a great general purpose scripting language.

Edit: I want to be clear, I don't think this is the best scripting language to learn, 
as there is no best scripting language to learn. This is just one I'd recommend people 
learn if they haven't, because it's so useful.

References:

    * http://javascript.crockford.com/
    * http://dean.edwards.name/
    * http://video.yahoo.com/watch/630959/2974197 (see more in related videos)
    * http://ejohn.org/

Implementations:

    * http://www.aptana.com/jaxer (server side)
    * http://groups.google.com/group/envjs
    * The engines in Webkit (JavaScriptCore and SquirrelFish Extreme), Gecko 
      (SpiderMonkey, TraceMonkey, Rhino) and Chrome (V8) can all run on the command line

Niches: It's not the first place you'd think, but with Jaxer and Env.js/Rhino (see 
links above), JavaScript on the server is becoming more and more viable. And if you 
think about it, it becomes a natural choice as it is the de facto standard client-side 
language.
Ruby

I'd suggest Ruby.
I started learning Python but after trying Ruby, I couldn't go back. Ruby is a happier, 
more elegant and doesn't feel as hacked together as Python (IMHO). The only downside 
is that it runs slower. That should change (for the better) with 1.9.

Perl

If you're familiar with C and Unix, Perl seems like a natural fit. The syntax is 
similar, but you get a lot of other "benefits" such as:

    * Regular expressions
    * Strings of unlimited size
    * Arrays of unlimited size and type
    * Easier file maniplation
    * Hash tables
    * CPAN
    * Flexible syntax
    * and more...

It's debatable whether you'll think features such as automatic type coercion, 
undefined values, and the sometimes-cryptic syntax are beneficial. I'll tell you this, 
however: with Perl, it was not uncommon for me to write a 100+ line program in a 
single sitting and have it work perfectly the first time I ran it. Not having to worry 
about declaring variables, overrunning arrays, and dealing with illegal null values 
allowed me to focus on solving the problem, not getting beat up by the compiler.

A lot is going to depend on what you need your scripting language for. I found Perl 
useful for the one-off programs I needed and for doing system administration tasks 
(chowing through log files, screen-scraping web sites, monitoring system resources, 
etc.)

My gut feeling, though, is that if you haven't had prior experience with Unix 
utilities such as grep, awk, and sed, you may not "get" Perl. In Perl-land, 
problems are best solved with hashes and regular expressions. They are far more 
productive (in terms of programmer time) than trying to shoehorn every data structure 
into arrays.
Powershell

If you use Windows, make it PowerShell.

Good

PowerShell combines a rich, relatively sensible syntax with .NET, COM, and WMI 
integration. It also offers a novel (and very cool) pipeline of objects.

It is both a great scripting languange and a great shell, so your knowledge is useful 
in both contexts. (Compare to CMD which is a fine shell but a crappy script language, 
or CScript/WScript, which are fine scripting languages, but no shell.)

Bad

If you're not on Windows, it's not much use to you.

If you hate Perl syntax, you'll mildly dislike PowerShell's syntax.

http://en.wikipedia.org/wiki/Windows_PowerShell
It depends on the specific program you're writing, which means you have to learn Perl, 
Python, PHP, and Ruby, all of them. Unfortunately, I have no knowledge of Ruby. And, 
JSP is less like a scripting language.

   1. Heavy on HTML, less heavy on DB, heavy on DOM/XML/XPath
      Learn PHP. It has a whole lot of quality third-party libraries.

   2. Heavy on HTML, heavy on DB
      Learn Ruby on Rails. Its MVC framework will make your life happier, I heard. But 
      this choice may limit the type of web servers. Ruby on Rails works like a charm with 
      Apache, lighttpd? I don't know.

   3. Generic pipe(stdin/stdout) scripts, or heavy regular expression
      Perl. You cannot claim yourself as a shell script master without knowing Perl. 
      You can easily install new modules with its CPAN repository.

   4. Massive concurrent network processing
      Python. The powerful network library Twisted runs on top of Python. Python looks 
      beautiful compared to Perl.


Why just one Language?

When I think scripting I think first Unix shell programmming where BASH is the common 
shell progam. Whatever your system is set up with though should be learnt to some 
extent. One can't reccomend BASH for major projects but it is well worth your time to 
at least learn a little.

Man does not live on bread alone so I'd strongly reccomend learning Python. Python is 
very cross platform so that helps a lot. Python is a lot like VIM, you can find it 
anywhere. Pervasive doesn't make it good but it does mean transferable skills.

To a some extent Ruby is in the same ball park as Python but not as mature. JavaScript 
is great but has severe limitations when inside a browserr.

Dave

Lua とか Tcl も挙がってましたがまあこんなところでしょうねえ。

■_

アンドロイドもプログラム言語をいちいち勉強する必要もない!? ってことは、何?... - Yahoo!知恵袋

■_ NELL

NELL (Never Ending Language Learner) て…w


A computer learns the hard way: By reading the Internet

A computer learns the hard way: By reading the InternetAt Carnegie-Mellon university, 
a massive computer system called NELL (Never Ending Language Learner) is 
systematically reading the internet and analyzing sentences for semantic categories 
and facts, teaching itself English and educating itself in human affairs. We spoke to 
NELL's creators.

NELL reads the Web 24 hours a day, seven days a week, learning language like a human 
would — cumulatively, over a long period of time. It parses text on the Internet for 
ontological categories, like "plants," "music" and "sports 
teams," then uses contextual clues to sort out what things belong in which 
categories, like "Nirvana is a grunge band" and "Peyton Manning plays 
for the Indianapolis Colts." And, perhaps most Skynet-horror-inducing, 
"anger is an emotion."

In these estimations, NELL is 87 percent correct. And the more it learns, the more 
accurate it will become. Like the premise of a dystopian sci-fi story, Read the Web is 
both wonderful and terrifying — not unlike the idea of a "Semantic Web," an 
Internet as comprehensible to computers as it is to humans, which has been in the 
computer science and AI discourse for years.

Upon discovering this project, I had tons of questions about NELL: could it read other 
languages? Who gets the data in the end? Does it have parental controls on? To find 
out, we talked to Professor Tom Mitchell, chair of the Machine Learning Department of 
the School of Computer Science at Carnegie Mellon University, and Burr Settles, a 
Carnegie Mellon postdoctoral fellow working on the project.

At the moment, NELL is learning language and semantic categories in English, which 
would mean that its learning is limited to the output of the English-speaking world. 
Are there any plans to expand the program to different languages?

略


Lastly, the name NELL is a joke about the Jodie Foster movie, right?

Professor Tom Mitchell: Well, no. I didn't really know about that movie...but I just 
took a look at NELL's knowledge base, and it appears to know about it. Take a look. 
There, the light grey items are low confidence hypotheses that NELL is considering but 
not yet committing to. The dark black items are higher confidence beliefs. So it is 
considering that NELL might be a movie, a disease, and/or a writer, but it's pretty 
confident that Jodie Foster starred in the movie.

A longer version of this article by Claire Evans originally appeared over at Universe.

The author of this post can be contacted at tips at io9.com


がんばって訳をつけ…たいなあ ○| ̄|_

■_ 本日の巡回から

■_ 読んだ

グラハム・ベル空白の12日間の謎―今明かされる電話誕生の秘話
いや、面白かった。 p49 に二つの図版が載っているのですが、 グレイの特許クレームの三ページ目にある、彼が描いた自身の発明品の略図を見て、 わたしは底に描かれている電流に感電したかのようなショックを受けたのである。 わたしはすぐさま、これとほとんどまったく同じ図をつい先日、 見たばかりだと気づいたのだ-それも、ベルの実験ノートのなかで。 と本文にもあるように、確かに一見してとてもよく似ているものです。 この図版ひとつで判断するのは当然危険なのですが、著者は粘り強く調査をしていきます (大学卒業時のテーマだったとか)。

同じ日に同様の特許を出願するもベルに「先を越されてしまった」 イライシャ・グレイ (エリシャ・グレイ) は「栄光なき天才たち」の第一話でも 取り上げられていたのでその名前は知っていました。 その出願の数時間の差で、というエピソードが実はニュートンとりんごのエピソード並みに 虚飾と脚色にまみれたものであるということにも触れられています。

グレイの特許は、1876年2月14日出願(ベルも同日)で、同年3月3日認可、3月7日に公開されています。 ベルは二月中旬からワシントンの特許局へ行っていて、 三月に戻って実験を再開したときそれまでにはまったく検討していなかったものを使っていたり、 特許出願に際しても具体的なサンプルの提出が要求されていなかったりと疑わしい点がいくつもあるのです。

果たして何があったのか。それはご自分の目でお確かめください :)

■_


一つ前へ 2010年10月(上旬)
一つ後へ 2010年10月(下旬)

ホームへ


Copyright (C) 2010 KIMURA Koichi (木村浩一)
リンクはご自由にどうぞ。

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