ときどきの雑記帖 二束三文編

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

一つ前へ 2011年7月(下旬)
一つ後へ 2011年8月(中旬)

ホームへ

2011年08月10日

■_

読書会

■_

【小惑星に挑む】あさりよしとお総合スレ36【まんがサイエンス】 

202 名無しんぼ@お腹いっぱい [sage] 2011/08/10(水) 19:17:20.10 ID:F1mu5Kw90 Be:
    Σ(゚д゚lll)ガーン

    --------------------------------------------------------------------
    Amazon.co.jpをご利用いただき、ありがとうございます。

    以下のご注文商品につきまして、出版社より発売延期の連絡を受けました。

    『ラジヲマン』(ASIN: 4022508183)

    ストーリーに原発の内容が含まれていることから、東日本大震災後、販売の見通しがまったく立っていない状況です。
    そのため、現在のところ発売日が未定であることから、誠に勝手ながら、今回ご注文をキャンセルさせていただきま
    したので、ご了承ください。

    このたびは、ご注文商品をお届けできず、ご迷惑をおかけしたことをお詫びいたします。

    このEメールアドレスは配信専用です。ご不明な点は、下記のURLからカスタマーサービスまでお問い合わせください。

    http://www.amazon.co.jp/contact-us/

    Amazon.co.jp カスタマーサービス
    Amazon.co.jp Customer Service.

203 名無しんぼ@お腹いっぱい [sage] 2011/08/10(水) 19:19:39.77 ID:h+WuH8fw0 Be:
    うん、まあそうだろうね・・・ 

204 名無しんぼ@お腹いっぱい [sage] 2011/08/10(水) 19:43:59.94 ID:hICmB+DW0 Be:
    去年のうちに出していれば・・・・・・。 

205 名無しんぼ@お腹いっぱい [sage] 2011/08/10(水) 20:05:17.51 ID:QXIcKl070 Be:
    ラジヲマンを出版出来た時が本当の復興だな
    20年はかかりそうだけど 

206 名無しんぼ@お腹いっぱい [sage] 2011/08/10(水) 20:09:00.13 ID:pESKzAJB0 Be:
    無期延期かな


    Amazon.co.jpをご利用いただき、ありがとうございます。

    以下のご注文商品につきまして、出版社より発売延期の連絡を受けました。

    『ラジヲマン』(ASIN: 4022508183)

    ストーリーに原発の内容が含まれていることから、東日本大震災後、販売の見通しがまったく立っていない状況です。
    そのため、現在のところ発売日が未定であることから、誠に勝手ながら、今回ご注文をキャンセルさせていただきま
    したので、ご了承ください。

207 名無しんぼ@お腹いっぱい [sage] 2011/08/10(水) 20:15:57.79 ID:b+SLk6Y20 Be:
    出版社からの具体的な理由w 

208 名無しんぼ@お腹いっぱい [sage] 2011/08/10(水) 20:22:03.87 ID:vjkSE0vq0 Be:
    毒入り短編集より先に出してくれれば・・・・ 

209 名無しんぼ@お腹いっぱい [] 2011/08/10(水) 20:24:13.45 ID:b4V5eUerO Be:
    アマゾンwww 

210 名無しんぼ@お腹いっぱい [sage] 2011/08/10(水) 21:12:30.67 ID:3Bq61rSr0 Be:
    ラジヲマンキャンセルこっちも北orz
    あとちょっと早く出版してれば、逆にベストセラーだったかもしれんのに・・・ 

211 名無しんぼ@お腹いっぱい [sage] 2011/08/10(水) 21:27:23.07 ID:2PVdwySZ0 Be:
    どういうコトだ! 「ラジヲマン」キャンセルのお知らせがAmazonから来たぞ……
    ッて、おまえらもか……一体、どの方面からの圧力が……心当たりがありすぎて分からん 


■_

■_ 2.11 → 4.0.0

256倍本に AWKを256倍使うための本 (Ascii 256倍)
AWKを256倍使うための本 (Ascii 256倍) というのがありまして。 かなり古い本なのですが、今でも簡単に手に入ります (そこそこ売れているらしい) が、 この本で使っているgawkから現在までにかなりの変更点があります。

256倍本で使っているのはこの辺のものです。 jgawk MSDOS用実行形式の詳細情報 : Vector ソフトを探す! gawkの詳細情報 : Vector ソフトを探す! go32版というのもありますが、ここではスルー(知らない人の方が多いだろうなあ)。

といいうわけで ChangeLog から ↑あたりから最新の4.0.0までの機能追加や重要な変更と思われるところを抜き出してみました。


Changes from 2.11.1 to 2.12
-----------------------------

Added support for FIELDWIDTHS.

固定長のフィールドを扱うための特殊変数 FIELDWIDTHS の追加。

AAAAABBBBBCCCCCDDDDDEEEE
XXXXX11111YYYYY22222ZZZZ

↑のような行が並んでいるときに、各フィールドの長さを指定することで
それを使ったフィールド分割を行わせる
substr を自前で連発しないでOK。

Deprecated -a and -e options -- they will go away in the next release, but for now they
cause a warning.

どちらも正規表現の指定。
-a は awk の正規表現、-e は egrep の正規表現を使用するように指定する
#POSIXではこの二つは同じものになるはずなので意味がない。


Moved -C, -V, -c options to -W ala posix.
-C -V -c という一文字オプションが、-W オプションの一項目に変更された
処理系独自のオプションは -Wほげ 形式で追加しましょうというヤクソク。

Added -W posix option: throw out \x
Added -W lint option.


Changes from 2.12 to 2.12.1
-----------------------------

Treat IGNORECASE specially, simplifying a lot of code, and allowing checking against
strict conformance only on setting it, rather than on each pattern match.

正規表現動作について大小文字の違いを無視させる特殊変数 IGNORECASE


Changes from 2.14 to 2.15
---------------------------

Command-line source can now be mixed with library functions.

   gawk -f library.awk '{....}'

みたいなことが可能に。
それまでは、同時にこれら二つを使用するのは許されていなかった

ARGIND variable tracks index in ARGV of FILENAME.

ARGIND は現在処理しているARGV要素の添え字が入っている特殊変数
ARGV[ARGIND] の値は FILENAME と同じ。

GNU style long options in addition to short options.

GNUスタイル →  -- で始まる長い形式のサポート。

Plan 9 style special files interpreted by gawk:
        /dev/pid
        /dev/ppid
        /dev/pgrpid
        /dev/user
                $1 = getuid
                $2 = geteuid
                $3 = getgid
                $4 = getegid
                $5 ... $NF = getgroups if supported

ERRNO variable contains error string if getline or close fails.
特殊変数 ERRNO
エラー情報が格納される

Very old options -a and -e have gone away.

Changes from 2.15.5 to 2.15.6
-----------------------------

If FS is "", gawk behaves like mawk and nawk, making the whole record be $1.
Yet Another Dark Corner. Sigh (field.c:def_parse_field).

??
この文章は FS が "" のときにレコード全体が $1 に格納されるように書かれていますが、
mawk はこの時点からそういった場合には一文字がひとつのフィールドになるように分割する
と思うんだけどなあ。


Regexp fixes:
	/./ now matches a newline (regex.h)
	^ and $ match beginning and end of string only, not any embedded newlines (re.c)

        . が改行にもマッチするようになった
        ^ と $ がそれぞれ文字列の先頭と末尾にのみマッチするようになった
        (文字列中にある改行には影響されない)

ひとつのレコードが複数行になる場合に注意すべき変更点。

Changes from 2.15.6 to 3.0.0
----------------------------

New --re-interval option to turn on interval expressions. They're off by default, except
for --posix, to avoid breaking old programs.

  foo{1,3} 形式の正規表現を有効にする --re-interval オプションの追加。
  --posix でも有効になる

Passing regexp constants as parameters to user defined functions now generates a lint warning.

ユーザー定義関数の引数に対して foo(/bar/, hoge) のように 正規表現定数 をわたしたときに警告

Handling of \ in sub and gsub rationalized (somewhat, see the manual for the gory [and I do mean gory] details).

sub や gsub の置換テキスト部に置かれた \ の解釈はいろいろ面倒なのでこの辺も注意が必要。
このバージョン以降のものであれば、マニュアルに動作が明記されているはず。

IGNORECASE now uses ISO 8859-1 Latin-1 instead of straight ASCII. See the
source for how to revert to pure ASCII.

IGNORECASE を使って大小文字の違いを無視させたときの話。
locale はいろいろ面倒。

New gensub function added. See the manual.

置換した結果を返す gensub 関数の追加。
sub や gsubは、「行われた置換の回数」を返していた。


--traditional option added as new preferred name for --compat, in keeping with GCC.

--lint-old option added, so that warnings about things not in old awk are only given if explicitly asked for.

オプション追加。

`next file' has changed to one word, `nextfile'. `next file' is still accepted but generates
a lint warning. `next file' will go away eventually.
現在処理しているファイルからの読み込みを打ち切り、次のファイルへ切り替えるための
予約語が、'next file' という空白を含んだ二語のものから 'nextfile' に変わった。

Gawk now uses POSIX regexps + GNU regex ops by default. --posix goes to pure posix regexps,
and --compat goes to traditional Unix regexps. However, interval expressions, even though
specified by POSIX, are turned off by default, to avoid breaking old code.

正規表現のメタ文字の話。
この辺もまあきちんと書くとそれなりの分量に。
が、ここで言っている GNU regex ops はたぶん知る人も少ないので気にしないでもおそらく大丈夫。
# \y とか \' ね。

IGNORECASE now applies to string comparison as well as regexp operations.

IGNORCASEが正規表現マッチングだけでなく文字列比較にも影響するように

The AT&T Bell Labs Research awk fflush builtin function is now supported.
fflush is extended to flush stdout if no arg and everything if given
the null string as an argument.

AT&T Bell研版 awk (one true awk) にあった組み込み関数 fflush をサポート
fflush() とか fflush("")とすると、標準出力を fflush する。


If RS is more than one character, it is treated as a regular expression and records are
delimited accordingly.  The variable RT is set to the record terminator string. This is
disabled in compatibility mode.

RSに二文字以上の文字列を設定すると、それを正規表現として解釈。
実際にレコードを分割することになったマッチ文字列が RT に格納される。


If FS is set to the null string (or the third arg. of split() is the null string),
splitting is done at every single character. This is disabled in compatibility mode.

FS に空文字列がセットされていたとき、あるいは split() の第三引数に空文字列を
渡したときに、文字ごとに分割する。


Changes from 3.0.6 to 3.1.0
---------------------------

1. A new PROCINFO array provides info about the process. The non-I/O /dev/xxx
   files are now obsolete, and their use always generates a warning.

   特殊配列変数 PROCINFO の追加。

2. A new `mktime' builtin function was added for creating time stamps. The `mktime'
   function written in awk was removed from the user's guide.

   組み込み関数 mktime の追加。

3. New `--gen-po' option creates GNU gettext .po files for strings marked with a leading underscore.

   メッセージ文字列のローカライズ向け機能

4. Gawk now completely interprets special file names internally, ignoring the existence
   of real /dev/stdin, /dev/stdout files, etc.

   これまではシステムにそのまま投げていたので、DOS(Windows)向けには注意が必要でした
    > /dev/stdin やら
   jgawk や gawk+mb だとその辺も考慮されています。

6. The BINMODE variable is new; on non-UNIX systems it affects how gawk opens files for
   text vs. binary.

   特殊変数 BINMODE の追加
   この変数のハンドリングはちょくちょくバグってたので、注意が必要。

8. Gawk no longer supports `next file' as two words.

15. It is now possible to open a two-way pipe via the `|&' operator.
    See the discussion in the manual about putting `sort' into such a pipeline,
    though.  (NOTE!  This is borrowed from ksh: it is not the same as
    the same operator in csh!)

    子プロセスと双方向でデータをやり取りするためのパイプ記法。
    これでデータを sort でソートさせた結果を取り込んでさらに処理するなんてことが
    できるように。

16. The `close' function now takes an optional second string argument
    that allows closing one or the other end of the two-way pipe to
    a co-process.  This is needed to use `sort' in a co-process, see
    the doc.

    close が省略可能な第二引数を受け付けるようになった。
    双方向パイプの片方だけをクローズするときに使用する。

17. If TCP/IP is available, special file names beginning with `/inet'
    can be used with `|&' for IPC. Thanks to Juergen Kahrs for the initial
    code.

    ネットワーク機能。これも細かい解説をすると結構大変なので略。


19. Unrecognized escapes, such as "\q" now always generate a warning.
    未定義のエスケープシーケンスに対して警告するように

20. The LINT variable is new; it provides dynamic control over the --lint option.
    特殊変数 LINTの追加

21. Lint warnings can be made fatal by using --lint=fatal or `LINT = "fatal"'.
    Use this if you're really serious about portable code.

    lint チェックに引っかかったときにそれをfatal errorにできるように。

24. It is now possible to dynamically add builtin functions on systems
    that support dlopen. This facility is not (yet) as portable or well
    integrated as it might be.  *** WARNING *** THIS FEATURE WILL EVOLVE!

    動的リンクによる組み込み関数追加機能のサポート

26. Profiling has been added!  A separate version of gawk, named pgawk, is
    built and generates a run-time execution profile.  The --profile option
    can be used to change the default output file.   In regular gawk, this
    option pretty-prints the parse tree.

    プロファイル機能の追加。

28. New `asort' function for sorting arrays.  See the doc for details.

    配列を要素の値でソートする関数 asort の追加

