ときどきの雑記帖 i戦士篇

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

一つ前へ 2009年1月(中旬)
一つ後へ 2009年2月(上旬)

ホームへ

2009年01月31日

■_ 一月は犬去ぬ

・購入
GENBUN MAGAZINE (ゲンブンマガジン)なるものを書店にて見かけ、購入してみたでござる。 って、Amazonにもあったーw Amazon.co.jp： ゲンブンマガジン (Vol-001): 小林源文: 本 著者について: 小林源文です。出版社など待っていられなくて、自分で描きたいテーマで本を作って見ました。 2号目は四月末発売。 うははは。

・今月の皇帝陛下
マムルークこええw あとネルソンが主役の作品(マンガでも小説でも)がないかなあと思った。

・東スポ
プロレス面のコラムから。 ハンセンが常に考えていたのは「どうやってブッチャー、シンに対抗してトップ・ガイジンになるか?」 ということ。そこで行き着いたのが“ブレーキの壊れたダンプカー”とも称された ノンストップのパワーファイトである。 (略) そして最も大きかったのは 「ラリアートはフィニッシュにしか使わない」というこだわり。 そうそう。具体的に名前を挙げることはしないけど、 当時も多くの日本人レスラーがまねして使ってたけど(一見簡単だしね)、 腕を当てるだけの打ち方をしたりで(あれはアメフトのタックルが原型だから、 体ごとぶつかってかないと威力もなんもない)、 フィニッシュの技に使ってるレスラーなんて皆無だった。 さすがはハンセン、名にし負うだけのことはある。

・ONE OUTS
マンガ喫茶でアニメでやってるちょっと先まで読んできた。 どうも原作の最後までやりそうにない(ボリューム的に収まらない)けど どこまでやるんだろう。しかし三人組のエピソードは泣けた。

■_ Bad Python

