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

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

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

ホームへ

2010年11月20日

■_

関数脳本~~~~~っ

■_ option base 1


for文の初期化の値や配列の最初の番号が1からではなく (大抵)0からだと 毎回 データの個数で混乱してしまいます - livedoor ナレッジ 知識、知恵のカタマリ

for文の初期化の値や配列の最初の番号が1からではなく (大抵)0からだと 毎回 データの個数で混乱してしまいます
まだ慣れないでいます。
なれるしかないのでしょうか・・・

それに 結果的に個数を合わせるために条件式内で< や >を使うことになるので
頭の中で遠回りしている感があってめんどくさい


<= >=を使った方が混乱しないで済むのですが…

なんで配列変数は番号が0から始まる仕様なのでしょうか


まあよくある疑問ですね。

歴史の旧いFORTRAN系では"1起算"です。
これは、コンパイラを設計した当時の背景で、数学に縁の薄い人にも使いやすいようにとの配慮でした。
現代では"0起算"の方が断然便利で、"麦麦club"さんがそこのところに
気づいておられないだけのことと思います。

FORTRANコンパイラを設計した当時の翻訳の仕方は、初期値から
わざわざ"1"を差し引いて"0起算"に調整していました。
コンパイラのひとつ下の水準であるアセンブラ系では、ずっと以前から
プログラマが"0起算"で処理してきました。"1起算"は考えられなかったのです。
中央処理装置の内部では、コンピュータが誕生した時点から"0起算"が普通なのです。

  
ありがとうございました。暗黙的に期待した内容の知識も得ることが出来ました。
コメ欄の 覚えるコツ もありがとうございます。

数学に縁の薄い人にも使いやすいようにとの配慮でした って本当なんでしょうか?

■_


The Code Dump » Say No to Null Checks

Say No to Null Checks

Hey, do you check your methods' arguments to make sure they're not null?
そこのアナタ、自分のメソッドに対する引数がnullでないことを保証するための
チェックをしていますか?

Today, I got into a little discussion with a teammate about testing contracts of 
methods: should we check for null in every public method?

今日わたしは、あるひとりのチームメイトと
メソッドのテスト契約 (testing contracts) についてちょっとした議論をしました。
それはこういうものです:
わたしたちはすべての public メソッドにおいて null チェックをすべきなのか?

I was against it, and he was for it.

わたしはそれに反対したのですが、彼はチェックすべきと主張しました。

The simple reasons to do it are, first, that it makes your code more defensive. You 
fail explicitly instead of failing implicitly when the code tries to dereference the 
null object. Another argument was that given 20 callers of an interface, it's easier 
to test in the interface for the precondition than to test each and every one of the 
callers. And, of course, that it is better API implementation, and that even if a 
class isn't part of one's public API now it might very well become part of it in the 
future, so why not add the tests now?

チェックすべきだという単純な理由は、第一に
チェックすることがコードをより防衛的 (defensive) にするというものです。


I'll tackle these all. First, I have to agree that some null checks are required, at 
the boundaries of your system. I believe a system should have a paranoid barrier, 
before it everything is as suspect as someone going on a bus with a heavy coat on a 
hot day – that's just waiting to blow. Once you've passed the barrier you know things 
are secure and no longer need to be paranoid.

わたしがこれらすべてに tackle してみましょう。まず、
システムの境界 (boundaries of your system) においては
なんらかの null チェックが必須であることはわたしも認めざるを得ません。
わたしはシステムというものは、
誰かが暑い日に重いコートを着てバスに乗り込もうとするかのようなことになってしまう前に
paranoid barrier (偏執狂的障壁?) を持っているべきであると確信しています。
#よくわからん
that's just waiting to blow.
一度その障壁をパスすれば、その対象が安全でありもはや偏執狂的になる必要は
ないとわかるでしょう。

So yes, some null checks are of course required.

ですから、一部の null チェックは当然必要なものなのです。

But, because we want our API to be user-friendly and error-proof does that mean we 
need to make every public method in our code paranoid just in case it will become part 
of the public API at some point? 5 letters: YAGNI! :)

けれども、わたしたちは自分たちの API がユーザーフレンドリーで error-proof であることを
要望していて、それはわたしたちが自分たちのすべての公開メソッドを
それがどこかで公開APIの一部になるであろうケースを病的なまでに考慮せねばならない
ことを意味するのでしょうか?
#ぐだぐだ
それに対する回答は五文字で表されます。「YAGNI」です。
#YAGNI → ぐぐれ。You Are Gonna Need It

The interesting part is the testing of the callers. I agree, if we have to write the 
test 20 times for each caller, it will get tedious. But we don't write the same thing 
twice, do we? As good old J.B Rainsberger teaches, what we actually need are 
collaboration tests. Each of the callers collaborate with the interface. And so, we 
create a collaboration test that makes sure the user is using the interface according 
to the contract. These are usually abstract tests that require us to create 
derivatives that implement a factory method for creating the calling class. This way 
we write the tests only once and make explicit the interface and contract, even in 
dynamic language.

興味深いのは呼び出し側のテストです。
すべての呼び出し元に対して20回テストを書かなければならないのであれば
それは tedious (退屈、飽き飽きする) なことになるだろうということに私は賛成します。
しかしわたしたちは同じことを二度は書きません。そうでしょう?
good old な J.B. Rainsberger が教えているように、
わたしたちが本当に必要としているものは collaboration tests なのです。
呼び出しもとのそれぞれはインターフェースと collaborate します。
同様に、ユーザーが契約に従ったインタフェースを使っていることを確実にする
collaboration test を作成します。
これらは通常、呼び出しクラスを生成するためのファクトリーメソッドの実装を
という derivatives の作成をわたしたちに要求する abstract tests です
このやり方ではわたしたちはテストをただ一度だけ記述して、
動的言語の場合であってもインターフェースと契約とを明確にするのです


In general, this is a powerful solution, that solves a basic problem with defensive 
programming. Say we do test for nullity wherever possible, what do we do then? Our 
system is likely to crash or throw an exception any way, since what is the interface 
to do? Obviously something is wrong if we were called in a way that doesn't match the 
contract, so is the hassle worth it? I think testing for nullity everywhere is a thing 
of the past, especially once you adopt dynamic programming and get used to the fact 
that most of the times you can't even be sure the object you've got will answer the 
methods you're about to use, so what difference does a null check make?

一般的には、これは防衛プログラミングについての基本的な問題 (basic problem) を解決する
強力な solution です。さて、わたしたちは可能性があるところすべてで nullity に対するテストを行います。
それからわたしたちがすることは?
わたしたちのシステムはインターフェースがそうするようになっているので、
クラッシュしたり何らかの方法で例外を送出しますか?
もし契約に従っていないやり方でもって呼び出されたのなら、
それは明らかに何かが間違っています。
so is the hassle worth it?
わたしはすべての場所 (everywhere) で nullity をテストすることは
過去のもの (thing of the past) であって、


So let's write some awesome collaboration tests tests and get cracking!

だから、テストと get cracking する awesome な collabpration tests を書きましょう!


■_ C++ vs Lisp?


Lisp Scheme Part31 [chaika]
383 デフォルトの名無しさん [sage] 2010/11/16(火) 15:41:28 ID: Be:
    yaccとpython組み合わせればlispが出来ることの大部分ができる 

384 デフォルトの名無しさん [sage] 2010/11/16(火) 23:02:36 ID: Be:
    蛇に騙されて楽園から追放されたらどうするんだ?

385 デフォルトの名無しさん [sage] 2010/11/17(水) 13:28:04 ID: Be:
    マクロ =俺言語からyaccで変換 

386 デフォルトの名無しさん [sage] 2010/11/19(金) 18:20:45 ID: Be:
    Lisperからみたc++の立ち位置ってどんななんだろ?
    Cで十分なのに無意味にlambdaとかいろいろ作ってる様にみえるんだろうか 

387 デフォルトの名無しさん [sage] 2010/11/19(金) 20:01:28 ID: Be:
    それなりに理由があって作られたものの是非は
    かなり後になってからでないとわからんもんだ 

388 デフォルトの名無しさん [sage] 2010/11/19(金) 22:24:20 ID: Be:
    グリーンスパンの第10法則 

389 デフォルトの名無しさん [sage] 2010/11/19(金) 23:38:10 ID: Be:
    >>386
    ABIの魔窟とか、お前FFIで使い辛いんだよとか、規格が尖り過ぎとか、
    規格の大きさで唯一Common Lispと戦える存在とか、Boostの立ち位置が凄いとか、
    気付いたらオブジェクト指向からジェネリック指向になっていたでござるとか、
    色々愉快な言語だよね。自分では使わないけど、傍から見てると面白い言語。
    CLerとしては性能面でのライバルだし、Schemerとしては完全に別世界の存在。

    無理矢理lambdaとかはむしろ感動した。あそこで新しい言語作らないのが逆に凄い。 

390 デフォルトの名無しさん [sage] 2010/11/20(土) 09:13:20 ID: Be:
    出自がcfrontだけに、なんでもかんでも見えるコードに落とそうとするからなあ。
    ランタイムの言語による支援を前提にすればいいのに。 

391 デフォルトの名無しさん [sage] 2010/11/20(土) 10:49:42 ID: Be:
    >>386
    自由にシンタックスを作れない不自由な言語
    覚えなきゃいけない記述っ方法が山ほどあって近寄りたくない言語
    # だけど, たまにくるんだよな. C++ の仕事 orz

392 デフォルトの名無しさん [sage] 2010/11/20(土) 21:08:16 ID: Be:
    LAND OF LISP受領。
    ハァハァ 

誰か Land of Lisp の書評(or 感想)よろしく~

■_ 本日の巡回から

■_

11/27→12/4→12/11→12/18と土曜日が連続で埋まった。

2010年11月19日

■_

・PowerShell
[今週の技術解説] 【使わなくっちゃもったいない!】 改めて Windows PowerShell 入門 - IT プロフェッショナルのみなさまへ - Site Home - TechNet Blogs 会社でも不自由なく使えるようになってきたっぽいのでちょっと気合入れてやってみるかと 思ってはみたものの、出ている本は微妙に古かったり(バージョンがどうとかは知らない)で ほいほい買っていいものやら。

・VBA
MOONGIFT : 便利なExcel VBA用マクロ「Surviveplus.net Excel Macro」 オープンソース・ソフトウェア/フリーウェアを毎日紹介 VBA でごにょごにょやっててなにがつらいって、VBEがしっくりこないということだったり。 それでもでっかいディスプレイがあればそれなりに見通しが良くなるのかなあ。

・温故知新
でもないか。 「実録! 天才プログラマー」という古い本(1980年代半ばの出版)を読んでいたら 面白いフォーマットのCプログラムを発見。 C・ウェイン・ラトリフ( dBASE作者) のコードなんですが。

p 139
/*
strdcpy - copy string until a specified character is found (or entire string copied)

return a pointer to 'chr' in from string (or terminator)
*/
char	*strdcpy(from, to, chr)
char	*from;
char	*to;
char	chr;
{
    char   c;

    while (c = *to = *from) {
       if (c == chra) {
           *to = '\0';
           retrun (from);
           }
       to++;
       from++;
       }
    return (from);
    }
/*=======================================*/
/*

strtrim - trim off blank characters (and CR, LF) from right side of line

*/

strtrim(line)
char  *line;
{
    int     i;
    char    *p;

    i = strlen(len);
    p = line + i - 1;   /* RHE of line  */
    while (i--) {
       if (*p == ' ' || *p == '\t' || *p == '\n' || *p == '\r')
           *p = '\0';
       else
           break;
       }
    return;
    }

この綴じブレースの位置は…

この本で取り上げられている人物は以下の通り。

チャールズ・シモニイ Multiplanの開発
バトラー・ランプソン Alto PCの開発
ジョン・ワーノック PostScriptの開発
ゲァリー・キルドール CP/Mの開発
ビル・ゲイツ BASICの開発
ジョン・ペイジ PFS-FILEの開発
C・ウェイン・ラトリフ dBASEⅡの開発
ダン・ブリックリン VisiCalcのデザイン
ボブ・フランクストン VisiCalcの開発
ジョナサン・サックス ロータス1-2-3の開発
レイ・オッジイ Symphonyの開発
ピーター・ロイゼン T/Makerの開発
ボブ・カー Frameworkの開発
ジェフ・ラスキン マッキントッシュ生みの親
アンディ・ハーツフェルド マッキントッシュOSの開発
岩谷 徹 パックマンの開発
スコット・キム Inversions for the Macintoshの開発
ジャロン・ラニアー Moon Dustの開発
マイケル・ハーレイ SoundDroid用ソフトウェアの開発

で、この本原題が「Programmers at Work」っていうんですね。 at Work といえば
Coders at Work
これの翻訳版まだーっ!?

■_

■_ ネタ

そのいち


バグにカッコ良い名前つけるスレ 
1 仕様書無しさん [] 2010/11/10(水) 20:00:09 ID: Be:
    虚無に消えた変数A
    →ヌルポ 

2 仕様書無しさん [] 2010/11/10(水) 20:50:20 ID: Be:
    LOOP終了判定変数のインクリメント忘れ
    →定番
    (わらくしのばやい)

3 仕様書無しさん [sage] 2010/11/10(水) 22:46:14 ID: Be:
    限界の彼方へ
    →配列添字のはみ出し 

4 仕様書無しさん [sage] 2010/11/10(水) 22:48:25 ID: Be:
    深淵を覗きし者
    →再起呼び出しの終了条件がおかしい 