29. The match function takes an optional array third argument to hold
    the text matched by parenthesized sub-expressions.

    match 関数の拡張。
    () でキャプチャした文字列を格納する引数を指定できるように。
    match("..". /(..)(..)/, data)
    のようにすると、
    \1 が data[1] に、\2 が data[2] に入る。
    全体は data[0] に。

30. The bit op functions and octal and hex source code constants are on by default, no longer
    a configure-time option.  Recognition of non-decimal data is now enabled at runtime with
    --non-decimal-data command line option.

    ビット操作の関数や八進定数、十六進定数がデフォルト設定のビルドで有効に。
    後者は実行時に --non-decimal-data オプションを指定する必要あり。


34. The new option --dump-variables dumps a list of all global variables and
    their final types and values to a file you give, or to `awkvars.out'.


Changes from 3.1.0 to 3.1.1
---------------------------

12. Multi-byte character support has been added, courtesy of IBM Japan.
j ではないマルチバイト対応。
IBM(当時)の金子さんによる。



Changes from 3.1.1 to 3.1.2
---------------------------

6. Completely new version of the full GNU regex engine now in place.

   正規表現エンジンの切り替え (GNU regex 0.12 → glibc)

11. As a result of #6, removed the use of the dfa code from GNU grep.
    ** →3.1.4 で復活

15. Grammar and scanner cleaned up, courtesy of Stepen Kasal, to hopefully
    once and for all fix the `/=' operator vs. `/=.../' regex ambiguity.
    Lots of other grammar simplifications applied, as well.

    /= 演算子と /=.../ という正規表現を混同することがあったのが解消された。

22. IGNORECASE no longer affects single-character field splitting (FS = "c"),
    or single-character record splitting (RS = "c").

    This cleans up some weird behavior, and makes gawk better match the
    documentation, which says it only affects regex-based field splitting
    and record splitting.

    The documentation on this was improved, too.


27. `match' now adds more entries to 3rd array arg:
	match("the big dog", /([a-z]+) ([a-z]+) ([a-z]+)/, data) fills in variables:
    	data[1, "start"], data[1, "length"], and so on.

matchの拡張
上記の第三引数 data を例にとると
data[1, "start"]   → \1 の開始位置
data[1, "length"]  → \1 の長さ
data[2, "start"]   → \2 の開始位置
data[2, "length"]  → \2 の長さ

data[1], data[2] なんかは以前と同じ。

28. New `asorti' function with same interface as `asort', but sorts indices
    instead of values.

    連想配列の「添え字」(key) でソートを行う関数 asorti の追加。
    使い方は asort と同じ。


Changes from 3.1.2 to 3.1.3
---------------------------

1. Gawk now follows POSIX in handling of local numeric formats for input, output and
   number/string conversions.

    locale 関連の頭痛の種がまたひとつ。
    日本語環境では多分引っかからないので詳しい説明は割愛>落とし穴。

8. C-style switch statements are available, but must be enabled at compile time via
   `configure --enable-switch'.  For 3.2 they'll be enabled by default. Thanks to
   Michael Benzinger for the initial code.

   ビルド時に指定していれば、C 形式の switch-case が使えるように!


Changes from 3.1.3 to 3.1.4
---------------------------

2. Gawk now supports the ' flag in printf. E.g., %'d in a locale with thousands separators
   includes the thousands separator in the value, e.g. 12,345.

   This has one problem; the ' flag is next to impossible to use on the
   command line, without major quoting games.  Oh well, TANSTAAFL.

   カンマによる三桁区切りなんかをやってくれるフラグ。
   これもリビジョンごとにバグが再発してたりしたので注意が必要。たぶん。

3. The dfa code has been reinstated; the performance degradation was just too awful.  Sigh.
   (For fun, use `export GAWK_NO_DFA=1' to see the difference.)

7. When --posix is in effect, sub/gsub now follow the 2001 POSIX behavior.
   Yippee.  This is even documented in the manual.

   たぶんこの違いが問題になることはない。んじゃないかなあ。
   #実は変更点を良く知らない。


Changes from 3.1.4 to 3.1.5
---------------------------

2. A new option, `--exec' has been added. It's like -f but ends option
   processing.  It also disables `x=y' variable assignments, but not -v.
   It's needed mainly for CGI scripts, so that source code can't be
   passed in as part of the URL.

   --exec オプションの追加。
    ふつうの人は多分これが必要になることはない。んじゃないかなあ。

3. dfa.[ch] have been synced with GNU grep development.  This also fixes
   multiple regex matching problems in multibyte locales.

*8. Gawk is now multibyte aware.  This means that index(), length(), substr() and match()
    all work in terms of characters, not bytes.
    index()やらlength()やらの「文字列関数」が「バイト単位」ではなく「文字単位」で
    動作するように。
    この変更は超重要!

15. length(array) now returns the number of elements in the array.  This is
    is a non-standard extension that will fail in POSIX mode.

    lengthの引数に配列を渡すと、その配列の要素数を返すように。
    非標準機能なので、POSIX モードでは無効。


 
Changes from 3.1.5 to 3.1.6
---------------------------

2. Too many people the world over have complained about gawk's use of the
   locale's decimal point for parsing input data instead of the traditional
   period.  So, even though gawk was being nicely standards-compliant, in
   a Triumph For The Users, gawk now only uses the locale's decimal point
   if --posix is supplied or if POSIXLY_CORRECT is set.  It is the sincere
   hope that this change will eliminate this FAQ from being asked.

   locale 問題でいろいろ。


5. Problems with wide strings in non "C" locales have been straightened out everywhere.  (At least, we think so.)

9. There are additional --lint-old warnings.

10. Gawk now uses getaddrinfo(3) to look up names and IP addresses. This
    allows the use of an IPv6 format address and paves the way for
    eventual addition of `/inet6/...' and `/inet4/...' hostnames.

    IPv6 対応?

13. Gawk now converts "+inf", "-inf", "+nan" and "-nan" into the corresponding
    magic IEEE floating point values. Only those strings (case independent)
    work.  With --posix, gawk calls the system strtod directly. You asked
    for it, you got it, you deal with it.

17. The strftime() function now accepts an optional third argument, which
    if non-zero or non-null, indicates that the time should be formatted
    as UTC instead of as local time.

    strftime が省略可能な第三引数を受け付けるように。
    第三引数が non-zerod だと UTC を使って文字列化する


20. A new option, --use-lc-numeric, forces use of the locale's decimal
    point without the rest of the draconian restrictions imposed by
    --posix. This softens somewhat the stance taken in item #2.

21. Everything relevant has been updated to the GPL 3.


Changes from 3.1.6 to 3.1.7
---------------------------

2. Gawk now handles multibyte strings better in [s]printf with field widths and such.


4. The handling of BINMODE is now somewhat more sane.

5. A getline from a directory is no longer fatal; instead it returns -1.

6. Per POSIX, special variable names (like FS) cannot be used as function parameter names.

7. The new -O / --optimize option enables simple constant folding on
   the parse tree during parsing.  We hope that with time the number
   of optimizations will increase.


 
Changes from 3.1.7 to 3.1.8
---------------------------
1. The zero flag no longer applies to %c and %s; apparently the standards
   changed at some point.


3. Failure to open a socket is no longer a fatal error.

4. dfa.h and dfa.c are now more-or-less in sync with GNU grep, for the first
   time in many years.


6. The ' flag (%'d) is now just ignored on systems that can't support it.

7. Lots of bug fixes, see the ChangeLog.

Changes from 3.1.8 to 4.0.0
---------------------------

1. The special files /dev/pid, /dev/ppid, /dev/pgrpid and /dev/user are
   now completely gone. Use PROCINFO instead.

   /dev/なんとか な特殊ファイルは全部なくなったので、PROCINFO 配列を代わりに使いましょう。

2. The POSIX 2008 behavior for `sub' and `gsub' are now the default.
   THIS CHANGES BEHAVIOR!!!!

3. The \s and \S escape sequences are now recognized in regular expressions.

4. The split() function accepts an optional fourth argument which is an array
   to hold the values of the separators.

5. The new -b / --characters-as-bytes option means "hands off my data"; gawk
   won't try to treat input as a multibyte string.

6. There is a new --sandbox option; see the doc.

7. Indirect function calls are now available.
   関数の間接呼び出し!

8. Interval expressions are now part of default regular expressions for GNU Awk syntax.
   x{1,4} な正規表現がデフォルトで有効に

10. switch / case is now enabled by default. There's no longer a need
    for a configure-time option.
    switch 文がデフォルトで有効に。

11. Gawk now supports BEGINFILE and ENDFILE. See the doc for details.
    BEGINFILE と ENDFILE というそれぞれファイルの先頭、末尾で実行される
    パターンの追加(ファイルごとのBEGIN/ENDみたいなもん)。

13. The new FPAT variable allows you to specify a regexp that matches
    the fields, instead of matching the field separator. The new patsplit()
    function gives the same capability for splitting.

    特殊変数FPATの追加。
    組み込み関数 patsplit() の追加

15. Support for IPv6 is added via the /inet6/... special file. /inet4/...
    forces IPv4 and /inet chooses the system default (probably IPv4).

17. Merged with John Haque's byte code internals. Adds dgawk debugger and
    possibly improved performance.

    バイトコード化。

21. Arrays of arrays added. See the doc.

    配列の配列が使えるように

23. In POSIX mode, string comparisons use strcoll/wcscoll.
    THIS CHANGES BEHAVIOR!!!!

    locale に注意。

25. Gawk now treats ranges of the form [d-h] as if they were in the C
    locale, no matter what kind of regexp is being used, and even if
    --posix.  The latest POSIX standard allows this, and the documentation
    has been updated.  Maybe this will stop all the questions about
    [a-z] matching uppercase letters.
    THIS CHANGES BEHAVIOR!!!!

    locale 問題はこれで決着?

26. PROCINFO["strftime"] now holds the default format for strftime().
    PROCINFO["strftime"] に strftime() のデフォルト書式を格納するように

29. If PROCINFO["sorted_in"] exists, for(iggy in foo) loops sort the
    indices before looping over them.  The value of this element
    provides control over how the indices are sorted before the loop
    traversal starts. See the manual.

    PROCINFO["sorted_in"] が存在している場合、for(iggy in foo) 形式のループで
    添え字をソートしてから繰り返しを行う。格納されている値がソートをどのように
    行うかを指示する。
    PROCINFOの詳細はマニュアルを。

30. A new isarray() function exists to distinguish if an item is an array
    or not, to make it possible to traverse multidimensional arrays.

    変数が配列かどうかを判定する isarray() の追加

31. asort() and asorti() take a third argument specifying how to sort.
    See the doc.

    asort() と asorti() で並び順を指定する省略可能な第三引数の追加

2011年08月09日

■_

やるきーぜろー

イブニングでしばちゅーさんをチェック。

■_ Do people lose interest in programming as they age?

Kent Beck がある質問に回答を。

Do people lose interest in programming as they age? - Quora

Do people lose interest in programming as they age?
人は年をとるとプログラミングに対する興味を失うだろうか?

Some younger programmers expect that older programmers are slower, make more mistakes, and
would rather be doing something else such as managing programmers. Are they right to think so?

若いプログラマーの中には、年嵩(としかさ)のプログラマーがのろまで、よくミスをして、
プログラマーの管理のような他のことをするようになると expect しています。
彼らのこういった考えは正しいのでしょうか?


Kent Beck, Husband, father, programmer, goat far...

I'm 50, which seems like aging to me.

The question as stated is incorrect. I do not make more errors now than I used to, I make
different errors. My memory is much worse than it used to be & my cognition is also a
step slower (in part, I suspect, because of my memory deterioration). However, I make fewer
errors of arrogance and fewer errors because of panic. After 35 years of programming and
raising 5 children, it's hard to rattle me.

I have noticed that my capacity for novelty has diminished as I have aged. The number of new
things I could tackle in a unit of time is maybe a third of what it used to be.

As to the rest of the question, I am not the least bit interested in managing programmers
and there is nothing I would rather be doing than programming.

I'm curious about why the question was asked. A young guy trying to figure out the old farts
around him? An old fart trying to figure out if he is alone? I'm half tempted to start a
Geezer Geek conference to address the concerns of the aging programmer.

ネタ元は例によってreddit→ Kent Beck's answer to Do people lose interest in programming as they age? : programming

■_

昨日あたり目立った 「起業して安定した収入を得る!」まずはそのふざけた幻想をぶち殺す!! - Diary of Dary ではなく、同じ方のちょっと前のエントリが気になった。

「見習いプログラマが読んだら、すぐにジョブレベルが上がる10冊」が酷いと思った理由とか - Diary of Dary こっち。

多分、これだけを考えた癖にタイトルで「見習いプログラマが読んだら、すぐにジョブレベルが
上がる10冊」とか言ってるから駄目なんだろうなと。ちゃんとタイトルを「自分が読んで良か
った本 10 冊」とかにするべき。