Pythonistaも大変というお話(違 redditでも大変盛り上がっております Bad Python : programming 

The Collected Words of Graham Poulter: Bad Python
Thursday, January 29, 2009

Bad Python

I've seen quite a lot of bad Python, even though Python makes the Path of Good Code 
relatively easier to find than other languages which degenerate to spaghetti without 
discipline and years of dedicated study of the language on the part of the programmer. 
Such is the Tao of Perl.

Much bad Python however is from programmers who only know static OO languages 
(Java/C++/C#) and don't grok dynamic typing,  first-class functions, pervasive use of 
iterators, properties, etc, leading to eyesores such as:

#静的言語にどっぷり使っている人が～


    * Accessors e.g. getDistance() and setDistance(), instead of an attribute.  
      Attributes can be turned into properties later, preserving the interface.
    * Asserting the type of every argument and returned value, taking up maybe 30% of 
      the lines of code and 80% of the unit tests.  This is pointless because the 
      interpreter will let you know if someduck doesn't .quack() like a duck.
    * Uber-private attributes (for no good reason), going so far as to use  
      double-underscores on each side, which are supposed to be reserved for language 
      features.
    * Dozens of customising parameters in constructors, such as reversed and strip and 
      maxlen - when passing in a general transform function would be so much more elegant 
      and allow you to do much more than just reverse the strings that the class works with.
    * Delegates where first-class function will do.
    * Wrapping things classes when dicts and tuples would be cleaner.


Partly, those developers don't recognise the ways in which many Design Patterns become 
trivial in Python, to the extent that they are more like one-line idioms than 
chapter-worthy Patterns with capital "P".   Singleton Pattern? Write a 
module.  Iterator? It's fundamental to the language.  Abstract Factory? Write a 
function and thanks to dynamic typing you can swap it out at will. Flyweight objects 
or Command Dispatch?  Just use a dictionary.  See also 
http://www.suttoncourtenay.org.uk/duncan/accu/pythonpatterns.html

Besides bad habits acquired from static OO, one can write bad code, in any language 
with

#「悪い習慣」は静的なオブジェクト指向言語のほかからも


    * Vague and misleading identifiers (topic of future post)
    * Massive 'god' classes
    * Source files having no discernable structure.
    * Awkward decompositions of function

          o Forces similar logic to be repeated in dozens of places
          o Prevents parts from being reused e.g. in unit tests 
          o Prevents dependencies from being stubbed out e.g. in unit tests
          o Mixing logic with orthogonal aspects like error-handling and logging for a 
            harder-to-maintain mess.

Oh well.   I recently spent a day re-doing about 30% of the functionallity of 8,600 
lines of someone elses Java-style Python into 200 lines of real Python to support the 
greater flexibility I needed.  Code can be that bad.

■_ 矢沢本

つつきまわるのも時間のムダなので、いくつか挙げてとっとと切り上げるでござるよ。 

p68

それでは、C言語とJavaのどちらを選んだらよいのでしょうか?
現在のIT企業の新人研修では、筆者が関わるかぎり、圧倒的にJavaが選択されています。
Javaには、最新のインターネットプログラミングの機能があるからです。
「それならJavaを選ぼう」と思われるかもしれませんが、
はじめてプログラミングを本格的に学ぶ人はC言語のほうがよいと思います。
 Javaには機能が多いので、習得に時間がかかるからです。筆者は、入門者を対象に
C言語の解説書とJavaの解説書をそれぞれ書いた経験があります。
C言語の解説書は、1冊(300ページほど)ですみました。
Javaの解説書は、2冊(300ページ×2冊=600ページほど)になりました。
このことから、Javaの習得にはC言語の2倍ほどの時間がかかると思ってください。



以上、いくつかの理由からC言語をお勧めしましたが、他の言語を選んでも後悔しないはずです。
なぜなら、プロになれば、複数のプログラミング言語を使わざるを得なくなるからです。
最初に選ぶプログラミング言語が何であっても、それをしっかりとマスターしておけば、
他の言語の習得は容易になります。どの言語も英語と数学を混ぜたような構文であり、
大きな違いはないからです。プログラミング言語の違いは、方言の違い程度のものです。

ほん～～～～～～っとにJavaキライなんだな(笑) んで、書店によってそのJavaとCの入門書を探してみたのですが、 Javaは2冊とも見つかりましたがCの方は見つかりませんでした(古い本のようだし)。 で、Javaのほうなんですけど、アプレットの説明やらGUIプログラムも説明がありました。 Cの方はたぶん、WindoowsのGUIプログラムとかXとかのプログラムはないですよね。 んじゃあJavaだからCの二倍の説明が必要になったというのは ちょっとフェアじゃないのではないですか? 

p128
このプログラムでは、ループカウンタである変数i を「0～9」まで1つずつ増加させることで、
a[0] ～ a[9] という10個の要素を取り扱っています。そのために使われている for 文の構文は、


for (i = 0; i < 10; i++)



つまり「変数iを0～10未満まで繰り返す」です。

…え? 

p181
ユークリッドの互除法
 最初に覚えるべき基本的なアルゴリズムで「その他」としてあげたものの中から、
まずユークリッドの互除法を紹介しましょう。これは、2つの整数の最大公約数を求める
アルゴリズムです。

ユークリッドの互除法は(おそらく学校では教わりませんが)、機械的な手順で最大公約数
を求めることができます。それは、

・大きいほうの数から小さいほうの数を引くことを、両者が等しくなるまで繰り返す
   ↓
・等しくなったら、その数が最大公約数である

  

#include <stdio.h>

int main(int argc, char* argv[])
{
    int a, b;

    /* 2つの整数をキー入力する */
    scanf("%d", &a);
    scanf("%d", &b);

    /* 両者が等しくなるまで、大きい方から小さい方を引く */
    while (a != b)
    {
        if (a > b)
        {
            a -= b;
        }
        else
        {
            b -= a;
        }
}

/* 等しくなったら、その値を表示する */
printf("最大公約数 = %d\n", a);

return 0;
}

「互除法」っつーくらいだしいまどき除算コスト相対的にはともかく 絶対的な視点では大したことないだろうから上のプログラムみたいにする必要は 相手が初心者だというののあらなおのこと不要じゃない? 

リスト 6-9 照準でバブルソートするプログラム

#include <stdio.h>

int main(int argc, char* argv[])
{
    int i;    /* 結果を表示するときのループカウンタ */
    int n;    /* 先生は何番目を決定しようとしているか */
    int p;    /* 先生はどこに立っているか */
    int temp; /* 値の交換で使われる変数 */
    int a[] = { 7, 4, 2, 8, 6, 1, 5, 3}; /* ソートの対象となる配列 */

    /* nは0～6まで変化する */
    for (n = 0; n<=6; n++)
    {
        /* p は7～n+1まで変化する */
        for (p=7; p>= n + 1; p--)
        {
             /* 小さい方前になるように交換する */
             if (a[p] < a[p - 1])
             {
                 temp = a[p];
                 a[p] = a[p - 1];
                 a[p - 1] = temp;
             }
        }
    }

    /* ソート結果を表示する */
    for (i = 0; i < 8; i++)
    {
        printf("[%d]", a[i]);
    }
    printf("\n");

    return 0;
}

一応このプログラムリストの前にいろいろ説明されてますけど、 生の数字使いすぎじゃね?

一応このプログラムリストの前にいろいろ説明されてますけど、 生の数字使いすぎじゃね? 6,7,8 と微妙に値が違う数字ばっかり まあアルゴリズム上、配列要素数→8、外側のループ→配列の添え字の最大値-2、 内側のループ→配列の添え字-1になるのは自明だけど、 「初心者向けの本」で「別の部分でマジックナンバー使うな」とか書いといて これはないんじゃない?

■_ Lisp vs. Scheme

まあわかっている人は先刻ご承知の内容でしょうけど。 

Lisp Scheme Differences
Lisp Scheme Differences
SchemeLanguage and CommonLisp (CL) are about as similar as Java and C++.

The following compares the standards for both languages. Many implementations offer extensions.

Common Lisp:

    * has more built-in procedures and macros, including some moderately deep ones 
      like GET-SETF-EXPANSION
      より多くの組み込み手続きとマクロがある。
    * has more built-in types (like multi-dimensional arrays)
      より多くの組み込み型がある (多次元配列など)
    * has a standard facility for creating new types
      新しい型を生成するための標準機能がある
    * has a standard package system
      標準のパッケージシステムがある
    * has a standard object system (CLOS, the CommonLispObjectSystem)
      標準のオブジェクトシステムがある
    * has a standard exception-handling system (aka "condition system")
    * has macros that allow arbitrary Lisp code to transform code
      任意のLispコードを受付けそのコードを変換することのできるマクロがある
    * has symbol macros (DEFINE-SYMBOL-MACRO, SYMBOL-MACROLET)
    * has compiler macros for user-defined optimizations (DEFINE-COMPILER-MACRO)
      ユーザー定義の最適化のためのコンパイラーマクロがある
    * has symbol property lists.
      シンボルの属性リストがある
    * has hash tables.
      ハッシュテーブルがある
    * has dynamically scoped variables (a.k.a. SpecialVariables) which are extremely useful.
      動的スコープを持った変数がある
    * has a working UNWIND-PROTECT
      working UNWIND-PROTECT がある
      (使い物になる～ということか?)
    * is a very large language, with both the positive and negative implications.
      非常に大規模な言語である
    * has a FORMAT function, which is something like C's printf but type safe and much
      more powerful
      FORMAT関数がある。
    * has a big streams library, including string streams which do I/O to and from strings.
    * has a sequence library for manipulating vectors and lists in useful ways.
      ベクターやリストを便利に操作できる大規模なストリームライブラリがある。
    * has a customizable read syntax by manipulation of read tables
    * has the COMPILE function to dynamically compile source code to functions.
    * has functions to compile source files and load them.
      ソースをコンパイルする関数やコンパイル結果をロードする関数がある
    * provides mechanisms to control whether evaluation happens at various "times"
      like compile time, load time or execution time.
    * defines evaluation order and specifies the result value for all, or nearly all built-in
      functions and operators.
    * allows car and cdr on the empty list without signaling an error
      空リストに対する car や cdr を signaling an error 抜きで許可している
    * has built-in support for multiple values
      多値の組み込みでのサポートがある
    * has built-in support for complex function parameter lists (&rest, &optional,
      &key)
      組み込みで関数の複雑なパラメータリストのサポート(&rest, &optional,
      &key)がある
    * has built-in support for various forms of declarations (type, optimizations,
      dynamic extent, ...)
多様な宣言形式の組み込みでのサポートがある(type, optimizations,
      dynamic extent, ...)
    * has built-in support for reading and writing sequences from streams
ストリームに対するシーケンスの読み出し/書き込みの組み込みでのサポートがある
    * treats t and other values as "true" and NIL as "false"
      t と "true"、NIL と"false"とを別の値として扱う

Scheme:

    * has a fairly minimal set of built-in procedures
      最小限の数にとどめられた組み込み手続き
    * has CallWithCurrentContinuation (which lets you express some amazing stuff but
      which also makes it tricky to express UNWIND-PROTECT)
      CallWithCurrentContinuation を持っている。
    * has a hygienic, referentially transparent macro system based on rewrite rules 
      (DefineSyntax), but most SchemeImplementations have one or more additional macro 
      systems more like the CL one (some of them clones), since some things are tricky to 
      express in standard scheme macros.
    * many schemers believe it has cleaner semantics, particularly a single namespace 
      and consistent use of lexical scoping (but see HyperStaticGlobalEnvironment)
    * evaluates the function position of a function call the same way as the argument positions
    * requires support for TailCallOptimization
      呼び出しの末尾最適化のサポートが必須とされている。
    * is a small language, with both the positive and negative implications.
      小さな言語である。
    * many standard forms in Scheme have an undefined result value, and the order of 
      function argument evaluation is unspecified.
    * doesn't use the same value for failure, falsity and the empty list.
      failure、falsity (偽?)、空リストで同じ値を使っていない
    * is a SingleNamespaceLisp.
      単一名前空間なLispである



The Beauty of Lisp-1: LispCast

I started working with Clojure after OOPSLA. Clojure is a Lisp-1.* I had never 
seriously used a Lisp-1 before Clojure. I was exposed to Scheme, but not to a great 
extent. I have always considered Lisp-1 to be the more elegant in theory and Lisp-2 to 
be the more practical. However, Clojure innovates in its approach to evaluation past 
the Lisp-1/Lisp-2 dichotomy and reveals serious research into the art of language 
design.

Lisp-1 encourages a very elegant style. A Lisp-1 has no need of flet or labels , since 
a let will do. Also, funcall is not needed. It arguably encourages a more functional 
style, since no distinction is made between the function value of a name and the 
non-function value of a name. The elegance and beauty lie in the consistent treatment 
of function and non-function values.

This elegance comes at a cost. Name collisions are more frequent in a Lisp-1. In 
Common Lisp (a Lisp-2), I can name a parameter list without conflicting with the 
function called list . Not so in Clojure. I also lose the helpful visual hints that a 
symbol is being treated as a function, namely #'cons and (funcall f 13) . If I am not 
accustomed to reading higher-level code, I might find it easier to read code that is 
explicit about when a value is being treated as a function. These tradeoffs are subtle 
and will inevitably displease some programmers.*

But Clojure has dealt with these tradeoffs beautifully. #'cons will normally evaluate 
to the cons function, even when cons is bound in a surrounding let . But so does cons 
alone when cons is not bound in a let .* Clojure is more functional in style than 
Common Lisp, so it makes sense to encourage treating functions like other values. 
Further, Clojure treats :keywords , vec 's, and map 's as functions. Having to funcall 
them would reduce their usefulness. Lisp-1 in Clojure works to make it the elegant 
language that it is.

I did not originally appreciate that Clojure is a Lisp-1. I was used to Common Lisp. 
But with use, I revealed its beauty. Though some tradeoffs were necessarily made, 
Lisp-1 was a decision consistent with its other design choices. In the end, it comes 
down to this: every decision point in language design is an opportunity to reiterate, 
refine, and uncover the beauty of the language. Clojure has only just begun to chart 
its way through design space. I am optimistic about Clojure and its future.

*Lisp-1: a Lisp with a single namespace for function definitions and variables. In 
other words, the first element of a function call s-expression is evaluated in the 
same way as the rest of the elements. Examples: Scheme and Clojure.

Lisp-2: a Lisp with distinct namespaces for functions and variables. The first element 
of a function call has different evaluation semantics from the rest of the elements. 
Example: Common Lisp.

■_ Perl 6

開発者オンラインミーティングの議事録から。 

use Perl | Perl 6 Design Minutes for 07 January 2009
Perl 6 Design Minutes for 07 January 2009
Journal written by chromatic (983) and posted by brian_d_foy on 2009.01.28 13:16   Printer-friendly
User Journal

The Perl 6 Design Team met by phone on 07 January 2009. Larry, Jerry, Allison, Patrick, 
Jesse, and chromatic attended.

Larry:

    * real life has been hectic
    * some family sickness
    * lots of meetings at work
    * mostly just sniping at various design issues
    * not a lot of bandwidth to think through deeper questions
    * periodically running tests on STD to make sure it keeps passing tests
    * not much exciting coming up until April
    * going to Oslo, and then a tour of Ivy League colleges

Jesse:    * will you need to add tasks to the roadmap?

Patrick:  * I can't think of any we need to add

Patrick:  * lots of them say "Not everything works, but the progress is amazing!"

Jerry:    * your post on the Winter Scripting Games sparked a lot of activity

Jesse:    * pondering quite a bit lately

Jesse:    * looking for suggestions for people to take over Perl 6 coordination

Larryの家族が病気というのは前々回くらいからあったと思うけどインフルエンザとか? にしても今度はオスロですか。世界中飛び回ってるなあ。

■_ x86 の NOPのビットパターンでどんなだったったけ?

十六進だと 90 だったと思うけど。 ビットパターンで見てくと無意味な命令に解釈できたような記憶が。 



無差別に技術をついばむ鳥 C言語の奥をつつく1ーmain関数は初めの関数じゃない！

Cの奥をつつくためにまずやるべきことは、最小の情報を解析する事ピヨ。
だからボクは次のCファイルを用意したピヨ。


//mini.c
void main(){}



どう？最小でピヨピヨ？という事で早速コンパイルしよう。一々開発環境で新規プロジェクトの
作成をするのは面倒だからコマンドラインでコンパイルしよう！

まずはVS Toolの方のコマンドラインプロンプトを立ち上げてから次の手順でコンパイルしてね。

cd /d ファイルパス
cl mini.c /FA


次回からはコンパイル方法を省略するからよく覚えておいてね。じゃあ早速asmファイルを見て
みよう。※画面の都合で一部改行しています


; Listing generated by Microsoft (R) 
;Optimizing Compiler Version 15.00.21022.08 

	TITLE	ファイル名
	.686P
	.XMM
	include listing.inc
	.model	flat

INCLUDELIB LIBCMT
INCLUDELIB OLDNAMES

PUBLIC	_main
; Function compile flags: /Odtp
_TEXT	SEGMENT
_main	PROC
; File ファイル名
; Line 1
	push	ebp
	mov	ebp, esp
	xor	eax, eax
	pop	ebp
	ret	0
_main	ENDP
_TEXT	ENDS
END


流石最小のコード！凄くシンプルピヨ♪このコードがやっている事は、 「EBPレジスタの値をス
タックに退避して、すぐに値を戻して、もと来た場所へ戻る。」だけなんだ。ちなみに、xor 
eax, eaxは何もしない命令ピヨ。何でこんなものが必要なのかというとデバッグ時にブレークポ
イントを仕掛けるためなんだ。これがないとmain関数内でブレークポイントを作れないからね。
もちろんこれは、最適化されると消えるピヨ。

この最小のコードから分かる事はmain関数以外にも処理がある事ピヨ。何で分かるかって？だっ
て、retで戻っているんだもん。これでわかったと思うけど、C言語はmain関数以外にも様々な処
理があるんだ。それは何の処理かと囀ると、環境変数の初期化、スタックに必要なヒープの確
保・・・などのCを実行する上で必要な準備ピヨ。それで、何で終わったら戻るのかというと処
理が正常か判断するためなんだ。C言語を触った事ある人ならば最後にreturn 0;とかするのは知
っているよね？その値を受け取る処理が必要というわけさ。

今回はこれで終わり。


この記事のコメント
2009-01-31 Sat 08:42 | URL | baka #en9qG856[ 編集]

最適化されると消えるのでしょうか
単なる戻り値でしょう


2009-01-31 Sat 09:59 | URL | インドリ #-[ 編集]
うーん。書いてある内容分かっていないね。
xor eax, eaxが最適化されたら消えるといっているんだよ。
これは戻り値じゃないよ。
xor命令なんだから・・・

2009-01-31 Sat 23:42 | URL | C入門者 #-[ 編集]
戻り値はeaxに入れるでしょ。だからeaxをxorを使ってゼロに設定しているんだよ。
ソースに書かなくてもreturn 0を暗黙のうちにコンパイラが生成しているわけ。理解している？

2009-02-01 Sun 00:14 | URL | インドリ #-[ 編集]
おっと、ごめんごめん。
デバッグ情報生成にしているとよくある
xchg eax, eax（nop）
と見間違ったよ。

最適化を有効にして同じことやればすぐわかるのに。 消えるのはむしろ ebp レジスター絡みのスタックフレーム部分。 ローカル変数も何もないから作る必要がない。 つーかどこのデバッガーなりが NOP の逆アセンブル(だろう、多分)を xchg eax, eax にするの?

「EBPレジスタの値をスタックに退避して、すぐに値を戻して、もと来た場所へ戻る。」 って、mov ebp, esp の意図を勘違いしてない?

ちなみに、xor eax, eaxは何もしない命令ピヨ。何でこんなものが必要なのかというとデバッグ時にブレークポ イントを仕掛けるためなんだ。 …えーと? まあコメントですでに解説されてるけど、にしてもブレークポイントしかけるためって。

それは何の処理かと囀ると、環境変数の初期化、スタックに必要なヒープの確保・・・などのCを実行する上で必要な準備ピヨ。 環境変数はまあ微妙だからおいといて、 「スタックに必要なヒープの確保」ってどゆこと?

2009年01月30日

■_

・セキュアプログラミング
一昨日の開催当日になって知ったのですが(当然参加申し込みは締め切り)、 セキュアプログラミングのセミナーなんてのが神保町あたりで開催されたのですね。 平日の午後という時間帯なのであらかじめ知っていたとしても参加できたかは微妙なところですが んーくやしいw

■_ いろんなGUIでhello, world

むかーし(笑)、名前のXでの hello, worldの行数見てひっくり返ったことが。 まあWindowsやらMac OSでも大差なかったけど。 

GUI "Hello World" examples in C - Stack Overflow
http://stackoverflow.com/questions/489858/gui-hello-world-examples-in-c

I would like us to put here "Hello World" example programs (one in each answer) using 
various GUI libraries.

The purpose:

    * we can decide which GUI library looks best by comparing
    * we can educate us

The question:

    * Because this post is not a question (so there is no good answer) you can vote for
      answers if you like the code or if you like that library, so the question could be: 
      What GUI library if best for C developers?

Program should:

    * be written in C
      Cで書かれていること
    * show window that displays (in title or in label inside it) "Hello World"
      "Hello World" という文字列がタイトルもしくはウィンドウ内にラベルに描画された
      ウィンドウを表示させる。
    * be as short as possible, but not lack something important for understanding basic concept
      可能な限り短く記述。ただし基本的なコンセプトを理解するのに重要なことを欠いてはいけない
    * be commented
      コメントをつける
    * expect primarily linux environment
      primarily に Linxu 環境で

You could also show a link to site of library used and a instruction to compile program.

  

#include < gtk/gtk.h >

/* callback function */
void quit (GtkWidget *, gpointer);

int
main (int argc, char *argv[])
{
  GtkWidget *window;
  GtkWidget *label;

  /* ライブラリの初期化 */
  gtk_init (&argc, &argv);

  /* メインウィンドウとラベルを作成 */
  window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
  label = gtk_label_new ("Hello World");

  /* ウィンドウのタイトル、大きさ、表示位置を設定 */
  gtk_window_set_title        (GTK_WINDOW (window), "Hello World");
  gtk_window_set_default_size (GTK_WINDOW (window), 300, 300);
  gtk_window_set_position     (GTK_WINDOW (window), GTK_WIN_POS_CENTER);

  /* ウィンドウはコンテナーなのでラベルを追加できる */
  gtk_container_add (GTK_CONTAINER (window), label);

  /* コールバック関数を登録, called when user closes the window */
  g_signal_connect (G_OBJECT (window), "destroy", G_CALLBACK (quit), NULL);

  /* ウィンドウとその子をスクリーンに表示 */
  gtk_widget_show_all (window);

  /* start the main loop that waits for user action */
  gtk_main ();

  return 0;
}

/* コールバック関数 */
void
quit (GtkWidget *window, gpointer data)
{
  /* this quits main loop when window is closed */
  gtk_main_quit ();
}

Library is GTK+ and you can compile with:


gcc hello.c `pkg-config --cflags gtk+-2.0` `pkg-config --libs gtk+-2.0`

  
#include <curses.h>
#include <unistd.h>

int main(void)
{
     // initialize and draw box
     initscr();
     WINDOW* screen = newwin(10, 20, 1, 1);
     box(screen, ACS_VLINE, ACS_HLINE);

    // draw text
    curs_set(0);
    mvwprintw(screen, 1, 1, "Hello, World!");
    wrefresh(screen);

    // wait for termination
    pause();
    endwin();
    return 0;
}

Uses Curses. Compile with:

cc -lcurses <file>

  
Qt 4 (C++)

#include <QApplication>
#include <QPushButton>

int main(int argc, char **argv)
{
    QApplication app(argc, argv);

    /* ボタンを作成してそれをウィンドウとして表示 */
    QPushButton button("Hello, world!");
    button.show();

    /* ボタンがクリックされたらアプリケーションを閉じる */
    QObject::connect(&button, SIGNAL(clicked()), &app, SLOT(quit());

    /* イベントループの実行 */
    return app.exec();
}

  
IUP:

#include <iup.h>
#include <stdlib.h>

int
main(int argc, char *argv[])
{
    IupOpen(&argc, &argv); /* ツールキットの初期化 */

    /* 子ラベルを持ったダイアログを表示 */
    IupShow(IupDialog(IupLabel("Hello, world!")));

    IupMainLoop();         /* メッセージループの実行 */

    IupClose();            /* ツールキットの後始末 */

    return 0;
}

Compile under Linux/Unix:

gcc hello.c -liup -lXm -lXmu -lXt -lX11 -lm

Compile under Windows (MinGW):

gcc hello.c -liup -liupcontrols --lcomctl32 -lole32 -lgdi32 -lcomdlg32

■_

History of Python のやってなかった方。 

The History of Python: Microsoft Ships Python Code... in 1996
http://python-history.blogspot.com/2009/01/microsoft-ships-python-code-in-1996.html

My thanks go to Guido for allowing me to share my own history of Python!

I'll save my introduction to Python for another post, but the end result was its
introduction into a startup that I co-founded in 1991 with several people. We were
working on a large client/server system to handle Business-to-Consumer electronic
shopping. Custom TCP protocols operating over the old X.25 network, and all that.
Old school.

わたしとPythonとの出会いの詳細は別の機会に譲りますが
一言で言えば数人の仲間と一緒に 1991年に co-found した startup でのことになります。
わたしたちは B2C (Business-to-Consumer) 電子ショッピングを取り扱う
大規模なクライアント/サーバーシステムに取り組んでいました。
カスタマイズした TCP プロトコルが古い X.25 ネットワーク上で処理していてそれがすべてでした。
Old school.


In 1995, we realized, contrary to our earlier beliefs, that more consumers actually
were on the Internet, and that we needed a system for our customers (the vendors) to
reach Internet-based consumers. I was tasked to figure out our approach, and selected
Python as my prototyping tool.

1995年のことですが、わたしたちの earlier beliefs に反して実際には想定していたよりも
もっと多くの消費者がインターネット上にいて、自分たちは顧客(ベンダー)向けの
インターネットベース経由の消費者のためのシステムを必要としていたということを認識しました。
I was tasked to figure out our approach,
Python をわたしのプロトタイプ用ツールとして選択したのです。

Our first problem was moving to an entirely browser-based solution. Our custom client
was no longer viable, so we needed a new shopping experience for the consumer, and
server infrastructure to support that. At that time, talking to a web browser meant
writing CGI scripts for the Apache and Netscape HTTP servers. Using CGI, I connected
to our existing server backend to process orders, maintain the shopping basket, and to
fetch product information. These CGI scripts produced plain, vanilla HTML (no AJAX in
1995!).

わたしたちが最初に直面した問題は完全にブラウザーベースのソリューションへ移行する
ということでした。わたしたちのカスタムクライアントはもはや viable ではなかったので
わたしたちは顧客に対する新しい shopping experience と
それをサポートするためのサーバーインフラストラクチャーを必要としていました。
その頃webブラウザーとやり取りするということは、
Apache や Netscape HTTP サーバー向けにCGIスクリプトを書くということでした。
バックエンドにあるサーバーに接続してオーダーを処理処理するために
買い物カゴの maintain をしたり商品の情報を取り出すということは CGIを使って行っていました。
そういったCGIスクリプトは plain で素の HTML (1995年にはAJAXはありません!)を
生成していました。


This approach was less-than-ideal since each request took time to spin up a new CGI
process. The responsiveness was very poor. Then, in December 1995, while attending the
Python Workshop in Washington, DC, I was introduced to some Apache and Netscape
modules (from Digital Creations, who are best known for Zope) which ran persistently
within the server process. These modules used an RPC system called ILU to communicate
with backend, long-running processes. With this system in place, the CGI forking
overhead disappeared and the shopping experience was now quite enjoyable! We started
to turn the prototype into real code. The further we went with it, the better it
looked and more people jumped onto the project. Development moved very fast over the
next few months (thanks Python!).

このようなやり方はリクエストがあるたびに新規のCGIプロセスを立ち上げてる時間が必要だった
ので理想とは程遠いものであり、その応答性と来たら貧弱もいいところでした。
そして1995年の12月に Washignton, DC で行われていた Python Workshop に出席していたときに
サーバープロセスの中で永続的に実行されるいくつかのApache や Netscape のモジュールを紹介しました
(from Digital Creations, who are best known for Zope)。
これらのモジュールは long-running なプロセスで、バックエンドとのやりとりのために
ILUと呼ばれていた RPC システムコールを使っていました
このシステムを導入することによってCGI の forking overhead が解消され、
買い物が快適にできるようになったのです!
わたしたちはこのプロトタイプを real code への変換を始めました。
The further we went with it, the better it looked and more people jumped onto the project.
Development moved very fast over the next few months (thanks Python!).


In January 1996, Microsoft knocked on our door. Their internal effort at creating an
electronic commerce system was floundering, and they needed people that knew the
industry (we'd been doing electronic commerce for several years by that point) and
somebody who was nimble. We continued to develop the software during the spring while
negotiations occurred, and then the acquisition finalized in June 1996.

1996年の一月、Microsoft がわたしたちのドアをノックしました。
電子コマースシステムを作る彼らの internal effort はfloundering,
そして彼らは industry (わたしたちはその時点ですでに何年も電子商取引 (electronic commerce)
を行っていました)を知っていて、機転が利く誰か(somebody who was nimble)を必要としていたのです。
わたしたちは交渉が行われていた春の間開発を継続し、1996年の6月に完了しました。

Once we arrived at Microsoft with our small pile of Python code, we had to figure out
how to ship the product on Windows NT. The team we joined had lots of Windows
experience and built an IIS plugin to communicate over named pipes to the backend
servers, which were NT Services with our Python server code embedded. With a mad
sprint starting in July, we shipped Microsoft Merchant Server 1.0 in October, 1996.

わたしたちは自分たちの small pile of Python code を携えて Microsoftに到着したときに
その製品をWindows NT上でどのようにして ship するのかを figure out しなければなりませんでした。
わたしたちが join したチームはWindowsそのものと名前つきパイプ (named pipe) 上でバックエンド
サーバーと通信するIIS プラグインについての豊富な経験がありました。
このIISプラグインがわたしたちのPython サーバーコードが埋め込まれていたNT サービスでした。
With a mad sprint starting in July, 
わたしたちは1996年の十月、Microsoft Merchant Server 1.0 を出荷したのでした。

And yes... if you looked under the covers, somewhat hidden, was a Python interpreter,
some extension DLLs, and a bunch of .pyc files. Microsoft certainly didn't advertise
that fact, but it was there if you knew were to look.

そして、もしカバーをめくって隠されているものを見てみたら、そこにはPython インタープリター
といくつかの拡張 DLL、そしてたくさんの .pyc ファイルがあります。Microsoft はこの事実を
積極的に公にはしていませんが、見方を知っていればそれがあるのがわかります。

Posted by Greg Stein at 6:40 AM

■_ Safer Alternatives to the C Standard Library - Stack Overflow

ライブラリの脆弱性とか。 

Safer Alternatives to the C Standard Library - Stack Overflow

The C standard library is notoriously poor when it comes to I/O safety. Many functions 
have buffer overflows (gets, scanf), or can clobber memory if not given proper 
arguments (scanf), and so on. Every once and awhile, I come across an enterprising 
hacker who has written his own library that lacks these flaws.

Cの標準ライブラリのI/O safete についての貧弱さは広く知れ渡っています。
多くの関数はバッファーオーバーフローするし(getsやscanfなど)、
適切な引数を与えないとメモリを引っ掻き回す可能性があったり(scanf)します。
Every once and awhile, I come across an enterprising hacker
who has written his own library that lacks these flaws.


What are the best of these libraries you have seen? Have you used them in production 
code, and if so, which held up as more than hobby projects?
これまであなたが見てきたこの種のライブラリの中で最も良かったのはなんですか?
hobby projects ではなくもっと規模の大きな
製品コードでそれを使ったことはありますか?


Use C++ with STL as a "better C". It's an ANSI standard, with more users 
than any library you'll name. Why not prefer that to C?

"better C" としてSTLつきのC++を使う。
これは ANSI標準で、
あなたが名前を挙げるであろうライブラリのどれよりもユーザー数が多い。
なんで Cを使いたがるの?


As an example of what I'm talking about, D.J. Bernstein, better known as djb, author 
of djbdns and qmail, has created adjbli, which provides a fast, tight, secure 
alternative to many C standard library functions.

djbdsn や qmail の作者で dbj としてよく知られている D.J. Bernstein が
adjbli というfast, tight, secure な標準のCライブラリ関数の多くを置き換えるようなものを
作っている。


This isn't really answering your question about the safest libraries to use, but most 
functions that are vulnerable to buffer overflows that you mentioned have safer 
versions which take the buffer length as an argument to prevent the security holes 
that are opened up when the standard methods are used.

これは最も安全なライブラリをというキミの質問に対する直接の回答ではないのだけど、
キミが指摘したようなバッファーオーバーフローなどの脆弱性を抱えた関数の大部分は
バッファの長さも引数に取るなどしてセキュリティに考慮した
より安全なバージョンのものを持っている。

Unless you have relaxed the level of warnings, you will usually get compiler warnings 
when you use the deprecated methods, suggesting you use the safer methods instead.

キミが警告に無頓着でないのなら、キミが指摘しているような非推奨の関数を
使ったらコンパイラーが警告を出しているはずだ。警告を出されたものの
より安全なメソッドを使うことをおススメするね。

Maybe the first question to ask is if your really need plain C? (maybe a language like 
.net or java is an option - then e.g. buffer overflows are not really a problem anymore)

最初の質問については本当に素のCでやる必要があるのかということを確認したい
(おそらく.NETやJavaのようなバッファオーバフローの心配がない言語が選択肢にあると思う)

Another option is maybe to write parts of your project in C++ if other higher level 
languages are not an option. You can then have a C interface which encapsulates the 
C++ code if you really need C.

C以外の高水準言語を使うという選択ができないとして
もう一つの選択肢はあなたのプロジェクトの一部をC++で書くというものだろう。
本当にCが必要だということならC++で書いたコードをカプセル化して
C のインターフェースでくるんでしまえばいい。

Because if you add all the advanced functions the C++ standard library has build in - 
your C code would only be marginally faster most times (and contain a lot more bugs 
than an existing and tested framework).

Check this out

ここをチェックしてみて。


For Windows there is a 'safe' C/C++ library.

Windows 向けだったら 'safe'なC/C++ライブラリがあるよ。

んで、最後から二つ目のリンク先。 

AIST Develops Safe C for Embedded Development -- Nikkei Electronics Asia -- August 2008 - Tech-On!
http://techon.nikkeibp.co.jp/article/HONSHI/20080729/155648/

AIST Develops Safe C for Embedded Development

Nikkei Electronics Asia -- August 2008
digg This!
E-Mail Article
del.icio.us

C-based software development is plagued by memory-related bugs, such as buffer 
overflows, but now there is a C-language processing system that avoids, in principle, 
all these bugs: Fail-Safe C, developed by Yutaka Oiwa of the Research Center for 
Information Security, National Institute of Advanced Industrial Science and Technology 
(AIST) of Japan. Java is a famous example of a language that avoids memory bugs, but 
the new approach delivers the same level of safety in C. Release 1, for 86-family 
processors, was released in April 2008.

(略)

One important feature of Fail-Safe C is that source code written in C can be used 
without rewriting: just recompile it to get an application free of memory bugs. It is 
highly compatible with the American National Standards Institute (ANSI) C standard, 
too. Application operability has been confirmed for the OpenSL encryption library, 
OpenSSH remote access, BIND 9 name server and others.

(略)

これって見覚えがあるなあ。名前は忘れてたけど。 って、これか https://staff.aist.go.jp/y.oiwa/FailSafeC/ http://www.rcis.aist.go.jp/project/FailSafeC-ja.html

■_ 

The Collected Words of Graham Poulter: Bad Python
http://grahamweekly.blogspot.com/2009/01/bad-python.html

PL Grand Challenges
http://plgrand.blogspot.com/

Perl and London Broil: The future of programming magic - Fozzolog
http://www.fozzilinymoo.org/Fozzolog/2009/01/perl-and-london-broil-the-futu.html

OCaml/guideline - U-Wiki+
http://www.math.sansu.org/u/pwplus/index.php?OCaml%2Fguideline

Why Perl 5.10 is Modern and Perl 5.8.9 is Legacy - Modern Perl Books
http://www.modernperlbooks.com/mt/2009/01/why-perl-510-is-modern-and-perl-589-is-legacy.html

Has anyone here ever used FORTRAN? : programming
http://www.reddit.com/r/programming/comments/7tjgr/has_anyone_here_ever_used_fortran/

なんか「俺は FORTRAN IIから使ってますけどなにか?」なコメントがあってびびったw

Lisp Scheme Differences
http://c2.com/cgi/wiki?LispSchemeDifferences


strlcpy and strlcat - consistent, safe, string copy and concatenation. : programming
http://www.reddit.com/r/programming/comments/7tjk1/strlcpy_and_strlcat_consistent_safe_string_copy/

strlcpy and strlcat - consistent, safe, string copy and concatenation.
http://www.gratisoft.us/todd/papers/strlcpy.html

なんか似たような話題が同時期に出るなあ。

そりゃあうるりっひの言うことは正しいだろうけどさ、現実にはそれを守れなくて
脆弱性抱えてしまっているプログラムがあるわけだよね。
であれば、バッファや文字列の長さを常に意識させるためにも strlcpy のようなのを
使うのは意味があるんじゃないのかなあ。


http://stackoverflow.com/questions/494389/why-doesnt-sun-do-a-c-to-java-byte-code-compiler
http://stackoverflow.com/questions/494192/how-can-i-become-a-better-c-programmer
http://stackoverflow.com/questions/494653/how-can-i-use-trace-macro-in-non-mfc-projects

今日の redditと stackoverflow はなかなか興味深いのが多かったので
できるだけ紹介したい。なあ。

■_ リリース

関係者各位お疲れ様でした。 

[ruby-list:45836] [ANN] Ruby 1.9.1リリース

Yuguiです。

Ruby 1.9.1をリリースしました。これは1.9系統初の安定版リリースです。

Ruby 1.9はRubyの新しい系統です。近代的に、高速に、文法も明確に、多言語化
され、多くの改善がなされました。Ruby 1.8系統は2003年以来利用され、多くの
素晴らしい製品を生み出しました。本日、1.9の歴史が始まります。

なお、Ruby 1.8はまだ継続します。1.8.8は今年くらいにはリリースされるで
しょう。

== 変更点
1.8.7以来の主な変更点は下記URLから参照できます。
http://svn.ruby-lang.org/repos/ruby/tags/v1_9_1_0/NEWS .

1.9.1 RC2以降7つのバグを修正しました。
 http://redmine.ruby-lang.org/projects/ruby-19/issues?query_id=11

もしバグや問題を発見なさいましたら、公式課題追跡システム(http:
//redmine.ruby-lang.org )を通じてお知らせください。

(以下略

自炊するか、artonさんのパッケージを待つか。

2009年01月29日

■_

・矢沢本
新しいのが出てたので買ってみた。 ほんとーにJavaキライなんだなあw
ifとelseの思考術 プログラマ脳育成講座
あと正直申し上げて今日び「プログラマ脳」とか書くのはいかがなものかと。

・みつからない
商品詳細 CD DJCD さよなら絶望放送 出張盤(仮) がみつからないでごじゃるよ。おろろーん。

■_ The History of Python: Personal History - part 2, CNRI and beyond

中途半端に英語が残っている部分は例によっておいおい。 

The History of Python: Personal History - part 2, CNRI and beyond "Personal History - 
part 2, CNRI and beyond
http://python-history.blogspot.com/2009/01/personal-history-part-2-cnri-and-beyond.html

The Python workshop (see previous posting) resulted in a job offer to come work on 
mobile agents at CNRI (the Corporation for National Research Initiatives). CNRI is a 
non-profit research lab in Reston, Virginia. I joined in April 1995. CNRI's director, 
Bob Kahn, was the first to point out to me how much Python has in common with Lisp, 
despite being completely different at a superficial (syntactic) level. Python work at 
CNRI was funded indirectly by a DARPA grant for mobile agent research. Although there 
was DARPA support for projects that used Python, there was not much direct support for 
language development itself.

Python ワークショップ (以前のポストを参照すること) は CNRI (the Corporation for National
Research Initiatives) におけるモバイルエージェントに関する come work の job offer となりました。
CNRI は非営利目的の research lab で、ヴァージニア州の Reston にあります。
わたしは1995年に joinしました。
CNRI のディレクターであった Bob Kahn は
Python と Lisp とが superficial (syntactic) level においては全く違ったものであるにも
関わらず共通点がどれほどあるのかを最初にわたしに指摘しました。
CNRI における Python work はモバイルエージェントの研究という名目で
DARPA から間接的に資金援助されていました。
プロジェクトに対するDARPAのサポートはPythonを使っていたにも関わらず
言語の開発そのものに対しての直接のサポートはそれほどでもありませんでした。


At CNRI, I led and helped hire a small team of developers to build a mobile agent 
system in pure Python. The initial team members were Roger Masse and Barry Warsaw who 
were bitten by the Python bug at the Python workshop at NIST. In addition, we hired 
Python community members Ken Manheimer and Fred Drake. Jeremy Hylton, an MIT graduate 
originally hired to work on text retrieval, also joined the team. The team was 
initially managed by Ted Strollo and later on by Al Vezza.

CNRIでわたしはPythonだけのモバイルエージェントシステムを構築しようと目論見、
小規模なチームを雇いました。
初期のチームメンバーはNIST での Python ワークショップで Python のバグを退治していた
Roger Masse と Barry Warsaw です。
わたし達はさらに Python コミュニティのメンバーである
Ken Manheimer と Fred Drake を雇いました。
MIT の graduate originally hired to work on text retrieval であった
Jeremy Hylton もチームに参加しました。
このチームは最初は Ted Strollo が、後には Al Vezza がマネージャを務めました。


This team helped me create and maintain additional Python community
infrastructure such as the python.org website, the CVS server, and the
mailing lists for various Python Special Interest Groups. Python
releases 1.3 through 1.6 came out of CNRI. For many years Python 1.5.2
was the most popular and most stable version.

このチームは、わたしがウェブサイト python.org や CVSサーバー、
様々な Python Special Interest Groupsのためのメーリングリストといった
Pythonコミュニティの付加的なインフラを立ち上げて保守するのを助けてくれました。
Python のリリース 1.3 から 1.6 までは came out of CNRI でした。
Python 1.5.2 は長いこともっとも使われていて、また最も安定していたバージョンでした。

GNU mailman was also born here: we originally used a Perl tool called Majordomo, but 
Ken Manheimer found it unmaintainable and looked for a Python solution. He found out 
about something written in Python by John Viega and took over maintenance. When Ken 
left CNRI for Digital Creations, Barry Warsaw took over, and convinced the Free 
Software Foundation to adopt it as its official mailing list tool. Hence Barry 
licensed it under the GPL (GNU Public License).

GNU mailman もまたここで生まれています:
わたし達は元々は Majordomo というPerl tool を使っていたのですが、
Ken Manheimer はそれが unmaintainable であると感じたので
Python を使ったソリューションを求めていました。
彼は John Viega がPython で書いたものを見つけ、そのメンテナンスを引き継ぎました。
そして Free Software Foundation に彼らの公式のメーリングリスト用ツールとして
adopt するよう convinced したのです。
Hence Barry はこれを GPL (GNU Public License) でライセンスしました。


The Python workshops continued, at first twice a year, but due to the growth and 
increased logistical efforts they soon evolved into yearly events. These were first 
run by whoever wanted to host them, like NIST (the first one), USGS (the second and 
third one) and LLNL (the fourth one, and the start of the yearly series). Eventually 
CNRI took over the organization, and later (together with the WWW and IETF conferences) 
this was spun off as a commercial effort, Fortec. Attendance quickly rose to several 
hundreds. When Fortec faded away a while after I left CNRI, the International Python 
Conference was folded into O'Reilly's Open Source Conference (OSCON), but at the same 
time the Python Software Foundation (see below) started a new series of grassroots 
conferences named PyCon.

Python ワークショップは継続していて、最初は年に二回行われていましたが
規模が拡大して logistical efforts が増大したために
すぐに一年に一回というペースになりました。
These were first run by whoever wanted to host them,
like NIST (the first one), USGS (the second and third one)
and LLNL (the fourth one, and the start of the yearly series).
CNRI さえも組織を take over し、そしてそれは後に
(WWWとIETF conferences を共に)commercial effort である Fortec として spin off しました
Attendance quickly rose to several hundreds. 
わたしが CNRIを離れたあとで Fortec が faded away したときに
International Python Conference が
O'Reilly's Open Source Conference (OSCON) に
folded into しましたが、それと同時に
Python Software Foundation (後述します) が
PyCon という名称の新しいgrassroots conferences を始めました。


We also created the first (loose) organization around Python at CNRI. In response to 
efforts by Mike McLay and Paul Everitt to create a "Python Foundation", which ended up 
in the quicksand of bylaw drafting, Bob Kahn offered to create the "Python Software 
Activity", which would not be an independent legal entity but simply a group of people 
working under CNRI's legal (non-profit) umbrella. The PSA was successful in rallying 
the energy of a large group of committed Python users, but its lack of independence 
limited its effectiveness.

わたし達はまたCNRI でPythonに関係した最初の(loose) organizationを立ち上げました。
Mike McLay と Paul Everitt の尽力によって
ended up in the quicksand of bylaw drafting な "Python Foundation" が設立されました。
Bob Kahn はCNRIから法的に独立したものではないけれども
CNRIの(non-profitな)法的な傘の下の単純なgroup of people working である
"Python Software Activity" の設立を提案しました。
この PSA はコミットしたPyhton ユーザーの大きなグループの力を集めるのには成功したのですが、
その限定された effectiveness (有効性)のために independence に欠けていました。


CNRI also used DARPA money to fund the development of JPython (later shortened to 
Jython), a Python implementation in and for Java. Jim Hugunin initially created 
JPython while doing graduate work at MIT. He then convinced CNRI to hire him to 
complete the work (or perhaps CNRI convinced Jim to join -- it happened while I was on 
vacation). When Jim left CNRI less than two years later to join the AspectJ project at 
Xerox PARC, Barry Warsaw continued the JPython development. (Much later, Jim would 
also author IronPython, the Python port to Microsoft's .NET. Jim also wrote the first 
version of Numeric Python.)

CNRI は DARPAからの資金をJavaによって実装されたJava向けの処理系であるJPython の
開発のためにも使っていました(JPython は後に Jythonと縮められました)。
Jim Hugunin は MIT で graduate work を行っているときにJPython を作成しました。
彼はそれから
convinced CNRI to hire him to complete the work
(or perhaps CNRI convinced Jim to join -- それはわたしが休暇中に起こりました)。
Jim がXerox PARC に AspectJプロジェクトへ参加するために
二年も経たずにCNRI を離れたとき、Barry Warsaw がJPython の開発を継続しました。
ずっと後になって、Jim はIronPython の authour にもなっています。
IronPython はMicrosoft の .NET に移植されたPythonです。
また、Jim はNumreic Python の first version も書いています。

Other projects at CNRI also started to use Python. Several new core Python developers 
came out of this, in particular Andrew Kuchling, Neil Schemenauer, and Greg Ward, who 
worked for the MEMS Exchange project. (Andrew had contributed to Python even before 
joining CNRI; his first major project was the Python Cryptography Toolkit, a third 
party library that made many fundamental cryptological algorithms available to Python 
users.)

CNRI での他のプロジェクトもPython を使うために開始されています。
何人かの Python のコア開発者たちが新たに加わりました。
MEMS Exchange プロジェクトの作業を行った
Andrew Kuchling, Neil Schemenauer, Greg Ward がここに含まれます。
Andrew は CNRIに就職する前から Python に貢献しています。
彼の最初の major project は多くの基本的な暗号化アルゴリズムを
Pythonユーザーが使えるようにするサードパーティライブラリである
Python Cryptography Toolkit (Python暗号化ツールキット)でした。

On the wings of Python's success, CNRI tried to come up with a model to fund Python 
development more directly than via DARPA research grants. We created the Python 
Consortium, modeled after the X Consortium, with a minimum entrance fee of $20,000. 
However, apart from one group at Hewlett-Packard, we didn't get much traction, and 
eventually the consortium died of anemia. Another attempt to find funding was Computer 
Programming for Everybody (CP4E), which received some DARPA funding. However, the 
funding wasn't enough for the whole team, and it turned out that there was a whole 
old-boys network involved in getting actually most of the money spread over several 
years. That was not something I enjoyed, and I started looking for other options.

On the wings of Python's success, CNRI tried to come up with a model to fund Python 
development more directly than via DARPA research grants.
わたしたちは X コンソーシアムに倣って Python コンソーシアムを立ち上げました。
このコンソーシアムに対する minimum entrance fee は 二万ドルでした。
しかしながら Hewlett-Packard 以外に十分な traction を我々は得ることができずにいたので
このコンソーシアムは died of anemia したのでした。
#anemia → 貧血、無気力、虚弱
#died of anemia → 衰弱死?
これとは別の資金を求める努力に Computer Programming for Everybody (CP4E) がありました。
これは部分的にですが DARPA からの資金を受けています。
しかしその資金はチーム全体に行き渡らせるには十分ではく、
and it turned out that there was a whole old-boys network
involved in getting actually most of the money spread over several years.
こういったことはわたしにとって楽しいことではなかったので、他の選択肢を求めることにしました。

Eventually, in early 2000, the dot-com boom, which hadn't quite collapsed yet, 
convinced me and three other members of the CNRI Python team (Barry Warsaw, Jeremy 
Hylton, and Fred Drake) to join BeOpen.com, a California startup that was recruiting 
open source developers. Tim Peters, a key Python community member, also joined us.

最終的には2000年の初めの (hadn't quite collapsed yetだった) ドットコムブームのときに
わたしとCNRI Python チームの三人のメンバー (Barry Warsaw, Jeremy Hylton, Fred Drake)が
オープンソース開発者をリクルートする California startup であった BeOpen.com に join しました。
Python コミュニティの重要なメンバーである Tim Peters もわたしたちに合流しました。

In anticipation of the transition to BeOpen.com, a difficult question was the future 
ownership of Python. CNRI insisted on changing the license and requested that we 
release Python 1.6 with this new license. The old license used while I was still at 
CWI had been a version of the MIT license. The releases previously made at CNRI used a 
slightly modified version of that license, with basically one sentence added where 
CNRI disclaimed most responsibilities. The 1.6 license however was a long wordy piece 
of lawyerese crafted by CNRI's lawyers.

BeOpen.com への transition においては将来のPython の ownership が難しい問題となっていました。
CNRI はPython のライセンスの変更を主張し、Python 1.6 を新しいライセンスの元でリリースするように
わたしたちに要求してきました。
CWI時代にわたしが使っていた古いライセンスはMIT ライセンスでした。
CNRI でのそれまでのリリースで使っていたのはそれを修正したもので、
基本的には CNRI disclaimed most responsibilities という一センテンスを加えただけのものです。
しかし1.6のライセンスは CNRI の弁護士たちによって起草された
a long wordy piece of lawyerese だったのです。


We had several long wrestling discussions with Richard Stallman and Eben Moglen of the 
Free Software Foundation about some parts of this new license. They feared it would be 
incompatible with the GPL, and hence threaten the viability of GNU mailman, which had 
by now become an essential tool for the FSF. With the help of Eric Raymond, changes to 
the CNRI Python license were made that satisfied both the FSF and CNRI, but the 
resulting language is not easy to understand. The only good thing I can say about it 
is that (again thanks to Eric Raymond's help) it has the seal of approval of the Open 
Source Initiative as a genuine open source license. Only slight modifications were 
made to the text of the license to reflect the two successive changes of ownership, 
first BeOpen.com and then the Python Software Foundation, but in essence the handiwork 
of CNRI's lawyers still stands.

わたしたちは Free Software Foundation の Richard Stallman や Eben Moglen と共に
この新しいライセンスのいくつかの部分について several long wrestling discussions を行いました。
彼らは新しいライセンスが GPL と非互換になることを憂慮していて
and hence threaten the viability of GNU mailman,
which had by now become an essential tool for the FSF. 
Eric Raymond の助けを得てCNRI Python ライセンスは
FSF と CNRI の双方を満足させるものに変更されました。
しかし、その結果としての文面は簡単に理解できるものではなくなってしまったのです。
それについてわたしがたった一つ良かったと言えることは
(Eric Raymondの助力には深く感謝しています)、
genuine なオープンソースライセンスとしてオープンソースイニシアティブ
(Open Source Initiative) の認可があったということだけです。

Like so many startups at the time, the BeOpen.com business plan failed rather 
spectacularly. It left behind a large debt, some serious doubts about the role played 
by some of the company's officers, and some very disillusioned developers besides my 
own team.

その頃の多くの startups と同じく、BeOpen.com のビジネスプランも
failed rather spectacularly.
It left behind a large debt,
some serious doubts about the role played by some of the company's officers,
and some very disillusioned developers besides my own team.


Luckily year my team, by now known as PythonLabs, was pretty hot, and we were hired as 
a unit by Digital Creations, one of the first companies to use Python. (Ken Manheimer 
had preceded us there a few years before.) Digital Creations soon renamed itself Zope 
Corporation after its main open source product, the web content management system Zope. 
Zope's founders Paul Everitt and Rob Page had attended the very first Python workshop 
at NIST in 1994, as did its CTO, Jim Fulton.

幸運なことに現在は PythonLabs として知られているわたしのチームはとてもhotでした。
そして　Python を使い始めた first companies の一つである
Digital Creations の一部門として雇われていました
(Ken Manheimer が数年前にわたしたちを preced していました)。
Digital Creations はすぐにその名前をその会社の主たるオープンソース製品である
web コンテンツ管理システムの Zope から名前を取った Zope Corporation に変えました。
Zopeの設立者である Paul Everitt と Rob Page は
had attended the very first Python workshop at NIST in 1994, as did its CTO, Jim Fulton.

History could easily have gone very differently: besides Digital Creations, we were 
also considering offers from VA Linux and ActiveState. VA Linux was then a rising star 
on the stock market, but eventually its stock price (which had made Eric Raymond a 
multi-millionaire on paper) collapsed rather dramatically. Looking back I think 
ActiveState would not have been a bad choice, despite the controversial personality of 
its founder Dick Hardt, if it hadn't been located in Canada.

History could easily have gone very differently:
Digital Creation 以外にも VA Linux と ActiveStateからもわたしたちに対するオファーがありました。
VA Linux は株式市場における超新星となりましたが、(紙の上で(帳簿上?) Eric Raymond を
multi-millionaireにした)その株価は劇的なまでに下降していきました (collapsed rather dramatically)。
今から振り返ってみるとカナダにある会社でなかったのなら、創設者の Dick Hardt の
controversial personality (面倒な性格?) という問題はあるものの
ActiveState は悪くない選択肢だったと思います。


In 2001 we created the Python Software Foundation, a non-profit organization, whose 
initial members were the main contributing Python developers at that time. Eric 
Raymond was one of the founding members. I'll have to write move about this period 
another time.

2001年にわたし達は非営利団体である Python Software Foundation を設立しました。
その初期メンバーはその時点におけるPython に  contriutting していた主な開発者たちでした。
Eric Raymond はその立ち上げメンバーの一人です。
I'll have to write move about this period another time.


Posted by Guido van Rossum at 2:01 PM

■_ The History of Python: Microsoft Ships Python Code... in 1996

こっちはほとんど手をつけられなかったので postponed。 

The History of Python: Microsoft Ships Python Code... in 1996
http://python-history.blogspot.com/2009/01/microsoft-ships-python-code-in-1996.html

My thanks go to Guido for allowing me to share my own history of Python!
#Guidoパパに感謝。

I'll save my introduction to Python for another post, but the end result was its 
introduction into a startup that I co-founded in 1991 with several people. We were 
working on a large client/server system to handle Business-to-Consumer electronic 
shopping. Custom TCP protocols operating over the old X.25 network, and all that. Old 
school.
#自己紹介などは他で書いてるので省略
わたしたちは、B2Cの電子ショッピングを取り扱う大規模なクライアント・サーバーシステムの
作業をしていました。カスタム化したTCP プロトコルが旧式の X.25 ネットワークの上で
動作していて云々

(ry

■_

■_

2009年01月28日

■_

・読んだ
・マイクロソフト戦記。あまり面白くなかった。 ただし話のネタ的には面白くできそうな部分もあったので書き手の問題が大きい?

・1+2=3
昨日のついったのごく一部で盛り上がった本。 幅広く網羅しているので、手広く知りたいという向きにはかなりオススメ。
1+2=3―足し算に潜む迷宮
1+2=3―足し算に潜む迷宮 (1+2=3―タしザンにヒソむメイキュウ) - 関心空間 に目次が載ってます。 

SourceMod DevLog » Blog Archive » Writnig a JIT, Part 1 - VM Introduction
http://www.sourcemod.net/devlog/?p=76

Using a PDP
http://fs6.depauw.edu:50080/~dharms/pdp11/

GetAFreelancer.com - Lisp Developers (Lisp? Really? Yes. Lisp. But no Lisp experience is necessary) Posted 27 Jan 2009
https://www.getafreelancer.com/projects/377103.html


FastCGI拡張がSegmentation faultを発生させる?(続き) - Kazzzの日記
Geekなぺーじ : 開発現場で使えるナウシカの名言
触られたくないPCに：机の上は立入禁止、ウィズ「USB工事現場」 - ITmedia +D LifeStyle
Compiler Construction:  Niklaus Wirth (pdf) 
ダウンロード - プログラミング言語C with lambda(仮) - SourceForge.JP


http://stackoverflow.com/questions/485500/fun-programming-metrics
http://stackoverflow.com/questions/485492/what-are-the-worst-programming-acronyms-names-or-phrases
http://stackoverflow.com/questions/485130/windbg-tracelistener-and-saturated-threadpool
http://stackoverflow.com/questions/4101/where-do-you-store-your-code-snippets
http://stackoverflow.com/questions/486621/when-should-one-use-a-www-subdomain-any-more
http://stackoverflow.com/questions/486383/safer-alternatives-to-the-c-standard-library
http://techon.nikkeibp.co.jp/article/HONSHI/20080729/155648/
http://www.superscript.com/djblib/intro.html
http://stackoverflow.com/questions/146466/tutorials-for-wii-programming
http://stackoverflow.com/questions/365176/how-do-you-make-programming-fun-or-at-least-less-painful-frustrating

Eclipse 3.4で超簡単Javaプログラミング基礎入門 (1/5) - ＠IT
http://www.atmarkit.co.jp/fjava/rensai4/java5eclipse01/java5eclipse01_1.html

.NETと安全なポインタ － ＠IT
http://www.atmarkit.co.jp/fdotnet/dotnetdeepdive/dotnetdeepdive02/dotnetdeepdive02_01.html
   管理下ポインタ→ managed pointer ?

やる気が出ないとき、「いまの自分はOK」から始めよう － ＠IT自分戦略研究所
http://jibun.atmarkit.co.jp/llife01/rensai/health09/health01.html

超便利！　ビジネスに役立つ無料ツール： USBメモリで持ち歩きできるスケジューラ「Schedule Watcher」
http://internet.watch.impress.co.jp/cda/biz_tool/2009/01/28/22232.html


Nabble - Scala - [scala] [ANN] Beginning Scala is available for pre-order
You can pre-order Beginning Scala from Amazon:
2009-01-27 - うっくつさん本を読む。
バカが征く on Rails 2009年01月28日
2009/1 (b)
きょう、日本語で書かれたプログラミング関連の資料をあさると、いかにダメかという例を見つけた:

■_ 前倒し

[Python-Dev] Python 3.0.1
[Python-Dev] Python 3.0.1
Guido van Rossum guido at python.org
Tue Jan 27 20:05:03 CET 2009

    * Previous message: [Python-Dev] Python 3.0.1
    * Next message: [Python-Dev] Python 3.0.1
    * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Tue, Jan 27, 2009 at 11:00 AM, Raymond Hettinger <python at rcn.com> wrote:
> With the extensive changes in the works, Python 3.0.1 is shaping-up to be a
> complete rerelease of 3.0 with API changes and major usability fixes.  It
> will fully supplant the original 3.0 release which was hobbled by poor IO
> performance.
>
> I propose to make the new release more attractive by backporting several
> module improvements already in 3.1, including two new itertools and one
> collections class.  These are already fully documented, tested, and
> checked-in to 3.1 and it would be ashamed to let them sit idle for a year or
> so, when the module updates are already ready-to-ship.

In that case, I recommend just releasing it as 3.1. I had always
anticipated a 3.1 release much sooner than the typical release
schedule.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

ちょっと前に触れましたが、ちょっと背景を説明すると、 3.0の入出力部分の性能が2.xに比べて目立って劣ったものであったという指摘がされていて、 それに対して性能改善を行うパッチというのが数日前に発表されています。

で、その性能改善を含めるのなら3.0.x ではなく、3.1 というものに対して行うべきであり その3.1を I had always anticipated a 3.1 release much sooner than the typical release schedule. 当初の予定よりも前倒しして3.1を出そうかなあ? という。

■_ 誰も指摘していなかったのか

GNU grep を Windows 上でビルドして実行したときに、 リダイレクトも引数の指定も一切しないで入力待ちにさせると エラーメッセージを出して終了するというもの。 とーぜん Linux 等々では発生しません。 

[bug #25414] grep on win32 gives "not enough space" when reading from st
[bug #25414] grep on win32 gives "not enough space" when reading from st

URL:
  <http://savannah.gnu.org/bugs/?25414>

                 Summary: grep on win32 gives "not enough space" when reading from stdin
                 Project: grep
            Submitted by: dim
            Submitted on: Mon 26 Jan 2009 10:04:35 PM CET
                Category: None
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

I have built grep 2.5.3 successfully on Win32, using MinGW.  This needed
just a few minor patches.  The test suite mostly passes, except for
some in the infamous foad1.sh, which seem to have been commented out in
the HEAD version in CVS. :)

However, running grep in the following fashion:

  grep foo

e.g. expecting it to read from stdin, you always get the error:

  grep: (standard input): Not enough space

After some digging, I found out this is caused by the default read()
buffer size in fillbuf(), INITIAL_BUFSIZE, which is 32 kiB.

Now, for some unfathomable reason, Microsoft has not deemed the Win32
standard input handle to be able to read 32767 bytes.  The actual Win32
ReadFile() API call fails with ENOMEM.

After some experimenting, I have determined that at least on my version
of Windows XP, the maximum input buffer size for stdin is 24546 bytes.

I would like to propose the following patch, which sets INITIAL_BUFSIZE
at 16384 bytes for Win32, which looks safely under the maximum.  If you
would rather have this in a header file somewhere, please let me know.


diff -uprd grep-2.5.3-orig/src/grep.c grep-2.5.3/src/grep.c
--- grep-2.5.3-orig/src/grep.c  Thu Jun 28 19:57:19 2007
+++ grep-2.5.3/src/grep.c       Fri Jan 23 14:19:52 2009
@@ -412,7 +412,11 @@ context_length_arg (char const *str, int
 
 static char *buffer;           /* Base of buffer. */
 static size_t bufalloc;                /* Allocated buffer size, counting 
slop. */
+#ifdef _WIN32
+#define INITIAL_BUFSIZE 16384  /* Initial buffer size, not counting slop. */
+#else
 #define INITIAL_BUFSIZE 32768  /* Initial buffer size, not counting slop. */
+#endif
 static int bufdesc;            /* File descriptor. */
 static char *bufbeg;           /* Beginning of user-visible stuff. */
 static char *buflim;           /* Limit of user-visible stuff. */

でまあここに書かれている通り、32k(以上)のバッファサイズで標準入力から ブロック読み込みしようとするとシステムコール(Windows API)が ENOMEM を 返してしまうので件のメッセージが出るという。 あ。でも After some experimenting, I have determined that at least on my version of Windows XP, the maximum input buffer size for stdin is 24546 bytes. とかあるな。

で、 

Re: [bug #25414] grep on win32 gives "not enough space" when reading fro
Re: [bug #25414] grep on win32 gives "not enough space" when reading fro

Hi Dimitry,

> [...]
>
> I would like to propose the following patch, which sets INITIAL_BUFSIZE
> at 16384 bytes for Win32, which looks safely under the maximum.  If you
> would rather have this in a header file somewhere, please let me know.

Thanks for the detailed bug report and the patch. Please note that
supporting win32 has a low priority at the moment so it may be a while
before I look into this; unless I hear confirmations of the bug and the
patch on several win32 systems from one or two more people.

In the mean time, you can try fixing the bugs identified by the failing
cases in foad1.sh :O) If you're not on the bug-grep mailing list, I
would encourage you to join.

Cheers,

TAA

supporting win32 has a low priority at the moment

ちゃんちゃん♪ まあそういうもんでしょう。 実は数年前から同様の変更を手元のものでやってたんですけど面倒で報告してなかったw

■_ 侘び寂び

defmacro - Taming Perfectionism
Taming Perfectionism
Tuesday, January 27, 2009
The Book of Tea

There was a time in my life when I couldn't get anything done. I was studying many 
different subjects at once, from theoretical Computer Science, to Zen, to principles 
of graphics design, when I developed a perception of deep underlying beauty of all 
things. Suddenly I could tell beautiful code from ugly code, a beautiful design from 
ugly design, and beautiful writing from ugly writing.


(略)

Perfectionism, which was always a friend, turned into my worst enemy.

I've heard that "perfect is the enemy of good enough" many times, but the 
repressed artist in me refused to accept this as truth. I was stalled in a proverbial 
checkmate that my mind has cunningly set up for itself and I could see no way out. And 
I desperately needed a way out, lest I be stuck in endless cycle of consumption 
samsara. I knew that real artists ship, but I refused to ship mediocre work, which 
meant I could never ship anything.

Wabi-Sabi: for Artists, Designers, Poets & Philosophers

Eventually I lucked out. By accident (or was it an accident?) I stumbled on the 
fascinating Book of Tea which led me to the concept of Wabi-sabi - the Japanese art of 
imperfect beauty. Wabi-sabi is a set of philosophical principles that relate Buddhist 
concepts that can be observed in meditation to all aspects of design. For the first 
time it occurred to me that Dukkha (the fundamental lack of satisfaction with anything 
in the physical realm), Anicca (impermanence, lack of any "timeless" 
principle), and Anatta (lack of "self", or the idea that any object can be 
complete in and of itself and exist separately from the subject) apply to all things 
we create.

Looking at Wabi-sabi objects was a breath of fresh air. Inability to achieve any 
lasting perfection is not fought, but embraced via lack of symmetry, respect for 
blemishes, and unsanitized simplicity. Imperfection, impermanence, and incompleteness 
is incorporated directly into the design - a simple idea that cuts the disease of 
perfectionism at its core.

Everything about this article is flawed - what I intended to say has an absolutely 
essential piece missing, the writing is poor and doesn't express my vision well 
(however imperfect that vision may be), and it probably doesn't matter in the long run. 
But I'm publishing it for all to see.

Real artists ship.

the Japanese art of imperfect beauty って。まあそういう見方もあるけどさあ。

Everything about this article is flawed (略), and it probably doesn't matter in the long run. But I'm publishing it for all to see. うははは。

■_ R.I.P.?

三週間ほど前のエントリですが、Merb がRailsに取り込まれるという話で。 

Ruby, Rails, Web2.0 ≫ Blog Archive ≫ Quo Vadis, Rails + Merb?
http://www.rubyrailways.com/quo-vadis-rails-merb/

Quo Vadis, Rails + Merb?
January 5th, 2009

Happy New Year to everyone! I have been totally off the grid for the past 2 weeks, 
just getting back to work (several hundreds of e-mails in my inbox, ugh) so just a 
really quick blurb on Rails + Merb (I guess everyone is sick of the topic by now 
anyways ;-). I am still dizzy after all the eating/drinking/pushing wii fit to the 
edge/doing nothing/… for 2 weeks, so get ready for some nonsensical rambling :-).

My gut reaction to the very first article on the merger:

Someone thought it is funny to post April's fools articles under the XMas tree.

After seeing about 3 more articles of the same kind:

Oh wow, there is a post-some-BS-which-is-a-bad-joke-even-for-april's-fools meme going on!

How amusing!

After actually reading the articles and digging around some more:

FUCK this is for real!!!

After calming down a bit and thinking it through:

This totally sucks. RIP Merb (2006-2008)

Sorry guys, I just can't join the grandiose Rails+merb merger celebration just yet (I'll
pop a few bottles after Rails 3 will hit the streets AND it will (mostly) work as 
promised though - but I am skeptical). I was happy that there is a new community which 
is different from the Rails one (of which I consider myself part of, by the way) - I 
joined the merb irc and voila - everyone was 100% helpful (no exceptions) even with 
the smallest things, and even beyond merb (I remember a great discussion on some fake 
data generators/factory girl style fixture replacement plugins which was started just 
because I asked a quick question on something totally different). How about the Rails 
irc? I don't really know as I joined just once about 1.5 years ago but was turned down
quickly by abrasive comments and overall behavior (e.g. a comment along the lines of
“dude if you are still using habtm anywhere (and not has-many-through), get a life 
and/or go back to your java thingy” - I don't even agree with this statement by the 
way, but that's a different story). Of course I am not saying the rails irc is always 
like this, and/or that all the rails guys are douchebags (I am not, for example ;-) 
but I heard similar stories from more people, unfortunately.

Just for the record - I am still a Ruby and Rails fanatic (please no comments like
‘it is maybe time to check out django' - no, it's definitely not, the rails climate 
has never been better), I am doing all my professional work with Rails since 2 years, 
own tons of Rails books, sleeping in DHH pajamas etc. so I am not attacking Rails in 
any way. From that perspective I couldn't be happier - Rails will become faster, more 
modular, less bloated etc. (I am sure you know all the bullet points from the other 
articles) and I have no doubt this is more or less going to happen. I am mourning over 
merb. The community. The influx of new ideas which maybe look bullshit when 
uttered/prototyped but have a chance to get into the framework because there is almost 
no bureaucracy. The competition. The monoculture (will Rails eventually eat Sinatra 
too?). The very fact that something like this just happened - a true black swan, in my 
opinion.

Of course, I am aware of the huge benefits too - first of all, the reverse ‘divide et 
impere' effect, turning enemies into allies - who wouldn't like to have Yehuda Katz 
(which indirectly means Engine Yard, to some extent), Matt Aimonetti and a ton of 
other kick-ass coders/evangelists in their ranks? Not to talk about the other great 
things - you obviously read about it all over the web already, so I am not going to 
duplicate that information again. However, in spite of all this awesomeness, something 
just does not feel right… this is not how it should have happened.

Just in case anyone cares what I am doing in this situation: I am packing my bags. 
Porting over Bob the Biller(tm), my first serious merb code to Rails. Advising my 
clients not to start merb projects from now on. Sorry merb, not long ago it felt like 
a beginning of a beautiful friendship - too bad you passed away prematurely. Rails, 
here I come again!

If you liked the article, subscribe to the rubyrailways.com feed!

MerbのRailsへの統合については、強烈な嫌悪感を表明しているようなものも見かけましたが、 正直わたしの英語の能力がおっつきません(量的にも質的にも)。 リンクを集めておいたはずだけどどこだ?

■_The History of Python

The History of Python: Personal History - part 2, CNRI and beyond The History of Python: Microsoft Ships Python Code... in 1996 と二つエントリが挙げられましたが(後者を書いたのはパパではありませんけど)、 気がついたのが日付が変わる直前くらいで時間的に余裕がないので29日以降ということで。

■_ 入門書

同じように思ってた人、自分のほかにもいたんだなw 

推薦図書/必読書のためのスレッド 44 [bbs2chreader]
236 デフォルトの名無しさん [sage] Date:2009/01/28(水) 09:44:14  ID: Be:
    未だにC言語の入門書が新刊で出続けるのってある意味すごいな 

237 デフォルトの名無しさん [sage] Date:2009/01/28(水) 09:50:41  ID: Be:
    CってC#の基礎になるの？ 

238 デフォルトの名無しさん [sage] Date:2009/01/28(水) 10:23:12  ID: Be:
    ならない
    C++ ならなるかな

2009年01月27日

■_

・CJKV本が到着しました。
早速積読山直行です。変更点の確認すらしていません○|￣|＿

・エディター
三日ほど前に、とあるオープンソース(フリーソフトウェア?)のテキストエディタを 見かけて、あとでソースを読もうと思ってたんだけど、ブックマークにも履歴にも それらしいのが見当たらない。夢幻だったんだろうか…(笑)

■_ 

Is There a "Dive Into Smalltalk" Book - Stack Overflow
Is There a “Dive Into Smalltalk” Book

I want to learn Smalltalk (particularly Squeak), but all the websites and books I've 
come across either assume I'm new to programming or spend forever getting acquainted 
with all the minutiae of the system.

When I picked up Python, Dive Into Python was my Bible for months. It had a great, 
straightforward way of teaching me how to apply all the programming concepts I already 
knew in Python. It would show you pythonic code while it also taught you all of 
Python's constructs and data types.

Is there a similar book for Smalltalk?

Here's a big list (from the wikipedia page actually):

http://stephane.ducasse.free.fr/FreeBooks.html


After familiarising yourself with the basics, I'd recommend Smalltalk Best Practice 
Patterns for learning the idioms of the language. I found this a profound text when 
starting out not just for learning Smalltalk but understanding the true essence of OO.

Cheers,
Matt



I have found a very interesting book called "squeakbyexample". The page seems to be 
down, but you can check out the book at this link.

Also, you can take a look at the documentation


If you already know how to program, you can't beat the original Smalltalk Blue Book, 
published in in 1983, titled Smalltalk-80: The Language and Its Implementation, by 
Goldberg and Robson. Three-quarters of the book is devoted to explanation and 
discussion of the predefined class hierarchy, and by learning that you will grok 
Smalltalk deeply.

■_ 

イーフロンティア、USBメモリにオフィスソフト、Office 2007まで対応:ニュース - CNET Japan
イーフロンティアは、オフィスソフトをUSBメモリに収めた「USBを挿すだけで使えるオフィスソ
フト EIOffice2009」を2月27日に発売する。ラインアップと価格は、PC1台用が5280円、PC3台用
が7980円。

　光学ドライブ非搭載のノートPCでも使えるオフィスソフト。マイクロソフトのOfficeとの高い
互換性を持ち、Office 2003からOffice 2007までの各種ファイルの読み込み、編集、保存が可能。
パスワードで保護されたファイルを開いたり、ファイルにパスワードをつけたりすることもでき
る。

　PCにソフトをインストールせず、USBメモリから直接起動できる。対応OSはWindows 
Vista/XP/2000 SP4以降。USBメモリにはバッファロー製の容量2GBのデータ暗号化ソフト付きモ
デルを採用した。

ああ、こういうの欲しかったんだよな。 って別に OOoをUSBに放り込んでもいいのだけど。

■_ 今日の疑問

文字コード変換プログラムについて -OKWave
文字コード変換プログラムについて

c言語でfgetcでファイルを読み込みをiconv関数を使用して文字コードを変換したいのですが、
サンプルソースを知っている方、もしくはソース知っている方教えていただけますか？

Wikiにiconvの説明とサンプルが掲載されているようです。
iconv - Wikipedia

ありがとうございます。すいません、fgetsではなく、fgetcを使って行いたいのですが、
たとえばWIKIのソースをどのように変えればよいのでしょうか？

  p_src = s_src;
  p_dst = s_dst;
  n_src = strlen(s_src);
  n_dst = S_SIZE-1;
  while (0 < n_src) {
      iconv(icd, &p_src, &n_src, &p_dst, &n_dst);
  }


特にこのあたりをどうにかすればよいのでしょうか？

fgetsではなく、fgetcを使っても良いですが、文字コードを変換する際全角文字は2バイトにな
ります。ですから一行単位で読み込むなどしてからiconvを使って変換しないと、文字化けする
と思います。

http://www9.plala.or.jp/sgwr-t/lib/fgetc.html

ありがとうございます。そうですか・・・、そのような仕組があるのですね
・・。勉強になりました。

…なぜ fgetc にこだわるのだろう? つか、iconvの使い方を勘違いしているのか? ストリームのように出し入れするものじゃないから、 1バイト(or 一文字)ずつ入力や出力するのって。 いやまあ i18n のえらいひと に言わせるとバッファの大きさの管理(どんだけ確保しておけば安心か)が難しいらしいですけどお。

■_ 



Why not Operator Overloading in JavaScript? at noumena
What Guy Steele said about Operator Overloading is that:

“If we grow the language in these few ways, then we will not need to grow it in a 
hundred other ways; the users can take on the rest of the task.”

へー。こんなこと言ってたのか。

■_ Emacs sucks

こいつもだいぶ間があきましたが。 



EmacsWiki: Why Does Elisp Suck

(See also EmacsLispLimitations, SchemeAndLisp)
EmacsWiki: Emacs Lisp Limitations
EmacsWiki: Scheme And Lisp

Contents

   1. Background
   2. EmacsLisp Isn't Scheme
   3. EmacsLisp Doesn't Have Lexical Scoping
   4. EmacsLisp Isn't CommonLisp/Haskell/Other
   5. The Emacs APIs Suck
   6. Do You Mean EmacsLisp (Language) Or EmacsLisp (Library)?
   7. Who Is EmacsLisp For? Who Wants EmacsLisp Dead?
   8. Conclusion
   9. Other commonly-named problems
  10. Pipeline's Commentary
  11. Utis' Commentary
  12. ad Pipeline's Commentary [2]
  13. ad the OP's topic "EmacsLisp Doesn't Have Lexical Scoping"
  14. ad the OP's topic "Who Is EmacsLisp For? Who Wants EmacsLisp Dead?"
  15. ad EmacsLisp in general
  16. Mathrick's plug-in
  17. Why Emacs Should Die (a.k.a Death Rebirth Revolution [1])
  18. Mornfall's comment
  19. Spirit's comment
  20. blandest's comment

EmacsLisp Isn't Scheme (Emacs Lisp はSchemeではない)

This, from my highly unscientific sample, is far and away the most popular reason 
EmacsLisp sucks. Well, that's good to know. EmacsLisp is also not Perl, or COBOL, or 
IBM 1130 assembler, or a bicycle, or an orange. Thanks for the help!

これは、Emacs Lisp が sucksだという最もpopular な理由からかけ離れたものです。
とはいえ知っておくのは良いことでしょう。
Emacs Lisp は(Schemeでないのと同様に) Perl でもありませんし、
COBOLでもIBM 1130のアセンブラーでも、はたまた自転車やオレンジでもありません。
Thanks for the help!

I didn't know Scheme ? and in fact do not now claim to know Scheme, though I have 
begun working through SICP ? and to my untrained eye, the main difference between 
EmacsLisp and Scheme was that Scheme required hitting the shift key a lot more (#t, #f, 
set!, predicate?, etc). Further inquiry eventually yielded the conclusion that this 
reason is really just a restatement of “EmacsLisp doesn't have lexical scoping”[2].

わたしはSchemeについては知りません。そしてSchemeのことを知れと主張するつもりもありません。
とはいえわたしは SICPに取り組み始めました。
and to my untrained eye
EmacsLispとSchemeとの間の主な違いとは、
Schemeの方がより多くのシフトキーの押下を要求するということです
(#tとか#f、set!、predicate?、などなど)。
“Emacs Lispはレキシカルスコープではない”ということの繰り返しが
ここでの結論と言うことになるでしょう。


That conclusion is not justified. There's a great deal of difference between Scheme 
and EmacsLisp beyond just the question of lexical scoping. As the OP mentions in 
passing, but then ignores, there's the fact that nil isn't false in Scheme, but is in 
CommonLisp and EmacsLisp. Scheme has a stylistic convention of marking destructive 
operations with an exclamation point and predicates (boolean functions) with a 
question mark; again noted in the OP. I'm not sure the latter is so significant, but 
the former indicates a stigmatization of side-effecting in the Scheme community, more 
closely wedded to function programming concepts, that we certainly don't see in 
EmacsLisp. Scheme is a Lisp-1, sharing the same namespace for variable and function 
definitions, so that the name list must be bound (at least locally) either to a 
function, or a variable, but not both. In a Lisp-2, you can use the same name for both 
a function and a variable.

この結論にはしかし十分な根拠がありません(not justified)。
Scheme と Emacs Lisp との間には、
レキシカルスコープに関することがらを除いてもなお大きな違いが存在しています。
As the OP mentions in passing, but then ignores,
Schemeでは、nil は false ではありませんが、Common Lisp や Emacs Lispでは false になります。
Scheme は破壊的操作を行うものにはエスクラメーションマークをつけ
述語的なもの(ブール関数)にはクエスチョンマークをつけるという形式的な規約 (stylistic convention)
を持っています。again noted in the OP.
わたしは後者がどれほどの違いなのかあまりよく分かりませんが、
前者はScheme コミュニティでは副作用のあることを重大視しているということを示しています。
つまり、より関数型プログラミングのコンセプトに近づいたものであり、
わたしたちがEmacs Lispをそこで見ることはありません。
Schemeは Lisp-1なので、変数と関数定義とで同じ名前空間を共有しています。
ですから、名前リストは(少なくともローカル的に)関数か変数のいずれか片方に束縛されて
いなければならず、両方ということは許されません。
Lisp-2では、同じ名前を変数と関数の両方で同時に使うことができます。


EmacsLisp Doesn't Have Lexical Scoping
(Emacs Lispはレキシカルスコープを使っていない)

This is a perfectly valid criticism of a programming language. I can see immediately 
how automatic lexical scoping of variables is a big win when writing complex and/or 
large Emacs extensions[3].

レキシカルスコープは全くもってプログラミング言語の正当な批判(criticism)です。
変数の自動レキシカルスコーピングが複雑で大規模なEmacs extensionsを記述するときに
big win であるかを即座に見つけ出すことができます。


However, as a new EmacsLisp programmer writing simple Emacs extensions which deal more 
with buffers and words than with turning Emacs into, say, a realtime financial 
analysis suite with embedded web browser, I really like the fact that I have access to 
every state variable in the whole editor. I can see if anything is set, and what it's 
set to. It's really quite great, being able to instantly harness the whole power of 
Emacs to frob my text around in an automated fashion. Is it possible to get lexical 
scoping without losing this?

しかしながら、新米のEmacs Lispプログラマとしてバッファと単語を扱うような単純なものではなく
Emacs に 組込みWebブラウザーを使って realtime financial analysis suite
を組み込むようなEmacs extention を書いたとき、
エディタ全体での state 変数すべてにアクセスできることがよかったと感じていました。
何かが設定されればそれを見ることができ、さらになにがセットされたのかを確認することが
できます。それは非常に素晴らしいことであり、
Emacs のパワー全体を即座に frob my text around in an automated fashion
のための harness にできます。
このような特長を失うことなしにレキシカルスコープを手に入れることが可能でしょうか?


    It is. It's called “fluids”, and they need to be specified explicitly.

        …in Scheme, or “special variables” in CommonLisp, FWIW.


Allegedly optional lexical scoping is coming after Emacs 23 is released. (according to 
emacs-devel) Once it's in place, adding coroutines will be feasible, which addresses 
the “single-threading sucks” argument that's surprisingly absent on this page. 
Should also make closures possible.

伝え聞いたところでは、Emacs 23がリリースされたあとでレキシカルスコープが
オプションと言う形で実装されるとのことです。emacs-devel メーリングリストによれば
一度これが実装されれば、コルーチンを追加するのも実現可能となって
“single-threading sucks” という主張に対するものとなるでしょう。

またこれによってクロージャも実装可能になるでしょう。

2009年01月26日

■_

・巡回先の数を絞らんとどーにもならんなあ。 

時を欠ける症状－うるう秒から考えるサステナビリティ - ＠IT
時間系問題の6つの処方箋

    * できるだけOSやプログラム言語の標準APIを使う。変に自作しない
    * 何事も決め打ちしない
    * 適切なテスト計画のうえで、網羅性の高いテストを
    * ユーザーインターフェイスで回避
    * 数年後に万が一不具合が起こった際、修正できる余地を残しておく
    * 数年後に作り替える、バージョンアップすることを前提として作る

■_ AND検索

やっぱ欲しがる人多いんだろうなあ。 ただメタ文字を増やしたりして対応するにしても条件を満たすかどうかの判定はどうにかなっても、 キャプチャーとかしたときの扱いが面倒っぽいな。 単純にエラー? 

Regular Expressions: Is there an AND operator? - Stack Overflow
Regular Expressions: Is there an AND operator?

Obviously, you can use | (pipe?), to represent OR, but can you match 'and' as well?

‘または’のを表す '|' はありますが、‘かつ’に対応するものはどうすればよいのでしょう? 

Specifically, I'm wanting to match paragraphs of text that contain ALL of a certain 
phrase, but in no particular order.
あるテキスト中にいくつかのフレーズが順不同で“すべて”存在しているかどうかを
検査したいのです。

Use a non-consuming regular expression.

The typical (i.e. Perl/Java) notation is:

(?=expr)

This means "match expr but after that continue matching at the original match-point."

You can do as many of these as you want, and this will be an "and." Example:

(?=match this expression)(?=match this too)(?=oh, and this)

You can even add capture groups inside the non-consuming expressions if you need to 
save some of the data therein.

Is it not possible in your case to do the AND on several matching results? in pseudocode

regexp_match(pattern1, data) && regexp_match(pattern2, data) && ...


You need to use lookahead as some of the other responders have said, but the lookahead 
has to account for other characters between its target word and the current match 
position. For example:

(?=.*word1)(?=.*word2)(?=.*word3)

The .* in the first lookahead lets it match however many characters it needs to before 
it gets to "word1". Then the match position is reset and the second lookahead seeks 
out "word2". Reset again, and the final part matches "word3"; since it's the last word 
you're checking for, it isn't necessary that it be in a lookahead, but it doesn't hurt.

In order to match a whole paragraph, you need to anchor the regex at both ends and add 
a final .* to consume the remaining characters. Using Perl-style notation, that would be:

/^(?=.*word1)(?=.*word2)(?=.*word3).*$/m

The 'm' modifier is for multline mode; it lets the ^ and $ match at paragraph 
boundaries ("line boundaries" in regex-speak). It's essential in this case that you 
not use the 's' modifier, which lets the dot metacharacter match newlines as well as 
all other characters.

Finally, you want to make sure you're matching whole words and not just fragments of 
longer words, so you need to add word boundaries:

/^(?=.*\bword1\b)(?=.*\bword2\b)(?=.*\bword3\b).*$/m

■_ 最後のシ(ry

◆最後のシ様2009/1/26 00:00kmaebashi

http://www.kt.rim.or.jp/~kbk/zakkicho/09/zakkicho0901c.html#D20090124

    ・「最後のシ良」 てw

これが何のことかはさっぱりですが、反射的に思いついたのは。

伊吹「何故? 最後の仕様だったんでしょ? あの仕様変更が」

青葉「ああ、全てのバグは消えたはずだ」

日向「今や平和になったって事じゃないのか」

伊吹「じゃあここは? 代休はどうなるの? 先輩も今、鬱で休職中なのに」

……どうでもいいです。はい。


http://d.hatena.ne.jp/kmaebashi/20090126

失礼しました。 アフタヌーン連載の「無限の住人」という作品の登場人物に尸良(しら)というのがいまして、 現在主人公とハゲシクやりあっております。 連載も終盤に差し掛かっていることもあって、そういうネタがアフタヌーンの 無限の住人のページ(の直前)にあったのですね。

無限の住人 (1) (アフタヌーンKC (90)) 無限の住人 第一巻 通常版 [DVD]

んー尸良が大きく写ってんのあるかな? 尸良 - Google イメージ検索

■_ 注目しておくべき十の言語

やっとリストの2番目。 

H3RALD : 10 programming languages worth checking out

Erlang

Erlang is a concurrent programming language originally developed by Ericsson for their 
real-time applications. It goes without saying that with these premise, Erlang seems 
the most natural answer to all concurrency problems you may encounter in your life as 
a programmer. Developing with concurrency in mind feels natural and easy in Erlang, 
and the performance of Erlang-powered systems can be unmatched.

Erlangは並列プログラミング言語であり、Ericsson 内におけるリアルタイムアプリケーションの
ために開発されたものが元になっています。
It goes without saying that with these premise,
Erlangはあなたがプログラマーとしてであうであろうすべての並列性に起因する問題
(concurrency problems)に対する最も自然な回答とも言えるでしょう。
Developing with concurrency in mind feels natural 
で、Erlangではそれは簡単なことです。
そしてErlangによるシステムのパフォーマンスはcan be unmatched.

Quite a few interesting applications have been developed in this language, such as:

この言語を使って、いかに挙げるようないくつかの興味深いアプリケーションが開発されています。

    * CouchDB, a popular distributed, document-oriented database
    * Yaws, a high-performance web server
    * even Facebook Chat

The price Erlang adepts have to pay, as Damien Katz (CouchDB creator and Erlang 
enthusiast) points out, is:

Damien Katz (CouchDB の作者でありかつErlang enthusiast)
が指摘したように The price Erlang adepts have to pay, 
それは以下のものです:

    * Awkward syntax, inspired by Prolog
      Prolog に影響を受けた奇妙な構文

    * Weird if expressions
      奇妙な if式

    * Difficult string operations
      難しい文字列操作

    * No classes or namespaces
      クラスや名前空間の欠如

…this list could go on. Damien's article is an interesting read, enough to put 
anyone off learning the language if read superficially. On the other hand, it provides 
an invaluable resource for newcomers who wish to be prepared before taking on the 
challenge of learning Erlang to build their next scalable, concurrent and 
industry-proof application.

このリストはまだ項目が増えるでしょう。
Damien's article はその上っ面だけを読んだだけなら
読者がこの言語を学ぶのを止めてしまおうとするような興味深いものです。
その一方で自分たちの次なる scalable かつconcurrent で industry-proof な
アプリケーションを構築するためにErlangを学ぶ前に情報を得ておきたいという
新参者のための invalualve resource があります。


To get you started…

    * Official Erlang Web Site
    * An Introduction to Erlang
    * Erlang Style Concurrency
    * PlanetErlang
    * Erlang Projects

Io

Io is a relatively new programming language by Steve Dekorte which recently surfaced 
from Google's oblivion (if you tried googling for it a few months ago, you couldn't 
event find its home page) thanks to a short vut stimulating article by _why. It doesn't 
have the best name for a programming language, that's for sure, but it's 
definitely a breath of fresh air in terms of the way it works.

IoはSteve Dekorteによるもので、
つい最近 surfaced from Google's oblivion した
比較的新しいプログラミング言語です
(もしあなたがほんの数ヶ月前にこの言語をぐぐろうとしたとしても、この言語のホームページを
見つけ出すことはできませんでした)。
その名前はプログラミング言語としてまったくもって良いものではありませんが
it's definitely a breath of fresh air in terms of the way it works.


Its unusual, minimalist and yet elegant and powerful syntax reminds of Smalltalk, but 
the language goes far beyond that. Io is an object-oriented, prototype-based, 
message-based and fully-reflective programming language. This means that you use 
messages like in Smalltalk, you create objects like in Javascript and every bit of 
your code can be inspected and passed around as you see fit.

その unusual かつ minimalist でありながらもエレガントかつ強力な構文は Smalltalkを
思い起こさせます。しかし Io は Smalltalk とはかなり遠いところに位置しています。
Ioはオブジェクト指向であり、プロトタイプベースであり、メッセージベースであり、
そして fully-reflective  なプログラミング言語です。
これはどういうことかというと、あなたはSmalltalkのようにメッセージを使うことができる
と同時にJavascriptのようにオブジェクトの生成ができ、さらに
あなたのコードのすべてのビットが
can be inspected and passed around as you see fit
だということです。

If you think Ruby allows fancy (and potentially dirty) tricks like metaprogramming and 
monkey-patching, Io takes this to a whole different level, imposing virtually no 
limitation to the programmer. What's truly amazing is that its grammar and syntax are 
so minimal that you can learn them in literally 10 minutes. After that, you can start 
experimenting, first with its extremely small core and then with its extension 
libraries and bindings.

あなたの脳裏にメタプログラミングやモンキーパッチのような fancy な
(と同時に dirty でもあり得る)トリックが使えるRubyが浮かびましたか?
IoはこういったことをRubyとはまったく異なるレベルで行っていて、
プログラマーに対して事実上制限を加えることなしに impose しています。
本当に驚きなのは Io の文法と構文が10分もあれば学べることができるくらい小さいものだ
ということです。文法と構文とをざっと学んでしまえば実験を始められます。
最初は極々小さなコードから始めてみて、続いて拡張ライブラリやバインディングを使っていきます。


Io has indeed a lot of potential. Granted, it's still young and under development, 
but also already quite efficient and suitable for real-world tasks demanding high 
speed and concurrency. It is implemented in C, but Ola Bini started to design a 
similar language called Ioke for the Java Virtual Machine.

Io は豊かな潜在能力を持っています。
言語としてまだ若く開発中であるにも関わらず
すでに高速性と並列性とを要求するような real-word task に対して
効率的で安定しているものとなっているのです。
IoはCを使って実装されていますが、Ola BiniはJavaの仮想機械向けで
Iokeという名前を持った同種の言語の設計を始めています。

To get you started…

    * Official Io Web Site
    * Io Repository on Github
    * Io user group
    * Io has a very clean mirror
    * Io Notes
    * Io Language Notes
    * Blame it on Io! A slow-paced introduction to the Io language
     * Io Wikibook

■_ 

推薦図書/必読書のためのスレッド 44
209 デフォルトの名無しさん [] Date:2009/01/26(月) 19:15:03  ID: Be:
    C#を覚えたいのですが、ウェブで「C# によるプログラミング Windows 上・下」
    というのを見かけました。だいぶ高価な本なのですが、著者のペゾルトさんの
    名前は素人でも聞いたことがあったので気になります。
    近くの書店には置いてないので、中身を確認することが出来ないのですが、
    C#をゼロから覚えるには適してるでしょうか？ 

210 デフォルトの名無しさん [sage] Date:2009/01/26(月) 19:17:01  ID: Be:
    買って間違いないが、C++とかの経験がないのなら、C#そのものを
    学ぶための本が必要。
    というか、C#のための本じゃないだろ。
    WindowsプログラミングをC#を使って説明している本だ。＞ペゾルド 

211 デフォルトの名無しさん [] Date:2009/01/26(月) 19:25:13  ID: Be:
    素人が言語を覚えるのには向いてないんですね。
    ありがとうございました。 

212 デフォルトの名無しさん [sage] Date:2009/01/26(月) 20:36:11  ID: Be:
    素人が最初に覚えるべき言語はRubyというのがスレの総意だよ。 

213 デフォルトの名無しさん [sage] Date:2009/01/26(月) 20:43:12  ID: Be:
    え、Ｃじゃないの？ 

214 デフォルトの名無しさん [sage] Date:2009/01/26(月) 20:46:42  ID: Be:
    え、英語じゃないの？ 

215 デフォルトの名無しさん [sage] Date:2009/01/26(月) 20:47:23  ID: Be:
    え、日本語じゃないの？ 

216 デフォルトの名無しさん [sage] Date:2009/01/26(月) 20:56:32  ID: Be:
    お前らという奴らはｗ

217 デフォルトの名無しさん [sage] Date:2009/01/26(月) 21:05:32  ID: Be:
    >>212
    俺は違う意見を持っている。だから総意ではないな。 

218 デフォルトの名無しさん [sage] Date:2009/01/26(月) 21:17:39  ID: Be:
    素人が最初に覚えるべき言語はCASLⅡというのがスレの総意だとおもしろいね。 


Linus「C++プログラマはウンコ。寄ってくるな」
193 デフォルトの名無しさん [sage] Date:2009/01/26(月) 03:28:06  ID: Be:
    XtとかMotifとかを生で触った事があって、Cでオブジェクト指向GUIプログラミングを
    をやると、どんだけ酷い目に遭わされるか知ってると、C++への感慨も
    変わってくると思う。 

199 デフォルトの名無しさん [sage] Date:2009/01/26(月) 15:16:28  ID: Be:
    C++でGUIアプリの開発は悲惨の一言だな。
    言語仕様が硬直的でまともにイベントディスパッチできねぇし。 

200 デフォルトの名無しさん [] Date:2009/01/26(月) 15:19:11  ID: Be:

    ゲーム開発以外はもう全部Cでいいよ。

201 デフォルトの名無しさん [sage] Date:2009/01/26(月) 17:30:25  ID: Be:
    ゲームこそCで十分だろ。アセンブラでも良いぞ。 

202 デフォルトの名無しさん [sage] Date:2009/01/26(月) 17:41:06  ID: Be:
    >>193
    ﾉｼ
    「こんないーもんあるじゃねーか！C++使わせろよ！」
    と思った。 

スレ立てるまでもない質問はここで 第94刷
910 まりこ [] Date:2009/01/26(月) 19:05:24  ID: Be:
    学校の課題なんす！
    んで、全然わからんぺ！
    ほいでな、みんなに聞きたいことがあんねんな。

    以下問題
    （１）学籍コード（５桁：すべて数字）を引数として、和暦表示での（4年間での）卒業年を返す関数

    （２）所得金額と特定寄付金の額を引数として、寄付金控除額を出力する関数を作成しなさい。
    　　　　　寄付金控除額＝（所得の２５％または特定寄付金の額のいずれかは少ない金額）－１万円
    　　　ただし上記の計算での寄付金控除額が負の場合は０

    （３）課税される所得金額を引数にして所得金額を計算する関数を作成しなさい
    　　　所得税額は、
    　　　　　課税される所得金額　　　税率　　　　控除額
    　　　　　0～3,300,000　　　　　　10％　　　　　　0
    　　　　　3,300,000～9,000,000　　20％　　　330,000
    　　　　　9,000,000～18,000,000　　30％　　1,230,000
    　　　　　18,000,000～30,000,000　40％　　3,030,000
    　　　　　30,000,000～　　　　　　50％　　6,030,000
    　　　の数値に基づき、
    　　　　　　　　　　　　所得税額＝（課税される所得金額×税率）－控除額
    　　　で求めます。ただし、１００円未満の端数は切り捨てです。所得金額が9,000,000な
          どの境目の場合、どちらの行の税率、控除額を使ってもOKです。実際どちらの行の
          計算式を使っても所得税額が同じになるように設定されています。

911 まりこ [] Date:2009/01/26(月) 19:05:59  ID: Be:
    書ききらなかったのでPart2

    （４）通貨統合されたEU諸国内の通貨は、ユーロとの固定相場になっていました（2001年12
          月31日まで。現在は、フランやマルクなどの通過は使われていません）
    　　　そこで、下の表に記載された国について、国名、その通貨での金額、およびユーロの
          日本円相場（1ユーロ＝XXX円、変動相場制）の3つを引数として、日本円での金額を
          返す関数を作成しなさい。

    国　　　　│　1ユーロ＝
    ──────────────
    ドイツ　　│　1.95583 マルク
    フランス　│　6.55957 フラン
    イタリア　│　1936.27 リラ
    スペイン　│　166.386 ペセタ
    オランダ　│　2020371 ギルダー

    　　　たとえば、フランスで、60フラン、1ユーロ＝123,67円の場合、
         （60/6.55957）× 123.67＝1131.202 で計算され、
    　　　　　　　　　　　＝EURO（”フランス”,60,123.67）
    　　　とすれば、1131.202と表示するようにしなさい。


    以上でち！
    誰か助けてケロ(><)!!!! 

912 デフォルトの名無しさん [sage] Date:2009/01/26(月) 19:08:22  ID: Be:
    宿題は自分でやれよゆとりが 

913 デフォルトの名無しさん [sage] Date:2009/01/26(月) 19:54:01  ID: Be:
    >>911
    よしおれがやってやるよ
    言語はcommon lispでいいか

914 デフォルトの名無しさん [sage] Date:2009/01/26(月) 20:22:10  ID: Be:
    暇だったからPERLで書いてみた。４ばん
    #!/usr/bin/perl

    sub en{ ($kuni,$kane,$euro)=@_;
    %a=(
    "ドイツ" =>1.95583,
    "フランス"=>6.55957,
    "イタリア"=>1936.27,
    "スペイン"=>166.386,
    "オランダ"=>2020371);
    return ($kane/($a{$kuni}))*$euro;
    }
    print en("フランス",60,123.67); 

915 まりこ [] Date:2009/01/26(月) 20:34:34  ID: Be:
    言語はVBAです～ 

916 デフォルトの名無しさん [sage] Date:2009/01/26(月) 20:39:02  ID: Be:
    ちっ、PL/SQL で書こうと思ったら釘を刺されたぜ。 

917 デフォルトの名無しさん [sage] Date:2009/01/26(月) 20:40:48  ID: Be:
    じゃあ僕はBCPL！ 

918 デフォルトの名無しさん [sage] Date:2009/01/26(月) 20:43:44  ID: Be:
    よし、VBAforAccessだな、任せておけ。 

919 デフォルトの名無しさん [] Date:2009/01/26(月) 20:58:47  ID: Be:
    Excelのマクロか！ 
929 デフォルトの名無しさん [] Date:2009/01/26(月) 23:08:01  ID: Be:
    >>910

    １問目：なんで学籍から年がわかるんですか？
    学籍に年情報はいっているん？ 

931 まりこ [] Date:2009/01/26(月) 23:20:30  ID: Be:
    >>929
    学籍番号の最初の文字が5だったら平成20年卒、6だったら平成21年卒。
    みたいな感じなんす。 

    932 デフォルトの名無しさん [sage] Date:2009/01/26(月) 23:20:52  ID: Be:
    同校の生徒でもなきゃとけないなｗ 

933 デフォルトの名無しさん [] Date:2009/01/26(月) 23:25:24  ID: Be:
    もっと情報を！！
    手有価
    卒？答え出てるやん

934 まりこ [] Date:2009/01/26(月) 23:26:50  ID: Be:
    確かに！何の参考書の問題かもわからないので質問の意図がよくわからないんですよ！ 

935 まりこ [] Date:2009/01/26(月) 23:28:37  ID: Be:
    答え出ててもこれを過去も未来もって感じなんでどんなプログラム書けばいいかわからなくて… 

936 デフォルトの名無しさん [] Date:2009/01/26(月) 23:30:43  ID: Be:
    ファンクション　int GetSotugyou()
    {
    GetSotugyou = left(学籍番号,1) + 15
    }


    こんな感じ？ 

937 まりこ [] Date:2009/01/26(月) 23:43:30  ID: Be:
    どんな年代の学生番号でも卒業年度が分かるようなプログラムにしたいです。

    例えば83456だったら平成23年度卒とかです。 

938 デフォルトの名無しさん [] Date:2009/01/26(月) 23:44:59  ID: Be:
    ごめんねむいや

    とおもったらエクセルに貼り付けたらできた
    引数の型適当（バリアント）なんでどうにかして


    Sub Macro1()
    学籍番号 = "11111"
    crn = FNC(学籍番号)
    MsgBox (crn)
    End Sub


    Function FNC(GetSotugyou As Variant) As Variant
    FNC = Left(GetSotugyou, 1) + 15
    End Function 

939 まりこ [] Date:2009/01/26(月) 23:47:13  ID: Be:
    どうもです！やってみます！ 

940 まりこ [] Date:2009/01/27(火) 00:19:16  ID: Be:
    ≫938さん
    できました!!!ありがとうございます。 

941 デフォルトの名無しさん [sage] Date:2009/01/27(火) 00:27:17  ID: Be:
    留年は考慮しなくていいの？ 


Ｃ言語なら俺に聞け（入門篇） Part 43 
99 デフォルトの名無しさん [sage] Date:2009/01/26(月) 21:40:02  ID: Be:
    ->この演算子嫌いなんだけど何とかならない？ 

100 デフォルトの名無しさん [sage] Date:2009/01/26(月) 21:42:28  ID: Be:
    (*p).member 

101 デフォルトの名無しさん [sage] Date:2009/01/26(月) 21:42:33  ID: Be:
    >>99
    ドットで置き換えればいいと思うよ。
    pointer->memberは常に(* pointer).memberだから。 

102 デフォルトの名無しさん [sage] Date:2009/01/26(月) 21:45:18  ID: Be:
    >>100>>101
    さんくす

2009年01月25日

■_

・地元にある図書館の検索システムの端末がWindowsで動いていた。 エラーのときに見覚えのあるスタイルのメッセージボックスががががw ついでに書いておくとNEC製ですた。ソフトまでそうかはわかんないけど。

■_ デバッグ手法

  はじめてのにき(2009-01-25)
"_ デバッグ話続き"
http://shinh.skr.jp/m/?date=20090125#p06

  printf の方がカンタンなソフトウェアとしてウィンドウマネージャがあるのだった。 gdb 使
うとなると、 X サーバ複数上げてパチパチやるか、 suspend した時に WM の機能が使えないの
を我慢するか、のどっちかになっちゃうんだよな。

Windows で最初にプログラミングした頃ってデバッグに苦労したんだよなあ。 と斜め上の感想。まともなデバッガもなかったし(海の向こうにはあったっぽい?)、 printfデバッグもままならない(なぜなら3.1まではWindows用プログラムが標準出力に 吐き出すようなことはできなかった。まあ OutputDebugString 使うと 似たようなことはできたけど)。

■_ 



Why "Modern Perl" Anyway? - Modern Perl Books
Why "Modern Perl" Anyway?
By chromatic on January 23, 2009 9:15 PM | No Comments | No TrackBacks

Perl 5 -- the current version of Perl -- is fourteen years old now. It's had several 
major revisions in that time. (See Perl History for more details.) These major 
revisions add new features, fix old bugs, and generally improve the language. All of 
these changes come from real-world users who use the language themselves.

The current stable major version of Perl is Perl 5.10, released in December 2007. This 
release includes several features backported from Perl 6, the next stage in evolution 
of Perl.

Perl's a popular language. It's been around for 21 years, and it was the language of 
server-side programming back in the day. It's still popular. There are hundreds of 
books and thousands of tutorials available all over the Internet. You can learn Perl 
with little more than a text editor and a web browser, if you so desire.

Remember, however, the Internet rarely forgets. A Perl tutorial which represented the 
best version of Perl from 1991 may still be around -- and thanks to search engines, it 
may be the most highly recommended tutorial anywhere. Eighteen years later, Perl's 
moved on. We've learned a lot since then.

～
インターネットが忘却することは滅多にありません。
1991年からあるベストなものとされている Perlのチュートリアルは今でも検索エンジンの
おかげで身近なものです、それがどこであってももっともオススメのチュートリアルだと
されているかもしれないのです。(1991年から)18年後の今、Perlは変わっています。
わたし達はその間多くのことを学んできているのです。

The best way to write Perl programs in 1991 or 2001 or 2004 isn't necessarily the best 
way to write Perl programs in 2009. It's time to discuss and document and disseminate 
all of the wisdom of the greater Perl community. It's time to talk about modern Perl.

1991年におけるPerlプログラムのベストな書き方と、2001年や2004年におけるベストなそれが
2009年におけるベストなものである必要はありません。今こそ話し合いをし、ドキュメントとして
形にして、偉大なPerlコミュニティの智恵を広めるべきときなのです。
さあ modern Perl について話し合おうではありませんか。

なんのかんの言って、5.10もリリースしてから丸一年以上たったのか。 It's time to talk about modern Perl. と思っている人がいるのは日本だけじゃないと (まあ当然)。

こんなのも→ Perldoc: The Need for a Better Documentation System

■_ As a budding programmer, what did you do everyday to get better? (stackoveflowから)



As a budding programmer, what did you do everyday to get better? - Stack Overflow×

Hi everyone! Here's the situation: I want to master Java and I'm thinking what do I 
need to do everyday to increase my chances of standing out and being hired if let's 
say I came from another field? If I have 1-2 hours a day of free time, what do you 
guys think I should do? Thanks in advance!


This is largely summarising what others have written (hence wiki) but:

    * Write code. Write lots of code. Don't be afraid to make mistakes - that's how we 
      learn. Do think before you code, but don't worry too much whether you're doing exactly 
      the right thing: try it and see how it pans out. This is particularly useful for small 
      projects.
    * Read good code. The Java collections API is a good start, and the Google Java 
      Collections are great too.
    * Read good books, blogs and articles - and don't believe anything they say 
      without thinking about it further. All authors are wrong about at least something :) 
      (I'd also second the recommendation to read Effective Java (2nd edition). It's 
      probably the best book on Java development I've ever read.)
    * Try to diversify - learn different programming styles and approaches. Try a 
      functional language. Try test-driven development. Try some scripting. Try a dynamic 
      language. You don't need to become an expert in these things to gain significant 
      benefit when using your main language/style.

For blog recommendations, there are at least three SO questions with plenty of answers:

    * What are the best RSS feeds for programmers/developers?
    * What are the best programming and development related blogs?
    * What are the 3 top blogs for new .NET developers? (A lot of .NET content is 
      relevant to Java too, and it's good to look at other platforms anyway.)


If you want to get better at Java, you might want to take a look at Effective Java by 
Joshua Bloch. It's more or less a "best practice" book which will show you 
with plenty of sample code of what to do and what not to do when designing and writing 
Java programs.

Aside from that, there are going to be the standard list of things to do:

    * Write code. Lots of it. ("Practice makes perfect.")
    * Work on projects that interest you.
    * Read. Keep studying the language.
    * Make an effort to write good clean code.

One of the things with Java is that the Java API itself is huge. That said, I feel 
that the Java API Specifications are very well-written. For Java, learning to read the 
Java API Specification and Javadoc-style documentation is going to be key.

As the Java API is huge, try to learn bits at a time, and work on projects you're 
interested in. If you're starting out, perhaps making small tools which you might want 
to use may be a good start. Perhaps, write a little calculator application. Then, 
maybe adapt the calculate application into an applet. Maybe write a text editor.

Probably the biggest thing is keep working at it everyday. If you have 2 hours per day, 
you would have been doing something programing-related for 60 hours per month. By the 
end of the year, that's 720 hours. What's going to make a difference is that you keep 
at working at it.

And most of all, have fun! The best way to learn something is having fun while you're 
learning it. Good luck!

訳はあとで(えー

■_今日の[ムマ]板から 

この会社辞めようと思ったソースコード＃1B 
347 仕様書無しさん [sage] Date:2008/12/07(日) 01:43:55  ID: Be:
    8085で、こういうのはやったな。これも左辺キャストになるのかな。
    /*　　strcpy(xxbuf+xxen,"\n");　　** 以下に最適化 */
    　　　*(int*)(xxbuf+xxlen) = '\n';　　/* <LF>を付加 */
    H8系ならアウトだけど、8085だとうまくいく（ｗ 

359 仕様書無しさん [sage] Date:2009/01/25(日) 19:13:45  ID: Be:
    >>347
    コードのどこにも書いていない '\0' の代入を、挙動を追いながら想像しろって？
    最　悪　な　コ　ー　ド　じ　ゃ　ん　。
    「プログラム書法（共立出版）」を最初から最後まで全部読め。速くするのはそれからだ。

360 仕様書無しさん [sage] Date:2009/01/25(日) 19:37:46  ID: Be:
    業者乙 

361 仕様書無しさん [sage] Date:2009/01/25(日) 20:18:30  ID: Be:
    今ならプログラミング作法じゃないの。おっさん乙 

362 仕様書無しさん [sage] Date:2009/01/25(日) 20:30:35  ID: Be:
    >>361
    「プログラム書法」に必要十分なことは書いてあるから、類似のものなど読まなくていい。
    おまえら若者が古いという理由だけでこういう良い本を読まないのは哀れにも愚かにも思える。
    「ビートルズやツェッペリンなんか聴いても仕方ない」と言っている奴らとまったく同じだ。

363 仕様書無しさん [sage] Date:2009/01/25(日) 20:38:36  ID: Be:
    そうやって古き良き時代にしがみつくからだめなんだよ 

364 仕様書無しさん [sage] Date:2009/01/25(日) 21:10:51  ID: Be:
    >363
    「古きよき時代にしがみつく」って日本語の意味を
    ちゃんと理解してから出直してこい

365 仕様書無しさん [sage] Date:2009/01/25(日) 21:27:11  ID: Be:
    >>363
    そういうのは「反論」じゃなくて「ただの減らず口」って言うんだよ。覚えとけ。
    反論したいなら、何か相手をうならせるようなことを言ってみろ。

368 仕様書無しさん [sage] Date:2009/01/25(日) 22:40:21  ID: Be:
    はいはい、類似なら書店で手に入るものでいいでしょ 

369 仕様書無しさん [sage] Date:2009/01/25(日) 23:46:50  ID: Be:
    >>362
    > 「ビートルズやツェッペリンなんか聴いても仕方ない」と言っている奴らとまったく同じだ。

    それとこれとは話が違うだろと思うビーヲタの俺。 

370 仕様書無しさん [sage] Date:2009/01/25(日) 23:58:13  ID: Be:
    見やすいのが一番だぜ

まあ書法はちと厳しいとこあるよなあ。 内容そのものは今でも有効なものが多いのは確かなんだけど。 

Linus「C++プログラマはウンコ。寄ってくるな」 
143 デフォルトの名無しさん [sage] Date:2009/01/25(日) 09:43:47  ID: Be:
    デバイスドライバ作っても給料は安いままだよな・・・
    何の技術も持ってない奴よりも俺の年収の方が低いなんて・・情けないよな・・・ 

144 デフォルトの名無しさん [sage] Date:2009/01/25(日) 09:47:35  ID: Be:
    >>143
    ヒント： 需要と供給 

145 デフォルトの名無しさん [sage] Date:2009/01/25(日) 10:04:19  ID: Be:
    >>143
    何の能力も無いまま広告代理店だの株屋だのに勤めてる奴らは俺らより年収高いぞ。
    歴史に残る天才が貧乏だったケースは無数にある。
    年収＝能力じゃないんだよ。
    俺らはポインタも配列も怖くない、メモリリークなんていうバカなバグは出さない、
    そこらの駆け出しプログラマとは格段にレベルが違う、その矜持だけでいいじゃないか。

147 デフォルトの名無しさん [sage] Date:2009/01/25(日) 11:26:59  ID: Be:
    linusの言いたい事は解る。
    自分の理解してる機能だけ使えばいいのにな。

    >>143
    日本のプログラマは給料安くてやってられね。
    使える友人増やして、会社起こすしかないよ。

150 デフォルトの名無しさん [sage] Date:2009/01/25(日) 12:00:44  ID: Be:
    >>143
    金を得るという技術が無いだけでしょ？

    金が欲しいならそっちの技術も磨けばいいじゃん。 

156 デフォルトの名無しさん [sage] Date:2009/01/25(日) 13:06:45  ID: Be:
    >>150
    そっちの技術に興味がないけど金は欲しい

    …ってのが大半なんだよな。エンジニアって…

デバイスドライバー(何用のだかわからんけど)がきちんと書ける人なら需要はあると思うがなあ。 

スレを勃てるまでもないC/C++の質問はここで 6
803 デフォルトの名無しさん [sage] Date:2009/01/25(日) 12:18:07  ID: Be:
    おすすめのC言語入門サイトを教えてください 

804 デフォルトの名無しさん [sage] Date:2009/01/25(日) 13:36:44  ID: Be:
    http://cm.bell-labs.com/cm/cs/cbook/

Linus「C++プログラマはウンコ。寄ってくるな」
163 デフォルトの名無しさん [sage] Date:2009/01/25(日) 14:26:24  ID: Be:
    クリティカルなところはC
    普通はLL言語つかってほうがいいわ。 

164 デフォルトの名無しさん [sage] Date:2009/01/25(日) 14:47:35  ID: Be:
    全然関係ない個人的な主観の話でいうと、LL言語という表記がキモい。
    見てると頭痛が痛くなってくる。 

165 デフォルトの名無しさん [sage] Date:2009/01/25(日) 14:49:57  ID: Be:
    病院行けよ 

166 デフォルトの名無しさん [sage] Date:2009/01/25(日) 14:51:30  ID: Be:
    例えも理解できないのかわかってて返してるのか 

167 デフォルトの名無しさん [sage] Date:2009/01/25(日) 14:54:32  ID: Be:
    理解を分かってるよ。
    LLかLW言語と言えってことだろ。 

168 デフォルトの名無しさん [sage] Date:2009/01/25(日) 14:57:08  ID: Be:
    そういうくだらない所にこだわって
    いちいち突っ込み入れて話を中断させる奴って小物ばっかりなんだよな。 

170 デフォルトの名無しさん [sage] Date:2009/01/25(日) 15:01:08  ID: Be:
    じゃあ、「C言語」で。 

172 デフォルトの名無しさん [sage] Date:2009/01/25(日) 15:16:56  ID: Be:
    >>168
    それはお前が大物と話す機会のある立場に居なくて、
    且つしょっちゅう言葉を間違えて突っ込まれる人生送ってるだけだろ。 

173 デフォルトの名無しさん [sage] Date:2009/01/25(日) 15:17:56  ID: Be:
    大物（笑） 

179 デフォルトの名無しさん [sage] Date:2009/01/25(日) 16:47:56  ID: Be:
    gitのすばらしいコードってどこでみれるかな

2009年01月24日

■_

・勧誘電話むかつく

・日経ソフトウエア
来月の特集1 はプログラマー必見。らしいぞw

・「最後のシ良」 てw

・ダムエー
オリジンはいんたーみっしょん。 教えてください富野ですのゲストは鍵屋十五代目。 最初はテクニックがどうこうよりも「安全」について叩き込まれたというのが印象に残った。

・東スポ
プロレス面に掲載のコラムにあったハンセンの言葉。 ラリアートに大切なのは全盛期にはパワーとスピードだったし、 晩年になって若いレスラーが速い動きをしたり、防御をしてくるようになってからは サイコロジーを考えるようになった。 オレは常にラリアートをフィニッシュムーブにするように心がけてトライしたよ ハンセンとそれ以外のラリアットの使い手の違いは、 それでフィニッシュできるかどうかだなと思ったり。 まあバックドロップやジャーマンスープレックスでさえ痛め技になってるくらいだから しかたのない面はあるのだろうけど、一試合で何発も繰り出すのは正直重みっつーものがない。 まあハンセンは正式には スタン・“ザ・ラリアット”・ハンセン てリングネームらしいからなあw

■_ プログラマーなら知ってて当然のお名前?

誰か日本人版を(ry 

What are the names that every programmer should know? - Stack Overflow
http://stackoverflow.com/questions/460894/what-are-the-names-that-every-programmer-should-know

Abraham Lempel
Ada Lovelace
Alan Turing - Father of computer science.
Alexander Stepanov - creator of STL
Alfred Aho
Anders Hejlsberg - Programming language creator (Turbo Pascal / Delphi, J++, C#)
Andrew Hunt
Andy Tanenbaum, of Minix, distributed operating systems, and many great textbooks fame.
Barbara Liskov
Bjarne Stroustrup - Creator of C++
Brian Kernighan
Bruce Schneier - If you don't know who this is you're on my list for getting security tested.
C. Antony R. Hoare - Inventor of the Hoare-Logic
C.A.R. Hoare of quicksort.
Charles Babbage
Charles Simonyi - author of Hungarian notation
Christopher Alexander - creator of Pattern Languages
Dave Thomas
Dennis Ritchie
Donald Knuth
Donald Knuth - "Art of Computer Programming", TeX, etc
Edgar "Saint" Codd
Edsger Dijkstra - algorithms, "GOTO considered harmful"
Edsger W. Dijkstra - For his algorithms
Erich Gamma
Fred Brooks
Gerald "Jerry" Weinberg
Guido Van Rossum - inventor of Python
Guy L. Steele.
Guy Steele
Herbert Simon A.I. and complex systems theorist
Ivar Jacobson - For his contribution on UML and Use Cases
J.B. Rainsberger
Jacob Ziv
Jim Gray
Joel Spolsky & Jeff Atwood - programmers/bloggers
John Backus - See: Backus-Naur-Form
John Carmack, game dev guru.
John McCarthy
John Vlissides
John Von Neumann
Joseph Marie Jacquard
Kent Beck
Kristen Nygaard - inventor of key object oriented programming concepts
Kurt Godel
Larry Wall - Perl
Leslie Lamport
Linus Torvalds - Creator of Linux
Martin Fowler
Marvin Minsky - AI Pioneer
Michael Abrash
Michael C. Feathers
Nancy Lynch
Niklaus Wirth
Noam Chomsky - Not a computer guy, but the Chomsky hierarchy should be basic stuff for every programmer
Norbert Weiner - Cybernetic Pioneer
Paul Graham
Peter Weinberger
Ralph Johnson
Raymond Chen
Richard Gabriel - Lisp developer and code poet
Richard Helm
Richard Stallman - Shame on you if you've never used anything GPL'd
Rivest, Shamir and Adleman - RSA
Robert Pike
Robert X. Cringely - industry writer / Pundit
Ron Jeffries
Rudolf Bayer and Ed McCreight for B-tree data structure which facilitates fast searching.
Scott Guthrie - Key product manager (architect?) at Microsoft
Scott Hanselman - Programmer / blogger / podcaster
Scott Meyers - author of the effective trilogy
Seymour Papert - Inventor of Logo and promoter of programming as a method of education.
Steve McConnell for coding best practices (Code Complete).
Though a virus becomes a side effect of that architecture.
Tim Berners Lee - Invented the internet!!!
Ward Cunningham

アルファベット順に並べなおして重複は取り除いた…はず。

■_

だいぶ前にリンクだけ拾ってたものから虫干しモードその1。 続くけるかどうかは未定 (元記事は全部あわせると結構なボリュームがある)。 

C - Advice And Warnings For C - Introduction Tutorials
Introduction (序文)

C and C++ are widely promoted as ideal portable, fast, and - in the case of C++ - 
"object-oriented" languages. This characterization is deserved when C is 
considered for systems-level programs such as compilers, or for mass-market products 
such as word processing or spreadsheet programs. C was designed as a reasonably 
transportable replacement for assembly language that would add some high-level 
language constructs, but would retain almost all the low-level procedural capabilities 
found at the machine instruction level. C++ follows in that tradition, adding 
object-oriented capabilities (encapsulation and inheritance) to improve productivity 
while retaining C's original features and its philosophy of "bare metal" 
performance.

CとC++ は移植性があり、高速で、さらにC++ の場合にはオブジェクト指向であるという
理想的なものだと広く promot されてきました。
この特徴は、Cがコンパイラーのようなシステムレベルのプログラムや
ワープロや表計算ソフトのようなmass-market products が
対象であるときにdeserve されるものです。
Cはアセンブリ言語を reasonably transportable に置き換えることのできる
アセンブリ言語にいくつかの高水準言語の構造を追加したものとして設計されました。
その一方で機械命令レベルの low-level procedural capabilities もほぼすべて残していたのです。
C++ はその伝統に従ったもので、C本来の機能とその　"bare metal" performance という
哲学とを残しながらもさらにオブジェクト指向の能力(カプセル化と継承)がproductivity の
改良のために追加されました。


But C is increasingly being considered as the best replacement for outdated commercial 
languages such as COBOL, RPG, and Basic. And many proponents also recommend C and C++ 
as superior alternatives to the Pascal family of languages (including Modula-2 and 
other successors to Pascal); to object-oriented languages such as Smalltalk, Eiffel, 
and Actor; and to the general-purpose language, Ada. C has its place, but in many 
cases - especially business programming - C can be a poor choice.

しかしながら、Cは時代遅れとなった商用言語である COBOL、RPG、BASICなどの言語に対する
best replacement だとみなされるようになりました。
そして多くの賛同者が CとC++を、Pascal一族 (Modula-2やその他のPascalの後継言語を含みます)や
Smalltalk、Eiffel、Actor といったオブジェクト指向言語、
Ada のような汎用目的の言語に対する superior alternatives
としても推奨するようになったのです。
C has its place, but in many cases - especially business programming - C can be a poor choice.

■_今日の十

だいぶ前にリンクだけ拾ってたものから虫干しモードその2。 

Top 10 Secure Coding Practices - CERT Secure Coding Standards
Top 10 Secure Coding Practices

1. Validate input. (入力の正当性検査をすること)
Validate input from all untrusted data sources. Proper input validation can eliminate 
the vast majority of software vulnerabilities. Be suspicious of most external data 
sources, including command line arguments, network interfaces, environmental variables, 
and user controlled files [Seacord 05].

信頼できないデータ源からのすべての入力の正当性検査を行うこと。
適切な入力検査によって主要なソフトウェア脆弱性の多くのものをなくすことが可能である。
外部にあるデータ源の大部分は疑いの目で見ること。
これにはコマンドライン引数やネットワークインターフェース、環境変数、
ユーザーが制御できるファイルといったものが含まれる。
 [Seacord 05]

2. Heed compiler warnings. (コンパイラーの警告に注意すること)
Compile code using the highest warning level available for your compiler and eliminate 
warnings by modifying the code .
使っているコンパイラーの警告レベルを最高にしてコードのコンパイルをすること。
そしてコードを修正し警告を解消せよ。
[C MSC00-A, C++ MSC00-A]

3. Architect and design for security policies.
(セキュリティのポリシーにしたがって構想と設計(architect and desing)をすること)
Create a software architecture and design your software to implement and enforce 
security policies. For example, if your system requires different privileges at 
different times, consider dividing the system into distinct intercommunicating 
subsystems, each with an appropriate privilege set.

software architecture を定め、実装のためのソフトウェアの設計を行った上で
セキュリティポリシーの強制をすること。
たとえばシステムが異なる場面では異なる権限を要求するのであれば、
そのシステムをそれぞれが適切な権限設定を有している独立した
intercommunicating subsystems (相互通信するサブシステム)
に分割することを検討すること。

4. Keep it simple. (単純にすること)
Keep the design as simple and small as possible [Saltzer 74, Saltzer 75]. Complex 
designs increase the likelihood that errors will be made in their implementation, 
configuration, and use. Additionally, the effort required to achieve an appropriate 
level of assurance increases dramatically as security mechanisms become more complex.

設計は可能な限り単純かつ小さなものにすること。[Saltzer 74, Saltzer 75]
複雑な設計は誤りを実装の中や、configuration,  use.
に入れてしまう可能性を増大させてしまう。
それに加えて、appropriate level of assurance (保証の適切なレベル?)のために
要求される労力はセキュリティ機構が複雑になるにつれて劇的に増加する。


5. Default deny. (既定は「拒否」にすること)
Base access decisions on permission rather than exclusion. This means that, by default, 
access is denied and the protection scheme identifies conditions under which access is 
permitted [Saltzer 74, Saltzer 75].

アクセスについての意思決定は exclusion (除外、排除)ではなく permission (許可)を
基準にすること。つまり、デフォルトにおいてアクセスは不許可であり、protection scheme が
アクセスを許可できる条件を判定する。 [Saltzer 74, Saltzer 75]

6. Adhere to the principle of least privilege. (最低権限の原則を遵守すること)
Every process should execute with the the least set of privileges necessary to 
complete the job. Any elevated permission should be held for a minimum time. This 
approach reduces the opportunities an attacker has to execute arbitrary code with 
elevated privileges [Saltzer 74, Saltzer 75].

すべてのプロセスはそのジョブを完了するのに必要最低限の特権のみを有して実行されること。
なんらかの権限昇格は最小時間で行うべきである。
このやり方は昇格した権限で任意のコードを実行しなければならない攻撃者の攻撃の機会を減少させる。
 [Saltzer 74, Saltzer 75].

7. Sanitize data sent to other systems. (ほかのシステムに送るデータはサニタイズすること)
Sanitize all data passed to complex subsystems [C STR02-A] such as command shells, 
relational databases, and commercial off-the-shelf (COTS) components. Attackers may be 
able to invoke unused functionality in these components through the use of SQL, 
command, or other injection attacks. This is not necessarily an input validation 
problem because the complex subsystem being invoked does not understand the context in 
which the call is made. Because the calling process understands the context, it is 
responsible for sanitizing the data before invoking the subsystem.

コマンドシェルや、リレーショナルデータベース、商用の off-the-shelf (COTS) components
のような複雑なサブシステムへ送る全てのデータをサニタイズすること。[C STR02-A]
攻撃者はこれらのコンポーネントに存在しているが使われていない機能をSQLやコマンド、
あるいはその他のインジェクション攻撃を通じて起動してしまうことが可能にできるかもしれない。
呼び出し側のプロセスはコンテキストを理解しているので、サブシステムを起動する前に
データをサニタイズする責務 (responsible) がある。


8. Practice defense in depth. (防御は徹底的に行うこと)
Manage risk with multiple defensive strategies, so that if one layer of defense turns 
out to be inadequate, another layer of defense can prevent a security flaw from 
becoming an exploitable vulnerability and/or limit the consequences of a successful 
exploit. For example, combining secure programming techniques with secure runtime 
environments should reduce the likelihood that vulnerabilities remaining in the code 
at deployment time can be exploited in the operational environment [Seacord 05].

複数の防御戦略でもってリスクを管理し、たとえひとつの防御レイヤーが突破されても
他の防御レイヤーがセキュリティ上の脆弱性に対する攻撃の成功を防ぐようにする。
#チョー訳上等
たとえばセキュアプログラミングとセキュアな実行環境を組み合わせることによって
開発時のコードに残っていた脆弱性が操作環境において exploit されてしまう危険性を
減少させるべきなのである。 [Seacord 05]

9. Use effective quality assurance techniques. (効果的な品質保証の技法を使え)
Good quality assurance techniques can be effective in identifying and eliminating 
vulnerabilities. Penetration testing, fuzz testing, and source code audits should all 
be incorporated as part of an effective quality assurance program. Independent 
security reviews can lead to more secure systems. External reviewers bring an 
independent perspective; for example, in identifying and correcting invalid 
assumptions [Seacord 05].

優れた品質保証の技法は、脆弱性の発見と除去とを効果的に行うことを可能とする。
Penetration testing, fuzz testing, そして source code audits といったものは
効率の良い品質保証プログラムの一部としてすべて incorporate しておくべきものである。
独立したセキュリティレビューはシステムをよりセキュアにすることにつながる。
外部レビューは independent perspective を持ち込むものである。
for example, in identifying and correcting invalid assumptions [Seacord 05].


10. Adopt a secure coding standard. (セキュアコーディングの標準を適用すること)
Develop and/or apply a secure coding standard for your target development language and 
platform.

ターゲットとなる開発言語および開発プラットフォーム向けのセキュアコーディングの
標準を適用して開発すること。

Bonus Secure Coding Practices

1. Define security requirements. (セキュリティの要求項目を定義すること)
Identify and document security requirements early in the development life cycle and 
make sure that subsequent development artifacts are evaluated for compliance with 
those requirements. When security requirements are not defined, the security of the 
resulting system cannot be effectively evaluated.

セキュリティ上の要求項目を開発ライフサイクルの初期段階で identify しドキュメント化
すること。そしてそのあとの development artifacts  がその要求項目を満たすものである
かどうか確実に評価すること。セキュリティ上の要求項目が定義されていなければ
システムのセキュリティを効率よく評価することは不可能である。


2. Model threats. (脅威のモデル化?)
Use threat modeling to anticipate the threats to which the software will be subjected. 
Threat modeling involves identifying key assets, decomposing the application, 
identifying and categorizing the threats to each asset or component, rating the 
threats based on a risk ranking, and then developing threat mitigation strategies that 
are implemented in designs, code, and test cases [Swiderski 04].

そのソフトウェアが標的にされることを見越した脅威モデル (threat modeling)を使うこと。
脅威モデルはkey assets, decomposing the application, 
各 asset やコンポーネントに対する脅威の identifying とカテゴライズ、
リスクに基づいた脅威のレーティングを必要とし、
and then developing threat mitigation strategies that 
are implemented in designs, code, and test cases [Swiderski 04].
#最後の文わかんねーー
#文の構造が把握できない。

■_

このネタ、Linusが実際に書いたのはちょっと前のことだと思うけど 新山さんが訳して紹介してから火がついた? 


Linus「C++プログラマはウンコ。寄ってくるな

1 デフォルトの名無しさん [] Date:2009/01/24(土) 13:32:25  ID: Be:
    > Git のソースコードを最初に見たとき、ヘンだと思ったこと:
    > 1. C++ じゃなくてただの C を使ってる。理由は謎。移植性が
    > どうとか言わないで、
    > そんなのウソに決まってるから。

    *あんた* のほうこそ大ウソつきだ。

    C++ はひどい言語だ。これは、多くの平均以下のプログラマーが
    使ってるためにさらに輪をかけてゲロゲロになっていて、どうし
    ようもないゴミが簡単に生産されるようになってる。正直いって、
    C を選ぶ理由が C++ プログラマーを追っぱらうため *だけ* だっ
    たとしても、それ自体、C を使う強力な理由になりうる。

    Linus Torvalds

    http://tabesugi.net/memo/2009/1a.html#152154

2 デフォルトの名無しさん [sage] Date:2009/01/24(土) 13:33:14  ID: Be:
    マでやれよカス 

3 デフォルトの名無しさん [sage] Date:2009/01/24(土) 13:35:12  ID: Be:
    C++ができたら、ほかの言語はなんでもできるみたいな自信家多いな　> C++PG 

4 デフォルトの名無しさん [sage] Date:2009/01/24(土) 13:37:27  ID: Be:
    いまだにC++がオブジェクト指向言語だと思ってるやつもいるしな 

6 デフォルトの名無しさん [sage] Date:2009/01/24(土) 13:42:36  ID: Be:
    Gitのソースを見てみたら、素直な書き方なんで心が洗われるような気がした。
    C++好きのやつは、初心者のころの素直な気持ちを思い出して欲しい。 

7 デフォルトの名無しさん [sage] Date:2009/01/24(土) 13:44:15  ID: Be:
    仕事してると Linus の言う事はある程度分かってくる。
    C++ 使いこなせる奴自体が少ないというのが C++ の大きな問題だということに。 

8 デフォルトの名無しさん [sage] Date:2009/01/24(土) 13:54:59  ID: Be:
    悪いけどLinusってフレーマーっていうイメージしかないから
    いまいち発言に説得力はないんだよね。論理的でもないし。 

9 デフォルトの名無しさん [] Date:2009/01/24(土) 14:09:03  ID: Be:
    Linus氏はポインタで優越感を感じテンプレートに劣等感を感じているのです。
    Ubuntuです。
    思いやりです。 

10 デフォルトの名無しさん [] Date:2009/01/24(土) 14:10:57  ID: Be:
    >>4
    C++はオブジェクト指向言語だが？ 

11 デフォルトの名無しさん [sage] Date:2009/01/24(土) 14:14:00  ID: Be:
    Linusが言ったということだけで2chの厨房レベルの発言でも
    感化される権威に弱い日本人って…
    せいぜい現場の親方どまりのLinusが
    Bjarneに劣等感いだきまくりなのが見え見えでなんとも…

    ちなみに俺はLinusがFedora使いだと知った時点であんまり信用できんな、と思いはじめた。 

12 デフォルトの名無しさん [sage] Date:2009/01/24(土) 14:14:42  ID: Be:
    Linusが良いことを言った!

    クラスベースのオブジェクト指向言語なんて、オブジェクト指向
    じゃないし。言語仕様がコロコロ変わり過ぎる。しかも互換性無し。
    C++はゲロゲロのウンコ。C++マは、ウンコにたかる蝿に過ぎない。 

20 デフォルトの名無しさん [sage] Date:2009/01/24(土) 14:42:22  ID: Be:
    いいこと言ってるな、とは思うが、cで書いてるとC++のSTLとかメンバ変数とかを使いたくなる
    こともあるんだよなあ。いちおう、便利なところは便利だわC++。
    世の中の「cわかります」と「C++わかります」って言ってる奴のほとんどがわかってない、
    というのは同意。

21 20 [sage] Date:2009/01/24(土) 14:45:30  ID: Be:
    メンバ変数じゃなくてメンバ関数だよ。メンバ変数ならcにもあるっての。 

22 デフォルトの名無しさん [sage] Date:2009/01/24(土) 14:53:53  ID: Be:
    型チェックを強化してくれ。
    あとやっぱりテンプレートも欲しい。
    そしたら C でもいい。

    あとやっぱ無名 union も欲しい。
    C++ に無いけど関数ない関数もくれ(0xのラムダは却下)。
    STL 相当のも欲しいけど、Boost みたいな何かができることを期待する。 

23 デフォルトの名無しさん [sage] Date:2009/01/24(土) 14:54:24  ID: Be:
    ところでみんなはC++分かってると豪語できる？ 

24 デフォルトの名無しさん [sage] Date:2009/01/24(土) 14:56:51  ID: Be:
    cならすっかりわかっていると言い切れるが、C++はよくわからん。 

25 デフォルトの名無しさん [sage] Date:2009/01/24(土) 15:09:03  ID: Be:
    　C++が最強だと言っていたときがあったが、いまではC言語を使っている。
    複数人で開発するときに理解度が違いすぎて使えない。
    とはいっても、ネームスペースとテンプレートが欲しい。
    しょうがないから、いろいろな方法で同じようなことしているけどね。 

26 デフォルトの名無しさん [] Date:2009/01/24(土) 15:11:40  ID: Be:
    複数人で開発するときにはCよりC++だろ。
    常識で考えても非常識で考えても。 

27 デフォルトの名無しさん [sage] Date:2009/01/24(土) 15:22:10  ID: Be:
    C++は、フールプルーフが無いからな。
    成果物の質はプロジェクトのメンバーの最底辺に揃えられる。 

31 デフォルトの名無しさん [sage] Date:2009/01/24(土) 15:53:04  ID: Be:
    おいお前ら、
    Linusが何千人もの（自称含めた）開発者を相手にしていることを忘れるなよ・・・

    >>29
    > 「カッコいい」と勘違いしてる奴がいるな。

    あー、中二病っていうんですかね。 

33 デフォルトの名無しさん [sage] Date:2009/01/24(土) 16:01:40  ID: Be:
    Firefox
    Google Chrome
    OpenOffice

    これらはLinusのいう「ひどい言語」で作られています。ゲロゲロです。

結構スレの流れが速いけど一応チェックしとくか。 

【逆立ちしても】使えない新人 0x18
664 仕様書無しさん [sage] Date:2009/01/20(火) 17:15:11  ID: Be:
    ポインタポインタ言ってるが、初級者と見分けるのに
    『malloc(),qsort()それぞれのサンプルプログラムが書ける』
    ではいかが？初心者卒業課題程度の位置づけで。普段使ってる使ってないは人によっていいと思う。

    高級言語では必要ない知識もあるかもしれんが、中上級者が持つべき知識が大体入ってると思う。
    普段ポインタを使うか使わないかは、仕事場依存として、
    上記のサンプルとその意味を作成＆理解できてれば、たいていの業務で使える人材じゃない？
    (ポインタ・メモリ領域の確保/開放・ポインタや配列の複合系の知識・自作関数・関数ポインタ) 

665 仕様書無しさん [sage] Date:2009/01/20(火) 19:09:53  ID: Be:
    たかが変数の1種の解説に何冊も本が出て馬鹿がそれをたくさん買う。 

666 仕様書無しさん [sage] Date:2009/01/20(火) 20:01:28  ID: Be:
    アセンブラやったことがあれば、「ああ、アドレスね」でおしまいなのに。 

668 仕様書無しさん [] Date:2009/01/20(火) 22:08:07  ID: Be:
    qsortでポインタが使える人かどうか判断できるか？

    俺ポインタ使えるけど
    qsortの仕様とか忘れた

    解説読めば
    あーはいはいって思い出すけど 

669 仕様書無しさん [sage] Date:2009/01/20(火) 22:11:23  ID: Be:
    qsort()は比較に使う関数を指定する必要があるって事で 

672 仕様書無しさん [sage] Date:2009/01/21(水) 01:27:17  ID: Be:
    >>666
    ポインタはアドレスとは違うぞ？
    ポインタは、「型」を指すところに存在意義があるんだから。 

673 仕様書無しさん [sage] Date:2009/01/21(水) 01:36:21  ID: Be:
    こういうところまで突っ込むやつがいるから使えない新人が使えないままなんだな。

674 仕様書無しさん [sage] Date:2009/01/21(水) 02:01:44  ID: Be:
    というか、一面だけ理解して
    「おれはポインタ理解したぜ ﾌﾌﾝ」
    なんて勘違いしている使えない奴が多いのが現実 

675 仕様書無しさん [sage] Date:2009/01/21(水) 02:38:24  ID: Be:
    ポインタって勘違いするほど複雑だったっけ？
    算数ができれば理解できるレベルでしょ 

676 仕様書無しさん [sage] Date:2009/01/21(水) 02:44:03  ID: Be:
    それはわからないヤツの思考がわからないヤツの台詞
    わからないヤツは算数だとか関係なくそれ以前のところで躓くので 

677 仕様書無しさん [sage] Date:2009/01/21(水) 06:18:42  ID: Be:
    >>672
    うん、だから、アセンブラやってた奴にとっては、
    「いままでやってたいろいろ面倒なことをしなくて済む便利なアドレス指定方法」
    という感覚ですんなりわかる。 

678 仕様書無しさん [sage] Date:2009/01/21(水) 08:15:12  ID: Be:
    少なくとも「一面だけ理解」しようとしたり「勘違い」したりできるほど
    複雑な概念じゃないよな。
    全く理解できないか何の問題もなく使えるかのどちらかだ。
    >>674はどんな状況を想定してるんだろ。 

689 仕様書無しさん [] Date:2009/01/21(水) 18:45:47  ID: Be:
    昔、自称C言語マスターにプログラム組ませたら

    char moji[400000][10];

    という処理を書いてくれて、メモリ不足でプログラムが吹っ飛ぶという面白い結果になったっけな。 

690 仕様書無しさん [sage] Date:2009/01/21(水) 20:13:01  ID: Be:
    >>689
    ヒープが枯渇するなｗ

691 仕様書無しさん [sage] Date:2009/01/21(水) 20:54:12  ID: Be:
    >>690
    ヒープじゃなくてスタックに取るんじゃない？ 

693 仕様書無しさん [sage] Date:2009/01/21(水) 21:16:26  ID: Be:
    >>691
    ローカル変数ならそうだな。
    ただ、こんなひどい変数宣言をするようなやつはグローバル変数使いまくりかもしれんぞww 

694 仕様書無しさん [] Date:2009/01/21(水) 21:36:12  ID: Be:
    あ・・・ありそうｗ

    グローバル変数で使いまわしとかｗ 

704 仕様書無しさん [] Date:2009/01/22(木) 01:22:04  ID: Be:
    ポインタがなぜ難しいかというと
    変数の中に別の変数が入っている場所を示す値が入っていることだと思う。
    物事を一次元でしか考えられない人には絶対に理解できない。 

705 仕様書無しさん [sage] Date:2009/01/22(木) 01:31:14  ID: Be:
    ポインタのポインタとかなってると嫌になってくる。
    ポインタシフトとかこわいっしゅ。 

706 仕様書無しさん [sage] Date:2009/01/22(木) 01:34:25  ID: Be:
    いつまでスレ違いの話を続けるつもりだよ
    このスレで頑張ったって使えない新人はポインタを理解してくれないよ 

707 仕様書無しさん [sage] Date:2009/01/22(木) 02:02:34  ID: Be:
    ポインタってほんと踏み絵みたいなものだよなｗ
    ポインタと言えば配列との違いも頻出かと 

741 仕様書無しさん [] Date:2009/01/23(金) 10:02:25  ID: Be:
    ポインタなんて使うのは低級言語だけ　現代は不要 

742 仕様書無しさん [sage] Date:2009/01/23(金) 11:07:01  ID: Be:
    たしかに、アセンブラ、C/C++以外はいらんかな

    でも、参照渡しについては知っておいたほうがよい

    参照型≠ポインタ型（値型） 

753 仕様書無しさん [sage] Date:2009/01/23(金) 13:44:40  ID: Be:
    ポインタと参照は別モノ
    ただし、Javaのヌルポはスペルミスなんだよ
    Javaは参照しか存在しない、ポインタなんて存在しないんだよ

    多分．．． 

754 仕様書無しさん [] Date:2009/01/23(金) 13:48:05  ID: Be:
    ポインタと参照が別物というひとは一度Javaの思想を読んでみるといいよ 

755 仕様書無しさん [sage] Date:2009/01/23(金) 13:49:07  ID: Be:
    この流れだから言える







    「Javaは参照しか存在しないの？」
    「どうざんしょ（参照）」

2009年01月23日

■_

・メールアドレスのイメージファイルがサーバーからなくなっていたのを復旧しました
rimnet のサーバー障害のときのあおりで消えていた模様。 今まで気がつかなかった＞＜

・C言語を256倍
ポインターを修飾する属性として far や near (MS-C 6.0あたりだと _far/_near みたいに アンダースコア付きのは有効じゃなかった。たぶん)はよーーく覚えているのですが、 baesd ポインターは忘れていた。まあほとんど使う機会もなかったし。 しかしMK_FPマクロとか懐かしいw

■_

■_ 



Rubyについて Part 33
555 デフォルトの名無しさん [sage] Date:2009/01/21(水) 23:55:54  ID: Be:
    最初からガンガンClassをfreezeしまくって
    モンキーパッチが出来ないrubyが欲しい。標準クラスを改変されるなんて
    怖すぎる。 

556 デフォルトの名無しさん [sage] Date:2009/01/22(木) 00:00:27  ID: Be:
    それは言語の責任じゃないとRubyは考える
    何してるかわからんような怪しいライブラリはそもそも使うなよ 

557 デフォルトの名無しさん [sage] Date:2009/01/22(木) 00:02:10  ID: Be:
    >>552
    「来た！Ruby、もう止まらない。」「来た！盾来た！」

    「これで　勝　つ　る！」

    >>556
    Railsとかの主要なライブラリで 

558 デフォルトの名無しさん [sage] Date:2009/01/22(木) 00:03:00  ID: Be:
    破綻が起きるまで>>>56でいいと思う
    Railsではあっさり破綻して一周してる感じだが 

560 デフォルトの名無しさん [] Date:2009/01/22(木) 01:06:25  ID: Be:
    >>558
    そうそうそんな感じｗ 

564 デフォルトの名無しさん [sage] Date:2009/01/23(金) 13:05:30  ID: Be:
    るｂｙｵﾜﾀ･･･
    http://slashdot.jp/it/article.pl?sid=09/01/23/0121226 

565 デフォルトの名無しさん [sage] Date:2009/01/23(金) 16:24:45  ID: Be:
    Pythonはどこだ、と思った。
    こういう調査なら圧倒的にPythonが強いと思ったのにな。 




初心者のためのプログラミング言語ガイド Part13
75 デフォルトの名無しさん [] Date:2009/01/23(金) 02:31:32  ID: Be:
    OOP を学びたい人向けの言語はなんですか？ 

76 デフォルトの名無しさん [sage] Date:2009/01/23(金) 04:12:49  ID: Be:
    英語
    OOP説明してある本を読みまくるべし 

77 デフォルトの名無しさん [sage] Date:2009/01/23(金) 05:23:30  ID: Be:
    >>75
    最初のうちは特定のプログラミング言語に絞ってOOPの勉強をするのはお勧めしない
    無理して英語でなくてもいいとは思うけど日本語でOOP関連の良書となると 

78 デフォルトの名無しさん [sage] Date:2009/01/23(金) 07:23:49  ID: Be:
    >>75
    　Smalltalk 

79 デフォルトの名無しさん [sage] Date:2009/01/23(金) 08:02:01  ID: Be:
    >>76
    この意見はよく見かけるのですが、OOPというのは日本語向きでないという
    ことがあるのですか? 

80 デフォルトの名無しさん [sage] Date:2009/01/23(金) 09:45:21  ID: Be:
    >>79
    　いや、そうではない。
    　自然言語としても、日本語のほうがOOPに近い。
    　
    ・I drew a map. （私は地図を描いた。 ）
    ・I drew the veil over my face. （私はそのベールを顔に被った。）
    ・I drew closer to the table. （私はテーブルのもっと近くに移動した。）

    　英語はあまりOOPではなく、激しくオーバーロードされている動詞が目的語に応じて動作を変える。
      つまり、Cの関数ようだ。

    　一方、日本語だと、

    ・私は約束を守った。 （I kept my promise.）
    ・私は規則を守った。 （I followed the rule.）
    ・私は彼女を守った。 （I protected her.）

    となっていて、目的語（オブジェクト）の動詞（メソッド）が呼ばれていることが分かる。
    　目的語の登場時に動詞の解釈の曖昧さがすでに排除されており、伝達に難があるとしても、
      思考において、日本語は英語より優れている。
    　エレガントなC#でもクラスライブラリは日本語と同じような方法がとられていて、
      「Thread.Join()」と「String.Join()」のそれぞれの「Join()」はまったく違うが、
       我々は大きく迷うことがない。（引数の数で動作が違う場合、文献で確認したりするんだけど。）
    　 OOPについて書かれた名著には、英語のものほうが多い。OOPが英語からかけ離れているからこそ、
       文献が揃うのだよ。

    （文化はわざわざいわなくても分かっていることを明示的に示さない。道徳哲学が大規模化する民族、
    たとえば中国人は、あまり道徳的だという評判を得ていない。一方、思考において非常に優れている
    日本語を使う日本人はわざわざいわなくてもわかることが多いので、日本では大規模な哲学が発達しにくい。
    個人間の好意的感情の高ぶりとある種の使命感という哲学的な案件も、「～萌え」で済ませられる。
    この「～萌え」もOOPだろ。） 

Lisp Scheme Part25
72 デフォルトの名無しさん [sage] Date:2009/01/20(火) 22:57:56  ID: Be:
    Head First Common Lispはまだか。 

73 デフォルトの名無しさん [sage] Date:2009/01/22(木) 03:10:07  ID: Be:
    たぶん一生でないよw 

74 デフォルトの名無しさん [sage] Date:2009/01/22(木) 13:05:51  ID: Be:
    主婦の友増刊号「誰にもわかるコモンリスプ」 

75 デフォルトの名無しさん [sage] Date:2009/01/22(木) 14:23:07  ID: Be:
    片仮名で書くとめちゃくちゃイメージ違うなぁ。 

76 デフォルトの名無しさん [sage] Date:2009/01/22(木) 16:32:13  ID: Be:
    フランス語みたい。

    イロムサコン・フィヨンセ・コモンリスプ 

77 デフォルトの名無しさん [sage] Date:2009/01/23(金) 01:35:12  ID: Be:
    特別寄稿ガイ・スチール・ジュニア氏
    「君もリスプやらないか？」 

78 デフォルトの名無しさん [sage] Date:2009/01/23(金) 02:00:30  ID: Be:
    「いいこと思いついた。
    お前、俺のテイルジャンプで、メッセージパッシングしろ」 

79 デフォルトの名無しさん [sage] Date:2009/01/23(金) 17:50:52  ID: Be:
    「アッーーク！」 


推薦図書/必読書のためのスレッド 44
139 デフォルトの名無しさん [sage] Date:2009/01/23(金) 22:23:51  ID: Be:
    必要になったときにはもう売ってなかったりするから、とりあえず買っとく癖がついたわ
    まんまと戦略にはまってる気もするけど 

140 デフォルトの名無しさん [sage] Date:2009/01/23(金) 22:28:03  ID: Be:
    わかるｗ
    前ほしかった本が絶版になったことがあって、とりあえず買っておくクセが付いた。
    限定に弱い人間だな。 

141 デフォルトの名無しさん [sage] Date:2009/01/23(金) 22:31:37  ID: Be:
    そう思って買った本に限って第２版とか出て腹立つ 

142 デフォルトの名無しさん [sage] Date:2009/01/23(金) 22:36:15  ID: Be:
    そうそうｗ
    しかも次版は内容、訳が改善されてたりな。 

143 デフォルトの名無しさん [sage] Date:2009/01/23(金) 23:02:18  ID: Be:
    ゲームプログラマになる前に覚えておきたい技術はあくまで
    ゲームプログラマになる前に覚えておきたい技術であって、
    ゲームバリバリに作ってるような人のための本じゃないから
    そこだけは勘違いしないようにね。 

144 デフォルトの名無しさん [sage] Date:2009/01/23(金) 23:09:28  ID: Be:
    はーい

うははは 139-142 とは楽しい会話ができそうな気がするw

■_ Python が先陣を切ったわけですが

Ruby 1.9.1 とか Perl 6が正式リリースされたときにどういう反応が出るのかなあ。 と考えてみたり。 


Why I'm excited about Python 3
Why I'm excited about Python 3

This is a rough transcript, with links, of a 3-minute lightning talk I gave at LCA. It'
s obviously not a complete argument; just a 180-second pitch for why the drama about 
Py3k is all smoke and no fire.

I'm excited about porting my code to Python 3, and you should be, too.
#俺はもうpy3k でバリバリ書いているぜ、キミもそうしなよ。的な


I'm sure all the Python users here are aware of the recent release of Python 3.0. 
Python 3.0 is the first Python release in something like a decade that is 
fundamentally incompatible with the previous release. There's been a lot doom & 
gloom & naysaying about this. Some have suggested that Python 3 marks the moment 
where Python jumped the shark.

That's not true, and I'm going to tell you why.

So, I'm one of the maintainers of Django. Django's about 75 kLOC, and it won't run 
under Python 3. Nor will anything I've written in Python to date. In my near future I 
see quite a bit of time porting code to Python 3 — as does every maintainer of every 
other Python program out there.

Now this sounds very scary. It sounds like I'm saying that every single one of the 
millions of lines of Python out there is going to have to be ported to a new language. 
You can see why this would cause a lot of angst: it seems like an impossible task.

But I'm still incredibly excited about porting to Python 3, and I'm going to give 
you three reasons why you should be excited, too.

First, there's no hurry.

Python 3.0 is out today, but I don't think anyone really expects you to switch to it 
immediately. Support for the Python 2 series will continue in parallel for quite some 
time. Many features of Python 3 will be backported into the Python 2 series, so you 
can make the move in baby steps.
#3.0がリリースされたけれども、2系列も3系列と並行してサポートされ続ける
#3から2.xにバックポートされた機能も結構あるので少しずつ移行のステップを踏める

A five-year timeline for moving to Python 3 is entirely reasonable. Python 2 isn't 
going anywhere.
#3系列への移行には5年のタイムラインが設定されている。
#2系列がどっかにいってしまうわけではない。

Second, it's not going to be that hard.

Python 3 ships with a tool, 2to3 which will automate a great deal of the gruntwork. A 
great deal of code can be automatically upgraded to Python 3. Where tools won't work, 
there are human resources. There's a dedicated python-porting mailing list for help 
with porting code to Python 3.
#移行の手助けをしてくれる 2to3 てツールがあるよ

If you've got good test coverage, porting these final bits should be easy, though not 
exactly fun. Run tests, fix failures, rinse, and repeat. If you don't have good test 
coverage, I don't have a lot of sympathy for you.

Finally, it'll be worth your effort.

Python 3 has a huge set of improvements I can't possibly enumerate. But more 
importantly, Python 3 is simply a better foundation from which to build the language 
forward. Improvements past 3.0 will come quicker and be more profound.

We all refactor code to take advantage of better APIs, or to build on improved 
frameworks, or to make an investment in future technology. Refactoring is part of the 
lifecycle of a healthy project. Moving to Python 3 is one of these refactorings. And 
we all know that while refactoring can be painful, the grass is indeed greener on the 
other side of this particular fence.

So, relax and don't worry. Trust in Guido and your faith shall be rewarded!
← Descriptivists and Prescriptivists

移行は喫緊のことではない(2.6から2.7へもあるよ)。 移行はそんなに困難なことではないよ。 移行に手間をかけてもそうするだけの見返りはあるよ。 といった感じでしょうか。

■_ Perl 6デザインミーティング

今回の注目点は一箇所。 

Sage Feeds
Larry:

    * real life has been hectic
    * some family sickness
    * lots of meetings at work
    * mostly just sniping at various design issues
    * not a lot of bandwidth to think through deeper questions
    * periodically running tests on STD to make sure it keeps passing tests
    * not much exciting coming up until April
    * going to Oslo, and then a tour of Ivy League colleges

■_ 努力の方向が違うよ

初心者です。Perlではどんな時変数宣言は必要ですか？ -OKWave

Perl初心者です。
マニュアル本を見ると、Perlでは特に変数を宣言しなくても扱えるようになっていますよね。

今まで幾つか自作ＣＧＩプログラムを作ってきたのですが、一度も my や localといった変数宣
言を使った事がありません。

プログラム自体は正常に稼働しているので今まで全く無視していたのですが、こちらのPerlカテ
ゴリの質問などを参照させていただいていると、皆さん必ず変数を　my　で宣言してらっしゃい
ます。

これは行った方がよいものなのですか？

宣言する事のメリット、宣言しない事のリスク、もしくはしたほうが良い場合、しない方が良い
場合等を教えてください。とりあえず、サブルーチン内で宣言すると他のサブルーチンでは使え
ないらしい、という事だけは朧気に…

よろしくお願いします。

他の言語のように、その変数が実数型であるかとか、そういう宣言は必要ありませんが、myや
loclaは、できるだけ使うようにしています。

　オブジェクト型なので、サブルーチンに分割して製作することが多いのですが、そうすると他
のサブルーチンやメインのプログラムと衝突することがでてきます。特に良くできたサブルーチ
ンを他のプログラムで流用したいときなど・・。

　単一の簡単なプログラムでは、my やlocalの宣言は、絶対必要というわけではありませんが、
宣言する癖を付けておいたほうが楽になります。この変数は使ったっけ???と悩むより、local宣
言ししまえば・・

　そんな感じでいます。

ありがとうございます。

perlを始める前に使っていた簡易スクリプト言語が、変数宣言しないタイプでしたので、すっか
り宣言しないクセがついてしまっていました。

やはり大きなプログラムを組むとなると、宣言しておいたほうが安全、ということになるのでし
ょうか。

今は、間違って同じ変数を使わないよう、
  ノートに変数リストを書き出して管理していますが、
大きなプログラム中で、絶対に宣言をしなくてはいけないケースなどはありますか？

今現在、１０００行～１５００行くらいのプログラムが主で、そんなに大きくない為なのか特に
不便を感じていないので、宣言の意図がいまいちピンと来ません。

名前の衝突があるかどうか「ノート」に「変数のリスト」を作ってどうのってのはやめて ○|￣|＿ COBOLのプログラム作ってんじゃないんだから。

2009年01月22日

■_

・ぢゃいあんとろぼのDVD BOX買った。 最初のLDから考えるとずいぶん安くなってるよなあ。 LD時代はたしか一枚9800円くらいで一話収録でそれが六枚。 今回のBOXだと6話全部収録で15000円しない。 

Perl6-Cookbook-0.03 - search.cpan.org
http://search.cpan.org/~szabgab/Perl6-Cookbook-0.03/

chromatic / parrot-0.9.0.1 - search.cpan.org
http://search.cpan.org/~chromatic/parrot-0.9.0.1/

Announcing Beginning Scala - David Pollak's Blog
http://blog.lostlake.org/index.php?/archives/88-Announcing-Beginning-Scala.html

R. John Shields ≫ Javascript's revenge?
http://rjohnshields.com/blog/?p=79

An Introduction to Scala
http://fupeg.blogspot.com/2009/01/introduction-to-scala.html

X# - XML oriented programming language - I can't believe they are serious about this
http://www.reddit.com/r/programming/comments/7rc5v/x_xml_oriented_programming_language_i_cant/

ITエンジニアの望み。尊敬できる仲間と仕事がしたい － ＠IT自分戦略研究所
http://jibun.atmarkit.co.jp/lcareer01/rensai/tenmoku09/tenmoku01.html

文字コード変換ツール「nkf」の最新版が公開 | パソコン | マイコミジャーナル
http://journal.mycom.co.jp/news/2009/01/21/005/index.html

CLR 徹底解剖: マネージ コードとネイティブ コードの相互運用性の推奨事項
http://msdn.microsoft.com/ja-jp/magazine/2009.01.clrinsideout.aspx?rss_fdn=MSDNTopNewInfo

某日記(後期)
http://diary.imou.to/~AoiMoe/2009.01/late.html#2009.01.21_s01_p04


  
しかしなあ、X Window System に 10 年以上携わっている俺が言うのもなんですが、
正直 X はウンコだと思うぞ。まああらゆるウィンドウシステムはどこかしら腐って
いるもんで、腐っていないのはどこにも存在しない「ぼくのかんがえたウィンドウシステム」だけだな。
  




文字化けに関するトラブルに強くなる【基礎編】 （1/3） － ＠IT
http://www.atmarkit.co.jp/fdb/rensai/ora_admin/05/oraadmin0501.html

Ruby 1.9に移行する際に注意すべき10のポイント - なんとなく日記
http://d.hatena.ne.jp/conceal-rs/20090119/1232348671

Visual Basic: リフレクションを使用して COM オブジェクトを検査する
http://msdn.microsoft.com/ja-jp/magazine/2009.01.basicinstincts.aspx?rss_fdn=MSDNTopNewInfo

セキュリティに関するブリーフィング: SDL 脅威のモデル化ツール
http://msdn.microsoft.com/ja-jp/magazine/2009.01.securitybriefs.aspx?rss_fdn=MSDNTopNewInfo

実践的なユーザビリティ: 実用的なエラー メッセージ
http://msdn.microsoft.com/ja-jp/magazine/2009.01.usabilityinpractice.aspx?rss_fdn=MSDNTopNewInfo

配列とループ処理を理解しよう - ＠IT
http://www.atmarkit.co.jp/fcoding/articles/objc/05/objc05a.html
http://www.atmarkit.co.jp/fcoding/articles/objc/05/objc05b.html
http://www.atmarkit.co.jp/fcoding/articles/objc/05/objc05c.html
http://www.atmarkit.co.jp/fcoding/articles/objc/05/objc05d.html

Sanseido Word-Wise Web ［三省堂辞書サイト］ » 『三省堂国語辞典』のすすめ その51
Hexenkessel - 他人のＬＡＮを経由して、携帯ゲーム機から出された脅迫文の差出人を特定するのは困難で、摘発は 全国初
Hexenkessel - 捕鯨に反対する人の中には，すべての鯨類が絶滅に瀕しており，捕鯨国がそれを捕り尽くそうとしていると単純に...
プログラマの素質って何ですか - Yahoo!知恵袋
codeなにがし::美しいコード
コンピュータ時刻2038年問題 -OKWave
ゲーム組み込みスクリプトは急速に進化中　－IGDA日本SIG-GT12レポート - iNSIDE
無差別に技術をついばむ鳥 ネタつつき20－軽視されている概念アクセスとプログラミング言語の進化

人のブログではピヨピヨ読みづらい書き方しといて、自分のブログではまともな文体ってのはどうなんですかね。
普通逆じゃないですか？


KBasic V1.87 Released - PLNews: Programming Language News
KBasic V1.87 has been released. It is a BASIC dialect running on Windows, Mac OS X and Linux. "

Ctpp 1.0.46 Released - PLNews: Programming Language News
Ctpp 1.0.46 has been released. It is a preprocessor for Ctalk, an object-oriented extension of C. 

PLT Scheme 4.1.4 Released - PLNews: Programming Language News

■_ The History of Python: Personal History - part 1, CWI

というわけで昨日の続きのエントリ。 一文がなげーよパパっ 

The History of Python: Personal History - part 1, CWI
http://python-history.blogspot.com/2009/01/personal-history-part-1-cwi.html
Personal History - part 1, CWI

Python's early development started at a research institute in Amsterdam called CWI,
which is a Dutch acronym for a phrase that translates into English as Centre for
Mathematics and Computer Science. CWI is an interesting place; funded by the Dutch
government's Department of Education and other research grants, it conducts
academic-level research into computer science and mathematics. At any given time there
are plenty of Ph.D. students wandering about and old-timers in the profession may
still remember its original name, the Mathematical Centre. Under this name, it was
perhaps most famous for the invention of Algol 68.

Pythonの初期の開発は CWI と呼ばれていたアムステルダムにある research institute で始まりました。
CWI は英語でいうところの Centre for Mathematics and Computer Science. にあたるオランダ語
表記での頭字語 (acronym)です。CWI は面白い場所でした。
オランダ政府の教育部門(省?)やその他の research grants によって設立されたもので、
it conducts academic-level research into computer science and mathematics.
#コンピュータサイエンスや数学の学会レベルの研究を行っていました?
At any given time there are plenty of Ph.D. students wandering about 
and old-timers in the profession may still remember its original name, the Mathematical Centre.
#数多くのPh.D. studentsがいて
#profession していた old-timers は元々の名前である
#Mathematical Centre の方を思い浮かべるかもしれません
その名前は Algol 68 の開発が行われていたということが最も知られているものでしょう。

I started working at CWI in late 1982, fresh out of university, as a programmer in the
ABC group led by Lambert Meertens and Steven Pemberton. After 4 or 5 years the ABC
project was terminated due to the lack of obvious success and I moved to CWI's Amoeba
group led by Sape Mullender. Amoeba was a micro-kernel-based distributed system being
jointly developed by CWI and the Vrije Universiteit of Amsterdam, under leadership of
Andrew Tanenbaum. In 1991 Sape left CWI for a professorship at the University of
Twente and I ended up in the newly formed CWI multimedia group led by Dick Bulterman.

1992年の終盤にわたしはCWIで働き始めました。そこでは、大学を卒業したてのプログラマーとして
Lambert Meertens and Steven Pemberton が指揮を執っていたABCグループに所属していました。
4年か5年の後、はっきりとわかる成果をあげられなかったのでABCプロジェクトは終了してしまいました。
そしてわたしは Sape Mullender がリーダーであったCWIのAmoeba グループに異動したのです。
Ameba はマイクロカーネルベースの distibuted システムで、CWI と (Andrew Tanebaum がリーダーを
務めていた)　Vrije Universiteit of Amsterdam とで共同開発をしていたものです。
1991年に at the University of Twente でのprofessorship のために Sape はCWIを離れ、
わたしは最終的に新しく結成された Dick Bulterman 指揮下の CWI multimedia group 
に所属することになったのです。

Python is a direct product of my experience at CWI. As I explain later, ABC gave me
the key inspiration for Python, Amoeba the immediate motivation, and the multimedia
group fostered its growth. However, so far as I know, no funds at CWI were ever
officially earmarked for its development. Instead, it merely evolved as an important
tool for use in both the Amoeba and multimedia groups.

あとで説明するように、Python は CWIにおける direct product of my experience でした。
ABCはわたしに、Pythonと
Amoeba the immediate motivation, and the multimedia group fostered its growth.
に対する key inspiration をわたしに与えてくれました。
しかしわたしの知る限りでは
その開発が公式にCWIに earmarkされて資金が出されたことはありませんでした。
その代わりとして Python は Amoeba と multimedia groups の両方で使われる重要なツールとして
進化していったのです。

My original motivation for creating Python was the perceived need for a higher level
language in the Amoeba project. I realized that the development of system
administration utilities in C was taking too long. Moreover, doing these in the Bourne
shell wouldn't work for a variety of reasons. The most important one was that as a
distributed micro-kernel system with a radically new design, Amoeba's primitive
operations were very different (and finer-grain) than the traditional primitive
operations available in the Bourne shell. So there was a need for a language that
would “bridge the gap between C and the shell.” For a long time, this was Python's
main catchphrase.

わたしがPythonを作った元々の動機は、Amoeba プロジェクトで高水準言語が必要なことが
わかったからです。わたしはC でシステム管理用のユーティリティを開発することは
時間がかかりすぎることを認識していました。それに加えて、システム管理を Bourne シェルで
行うことはさまざま理由があってうまく行かなかったのです。
最も重要だったのは、distributed micro-kernel system が全くの新しい設計 
(radically new design) であったために Amoeba の primitive operations は
Bourne shell で可能だった伝統的な primitive operations とはとても異なっていたのです
(and finer-grain)。ですから、Cとシェルとの間の溝を橋渡し
(“bridge the gap between C and the shell”)するための言語が必要だったのです。
後にこれはPyton の主たるキャッチフレーズとなりました。

At this point, you might ask "why not port an existing language?" In my view, there
weren't a lot of suitable languages around at that time. I was familiar with Perl 3,
but it was even more tied to Unix than the Bourne shell. I also didn't like Perl's
syntax--my tastes in programming language syntax were strongly influenced by languages
like Algol 60, Pascal, Algol 68 (all of which I had learned early on), and last but
not least, ABC, on which I'd spent four years of my life. So, I decided to design a
language of my own which would borrow everything I liked from ABC while at the same
time fixing all its problems (as I perceived them).

この時点であなたは“なぜ既存の言語を移植しなかったのか”と疑問に思うかもしれません。
わたしの考えでは、その頃には suitable languages がそう多くは存在していなかったのです。
わたしは Perl 3に慣れ親しんでいましたが、Bourne シェルよりもさらに強くUnixに結びついた
ものでした。また、わたしはPerl の構文があまり好きではなかったのです。
わたしが好むところのプログラミング言語の構文とは Algol 60やPascal、Algol 68
(どの言語もそれ以前に学んでいたものです)といった言語やlast but not least, ABC, on
which I'd spent four years of my life.  に強く影響を受けたものでした。
ですからわたしは、自分自身の、
would borrow everything I liked from ABC while at the same time fixing all its problems 
ABCの好きな部分のすべてを受け継ぎながらもその問題点をすべて解消する
言語を設計しようと決心したのです(as I perceived them)。


The first problem I decided to fix was the name! As it happened, the ABC team had some
trouble picking a name for its language. The original name for the language, B, had to
be abandoned because of confusion with another language named B, that was older and
better known. In any case, B was meant as a working title only (the joke was that B
was the name of the variable containing the name of the language--hence the italics).
The team had a public contest to come up with a new name, but none of the submissions
made the cut, and in the end, the internal back up candidate prevailed. The name was
meant to convey the idea that the language made programming “as simple as ABC”, but
it never convinced me all that much.

最初に解決しようと考えた問題は名前でした!
As it happened, the ABC team had some trouble picking a name for its language.
ABCの元々の名前はBだったのですが、
すでに自分たちのものよりも古くからあってしかもよく知られている別の Bという名の言語が
あったのでその名前は諦めなければなりませんでした。
ABCというその名前は、プログラミングを“ABCと同じくらい単純にする”(as simple as ABC)
言語という考えを表したものだったのですが、
わたしにはとてもそうだとは思えませんでした。

So, rather than over-analyzing the naming problem, I decided to under-analyze it. I
picked the first thing that came to mind, which happened to be Monty Python's Flying
Circus, one of my favorite comedy troupes. The reference felt suitably irreverent for
what was essentially a “skunkworks project”. The word “Python” was also catchy, a
bit edgy, and at the same time, it fit in the tradition of naming languages after
famous people, like Pascal, Ada, and Eiffel. The Monty Python team may not be famous
for their advancement of science or technology, but they are certainly a geek favorite.
It also fit in with a tradition in the CWI Amoeba group to name programs after TV shows.

ですから、命名の問題をover-analyzingするよりむしろ under-analyze することを選択したのです。
わたしは最初に脳裏に浮かんできたことがらを取り上げてみました。それは、わたしが好きな
comedy troupes の一つであるモンティ・パイソンの空飛ぶサーカス (Monty Python's Flying
Circus) でした。
The reference felt suitably irreverent for what was essentially a “skunkworks project”.
“Python”という単語は注意を引くものでもあり、ちょっと edgyで、
そして同時にPascal や Ada、Eiffelなどのように有名な人物から言語の名前を付けるという
伝統に従ったものだったのです。
モンティ・パイソンチームは
their advancement of science or technology
しかし確実にギーク好みのものでした。
これはまた、CWI Amoeba グループのTV番組からプログラムの名前を付けるという
伝統にも沿ったものでした。

For many years I resisted attempts to associate the language with snakes. I finally
gave up when O'Reilly wanted to put a snake on the front of their first Python book
"Programming Python". It was an O'Reilly tradition to use animal pictures, and if it
had to be an animal, it might as well be a snake.

何年にも渡ってわたしはこの言語とヘビを連想させることに抵抗していたのですが、
O'Reilly が彼らの最初のPython本である　"Programming Python"　の表紙にヘビを使いたい
といってきたときについに観念したのです。
動物の絵を使うのはO'Reillyの伝統でしたし、
動物を使わなければならないのなら、結局はヘビにするしかなかったのです。

With the naming issue settled, I started working on Python in late December 1989, and
had a working version in the first months of 1990. I didn't keep notes, but I
remember vividly that the first piece of code I wrote for Python's implementation was
a simple LL(1) parser generator I called “pgen." This parser generator is still part
of the Python source distribution and probably the least changed of all the code. This
early version of Python was used by a number of people at CWI, mostly, but not
exclusively in the Amoeba group during 1990. Key developers besides myself were my
officemates, programmers Sjoerd Mullender (Sape's younger brother) and Jack Jansen
(who remained one of the lead developers of the Macintosh port for many years after I
left CWI).

名前に関する問題が解決して、1989年の12月の終わりにわたしはPythonの作業を始めました。
そして1990年の最初の数ヶ月でworking verison が得られました。
記録に残してはいませんが、“pgen”とわたしが呼んでいた LL(1) パーザジェネレーターの
Python による実装のために最初のコード片を書いたことを鮮明に思い出します。
そのパーザジェネレーターは今でもPython の source distribution の一部であり続けていて、
おそらくすべてのコードの中で最も変更されていないものです。
この初期バージョンのPython はCWIにいた多くの人たちによって使われていたのが
大部分でしたが、but not exclusively in the Amoeba group during 1990.
カギとなる開発者にはわたし自身と、わたしの officemate たちやプログラマーたち、
(Sapeの弟の) Sjoerd Mullender、そして
わたしがCWIを去ったあとも何年も Macintosh への移植をリードした人たちの一人である
Jack Jansen がいました。

On February 20, 1991, I first released Python to the world in the alt.sources
newsgroup (as 21 uuencoded parts that had to be joined together and uudecoded to form
a compressed tar file). This version was labeled 0.9.0, and released under a license
that was an almost verbatim copy of the MIT license used by the X11 project at the
time, substituting “Stichting Mathematisch Centrum”, CWI's parent organization, as
the responsible legal entity. So, like almost everything I've written, Python was
open source before the term was even invented by Eric Raymond and Bruce Perens in late
1997.

1991年の2月20日、わたしは最初のPython を世界に向けて alt.sources newsgroup にリリースしました。
(as 21 uuencoded parts that had to be joined together and uudecoded to form a compressed tar file).
21個の uuencode されてパーツになっていて、圧縮された状態の tarファイルにするには
それらをつなげた上で uudecode しなければなりませんでした
このバージョンは 0.9.0 とラベルがつけられ、その頃 X11 プロジェクトが使っていた 
MIT ライセンスのresponsible legal entity を CWIの親組織である
“Stichting Mathematisch Centrum”に置き換えたほぼ丸ごとMITライセンス
なライセンスのもとでリリースされました。
ですからわたしが書いたほぼすべてのものと同様に、Pythonは
オープンソースという言葉が Eric Raymond と Bruce Perens によって1997年に発明される
以前からオープンソースだったのです。

There was immediately a lot of feedback and with this encouragement I kept a steady
stream of releases coming for the next few years. I started to use CVS to track
changes and to allow easier sharing of coding responsibilities with Sjoerd and Jack
(Coincidentally, CVS was originally developed as a set of shell scripts by Dick Grune,
who was an early member of the ABC group). I wrote a FAQ, which was regularly posted
to some newsgroup, as was customary for FAQs in those days before the web, started a
mailing list, and in March 1993 the comp.lang.python newsgroup was created with my
encouragement but without my direct involvement. The newsgroup and mailing list were
joined via a bidirectional gateway that still exists, although it is now implemented
as a feature of mailman - the dominant open source mailing list manager, itself
written in Python.

即座にたくさんのフィードバックが返ってきました。
そしてその激励でわたしはそれから何年も安定したリリースを保ったのです。
変更を記録し、Sjoerd や Jack との　sharing of coding responsibilities を
容易にするために CVSを使い始めました
(Coincidentally, CVS was originally developed as a set of shell scripts by Dick Grune,
who was an early member of the ABC group)。
#偶然ですが、CVSは元々 ABCグループの初期メンバーであった Dick Grune によって
#シェルスクリプトの集合として開発されたものでした
わたしは FAQを書いて、web以前のその頃のFAQでよく行われていたように
それを定期的にいくつかのニューズグループに投稿するようにしました。
さらにメーリングリストを開設しました。
1993年の三月にはわたしの encouragement で comp.lang.python newsgroup が作成されましたが
わたしが直接それに関わることはありませんでした。
ニューズグループとメーリングリストは双方向ゲートウェイを通じて接続されていて
今でも存在していますが、現在ではPythonで記述されている
dominant open source mailing list manager の mailman の機能として実装されています。

In the summer of 1994, the newsgroup was buzzing with a thread titled “If Guido was
hit by a bus?” about the dependency of the growing Python community on my personal
contributions. This culminated in an invitation from Michael McLay for me to spend two
months as a guest researcher at NIST, the US National Institute for Standards and
Technology, formerly the National Bureau of Standards, in Gaithersburg, Maryland.
Michael had a number of “customers” at NIST who were interested in using Python for
a variety of standards-related projects and the budget for my stay there was motivated
by the need to help them improve their Python skills, as well as possibly improving
Python for their needs.

1994の夏、そのニューズグループはPython コミュニティの成長がわたしの個人的な貢献に依存
していることについて述べた “If Guido was hit by a bus?”(もし Guido がバスにはねられたら?)
というスレッドタイトルで溢れかえりました。それは Michael McLayがわたしを二ヶ月に渡って
NIST, the US National Institute for Standards and
Technology, formerly the National Bureau of Standards, in Gaithersburg, Maryland.
にguest researcher として招待したときに最高潮に達したのです。
Michael は NIST にPython を　variety of standards-related projects に使うことに興味を
持っていたたくさんの“顧客”(customers)を抱えていて、わたしがそこに滞在するための budget は
motivated by the need to help them improve their Python skills,
as well as possibly improving Python for their needs.

The first Python workshop was held while I was there in November 1994, with NIST
programmer Ken Manheimer providing important assistance and encouragement. Of the
approximately 20 attendees, about half are still active participants in the Python
community and a few have become major open source project leaders themselves (Jim
Fulton of Zope and Barry Warsaw of GNU mailman). With NIST's support I also gave a
keynote for about 400 people at the Usenix Little Languages conference in Santa Fe,
organized by Tom Christiansen, an open-minded Perl advocate who introduced me to Perl
creator Larry Wall and Tcl/Tk author John Ousterhout.

最初の Python ワークショップは 1994年の11月に開催されました。
with NIST programmer Ken Manheimer providing important assistance and encouragement.
Of the　approximately 20 attendees, 
about half are still active participants in the Python community 
and a few have become major open source project leaders themselves 
(Jim Fulton of Zope and Barry Warsaw of GNU mailman).
NISTのサポートで、わたしは open-minded な Perl advocate であり
わたしを Perl creator Larry Wall と Tcl/Tk の作者である John Ousterhout
に紹介してくれた Tom Christiansen が organizeした
Santa Fe で行われた Usenix Little Languages conference で 
400人を前にキーノートを行ったのです

ところどころ英文のままになっている部分はおいおい。

■_ Parrot 0.9.0

あ、修正されてるw 

/*
 * Microsoft provides two annotations mechanisms.  __declspec, which has been
 * around for a while, and Microsoft's standard source code annotation
 * language (SAL), introduced with Visual C++ 8.0.
 * See <http://msdn2.microsoft.com/en-us/library/ms235402(VS.80).aspx>,
 * <http://msdn2.microsoft.com/en-us/library/dabb5z75(VS.80).aspx>.
 */
#if defined(_MSC_VER) && (_MSC_VER >= 1400)
#  define PARROT_HAS_SAL 1
#  include <sal.h>
#else
#  define PARROT_HAS_SAL 0
#endif

これはこれでうれしいのだけど、 なんかMakefileも変わってて perl6.exe を作るにはどうするのやら。 

>nmake perl6

Microsoft(R) Program Maintenance Utility Version 7.10.3077
Copyright (C) Microsoft Corporation.  All rights reserved.

        C:\perl510\bin\perl.exe -e "chdir shift @ARGV;system 'nmake', '-nologo',
 @ARGV; exit $? >> 8;" compilers\pct
        C:\perl510\bin\perl.exe -e "chdir shift @ARGV;system 'nmake', '-nologo',
 @ARGV; exit $? >> 8;" compilers\pge
        C:\perl510\bin\perl.exe -e "chdir shift @ARGV;system 'nmake', '-nologo',
 @ARGV; exit $? >> 8;" compilers\tge
        C:\perl510\bin\perl.exe -e "chdir shift @ARGV;system 'nmake', '-nologo',
 @ARGV; exit $? >> 8;" compilers\nqp
        C:\perl510\bin\perl.exe -e "chdir shift @ARGV;system 'nmake', '-nologo',
 @ARGV; exit $? >> 8;" compilers\json
        C:\perl510\bin\perl.exe -e "chdir shift @ARGV;system 'nmake', '-nologo',
 @ARGV; exit $? >> 8;" languages\perl6 perl6.exe
        C:\work\src\parrot-0.9.0\pbc_to_exe.exe perl6.pbc
cl -Foperl6.obj -I"C:/work/src/parrot-0.9.0\include" -nologo -GF -W4 -MD -Zi -DNDEBUG -DWIN32 -D_CONSOLE
  -DNO_STRICT -DUSE_SITECUSTOMIZE -DPRIVLIB_LAST_IN_INC  -DHASATTRIBUTE_DEPRECATED -wd4101
  -DHASATTRIBUTE_NORETURN -wd4101 -I c:\usr\local\include\icu -c perl6.c
perl6.c
Compiled: perl6.obj
link -out:perl6.exe "perl6.obj" C:/work/src/parrot-0.9.0\src\parrot_config.obj
libparrot.lib   -nologo -nodefaultlib -debug     -machine:x86 kernel32.lib ws2_32.lib msvcrt.lib
  oldnames.lib gmp.lib readline.lib c:\usr\local\lib\icudt.lib c:\usr\local\lib\icuuc.lib
LINK : fatal error LNK1104: コンパイラは、ファイル 'libparrot.lib' を開くことができません。
linking failed
current instr.: 'link_file' pc 837 (pbc_to_exe.pir:427)
called from Sub 'main' pc 134 (pbc_to_exe.pir:51)
NMAKE : fatal error U1077: 'C:\work\src\parrot-0.9.0\pbc_to_exe.exe' : リターンコード '0x1'
Stop.
NMAKE : fatal error U1077: 'C:\perl510\bin\perl.exe' : リターン コード '0x2'
Stop.


Journal of chromatic (983)
Wednesday January 21, 2009
12:46 PM
Parrot 0.9.0 "From Outer Space" Released
[ #38323 ]

    Greetings, my friend. We are all interested in the future, for that is where you 
    and I are going to spend the rest of our lives.

    Remember, my friend, future events such as these will affect you in the future.

    You are interested in the unknown... the mysterious. The unexplainable. That is 
    why you are here. My friend, we cannot keep this a secret any longer. Let us punish 
    the guilty. Let us reward the innocent. My friend, can your heart stand the shocking 
    facts of ....

"Plan 9 From Outer Space"

(ry

Parrot 0.9.0 News:

(ry

      + PGE
        - add "skipkey" option to PGE::OPTable
        - allow spaces before modifiers in regexes
        - add '(' ~ ')' goal matching syntax
        - skip creating a class/grammar if it already exists
    - Languages
      + Rakudo
        - improved error mesages in multi dispatch
        - implemented clone method for all objects
        - implemented MAIN sub
        - Unicode versions of infix hyper operators
        - refactored IO.readline
        - basic support for Inf and NaN
        - list and array slices with whatever star
        - hash slices
        - implemented last and redo
        - pointy blocks as terms
        - refactored variable and parameter passing
        - improved assignment semantics
        - improved parsing of type names and subs
        - mostly implemented parametric roles
        - separate types for blocks, subs and methods
        - basic support for submethods
        - implemented Junction autothreading of user code (not builtins yet)
        - eval supports :lang attribute
        - proto makes other subs in scope multis, including in role composition

(ry
    - Miscellaneous
      + Infrastructure
        - 'make smoke' now generates Smolder reports sent to
          http://smolder.plusthree.com/app/public_projects/smoke_reports/8
      + Improved const and null correctness for C function parameters
      + Sped up STRING manipulation (append, chop), improving PGE about 30%
      + BOOK
        - Added sections about Classes, OO programming, and methods.
        - Added information about Annotations, Exceptions, and Handlers
      + STM
        - Removed non-functional STM subsystem

0.8.2 からちょっとだけバージョンが飛んで 0.9 になっただけのことはある? あれ、CPANには chromatic / parrot-0.9.0.1 - search.cpan.org なんてのがあるぞ。

■_ Cは今でも支配的な言語なのか?

Computing Now | January 2009 | Theme: Software's 25th Anniversary C dominated 2008's open-source project nursery • The Register

あとで(ry

あとで(ry その2。 Sometimes the Old Ways Are Best by Brian Kernighan : programming 経由で Computing Now | January 2009 | Theme: Software's 25th Anniversary カーニハン大先生のお書きになった記事なれば。

2009年01月21日

■_

・図書館から「C言語を256倍～」ともう一冊借りてきました
日曜日に予約したのが届いたとの連絡を受け、閉館ぎりぎりの時刻で受け取り成功。 さて読もう。

■_ 高速化

Message 80092 - Python tracker 

Message 80092 - Python tracker

The work to rewrite the IO stack in C will solve this problem as it will
probably solve most performance-related IO problems in py3k.

Amaury and I have been progressing a lot, the rewrite is now a real
branch in SVN at branches/io-c/. On this very issue, it is only 30%
slower than 2.x, which is quite good given the layered nature of the IO
stack and the fact that text IO does a lot more than in 2.x (it
translates newlines and encodes the text).

(actually, if I add an explicit .encode('utf8') call to the 2.x version
of the script, it becomes slower than our io-c rewrite)

3.0.1で適用? どう変更したら高速化されたのかあとでソース読んでみやう。

■_ らいせんす

2009/1 (b)
(23:49)
LGPL 話のづつき。LGPL は基本的には C++ には向いてないのだが、 Lisp コミュニティでは、
Lispの「ライブラリ」の定義にあわせて LGPL を修正した LLGPL というのがあった (以前 
Kenny から聞いたことがあったが忘れていた、今回 LWN のコメントを見て思い出したのである)。 
さらに、Ada コミュニティでは Adaのライブラリに使える GNAT拡張 LGPLというのがあるそうな。 
このように、LGPL ではライブラリやリンクの定義がめちゃくちゃ C言語依存なために、 違う言
語では、わざわざ言語ごとに“LGPL 相当”のライセンスが作られている。 しかし、これにとも
なう手間と混乱よりもライブラリ本体のほうがホントーに価値があるのだろうか?? なんともわ
からん。ほんとに。

なるほど、Adaには総称関数があるからその実現のためにライブラリコードが ユーザープログラム本体に(STLと同じように) 潜り込んでくる(うまい表現でないな)と。

Preamble to the Gnu Lesser General Public License

■_ 本日のム

C++0x 5 
11 デフォルトの名無しさん [sage] Date:2009/01/20(火) 23:33:15  ID: Be:
    【あたらしいきのう】

    ・こんせぷと！
    　テンプレートひきすうをせいげんするぞ！
    　constのつけわすれでエラーメッセージが1000ぎょうもでなくなる！
    　でもむずかしすぎてだれもじっそうできてないよ！　

    ・らむだしき！
    　みんながまってたインラインかんすうオブジェクト！
    　STLがすっごくべんりになるよ！
    　でもこうぶんがすっごくグロいよ！

    ・うへんちさんしょう！
    　いちじオブジェクトをさすためのさんしょうだ！
    　いらないおぶじぇくとをぶっこわしてポインタをごうだつする！
    　それがむーぶせまんてぃくす！かこいい！

突然 alloca で盛り上がってたw 

Ｃ言語なら俺に聞け（入門篇） Part 42
776 デフォルトの名無しさん [sage] Date:2009/01/21(水) 18:02:30  ID: Be:
    C FAQ の 7.32 に
    「戻り値を直接別の関数に渡す場合に（略）、例えば
    fgets(alloca(100), 100, stdin)のような式で問題を招く」
    とありますが、これはなぜでしょう？

    alloca()の解放は fgetsを呼ぶ関数の終了時なので
    問題ないようにみえますが 

777 デフォルトの名無しさん [sage] Date:2009/01/21(水) 18:04:30  ID: Be:
    allocaの失敗したときを考えろよクズ 

779 デフォルトの名無しさん [sage] Date:2009/01/21(水) 18:25:35  ID: Be:
    >>777 そんなのは別の関数関係ないだろ 

781 デフォルトの名無しさん [sage] Date:2009/01/21(水) 18:37:35  ID: Be:
    >>779
    分けてちゃんと返り値ちぇっくしたら起こらない問題が起こるだろーが、理解したか？このカス 

782 デフォルトの名無しさん [sage] Date:2009/01/21(水) 18:45:05  ID: Be:
    >>781
    だからそんなのは本質じゃないって
    お前は回答側に回るの半年早い 

783 デフォルトの名無しさん [sage] Date:2009/01/21(水) 18:45:26  ID: Be:
    >>776
    スタック方式に話を限定するけど
    alloca()で確保された領域をいつ開放するべきかを決定する要素が「関数を抜けるとき」しかない
    だからその他のローカル変数同様に確保する領域をスタック上に積んで
    （よーするにローカル変数な配列のサイズをあとで決めるということだが）
    それへのポインタを返すことになるわけだが、
    問題はalloca()から制御が帰ってくるまで「現在のスタックの大きさ」が確定しないことにある
    その状態で別の関数を呼び出す準備をはじめたら、
    つまりalloca()から帰る前のスタックに値を積みはじめたらきっとひどいことになる 

784 デフォルトの名無しさん [sage] Date:2009/01/21(水) 18:46:36  ID: Be:
    fgetsを呼ぶとき、よくある例だとコールスタックはこうなる（あくまで一例だけど）。
    3番目の引数
    2番目の引数
    1番目の引数
    fgetsからreturnする先のアドレス

    ところが、allocaが混ざるとこうなってしまう可能性が高い。
    3番目の引数 (stdin)
    2番目の引数 (100)
    allocaで確保した100バイト
    1番目の引数 (allocaの戻り値)
    fgetsからreturnする先のアドレス
    こうなると、fgetsの中で、2-3番目の引数と思ってアクセスした場所が
    実はallocaの領域だったという事態になってしまっている。
    だからallocaを引数の中で使うなというわけ。 

786 デフォルトの名無しさん [sage] Date:2009/01/21(水) 18:54:39  ID: Be:
    >alloca() 関数は、割り付けた領域の始まりを指すポインタを返す。
    >割り付けによってスタックオーバーフローが起った場合の プログ
    >ラムの動作は定義されていない。
    http://www.linux.or.jp/JM/html/LDP_man-pages/man3/alloca.3.html

    NULLなどの特殊な値がかえってくるわけではなく、成功失敗は
    プログラムからは決定できないので、呼び出すのは一種のバクチ

    >多くのシステムにおいて、関数コールの引き数のリスト内では
    >alloca() が使えない。
    >これは、 alloca() によって予約されるスタック領域が、
    > 関数引き数に使われるスタック領域の中に現れてしまうためである。
    >>784の言う通り
    スタックポインタを操作する危険な関数で、仕様も素性もわからない
    関数を標準ライブラリにあるからという理由で、気軽に「合成」して
    使うと思わぬ落とし穴に嵌る可能性があるというお話 

787 776 [sage] Date:2009/01/21(水) 19:23:44  ID: Be:
    回答ありがとうございます。

    >>784
    なるほど、関数のパラメタをスタックに積んでいるところを妨害する
    可能性があるわけですね。非常に納得しました。
    でもそういうアーキテクチャの場合、alloca をサポートしちゃいけないような気も・・

    >>783
    スタックフレームのサイズが静的に決まらないので、いろいろ実装が難しいですね。
    とくに、関数コールがスタックフレームサイズを増やすアーテキチャの場合は
    関数の外側で使わないとまずいですし。

    >>786
    確かに、不定値が返るって仕様は厳しい。
    それでも GNUのstrdupa() みたいにわざわざ alloca版が作られているのは、
    リスクもあるけど便利なんでしょうね

788 デフォルトの名無しさん [sage] Date:2009/01/21(水) 19:28:39  ID: Be:
    ようするに可変長配列万歳（違 

791 デフォルトの名無しさん [sage] Date:2009/01/21(水) 19:56:27  ID: Be:
    というかちゃんと構造化してるなら
    allocaなんかつかわなくたって
    明示的にmalloc/freeするのは
    そんな難しいことじゃないんだけどな 

792 デフォルトの名無しさん [sage] Date:2009/01/21(水) 19:58:47  ID: Be:
    alloca は速さも重要だと思うが。 

793 デフォルトの名無しさん [sage] Date:2009/01/21(水) 20:04:21  ID: Be:
    >>792
    はぁ？ 

794 デフォルトの名無しさん [sage] Date:2009/01/21(水) 20:08:25  ID: Be:
    関数内で使うちょっとした領域を malloc で確保するなんて無駄じゃん。 

795 デフォルトの名無しさん [sage] Date:2009/01/21(水) 20:25:49  ID: Be:
    >>794
    お前は何を言っているんだ
    具体的に何がどう無駄だと思っているんだ 

797 デフォルトの名無しさん [sage] Date:2009/01/21(水) 20:30:07  ID: Be:
    >>795
    管理の手間の無駄。
    処理時間の無駄。 

802 デフォルトの名無しさん [sage] Date:2009/01/21(水) 20:57:44  ID: Be:
    >>795
    ちょっと実装して計ってみた
    処理時間30倍ﾜﾗﾀ
    小さくて多く呼ばれる関数だったらバカにできないせ 

803 デフォルトの名無しさん [sage] Date:2009/01/21(水) 20:58:08  ID: Be:
    >>797
    ちょっとした領域というのが本当にちょっとしたものなら、
    ちょっとした配列をあらかじめ確保しておくのが管理も処理も効率的である。
    ちょっとしたというには大きい領域が頻繁に必要になるなら、
    最初から大きい配列を確保しておけばよい（どうせスタックに積まれるのだから）。
    常に使われるのはちょっとした領域だけれど、
    時折来る大きな領域にも対応したいなら、
    普段はあらかじめ確保したちょっとした配列を使い、
    大きな領域が来たときだけ大きく確保するほうがきっと効率的である。
    もし処理そのものが滅多に呼ばれることがないなら、
    処理時間に関する論議はほとんど無意味に近い。

    いずれにせよallocaは標準外であり、それを使うための細かい話も環境依存である。 

806 デフォルトの名無しさん [sage] Date:2009/01/21(水) 21:01:09  ID: Be:
    alloca がどれだけ簡単な処理か分かってて言ってんのかね。 

807 デフォルトの名無しさん [sage] Date:2009/01/21(水) 21:02:24  ID: Be:
    それこそ環境依存だから一概には言えないけど
    スタックに積むだけなら自動変数と同等=タダ同然というのは間違ってる？ 

808 デフォルトの名無しさん [sage] Date:2009/01/21(水) 21:02:49  ID: Be:
    別に間違ってない 

809 デフォルトの名無しさん [sage] Date:2009/01/21(水) 21:05:03  ID: Be:
    微妙に今の話題と関係ないんだけどC99で出来るようになった可変長配列は
    どっち系なの？malloc? 

810 デフォルトの名無しさん [sage] Date:2009/01/21(水) 21:07:45  ID: Be:
    >>809
    alloca相当の実装だと期待していい。 

811 デフォルトの名無しさん [sage] Date:2009/01/21(水) 21:09:10  ID: Be:
    allocaはみんななんて読んでる？ 

812 デフォルトの名無しさん [sage] Date:2009/01/21(水) 21:09:37  ID: Be:
    あろっか 

813 デフォルトの名無しさん [sage] Date:2009/01/21(水) 21:10:27  ID: Be:
    オールッカ 

814 デフォルトの名無しさん [sage] Date:2009/01/21(水) 21:12:21  ID: Be:
    あろっか

むかーし DOS用のコンパイラ(Turbo-Cだったかなあ?)で、GNU のツール移植するときに alloca を書いたことがあるんだけど(コンパイラのライブラリには _alloca 的なものも 含めて入ってなかった)、簡単そうに見えて結構面倒だったけどねえ。 って俺の実力不足? ○|￣|＿ あと可変長配列は、 めもがきの中の人が問題点を指摘していたはず。 

【Perl,PHP】LLバトルロワイヤル3【Ruby,Python】
541 デフォルトの名無しさん [] Date:2009/01/20(火) 19:33:16  ID: Be:
    ところでVBってLLに分類される？
    PythonVCLこそ真のVB6の後継者になりえると思うんだ 

542 デフォルトの名無しさん [sage] Date:2009/01/20(火) 19:57:24  ID: Be:
    自分はPython使ってますが
    それそのもので開発するのではなく
    インタプリタであることを生かして
    ちょっとapiを試すのに重宝しています。
    こういう使い方してる人結構いると思います。
    PHPみたいにプロジェクトの
    主要開発言語に選ばれることは少ないので
    普及していないと錯覚されていますが
    自分が知る限りではPythonユーザー相当数いますよ。 

543 デフォルトの名無しさん [sage] Date:2009/01/20(火) 20:11:07  ID: Be:
    //Rhino犀強伝説

    (function(cmdlArgs,　index,　argsLength)　{
    　
    　if　(index　<　argsLength)　{
    　　
    　　java.lang.System.out.print(readFile(cmdlArgs[index]));
    　　
    　　arguments.callee(cmdlArgs,　index　+　1,　argsLength);
    　}
    　
    })(arguments,　0,　arguments.length);

544 デフォルトの名無しさん [sage] Date:2009/01/20(火) 22:29:37  ID: Be:
    >>515 >>541
    P4DっていうPythonのDelphiバインディングに
    Python用のVCLの拡張ライブラリがあったはず。 

545 デフォルトの名無しさん [sage] Date:2009/01/20(火) 23:28:29  ID: Be:
    >>539
    おまえいつも天然って言われるだろ 

546 デフォルトの名無しさん [sage] Date:2009/01/21(水) 01:44:15  ID: Be:
    http://en.wikipedia.org/wiki/Lightweight_languages
    LLって間違って使ってるの日本だけだからな。海外では高速な言語という意味でC言語とかを指す。
    辺境のバズワードもいいとこだし、LLが云々語ってる奴って大体DQNばっかだよな。 

547 デフォルトの名無しさん [sage] Date:2009/01/21(水) 01:57:58  ID: Be:
    そういうスレだから仕方ない 

548 デフォルトの名無しさん [] Date:2009/01/21(水) 02:20:22  ID: Be:
    世界基準に合わせるか日本基準に合わせるかで迷うよね。
    世界基準ならPython、日本基準ならRuby。 

549 デフォルトの名無しさん [sage] Date:2009/01/21(水) 03:04:55  ID: Be:
    仕事の案件にもよるんじゃね？
    世界基準って言ったとこで国内にしか目を向けてない企業のとこなんて作成する
    言語なんてなんでも良いわけで、理由はどうせメンテや改修も国内の企業がするんだし。

    国外との取引のある(国外企業がメンテや改修をする事ありそうな)企業に対しての
    納品物は作成する前の打合わせが半端ない(言語を何にするか等)のが現実。 

550 デフォルトの名無しさん [] Date:2009/01/21(水) 04:03:25  ID: Be:
    >>546
    高速なんてどこにも書いてないじゃないか。 

551 デフォルトの名無しさん [sage] Date:2009/01/21(水) 06:05:50  ID: Be:
    今から編集します 

552 デフォルトの名無しさん [sage] Date:2009/01/21(水) 08:18:00  ID: Be:
    >>546
    > http://en.wikipedia.org/wiki/Lightweight_languages
    > LLって間違って使ってるの日本だけだからな。海外では高速な言語という意味でC言語とかを指す。
    > 辺境のバズワードもいいとこだし、LLが云々語ってる奴って大体DQNばっかだよな。

    まじか。Matzとか堂々とLLとか言ってないか？ 

553 デフォルトの名無しさん [sage] Date:2009/01/21(水) 08:58:56  ID: Be:
    >>552
    それはWikipediaを書いた奴が偏ってる。
    向こうの「lang.lightweight」メイリングリストでは「重い」言語の話題も山のようにある。
    ttp://osdir.com/ml/lang.lightweight/2005-04/threads.html 

554 デフォルトの名無しさん [sage] Date:2009/01/21(水) 09:10:34  ID: Be:
    Lightweight Languageは英語圏のScripting languagesを指す和製英語である
    とするのが妥当だと思います。

    軽量プログラミング言語
    http://ja.wikipedia.org/wiki/%E8%BB%BD%E9%87%8F%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E8%A8%80%E8%AA%9E 

555 デフォルトの名無しさん [sage] Date:2009/01/21(水) 10:11:59  ID: Be:
    こうしてまた嘘つきが勝つのでした 

556 デフォルトの名無しさん [sage] Date:2009/01/21(水) 10:52:09  ID: Be:
    >>546
    それ見た感じ組み込み用の言語、の段階で止まっているね。
    日本の場合>>554で定着したんで、いろいろ使われて今に至っている印象。
    wikipediaだけ見るに海外だと言葉そのものが全然使われていない印象だなー。

557 デフォルトの名無しさん [sage] Date:2009/01/21(水) 12:10:00  ID: Be:
    外人的には、昔からあるただの遅いスクリプト言語に最近Lightweightとか真逆の名前を
    付けてマーケティング活動頑張ってる黄色い猿がいる、くらいの印象だからな。
    日本って自己主張・利益のためにすぐ論理曲げちゃうから、グローバルスタンダードとか
    ずれてガラパゴスになるんだよな。 

558 デフォルトの名無しさん [sage] Date:2009/01/21(水) 12:31:44  ID: Be:
    池田さんはブログの更新がんばれば？ 

559 デフォルトの名無しさん [sage] Date:2009/01/21(水) 14:18:05  ID: Be:
    なんで適当なこと言ってまで日本人を叩きたいんだろうね 

560 デフォルトの名無しさん [sage] Date:2009/01/21(水) 15:55:04  ID: Be:
    まあ、ここ最近急に巷で"LL"とか使いはじめてから、
    どことなくうさんくささを感じてたのは俺だけじゃないはず。
    なんか、言語センスといい発想といい
    「『かっこいい外人が使ってそう』っていう日本人が使ってます」
    的なんだよね。何故かモサさを感じさせるところか、モロ日本人的。 

561 デフォルトの名無しさん [sage] Date:2009/01/21(水) 16:32:14  ID: Be:
    おおむねWikiPedia(jp)の内容で合ってるという感じか？

    >>557
    > 日本って自己主張・利益のためにすぐ論理曲げちゃうから、グローバルスタンダードとか
    > ずれてガラパゴスになるんだよな。

    外来語の使い方について適当すぐるというのは確かにあるね。 

562 デフォルトの名無しさん [sage] Date:2009/01/21(水) 16:42:36  ID: Be:
    ttp://ja.uncyclopedia.info/wiki/%E3%83%91%E3%83%BC%E3%83%AB%E3%81%AE%E3%82%88%E3%81%86%E3%81%AA%E3%82%82%E3%81%AE
    これで十分だろ 

(｀

たしか北米の東海岸で二回だか三回ぐらいしか開催されなかったイベントで LLって名前をつけたんじゃなかったっけ? 適当に名前をつけたのでかっちりした定義はないとか言うのを読んだ覚えが。 

初心者のためのプログラミング言語ガイド Part13 
54 デフォルトの名無しさん [e] Date:2009/01/20(火) 20:58:21  ID: Be:
    プログラムの事が全くわからない大学生です。
    将来のことを考え、プログラミング言語を春休みから勉強していきたいと思ったのですが、
    これから先、１番汎用性のありそうな言語を教えて下さい。 

56 デフォルトの名無しさん [sage] Date:2009/01/20(火) 21:47:59  ID: Be:
    >>54
    　C++ 

57 デフォルトの名無しさん [sage] Date:2009/01/20(火) 21:52:29  ID: Be:
    C+ 

58 デフォルトの名無しさん [sage] Date:2009/01/20(火) 22:28:58  ID: Be:
    C 

59 デフォルトの名無しさん [sage] Date:2009/01/20(火) 22:33:10  ID: Be:
    C- 

60 デフォルトの名無しさん [] Date:2009/01/21(水) 02:51:26  ID: Be:
    Javascript 

61 デフォルトの名無しさん [sage] Date:2009/01/21(水) 08:24:25  ID: Be:
    プログラムの事が全くわからない大学生が将来のことを考えプログラミング言語を
    勉強していきたい、というのがまずわからないw 

62 デフォルトの名無しさん [e] Date:2009/01/21(水) 09:04:43  ID: Be:
    >>61
    確かに抽象的すぎたかもしれません。
    要するに理系としてプログラミングができた方が、
    例えば就職などでも便利だと思うので、勉強したいと思ったんです。
    しかし、何しろ言語がいっぱいあるため、どの言語を勉強していいか分かりません。
    なので１番将来的にも汎用性のある言語が何かを教えてもらえたらありがたいなと… 

63 デフォルトの名無しさん [sage] Date:2009/01/21(水) 10:11:39  ID: Be:
    どれか一つだけ勉強しようという、最短距離を求める精神に問題があると思うなぁ。
    てか、>>54から>>62まで12時間あったわけだけど、この間にちょいと徹夜して
    最初にもらった回答であるC++を勉強していれば、現時点で既にちょっとは読み書きできてたね。

    12時間も経ってるのに、まださっきと同じ未経験者であるというその「腰の重さ」を何とかした上で、
    CとかJavaとか、Perl、Python、このあたりは「全部」春休み中に読み書きできるくらいには
    なっといたほうが。 

65 デフォルトの名無しさん [e] Date:2009/01/21(水) 13:23:34  ID: Be:
    >>63
    耳が痛いですｗ自分は全ての物事においてそういう傾向があるので…
    他科目との兼ねあいもあるのでそこまでは厳しいでしょうが、
    とりあえずC(++)から少しずつやっていきたいと思います。
    あと｢腰の重さ｣に関しては、来週からテスト期間なんで勘弁して下さいｗ 

66 61 [sage] Date:2009/01/21(水) 16:39:11  ID: Be:
    俺が言いたかったのは、コンピュータに興味ない人がプログラミングを勉強することが
    より金持ちになる（就職のためというのはそういうことだよね？）ことにつながるとは
    思えないってことなんだけど、偏見だろうか？ 

67 デフォルトの名無しさん [sage] Date:2009/01/21(水) 17:45:13  ID: Be:
    そんじょそこらのプログラミングレベルというのは
    就職では全くアピールポイントにならないんだよね
    そもそも大抵の企業がシステム構築は外注しているので
    自社にプログラミングができる人材を欲していないし

    偽装請負や派遣は頭数勝負でずぶの素人を売れる人材に
    仕立て上げるのに十分な教育体制を備えているので
    （そうでなくても経歴を偽装するので）大学で焦って独学する意味がない

    プログラミングできる人材を欲している技術系企業の多くは規模が小さく
    社内に十分な教育体制を持たないので
    とことんハイレベルで実績のある人材じゃないと採用できない

    以上、本人が語る失敗体験談でした 

68 デフォルトの名無しさん [sage] Date:2009/01/21(水) 18:48:28  ID: Be:
    >>65
    以上の意見を取り入れて、
    あなたのキーワード「汎用性」はこの際取り下げて、
    Ocamlを勉強することを勧めます。 

69 デフォルトの名無しさん [sage] Date:2009/01/21(水) 19:16:30  ID: Be:
    初心者のとっつきやすさを考えると、フレームワークの仕様が小さく、
    制限がきついほうがいいよ。
    Silverlight2 + C#とかおすすめ。
    無料で優秀な開発環境手に入るし、慣れてきたらすぐにWPFに移行できる。

    Adobe AIRでECMAScript(ActionScriptっていうのかこれも？)
    なんかもいいかも。無料でやろうとすると、環境構築ちょっと面倒だけど。 

70 デフォルトの名無しさん [sage] Date:2009/01/21(水) 19:23:25  ID: Be:
    それだったらまだOCaml勧めるわ。

まあ耳に痛いに w つけてごまかしちゃあダメだな。

■_ The History of Python

なんか2回分来てた～ 

The History of Python: A Brief Timeline of Python
A Brief Timeline of Python

The development of Python occurred at a time when many other dynamic (and open-source) 
programming languages such as Tcl, Perl, and (much later) Ruby were also being 
actively developed and gaining popularity. To help put Python in its proper historical 
perspective, the following list shows the release history of Python. The earliest 
dates are approximate as I didn't consistently record all events:

Python の開発は他の多くの動的(かつオープンソースの)プログラミング言語である
TclやPerl、(だいぶ遅れて)Ruby が活発に開発が進められるようになり
広く知られるようになっていった時期に始まりました。
To help put Python in its proper historical perspective,
以下のようにPythonのリリース履歴をリストにしました。
最初期の日付はわたしがすべてのイベントをきちんと記録してはいなかったために
大まかなものになっています。

リリース日          バージョン
1989年12月          実装開始
1990年              CWIでの内部リリース
1991年2月20日       0.9.0 (released to alt.sources)
1991年2月           0.9.1
1991年8月           0.9.2
1991年12月24日      0.9.4
1992年1月2日        0.9.5 (Macintosh のみ)
1992年4月6日        0.9.6
1992年のどこか      0.9.7beta
1993年1月9日        0.9.8
1993年7月29日       0.9.9
1994年1月26日       1.0.0
1994年2月15日       1.0.2
1994年5月4日        1.0.3
1994年7月14日       1.0.4
1994年10月11日      1.1
1994年11月10日      1.1.1
1995年4月13日       1.2
1995年10月13日      1.3
1995年10月25日      1.4
1998年1月3日        1.5
1998年10月31日      1.5.1
1999年4月13日       1.5.2
2000年9月5日        1.6
2000年10月16日      2.0
2001年4月17日       2.1
2001年12月21日      2.2
2003年7月29日       2.3
2004年11月30日      2.4
2006年9月16日       2.5
2008年10月1日       2.6
2008年12月3日       3.0

I've added hyperlinks to the releases that are still being advertised on python.org at 
this time. Note that many releases were followed by several micro-releases, e.g. 2.0.1; 
I haven't bothered to include these in the table as otherwise it would become too long. 
Source tarball of very old releases are also still accessible, here: 
http://www.python.org/ftp/python/src/. Various ancient binary releases and other 
historical artefacts can still be found by going one level up from there.

現時点において python.org で今でも advertise されているリリースにはハイパーリンクを
追加しています(訳注: 原文の話)。
多くのリリースには、それぞれ 2.0.1 のようなマイクロリリースが続いていることに
注意してください。そういったものもこのリストに含めることはわたしにとっては
苦痛ではありませんがリストが長くなりすぎるのでやっていません。
非常に古いリリースの tar玉は今でもアクセス可能な状態で
http://www.python.org/ftp/python/src/ に置かれています。
古代の各種のバイナリリリースやその他の historical artefacts は
先ほどのディレクトリから一つレベルを上がった所を起点に見つけることができるでしょう。


Posted by Guido van Rossum at 2:05 PM

1.3 あたりでいじったような記憶があるんだよなあ。 この次のエントリである The History of Python: Personal History - part 1, CWI は、明日以降に。

■_ タイトルだけではなかったような



Floating Log 21.1.2009
ときどきの雑記帖で知ったが工学社から「はじめてのPython3」が出るそうだ。 オライリーから
は「初めてのPython 第3版」も2月に出るという。

ところで「はじめてのPython」は名前が紛らわしいと叩かれるが、あれは工学社が「はじめての」
でシリーズ化している中の一冊として著者にはどうしようもなかったはずで、あまりに責められ
ることに同情を禁じ得ない。

はじめての Python - odz buffer あたりで odzさんも指摘していますが、タイトルをおいといても、 内容も事実誤認が少なからずあったからという面が多分にあると思います＞著者叩き 自分は、PythonのUnicodeを扱うときの内部コードはUTF-8 とかいう記述 (記憶で書いているのでそのままではありません)を見てひっくり返った記憶があります。 他にもあったかもしれないけど忘れました。

■_

sumimさんが久しぶりに書いてる～ あ、みねこあさんもプログラムネタだ。

一つ前へ 2009年1月(中旬)
一つ後へ 2009年2月(上旬)

ホームへ

Copyright (C) 2009 KIMURA Koichi (木村浩一)
この文書の無断転載はご遠慮ください(リンクはご自由にどうぞ)。

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