5 仕様書無しさん [sage] 2010/11/10(水) 22:52:47 ID: Be:
    あとお約束で

       ( ・∀・)   | | ガッ
      と    )    | |
        Y /ノ    人
         / )    <  >__Λ∩
       _/し' //. V`Д´)/ ←>1
      (_フ彡        / 

6 仕様書無しさん [sage] 2010/11/11(木) 00:47:11 ID: Be:
    異次元からの来訪者
    変数の初期化漏れ

7 仕様書無しさん [sage] 2010/11/11(木) 01:00:31 ID: Be:
    さすらいの放浪者
    →メモリリーク

8 仕様書無しさん [sage] 2010/11/11(木) 01:17:27 ID: Be:
    >7
    馬から落馬…

    彼方への疾走
    →無限ループ 

9 仕様書無しさん [sage] 2010/11/11(木) 01:28:21 ID: Be:
    宛先不明のラブレター
    →例外処理漏れ 

10 仕様書無しさん [sage] 2010/11/11(木) 01:32:46 ID: Be:
    死神の接吻
    →セグメンテーションフォールト 

11 仕様書無しさん [sage] 2010/11/11(木) 01:41:35 ID: Be:
    道化師の宴
    →単純な計算ミス 

12 仕様書無しさん [] 2010/11/11(木) 01:41:57 ID: Be:
    ノービス・ミス・テイカーB(ブラッド)
    →構文エラー 

13 仕様書無しさん [sage] 2010/11/11(木) 01:45:22 ID: Be:
    知らされなかった真実
    →リソースがスコープを抜けた、あるいはdeleteされたなどの理由で無効になっているのに
     その通知を受け取っていない関数、モジュールが存在すること 

14 仕様書無しさん [sage] 2010/11/11(木) 01:45:44 ID: Be:
    介護士の反乱
    →ケアレスミス 

15 仕様書無しさん [sage] 2010/11/11(木) 01:48:26 ID: Be:
    部屋とワイシャツとタワシ
    →意図的としか思えないバグ

16 仕様書無しさん [sage] 2010/11/11(木) 17:15:09 ID: Be:
    色即是空
    →ヌルポ 

17 仕様書無しさん [sage] 2010/11/11(木) 21:40:17 ID: Be:
    へんじがない ただのしかばねのようだ
    →タイムアウト 

18 仕様書無しさん [sage] 2010/11/12(金) 21:15:25 ID: Be:
    無力化
    →ヌルポ 

19 仕様書無しさん [sage] 2010/11/12(金) 21:42:06 ID: Be:
    バーニング・ダウン・ザ・ハウス
    →ぬるぽ

    アクトン・ベイビー
    →メモリリーク

    ゴールド・エクスペリエンス・レクイエム
    →無限ループ

    20th Century BOY
    →デッドロック

    ダイバー・ダウン
    →潜在不具合 

20 仕様書無しさん [sage] 2010/11/13(土) 14:19:16 ID: Be:
    心の目で見ろ
    →404 NOT FOUND 

21 仕様書無しさん [sage] 2010/11/15(月) 17:09:02 ID: Be:
    奇門遁甲八陣
    →不具合解析すら拒絶するトリッキーな設計 

■_

そのに


諸君 私はJavaが嫌いだ 
1 ◆r5n0jpZSDw [] 2010/11/11(木) 18:11:11 ID: Be:
    諸君 私はJavaが嫌いだ
    諸君 私はJavaが大嫌いだ

2 ◆r5n0jpZSDw [] 2010/11/11(木) 18:13:21 ID: Be:
    Sunが嫌いだ
    JDKが嫌いだ
    JREが嫌いだ
    J2EEが嫌いだ
    Beansが嫌いだ
    Servletが嫌いだ
    JSPが嫌いだ
    J2MEが嫌いだ
    JavaDocが嫌いだ

    サーバで Webで
    携帯で 組み込みで
    Linuxで Windowsで
    少人数で 多人数で
    オフショアで 下請けで

    プログラミングで使われるありとあらゆるJavaが大嫌いだ

3 ◆r5n0jpZSDw [] 2010/11/11(木) 18:14:17 ID: Be:
    成果物をならべたTomcatの連結テストが轟音と共にサーバを吹き飛ばすのが嫌いだ
    空中高く放り捨てられた仕様書が政治力でばらばらになった時など心が沈む

    担当者の操るIBMのWebSphereがjava.lang.ClassFormatErrorを連発するのが嫌いだ
    悲鳴を上げて燃えさかるプロジェクトから飛び出してきた派遣プログラマを管理職が殴り倒した時など胸が疼くような気持ちだった

    仕様変更をそろえた自社の営業が納期の見積もりを蹂躙するのが嫌いだ
    恐慌状態の新入社員がバグだらけのクラスファイルを何度も何度も確認している様など吐き気すら覚える

    悲観主義の退職者達をJava雑談スレッドに吊るし上げていく様などはもうたまらない
    泣き叫ぶエンジニア達がEclipseの投げ出したヒープ不足例外とともに画面に収まらないスタックトレースをひとつひとつダンプするのも最低だ

    哀れな下請け達が雑多な実装で健気にも組み上げてきたコードをユニットテストのプログレスバーがクラスまるごと真っ赤に表示した時など失神すら覚える

    オフショアの下請けにインターフェースを滅茶苦茶にされるのが嫌いだ
    必死に守るはずだったコード規約が蹂躙されコメントが削られ壊されていく様はとてもとても悲しいものだ

    中国の価格に押し潰されて残業させられるのが嫌いだ
    客の要望に追いまわされ害虫の様に社内調整に這い回るのは屈辱の極みだ

4 ◆r5n0jpZSDw [] 2010/11/11(木) 18:15:01 ID: Be:
    諸君 私はJavaを地獄の様なJavaを嫌っている
    諸君 ここまで読んだ暇なプログラマ諸君
    君達は一体何を望んでいる?

    更なる地獄を望むか?
    情け容赦のない糞の様な仕事を望むか?
    鉄風雷火の限りを尽くし三千世界の鴉を殺す嵐の様な言語を望むか?

5 ◆r5n0jpZSDw [] 2010/11/11(木) 18:15:44 ID: Be:





    『Java! Java! Java!』





    . 

6 ◆r5n0jpZSDw [] 2010/11/11(木) 18:16:27 ID: Be:

    よろしい ならばJavaだ

    我々は渾身の力をこめて今まさに振り降ろさんとする握り拳だ
    だがこの暗い闇の底で底辺の土方作業に堪え続けてきた我々にただのJavaではもはや足りない!!

    大規模案件を!!
    一心不乱の大規模案件を!!

    我らはわずか一個人 人月60万に満たぬエンジニアに過ぎない
    だが諸君は残業150時間の徹夜組だと私は信仰している
    ならば我らは諸君と私で総力100万人月の下請け集団となる

7 ◆r5n0jpZSDw [] 2010/11/11(木) 18:18:09 ID: Be:
    我々を火のついたプロジェクトへと追いやり眠りこけている連中を叩き起こそう
    髪の毛をつかんで引きずり降ろしJavaをデプロイさせ思い出させよう
    連中に設定ファイルの不整合を思い出させてやる
    連中に徹夜時のキータッチの音を思い出させてやる

    管理職と現場のはざまには奴らの想定では思いもよらない仕様バグがあることを思い出させてやる
    一千人のエンジニアのコミュニケーション不足で
    案件を燃やし尽くしてやる

8 ◆r5n0jpZSDw [] 2010/11/11(木) 18:18:57 ID: Be:





    「最後の正気を保ったプログラマより全エンジニアへ」
    目標リリース前日サーバダウン!!

    第一世代ゲートウェイ(GRIMM)作戦 状況を開始せよ





    . 

9 仕様書無しさん [sage] 2010/11/11(木) 18:29:01 ID: Be:
    長ぇコピペだなぁ 

10 仕様書無しさん [sage] 2010/11/11(木) 18:31:25 ID: Be:
    色々と心がえぐられるなw 

13 仕様書無しさん [] 2010/11/11(木) 20:41:32 ID: Be:
    私はJavaが嫌いです
    Javaは幼稚で礼儀知らずで気分屋で
    前向きな姿勢と 無いものねだり 心変わりと 出来心で生きている
    甘やかすとつけあがり 放ったらかすと悪のりする
    オジンだ 入れ歯だ カツラだと はっきり口に出して人をはやしたてる無神経さ
    私ははっきりいっで絶壁です
    努力のそぶりも見せない 忍耐のかけらもない 人生の深みも 渋みも 何にも持っていない
    そのくせ 下から見上げるようなあの態度
    火事の時は足でまとい 離婚の時は悩みの種 いつも一家の問題児
    そんなお荷物みたいな そんな宅急便みたいな そんなJava達が嫌いだ
    私は思うのです この世の中からJavaがひとりもいなくなってくれたらと
    C++だけの世の中ならどんなによいことでしょう
    私はJavaに生まれないでよかったと胸をなで下ろしています
    私はJavaが嫌いだ ウン Javaが世の中のために何かしてくれたことがあるでしょうか
    いいえ Javaは常に私達C++の足を引っぱるだけです
    身勝手で 足が臭い
    ハンバーグ エビフライ カニしゅまい コーラ 赤いウインナー カレーライス スパゲティナポリタン
    好きなものしか食べたがらない 嫌いな物にはフタをする
    泣けばすむと思っている所がズルイ 何でも食うJavaも嫌いだ
    スクスクと背ばかり高くなり  定職もなくブラブラしやがって
    逃げ足が速く いつも強いものにつく あの世間体を気にする目がいやだ
    あの計算高い物欲しそうな目がいやだ 目が不愉快だ
    何が天真爛漫だ 何が無邪気だ 何が星目がちな つぶらな瞳だ
    そんなJavaのために 私達C++は 何もする必要はありませんよ
    第一私達C++がそうやったところで ひとりでもお礼を言うJavaがいますか
    これだけJavaがいながらひとりとして 感謝するJavaなんていないでしょう
    だったらいいじゃないですか それならそれで けっこうだ
    ありがとう ネ 私達C++だけで 刹那的に生きましょう ネ
    Javaはきらいだ Javaは大嫌いだ 離せ 俺はC++だぞ
    誰が何といおうと私はJavaが嫌いだ 私は本当にJavaが嫌いだ

■_

メタなネタが

2010年11月18日

■_

まだまじめにやってないんですが>すから

■_ The power of Lists in Scala

The power of Lists in Scala « All-Code-Edges: Java, Scala and Design Patterns
(略)

Let me introduce you the piece of code possibly most used in history:

    for(int i = 0; i < list1.length() ; i++){
        //do something
    }


Since java 1.5 we have a more concise way to do the same, the foreach iteration:
Java 1.5 からは、同じことをより簡単なやり方で行えるようになっています
  
    for(Object o : list1){
        //do something
    }

If we want to create a list with all elements of list1 that fulfill some condition, we 
need some boilerplate code:
なんらかの条件を満足する list1 のすべての要素からなるリストを作成したいのなら
ちょっとしたboilerplate codeが必要です:

    List list2 = new ArrayList();
    for(Integer i : list1){
        if(i > 0){
            list2.add(i);
        }
    }

Every time we want to find elements that fulfill some condition, we need to copy this 
code except for the third line, which has to be adapted.

ある条件を満たす要素を見つけ出そうとする度に、
条件に応じて変更しなければならない三行目を除いてこのコードをコピーする必要があります。


One of the main goals of Scala is to reduce the boilerplate code that exists in our 
Java code. To accomplish this goal, there are some higher-order operators, which can 
take a function as a parameter. Some useful higher-order operators will be described 
in this post.

Scala の main goals の一つは既存のJavaコードに存在している bilerplate code を減らす (reduce)
ことです。この goal を満足させるために、
パラメータとして関数を受け取る高階演算子 (higher-order operators) がいくつか存在します
このポストでいくつかの高階演算子を説明します。


Filter

The filter operator takes as operands a list of type List[T] and one function of type 
T => Boolean called predicate. This operator returns a new list with all elements of 
the original list for which the predicate is true. With this operator we can, in only 
one line, do the same that the Java code.

filter 演算子はオペランドとして List[T] 型のリストを一つと述語 (predicate) と呼ばれる
T => Boolean 型の関数を一つ取ります。
この演算子は元のリストの中で述語がtrueとなる要素すべてを含む新しいリストを返します。
この演算子を使えば等価なJavaコードが行うことを一行にしてしまえます。


    scala> val list1 = List(1,3,4,0,-1,6)
    list1: List[Int] = List(1, 3, 4, 0, -1, 6)
    scala> val list2 = list1 filter (_ > 0)
    res0: List[Int] = List(1, 3, 4, 6)

The list created will contain only the elements of list1 that are greater than 0.
生成されたリストは list1 にありかつ 0 よりも大きい要素のみで構成されます。

Find

This operator is very similar to filter, except that returns the first element for 
which the predicate is true. Actually it returns an optional value; this is the Scala 
approach for nullable objects. If at least one element makes predicate true, it will 
return Some(T), otherwise None. This approach ensures in compilation time that no 
optional values are considered as common variables of type T.

この演算子は filter によく似ていますが、述語が true となる最初の要素を返す点が異なりま
す。実際にはこの演算子は optinal value を返します。これは nullable objects に対する
Scala のアプローチです。もし一つでも述語がtrueを返す要素があるのなら Some(T) を返しま
すが一つもなければ None を返します。このアプローチはコンパイル時に optinal value が型 T
のcommon variables として扱われるような値ではないことを保証します。


    scala> list1 find (_ > 0)
    res1: Option[Int] = Some(1)
    scala> list1 find (_ > 100)
    res2: Option[Int] = None

Partition

The partition operator returns a pair of lists. The first one includes all elements 
that satisfies the predicate. The second includes all elements for which the predicate 
is false.

partition 演算子はリストのペアを返します。そのペアの最初のリストは述語 (predicate) を
満足するすべての要素を含むもので、二番目のリストはその述語を満足しないすべての要素を含
むものです。

    scala> list1 partition (_ &t; 0)
    res3: (List[Int], List[Int]) = (List(1, 3, 4, 6),List(0, -1))

TakeWhile

The takeWhile operator iterates the original list until it finds one element that 
doesn't satisfy the predicate, all this elements are added in the result list. In 
other words, it returns the longest prefix such that every element satisfies the 
predicate.

takeWhile 演算子は、述語 (predicate) を満足しない要素が見つかるまでオリジナルの
リストをイテレートします。それまでの要素はすべて結果リストに追加されます。
言い換えれば、この演算子は述語を満足する要素からなる最長の接頭辞 (prefix)
を返します。


    scala> list1 takeWhile (_ > 0)
    res4: List[Int] = List(1, 3, 4)

DropWhile

The dropWhile operator iterates the original list until it finds one element that 
doesn't satisfy the predicate, the remaining elements are added in the result list. 
In other words, it drops the longest prefix such that every element satisfies the 
predicate.

dropWhile 演算子は述語を満足しない要素が見つかるまでオリジナルのリストをイテレートし、
リストの残りを結果リストに追加します。言い換えると、この演算子は述語を述語を満足する
要素からなる最長の接頭辞を取り除きます。

    scala> list1 dropWhile (_ > 0)
    res5: List[Int] = List(0, -1, 6)

These are few operations that can help us in our everyday coding. The less lines we 
code, the less chances of introducing errors we have. In addition, we can avoid 
repeating the most repetitive and error-prone code.

へー。こんなのもあったのね。

■_


Wade Arnold » Scala is easier than PHP

Scala is easier than PHP
Scala は PHP よりも易しい

November 17th, 2010


OK, that was a bit of link bating. However for the types of problems that I am 
currently working on it really is!  I have been asked a couple hundred times in the 
last 8 months why I tweet about Scala and Hbase all the time. The larger post is 
coming but I figured I could answer the technical scala question first. In order to 
stop the comment flames let's start by saying that I know PHP better than most human 
beings. It is something that I have been coding in since PHP 3 and have really enjoyed 
the language the entire time. I still believe that PHP is the best language for the 
web for the majority of programmers; it quite possibly has the best documentation and 
examples of any language like a DSL for the web! I am still slinging PHP and so is my 
company. I have been a speaker at lots of php conferences, aided in php's documentation,
enjoyed the community, and for the past three years have been Zend Framework committer.
That's all to say that there are lots of other PHP developers that are smarter than me;
but I probably have met them.

以下略

Special thanks to the following scala studs for getting me past the grind. I really 
appreaciate the community support so far! Follow these guys on twitter and read their 
blogs. They are leaders in the scala community but have still taken the time to answer 
my neive questions! Almost everything I know has come from their books or blog posts.

    * Daniel Spiewak
    * Jonas Boner
    * Debasish “The almighty” Ghosh
    * Timothy Perrett
    * Victor Klang
    * Alex Payne
    * Dean Wampler
    * David Pollak

So is scala hard? Sure, but I personally recommend never bringing a knife to a gun 
fight. Especially when the competition has Uzi's!

結局のところ、Scala は難しいのでしょうか?
もちろんそうです。しかし、わたしは銃撃戦 (gun fight) にナイフで参加するようなことは
決してお薦めしません。ことに相手がウージーのサブマシンガンを持っているのであれば!


■_

きょうのまるなげ


プログラミングの作成の仕方がよくわかりません。下の問題2問解ける方がいました... - Yahoo!知恵袋
プログラミングの作成の仕方がよくわかりません。下の問題2問解ける方がいました...

プログラミングの作成の仕方がよくわかりません。下の問題2問解ける方がいましたら至急解答
を教えてください。お手数ですがよろしくお願いします。


Ⅰ.Write a VB application to translate 6 digit number to it t

ext reading. You may start with the given sample code.
e.g. 654321: six hundred and fifty four thousand three hundred and twenty one

Steps:
1. create a function one Str(x), 3marks
2. create a function tenStr(x), 3marks
3. 3 digit reading (optional)
4. expand to 6 digit reading ,4marks
5. Handing exceptions in the text (e.g. no 'zero' terms at the start or in the middle),5marks


Ⅱ. Write a VB application to translate 8digitt number to it text reading (for the 
Japanese Counting System).(8marks)

e.g. 654321: 六十五万四千三百二十一 or any other text format is accepted.

補足
    この英文はある程度わかっているつもりですが
    Cのプログラムに関してはさっぱりわかりません。
    なので、この2つの問題の解答を教えていただけると非常にありがたいです。
    よろしくお願いします。


問題文に VB ってあるんですけど…

■_


「プログラミング」の「本質」? | OKWave

こんにちは。
僕は今C言語を独学してる大学生ですがプログラミングに関してわからないことがあります。

まず、プログラミングの入門書には主にその言語の文法の解説だけしか載ってませんよね。
しかし実用的なソフトウェアを作るには文法以外にも大事な概念とか機能がありますよね?(実装とか組み込みとかライブラリとかフレームワークとかAPIとか.NETとかexeとか)
入門書はその部分を曖昧にしてると思うんですよね。
例えば「APIはOSとアプリケーションを繋ぐ窓口」とかいう感じで。
僕は「API」がどういう仕組みでどういう役割を持ち具体的にどう使えばいいのかを知りたいわけなんですよ。
この詳しい解説はいったいどんな本に載ってるんでしょうか?

次にソフトウェアって、僕の考え方が正しいかわかりませんが、他の色んな部分に繋がっていますよね。
例えばブラウザは「ネットワーク」に、OSは「ハードウェア」に。
その「連結部分」がいったいどういう仕組みで何が支配してるんでしょうか?
もちろんネットワークもハードウェアも仕組みが違うことはわかりますが、「Hello,World!」と表示する道具をどう弄れば「連結部分」となり得るのでしょうか?


以上の二つが僕が疑問に思ったことです。
文才が無くてすみません。
僕自身何がわからないのかわからないので。

つまり、作りたいモノがあっても「プログラミング」という一つのカテゴリーが大きすぎてどう
やればいいかわからないということです。

ちなみに僕は人工生命のシミュレーションソフトを作ってみたいんですが、Linuxとかを弄って
みたいなと思っています。

誰かこの疑問に答えてくれませんか。
こいつのせいでプログラミングをやる意味が見出せずプログラミングに対して恐怖すら覚えるようになってきました。
助けてください。
お願いします。

■_

2010年11月17日

■_

○| ̄|_

■_


スレ立てるまでもない質問はここで 108匹目 
424 デフォルトの名無しさん [] 2010/11/16(火) 20:44:58 ID: Be:
    for文などのカウンタ変数にiとかjとか使うのは一昔前の書き方だって
    どっかの本で読んだんですが、その本の名前が思い出せない。
    確かC++関連の有名な外国の著書(の日本語和訳)だったと思うんですが、
    思い出せる方いらっしゃいますか?Generic関係の本だったような気がします。

    なぜiとかjとかが駄目なのか、についても教えてもらえると嬉しいです。
    (個人的にはi、jというのはカウンタであることが自明なので良いと思ってますが) 

425 デフォルトの名無しさん [sage] 2010/11/16(火) 20:49:14 ID: Be:
    そもそもフォートランが 

426 デフォルトの名無しさん [] 2010/11/16(火) 20:55:04 ID: Be:
    いや、そういうのではなく、
    iとかjとか意味のない変数名を使うべきでない、という主張でした。
    呼んだ当時はふむふむなるほど、と思っていたのですが
    最近は「長いと可読性を損ねるデメリットの方が大きいんじゃないか」と
    思うようになってきました。 

427 デフォルトの名無しさん [sage] 2010/11/16(火) 20:59:15 ID: Be:
    >>426
    意味はあるだろ、そもそもFortranが(ry

    その本の主張は正しい
    が、君が最近思ってることも正しい 

428 デフォルトの名無しさん [sage] 2010/11/16(火) 21:01:43 ID: Be:
    ijkは意味があるから いいじゃん。 

429 デフォルトの名無しさん [sage] 2010/11/16(火) 21:15:56 ID: Be:
    一般的な慣例句としてijkが定着している場合、ijk使用によるリストの見やすさ、
    意味が一瞬で伝わることの良さが大きくなる。
    本も正しいが、俺はijkを進める。まあ、jはパスする場合が大きくなったけどね。
    iklmnを使用している。 

430 デフォルトの名無しさん [sage] 2010/11/16(火) 21:29:03 ID: Be:
    >>429
    j飛ばすならlも飛ばせばいいのに。

    この前派遣さんの書いていたコード
    for(double i = 0; i += 0.1; i < 1) {...}
    短いコードにずいぶん突っ込みどころを詰め込めるもんだと感心した 

431 デフォルトの名無しさん [sage] 2010/11/16(火) 21:35:57 ID: Be:
    愛は外せない 

432 デフォルトの名無しさん [sage] 2010/11/16(火) 21:57:49 ID: Be:
    なのに童貞 

433 デフォルトの名無しさん [sage] 2010/11/16(火) 22:52:57 ID: Be:
    j飛ばすなよ。老人かよ。 

434 デフォルトの名無しさん [sage] 2010/11/16(火) 23:10:05 ID: Be:
    社内のコーディング規約で
    iとjは誤認しやすいから2重の時はm,n、3重の時はl,m,nを使うようにって指示された会社はあった
    興味本位で「4重のときはどうするのですか?」ときいたら
    4重でforを入れ子にするようなクソプログラムを書く奴は死んでしまえと言われた 

435 デフォルトの名無しさん [sage ] 2010/11/16(火) 23:20:31 ID: Be:
    >>434
    ことあるごとにこれがわからないなら窓から飛び降りてください
    って言ってた教授思い出すわ 

436 デフォルトの名無しさん [sage] 2010/11/16(火) 23:20:54 ID: Be:
    まあ、ヘタクソにかぎってつまらないところで工夫したがるな。 

437 デフォルトの名無しさん [sage] 2010/11/16(火) 23:25:05 ID: Be:
    たぶん他のアルファベットより区別しやすいから i j なんだろうが
    r c とか f s とか適宜使い分けてる
    つか意味を持たないカウンタつかわない 

438 デフォルトの名無しさん [sage] 2010/11/16(火) 23:33:24 ID: Be:
    >>437
    >たぶん他のアルファベットより区別しやすいから i j なんだろうが
    いや、だから、そもそもFORTRAN がな(ry 

439 デフォルトの名無しさん [sage] 2010/11/16(火) 23:33:26 ID: Be:
    iとj誤認する馬鹿はアルファベット練習帳を1000回ループしてろ 

440 デフォルトの名無しさん [sage] 2010/11/16(火) 23:37:16 ID: Be:
    テーブルを舐めるだけとか、ふつーにiとか使ってる。
    変に工夫してもしょうがない。 

441 デフォルトの名無しさん [sage] 2010/11/16(火) 23:39:39 ID: Be:
    しかしJavaラーはイテレータを使った 

442 デフォルトの名無しさん [sage] 2010/11/16(火) 23:42:57 ID: Be:
    イテレータってなんか気持ち悪い 

443 デフォルトの名無しさん [sage] 2010/11/16(火) 23:43:58 ID: Be:
    ループ制御変数 i の由来は
    ttp://ja.wikipedia.org/wiki/FORTRAN

    「7 暗黙の型宣言による伝統的・慣習上の変数命名規則の誕生」 を参照汁 

444 デフォルトの名無しさん [sage] 2010/11/16(火) 23:57:28 ID: Be:
    数学的にはijkはΣみたいな反復演算子や行列の添字で十分通用してるんだから
    forや配列におけるijkも同じように添字やカウンタとして意味は確立してるんじゃないの 

445 デフォルトの名無しさん [sage] 2010/11/16(火) 23:59:39 ID: Be:
    そうだな、Forth なんてループカウンタ値取り出すワード(他の言語で言う関数)が i だもんな。 

446 デフォルトの名無しさん [sage] 2010/11/17(水) 08:55:05 ID: Be:
    ちなみにアイアイはおさるさんだよ 

447 デフォルトの名無しさん [sage] 2010/11/17(水) 11:05:38 ID: Be:
    変数が一文字だと検索するときに面倒くさいから、
    ちゃんとindexとかにしなさいと言われた。 

448 デフォルトの名無しさん [] 2010/11/17(水) 12:05:31 ID: Be:
    で、本の題名誰か教えてよ 

449 デフォルトの名無しさん [sage] 2010/11/17(水) 14:33:29 ID: Be:
    iとjが分かりやすい文字使えよ。 

日本語版Wikipediaの記述は今ひとつ信頼できないんだよなあ。 Iから始まる6文字に決まったのはIntegerの頭文字Iを連想しやすいからと推測される。 推測するのはかまわないのだけど、それを裏付けるものって提示されたことないですよね? 単にそう思えるというのですませるのはちと無責任な気が。 プログラミング上の習慣、ということに限定すればFORTRAN起源でまあ間違いないのだろうけど。

■_ quine

The Shoestring Foundation Weblog
Quine in dc

   Perhaps the first quine to be written in dc.

       [91PlqP93P[dsqx]P10P]dsqx

   To test run

   echo '[91PlqP93P[dsqx]P10P]dsqx' | dc


>echo '[91PlqP93P[dsqx]P10P]dsqx' | dc
[91PlqP93P[dsqx]P10P]dsqx

おー

■_

■_

だめだー

2010年11月16日

■_

X の内部構造なんかを詳しく説明したドキュメントとかあるんでしょうか? 日本語ではまずないでしょうから英語でもいいんですが。

読みにくいプログラムを一生懸命解析して何をやってるかわかってみたら、 それはなんと言語組み込みの機能にあるものをわざわざ自前で書いていたものにござった ○| ̄|_

■_ ものぐさまっちんぐ


正規表現 Part7 
638 デフォルトの名無しさん [] 2010/11/15(月) 16:45:54 ID: Be:
    最短一致のない悲しい環境で使うための

    a(.*?)b

    という文字列を渡すと

    a([^b]*)b

    という最短一致を排除した形式に変換してくれるスクリプトかなんかないかな。 

これ、一文字なら↑のように簡単に片付けられるですが、 複数文字の文字列だったりすると面倒になるんですよね。 で、まあ少なくともメタ文字を含まない固定文字列なら変換する手順はあったりするんですが。

対象文字列を入力してください:
結果:

大昔に ruby でこれを書いた人がいて、ロジックを借りてJavaScriptで書き直したのがこれ。 これを書いた時点ですでに元のページはなくなってて、Web Archiveから拾ってきたような気がする。 で、どこから持ってきたのか完璧に忘れました(苦笑)

■_

スレ立てるまでもない質問はここで 108匹目 
395 デフォルトの名無しさん [sage] 2010/11/15(月) 22:44:53 ID: Be:
    VB2005にてGPIB制御をしています。
    ボードのサンプルプログラムから使えそうなプログラムを抜き出しているのですが、そのなかの「GCHandle」って型だけ定義がされません。
    vbの型じゃないのかな? と思いながらもサンプル自体はVBのものでありますし、さらには「GCHandle」はメソッドでもあるようで混乱……
    ググればFrameworkで使うともVBで使うとも書いてあり、しかしVBで使えるのならなぜ定義できないのだろうと頭を抱えております。

    どなたか教えていただければ幸いです。 

396 デフォルトの名無しさん [sage] 2010/11/15(月) 22:59:09 ID: Be:
    >>395
    前も聞いてた人でしょ?CONTEC に聞けないの? 

397 デフォルトの名無しさん [sage] 2010/11/15(月) 23:05:56 ID: Be:
    >>396
    わっ、そうですそうです。たびたびすいません。

    ちょっと直接向こうの方に問い合わせてみます。
    ありがとうございます。 

398 デフォルトの名無しさん [sage] 2010/11/15(月) 23:20:02 ID: Be:
    最初からやれよクソが 

399 395 [sage] 2010/11/15(月) 23:21:08 ID: Be:
    しかし当方、一学生でありますので、企業様にこれプログラムが云々~って聞くのは勇気いります超いります。
    でもウチの教授様も怖いんだヒイイィ

    こ、ここは勇気を出してみるでござる。 

400 デフォルトの名無しさん [sage] 2010/11/15(月) 23:21:57 ID: Be:
    >>398
    ごめんなさい吊ります 

401 デフォルトの名無しさん [sage] 2010/11/15(月) 23:24:04 ID: Be:
    >>399
    (学校が)お金出して買った製品でしょ?
    自分はお客様、で良いんだよw

402 デフォルトの名無しさん [sage] 2010/11/15(月) 23:27:30 ID: Be:
    >>401
    なるほど……言われてみればそうかもです。

    知らない人に連絡を取るのが苦手だけど、ここはいざ頑張ってみますです 

403 デフォルトの名無しさん [sage] 2010/11/15(月) 23:29:14 ID: Be:
    >>402
    いいとこの大学だったりしたら、大学名を出すとよいことがあるかも・・まあMSだからないかな。 

404 デフォルトの名無しさん [sage] 2010/11/15(月) 23:39:00 ID: Be:
    MS? 

405 デフォルトの名無しさん [sage] 2010/11/15(月) 23:40:02 ID: Be:
    >>395
    Imports System.Runtime.InteropServices
    が無いとかそんなんじゃないの

406 デフォルトの名無しさん [sage] 2010/11/15(月) 23:44:45 ID: Be:
    >>405
    おおおそうだこれを忘れていたんだ……!
    すいませんありがとうございました、完全に見落としてました…… 

407 デフォルトの名無しさん [sage] 2010/11/15(月) 23:45:44 ID: Be:
    >>403

    >>405さんのであってました……
    ご迷惑をおかけしましたホント 

408 デフォルトの名無しさん [sage] 2010/11/15(月) 23:46:45 ID: Be:
    ぶっちゃけサポートは質問され慣れてるから
    恥ずかしがるとか全く気にする必要はない 

409 デフォルトの名無しさん [sage ] 2010/11/15(月) 23:55:06 ID: Be:
    用語とか言われてもとっさに理解できないレベルだと気が引けるのはよくわかるぜ同志 

410 デフォルトの名無しさん [sage] 2010/11/15(月) 23:55:58 ID: Be:
    金を払って作ってもらえばいいじゃないか 

411 デフォルトの名無しさん [sage] 2010/11/16(火) 00:01:03 ID: Be:
    ただのコピペグラマか

412 デフォルトの名無しさん [sage] 2010/11/16(火) 00:14:15 ID: Be:
    GP-IB に CONTEC か。
    懐かしいな、、、 

414 デフォルトの名無しさん [sage] 2010/11/16(火) 13:36:15 ID: Be:
    例外処理・例外仕様の設計について初歩から判る詳しい書籍やサイトって有りませんか? 

415 デフォルトの名無しさん [sage] 2010/11/16(火) 14:12:28 ID: Be:
    >>414
    2chのム板。 

419 デフォルトの名無しさん [] 2010/11/16(火) 18:07:42 ID: Be:
    英語の解説サイトを見ながらプログラムを勉強していますが、
    プログラミングの話に出てくる「dictionary」という単語の的確な意味は、日本語でどういうものでしょうか?

    そのまま辞書という解釈ではわかりにくかったもので、
    Functionが「機能」ではなく「関数」と訳されるように、なにか特別な言い回しがあるのならご教授お願いします。

    併せてどういった概念なのかも教えていただければ幸いです。 

420 デフォルトの名無しさん [sage] 2010/11/16(火) 18:15:16 ID: Be:
    辞書、だろうけど。

    ていうか、functionが関数なのは、なにもプログラミングに限らず数学とかより
    広い世界でそこそこ一般的だと思うけどな。

    話を戻すと、名前から何かを引けるようなもの、をdictionaryということが多いんじゃないかな。
    使われるテクニックからハッシュとかとも呼ばれるような。 

421 デフォルトの名無しさん [sage] 2010/11/16(火) 18:18:17 ID: Be:
    >>419
    ハッシュテーブルとかかな 

422 デフォルトの名無しさん [sage] 2010/11/16(火) 18:26:43 ID: Be:
    連想配列ともいう 

423 デフォルトの名無しさん [sage] 2010/11/16(火) 18:44:26 ID: Be:
    なるほど、ありがとうございました 

424 デフォルトの名無しさん [] 2010/11/16(火) 20:44:58 ID: Be:
    for文などのカウンタ変数にiとかjとか使うのは一昔前の書き方だって
    どっかの本で読んだんですが、その本の名前が思い出せない。
    確かC++関連の有名な外国の著書(の日本語和訳)だったと思うんですが、
    思い出せる方いらっしゃいますか?Generic関係の本だったような気がします。

    なぜiとかjとかが駄目なのか、についても教えてもらえると嬉しいです。
    (個人的にはi、jというのはカウンタであることが自明なので良いと思ってますが) 

425 デフォルトの名無しさん [sage] 2010/11/16(火) 20:49:14 ID: Be:
    そもそもフォートランが 

426 デフォルトの名無しさん [] 2010/11/16(火) 20:55:04 ID: Be:
    いや、そういうのではなく、
    iとかjとか意味のない変数名を使うべきでない、という主張でした。
    呼んだ当時はふむふむなるほど、と思っていたのですが
    最近は「長いと可読性を損ねるデメリットの方が大きいんじゃないか」と
    思うようになってきました。 

427 デフォルトの名無しさん [sage] 2010/11/16(火) 20:59:15 ID: Be:
    >>426
    意味はあるだろ、そもそもFortranが(ry

    その本の主張は正しい
    が、君が最近思ってることも正しい 

428 デフォルトの名無しさん [sage] 2010/11/16(火) 21:01:43 ID: Be:
    ijkは意味があるから いいじゃん。 

GP-IB まだ現役なのか…

そしてループの制御変数に i, j, kネタ。

■_

InfoQ: マイクロソフトのオープンソースF# http://www.infoq.com/jp/news/2010/11/FSharp-Open-Source InfoQ: Microsoft Open Sources F# http://www.infoq.com/news/2010/11/FSharp-Open-Source

「drop」の訳がおかしいような? 「code drop」で一まとまりの名詞だと思うし、 「ドロップする」とか動詞ではないんじゃないかなあ。

■_ バージョン管理ツールいろいろ

結構あるもんですねえ。 Plastic SCM blog: The version control timeline

Plastic SCM blog: The version control timeline

The Plastic SCM blog

Monday, November 15, 2010

The version control timeline
バージョンコントロールのタイムライン

Software Configuration Management (or source code management, for you real hard core 
coders) has been around for quite a few years, slowly moving from an almost 
manual-labor, dark prehistory to the shiny days of the DVCS (distributed version 
control system).

Software Configuration Management (あるいは本物の hard core coder であるあなたがたに
とっては source code management) は

You've all used at least one of the SCMs on the following list, but are you aware of 
how long the system you're using has been around? Do you know the big names? Ok, that's
what I'll try to supply with this short compilation.

あなたがたはみな、以下に挙げたリストにあるSCMの少なくともどれか一つを使ったことがあるでしょう
が、自分の使っているシステムがどのくらいの期間使われてきているのか注意していますか? (SCM の)
「big names」を知っていますか? よろしい。それはわたしがここで書こうと思っていることです。


Look at the following diagram to find some of the main names in SCM history. Yes, I must
be missing a good number of them, so don't be shy: post a comment and I'll update the list
with your favorite one I missed :)


If you're still feeling good about using really “old irons”, I've added some pictures of
how “cell phones” looked like when the SCMs were released, so you feel older and bloody
outdated :). So yes, if you're using CVS and still think it's ok, look at the cell phone
directly below “CVS” in the diagram. Do you feel like Gordon Gecko (Michael Douglas) in
“Wall Street, Money Never Sleeps”, getting his brick-sized cell phone back as he leaves
jail?

Prehistory
前史

There was a time when you stored your versions manually. Ok, for many of you this time 
wasn't the 80s, but a few years back when you were at college naming your source-code 
archives exercise.zip, exercise-0.zip, exercise-good.zip, exercise-good-final.zip, and 
so on. Well, believe it or not, there was a time without real SCMs. It was always dark 
and people were living in caves.

手作業で各バージョンを格納する時代がありました。
Ok, for many of you this time wasn't the 80s,
けれどもあなたが大学にいたほんの数年前にはソースコードのアーカイブに
exercise.zip, exercise-0.zip, exercise-good.zip, exercise-good-final.zip
のような名前をつけていたのです。

Well, believe it or not, there was a time without real SCMs. It was always dark 
and people were living in caves.

信じようと信じまいと、本物の SCM がなかった時代だったのです。
常に暗闇であり、人々は洞穴 (caves) で生活していました。

  
RCS

Then 1982 came and RCS was released. RCS is not a huge piece of technology, but you 
can still find it around in Unix distros. It is simple and straight to the point.

そして1982年になり、RCS がリリースされました。RCS は huge piece of technology ではありませんが
今でも Unix distros で見つけられるものです。
  RCS は単純で、straight to the point です。

  
One nice feature was that text changes were stored as deltas (pretty important, 
considering hard drives used to be small!). Deltas are still used nowadays by most 
SCMs.

RCS の one nice feature はテキストの変更が差分(deltas)として格納されていたことです
(これはとても重要なことで、ハードドライブの使用量を小さくするのを考えているのです!)
大部分の SCM で差分は今日でも使われています

Some RCS drawbacks worth mentioning:
一部の RCS は worth mentioning を drawbacks していました:

# It is text only.
  テキストのみ

# There is no central repository; each version-controlled file has its own repo, in the form of
  an RCS file, stored near the file itself. For example, the RCS file for /usr/project/foo.c is
  /usr/project/foo.c,v ― or a little better, in a subdirectory, /usr/project/RCS/foo.c,v.
  中央リポジトリが存在しない。
  バージョンコントロールされているファイルはそれぞれが固有のリポジトリを持ちます
  RCS ファイルの形で管理対象のファイル自身のそばに格納されている
  たとば /usr/project/foo.c の RCS ファイルは /usr/project/foo.c,v 

# Developers make private workspaces by creating symbolic links to RCS subdirectories – say,
  a symlink from /usr/home/john/RCS to /usr/project/RCS.
  開発者たちは RCSサブディレクトリへのシンボリックリンクを張ることで private なワークスペースを作りました
たとえば /usr/home/john/RCS から /usr/project/RCS への symlink です。

# Naming of versions and branches is downright hostile. A version might be named 1.3, and a
  branch might be named 1.3.1, and a version on the branch might be named 1.3.1.7.

バージョンとブランチの命名は downright hostile です。バージョンは 1.3 のようにつけられるでしょうし
ブランチは 1.3.1 のようになるでしょう。ブランチ上のバージョンは 1.3.1.7 のように命名されます。

The classic era

In the SCM arena, the 90s are the classic era.

SCM arena では、90年代は classic era です。


CVS

It all started with CVS (Concurrent Version System) in 1990. It was able to handle 
multiple versions being developed concurrently on different machines and stored on a 
central server. The client-server age was upon us and developers took major advantage 
out of it.


すべては 1990 年に CVS (Concurrent Version System) によってはじまりました。
CVS は異なるマシン上で並行して開発されている複数バージョンを扱うことが可能で
中央サーバーに格納していました。
クライアント-サーバー時代は
The client-server age was upon us and developers took major advantage out of it.  

CVS was able to handle versions in a decent way. And it even supported branching and 
merging, though it wasn't very good at doing it. That's one of the reasons many people 
are scared about the “B” word and the “M” word.

CVS は decent way でのバージョンの取り扱いが可能でした。
また、非常に良いというものではなかったにせよ
ブランチ分け (branching) とマージ (marging) すらサポートしていました。
That's one of the reasons many people are scared about the “B” word and the “M” word.



CVS didn't track directories or filename changes (no refactoring allowed here!) and 
heavily relied on locking the whole repository. It is outdated now, but it worked in 
the 90s! (If you have it, just walk away and go on to something else!)

CVS はディレクトリやファイル名の変更を追跡していませんでした (リファクタリングが許されていませんでした!)し、
リポジトリ全体のロックにかなり依存していました。
現在それは時代遅れですが 90年代にはそれでうまくいっていたのです!
  
  
PVCS

Polytron Version Control System (PVCS) was initially released in 1985 and then went 
through a series of mergers and acquisitions: Polytron, then Sage, Merant, and finally 
Serena.

Polytron Version Control System (PVCS)  は1985年に最初にリリースされ、
through a series of mergers and acquisitions:
Polytron とそれから Sage, Merant ときて最後には Serena。


It's an old, outdated system (initially designed to avoid branching/merging, using 
file-locking instead), but it's still supported by Serena Software.

これは古く、outdated なシステム(当初はbranching や merging を
排除し、ファイルロッキングを使っていました)ですが、
but it's still supported by Serena Software.
今でも Serena Software によってサポートされています。

(略)

■_

The program running in a console decides what appears in that console - The Old New Thing - Site Home - MSDN Blogs http://blogs.msdn.com/b/oldnewthing/archive/2010/11/15/10090867.aspx

■_ だめだ

ぜんぜん時間が足りない○| ̄|_

■_

2010年11月15日

■_

・センゴク桶狭間戦記
完結。あの締めくくり方はちょっと自分の好みではないかな。

■_

■_ これだけですよこれだけ

細切れにやってたせいもあるけどこんなにてこずるとは。

--- regcomp.c.1~	2007-10-29 16:22:26.000000000 +0900
+++ regcomp.c	2010-11-16 01:52:07.334000000 +0900
@@ -911,7 +911,7 @@ init_dfa (re_dfa_t *dfa, size_t pat_len)
 	    for (j = 0; j < BITSET_WORD_BITS; ++j, ++ch)
 	      {
 		wint_t wch = __btowc (ch);
-		if (wch != WEOF)
+		if (wch != WEOF && !(0xff61 <= wch && wch <= 0xff9f))
 		  dfa->sb_char[i] |= (bitset_word_t) 1 << j;
 # ifndef _LIBC
 		if (isascii (ch) && wch != ch)

もっとも、この修正はあんまりよろしくないのだけどね。

さてこれからどうしたものか。

■_ なんというか

会社でいろいろと以下略

2010年11月14日

■_

・で
オブジェクト指向+関数型の「Scala」で身につける"関数脳"- 技術評論社 | ブック | マイコミジャーナル 技術評論社は、『オブジェクト指向プログラマが次に読む本――Scalaで学ぶ関数脳入門』(株式会社テクノロジックアート 著/ 長瀬嘉秀・町田修一 監修)を発売した。価格は3,339円。 本当に発売されてんでしょうか。目撃証言求む(笑)

・モバイルブースター
秋葉ヨドバシで、一見同じものに見えたのに値段が違うのを見つけたので何でと思ったら Amazon.co.jp: SANYO NEW eneloop スティックブースター USB出力専用ブースターセット(単3形2個セット) KBC-D1AS: パソコン・周辺機器 Amazon.co.jp: SANYO eneloop USB出力付ハンディ電源(単3形2個セット) KBC-D1BS: パソコン・周辺機器 型番違いでした。iPhone対応と謳っているのが出たのですね。 コメントを見ると iPhone4 ではなんか問題ありげですが。 確かにアキヨドでも iPhone 3G と iPhone 3GS 対応としか書いてなかったような気がする。

・温故知新
また図書館からダイクストラ先生の古い本を借りてみたり。 タイトルは以下の三つ。 サイエンスライブラリ 情報 電算機 42 ダイクストラ プログラミング原論 -いかにしてプログラムをつくるか- Information & Computing 59 ダイクストラ プログラミングの方法-論理学を用いた正しいプログラムの作り方- サイエンスライブラリ情報 電算機 32 構造化プログラミング いずれもサイエンス社。 で、プログラミング原論をぱらぱらと眺めていて気になったのですが、 命名のなかの各相続する名前に陽に型もつけるように規定した場合、支払う代償は何であり利益はなんだろうか さらに、陽に相続することの機能は、外側の世界を保護することであり、内側のブロックが知らなければならないその環境と相互に作用できる方法を簡約した結果であると決めた。 こういう文章の「陽に」って最近では「明示的に」と書かれることがほとんどだと思うのですが (実はあまり好きな言い回しではない)、これっていつ頃から主流になったんでしょうね。 90年代初めあたりに「明示的に~」がどうのって論争? を fjあたりで見かけたような気がしないでもないのですが。

■_ カラオケ

こーゆーの縛りでやりましょうとか云ったら人集まるかしらん ♪♪♪♪プログラマ的替歌♪♪♪♪ - プログラマー - READ2CH



♪♪♪♪プログラマ的替歌♪♪♪♪ - プログラマー - READ2CH
やつらの足音のバラード

なんにもない なんにもない まったく なんにもない
生まれた 生まれた なにが生まれた
JOBがひとつ 暗い会社に 生まれた
JOBには客があり そして朝が訪れた
なんにもない 会社に ただ風が吹いてた

やがて 会社に 人が増え 蠢き
昼には 派遣社員が 生まれた
雲が流れ 時が流れ 流れた
テストプログラムが 動き データ領域も 作った
なんにもない 会社で ただJOBが動いた

徹夜が続き PGを 疲労が襲った
同僚の 頭を 白い毛が おおった
なんにもない 会社に かすかに
やつらの足音がきこえた 地平線のかなたより
ドキュソのにおいとともに 仕変が やってきた
やってきた
やってきた

Hum… Hum…
Hum… Hum…

なんにもない なんにもない なんにもない
なんにもない なんにもない なんにもない 

♪♪♪♪プログラマ的替歌♪♪♪♪ - プログラマー - READ2CH
12 + 1:仕様書無しさん[] /05/09 02:49
    誰がために
    '80「サイボーグ009」より

    吹きすさぶ風がよく似合う
    1人の戦鬼と人のいう

    だが我々は金のため
    戦い忘れた人(社員)のため
    涙で渡る血の納期
    夢見て走る死のマーチ
    フリーランス戦士 誰がために戦う
    コーディング戦士 誰がために戦う

    仮眠室がよく似合う
    火消しの使者と人のいう

    だが我々は金のため
    戦い忘れた人(社員)のため
    闇追いはらう時の鐘
    明日の夜明けも職場
    フリーランス戦士 誰がために戦う
    コーディング戦士 誰がために戦う

    だが我々は金のため
    戦い忘れた人(社員)のため
    涙で渡る血の納期
    夢見て走る死のマーチ
    フリーランス戦士 誰がために戦う
    コーディング戦士 誰がために戦う
13:仕様書無しさん[] /05/09 03:04
    >>12
    なんかカッコイイじゃねぇか(w 

面白いのがあったら教えてください :)

■_ Python におけるインデントとは


【Perl,PHP】LLバトルロワイヤル13【Ruby,Python】
723 デフォルトの名無しさん [sage] 2010/11/14(日) 09:26:37 ID: Be:

    インデント批判はLispの括弧批判みたいなもんで、
    使っている人には気にならなくて、外から見たときに付け入られる見に見えた弱点のようなもの。

なるほど。

■_ グローバル変数

C言語なら俺に聞け(入門編)Part 73 [chaika]
224 デフォルトの名無しさん [sage] 2010/11/13(土) 22:05:16 ID: Be:

    グローバル構造体配列とグローバル構造体配列のカウンタ(giとかだったかなwww)
    が設置してある(配列・カウンタとも5個くらいあった)
    色々な関数でインクリメントやらデクリメントやらしてるプログラムに出会ったんだ
    5万行くらいあったんだが、書いた奴出て来いよwww
    メンテする身になってくれ…マジで綱渡りしてるみたいに仕様変更したぞ 

むかーし、一文字の名前を持ったグローバル変数がある(数は少なかった)ソースを 押し付けられたことがあったなあ(遠い目)。

■_ enter/leave

第二オペランドの意味を良く知らなかったけどそういうことだったのか > enter

68K v.s. x86 
320 ナイコンさん [] 2010/05/21(金) 22:39:18 ID: Be:
    8086のBPはなんちゃらの高級言語向けに設計されたって読んだ覚えがある。
    186のentry/leave命令のセットがその延長でスタックフレームの転写を明示的に行うんだとか。 

321 ナイコンさん [sage] 2010/05/21(金) 23:34:22 ID: Be:
    設計された時期が時期だけに高級言語は意識しただろうな。
    どれだけの価値があるか不明だったmicro processorとやらの用途が
    当初の予想以上に広がりつつあった頃だから。 

322 ナイコンさん [sage] 2010/05/22(土) 01:54:14 ID: Be:
    ふーん、そうなの。
    8086なんて単に8080を16bit化(もちろん多少の命令も加えて)した物かと思ってた。 

323 ナイコンさん [sage] 2010/05/23(日) 01:23:06 ID: Be:
    8080とアセンブラソースレベルでの互換性も考慮したんだけど
    結果8080の基本構造をおおむね引きずることになった。
    16bitCPUを新たに設計したというより8080を16bit拡張したと見るほうが
    しっくりくるのはそのせい。 

324 ナイコンさん [sage] 2010/05/23(日) 01:24:05 ID: Be:
    なにしろフラグ変化なんてほとんど8080と互換だしw 

325 ナイコンさん [sage] 2010/05/23(日) 21:39:52 ID: Be:
    >>320
    「なんちゃら」とかでなくて、局所変数をもつ近代的な言語すべてに必要。
    スタック上に局所変数域(スタックフレーム)を形成するため。

    ただし 386 以降のように SP 相対アドレッシングモードがあれば、そちら
    で代用することも可能。gcc では --omit-frame-printer オプションで
    切り替えられる。SP で代用しちゃうと動鎖を手繰れないので、デバック時
    にバックトレースできなくなるけどね。

    enter/leave 命令はスタックフレームの形成・開放を1命令でやってくれて
    便利なんだけど、オンスタックディスプレイを転写する第2引数なんて正気
    の人間は誰も使わない。


326 320 [sage] 2010/05/25(火) 00:18:59 ID: Be:
    高級言語をアセンブラでデバッグしたことがないから、興味なくて読んだときに「へー、そうなんだ」でながしちゃったよ。
    富士テクノロジーとかなんとかいう会社の出してた386/486の解説本だったはず。
    技評の286アセンブラ入門だったかも、
    よくわかる486でないことはかなり自信あるけど
    紙ベースで読んでるからIA32マニュアルではないことだけは確かだ。

    実際entry命令の2つめの引数はコンパイラだけが知ってればいいんだよね。
    実際いつでも、386のコード書いたときだってずっと0だったし。

327 ナイコンさん [sage] 2010/05/25(火) 15:00:00 ID: Be:
    entry/leaveはたぶんPascal系の(C言語ではない)
    引数の数が不定じゃない言語用だな。
    あれ?むかしのMS-DOSのC言語で、pascal宣言入れておくと速く(小さく?)なったのは
    それのせいだっけ? 

328 ナイコンさん [sage] 2010/05/26(水) 20:40:46 ID: Be:
    >>326

    > 実際entry命令の2つめの引数はコンパイラだけが知ってればいいんだよね。

    いや、コンパイラ作成者でも絶対に使わない。

    もう少し詳しく言うと、Pascal や ADA のように関数・手続きの中に
    局所的な関数・手続きを定義できる言語で、中間変数(内側の関数など
    からみて大域的な、外側の局所変数)を正しくアクセスするために使う。

    伝統的には、この目的には静鎖(スタティックリンク)が使われる。
    あるいは高速化を狙ってディスプレイ(陳列棚)方式が使われることもある。

    通常のディスプレイは静的な配列を1つもっていて、サブルーチンコールの
    たびに、その中の1エントリだけ更新する。コピーが必要なのは手続き引数
    を使うときだけ。

    で、インテルは何を思ったのか、ディスプレイをスタック上にとって、サブ
    ルーチンコールのたびにコピーして回るという方法を想定した機能を enter
    命令につけてしまったので、みんなの笑いものになったというお話。

329 ナイコンさん [sage] 2010/05/26(水) 20:54:37 ID: Be:
    >>327

    それは leave 命令のオペランドの話ね。
    呼び出された側がスタックに詰まれた引数をとりのぞく。

    今でも PASCAL または WINAPI 呼び出し規約を指定するとそういうコードがでるよ。
    なにしろ伝統的な Windows API はほとんどこっちだから。

    ただ、昔でも 186 以降を指定しないと enter/leave 命令は使ってくれなかったけどね。
    486 以降は単純命令の組み合わせのほうが速かったりするから、今のコンパイラでも使って
    くれないかもしれない。 

フレームのスタティックリンク方式とディスプレイ方式は知っていたけど (むかーし作ったPascalもどきはこっち使った)、 後者をサポートする命令だったのねえ。

んでちょっとぐぐって見つけた。 CHAPTER TWELVE: PROCEDURES: ADVANCED TOPICS (Part 3)


CHAPTER TWELVE: PROCEDURES: ADVANCED TOPICS (Part 3)

12.1.5 The Display

After reading the previous section you might get the idea that one should never use 
non-local variables, or limit non-local accesses to those variables declared at lex 
level zero. After all, it's often easy enough to put all shared variables at lex level 
zero. If you are designing a programming language, you can adopt the C language 
designer's philosophy and simply not provide block structure. Such compromises turn 
out to be unnecessary. There is a data structure, the display, that provides efficient 
access to any set of non-local variables.

A display is simply an array of pointers to activation records. Display[0] contains a 
pointer to the most recent activation record for lex level zero, Display[1] contains a 
pointer to the most recent activation record for lex level one, and so on. Assuming 
you've maintained the Display array in the current data segment (always a good place 
to keep it) it only takes two instructions to access any non-local variable. 
Pictorially, the display works as shown below:

(略)

12.1.6 The 80286 ENTER and LEAVE Instructions

When designing the 80286, Intel's CPU designers decided to add two instructions to 
help maintain displays. Unfortunately, although their design works, is very general, 
and only requires data in the stack segment, it is very slow; much slower than using 
the techniques in the previous section. Although many non-optimizing compilers use 
these instructions, the best compilers avoid using them, if possible.

(略)

The enter instruction takes two operands. The first is the number of bytes of local 
storage the current procedure requires, the second is the lex level of the current 
procedure. The enter instruction does the following:

(略)

The enter instruction puts the value for the display[n] entry at location BP-(n*2). 
The enter instruction does not copy the value for display[0] into each stack frame. 
Intel assumes that you will keep the main program's global variables in the data 
segment. To save time and memory, they do not bother copying the display[0] entry.

The enter instruction is very slow, particularly on 80486 and later processors. If you 
really want to copy the display from activation record to activation record it is 
probably a better idea to push the items yourself. The following code snippets show 
how to do this:

; enter n, 0    ;14 cycles on the 486

                push    bp              ;1 cycle on the 486
                sub     sp, n           ;1 cycle on the 486

; enter n, 1    ;17 cycles on the 486

                push    bp              ;1 cycle on the 486
                push    [bp-2]          ;4 cycles on the 486
                mov     bp, sp          ;1 cycle on the 486
                add     bp, 2           ;1 cycle on the 486
                sub     sp, n           ;1 cycle on the 486

; enter n, 2    ;20 cycles on the 486

                push    bp              ;1 cycle on the 486
                push    [bp-2]          ;4 cycles on the 486
                push    [bp-4]          ;4 cycles on the 486
                mov     bp, sp          ;1 cycle on the 486
                add     bp, 4           ;1 cycle on the 486
                sub     sp, n           ;1 cycle on the 486

; enter n, 3    ;23 cycles on the 486

                push    bp              ;1 cycle on the 486
                push    [bp-2]          ;4 cycles on the 486
                push    [bp-4]          ;4 cycles on the 486
                push    [bp-6]          ;4 cycles on the 486
                mov     bp, sp          ;1 cycle on the 486
                add     bp, 6           ;1 cycle on the 486
                sub     sp, n           ;1 cycle on the 486

; enter n, 4    ;26 cycles on the 486

                push    bp              ;1 cycle on the 486
                push    [bp-2]          ;4 cycles on the 486
                push    [bp-4]          ;4 cycles on the 486
                push    [bp-6]          ;4 cycles on the 486
                push    [bp-8]          ;4 cycles on the 486
                mov     bp, sp          ;1 cycle on the 486
                add     bp, 8           ;1 cycle on the 486
                sub     sp, n           ;1 cycle on the 486

; etc.

If you are willing to believe Intel's cycle timings, you can see that the enter 
instruction is almost never faster than a straight line sequence of instructions that 
accomplish the same thing. If you are interested in saving space rather than writing 
fast code, the enter instruction is generally a better alternative. The same is 
generally true for the leave instruction as well. It is only one byte long, but it is 
slower than the corresponding mov bp,sp and pop bp instructions.

Accessing non-local variables using the displays created by enter appears in the 
exercises.

なるほどこういう動作をするものだったのか。

■_


The Two Things about Computer Programming - The Fishbowl

The Two Things about Computer Programming

April 15, 2007 7:36 PM

(略)

In The Two Things about the Two Things, it's noted that people are unlikely to agree 
what the two things are, especially when it comes to computing. So I'm going to cheat. 
Here are my four two by two things:

Computer Programming:

   1. Every problem can be solved by breaking it up into a series of smaller problems.
      すべての問題は、より小さな問題の集まりへと分解することで解決可能にできる

   2. The computer will always do exactly what you tell it to.
      コンピューターはいつでもあなたの指示した通りそのままを行う

Software Engineering:

   1. Writing the code is the easy part. Writing it so someone else can understand it 
      later is the important part.
      コードを書くことは簡単な部分であり、他人があとでそれを理解できるようにすることが
      重要である

   2. Make it work, then make it elegant, then make it fast.
      動作するようにして、それから elegant にし、その後に高速化する

reddit で結構スレッドが伸びてまして。 そこから二つ三つ。


The Two Things about Computer Programming : programming

The two things about engineering:

   1. build it so it doesn't break
   2. have a plan for when it breaks


    Make it work, then make it elegant, then make it fast.

This is my approach. Unfortunately, the Real World usually dictates that there isn't 
enough time to make it fast, and there is never, ever enough time to make it elegant.


It's great that you work in an industry where you're given the time to make 
"elegant"/"fast" code. However, in the embedded software industry 
we develop in parallel with other functional groups. The second you're handed a task 
is the second that you are blocking someone else's progress. If it is not elegant/fast 
by the time you get it working, it's because of your own short-sightedness. Here are 
my iterations for embedded software:

    * Make it debuggable.
    * Make it work.
    * Make it work all the time.

デバッグできるように。ってのは重要かも。 elegant にするだけの時間的余裕があるとは限らないってのもそうでしょうね。

■_ apply

blog 主はつけられたコメントで納得していますが。



elisp なんで applyはリストが必要なんだろう? - ながとダイアリー
(apply '+ 1 2) ダメ (apply '+ '(3 4)) 7 (apply '+ 1 2 3 '(4 5)) 15 

naruto_nico 2010/11/13 10:37
list無しでよいならfuncallで足りるから。
(funcall '+ 1 2)

mclh46mclh46 2010/11/13 11:08
 なるほど

(funcall FUNCTION &rest ARGUMENTS)
(apply FUNCTION &rest ARGUMENTS)
このように、引数全く同じですが、applyの説明には、
using our last arg as list of args.
とありました。
funcallを使います! 

「初めての人のためのLisp」で何か書いてあったような覚えがあるので 調べてみたら、第12講で apply と funcall に触れていましたが 求めているものではありませんでした。

funcall 云々は忘れて、引数が 適用する関数 引数リスト の二つになるから リストを受け取るんじゃないんでしょうか。 引数の個数が可変だといろいろ面倒な気が。

■_ list comprehension

見た瞬間には動作が浮かんできませんでした ○| ̄|_



pythonはじめコマンドラインアプリの作成(nabe.py) - podhmoの日記
import sys

def nabe(n):
    return ["aho" if x % 3 == 0 or "3" in str(x) else x for x in xrange(1,n)]

# main
if len( sys.argv ) >= 2:
    n = int(sys.argv[1])
    print nabe(n)
else:
    sys.stderr.write("""invalid arguments
% nabe.py <int>
""")

まあ条件式 (conditional expression) とのあわせ技というせいもあるんでしょうけど。 タイミングよくというか 【Perl,PHP】LLバトルロワイヤル13【Ruby,Python】 の747あたりから Python の list comprehension の話題が続いてますね。

■_

2010年11月13日

■_

・はじめてのGO言語
で、「実体渡し」という用語が出てきていて、なんじゃいそらとぐぐると "実体渡し" - Google 検索 …やっぱり良くわからん。オレ様用語?

・関数脳本
11/13が発売予定だったはずなんだけど本当に出ている? Amazon.co.jp: オブジェクト指向プログラマが次に読む本 -Scalaで学ぶ関数脳入門: 株式会社テクノロジックアート, 長瀬 嘉秀, 町田 修一: 本 書籍案内:オブジェクト指向プログラマが次に読む本―Scalaで学ぶ関数脳入門|gihyo.jp … 技術評論社 昨日今日と何件か大型書店を回ったけど入った形跡が見当たらない。 ジュンク堂書店公式サイト ここにもない。

arton さんのところの CR 増殖ネタをみて何か書こうと思ったんだけど忘れた (けんぼーしょー)。

■_ E

一文字言語は結構あるみたいですが (A-Z全部埋まってたっけ? あとZ は仕様記述言語だったような)。

【超高速】C/C++に代わる低級言語を開発したい 7 [chaika]
396 デフォルトの名無しさん [sage] 2010/11/13(土) 08:07:01 ID: Be:
    だれも知らないだろうけどamigaEは >>3のコンセプトにわりと合致するんだ

    E is an object-oriented/procedural/unpure functional/whatever language with quite a popular implementation
    on the amiga. It's mainly influenced by languages such as C++, Ada, Lisp etc., and features extremely fast
    compilation, inline assembler, large set of integrated functions, powerful module concept, flexible type-system,
    quoted expressions, immediate and typed lists, parametric and object polymorphism, exception handling,
    inheritance, data-hiding, methods, multiple return values, default arguments, register allocation, fast memory
    management, unification, LISP-Cells, macro-preprocessing, a very powerful source-level debugger, gui-toolkit,
    library linker, and then some. 

とかあったので気になってスレッドの最初のほうをチェック。


【超高速】C/C++に代わる低級言語を開発したい 7 [/a>
1 デフォルトの名無しさん [] 2010/05/31(月) 00:56:58 ID: Be:
    70年代、Cは生まれ、それから30余年、現代においてもなお、低レベルなシステム開発に広く使われている。

    しかし、2010年の今、もしもCが発明されていなかったとして、低レベルなシステム開発のためのプログラミング言語を
    新たに作るとしたら、Cとは違う言語になるだろう。少なくとも、全く同じにはならないはずだ。

    そこで、このスレッドでは、
    低レベルなシステム開発のためのプログラミング言語
    を一から考えたい。

    既存の言語を使って何かをすることが目的ではなく、新たなプログラミング言語を考えることが目的であるから、
    「既存のXX言語を使えばいい。」という類の発言は無意味である。

    「既存のYY言語のZZ機能は、WWと言う点で有用だから採用したい。」という発言は歓迎だ。
    現代の一流のプログラミング言語研究者が、最先端の研究成果を盛り込んで、
    一から低レベルなシステム開発のためのプログラミング言語を作るとしたら、どのような言語になるだろうか、
    という観点で考えたい。

    ◆前スレ
    【超高速】C/C++に代わる低級言語を開発したい 6
    http://pc12.2ch.net/test/read.cgi/tech/1274015781/ 

3 デフォルトの名無しさん [] 2010/05/31(月) 01:01:24 ID: Be:
    ◆新言語の要件 v0.1◆

    (1)ハードウェアを直接操作する低レベルの記述が可能
    (2)プログラマーが勘違いしてプログラマーの意図と違う動作をしないように言語仕様が直感的で学習が容易
    (3)最新のオサレ機能が使えてワクワクしながらプログラミング可能


    ◆主な要望◆

    ・デバドラ屋だって、オサレ言語で開発したい!
    ・プログラマーの言語仕様の学習不足によるヒューマンエラーを最小限にするために、できるだけ小さな言語仕様にしたい。
    ・組込み屋だけど、関数型とダックタイピングしたい。
    ・shared_ptrの構文糖が欲しいな
    ・低レベル記述性(絶対条件) > 構文の美しさ(読みやすさ、学習の容易さ) > 再利用性(抽象性)
    ・算術演算以外の演算子は後置
    ・割込み、例外、非同期IOとかを統一扱えるイベント機能が欲しい。 

いずれにしてもAmigaはよくわからんのであった。

■_


Improved Means For Achieving Deteriorated Ends / The Spirit of Lisp (some young kid's impression)

The Spirit of Lisp (some young kid's impression)
Lisp の精神

Disclaimer: I am not speaking for the CL community. Hell, depending on who you ask 
there *is* no Common Lisp community. If you're an old hat lisper, this article will 
probably make you groan, scratch your beard, kick something and mumble something like 
“Lisp just smells funny, News at 11″. I'm posting it because I haven't put the 
words down before and the thoughts bring me joy. But *this is not news*. Because news 
is at 11. If you're a not-yet (common) lisper who has some interest in the language, 
my hope is that if you show up on #lisp or otherwise begin investigating or playing 
with lisp, you'll arrive with a slightly more informed perspective.

I recently read something on Zach Beane aka xach's blog that made me quite happy. He 
was posting about this year's International Lisp Conference and discussed (among 
other things) the low attendance this year and some possible causes of that. But then 
he went on to write this wonderful bit,

   “I really like getting together in space and time with other Lispers. An ideal 
     future Lisp conference for me, personally, would … attract hundreds of cheerful and 
     enthusiastic Lisp nerds…Navel-gazing and nostalgia would be at a minimum. People 
     would talk about what they're doing today and what exciting things they plan for
     the future. Everyone would get together at dinner and swap stories about Lisp, life,
     and whatever else came to mind.

    I know people are doing fun stuff with Lisp because I talk to them every day about 
    it online. It would be pretty special to talk to them for a few days about it
    face-to-face.”

    …which in part led me to tweet the following just because I thought it embodied some 
    things I really love about the lisp community:

    “(loop (awhen (build-something) (release it))) ;; Wake up #lisp ers. Your time is 
     now. This message brought to you in part by #quicklisp”

Nikodemus Siivola nailed this too at some point with the quote, “Schemer: “Buddha is 
small, clean, and serious.” Lispnik: “Buddha is big, has hairy armpits, and laughs.” 
Scott Fahlman's statement that “Common Lisp is politics, not art.” seems similarly 
indicative of this in some ways also. T here are two things I'm really trying to get 
at. One is agnosticism, a very serious take on multi-paradigm, “you want it, you got 
it” programming. Opinionated languages are great as are languages or communities that 
are pursuing other goals, be they some abstract notion of elegance, minimalism or 
anything else. But…Common Lisp *is* a programmer amplifier. It subscribes to no 
preordained or predefined notion of what elegance is.[1] Hell, a recent article talked 
about 3 different kinds of languages you need to know and I might add an unopinionated 
language and an opinionated language to that list. Whatever the opinions you ought to 
see the difference.

My other point is the more important one, the emphasis both in the language and 
community on practicality, productivity and getting things done. People often show up 
on lisp.reddit or the #lisp channel on Freenode/IRC and ask if Lisp can has monads or 
Lisp does functional programming or if people have built big things with it and so on 
*before* trying to learn lisp or using it.[2] Almost always the first response is “
Why are you asking that? Why does it matter? Why do you want to know?”. This tends to 
dissatisfy the visitors whose real agenda, in my humble opinion, is usually to ensure 
they study the thing that will “make them good” or get them furthest ahead of the 
curve. Why waste your time with “the wrong language”?

Generally, the whole conversation devolves. The parties are coming from totally 
different points of inquiry. But whether the visitors are “flamed so hard they die” 
or gently dealt with until agreements are reached things end pretty quickly and 
everyone goes on about their day. Paul Snively calls lisp the “cockroach of 
programming languages” and I'm not sure if he means Common Lisp or just the Lisp 
family genes. But when people ask if lisp is dead or “shouldn't I just use/study 
language X?” I'm relieved and pleased that we're too busy having fun and building 
things to worry about it. Who cares what language wins tomorrow? This language works 
today, we're using it and when we see other languages with something we need, we grab 
it.

To me this is something refreshing about the lisp community that isn't internally or 
externally recognized quite enough. Which isn't to say that we should go around 
beating our chests and talking about what rock stars or great programmers we are. I'm 
certainly not one. I remain a wet behind the ears programmer. I'm not writing as much 
code as I should and as a consequence still have little useful stuff to release. But I'
ve been privileged to watch and try to help Will Halliburton with a lisp-powered 
startup and work with Leslie Polzer on Weblocks and Paktahn.

Really it's most likely that there's so much more noise than signal regarding “lisp” 
and often so little clarity as to whether scheme, lisp or genetically ‘lispy' 
languages are being discussed on online forums that the public image about Common Lisp 
is horribly out of whack. Hell, I've said terrible, stupid, ridiculous things about 
Common Lisp in the past. Why? I hadn't seen the community, I hadn't seen the 
language, I didn't understand *what* it was. And maybe we can't change that or it's 
just not worth the effort. The people who have heard something from x, who heard it 
from y, who heard it from z will keep repeating old wives' tales forever. But here's 
my attempt at getting down why this language is in no danger of dying anytime soon:

We're all just having fun building things. And if that sounds like something you'd 
like to do, please come in, visit #lisp and ask us questions. Message me personally if 
you want, I'm on freenode as redline6561. I promise the water is fine. Just don't 
ask if this is the right way to use your time. Figure that out in advance. As far as I'
m concerned, between great open source implementations like SBCL and CCL, great 
editing solutions like SLIME for emacs, Slimv for vim and the new Textmate bundle and 
easy access to libraries through quicklisp, there's never been a better time.

[1] This certainly is not to say that you can't use or practice other languages 
notions of elegance in lisp. Drew Crampsie aka drewc has been perfectly happy working 
on a monadic web request dispatcher of late and Francois Rene Rideau aka fare happily 
does Purely Functional Programming in CL and came up with an “Interface Passing Style” 
which simulates the parametric polymorphism of Haskell's type classes.

[2]If you're doing that, you're missing the point. Part of the reason that happens 
is surely the endless blog articles and old reddit comments which endorse SICP and “
learning lisp” as a way to expand your mind and reach some ersatz programming 
enlightenment. Part of it is that you might just be getting started in programming and 
looking for ways to skip to the end. And that's understandable, I've been there 
myself. But remember the words of Norvig and Nostrademons.

■_ 興味深い

VBA じゃなくて Python でいじくりまわせたらなあ>えくせる


Pyspread

About

Pyspread is a cross-platform Python spreadsheet application. It is based on and 
written in the programming language Python.

Instead of spreadsheet formulas, Python expressions are entered into the spreadsheet 
cells. Each expression returns a Python object that can be accessed from other cells. 
These objects can represent anything including lists or matrices.

スプレッドシートの数式の代わりに、Python の式をスプレッドシートのセルに入力します。
それぞれの式はほかのセルからアクセスできるような Python オブジェクトです。
これらのオブジェクトはリストや行列のようなものを含むすべてを表現可能です。


Features

In pyspread, cells expect Python expressions and return Python objects. Therefore, 
complex data types such as lists, trees or matrices can be handled within a single 
cell. Macros can be used for functions that are too complex for a single expression.

pyspread では、セルはPython の式を期待していてPythonオブジェクトを返します。
したがって、リストや木、行列のような複雑なデータ型も一つのセルの中で
取り扱いが可能です。ひとつの式では複雑すぎるような機能にはマクロを使えます。

Since Python modules can be easily used without external scripts, arbitrary size 
rational numbers (via gmpy), fixed point decimal numbers for business calculations, 
(via the decimal module from the standard library) and advanced statistics including 
plotting functions (via RPy) can be used in the spreadsheet. Everything is directly 
available from each cell. Just use the grid

Python モジュールは外部スクリプトなしで簡単に使うことができ、
(gmpy を通じた) 任意の大きさの有理数、
(標準ライブラリの decimal を使った) ビジネス計算向けの固定小数点の十進数、
(RPyを使った) プロット関数を含む高度な統計といったものをスプレッドシートでは
使えます。すべてのものは各セルから直接利用可能です。

Data can be imported and exported using csv files or the clipboard. Other forms of 
data exchange is possible using external Python modules.

csvファイルやクリップボードを使ってデータのインポートやエクスポートができます。
そのほかのデータ形式の交換は外部のPythonモジュールを使って可能です。


In  order to simplify sparse matrix editing, pyspread features a three dimensional 
grid that can be sized up to 85,899,345 rows and 14,316,555 columns (64 bit-systems, 
depends on row height and column width). Note that importing a million cells requires 
about 500 MB of memory.

疎行列の編集を単純化するために、pyspread の三次元グリッド機能であつかえるのは
行が 85,899,345 、列が 14,316,555 までの大きさのものになります (64ビットシステムの
場合は、行の高さや列の幅に依存します)。
百万個のセルはおおよそ500メガバイトのメモリーを要求することに注意してください。

The concept of pyspread allows doing everything from each cell that a Python script 
can do. This may very well include deleting your hard drive or sending your data via 
the Internet. Of course this is a non-issue if you sandbox properly or if you only use 
self developed spreadsheets. Since this is not the case for everyone (see the 
discussion at lwn.net), a GPG signature based trust model for spreadsheet files has 
been introduced. It ensures that only your own trusted files are executed on loading. 
Untrusted files are displayed in safe mode. You can trust a file manually. Inspect 
carefully.

pyspread のコンセプトは各々のセルから Python スクリプトでできることすべてをできる
ようにします。それにはあなたのハードディスクの内容の削除であるとかインターネット経由で
あなたのデータを送信してしまうといったことも含まれます。もちろんこれは
あなたが適切にサンドボックスにしていたり self develope したスプレッドシートだけを
使っているならば問題にはなりません。これはすべての人に当てはまるわけではないので
( lwn.net での議論を参照してください)、GPGを使った署名に基づく信頼モデルが
スプレッドシートに導入されています。これはあなたが信頼しているファイルだけを
ロード時に実行することを保証するものです。信頼されていないファイルはセーフモード下で
表示されます。マニュアル操作でファイルを信頼することができます。
注意深く調べてください。

(以下略)

■_ ねた

組み込みプログラマー雑談スレッド その17 
469 仕様書無しさん [] 2010/11/13(土) 12:28:37 ID: Be:
    javaでクロックジェネレータのレジスタの変更の仕方がわからない 

470 仕様書無しさん [sage] 2010/11/13(土) 13:38:46 ID: Be:
    >>469
    関数作れよ、C++ でなw 

474 仕様書無しさん [sage] 2010/11/13(土) 16:02:59 ID: Be:
    >>469
    つ JNI

    java と C は仇のようで実はお友達。
    チャイナとアメリカみたいなもん。 

475 仕様書無しさん [sage] 2010/11/13(土) 16:24:01 ID: Be:
    >>469
    むしろ、文楽人形と人形師だろ 

476 仕様書無しさん [sage] 2010/11/13(土) 16:30:31 ID: Be:
    伝説のハッカー「人形使い」 

477 仕様書無しさん [sage] 2010/11/13(土) 16:31:31 ID: Be:
    そーいえばおまえらもゴースト無くしてないか?w 

478 仕様書無しさん [sage] 2010/11/13(土) 16:33:44 ID: Be:
    このスレはどこかのオタクに占領されたらしい。 

479 仕様書無しさん [] 2010/11/13(土) 17:46:46 ID: Be:
    >>469
    System.Native.Interfacem.Register.CockGenerator.Oscillator,PhaseLockedLoop,Enable() 

475 のアンカーは 469 の間違いかな?

■_

■_

RubyConf2010 -Matz基調講演編- - Everyleaf Lab RubyConf X - 思っているよりもずっとずっと人生は短い。

2010年11月12日

■_

・しょぼーん
午後から秋葉原に行ったのに、月~木よりもかなり早く売り切れしまって ショボーンクッション買えなかった。次は12月下旬って○| ̄|_ 関数脳本もなかったし。

データ形式は単純に

■_


【Perl,PHP】LLバトルロワイヤル13【Ruby,Python】 
678 デフォルトの名無しさん [sage] 2010/11/12(金) 03:18:18 ID: Be:
    プログラミング言語マニアみたいな人がいたらお聞きしたいのですが
    Pythonの並に一貫して書きやすさや冗長性をなくすことよりも読みやすさを重視していてかつ
    ドキュメントが少なく、コミュニティが活発でないマイナー言語はありませんでしょうか?

    Pythonと他のLLやその他言語が比較されることがありますが、
    いつも話を聞くのは、誰にとっても同じように書け、またあとから読みやすいからよいということのようです。

    例えばRubyが使いづらいのはメタプログラミング以上に、ドキュメントが少ない、
    Windowsでのサポートが少ないなどと言われることもありますが
    それは単にPythonのコミュニティが大きくが人的なリソースを潤沢に持っているからなのではないか?と

    つまり、Pythonからコミュニティやドキュメントなどを省いたような言語でも使いやすいはずと考えました。

    動作はWindowsかLinuxで動くもので

679 デフォルトの名無しさん [sage] 2010/11/12(金) 03:20:28 ID: Be:
    > つまり、Pythonからコミュニティやドキュメントなどを省いたような言語でも使いやすいはずと考えました。

    つまり、誰にとっても同じように書け、またあとから読みやすいから、ということであれば
    Pythonからコミュニティやドキュメントなどを省いたような言語であれば使いやすいはずと考えました。


    支離滅裂ですいませn 

681 デフォルトの名無しさん [sage] 2010/11/12(金) 10:52:14 ID: Be:
    >>678
    日本語勉強してからまた来なさい 

682 デフォルトの名無しさん [sage] 2010/11/12(金) 11:21:19 ID: Be:
    言ってることはわかるよ、俺はそういう言語あるのか知らんけど 

683 デフォルトの名無しさん [sage] 2010/11/12(金) 11:58:19 ID: Be:
    synapticパッケージマネージャなり,
    comp.langの(何だっけ)を眺めて自分で探せ 


「使いやすさ」(と「読みやすさ」、「書き易さ」)をどう定義するかにもよるんじゃないかなあ というかそこを発揮しさせないとどうにもならない気が。

■_

この辺もある意味過去を引きずったせいなんかねえ。


INT_MIN の定義について - Yahoo!知恵袋
INT_MIN の定義について

C の規格では、INT_MAX は 32767 以上を、INT_MIN は -32767 以下を表現出来なければならな
い、と定められています。

しかし、たとえば 16ビットの処理系では、INT_MAX が 32767 で、INT_MIN が -32768 であるも
のが多く見られましたし、私が使っている MinGW の gcc では INT_MAX が 2147483647 で、
INT_MIN は (-INT_MAX-1) すなわち -2147483648 になっています。

つまり、多くの処理系で、2の補数系における最大値と最小値が INT_MAX と INT_MIN に定義さ
れています。もちろん、これは規格合致ではあるのですが、1つ疑問があります。

なぜ、INT_MIN を (-INT_MAX) にしないのでしょうか。わざわざ (-INT_MAX-1) にする理由は何
なのでしょうか。

INT_MIN が (-INT_MAX) であれば、たとえば abs( INT_MIN ) は正しく INT_MAX を返してくれ
る事が期待出来ますが、これが (-INT_MAX-1) だと、abs( INT_MIN ) は正しい結果を返せると
は思えません。

(-INT_MAX-1) としても、たかだか範囲を1だけ広げるだけで、メリットは少なく、しかもデメ
リットは少なくないと思われるのですが…。


処理系依存のint型だから。

・ ○○以上であること
・ △△以下であること

として範囲を定義しただけ。

それなら1の補数を採用している処理系でも2の補数を採用している処理系でも
規定値が2バイトでも4バイトでも

一通りフォローできるだろ?


広げるも何も、細かい点については「お任せ」されているんだからメリットもデメリットも無い。

解釈が自然かどうか、わざわざ変数を使って符号を反転させてまで定義する意味があるのか?
それだけのオハナシ。

2 の補数以外のアーキテクチャを実際にいじったことはないかも。

■_

reddit から。


Learning Perl is making me appreciate Ruby even more : ruby

Dynamic getters and setters in Perl:

sub AUTOLOAD {
  my @elements = qw(color age weight height);

  our $AUTOLOAD;
  if ($AUTOLOAD =~ /::(\w+)$/ and grep $1 eq $_, @elements) {
    my $field = ucfirst $1;
    {
      no strict 'refs';
      *{$AUTOLOAD} = sub { $_[0]->{$field} };
    }
    goto &\1{$AUTOLOAD};
  } elsif ($AUTOLOAD =~ /::set_(\w+)$/ and grep $1 eq $_, @elements) {
    my $field = ucfirst $1;
    {
      no strict 'refs';
      *{$AUTOLOAD} = sub { $_[0]->{$field} = $_[1] };
    }
    goto &\1{$AUTOLOAD};
  } else {
    croak "$_[0] does not understand this method\n";
  }
}

In Ruby:

attr :color, :age, :weight, :height

Yeah.


AUTOLOAD is evil. And besides, nobody who programs Perl would used hacked OO like that 
these days - you'd use Moose.

package SomeClass;
use Moose;

has 'color' => (is => 'rw');
has 'age' => (is => 'rw');
has 'weight' => (is => 'rw');
has 'height' => (is => 'rw');

1;

Not much different to the Ruby.

But then, I don't want to ruin your stereotype that Perl is a mess, so maybe I should 
just shut up now ;-)

Moose isn't Perl just like jQuery isn't JavaScript, though. Unless I'm mistaken and 
Moose is an official part of Perl, and not a third-party library? If the latter, it's 
fair to criticise Perl's OO hacking way of doing accessors.


Moose is pretty much an unofficial standard for anything larger than a maintenance or 
one-off script.


Understood, and so are libraries like jQuery to JavaScript. Working with Perl doesn't 
imply working with a framework that glosses over the prickly bits. There's still the 
language underneath, which is what OP fairly criticised.


Aw - give Perl a break. Keep in mind, Matz had Perl (and other languages of course) in 
mind when he designed Ruby - of course he's going to borrow the good parts and leave 
the bad parts behind.

From "An Interview with the Creator of Ruby", 
http://linuxdevcenter.com/pub/a/linux/2001/11/29/ruby.html

Stewart: I gather you had worked with both Perl and Python before creating Ruby. What 
bits of Perl did you incorporate in Ruby?

Matz: A lot. Ruby's class library is an object-oriented reorganization of Perl 
functionality--plus some Smalltalk and Lisp stuff. I used too much I guess. I 
shouldn't have inherited $_, $", and the other, ugly style 
variables.

Instead - marvel at the fact that perl does OO pretty much at all! It's really 
something grafted onto the language as an afterthought; the fact that it can be used 
so successfully and widely (and that the ugliness above can be hidden so well in 
modules) is a testament to Perl's flexibility. Can newer languages do it cleaner? of 
course - it would be sad if they didn't. But making fun of perl because of unweildy 
object programming is like making fun of COBOL because it's "wordy" - well, 
duh.

If you really want to do OO in perl (and you don't mind module hell) - try Moose.

Yes. Ruby programmers owe thanks to Perl.

Just as Java was designed with eyes firmly planted on C and C++, Ruby was very 
strongly informed by Perl and Smalltalk.

I think Ruby was far more successful in improving on its influence, but that's a 
different topic. :)

I agree with this – I realize the historical context of the two languages needs to be 
taken into account. Like I said, learning Perl now only makes me appreciate Ruby and 
how it's moved things forward.


Other things that you will grow to hate:

    * Having to explicitly check for errors on every function, except when you
      shouldn't. Good luck figuring out when that is.

    * Along those same lines, lack of structured exceptions.

    * Stuff like "eq" vs "==" and loads of other quirks.

    * Byzantine scoping rules.

    * Having to remember what a function returns for list vs scalar context. This
      alone is a source of endless bugs.

    * Getting yelled at by the community every time you forget to use
      strict/warnings/whatever-the-pragma-of-the-year-is. Followed by a lecture on
      why they aren't the default behavior.

    * Lack of anything resembling the simplicity of begin/ensure/else.

    * Watching your code blow up because you forgot to put a "1;" at the
      end of your module.

    * Ugly syntax, especially hash dereferencing syntax.

    * Using hashes for everything.

    * Writing C extensions with XS. WTF.

    * A crap ton of operators. You'll just have to figure out which ones matter.

    * As you've experienced, crappy, bolted on OO. At least there's Moose now.

    * No threads by default. Get used to fork.

There's more, but I'm tired of writing. You'll figure it out. >:)

■_あとでやくす

時間あったはずなんだけどなあ


The Future of Programming Languages: Economics

The Future of Programming Languages: Economics

Posted by David N. Welton Wed, 10 Nov 2010 15:44:00 GMT

Someone on Hacker News asks about the future of programming languages, and I realized 
that it's a pretty interesting topic. Here's my take on it:

Hacker new で誰かがプログラミング言語の将来について質問していたのだけど、
それはとても興味深いものだと思ったのでここで自分の意見を書いてみることにした。

Programming languages are about people, and the compromises they may or may not make 
in order to communicate their intentions to computers.  The technology in question may 
change, but there will likely always be people involved, and as long as that's true, 
looking at the problem through the lense of economics provides useful results.

Therefore, looking at programming languages pretty much requires that you look at the 
economics of them:

したがって、プログラミング言語に注目するということは、その経済学について
見ることをとても要求しているのです。

    * Network effects are important, but obviously don't squeeze out smaller languages 
      entirely.  I.e. it's good to be able to get libraries, find people to hire, books to 
      read, friends to chat with about problems, etc...  This means that future languages 
      will have to seek out a critical mass of users.

      ネットワーク効果は重要である。しかし、小さな言語を完全に squeeze out しないことは
      明らかである。ライブラリを得るのが可能なようにし、雇う人を見つけやすいようにし
      読むべき本を見つけやすくし、問題を相談できる友人を見つけやすくするなどなど。
      このことは将来の言語はそのユーザーの critical mass (臨界) を seek out しなければ
      ならなくなるだろうということだ。

    * Since the times of Fortran, languages have been getting more efficient in terms 
      of programmer time, because programmer time stays the same or gets more expensive, 
      while computer time keeps getting cheaper, and language implementors keep getting 
      better at making things fast under the hood.  This means that languages of the future 
      are likely to let you do more with less, all else being the same.

      Fortran 以来、プログラミング言語というものはプログラマーの時間という意味において
      より効率的になってきている。なぜならば、プログラマーの時間というのはコンピューターの
      時間が安価になっていくのに反比例して高価になっていったりそのままの価値を保って
      いたりするからだ。そして言語の実装者は

    * Learning a programming language will continue to be a fairly involved process for
      most people, meaning that for many, it's more efficient to learn a few languages 
      well and use them for as much as possible, rather than to try and find the 'perfect' 
      language for each problem.  This rewards general-purpose languages, compared to
      niche languages.  This also rewards flexible languages that can be used in many
      different environments.

      プログラミング言語を学ぶことは大多数の人にとっては fairly involved process であり続け
      るだろう。

個々の問題のための「完全な」言語を見つけ出そうとするよりも
これは nichie な言語よりは汎用的な言語 (general-purpose languages) に rewards する。
これはまた多くの異なる環境で使えるように flexible な言語に rewards する。

    * Computers are only going to become more and more important, meaning that more 
      people are going to want to develop the skills to work with them.  Not all of them 
      will be experts, and many may not know much, but have a vision for how a program
      could solve a particular problem in a field they are knowledgeable about.  This
      means a low barrier to entry is important, because those novices will pick easier
      languages, become progressively more competent in them, and thus (network effects)
      contribute to their diffusion.  Case in point: PHP.  Future languages should be
      capable of solving hard problems, but should also make it easy to get started
      solving simple problems too.

このことは入門への障壁が低いことが重要であることを意味する。
なぜなら、そういった初心者たち (novices) は
より簡単な言語 (easier languages) を取り上げて

そして(ネットワーク効果を起こして)その拡散に貢献するのだ。
PHPの場合を考えてみよう。
将来の言語は難しい問題 (hard problems) を解決できるものであるべきだが、
同時に単純な問題 (simple problems) を解決するのも容易にできるように
なっているべきなのだ。

    * Working on languages is lots of fun, so even though there aren't necessarily 
      monetary rewards, people will continue to play with and explore new ideas.  I
      don't see there being a limited supply of new languages in the future.

言語について作業することはとても楽しいことだから、
金銭的な見返りの必要性がなかったとしても
人々はその言語を play し、新しいアイデアを求め続けるだろう。
わたしは将来において新しい言語の供給が限定されるものになるとは考えていない。

    * The costs of switching from established languages will continue to be high, so 
      future languages will still need to interact with "legacy" languages
      like Cobol, Fortran, C, Java, and so on, that are so widely established in
      industry that systems written in them will be with us for a long time yet.

established languages からの切り替えのコストは
高止まりし続けるだろうから、
将来の言語はCOBOLやFortan、C、Javaなどといった“legacy”な言語と
iteract する必要があるだろう。


I wrote this in a hurry.  Have I missed anything?  How do these factors apply to 
languages you see emerging?

駆け足でわたしの意見を述べてみた。
何か見落としていることはあるだろうか?
これらの要素 (factors) をどのようにして
あなたが emerging させたい言語に適用すればよいのだろうか?

■_

2010年11月11日

■_

まだバグを追いかけています。

あともうちょいだと思うんだけどなあ。 状態遷移表を作っているところがおかしいような気はするのだけど 現場を押さえられない(笑)

■_

追いかけてる余裕ナッシング

Eternally Confuzzled - Skip Lists
By Julienne Walker
License: Public Domain

A binary search tree is a data structure designed for efficient search, insertion, and 
deletion in the presence of a large number of items. While these operations are easy 
to implement for a basic binary search tree, less trivial operations such as flexible 
non-recursive traversal are not as simple to create. Also, basic binary search trees 
have uncomfortably common worst case behavior that makes them impractical for many 
applications.

From an architect to a programmer... - The Emergent Life

My team and I received this in our inbox from our architect six months ago when we 
started a new project:

Shedding Bikes: Programming Culture And Philosophy

By Zed A. Shaw
Tir: A Mongrel2+Lua Micro-Framework

I created a fun little Lua micro-framework test out some ideas for Mongrel2 I'm 
calling Tir. This blog post is a quick introduction to what I've got so far, with more 
concrete stuff later. I'm using Tir on two very real projects, so if you're a Lua 
expert please let me know how I can improve it.

Apache declares war on Oracle over Java | ITworld

Apache declares war on Oracle over Java

The Apache Software Foundation threatens to ditch Java if Oracle doesn't relent on use 
restrictions

■_


makin' it work: musings of the math gladiator: The 3 Programming Languages you need to Know

makin' it work: musings of the math gladiator

Wednesday, November 10, 2010

The 3 Programming Languages you need to Know
あなたが知っておくべき三つのプログラミング言語

Every good programmer needs to know at least 3 languages. Of course, I'm probably 
wrong.

すべての優れたプログラマーは少なくとも三つ、プログラミング言語を知っています。
もちろん、わたしが間違っていることもあるでしょう。


I can quickly understand a programmer using the biases and stereotypes that I've built 
up over the years by knowing their favorite programming languages. When I read a resume,
I try to classify the "why the programmer used the programming language" with
these arch types and how I stereotype and use my biases to find what I want from a stack
of resumes.

わたしはレジュメを読んだとき
"why the programmer used the programming language"
の classify を試みます


Happiness Language

This language is what you think in. This is the language that you wish you could use 
all the time. This is the language that you write your projects in. For me, this is 
OCaml (and now JavaScript although I'm integrating CoffeeScript into my universe). For 
many, this is LISP or Haskell. When I find out someone's happiness language, it tells 
me a lot about them.

この言語はあなたがそれを使って考えるものです。
わたしにとってはこの言語は OCaml です (そして現在は CoffeeScript に興味があるのですが
JavaScript もです)。多くの人にとってはこの言語は LISP や Haskell でしょう。誰かの
happiness language に気づいたとき、そのことはその人に関する多くのことを教えてくれるのです。


If the language is esoteric or new, then they are passionate about computing.

もしのその言語が奇妙であったり新しいものであれば、彼らはコンピューティングに
対して情熱的でしょう。


If the language is mainstream, then they may be more sensible or practical about 
computing.

もしその言語がメインストリームのものであれば、彼らはコンピューティングに対して
より sensible であったり practical であるかもしれません。


Hack-it-out / GTD Language

This is the language that contains everything including a kitchen sink. It is very 
mature and has a massive library base. With this language, you enable yourself to 
build quick services and command line utilities to help you out in a pinch. Anything 
that has already been done is at your finger tips.

この言語はキッチンシンクを含めたすべてを備えている言語です。
非常にmatureであり、大規模なライブラリベースを有しています。
この言語を使うことで、
あなたは自分がピンチに陥ったときにも自分を助けるために
サービスをすばやく立ち上げたりコマンドラインユーティリティを組み上げることが可能です。
用意されているものはあなたの指先にあります。

If the programmer lists many languages, then they may be able to utilize all of them 
by building RESTful services.

もしプログラマーが多くの言語をリストすれば、それらはたぶん
RESTful サービスを構築することでそれらすべての utilize が可能でしょう

If I don't detect a hack-it-out language or too few languages, then I suspect they are 
either inexperienced or too specialized.

わたしが hack-it-out 言語を detect しなかったりあるいは言語が少なすぎたりしたら、
わたしは彼らが経験不足(inexperienced) か specialize しすぎであると suspect します。


Bread and Butter
パンとバター

This is the language that you can use to keep yourself alive when life hands you lemons.
This is the language that you know just in case you need to hustle yourself to provide
for yourself and your family.

これは life hands you lemons のときに
あなたが keep yourself alive するのに使える言語です
これは

If they don't have a bread and butter language, then they probably need some education 
on how to work in a team effectively.

もし彼らが bread and butter language を持っていなければ
おそらく彼らは少々の教育が必要でしょう
チームをどのように効果的に働かせるかについての

■_

■_


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

ホームへ


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