そうなると初心者に勧める本の紹介は、ちゃんと客観的に何故初心者にお勧めなのか書かないと
その人の主観になるので、その個人の信用がそのままオススメ度になるわけで、まあ糞本を薦め
てるような奴が勧める本とか推して知るべしとか。

  

同感だなあ。 時折り、「~の n 冊」のようなエントリがたちますけど(特に休み前とか)、 人目を引くキャプションつけて とにかくリストアップしときゃあいいだろうという雰囲気が感じられるのが目立つ気がします。

人のことは言えませんけどねw

■_ 部分適用 != カリー化

boxing/unboxing の boxing を「ボックス化」と訳すのはまずいと思うんだけど currying はどうなんすかね。

The Uncarved Blog: Partial Function Application is not Currying

Partial Function Application is not Currying

These two related concepts are often confused. Until yesterday I thought they were the 
same thing myself.

これら二つの関連するコンセプトはしばしば混乱を招いています。
昨日までわたし自身もこれらが同じものであると考えていたのです。

Often you will see in computer books and articles a pattern where a function is 
applied to some but not all of it's required arguments, resulting in a function of 
fewer arguments. In python, this looks like this (from PEP 309):

コンピューターに関する書籍やアーティクルで、
必要な引数のすべてを与えていないで呼び出されている関数がその結果としてより少ない
引数を取る関数を返すというものを良く見かけることでしょう。
Python では、それは次のようなものです (PEP 309より):


  def papply(fn, *cargs, **ckwargs):
      def call_fn(*fargs, **fkwargs):
          d = ckwargs.copy()
          d.update(fkwargs)
          return fn(*(cargs + fargs), **d)
      return call_fn

This is called "partial function application" - it returns a function which 
acts like the function you pass in but which takes fewer arguments, the others having 
been "bound in". The author of this code, however, had the (very common) 
misconception that this is currying, and called his function "curry" as a 
result. I shared this misconception for some time, and thought that currying and 
partial application were the same thing. In fact they are to certain extent opposites.

これは“関数の部分適用”と呼ばれているもので、渡した関数のように振舞うけれども
受け取る引数の数が少ない(一部の引数を“束縛”している)関数を返します。
しかしこのコードの書き手は、これを(非常によくありがちなことなのですが)
カリー化と勘違いしていました。そして関数を "curry" という名前にしてしまったのです。
しばらくの間わたしも同様の勘違いをしていて、カリー化と部分適用が同じものであると考えていました。
実際には、それらは一部の点においては反対のものであったのです。

Where partial application takes a function and from it builds a function which takes fewer
arguments, currying builds functions which take multiple arguments by composition of
functions which each take a single argument. Thus we curry in python like this:

部分適用が関数を引数にとってそこから元よりも少ない引数をとる関数を組み立てるのに対し、
カリー化は引数を一つだけとる関数を合成して複数の引数をとる関数を構築します。
したがって、curry はpython では次のようになります:

  def addN(n):
      return lambda x: x + n

  def plus(a, b):
      addA=addN(a)
      return addA(b)

Now why would we ever want to do that? Well, in some pure functional languages this is 
exactly how functions with multiple arguments are built up. In ocaml, a function which 
takes two ints and returns a float is actually a function which takes an int and 
returns a function which takes an int and returns a float. In this world, partial 
application just happens without any extra code:

さて、なぜわたしたちはこういったことをしたいと望むのでしょうか?
実は一部の純粋な関数型の言語では、これは正しく複数の引数をとる関数を構築する手順なのです。
OCaml では、ふたつの int を引数にとり float を返す関数は、
実際にはint を引数にとって int を引数にとり float を返す関数を返す関数なのです。
この環境では、部分適用は一切の extra code なしに起きることです:

  % rlwrap ocaml
      Objective Caml version 3.09.3

  # let add a b=a+b;;
  val add : int -> int -> int = <fun>

So the type of add is a function which takes an int and returns a function which takes 
an int and returns an int.

この add の型は、int の引数をとってint を引数にとり int を返す関数を返す関数です。

# let add2=add 2;; 
val add2 : int -> int = <fun>

add is a curried function, so here we can partially apply by just calling with a 
single arg- it returns the function that takes the other arg and returns the result.

add はカリー化された関数なので引数を一つだけ渡して呼び出すだけで部分的な適用ができます。
そしてそれは、そのほかの引数をとり結果を返す関数を返します。


  # add2 34;;
  - : int = 36

...and we can call add2 with a single argument as you would expect. Because ocaml curries add
for us, the function has been partially applied. It's interesting to note that in ocaml if
you label your function arguments, they can be partially applied in any order.

...and we can call add2 with a single argument as you would expect.
add2 を呼び出せます
一つだけ引数を与えて

OCaml は add をカリー化してくれるのでこの関数は部分適用されたのです。
It's interesting to note that in ocaml if you label your function arguments,
they can be partially applied in any order.


■_

2011年08月08日

■_

読みたい
Amazon.co.jp: スマート・プライシング 利益を生み出す新価格戦略: ジャグモハン・ラジュー, Z・ジョン・チャン, 藤井清美: 本
が、(住んでいる地域の)図書館にない。 買ってもいいんだけど一回読んで終わりっぽいんで、今このタイミングではなあ (と悩みつつ忘れてしまう流れ)。

新刊情報
今まで気がつかなかったのだけど(なぜか更新停止付近の日付のデータを見ていなかったっぽい) IT Books 刊行スケジュール: 更新停止のお知らせ あらら更新停止。 んーむ重宝してたんだけどなあ。 ほかにあるかなあ。有料でもいいんだけど(といいつつもあまり出せないけど)。

BOX 三つ
SFアニメ「太陽の牙ダグラム」を全3巻で再びDVD-BOX化 :おた☆スケ さすがに70話以上あると三つか。 興味はあるけど、この値段でそろえるだけの余裕があるかというと…

■_

横浜ベイスターズ - グッズに関するニュース


横浜ベイスターズの隠れた人気マスコットキャラクター『ブラックホッシー』が、今年6月から
販売中の自身がデザインされたTシャツ&タオルマフラーを「横浜スタジアムで、ご購入された
方」に限り直筆サインをします!

(略)

ぜひこの機会にハマスタへご来場いただき、ブラックホッシーグッズを購入し、直筆サインを
Get!してください!!!

ただし非常に自由気ままなキャラのため、ブラックホッシーがいつまでグッズショップにいるか
は、分かりません……(笑)


【日 時】
8月10日、11日(水、木) 読売ジャイアンツ戦(18:00試合開始)
販売促進時間:開門 ~ 閉門まで
※ブラックホッシーの気持ち次第(!?)で、変更になる可能性もあります


【場 所】
横浜スタジアム 球場内グッズ販売所(一塁側3ゲート横、球場内11通路前)


うは。欲しいw

■_ 将来の Perl 5

以前からも流れてましたが

The future of Perl 5 - Perlbuzz


The future of Perl 5

By Andy Lester on August 7, 2011 10:45 PM

Jesse Vincent, the pumpking for Perl 5, gave a talk at OSCON called "Perl 5.16 
and beyond" where he lays out the future of Perl 5. The slides are up on 
slideshare, and they're well worth reading. I haven't read perl5-porters, the Perl 5 
maintainers' mailing list, in a few years, and Jesse's slides are an eye-opener to the 
trials and tribulations of keeping Perl 5 usable in legacy situations but moving 
forward with new innovations.

The pumpking is sort of the project leader for Perl 5, and arbiter of what gets 
committed into the source tree. The pumpking also used to be the person who created 
the releases, but as Jesse points out below, this responsibility has been delegated to 
others. The term "pumpking" comes from the holder of the patch pumpkin.

Key points from the slides:

    * Perl 5 is now on a regular release schedule, where releases are made based on the
      calendar, not some critical mass of changes.

    * The dual track of odd numbers (5.13.x) for development releases and even numbers 
      (5.14.x) for production releases continues.

    * Although Perl 5.14.1 is current production, 5.12.4 and 5.15.0 have recently been 
      released as well.

    * Releases used to take three weeks for a single pumpking to do. Now it's a documented
      process that takes only a few hours. Releases are done by rotating volunteer release
      engineers. Per Larry, the time of hero pumpkings is over.

    * As Perl 5 changes much more quickly, we need to be able to recover from mistakes. Perl
      should have sane defaults. Perl 5 should run everywhere: Every OS, every browser,
      every phone.

    * Forward changes should not break older code. Programmers shouldn't have to build
      defensive code to protect against future changes to Perl 5.

      将来行われる変更が従来のコードを動かなくさせるべきではない。
      プログラマーは build defensive なコードを書かずにすむようにすべき。

    * The Perl runtime needs to slim down. Old modules are getting yanked from core and
      moved to CPAN. Not deprecating, but decoupling. We need to release a version of the
      Perl core that contains all the stuff we've yanked out of the "slim" core
      distribution.

      必要なランタイムを軽量化する。古いモジュールはコアから取り除いてCPANへ移す。

    * The test suite needs to be split into three types of tests: language, bug-fix and
      implementation.

      test suite は三つに分割する必要がある

    * Jesse wants saner defaults in the future, to make Perl 5 cleaner, simpler and easier
      to work with:

          o warnings on
            警告を有効に

          o autodie-esque behavior

          o throwing exceptions rather than returning on failure
            失敗を返すのではなく例外を投げる

          o 1-arg and 2-arg open gone
            一引数や二引数の open をなくす

          o Latin-1 autopromote off
          o utf-8 autopromote on
            UTF-8 寄りに

          o Basic classes and methods

          o No indirect object syntax

    * How to make this happen faster? Donate to the Perl 5 Core Maintenance Fund.

I couldn't attend Jesse's talk because I was speaking about community and project management with Github in the same time slot, so if video exists I'd love to see it. And thanks very much to Jesse and the rest of p5p for keeping Perl 5 so amazing.


This blog is licensed under a Creative Commons License.

■_

■_

この辺後でチェック

http://www.reddit.com/r/programming/comments/jc021/the_demise_of_the_low_level_programmer/
http://www.reddit.com/r/programming/comments/jbxcg/oscon_2011_a_retrospective/
http://www.reddit.com/r/programming/comments/jboo2/kent_becks_answer_to_do_people_lose_interest_in/
http://www.quora.com/Do-people-lose-interest-in-programming-as-they-age/answer/Kent-Beck?srid=pRa
http://www.reddit.com/r/programming/comments/jbln2/an_invitation_for_kids_to_learn_programming/
http://cdsmith.wordpress.com/2011/08/07/an-invitation-for-kids-to-learn-programming/
http://www.reddit.com/r/programming/comments/jbigx/jython_vs_cpython/
http://www.reddit.com/r/programming/comments/jbgbp/an_inspiring_and_amazing_talk_about_the_future_of/

■_

おかしいな、特に用事があったわけでもないのに(夏休みちう) なんでこんなに時間が足りない感にあふれているんだろう。

時間の使い方が下手? ごもっとも ○| ̄|_

2011年08月07日

■_

揺れる想い
わずか200gのナノ一眼「PENTAX Q」徹底解剖--第1回:ファーストインプレッション - CNET Japan 【ナノ一眼】 PENTAX Q Part-12 【ミラーレス】 [chaika] まあレンズが揃ってない(手持ちのレンズが使えるわけがない)のにって話もあるし、 新たに揃えたらいくらかかるやら。で。

高木豊
息子三人、全員サッカーやってて、しかも Jクラブに行ったりとかユースにいるとかすごいのねー。 長所を伸ばすよりも欠点を無くすほうが先という方針には 全面的には賛成できないけど(たとえばライオンズの中村のような例がある)、 三兄弟にはぴったりはまったというところなのかなあ。 などとニッカンスポーツの記事を読んで思ったり。

■_ エスパー能力を発揮してみる

例によって丸投げ

プログラミングについて | OKWave

次の問題と似た問題が試験で出るのですがまず例となる問題の答えにどうしてもたどりつけません
どなたか教えてくださいお願いします。

逆ポーランド記法による完全な整数電卓を作成すること仕様は以下の通り

INで逆ポーランド記法入力をする
OUTで結果を入力する
数値は複数桁対応(3桁まででよい)
数値と数値の間は1つ以上のスペースで区切られる
乗算は、シフト命令をうまくかうこと
除算は、商だけでよい
スタック、サブルーチンをうまく活用すること
たとえば、文字列を数値に変換する部分や、各演算部分をサブルーチン化するシュミレータによる動作確認をすること

ANo.2

まずは、どうして「たどりつけない」のか
あなたが「できること」と「できないこと」をまとめましょう。そうすれば、何を勉強しなおせ
ばいいかはっきりするはずです。質問するときもピンポイントでできるし、答える方も楽です。

それに、教えようにも、不明な点が多すぎて無理です。
・これをどんな言語で作れと?何の指定もなければ Forth を使いますよ?
・IN,OUTって何?
・「乗算は、シフト命令を」って、乗算は普通にできないの?(となるとアセンブリ?)

Copyright © OKWave. All rights reserved.

これ、CASL-II じゃないかなあ。 IN,OUTって入出力マクロの名前でそんなのがあった覚えがあるし、 乗除算命令もないと。

■_

■_ UTF-8

redditで見かけたやりとり。 回答のひとつにおもしろいものがあったのでそこだけ。

utf 8 - why is there so much overhead when we decide to use UTF-8 for characters outside the 1-127 range? - Stack Overflow

why is there so much overhead when we decide to use UTF-8 for characters outside the 1-127 range?


The answer is that in UTF-8, ASCII is just 1 byte, but that in general, most Western languages
including English use a few characters here and there that require 2 bytes, so actual
percentages vary. The Greek and Cyrillic languages all require at least 2 bytes per character
in their script when encoded in UTF-8.

Common Eastern langauges require for their characters 3 bytes in UTF-8 but 2 in UTF-16. Note
however that “uncommon” Eastern characters require 4 bytes in both UTF-8 and UTF-16 alike.

3 is indeed only 50% greater than 2. But that is for a single code point only. It does not
apply to an entire file.

The actual percentage is impossible to state with precision, because you do not know whether
the balance of code points down in the 1- or 2-byte UTF-8 range, or in the 4-byte UTF-8 range.
If there is white space in the Asian text, then that is only byte of UTF-8, and yet it is a
costly 2 bytes of UTF-16.

These things do vary. You can only get precise numbers on precise text, not on general text.
Code points in Asian text take 1, 2, 3, or 4 bytes of UTF-8, while in UTF-16 they variously
require 2 or 4 bytes apiece.

Case Study

Compare the various languages' Wikipedia pages on Tokyo to see what I mean. Even in Eastern
languages, there is still plenty of ASCII going on. This alone makes your figures fluctuate.
Consider:

Paras Lines Words Graphs Chars  UTF16 UTF8   8:16 16:8  Language

 519  1525  6300  43120 43147  86296 44023   51% 196%  English
 343   728  1202   8623  8650  17302  9173   53% 189%  Welsh
 541  1722  9013  57377 57404 114810 59345   52% 193%  Spanish
 529  1712  9690  63871 63898 127798 67016   52% 191%  French
 321   837  2442  18999 19026  38054 21148   56% 180%  Hungarian

 202   464   976   7140  7167  14336 11848   83% 121%  Greek
 348   937  2938  21439 21467  42936 36585   85% 117%  Russian

 355   788   613   6439  6466  12934 13754  106%  94%  Chinese, simplified
 209   419   243   2163  2190   4382  3331   76% 132%  Chinese, traditional
 461  1127  1030  25341 25368  50738 65636  129%  77%  Japanese
 410   925  2955  13942 13969  27940 29561  106%  95%  Korean

Each of those is the Tokyo Wikipedia page saved as text, not as HTML. All text is in 
NFC, not in NFD. The meaning of each of the columns is as follows:

   1. Paras is the number of blankline separated text spans.
   2. Lines is the number of linebreak separated text spans.
   3. Words is the number of whitespace separated text spans.
   4. Graphs is the number of Unicode extended grapheme clusters, sometimes called glyphs. These are user-visible characters.
   5. Chars is the number of Unicode code points. These are, or should be, programmer-visible characters.
   6. UTF16 is how many bytes that takes up when the file is stored as UTF-16.
   7. UTF8 is how many bytes that takes up when the file is stored as UTF-8.
   8. 8:16 is the ratio of UTF-8 size to UTF-16 size, expressed as a percentage.
   9. 16:8 is the ratio of UTF-16 size to UTF-8 size, expressed as a percentage.
  10. Language is which version of the Tokyo page we’re talking about here.

I've grouped the languages into Western Latin, Western non-Latin, and Eastern. Observations:

   1. Western languages that use the Latin script suffer terribly upon conversion from UTF-8
      to UTF-16, with English suffering the most by expanding by 96% and Hungarian the least
      by expanding by 80%. All are huge.
   2. Western languages that do not use the Latin script still suffer, but only 15-20%.

   3. Eastern languages DO NOT SUFFER in UTF-8 the way everyone claims that they do! Behold:
          * In Korean and in (simplified) Chinese, you get only 6% bigger in UTF-8 than in UTF-16.
          * In Japanese, you get only 29% bigger in UTF-8 than in UTF-16.
          * The traditional Chinese actually got smaller in UTF-8 than in UTF-16! In fact, it
            costs 32% to use UTF-16 over UTF-8 for this sample. If you look at the Lines and
            Words columns, it looks that this might be due to white space usage.

I hope that answers your question. There is simply no +50% to +100% size increase for 
Eastern languages when encoded in UTF-8 compared to when these same texts are encoded 
in UTF-16. Only when taking individual code points do you ever see numbers like that, 
which is a completely unreasonable metric.

Eastern languages DO NOT SUFFER in UTF-8 the way everyone claims that they do! か。まあねえ。

■_ 買った

三国志 ④ (バンブーコミックス )
三国志 ④ (バンブーコミックス )
夏侯惇 の描かれ方にちと不満が。 蒼天航路に染まりすぎたか?

2011年08月06日

■_

あとで読む(ちょっとだけ見た) [Journey to Japan #2] The Final RubyKaigi - AkitaOnRails.com

二日目だけ。かな。 Comiket 80

ちぇんごく

x86/x64最適化勉強会1 : ATND かなーり濃い話が行われた模様。 躊躇しないで申し込めばよかったかしらん。

後で読む。その2. SoftwarePatent

■_ モナド

関数型プログラミング言語Haskell Part15 

299 デフォルトの名無しさん [sage] 2011/08/06(土) 12:18:56.22 ID: Be:
    モナドを一言で言うと「本末転倒」 

なんだってー(よくわかってない

■_ 1.6Kg

残念ながらまだわたしは遭遇してません。

推薦図書/必読書のためのスレッド 63

663 デフォルトの名無しさん [sage] 2011/08/01(月) 17:15:21.26 ID: Be:
    ストラウストラップのプログラミング入門
    http://www.seshop.com/product/detail/13444/

    1288ページで¥8,190だから
    このスレ的にはやや安いに分類されるな 

664 デフォルトの名無しさん [sage] 2011/08/01(月) 17:19:23.86 ID: Be:
    この値段で1288ページんてありえないから
    読み物的な内容だろうな。
    著者が沢山いるなら内容のある本だろうが
    普通の本で一人で1288ページはありえないからな。
    クヌースだけはありえたが。 

665 デフォルトの名無しさん [sage] 2011/08/01(月) 17:26:26.56 ID: Be:
    C++の生みの親だし、あり得なくは無いだろうけど。。。

666 デフォルトの名無しさん [sage] 2011/08/01(月) 17:35:51.07 ID: Be:
    まあ実際は編集者が書いたということもありえるからな。 

667 デフォルトの名無しさん [sage] 2011/08/01(月) 17:51:11.27 ID: Be:
    おれは文字がでかいからページが増えたにしとこっと 

668 デフォルトの名無しさん [sage] 2011/08/01(月) 17:59:15.25 ID: Be:
    >>664
    >>369-370 

669 デフォルトの名無しさん [sage] 2011/08/01(月) 20:21:34.43 ID: Be:
    その本はあくまでプログラミングの入門書なんだよな
    でも表紙見るとC++の入門書に見えてしまう
    詐欺じゃね 

670 デフォルトの名無しさん [sage] 2011/08/01(月) 20:49:36.26 ID: Be:
    「本当のプログラミングを体得したい開発者に」なら問題なかったか
    中身は全部やれば中級プログラマって内容で時間と根気のある人向け 

671 デフォルトの名無しさん [sage] 2011/08/01(月) 23:31:27.00 ID: Be:
    1288ページは上司、先輩が
    下の人間に渡して、読み込みが浅い場合
    思いっきりこれで頬をぶん殴るために必要な厚さだと思う 

699 デフォルトの名無しさん [sage] 2011/08/04(木) 21:25:43.78 ID: Be:
    ストラウストラップのプログラミング入門
    重いな
    持ち歩けん 

700 デフォルトの名無しさん [sage] 2011/08/04(木) 21:56:24.29 ID: Be:
    >>699
    その本いいの? 

701 デフォルトの名無しさん [sage] 2011/08/04(木) 22:18:21.66 ID: Be:
    電子書籍化すれば 

702 デフォルトの名無しさん [sage] 2011/08/04(木) 22:24:46.91 ID: Be:
    これですか?
    http://www.amazon.co.jp/dp/4798119598
    # まだ売ってないけど…(発売日: 8/10) 

703 デフォルトの名無しさん [] 2011/08/04(木) 22:33:21.52 ID: Be:
    入門させる気あるのかな 

712 デフォルトの名無しさん [sage] 2011/08/05(金) 19:36:46.80 ID: Be:
    >>702
    一部の書店ではもう売ってる
    普通は手に入んないので原著の評価くらいしか聞けないが
    レビュアーの評価ならここにある
    ttp://d.hatena.ne.jp/faith_and_brave/20110720/1311144650 

714 デフォルトの名無しさん [sage] 2011/08/06(土) 10:53:16.40 ID: Be:
    ストラウストラップのプログラミング入門
    買ってきた。
    全編カラーで見やすい。
    エピステーメーさんがやっただけあって、訳もいい感じ。 

716 デフォルトの名無しさん [sage] 2011/08/06(土) 11:04:12.13 ID: Be:
    >714
    もう売ってるんだ。フラゲ? 

717 デフォルトの名無しさん [sage] 2011/08/06(土) 11:07:19.51 ID: Be:
    1288ページで¥8,190
    ページ単価6.4円
    カラー
    著者がC++の作者
    これ買わんで他に何買うんだよ 

720 デフォルトの名無しさん [sage] 2011/08/06(土) 11:21:51.65 ID: Be:
    価値がカットされた名著 ストラウストラップのプログラミング入門
    http://11017291.at.webry.info/201107/article_1.html 

721 デフォルトの名無しさん [sage] 2011/08/06(土) 12:02:01.88 ID: Be:
    >>720
    余程個人的恨みでもあるのかな 

722 デフォルトの名無しさん [sage] 2011/08/06(土) 12:05:42.35 ID: Be:
    επιστημηの悪評ってそんなに聞かないように思うけどなぁ。
    書籍の記述の個々の問題点は指摘されてるけど、監修が氏によるものだからクソ本、
    というような評価を受けるいわれはないように思うが。

    と思ったがこれかw そのおっさん、自分がダメって評価してるだけだろw
    http://11017291.at.webry.info/201008/article_3.html

    それを「悪名高き人物が監修しているとなると我が社は許可しないであろう。」とか、
    馬鹿か? 

723 デフォルトの名無しさん [sage] 2011/08/06(土) 12:09:16.21 ID: Be:
    名前が読めないって悪評よく聞くけど 

724 デフォルトの名無しさん [sage] 2011/08/06(土) 12:09:52.06 ID: Be:
    「また名前読めねえお監修か」の一行で済むな 

725 デフォルトの名無しさん [sage] 2011/08/06(土) 12:19:40.57 ID: Be:
    > 会社の研修で使用するテキストは内容よりも、執筆者、翻訳者、監修者、出版社の信用度をチェックする。
    > 品質までカット
    1ページも読まずに批判とか頭おかしいんじゃね?少なくともこんなやつ飼ってる会社はどうかしてる。 

726 デフォルトの名無しさん [sage] 2011/08/06(土) 12:22:48.82 ID: Be:
    >>716
    先行販売されてるのを買ってきた

    ttp://twitter.com/junkudo_ike_pc/status/99068680775811072

727 デフォルトの名無しさん [sage] 2011/08/06(土) 12:23:53.16 ID: Be:
    そのオヤジもそのオヤジだが、
    「会社の研修で使用するテキストは内容よりも、執筆者、翻訳者、監修者、出版社の信用度をチェック」
    これが社是なら会社名晒してもらって、全力で回避すべき会社として末永く記憶されるべきレベルだよなw 

728 デフォルトの名無しさん [sage] 2011/08/06(土) 12:36:38.51 ID: Be:
    >>717
    でもC++の入門書ではないんだよな? 

735 デフォルトの名無しさん [sage] 2011/08/06(土) 13:49:40.32 ID: Be:
    目次はどこで見られるんだ? 

741 デフォルトの名無しさん [sage] 2011/08/06(土) 15:18:45.06 ID: Be:
    どっかのおかしい人の脳内悪評はどうでもいいんだけど内容的にはどうなの
    尼の紹介文だと内容がいまいち掴めないんで目次晒してくれると嬉しい
    発売前だとまずかったりするかな 

742 デフォルトの名無しさん [sage] 2011/08/06(土) 15:28:21.73 ID: Be:
    布教用と観賞用と保存用に3冊買ったわ 

743 デフォルトの名無しさん [sage] 2011/08/06(土) 15:57:08.53 ID: Be:
    自分の勉強のためには使わないのか・・・ 

746 デフォルトの名無しさん [sage] 2011/08/06(土) 17:43:04.37 ID: Be:
    ヨドバシだともう置いてある 

747 デフォルトの名無しさん [sage] 2011/08/06(土) 17:44:10.82 ID: Be:
    いや
    高過ぎだろこれ 

750 デフォルトの名無しさん [sage] 2011/08/06(土) 19:54:33.08 ID: Be:
    要するにC++のリファレンスには使えないって事だよね?
    プログラムのコツとかアルゴリズムとかの本なのだろか 

751 デフォルトの名無しさん [sage] 2011/08/06(土) 20:40:35.34 ID: Be:
    なんか哲学よりの印象を受けるんだけど
    実用的ですぐ役立つってのとは違うようだな 

752 デフォルトの名無しさん [sage] 2011/08/06(土) 21:02:22.89 ID: Be:
    でも重要な事は書いてそう
    プログラミング初心者には多分かなり役に立つんじゃないかな
    C++の入門書は別途必要そうだけど 

753 デフォルトの名無しさん [sage] 2011/08/06(土) 22:25:25.48 ID: Be:
    >>745ありがと幅広いね
    個人的には分冊されてても良かったかも 

754 デフォルトの名無しさん [sage] 2011/08/06(土) 22:42:05.58 ID: Be:
    腕力鍛えろよという
    ありがたい配慮だろ 

755 デフォルトの名無しさん [sage] 2011/08/06(土) 22:47:25.77 ID: Be:
    こういうのこそ、さっさと電子化して欲しいんだがな 

んーむ。著者のせいなんですかねえ>「C++の入門書」のように受け取られている。 一時期分冊のように出版社のページにあったような気もするけど(略)な事情かなあ。

誰かこの本を実際に使って入門者に教える講座とかやってみてくれないかなあ (っても大変だろうなあ。かなりの回数になりそうだし)。

■_ ビットを数える

竹迫さんの発表にあったビットを数える話。 x86x64 SSE4.2 POPCNT

1バイトごとにテーブル引いて…という例がありましたが

static const char popTable8bit = {
  0, 1,...
  1, 2,...
  1, 2,...
  2, 3,...
  1, 2,...
  2, 3,..
  2, 3,..
  3, 4, ..  6,7,7,8
};
for (int i = 0; i < n; i++) {
     c += popTable8bit[(uint8)*x++];
}

こんな感じの。

むかーーーーし、「たかがビットを数えるのに256バイト“も”使うな」ということで、 テーブルの大きさを16バイトにしておいて4ビットごとに数え上げる。 なんてことをやりました(本日のムダ知識)。 テーブル引きが2回に増えたり、シフト演算が入ったりしますが それでも256バイト→16バイトに減らせるし、 コードのみで数えるよりは速い。と。

■_ 「非難に屈する」

ついったでTLに流れてきて知ったのですが、なんかこの見出しに違和感が 「SICP が非難に屈している」 - blechmusik2の日記

「屈した」という結果でなしに「屈している」と現在形にしているのは 英語記事の見出しに引きずられたのかなあとも思ったんですが

「SICP が非難に屈している」 - blechmusik2の日記

「SICP が非難に屈している」

SICP を用いた講義がバークレーで途絶えることを嘆いている。

    * /home/vk/misc - SICP is Under Attack
    * Class Textbook and Course Materials Requirements courtesy of Cal Student Store

MITに引き続き、バークレーにおけるプログラミングの入門講義でも使用する言語を Scheme か
ら Python に変えるようだ(講義用テキストは SICP から "Dive into Python" に変
更するとのことである)。使用する言語を変更する理由は MIT のそれと同じなのだろうか*1?

とにかく元記事を読むべと。

/home/vk/misc - SICP is Under Attack (Updated)

SICP is Under Attack (Updated)

It's official. UC Berkeley will soon join MIT and several other universities in 
abandoning Structure and Interpretation of Computer Programs, widely regarded as one 
of the best textbooks in computer science, in favor of alternative material covering 
Python.

This is a mistake.

SICP is revered for its wit, clarity, and brilliance. It expands the mind. It rewards 
creativity. There have even been reports of it inducing paroxysms of joy.

The best thing that can be said about SICP is that it will make you a better programmer.
It discusses crucially important topics like problem decomposition and the performance
implications of various types of procedures. It initiates profound changes in the way
you plan and think about code. Although the text is based on Scheme, its teachings are
timeless and essentially language agnostic.

This is where most of its competition fails.

Berkeley's intended replacement for SICP, Dive Into Python, will make you a better Python
programmer. Another candidate, Thinking In Java, will make you a better Java programmer. A
third option, Thinking In C++, will no doubt make you a better C++ programmer. From an
educational standpoint however, none of these alternatives are satisfactory. The sad truth
is that SICP's gradual removal from computer science curricula has left behind a gaping
hole that few other texts can hope to fill.

To understand what makes SICP so special, you have to immerse yourself in it. So get ready.

To Slay a Dragon!

(略)

A Plea

I respect the Berkeley CS department's decision to try Python for its introductory 
course. I'm sure that the decision was well-meaning, and who knows, things may even 
turn out for the best this way.

That said, I really hate to see SICP on its deathbed at Berkeley. Dive Into Python, 
whatever its merits, is certainly not an adequate replacement. Not if you want 
students to walk away with a deep appreciation for the elegance and power of their 
field. I was looking forward to CS61A over the summer and received an unpleasant 
surprise when I heard rumors of change… A lot of students will be missing out on a 
great program this fall.

Please help me raise awareness about this issue. I don't know if the department can be 
convinced to reverse their decision, but I hope that's the case.

I'll take the musings of Ben Bitdiddle over XML parsing 101 any day. Any day.

An Update

SICP will not be abandoned at Berkeley.

Although Python will be used to convey the material, I have been assured that much of 
the content from SICP will be preserved.

I recognize now that CS61A is a fusion of sorts: an exciting modern treatment of 
traditionally intellectual material. This change reflects concerns about the 
difficulty of SICP, the popularity of Python, and a general lack of interest on the 
part of students and teachers in Scheme. Fair enough. I think this is the best 
possible solution for an introductory course, but that's just my opinion.

I want to reiterate that I mean Berkeley or its professors no disrespect, and that I 
only raised this issue because I was concerned about a potentially drastic shift in 
the curriculum.

I can't begin to thank you all for your comments, criticism, emails, and interest. 
It's made a world of difference.

-vk

この記事、redditではそれほどでもありませんが Hacker News ではそれなりに 熱く語られている模様(中身は見てません)。 Hacker News | SICP is Under Attack SICP is under attack : programming

be under attackの意味 - 英和辞典 Weblio辞書

be [come] under attack [fire]
攻撃を受ける

be under attack [pressure]
風当たりが強い

んー。「非難」に「屈する」ってどこから?

■_

■_

2011年08月05日

■_

「湯水のように」
湯水のように湯水を使えないところでは湯水のようにというのをどのように表現してるんだろうか。 以前どっかでいくつか聞いた覚えもあるようなないような。

「星守る犬」「続・星守る犬」
マンガ喫茶で読んだ。 ちょっとやられた(続でそう来たかあ)。

twitter 旧UI廃止と同時にRSSもとれなくなったっぽい と思ったらそうでもない? いずれにしても、新しくRSSのアドレス(というのか)を見つける手段はなさそうだけど。

■_ How do you define elegant code?

What does it mean to write "good code"? - Programmers - Stack Exchange と重複してる質問だろうと突っ込まれてますがそれはさておき。

How do you define elegant code? - Programmers - Stack Exchange

How do you define elegant code? [closed]


In a discussion on coding quality, and how you identify it, I came across a discussion 
on testing people's coding ability by getting them to show how they would swap two 
values using a piece of code to achieve the objective. Two key solutions were produced:

   1. Introduce a spare variable to do some pass the parcel of the values or:
   2. Use some bitwise operators.

There then ensued an argument on which was in fact the better solution (I'd be leaning 
towards the first option while being aware that the second one exists, but may not 
always evaluate as expected depending on the values in question).

Bearing in mind the story of Mel the Real Programmer, I am interested in knowning how 
you evaluate code as being elegant or not, and is succinctness a key feature of 
elegant code.

Good code should be clean, simple and easy to understand first of all. The simpler and 
cleaner it is, the less the chance of bugs slipping in. As Saint-Exupery coined, 
"Perfection is achieved, not when there is nothing more to add, but when there is 
nothing left to take away."

Moreover, elegant code is usually the result of careful analysis of the problem, and 
finding an algorithm and design which simplifies the code greatly (and often speeds it 
up too). E.g. Programming Pearls shows several examples where an insight gained during 
analysis gave a totally different angle of attack, resulting in a very simple, elegant 
and short solution.

Showing how clever the author is, only comes after these ;-) Performance 
micro-optimization (like using the bitwise operations you mention) should be used only 
when one can prove (with concrete measurements) that the piece of code in question is 
the bottleneck, and that the change actually improves performance (I have seen 
examples to the contrary).

Not to mention if you are going to do something clever it should be WELL documented. 2 
Years from now you are probably not going to be around to ask questions of or at least 
you should not have to answer questions about your old code. 


Elegant code is a combination of:

    * Correctness. IMHO no wrong code can truly be elegant.
    * Succinctness. Less code means less to go wrong, less to understand*.
    * Readability. The easier it is to understand code, the easier to maintain.
    * Performance. To a point. Prematurely pessimized code cannot truly be elegant.
    * Following the established standards of the platform or project. When given two equally
      elegant options, the one that is closest to the established standard is the best.
    * Exactly the way I would do it. Okay, I'm joking, but it's easy to label code that is
      NOT how you would do it as "inelegant". Please don't do that - keep an open
      mind to different code.

Of course, there's also the all-too-often true adage: "To every problem there is 
a solution that is simple, elegant, and wrong".

*As the comments below show, there is some contention on shorter code. 
"Succinct" does not mean "in as few characters as possible", it 
means "Briefly and clearly expressed.".

My definition is simple unfortunately you can't determine (all of) it yourself.

Elegant Code has the following features:

    * It solves the problem.
    * I can trust the tests such that if I modify any behavior, a test will break.
    * When I or +any other developer+ open the code, it is immediately easy to follow. Any
      non-trivial logic blocks are described by a comment.
    * Simple things are simple, hard things are possible.
    * Someone else is +willing+ to take over development of the code even though I am still
      there. Without being forced.


site design / logo © 2011 stack exchange inc; user contributions licensed under cc-wiki with attribution required

簡潔明瞭。かなあ>エレガントなコード とはいえ、短いけど一見してなにがなにやらというのもあるから油断はできない (「エレガント」と「わかりやすさ」は別の視点だろうし)。

■_

つづき。

The Most Expensive One-byte Mistake: Did Ken, Dennis, and Brian choose wrong with NUL-terminated text strings? : programming

Have the first byte defines how many of the next bytes store length, which'll limit you to
2(256*8) byte-strings ;) (A bit over 3x10616 )

(On a related note, the way UTF-8 does variable-length character encoding may be interesting.)
Header bytes 	Min message length 	Max message length
0 	0? 	0?
1 	0? 	0?
2 	0 	255
3 	256 	65535
4 	65536 	16777215
n 	256(n-2) 	256(n-1) -1

Sure, the overhead isn't that fun with strings under 200 bytes, but it does open up that
higher area quite nicely ;)


And then we get to the issue that the null terminated string can be worked with using 
a simple loop, all the mangement code to read/write it fits in one line in the for() 
statement. A single byte works (see p-strings), it's just easy to work with, even a 
fixed 2 or four bytes work (needing only a cast with what would end up being a macro). 
The problem is that that one byte is unusable, 2 bytes is limited, and 4 bytes took up 
way too much space back then. So then you go to variable length styles and you find 
you now need variable length code just to read a string? WTF does it look like to read 
someones name when they type it in? sounds like 10 lines of code for something that 
takes two, it's just too complicated. Yes, this would work in other languages, but not 
C, it's too low level, people want to operate on the string buffers directly and the 
APIs need to support long strings, null terminated is what works.


Why not a start_ptr + end_ptr format?

Advantages:

    * Pointer arithmetic allows quick-and-easy indexing, and checking length
    * It allows for infinite strings
    * Incredibly easy buffer overflow prevention
    * Modifying a string (changing length) is as easy as changing the end pointer
    * It only takes 8 or 16 bytes (for 32 or 64-bit systems)

Problems:

    * It takes 8 or 16 bytes regardless of string length.

文字列(を表すデータ構造)に長さを持たせるのはいろいろ面倒なんですよね。 その昔、文字列の長さを表す1バイト+255バイトの格納領域という文字列形式が BASIC で割と使われていた(と思う)のですが、 フロッピーディスクからデータを読み込むときの最小単位が256バイトだったりするので 文字列変数ひとつでその最小単位を格納し切れなかったりしたという (本日のムダ知識)。

じゃあ長さを2バイトで表せば…といってもこれがまた。という話になるわけですね。

ポインター二つ(先頭と終端)で表現するってのはどうなんですかね。 使い方次第では良い局面もありそうな気がするんですが (Advantage に書かれてるか)。

■_ Forth

Forth と再帰 - MetaNest あねっくす

Forth における再帰はちょっと面白いのだが、歴史的なところまで含めた日本語での解説がない
みたいなのでちょっと書いてみたい。きっかけは Forth とメタプログラミングという話題が TL 
に流れてたのでちょっとつぶやいてみたのだが、プログラミングについての話題はかなり貪欲に 
RT する某氏にスルーされたためでもある

(略)

最初期の Forth と再帰

http://www.colorforth.com/HOPL.html によると、「Mohasco, 1968」という節に

    SMUDGE avoided recursion during the interpretation of a definition. Since the 
    dictionary would be searched from newest to oldest definitions, recursion would 
    normally occur.

という説明がある。つまり、最初期の Forth は後の Forth とは異なり、定義中のワードが参照
できてしまうという仕様であり、SMUDGE (ぼかす、不鮮明にする、という意味がある。ペイン
ト系グラフィックツールにそんな名前のブラシがあったりしますよね)というワードで、定義中
のワードを参照してしまうのを防ぐ(そうすることで、同名ワードの再定義の時、古い定義を参
照する)ようになっていた

その後の Forth と再帰

マイコン時代に入り、Forth はマイコンで広く使われるようになるが、その頃の Forth では既
に、定義中のワードは参照できない、という仕様であった。当時の資料(本稿は手元にある、共
立出版の井上著『標準FORTH』を参考にした)などで確認できる

しかし、SMUDGE というワードは使われており、上記の Charles H Moore 氏の説明とは全く逆に、
即ち再帰呼び出しをするために、使われていた。しかしおそらく、SMUDGE というワード自体の
定義は変わっていなかっただろうと思われる。以下、どういう仕掛けなのかを説明する

Forth の辞書中のエントリにおけるワード定義のデータ構造は、他の、プログラミングにおいて
一般的なシンボルテーブル等と同様の、まずヘッダがあり各種属性などのビットや名前があり、
可変長の本体が続く、という形になっている

この辞書のエントリにおけるヘッダ内に SMUDGE ビット、というフラグがあり、ワードの探索時
にそれを見てスルーしたりしなかったりする、というようになっている(このへんは言語仕様的
には実装の詳細ということになるのだろうが、Forth はそういうことは気にしない文化(という
気がする))。そして SMUDGE というワードは、この SMUDGE ビットを反転する、というワード
である

(略)

ちょっと前に国会図書館にまで行って、Oh! MZ やら Oh! X といった昔の雑誌を調べたり コピーしたり(A4一枚25円は結構きつい)してきたのですが、 その雑誌にソースコードつきで掲載されていた magiForth という処理系の ソースコードを眺めていたら SMUDGE というフラグが使われてました。 が、まだ詳しく追いかけていないので実装の詳細は把握していなかったり。

magiForth 以外にもいろいろと面白いものがある(とはいえ8ビット時代のものなので、 機能は推して知るべし)のでいずれまた。 というかそのために国会図書館まで行ったのだった。

■_

ぼつ

■_

2011年08月04日

■_

今週のモーニング。 カレチもグラゼニも良かった。 まあ流行のキャラクターじゃないけどねえ。

すぽすっぽ先生の例の本、先行販売でいくつかの書店で入ったようですね。

■_

なぜ代入されるものが左辺にくるのか。など。

language design - Why does the assignment operator assign to the left-hand side? - Programmers - Stack Exchange

I began teaching a friend programming just recently (we're using Python), and when we 
began discussing variable creation and the assignment operator, she asked why the 
value on the right is assigned to the name on the left, and not vice-versa.

I had not thought about it too much before, because it seemed natural to me, but she 
said that left-to-right seemed more natural to her, since that's how most of us read 
natural languages.

I thought about it, and concluded that it makes code much easier to read, since the 
names that are assigned to (which the programmer will need to reuse) are easily 
visible, aligned on the left.

■_ 12 Tips For Teaching A Programming Class

12 Tips For Teaching a Programming Class : programming

12 Tips For Teaching A Programming Class | Intridea Blog

12 Tips For Teaching A Programming Class

Here are 12 tips to keep in mind when creating and teaching a technical course:

   1. Rest- I've learned to make sure I get plenty of rest the night before I teach. I
      also make sure I have plenty of caffeine, water, and healthy snacks at my disposal 
      during the day. Do not underestimate how much energy it takes to run a class.

   2. Relax- You lose your train of thought, you freeze, you stutter, you sweat a little,
      you don't know the answer, you forget their names... Relax, these things happen.
      Believe it or not, your students want you to succeed and are very forgiving. Just
      realize that mistakes happen: handle it, and move on. If you can't recover quickly,
      simply make the class take a 5-10 min break to recover or defer to the other
      instructor.

   3. Break the Ice with Introductions- For me, the hardest part of teaching a class is
      the first hour of class on the first day. You don't know the students and they 
      don't know you. The best way to get around this is to quickly introduce yourself
      then have the students go around the room and introduce themselves. "Please
      tell us your name, where you're from (location, work), what's your specialty,
      and what you hope to get out of the class". This takes the pressure off you,
      distributes it across everyone in the room and gives you the time to get
      comfortable and ease into the role of instructor.

   4. Labs- Lots of them. Labs are the most important aspect of teaching a class on 
      programming. Students will not absorb the information from your lectures as well if 
      you don't give them frequent opportunities to put the material to use in a practical 
      way. It's like playing a musical instrument - you can read about it all day long but 
      when it comes down to making music there's no substitute for physical practice and 
      interaction with the instrument itself. Knowledge is solidified during lab time.
      This is when most of the "Ah-ha!" moments occur.

   5. Avoid Slides if Possible- Slides work really well for short presentations because
      they help support your succinct message; in the classroom, slides can actually hinder
      students from paying attention. Slides also have a tendency to kill the opportunity
      for spontaneous subjects. It's okay to go off on a tangent, especially if your
      students are engaged. Don't just read from a slide deck. Build things with them on
      the fly. There's nothing techies love more than live, working, and tweakable examples.
      Student: "How does that work? Why does that work?" Instructor: "Here,
      let me show you". That wins over slides every time.

   6. Encourage Discussion- People like to talk. Give them frequent opportunities to talk
      with you and the other students about the material. I've found that if you encourage
      lots of discussion during the lecture (and throughout the course) people tend to help
      each other a lot more during labs. It creates a more lively and memorable environment.
      People pay attention more if an interesting conversation is likely to break out at
      any time.

後半は略

■_

■_ The Official Ruby Site Is Proudly Maintained by No-One

本文はまあおいといて、コメント欄から。

The Official Ruby Site Is Proudly Maintained by No-One
libogski says:
August 3, 2011 at 5:52 am

Ruby is not yet dead, but it has bottomed out. Ruby had a chance of making it big, but 
ultimately it failed to deliver (except Rails).

A good analogy for the paths of Python and Ruby is the careers of two Star Wars stars: 
The career of Mark Hamill resembles that of Ruby, while Python is that of Harrison 
Ford.

どういう喩えだ…

2011年08月03日

■_

ナポレオンの戦役
ナポレオンの戦役
をちまちまと読んでいるのですが(戦いごとに独立しているので割と細切れに読みやすい)、 なんとまあすごい面子がそろったものだなあと改めて思ったり >ナポレオン指揮下の将軍たち

「銀河英雄伝説」のエピソードにもでてきた「730年マフィア」を連想したのだけど、 ひょっとしたらモデルのひとつだったのかも。
銀河英雄伝説外伝 螺旋迷宮 1 [DVD] 銀河英雄伝説外伝4 螺旋迷宮 (創元SF文庫)

と意味もなくアサマシを貼ってみる。

■_

なんかいろいろ盛り上がってるようですが

. PyPy is faster than C, again: string formatting : programming

Twitter: From Ruby on Rails to Java - The Gory Details : programming Twitterが、Ruby on RailsからJavaVMへ移行する理由 - Publickey

The dangerous side of smart people who get things done: Sometimes they are too smart and do too much. : programming Hacker News | When I was at Google I wished they had a few 'uncoders', people who made it thei...

The Official Ruby Site Is Proudly Maintained by No-One

読んでる余裕がががが

■_ 最も高価な一バイト

© 2011 ACM 1542-7730/11/0700 $10.00 だから丸ごと訳したりしたらあれか。 にしても、何でこのネタでredditのスレッドがあんなに伸びるんだろう。 The Most Expensive One-byte Mistake: Did Ken, Dennis, and Brian choose wrong with NUL-terminated text strings? : programming

The Most Expensive One-byte Mistake - ACM Queue

The Most Expensive One-byte Mistake
Did Ken, Dennis, and Brian choose wrong with NUL-terminated text strings?

Poul-Henning Kamp

IT both drives and implements the modern Western-style economy. Thus, we regularly see 
headlines about staggeringly large amounts of money connected with IT mistakes. Which 
IT or CS decision has resulted in the most expensive mistake?

Not long ago, a fair number of pundits were doing a lot of hand waving about the 
financial implications of Sony's troubles with its PlayStation Network, but an event 
like that does not count here. In my school days, I talked with an inspector from The 
Guinness Book of World Records who explained that for something to be "a true 
record," it could not be a mere accident; there had to be direct causation 
starting with human intent (i.e., we stuffed 26 high school students into our music 
teacher's Volkswagen Beetle and closed the doors).

(略)

The best candidate I have been able to come up with is the C/Unix/Posix use of 
NUL-terminated text strings. The choice was really simple: Should the C language 
represent strings as an address + length tuple or just as the address with a magic 
character (NUL) marking the end? This is a decision that the dynamic trio of Ken 
Thompson, Dennis Ritchie, and Brian Kernighan must have made one day in the early 
1970s, and they had full freedom to choose either way. I have not found any record of 
the decision, which I admit is a weak point in its candidacy: I do not have proof that 
it was a conscious decision.

As far as I can determine from my research, however, the address + length format was 
preferred by the majority of programming languages at the time, whereas the address + 
magic_marker format was used mostly in assembly programs. As the C language was a 
development from assembly to a portable high-level language, I have a hard time 
believing that Ken, Dennis, and Brian gave it no thought at all.

Using an address + length format would cost one more byte of overhead than an address 
+ magic_marker format, and their PDP computer had limited core memory. In other words, 
this could have been a perfectly typical and rational IT or CS decision, like the many 
similar decisions we all make every day; but this one had quite atypical economic 
consequences.

(略)

© 2011 ACM 1542-7730/11/0700 $10.00

acmqueue

Originally published in Queue vol. 9, no. 7—
see this item in the ACM Digital Library

コメントが結構面白い。 いくつか抜き出し。

Comments
    * fisted | Wed, 03 Aug 2011 06:13:02 UTC

      Oddly, what isn't mentioned in a single word is that the addr+len variant would also
      get us rid of yet another inconvenience regarding NUL-terminated strings. Namely the
      fact that you cannot store such a NUL byte in it.

    * PCM2 | Wed, 03 Aug 2011 06:08:07 UTC

      Dennis Ritchie has written about this subject:
      http://cm.bell-labs.com/who/dmr/chist.html
      "C treats strings as arrays of characters conventionally terminated by a marker.
      Aside from one special rule about initialization by string literals, the semantics of
      strings are fully subsumed by more general rules governing all arrays, and as a result
      the language is simpler to describe and to translate than one incorporating the string
      as a unique data type." (He admits that C's approach does have its faults, but it
      was definitely a conscious decision that made sense at the time.)

    * Bruce | Wed, 03 Aug 2011 05:44:57 UTC

      The only problem I have with this is that the PDP-11 was a 16-bit word architecture
      which supported only a small subset of instructions having 8-bit boundary address
      access. Therefore all malloc() and stack allocations were always done in 16-bit word
      chunk sizes to ensure that any word accesses were all even byte aligned, so there was
      no 1 byte saving by using null termination. Every C compiler under every O/S on a
      PDP-11 I have ever used HAD to behave this way or have the CPU throw a word access
      exception.

    * Rudi Cilibrasi | Wed, 03 Aug 2011 05:42:25 UTC

      BCPL had it right all along. The Amiga kernel was written using BCPL strings and it was
      a great technical achievement but unfortunately the market could not accept it at that
      time. Fast forward three decades and we have reinvented preemptive multitasking and
      resource efficiency in the mobile market and are about to repopularize length-prefixed
      strings as std::string in C++ as part of the upcoming C++ Renaissance.
      ftp://cm.bell-labs.com/who/dmr/bcpl.html

    * Krz | Wed, 03 Aug 2011 00:56:55 UTC

      @Lucio Maciel: Would you really have needed to support a string size >64KB? The
      author supposes a net change to the storage requirement of a new string as "one
      byte longer," implying a two byte length field, since we're dropping the trailing
      null. Machines at the time had 16, 18, and 22 bit address spaces, so a 16 bit string
      size would certainly have been quite sufficient back then. Moreover, even those PDP
      machines with 18 and 22 bit addresses provided it to user space with overlays, further
      restricting you to only 64 KB of contiguous storage at any given point in time.

      @Me: Defining the storage requirement as one byte longer does not imply a one byte
      length, it implies a two byte length, more than enough for the time. If the decision
      had been made so, the length field would have likely been expanded with the machine's
      native int size, just as the pointer grew with the underlying architecture. It almost
      goes without saying the address space would have been available to a single string
      (though whether that's a feature or misfeature is another question entirely).

    * maht | Tue, 02 Aug 2011 18:53:58 UTC

      The answer was easy to find : http://cm.bell-labs.com/cm/cs/who/dmr/chist.html
      Bell-Labs were dumping GE-645 Multics and looking for an alternative. Faced with porting
      BCPL from Multics to the PDP-7 he dropped some stuff to squeeze it into less memoryand
      thus B was born. "In BCPL, the first packed byte contains the number of characters
      in the string; in B, there is no count and strings are terminated by a special character,
      which B spelled `*e'. This change was made partially to avoid the limitation on the
      length of a string caused by holding the count in an 8- or 9-bit slot, and partly
      because maintaining the count seemed, in our experience, less convenient than using a
      terminator."

    * ForkQueue | Tue, 02 Aug 2011 18:06:05 UTC

      Why not change and fix the mistake? http://www.gnu.org/s/libc/resources.html you could
      fork it (to github) and monkey patch the bug and fix the other design flaws that you
      see. I'd happily compile my C code with it.

文字列の表現形式でちょっと書こうと思ったけど時間がねー。 またの機会があれば。

■_

■_

[ruby-core:38725] [Ruby 1.9 - Bug #5149][Open] Specific combination of regexp an...
[ruby-core:38726] [Ruby 1.9 - Bug #5149] Specific combination of regexp and stri...
Specific combination of regexp and string can cause ruby process to hang with 100% CPU.
[ruby-core:38727] [Ruby 1.9 - Bug #5149] Specific combination of regexp and stri...
[ruby-core:38728] [Ruby 1.9 - Bug #5149] Specific combination of regexp and stri...

[ruby-core:38736] [Ruby 1.9 - Feature #5153][Open] Remove rb_add_suffix

↑ (.*)+ のように正規表現の量指定子を重ねると大変よ。という話なんですがまたの機会に。 というか鬼車はこれを検出して警告するオプション持ってたような。

2011年08月02日

■_

久しぶりにココイチのカレー食った。

■_ lint

COBOLINTがツボに。Lで終わる名前のプログラミング言語てえと PascalとかAlgolとかPerlあたり?

この会社辞めようと思ったソースコード#1C

848 仕様書無しさん [sage] 2011/07/27(水) 00:32:36.70 ID: Be:
    未だに内の会社で見るバグ
    COBOL

    PERFORM VARYING I FROM 1 BY 1 UNTIL I > 5
      ~~
      PERFORM VARYING I FROM 1 BY 1 UNTIL I > 10
        ~~
    END-PERFORM
      ~~
    END-PERFORM

    外のループは絶対5回は回らなきゃいけないのに、
    追加したコードがそれをぶち壊し…
    一体、何回同じバグを繰り返せば身に染みてくれんだろう…orz 

849 仕様書無しさん [sage] 2011/07/27(水) 02:27:41.32 ID: Be:
    COBOLINTを作るんだ!w 

850 仕様書無しさん [sage] 2011/07/27(水) 10:09:39.02 ID: Be:
    COBOLってブロック内変数とかって出来ないんでしたけ?
    なら怖すぎますね。 

851 仕様書無しさん [sage] 2011/07/27(水) 18:54:50.86 ID: Be:
    汎用機の頃からガリガリ書いてるはずなのに、未だに>>848のザマだよ!
    直した本人は外出中で居ねぇ
    おまけに特定の顧客の時のみ爆発するというスグレもの

    >ブロック内変数
    COBOLまだ中途半端にしか把握してないし、
    少なくとも会社のソースにブロック内変数なんて見た事ねぇ

    GOTOの入ってる関数コピペして、そのGOTO先を直さずに…
    ってこれも何回目だ、くそがあ゙あ゙ああああ!!くぁwせd

852 仕様書無しさん [sage] 2011/07/27(水) 23:27:59.06 ID: Be:
    >850
     構造化なんてもんがない時代に作られた言語に何を期待するかね。

     とはいえ、COBOL-78(第3次国際規格の元)でスコープの概念が導入されてるけどさ。
     COBOL 2002、第4次国際規格だとオブジェクト指向すら組み込んでたりするから怖いが。 

853 仕様書無しさん [sage] 2011/07/27(水) 23:32:30.38 ID: Be:
    むか~し N-BASICって言語で開発したけど、
    変数ぶつからないようにするのが工数のほとんどだったなぁ。
    今 思い出しただけでも怖いっす。 

854 仕様書無しさん [sage] 2011/07/27(水) 23:40:54.20 ID: Be:
    >>850
    END-PERFORM があるなら、あっても良さそうな気がしますけど。
    (cobol65しか経験ないので、よくわからない)

855 仕様書無しさん [sage] 2011/07/30(土) 23:00:11.23 ID: Be:
    デバッガで値を見るためだけにグローバル変数が定義してあって1000個くらいある。 

856 仕様書無しさん [sage] 2011/07/31(日) 09:27:23.01 ID: Be:
    グローバルスコープそのものが悪いとは思わない。
    ブロックで閉じた空間を作れないのが最悪かと。 

857 仕様書無しさん [sage] 2011/07/31(日) 09:51:45.30 ID: Be:
    ある関数のそばのグローバル変数が変わると遠くのソースで竜巻が起こる
    バタフライモデルだな 

858 仕様書無しさん [sage] 2011/07/31(日) 20:08:00.17 ID: Be:
    友達の友達はまた友達だ
    みんなで作ろう副作用yの輪... 


■_

ずいぶん伸びてるけどなんでまた

Learn Perl in about 2 hours 30 minutes : programming

Grow up, reddit. Perl's not my favorite language either, but is bitching about the 
language even relevant here? It's not an article about advocating Perl; it's a 
resource for learning the language, whatever your reasons. Having worked at a job 
previously where I was forced to program in Perl, I would have been grateful to have a 
tutorial like this. (The Camel book just wasn't my cup of tea.)


Agreed.

It'll be nice in the next 5-10 years when the latest scripting language is popular and 
all the Python and Ruby users have to defend their choices the same way Perl and PHP 
users have.


I'm kind of hoping that latest scripting language will be Perl 6. I like to tell that 
to my Ruby-on-Rails-fan co-workers and give them nightmares.

Edit: and when I do that I remind them of how mercilessly Mozilla was mocked during 
its long development. That really scares 'em. :D


It shouldn't. Most projects fail; mockery is not a badge of honor because every 
well-publicized project is mocked.


EDIT: Reddit is fucking with me today. Sorry about the multiple replies, I thought the 
last one didn't make it through. But I'm leaving this in bceause I spent all the time 
writing it. :/

Mozilla was not just mocked, it was scathingly mocked by geeks who hated IE and should 
have supported it. Every delay of Mozilla was seen as another opportunity to tell the 
Mozilla devs to throw in the towel and admit their work was useless, pointless and 
hopeless. I'm mainly thinking of the slashdot geeks.

But the badmouthers were wrong. Gloriously, gloriously wrong. I'm not saying being 
mocked is a badge of honor. I'm saying there was a huge amount of spleen vented at 
Mozilla, it was seen as an utterly wasted effort. No one would ever use it. It'll 
never be finished. Etc etc. And we know how that all turned out.

And today, there is a devoted group of coders working to do great things with Perl 6. 
They are not rushing things. They are taking their time and doing it right. Meanwhile, 
Perl has probably the worst reputation of any of the "script" languages 
coders could choose (so it seems to me), warranted or not. r/programming rarely has 
stuff that mentions Perl. Perl is unexciting. Perl is passe. Perl implicitly will 
never change; it's old, ugly, and has crappy OO.

I'm really looking forward to how this will turn out.

Gonna have to disagree with you there, buddy. Mozilla was not just mocked, but mocked 
"mercilessly". I used to hang out on /. and the amount of hostility directed 
at the Mozilla project by the geeks, for example, was amazing. They were constantly 
being told to throw in the towel.

And they were all wrong. I'm not saying that being mocked is a badge of honor. I'm 
just saying they all thought Mozilla was a wasted effort, and they were all wrong. 
Gloriously, gloriously wrong. :)


But much of Mozilla was a wasted effort.

They were handed the entire source code of Netscape 4.0, found it bloated and 
cumbersome, fully of shoddy crap and enterprise crap that Netscape had picked up since 
the idiots at Collabra came on board, and the Mozilla crew proceeded to write it again 
almost from scratch, yet they kept much of the same architecture that made it 
cumbersome (e.g. XPCOM, Mork)

What saved Mozilla's bacon was the Firefox team. They stripped out the bullshit. They 
left the modularity in and put the features in plugins. Easy to write plugins, thanks 
to XUL. Genius move.

This document totally reminds me why I dropped Perl for Python. Hash and Array refs 
drove me nuts last time I had to do lists-of-lists :|


Agreed that this tutorial isn't great. But there's nothing hard about creating lists 
of lists in Perl:

my $list_of_lists = [
    [ 'this', 'is', 'list', 'one' ],
    [ 'this', 'is', 'list', 'two' ],
    [ 'this', 'is', 'list', 'three ],
];

It's exactly the same syntax (barring the leading $ on the variable name and my 
declaration) as Python and Javascript.

    Agreed that this tutorial isn't great.

Hey, I thought the tutorial was pretty good. Just because the subject matter sucks 
doesn't make it a bad explanation.

Perl makes me cry blood, that is all

適当に抜粋。

■_

で、騒動の元。

Perl

Learn Perl in about 2 hours 30 minutes

By Sam Hughes

Perl is a dynamic, dynamically-typed, high-level, scripting (interpreted) language 
most comparable with PHP and Python. Perl's syntax owes a lot to ancient shell 
scripting tools, and it is famed for its overuse of confusing symbols, the majority of 
which are impossible to Google for. Perl's shell scripting heritage makes it great for 
writing glue code: scripts which link together other scripts and programs. Perl is 
ideally suited for processing text data and producing more text data. Perl is 
widespread, popular, highly portable and well-supported. Perl was designed with the 
philosophy "There's More Than One Way To Do It" (TMTOWTDI) (contrast with 
Python, where "there should be one - and preferably only one - obvious way to do 
it").

Perl has horrors, but also some great redeeming features. In this respect it is like 
every other programming language ever created.

Preliminary notes

    * This document is aimed at people who - like me - learn new programming languages 
      most quickly by "axiom and example", and who dislike the official Perl 
      documentation at http://perl.org/ for being intensely technical and giving far too 
      much space to very unusual edge cases. This document is intended to be as short as 
      possible, but no shorter.

    * The following can be said of almost every declarative statement in this document: 
      "that's not, strictly speaking, true; the situation is actually a lot more 
      complicated". I've deliberately omitted or neglected to bother to research the 
      "full truth" of the matter for the same reason that there's no point in 
      starting off a Year 7 physics student with the Einstein field equations. If you see a 
      serious lie, point it out, but I reserve the right to preserve certain critical 
      lies-to-children.

(略)

ぱっと見たところ良くかけているドキュメントだと思うけどなあ。

■_

■_

2011年08月01日

■_

イカサマータイムで順調に削られてます。いろいろ。

夏休みの

■_ D

盛り上がるやり取り

programming languages - What does C++ do better than D? - Programmers - Stack Exchange

What does C++ do better than D?
C++ が D よりもよいこととは?

I have recently been learning D and am starting to get some sort of familiarity with 
the language. I know what it offers, I don't yet know how to use everything, and I 
don't know much about D idioms and so on, but I am learning.

I like D. It is a nice language, being, in some sort of ways, a huge update to C, and 
done nicely. None of the features seem that "bolted on", but actually quite 
well thought-out and well-designed.

You will often hear that D is what C++ should have been (I leave the question whether 
or not that is true to each and everyone to decide themselves in order to avoid 
unnecessary flame wars). I have also heard from several C++ programmers that they 
enjoy D much more than C++.

あなたはDが、C++があるべきものであると耳にすることが頻繁にあるでしょう
わたしは何人かのC++プログラマーがC++よりもDをenjoyしているというのを聴いたことがあります。

Myself, while I know C, I can not say that I know C++. I would like to hear from 
someone knowing both C++ and D if they think there is something that C++ does better 
than D as a language (meaning not the usual "it has more third-party 
libraries" or "there are more resources" or "more jobs requiring 
C++ than D exists").

D was designed by some very skilled C++ programmers (Walter Bright and Andrei 
Alexandrescu, with the help of the D community) to fix many of the issues that C++ had, 
but was there something that actually didn't get better after all? Something he missed? 
Something you think wasn't a better solution?

D は何人かのとても実力のあるC++プログラマーたちによって、
C++の持っている問題の多くを解決するために設計されました。
しかし、結果的に改良されなかったものはなかったのでしょうか?
設計者がミスしたことは?
あなたが better solution ではないと考えることは?

Also, note that I am talking about D 2.0, not D 1.0.

Most of the things C++ "does" better than D are meta things: C++ has better 
compilers, better tools, more mature libraries, more bindings, more experts, more 
tutorials etc. Basically it has more and better of all the external things that you 
would expect from a more mature language. This is inarguable.

C++ がDよりも優れていることのほとんどは、meta things です。
C++ にはより優れたコンパイラーがあり、より優れたツールがあり、より mature な
ライブラリーがあり、より多くの bindings があり、より多くのエキスパートが存在し、
より多くのチュートリアルがあります。

As for the language itself, there are a few things that C++ does better than D in my 
opinion. There's probably more, but here's a few that I can list off the top of my 
head:

C++ has a better thought out type system
C++ にはより考え抜かれた型システムがある

There are quite a few problems with the type system in D at the moment, which appear 
to be oversights in the design. For example, it is currently impossible to copy a 
const struct to a non-const struct if the struct contains class object references or 
pointers due to the transitivity of const and the way postblit constructors work on 
value types. Andrei says he knows how to solve this, but didn't give any details. The 
problem is certainly fixable (introducing C++-style copy constructors would be one fix), 
but it is a major problem in language at present.

Another problem that has bugged me is the lack of logical const (i.e. no mutable like 
in C++). This is great for writing thread-safe code, but makes it difficult 
(impossible?) to do lazy intialisation within const objects (think of a const 'get' 
function which constructs and caches the returned value on first call).

Finally, given these existing problems, I'm worried about how the rest of the type 
system (pure, shared, etc.) will interact with everything else in the language once 
they are put to use. The standard library (Phobos) currently makes very little use of 
D's advanced type system, so I think it is reasonable the question whether it will 
hold up under stress. I am skeptical, but optimistic.

Note that C++ has some type system warts (e.g. non-transitive const, requiring 
iterator as well as const_iterator) that make it quite ugly, but while C++'s type 
system is a little wrong at parts, it doesn't stop you from getting work done like D's 
sometimes does.

Edit: To clarify, I believe that C++ has a better thought out type system -- not 
necessarily a better one -- if that makes sense. Essentially, in D I feel that there 
is a risk involved in using all aspects of its type system that isn't present in C++.

D is sometimes a little too convenient

One criticism that you often hear of C++ is that it hides some low-level issues from 
you e.g. simple assignments like a = b; could be doing many things like calling 
conversion operators, calling overload assignment operators etc., which can be 
difficult to see from the code. Some people like this, some people don't. Either way, 
in D it is worse (better?) due to things like opDispatch, @property, opApply, lazy 
which have the potential to change innocent looking code into things that you don't 
expect.

I don't think this is a big issue personally, but some might find this off-putting.

D requires garbage-collection
D はがーべじコレクションを要求する

This could be seen as controversial because it is possible to run D without the GC. 
However, just because it is possible doesn't mean it is practical. Without a GC, you 
lose a lot of D's features, and using the standard library would be like walking in a 
minefield (who knows which functions allocate memory?). Personally, I think it is 
totally impractical to use D without a GC, and if you aren't a fan of GCs (like I am) 
then this can be quite off-putting.

Naive array definitions in D allocate memory
D における Naive array の定義はメモリーを割り当てる

This is a pet peeve of mine:

int[3] a = [1, 2, 3]; // in D, this allocates then copies
int a[3] = {1, 2, 3}; // in C++, this doesn't allocate

Apparently, to avoid the allocation in D, you must do:

static const int[3] staticA = [1, 2, 3]; // in data segment
int[3] a = staticA; // non-allocating copy

These little 'behind your back' allocations are good examples of my previous two points.

Edit: Note that this is a known issue that is being worked on.

Conclusion
結論

I've focussed on the negatives of D vs C++ because that's what the question asked, but 
please don't see this post as a statement that C++ is better than D. I could easily 
make a larger post of places where D is better than C++. It's up to you to make the 
decision of which one to use.

この後も結構続きますt。

■_

で、こっちも。 How is C++ better than D? : programming

■_

■_

なんか次のがきてたからここで投げるw

Twitter / @repeatedly: 誰かが訳してくれるのを待つ(チラチラ &gt; "c ...

誰かが訳してくれるのを待つ(チラチラ > "compare iteratee with python's yield"

  http://www.haskell.org/pipermail/haskell-cafe/2011-July/094384.html
[Haskell-cafe] compare iteratee with python's yield


[Haskell-cafe] compare iteratee with python's yield
iteratee を Python の yield と比較する

Fri Jul 29 05:02:42 CEST 2011

Your question is insightful. The posted answers are excellent. I merely wish
to illustrate one, already made, point on a concrete example.

あなたの質問は insightful です。
ポストされた回答は素晴らしいものです。


The complete code is in the file
コード全体は以下のファイルにあります
	http://okmij.org/ftp/Haskell/Iteratee/IterDemo.hs

The file implements a series of progressively more complex examples
-- from wc to grep, -- stressing compositionality. The whole program
is assembled from independent building blocks; as our task changes, we
replace one building block with another. The building blocks,
iteratees, may be stateful. We never have to worry about writing out the
whole state of the program and properly initializing it. The overall
state is implicitly composed from the state of each building block; 
each iteratee manages its own state without leaking it.

このファイルは wc から grep という、 stressing compositionality でより複雑な例の progressively
な series を実装しています。プログラム全体は独立した building block から組み立てられています。
わたしたちのタスクの変更として、ひとつの building block を別の building block で置き換えます。
その building block 、iterateee は stateful なものかもしれません。わたしたちがプログラムの
whole state を書き出すことや適切に初期化することについて心配することは決してありません。
overall state は state of each building block から implicitly に compose されます。
それぞれの iteratee は自身の state を leak することなく manage します。


The particular example to illustrate the state encapsulation is grep1_word

state encapulation を illustrate するための例として grep1_word を使います

> grep1_word word fname =
>   let search = IterateeM.dropWhile (/= word) >> IterateeM.head 
>       runI'  = runI . en_handle (\_ -> "not found:" ++ word) in
>   print =<< run =<< enum_file fname 
>     (runI =<< en_lines 
>      ((runI' =<< en_words search)
>       `en_pair` (count_i `en_pair` en_last)))

which implements "grep -w -n -m 1 <word> <filename>". It searches for
the first occurrence of the given word in the file and returns the line of that occurrence
and the line number.  (The example also illustrates exception handling: The exception is
raised by Iteratee.head when IterateeM.dropWhile dropped the whole stream while looking
for the given word.) A few comments: en_lines is the enumeratee, transforming a stream of
characters into a stream of lines; en_words is the enumeratee that transforms the stream
of lines to the stream of words. The stateful iteratee count_i counts the elements in any
stream; en_last, the analogue of List.last, returns the last seen element. The combinator
en_pair pairs two iteratees to run in parallel, processing the same stream chunk-by-chunk.
The processing stops as soon as one of the iteratees in the pair stopped. That behavior
does the trick: "en_words search" stops when the word is found. The whole pair
is stopped too. The other component of the pair, (count_i `en_pair` en_last), will receive
EOF and tell us the line and the line count they have last seen.

このコードは "grep -w -n -m 1 <word> <filename>" を実装しています。
与えられた単語がファイル中で最初に現れるところを探し、その単語を含んだ行とその行番号とを
返します (この例は例外処理も illustrate しています。与えられた単語の検索中に
IterateeM.dropwhile がストリーム全体を drop したときに例外が Iteratee.head により送出されます)。
A few comments:
en_lines は enumeratee で、キャラクターのストリームを行のストリームへと変形します。
en_words は行のストリームを単語のストリームへと変形する enumeratee です
stateful な iteerateee である count_i は任意のストリーム中の要素をカウントします。
List.last の analogue である en_last は最後に見た要素を返します。
コンビネーター en_pair は、同じストリームに対する chunk-by-chunk での処理を並行に
実行するための二つの iteratee の pair です。
この処理はペアとなっている iteratee のひとつが停止すると即座に停止します
この behavior では、対象のの単語が見つかったときに "en_words search" を止める
というtrick を行っています。このときペア全体も停止します。
ペアのもうひとつの componet (count_i `en_pair` en_last) は EOF を受け取って、
最後の行と行カウントに到達したことをわたしたちに知らせます



I guess the example can be written in Python-like style as follows
(simplifying and assuming that the file is already parsed into lines):

わたしは、この例を次の Python のようなスタイルで書けるのではないかと思います
(単純にしていますし、また、ファイルはすでに行ごとに分割されていると仮定しています):

counter = 0
for line in file_lines:
  counter = counter + 1
  if contains line word:
     print counter
     print line
     break


Suppose we wish to change our example to print not only the found line, but a few lines
before it (the option "-B" of grep). We have to modify our Python-like code:

この例を、見つかった行だけでなくそれに先行する数行も出力するように改造したいとします
(grep の "-B" オプションです)。わたしたちの Pythonもどきのコードを改造しなければなりません:

 -- add a piece of state to keep the context lines,
    and initialize it
    context linesを保持するための piece of state とその初期化を追加する

 -- add code to update the state as we read lines
    行を読んだときに state を更新するコードを追加する

 -- add the finalization code, to convert the state to the desired result
    state を望む結果に変換するための finalization code を追加する

The code will look like the following (### mark the changes):
このコードは次のものと見た目が似ています (### がついている部分が変更されたものです)

counter = 0
lines_seen = []  ###
for line in file_lines:
  counter = counter + 1
  accumulate lines_seen line ###
  if contains line word:
     print counter
     print (finalize lines_seen) ###
     break

In contrast, to modify the iteratee code for the new task, we make the
_single_ change: replace en_last with (en_lastN 5) (for 5 lines of context).

対照的に、新しいタスクのためにこの iteratee code を修正するには
en_last を(コンテキスト五行分のための) (en_lastN 5) に置き換えるという変更
「一箇所」だけです。


It should be stressed that the Python code has to be changed in three
*distinct, disconnected places*. New state has to be defined and
initialized, before the loop. The state has to be updated, somewhere
in the loop. The state has to be finalized, in the loop termination
part. When changing code, it is easy to overlook the needed
changes. For example, it is easier to accumulate the context lines in
reverse order. When printing the lines, we should not forget to
reverse them. When changes are disconnected, it is hard to reason and
test for them. With so many other things going on, it is hard to write
a proper test (for example, when testing the context accumulation we
don't care about word matching; we should test the accumulation in
isolation of whatever else we are doing in the iteration).

It should be stressed that
the Python code has to be changed in three *distinct, disconnected places*.
この Pythonコードは三箇所の*distinct, disconnected places* を変更する必要があります
新しい state はループよりも前に定義され、初期化がされていなければなければなりませんし、
この state はループのどこかで更新されなければなりません。
また state はループの終了処理部で finalize されなければなりません。
コードを変更するときに必要な変更点を overllok するのは容易なことで、
たとえば、逆順で context lines を accumulate するのは簡単なことです。
行を出力するときにはそれを逆順にすることを忘れないようにしなければなりません。
When changes are disconnected, it is hard to reason and test for them.
変更が disconect された場合
With so many other things going on, it is hard to write a proper test
適切なテストを書くことは困難になってしまいます
(for example, when testing the context accumulation we don't care about word matching;
we should test the accumulation in isolation of whatever else we are doing in the iteration).
たとえば、context accumlation をテストするときわたしたちは単語のマッチングには don't care です。
わたしたちはテストすべきです
accumulationを
isolation で
イテレーションでわたしたちが行っている
whatever  else 


The iteratee en_lastN deals only with the context accumulation aspect:

en_lastN という iteratee は期待されている context accumlation のみ扱います:

> -- Return N last received elements
> -- The acc below is the list of N last elements in the reverse
> -- order
> en_lastN :: Monad m => Int -> Iteratee el m [el]
> en_lastN n = ie_cont $ step []
>  where
>  step acc (Chunk [])  = ie_contM (step acc) 
>  step acc (Chunk ls)  = ie_contM (step $! Prelude.take n $ reverse ls ++ acc)
>  step acc stream      = ie_doneM (reverse acc) stream

The initialization of the state, the accumulation and the finalization are all
in the same place. The en_lastN iteratee does not care of counting,
searching, or whatever else is going on. In fact, the iteratee is pure
and deals with arbitrary elements (not necessarily lines). We can test
it using Quickcheck or HUnit. No IO is needed for the test.

状態の初期化、accumlation、そして finalization はみな同じ箇所にあります。
en_lastN itratree は数え上げ (counting) や検索 (searching)、などのようなものには
注意を払いません。実際、この itrateee は pure であり
任意の elements を扱います(行である必要はありません)。
わたしたちはこれを Quickcheck や HUnit を使って検査できます。
検査のために IO は必要ありません。


Thus in the iteratee style, the overall state of the program becomes
distributed, across iteratees that encapsulate and manage only their
own, small portion of the program state.

したがってこの iteratee 形式では overall state of the program は distributed になり、
encapsulate された iteratees の across は
自身の持っている small portion of program state だけを manage します。

The code IterDemo.hs shows other examples, including emulating
generators (aka, unfold_stream, or the `while loop'), to build the
stream of intermediate results of an iteratee. An iteratee in question
does not even suspect that it is being used `incrementally',
seduced to reveal the intermediate results.

IterDemo.hs というコードでは、ジェネレーター (aka, unfold_stream, or the `while loop') の
エミュレーションを含むある iteratee の中間結果のストリームを構築するための
別の例を示しています。
An iteratee in question does not even suspect that it is being used `incrementally',
seduced to reveal the intermediate results.



Thank you for the inspiring question.

インスピレーションを刺激する質問をどうもありがとうございます。


一つ前へ 2011年7月(下旬)
一つ後へ 2011年8月(中旬)

ホームへ


リンクはご自由にどうぞ

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