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

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

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

ホームへ

2010年09月30日

■_

・今月の皇帝陛下
エジプト脱出。
YOUNGKING OURS (ヤングキングアワーズ) 2010年 11月号 [雑誌]

■_

つーか、これにほとんど書かれちゃってるわけで。


O'Reilly Village/オラの村 - 『プログラミングF#』著者が明かすF#を使いこなすとっておきの秘訣!

『プログラミングF#』の著者であり、またF#開発チームのメンバーであったクリス・スミスさん
をお迎えして、秋葉原の書泉ブックタワーで9月22日にトークショーが開かれました。
(略)



Q: 関数型言語の利点は何でしょうか。

A: 無数にあります。関数型言語の一番はっきりとした利点は、並列プログラミングにあるでし
ょう。不変型のデータに注目すれば、並列プログラム、並行プログラムを簡単に行えるようにな
ります。しかし私の意見では、関数型言語とF#を学ぶ一番大きな利点は、どのようにプログラミ
ングにアプローチするかということを見直すことができる点です。C++やJava、C#、Visual 
Basicでは問題を同じ方法で解決します。しかし、関数型言語はそれらとは異なる視点をプログ
ラマに要求します。また、F#はハイブリッドなプログラミング言語であるので、関数型と命令型
の両方のことができるのです。プログラマは一番うまくいく解決方法をどれでも自由に選べるの
です。

Q: 関数型言語は習得が難しいと言われていますが、よいアドバイスはありますか?

A: F#やほかの関数型言語を学ぶのに実に100%ベストなアドバイスがあります。それは、思い切
って間違いをすることです。新しい言語を学ぼうとするときによく直面する問題として、人はす
ぐに物事を「正しく」「完璧に」しようとするのです。けれども人には経験し、学び、成長する
余裕が必要です。私の本を読むと、関数型プログラミングについてのすべてが学べるでしょう。
しかし関数型言語を自分のものにして、関数型スタイルのプログラムの書き方を理解するには、
経験が必要です。そして、それを達成する唯一の方法は、一歩踏み出して、コードを書き始める
ことです。

(略)

Q: F#プログラマへとっておきのアドバイスがあれば教えてください。

A: 本当に役に立つ機能が3つあります。
1つ目はF#のインタラクティブウィンドウです。これはREPLで、対話的にコードを入力し、その
結果を確かめられます。このツールはあなたの生産性に素晴らしい恩恵をもたらします。という
のも、ビルドしてアプリケーションを実行してデバッガを立ち上げなくても、コードをすぐにテ
ストできるからです。
2つ目はF#スクリプトファイルです。F#コードを書いて、.FSXの拡張子を付けると、Windowsシェ
ル内からコードを実行できます。これは、タスク自動化用のスクリプトを書くのにすごく適して
います。たとえば私が最初この本を書いていたとき、カレントフォルダ中のword文章ファイルそ
れぞれを印刷するようなF#スクリプトを用意していました。なので、それぞれのドキュメントを
一々開くことなく、本全体を印刷することができました。そのスクリプトの例は、この本の10章
に載っています。
3つ目は、F#のPowerPackをダウンロードするとFSLexとFSYaccが使えます。これは独自のプログ
ラミング言語を作る際にレキサ(字句解析器)とパーサ(構文解析器)を素早く生成する手助けをし
てくれるツールです。XMLは使いたくないけれども、構造化データを扱いたいときに、この2つの
ツールはとても役に立ちます。ただし、この2つは使いこなすのが難しいことに注意してくださ
い。

Q: どうすればF#ニンジャになれるでしょうか?
A: 訓練、訓練、訓練です。レベル9のF#忍者になるためには、関数型プログラミングの禅を習得
しなければなりません。つまり、どんなソリューションでも関数型スタイルに再構成する方法を
理解することです。それをマスターした後は、命令型、オブジェクト指向、関数型をミックスし
て正確かつエレガントなコードを書くようにすることで「忍者」のステータスを手に入れられま
す。
© 2010 O'Reilly Japan, Inc. All rights reserved.

訓練、訓練、訓練のところは確か Practice, Practice, Practice といってたはず。

F# はメインストリームの言語になるだろうか? という質問もありました。 それに対する回答は「I hope not.」 関数型言語を学ぶ意義は? という問いに対して、 「関数型言語を学ぶことにより、それまで使っていたプログラミング言語によるものとは 『違った視点』を持てるようになるでしょう」とか。 関数型言語で入門した人はという突っ込みはなしで。

F# でプログラムを開発しにくいという意見が会場からでたのですが、 それは、たとえばC#のようにはデバッガーを使ってデバッグ(や開発)が やりにくいからではないか。「細かい単位」毎にイミディエイトウインドウを使って 動作を確認しながら組み立ててみようというアドバイスが。 また、これらのツールもこれから改良されるでしょうとも、

Clojure、Sscala と比べてみてどうかという質問もあり、 それには Clojure → リッチなツールのサポートがない Scala →「関数プログラミングもできる」オブジェクト指向+関数型 両者の基盤となる JVM と .NET を比べると 後者のほうが機能が豊富(ライブラリが充実)。

C++ は low levelなところも書けるし、高速な実行ファイルが作れるけれども 「難しい」

オブジェクト指向、関数型、命令型を適切に使い分けて 問題を解決しましょう。

正しく完璧にやろうしてしまうには経験が必要。 どんどんコードを書きましょう。

■_

It's just a tree, silly! :: Strangely Consistent
http://strangelyconsistent.org/blog/its-just-a-tree-silly

About Ruby error 'kEnd' ?
http://stackoverflow.com/questions/3826525/about-ruby-error-kend

Why you should know just a little bit of Awk : programming
http://www.reddit.com/r/programming/comments/dkew8/why_you_should_know_just_a_little_bit_of_awk/

John's Combinatory Logic Playground
http://homepages.cwi.nl/~tromp/cl/cl.html

LC.pdf (application/pdf オブジェクト)
http://homepages.cwi.nl/~tromp/cl/LC.pdf

Travis Vachon ― Clojure++
http://combinate.us/clojure/2010/09/27/clojure/

Clojure++ : lisp
http://www.reddit.com/r/lisp/comments/djy4i/clojure/

How to write a big app in an obscure Lisp dialect 

 ProDevTips - programming tutorials
http://www.prodevtips.com/2010/03/20/how-to-write-a-big-app-in-an-obscure-lisp-dialect-you-dont-know/

journal.stuffwithstuff.com  Blog Archive  Ruby blocks, Python’s with, and Magpie’s Test Suite
http://journal.stuffwithstuff.com/2010/09/28/ruby-blocks-pythons-with-and-magpies-test-suite/

Ruby blocks, Python's with, and Magpie's Test Suite : programming
http://www.reddit.com/r/programming/comments/dk1bk/ruby_blocks_pythons_with_and_magpies_test_suite/

■_ ネガティブコードとは

What is negative code? - Stack Overflow

I was reading http://en.wikipedia.org/wiki/Douglas_McIlroy and found a quote that
mentions "The real hero of programming is the one who writes negative code."

Can any one explain what that means.

It means reducing lines of code, by removing redundancies or using more concise constructs.

See for example this famous anecdote from the original Apple Lisa developer team:

http://www.computerhistory.org/highlights/macpaint/

   When the Lisa team was pushing to finalize their software in 1982, project managers
   started requiring programmers to submit weekly forms reporting on the number of
   lines of code they had written. Bill Atkinson thought that was silly. For the week
   in which he had rewritten QuickDraw’s region calculation routines to be six times
   faster and 2000 lines shorter, he put "-2000" on the form. After a few
   more weeks the managers stopped asking him to fill out the form, and he gladly
   complied.


Its tongue-in-cheek. If it costs you $N per average coded line, then coding
"negative lines" is surely a winner.

What this means as practical advice, is that small codes that accomplish the job, are
much better than big codes that do the same thing, all other things being equal.

2010年09月29日

■_

コーディングに熱中してたら時間がなくなってたんですよ

■_

What is Gradual Typing? by Jeremy Siek
http://ecee.colorado.edu/~siek/gradualtyping.html

Gradual typing is a type system I developed with Walid Taha that allows parts of a 
program to be dynamically typed and other parts to be statically typed. The programmer 
controls which parts are which by either leaving out type annotations or by adding 
them in. This article gives a gentle introduction to gradual typing.


Gradual typing とはわたしたちが Waild Taha とともに開発した型システムで、プログラムの
一部では動的な型付けを行い、別の部分では静的な型付けを行うことを可能とするものです。
プログラマーはどのパーツに型アノテーション (type annotations) をつけずに放置するのか
あるいは付加するのかを制御します。本 article は gradual typing に対する gentle
introduction を提供します。


The following were our motivations for developing gradual typing:

以下にわたしたちがgradual typing を開発した動機を挙げます:

    * Large software systems are often developed in multiple languages partly because 
      dynamically typed languages are better for some tasks and statically typed
      languages are better for others. With a gradual type system, the programmer can
      choose between static and dynamic typing without having to switch to a different
      language and without having to deal with the pain of language interoperability.
      Hopefully this will increase programmer productivity.

    * 大規模なシステムはしばしば部分的 (partly) に複数の言語を使って開発されますが、
      それは動的型付けの言語 (dynamically typed languages) は一部のタスクにおいてよ
      り優れていて、静的型付けの言語 (statically typed languages) はそれとは別の部分
      についてより優れているからです。gradual type system によって、プログラマーは静
      的型付け (static typing) と動的型付け (dynamic typing) の選択を異なるプログラ
      ミング言語ごとに切り替えたり、 pain of language interoperability を扱う必要な
      しに行えます。これがプログラマーの生産性 (productivity) を向上させることを期待
      しています。

    * Several languages already have optional type annotations, but surprisingly, 
      there had been little formal work on what a type checker should do with the
      optional type annotations and what kind of guarantees the type system should
      provide. Languages with optional type annotations include Common LISP, Dylan,
      Cecil, Visual Basic.NET, Bigloo Scheme, Strongtalk. Gradual typing is meant to
      provide a foundation for what these languages do with their optional type
      annotations. There are several new languages in development that will also
      include optional type annotations such as Python 3k, the next version of
      Javascript (ECMAScript 4), and Perl 6. Hopefully our work on gradual typing will
      influence these languages. 

    * 一部の言語はすでに optional type annotaions を持っていますが、optional type
      annotations に対して type chekcer が行うべきことや型システムが provide すべき
      kind of gurantees がどういったものなのかについて little formal work しか行われて
      きていません。optional type annotation を持った言語には Common LISP, Dylan,
      Cecil, Visual Basic.NET, Bigloo Scheme, Strongtalk といったものが含まれます。
      Gradual typing とは、これらの言語がその optional type anntations を使って行う
      ことのための基盤 (foundation) を提供するものです。Python 3k、Javascript の
      次期バージョン (ECMAScript4)、そして Perl 6のような optional type annotaions
      が取り込まれるであろう開発中の新しい言語がいくつかあります。
      Hopefully our work on gradual typing will influence these languages.


Before describing gradual typing, let's review dynamic and static type checking.

gradual typing を説明する前に、
動的型検査 (dynamic type checking) と静的型検査 (static type checking)を review しましょう。


Dynamic type checking
動的型検査

A number of popular languages, especially scripting languages, are dynamically typed. 
Examples include Perl, Python, Javascript, Ruby, and PHP. In general, a type is 
something that describes a set of values that have a bunch of operations in common. 
For example, the type int describes the set of (usually 32 bit) numbers that support 
operations like addition, subtraction, etc. A type error is the application of an 
operation to a value of the wrong type. For example, applying concatenation to an 
integer would be a type error in a language where concatenation is an operation only 
on strings. Another example of a type error is invoking a method on an object that 
doesn't implement the method, such as car.fly(). (Isn't it a shame that flying cars 
have not yet hit the mainstream, and it's well past the year 2000!) The precise 
definition of type error is programming language dependent. For example, one language 
might choose to allow concatenation of integers and another language not. In a 
dynamically typed language, type checking is performed during program execution, 
immediately before the application of each operation, to make sure that the operand 
type is suitable for the operation.


ポピュラーな言語、特にスクリプティング言語の多くが動的な型付けを行っています。たとえば 
Perl, Python, Javascript, Ruby, PHP といったものがこれに含まれます。一般的なことをいえ
ば型とは共通する操作の集合を持った値の集合を describes する something です。たとえば 
int という型は加減算のような操作をサポートしている(通常32ビットの範囲の) 数値の集合を 
describes します。型エラーとは、間違った型の値に対する操作の適用 (application of an 
operation) です。一例を挙げると、連結が文字列にのみに対する操作である言語であれば整数
に対する連結 (concatenation) の適用は型エラーになるでしょうもうひとつ別の例を挙げると、
car.fly() のようなそのオブジェクトに実装されていないメソッドの呼び出しも型エラーになり
ます (Isn't it a shame that flying cars have not yet hit the mainstream, and it's well
past the year 2000!)。
型エラーの precise definition はプログラミング言語依存 (programming language dependent)
です。たとえばある言語は整数の連結を許すのに、別の言語が許さないということもあるでしょう。
動的型付け言語では、オペランドの型がその操作に対して suitable であることを保証するために
型検査はプログラムの実行時の各操作が行われる直前に行われます。


The following is an example Python program that results in a type error.

以下に挙げるのは型検査を起こす Python プログラムの例です。

  def add1(x):
      return x + 1

  class A:
      pass

  a = A()
  add1(a)

The output from running the above program on the standard Python interpreter is

このプログラムを標準の Python インタープリターで実行したときの結果は
次のようになります


  TypeError: unsupported operand type(s) for +: 'instance' and 'int'


(It would have been nice if the above error message was more specific and said the 
instance was of class 'A' instead of saying that it is an 'instance' of any old class.)



Static type checking
静的型検査

There are also a number of popular statically checked languages, such as Java, C#, C 
and C++. In a statically checked language, some or even all type errors are caught by 
a type checker prior to running the program. The type checker is usually part of the 
compiler and is automatically run during compilation.

静的型検査を行うポピュラーな言語も、Java や C#、C、C++ のようにたくさんあります。静的
型検査を行う言語では、その一部、ひょっとしたらすべての型エラーがプログラムの実行よりも
前に type checker によって捕捉されます。この type checker は通常コンパイラーの一部であ
ってコンパイル時に自動的に実行されるものです。


Here's the above example adapted to Java.

上述の例をJavaに適用したものがこれです。

  class A {
      int add1(int x) {
	  return x + 1;
      }
      public static void main(String args[]) {
	  A a = new A();
	  add1(a);
      }
  }

When you compile this class, the Java compiler prints out the following message.

このクラスをコンパイルすると、Java コンパイラーは以下のメッセージを出力します。

  A.java:9: add1(int) in A cannot be applied to (A)
          add1(a);
          ^
  1 error

You may wonder, how can a type checker predict that a type error will occur when a 
particular program is run? The answer is that it can't. It is impossible to build a 
type checker that can predict in general which programs will result in type errors and 
which will not. (This is equivalent to the well-known halting problem.) Instead, all 
type checkers make a conservative approximation of what will happen during execution 
and give error messages for anything that might cause a type error. For example, the 
Java compiler rejects the following program even though it would not actually result 
in a type error.

どのようにすれば type checker が特定のプログラムを実行したときに型エラーが起きるだろう
ということが予測 (predict) できるのかあなたは不思議に思うかもしれません。そんなことは
できないというのがそれに対する回答です。プログラムが結果として型エラーを起こすかそうで
ないかを in general に予測できるような type chekcer を構築するのは不可能です (これは 
よく知られている halting problem と等価な問題です)。その代わりにすべての type checker は、型
エラーが実行中に発生するもので型エラーを起こすかもしれない anything に対してエラーメッ
セージを give するという conservative approximation を make します。たとえば Java コン
パイラーは、次のプログラムを実際には型エラーにはならないにもかかわらずreject してしま
います。

  class A {
      int add1(int x) {
	  return x + 1;
      }
      public static void main(String args[]) {
	  A a = new A();
          if (false)
  	      add1(a);
          else
              System.out.println("Hello World!");
      }
  }

  class A {
      int add1(int x) {
	  return x + 1;
      }
      public static void main(String args[]) {
	  A a = new A();
          if (false)
  	      add1(a);
          else
              System.out.println("Hello World!");
      }
  }

The Java type checker does not try to figure out which branch of an if statement will 
be taken at runtime. Instead it conservatively assumes that either branch could be 
taken and therefore checks both branches.


Java の type checker は if 文のいずれの分岐が実行時に選択されるかを検出 (figure out) 
しようとはしません。その代わりにどちらの分岐も選択される可能性があると conservatively 
に仮定します。このため、両方の分岐をチェックすることになります。


Comparing dynamic and static type checking
動的型検査と静的型検査の比較


There is a religious war between people who think dynamic checking is better and 
people who think static type checking is better. I believe that one of the reasons why 
this war has gone on for so long is that both groups have good points. (They also have 
some not-so-good points.) Unfortunately the two groups typically don't acknowledge the 
good points made by the other group as being good points. My evaluation of the points, 
given below, will probably annoy both the static typing fans and the dynamic typing 
fans. There are of course arguments to be made for or against each of the points, and 
the evaluation below shows where I land after considering the arguments.

動的型検査がより良いものだと考える人たちと静的型検査がより良いものだと考える人たちとの
間には宗教戦争 (religous war) が存在します。この戦争が has gone on for so long な理由
の一つが双方のグループが good points を持っているということです。(They also have some 
not-so-good points.)残念なことにこれら二つのグループはtypically には他方のグループによ
って作られた good points を good points として認めません。以下に示したわたしの評価ポイ
ントはおそらく static typing のファンと dynamic typing のファンの両方ともを annoy (い
らいら) させるでしょう。
There are of course arguments to be made for or against each of the points,
and the evaluation below shows
where I land after considering the arguments.
もちろん
主張が存在します



    * Static type checking catches bugs earlier, thereby removing the greater cost of 
      fixing bugs later in the development cycle or the even greater cost of a bug that 
      occurs in the field. Good point! Fans of dynamic typing will argue that you catch
      even more bugs by creating a thorough test suite for your programs. Nevertheless,
      I believe static type checking provides a convenient and low-cost way to catch
      type errors.


      静的型検査はバグを早期に捕捉し、開発サイクルの後になってバグを修正する greater cost や
      field で発生してしまったバグの even greater cost を remove します。
      Good point!
      動的型付けのファンは a thorough test suite for your programs
      を作ることによってより多くのバグを捕捉できると主張するでしょう。いずれにしても、静的型
      検査が型エラーを捕捉するための convienient で low-cost な手段を提供するとわたしは確信
      しているのです。


    * Dynamic type checking doesn't get in your way: you can immediately run your program
      without first having to change your program into a form that the type checker 
      will accept. Good point! Fans of static typing will argue that either 1) you don't 
      really need to change your program very much, or 2) by changing your program to fit 
      the type checker, your program will become better structured. The reason why 1)
      feels true to some programmers is that the language you use changes how you think
      about programming and implicitly steers you towards writing programs that will type
      check in whatever language you are using. Also, you get so use to working around the
      minor annoyances of the type system that you forget that they are annoyances and
      instead become proud of your ability to workaround the type system. As for 2), there
      are situations in which the type system gets in the way of expressing code in its
      most clear and reusable form. The well-known Expression Problem is a good example of
      this. The reason why research on type systems continues to flourish is that it is
      difficult to design and implement a type system that is expressive enough to enable
      the straightforward expression of all programs that we would like to write.

      動的型検査があなたの邪魔をすることはありません:
      あなたは自分のプログラムを最初に type checker がそのプログラムを受理する形式に変更
      する必要はなく、即座に実行できます。
      Good point!
      静的型付けを贔屓する人たちは次のいずれかを主張するでしょう
      1) 実際にはあなたはプログラムをそれほど大幅に変更する必要がなかった。
      あるいは
      2) type checker に fit するように変更することであなたのプログラムはより良く構造化される。
      一部のプログラマーたちが 1) が真実であると感じるのは、使っているプログラミング言語は
      プログラミングについてどのように考えるのかを変えて、暗黙のうちに
      writing programs that will type check in whatever language you are using.
      の方向へあなたを導くからです。
      同様に、
you get so use to working around the minor annoyances of the type system
that you forget that they are annoyances
and
instead become proud of your ability to workaround the type system.
As for 2),
there are situations in which
the type system gets in the way of expressing code in its most clear and reusable form.
よく知られている Expression 問題はこの好例です。
The reason why research on type systems continues to flourish is
型システムに関する研究が flourish し続けている理由は、
that it is difficult to design and implement a type system
型システムを設計したり構築するのが難しいからです
that is expressive enough to enable the straightforward expression of all programs
that we would like to write.
すべてのプログラムの straightforward expression を可能にするのに
十分な表現量区のある
わたしたちが記述しようとしている


    * Static type checking enables faster execution because type checking need not be 
      performed at runtime and because values can be stored in more efficient
      representations. Good point!

      静的型検査は実行時に型検査を行う必要がなく、また、値をより効率の良い表現で格納できるので
      高速の実行を可能にします。Good point!

    * Dynamic type checking makes it easy to deal with situations where the type of a 
      value depends on runtime information. Good point!

      動的型検査は実行時情報に依存した値の型を取り扱うシチュエーションを簡単にします。
      Good point!

    * Static typing improves modularity. Good point! For example, in a dynamic language,
      you can call a library subroutine incorrectly but then get a type error deep
      inside that routine. Static checking catches the type errors up-front, at the
      point where you called the subroutine.

      static typing は modularity を向上します。
      Good point!
      たとえば動的言語では、ライブラリのサブルーチンを incorrectly に呼び出せますが、
      その後で型エラーとなるのは呼び出したルーチンの内側奥深くに行ってからです。
      静的型検査では型エラーをサブルーチン呼び出しのその場所で up-front に捕捉します。


    * Static type checking makes you think more seriously about your program which 
      helps to further reduce bugs. Bad point. Type checkers only check fairly simple 
      properties of your program. Most of the work in making sure that your program is 
      correct, whether written in a statically or dynamically checked language, goes
      into developing comprehensive tests.

      静的型検査はあなたに、さらにバグを減らすことを助けるような自分のプログラムについて
      より真剣に (more seriously) 考えさせるようにします。
      Bad point.
      type checkers はあなたのプログラムの fairly simple な propeties しか検査しません。
      あなたのプログラムが正しいことを making sure するための作業の大部分は
      statically checked language を使おうが dynamically checked lanugage を使おうが
      comprehensive tests を developing することになるのです。

    * With dynamic type checking, you don't have to spend time writing type annotations.
      Bad point. The time it takes to write down a type annotation is rather trivial
      and there are programs called type inferencers that can do type checking without
      requiring type annotations. 

      動的型検査を使うことであなたは type annotations に時間をかける必要がなくなります。
      Bad point.
      type annotations を書き下すのに要する時間はとても些細なもの (rather trivial) であり、
      type annotations を要求せずに型検査が実行可能な型インターフェース
      を呼び出すプログラムが存在します。


Because neither static or dynamic type checking is universally better than the other, 
it makes sense to provide the programmer a choice, without forcing them to switch 
programming languages. This brings us to gradual typing.

静的型検査と動的型検査のいずれかがもう一方よりも universally に優れているということは
ありませんから、プログラミング言語の切り替えを強制することなしに
選択肢をプログラマーに与えることには意味があります。
これがわたしたちを gradual typing に導きました。


Gradual type checking

A gradual type checker is a type checker that checks, at compile-time, for type errors 
in some parts of a program, but not others, as directed by which parts of the program 
have been annotated with types. For example, our prototype gradual type checker for 
Python does not give an error for the above program, reproduced again below.

gradual type checker は、コンパイル時にプログラムの一部において型エラーに対する検査を行う
けれども、プログラムのそのほかの部分については型に付随するアノテーションにより指示によって決める
type checker です。
たとえば、わたしたちの Python 向けのプロトタイプ gradual type checker では次のプログラムを
エラーにしません。
reproduced again below.

  def add1(x):
      return x + 1

  class A:
      pass

  a = A()
  add1(a)

However, if the programmer adds a type annotation for the parameter x, as follows, 
then the type checker signals an error because the type of variable a is A, which is 
inconsistent with the type of parameter x of the add1 function, which is int.

ただし、もしプログラマーが次の例のようにパラメータ x に対する型の annotation を追加し
たときに type checker はエラーを知らせます。それは変数の型が A であり、add1 関数の
パラメータ x の型 int に対して inconsistent であるからです

  def add1(x : int):
      return x + 1

  class A:
      pass

  a = A()
  add1(a)

(Our rules for assigning static types to local variables such as a are somewhat 
complicated because Python does not have local variable declarations but in most cases 
we give the variable the same type as the expression on the right-hand side of the 
assignment.
静的型をローカル変数に代入するためのわたしたちのルール
(Our rules for assigning static types to local variables)
は少々複雑です。それは Python はローカル変数の宣言を持っておらず、
ほとんどのケースでは代入の右辺にある式と同じ型を変数に与えているからです。)

The gradual type checker deals with unannotated variables by giving them the unknown 
type (also called the dynamic type in the literature), which we abbreviate as "?" and 
by allowing implicit conversions from any type to ? and also from ? to any other type. 
For simplicity, suppose the + operator expects its arguments to be integers. The 
following version of add1 is accepted by the gradual type checker because we allow an 
implicit conversion from ? (the type of x) to int (the type expected by +).

gradual type checker はアノテートされていない変数に unknown type
(also called the dynamic type in the literature) を与えることを
わたしたちは "?" として abbreviate していて、
任意の型から ? へ、あるいは ? から他の任意の型への
implicit conversion を許可することによって取り扱っています。
簡単のため、+ 演算子がその引数に整数を期待していると仮定します。
次の例にある add1 は、わたしたちが (x の型である) ? から (+ が期待している型である) int への
implicit conversion を許しているので gdarual type checker によって accept されます


  def add1(x):
      return x + 1


Allowing the implicit converson from ? to int is unsafe, and is what gives gradual 
typing the flavor of dynamic typing. Just as with dynamic typing, the argument bound 
to x will be checked at run-time to make sure it is an integer before the addition is 
performed.

? から int への implicit conversison を許すことは unsafe であると同時に、
dynamic typing の flavor を gradual typing に与えているものです。
ちょうど dynamic typingを使うときと同じように、
x に束縛されている引数は加算が実際に行われる前に整数であるかのチェックがなされます。


As mentioned above, the gradual type checker also allows implicit conversions from any 
type to type ?. For example, the gradual type checker accepts the following call to 
add1 because it allows the implicit conversion from int (the type of 3) to ? (the 
implied type annotation for parameter x).

先に言及したように gradual type checker は任意の型から ? への implicit conversions も許可します。
たとえば type checker は次の例のような add1 の呼び出しを受理します。
それは (3の型である) int から (パラメーター xに対する implicit type annotationである)
? への implicit conversion を許しているからです。

  add1(3)

The gradual type checker also allows implicit conversions between more comlicated 
types. For example, in the following program we have a conversion between different 
tuple types, from ? * int to int * int.

gradual type checker はまた、より複雑な型の間での implicit conversions も許しています。
たとえば次のプログラムでは ? * int から int * int という
二つの異なる tuple type の間でconversionしています。

  def g(p : int * int):
    return p[0]

  def f(x, y : int):
    p = (x,y)
    g(p)

In general, the gradual type checker allows an implicit conversion between two types 
if they are consistent with each other. We use the shorthand S ~ T to express that 
type S is consitent with type T. Here are some of the rules that define when two types 
are consistent:

一般的に guradual type checker は二つの型の間の implicit conversion を
they are consistent with each other であるときに許可します。
わたしたちは 型 S が 型 T に対して consistent であるときに S ~ T という省略形を使って表します。
以下に、二つの型が consistent であると定義するルールをいくつか挙げます:

   1. For any type T, we have both ? ~ T and T ~ ?.
      任意の型 T に対して ~ T と T ~ の両方があります。

   2. For any basic type B, such as int, we have B ~ B.
      int のような任意の基本型 B に対して B ~ B となります。

   3. A tuple type T1 * T2 is consitent with another tuple type S1 * S2 if T1 ~ S1 and 
      T2 ~ S2. This rule generalizes in a straightforward way to tuples of arbitrary size.

      あるタプル型 T1 * T2 は別のタプル型 S1 * S2 に対して T1 ~ S1 かつ T2 ~ S2 であるとき
      consistent です。この規則は任意のサイズのタプルに対して straightfoward way で
      generalizes されます。

   4. A function type fun(T1,...,Tn,R) (the T1...Tn are the parameter types and R is 
      the return type) is consistent with another function type fun(S1,...,Sn,U) if
      T1 ~ S1...Tn ~ Sn and R ~ U.

      ある関数型 fun(T1, ... Tn, R) は別の関数型 fun(S1, ... Sn, U) に対して
      T1 ~ S1...Tn ~ Sn and R ~ U であれば consistent です。


We write S !~ T when S is not consistent with T. So, for example

S が T に対して consistent でないとき S !~ T と書きます。ですからたとえば

    * int ~ int
    * int !~ bool
    * ? ~ int
    * bool ~ ?
    * int * int ~ ?
    * fun(?,?) ~ fun(int,int)
    * ? ~ fun(int,int)
    * int * int !~ ? * bool


Why subtyping does not work
なぜ subtyping がうまくいかないのか

Gradual typing allows an implicit up-cast from any type to ?, similar to 
object-oriented type systems where Object is the top of the subtype lattice. However, 
gradual typing differs in that it also allows implicit down casts. This is the 
distinguishing feature of gradual typing and is what gives it the flavor of dynamic 
typing. Previous attempts at mixing static and dynamic typing, such as Thatte's 
Quasi-static Typing, tried to use subtyping but had to deal with the following problem. 
If the dynamic type is treated as both the top and the bottom of the subtype lattice 
(allowing both implicit up-casts and down-casts), then the lattice collapses to one 
point because subtyping is transitive. In other words, every type is a subtype of 
every other type and the type system no longer rejects any program, even ones with 
obvious type errors. Consider the following program.


gradual typing は Object が subtype lattice のトップであるようなオブジェクト指向の型シ
ステムと同様に、任意の型から ? への暗黙のアップキャスト (implicit up-cast) を許可しま
す。ただし、gradual typing では暗黙のダウンキャスト (implict down cast) も許している点
が異なります。これは gradual typing の distinguishing feature であり、dynamic typing 
の flavor を与えるものです。
Thatte の Quasi-static typing のような先行の static typing と dynamic typing を
混合する試みでは subtyping を使おうとしていましたが、
以下に挙げるような問題に対処しなければなりませんでした。
もしその dynamic type が (implicit up-cast と implicit down-cast の両方を許していることによって)
subtype lattice の top と bottom のどちらとしても扱われるならば、
subtyping が transitive であるためにその lattice は collapses to one point
(一点に向かって崩壊する?) です。
言い換えると、すべての型はそのほかすべての型の subtype であり、その型システムは
明らかに型エラーを持っているようなプログラムさえももはや reject しません。
次のプログラムを考えてみましょう。


  def add1(x : int) -> int:
     return x + 1
  add1(true)  


Using true as an argument to the function add1 is an obvious type error but we have 
bool <: ? and ? <: int, so bool <: int. Thus the subtype-based type system 
would accept this program. Thatte partially addressed this problem by adding a 
post-pass after the type checker but this still did not result in a system that 
catches all type errors within fully annotated code, as pointed out by Oliart. 


関数 add1 に対する引数として true を使うことは明らかに型エラーですが、わたしたちには  
bool <: ? と ? <: int があるので、 bool <: int となります。このため 
subtype-based の型システムはこのプログラムを受理するでしょう。type checker の後に 
post-apss を追加することによってこの問題に部分的に対処していますが、Oliart が指摘した
ようにこれは fully annotated なコードでのすべての型エラーを捕捉するシステムにおいて 
still did not result です。

  

■_


PHPカンファレンス2010スペシャルレポート:2日目,テックデイレポート[随時更新]|gihyo.jp … 技術評論社

Rasmus Lerdorfさん「PHP Then and Now.」

今日の基調講演は,PHPの生みの親,Rasmus Lerdorfさんです。

「1993年,すべては Mosaic を見た時に始まった」との語りとともに,スライドには懐かしい
Mosaicの画面が映し出されました。Mosaicの出現によって,「自分のやっていることを初めて母
親に説明できるようになった」とRasmusさんは話します。

懐かしいPHP 1のコードがスライドに表示された後は,PHP 5.3の説明です。最新版である
PHP5.3.3はほぼ1ヶ月前にリリースされました。「まだPHP 4を使っている人はぜひアップデート
してほしい。現在はPHP 4を走らせるべきではない」とし,PHP 4よりPHP 5のほうがはるかに速
く,また5.2よりも5.3のほうがさらに速いと話します。

PHP 5.3.3は,内部のエンジン内のスタックが改善されていること,定数には専用のメモリが割
り当てられること,例外処理も高速化されていること,コンパイラをうまく活用することでバイ
ナリサイズも小さくなり,起動も高速化していること,Windows版のPHPはマイクロソフトの協力
によって40%の速度向上が実現したことなど,最新版では著しい高速化が実現しているとの話で
した。 PHP 5.3以降の新機能として,クロージャ,名前空間,遅延スタティックバインディング
(LSB),ガベージコレクション,ヒアドキュメントのシングルクォート版であるNOWDOCなど,
多くのフィーチャーが説明されました。また,名前空間の区切り文字として「\」が選ばれた理
由として,ウェスタンキーボードで機能の割り当てられていない一文字の記号が \ しかなかっ
たことを説明した後,「ひょっとして日本語の文字を使ったほうがよかったのかな」とリップサ
ービスも忘れないRasmusさんでした。

今回の講演のスライドは,http://talks.php.net/show/phpjp10 にて公開されています。

そんな理由で \を選択したのか…

■_ これは読まねば

Zed の書いた入門書とやらを。


Shedding Bikes: Programming Culture And Philosophy


By Zed A. Shaw

Learn Python The Hard Way Done!

Alright, so maybe it's "programmer done" but I just finished the last 
exercise for Learn Python The Hard Way and will now be editing it and doing the index. 
That's 52 exercises mapping out quite a lot more Python than I thought I'd do 
originally.

I get into most data structures, classes and object, and I manage to very sneakily 
teach parsing even. I'm thinking that when someone's done with LPTHW they can 
definitely move onto another book and do some real programming.

You can get the PDF of the book and read through it. If you find errors then please 
report a new ticket so I can fix it.

Writing this book was incredibly fun. Having people actually learn to code from it is 
probably the best. Having people who couldn't learn to code before my book is even 
better.

この本を書くことはこの上もなく楽しかった。
この本からコーディングを学ぶ人にはおそらく最良のもので、
この本に出会うまでコーディングを学ぶ人に対しても良いものである。

I'm probably going to take the final edited version of the book and offer it on 
lulu.com for very cheap from their JIT printing service. The goal will be to make the 
book cheap enough that just about anyone can get a printed copy if they want. The book 
will always be a free download from the website as a PDF too, and you're free to share 
it with others as long as you don't charge for it or change it.

この本は PDF としてもいつでも website からダウンロードが自由にできます。
そしてそれを、あなたが料金を課したり変更しないかぎり
ほかの人との共有が自由に行えます。

I may also want to meet people in SF who are going through the book and help them out. 
If anyone's interested, let me know on twitter.


http://learnpythonthehardway.org/static/LearnPythonTheHardWay.pdf

■_

2010年09月28日

■_

・結構面白い
情報系+αことのは辞典
情報系+αことのは辞典
この手の本は結構好き。

・J9
パナソニック、Let's noteの新シリーズ「J9」を発表:ニュース
軽量コンパクトな高性能ノート「Let’snote J9」が登場、着脱可能な「ジャケット」装備で高耐久性を実現 - GIGAZINE
ジャケットを「着せ替え」できる女性向けLet's noteが登場:ニュース
んー R6から乗り換えようかなあ。Rは打ち止めらしいし。

■_ リストの先頭を


GarlicSim blog - Python idiom for taking the single item from a list
It sometimes happens in code that I have a list, let's call it stuff, and I know for 
certain that this list contains exactly one item. And I want to get this item and put 
it in a variable, call it thing. What's the best way to do this?

In the past I used to do this:
以前、わたしはこのような書き方をしていました:

    thing = stuff[0]

But I think that's not the best idiom. I came up with a better one:
しかしわたしはこれがベストなイディオムであるとは思いません。
わたしはより良い書き方にたどり着きました:

    (thing,) = stuff

Why is this one better?
なぜこちらの方が良いのでしょうか?

   1. Readability: It lets the reader know that stuff has exactly one element.
      読みやすさ
      読み手に対して一要素だけを取り出そうとしていることを教えられます。

   2. Free assert: It makes Python assert that stuff has exactly one element, so if I 
      was wrong in my original assumption that stuff has exactly one element, Python
      will shout at me before this will manifest itself as a hard-to-find bug
      someplace else in the program.

   3. Hard to miss: The previous method had a [0] at the end. Now, that's easy to 
      notice in a line as short as thing = stuff[0]. But what if the line was something 
      messy like this:
      間違いをしにくい
      前者の書き方では、末尾に[0]をつけなければなりません。これは thing = stuff[0]のように
      行が短い場合には認識しやすいですが、行が長い場合には次の例のように messy になってしまいます。

          thing = some_dict[my_object.get_foobar_handler()][0]

      In this case, the [0] at the end is easy to miss, because when casually glancing 
      the code, it might seem connected to that function call or dict lookup. So the reader 
      might miss the fact that we're taking an item out of a list here. This would be 
      better in this case:
      この書き方の場合、末尾にある [0] は間違いやすいです。なぜなら、casually glancing に
      コーディングしているとき、関数呼び出しや辞書参照 (dict lookup) に connect するようです。
      そのため、わたしたちがここではリストからアイテムを取り出そうとしていることを
      読み手は勘違いしてしまうかもしれません。この場合、次のように書くのがより良い書き方でしょう:

          (thing,) = some_dict[my_object.get_foobar_handler()]

   4. General for any “collection” (Props to Ulrik for noting this): This method 
      works even when stuff is a set or any other kind of collection. stuff[0] wouldn't 
      work on a set because set doesn't support access by index number.
      任意の「コレクション」に対して一般的である
      このやり方は set やそのほかのコレクションであっても動作します。
      stuff[0] は set に対してはうまくいきません。なぜなら、set は数字による添え字付け
      を使ったアクセスをサポートしていないからです。

Have fun programming!

一要素のタプルで受け取る記述のほうが読みやすい…のかなあ?

■_

O'Reilly Village/オラの村 - 『プログラミングF#』著者が明かすF#を使いこなすとっておきの秘訣!

なんかレポートまとめる必要なくなった気が(苦笑)

■_ ないわー

オライリーさんしっかりしてよ。

ちょっと見づらい画像で申し訳ありませんが、 「どんどん、、、」、「大きくなっていく、、、」、「てくる、、、」 のように、…を使うべきところがなぜか読点三連打。 ネットの書き込みでは「、、、」とか「。。。」のようなのを時折見かけますが、 書籍でこれは… あ、この本は「言語設計者たちが考えること」です。

■_ 本日の巡回から

■_ Python←PHP

PHP カンファレンスの記事で一番気になったもの。

PHPカンファレンス2010スペシャルレポート:2日目,テックデイレポート[随時更新]|gihyo.jp … 技術評論社
http://gihyo.jp/news/report/01/phpcon2010/0002?page=6

桑田誠さん「PHPer100人にPythonを教えてみた」

PHPとPythonを比較しながらの勉強会を開催されているそうで,これまでに7回開催されています。
この勉強会には,地方からの参加者や,複数回参加される方などても勉強熱心な方々が参加され
ているそうです。
  

どんなんだろう。

2010年09月27日

■_

こんなExcel本を目撃 エクセルができたくらいで好きになんかならないんだからねっ! | 学研出版サイト 残念ながらシュリンクされていたので中身の確認はできませんでした。 エクセルができたくらいで好きになんかならないんだからねっ! (学研ムック)
エクセルができたくらいで好きになんかならないんだからねっ! (学研ムック)
これと同系統? これはわりとまじめな内容だったけど。 電撃PC [超解]Excelたん
それから、このシリーズのパワーポイントのは結構参考になる記述が多いと思います。 ってイマドキはパワポ使いは流行らないかな。
電撃PC [超解]パワポたん 社会人までに身につけたいプレゼン力を磨け!

・センゴク外伝桶狭間戦記
来週休載とな? ○| ̄|_

■_ -F

またか


awkについて語るスレ $2 
378 デフォルトの名無しさん [sage] 2010/09/27(月) 14:57:18 ID: Be:
    質問です。
    データが
    |1|aaa|
    |2|bbb|
    |3|ccc|
    などとなっているとき
    aaa
    bbb
    ccc
    を取り出そうとして
    awk 'FS="|"{print $3}' ファイル名
    としたんですが、1行目だけがうまくとれません。
    データファイルの1行目を空行にすれば解決できないことはないんですが、
    空行を入れ忘れてしまう懸念があります。
    どうすればいいんでしょうか? 

379 デフォルトの名無しさん [sage] 2010/09/27(月) 15:01:46 ID: Be:
    やりたいことは awk 'BEGIN {FS="|"} {print $3}' じゃないかと思うんだけど 

380 デフォルトの名無しさん [sage] 2010/09/27(月) 15:08:38 ID: Be:
    378です。
    >>379
    どうもありがとうございました。 

381 デフォルトの名無しさん [sage] 2010/09/27(月) 18:42:12 ID: Be:
    gensub()にて、マッチした10番目以降のグループの指定の仕方を教えてください。
    下記サイトでは、17番目まで普通に指定できるような事が書いてあるけど、
    http://tounderlinedk.blogspot.com/2010/08/gensub-n-awk.html

    gensub(pattern,"\\10","g",$2) とかくと
    \\1(マッチ箇所)と0(文字)として解釈されちゃって上手くいなかい。

    シェルスクリプト風かと思って、\\{10} も試したけどダメダッター。

    GNU Awk 3.1.5です。

382 381 [sage] 2010/09/27(月) 19:00:47 ID: Be:
    BSDのjmanには、1から9までの数字って明記されてるなあ。
    実装によって違うのかなあ
    パターンを動的に生成してマッチさせようとしてるから結構困る(´・ω・`)
    http://www.linux.or.jp/JM/html/GNU_gawk/man1/gawk.1.html

383 デフォルトの名無しさん [sage] 2010/09/27(月) 19:04:47 ID: Be:
    >>381
    マニュアルには1から9までって書いてあるし

    Within the replacement text s, the sequence \n, where n is a digit from 1 to 9, may be
    used to indicate just the text that matched the n'th parenthesized subexpression.

    ソースの該当箇所(builtin.cの2542行目あたりから)みても1桁限定のロジックだよ。(3.1.7調べ)

    int dig = scan[1] - '0';

    なんてやってる。 

384 デフォルトの名無しさん [sage] 2010/09/27(月) 19:08:03 ID: Be:
    一旦ぶった切るしかないんじゃね 

385 381 [sage] 2010/09/27(月) 19:12:31 ID: Be:
    >>383
    どうもありがとうございます。

    >>384
    ちょっと見栄え悪くなるけどそうする(´・ω・`) 

386 デフォルトの名無しさん [sage] 2010/09/27(月) 21:27:29 ID: Be:
    >>381
    なんでそこのひとは16までできたんだ? 

387 デフォルトの名無しさん [sage] 2010/09/28(火) 00:32:52  ID: Be:
    10の代わりに:を使っていたりして。 

FS に入れるのは正規表現だから、\\| とかにしないといかんのじゃないかなあ (二回解釈されるのでバックスラッシュは二重でないと×)。 あと、BEGIN でやらないで -F"\\|" でいいのに。

back referennce 16個までできたってのは謎だ。 どんなパターンでやったんだろうか。

■_

この質問してた人かなあ >164 文字コードについて | OKWave 文字コードのASCIIについてなんですが、どうしてこういう配置になったかっていう根拠みたいなのが書かれた文献等ってありますか?


文字コード総合スレ part6 
164 デフォルトの名無しさん [sage] 2010/09/27(月) 19:50:00 ID: Be:
    ASCIIについてなんですが、
    ASCIIの配置がこうなった理由とか書いてあるとこ知りませんか?

165 デフォルトの名無しさん [sage] 2010/09/27(月) 20:19:00 ID: Be:
    え? 

166 デフォルトの名無しさん [sage] 2010/09/27(月) 20:24:41 ID: Be:
    >164
    ASCIIのコード配置はテレタイプに由来してる 

167 デフォルトの名無しさん [sage] 2010/09/27(月) 20:31:33 ID: Be:
    契丹文字の追加提案が出てるな 

168 デフォルトの名無しさん [sage] 2010/09/27(月) 21:53:30 ID: Be:
    この調子でアヒル文字とか入れてくれないかな 

169 デフォルトの名無しさん [sage] 2010/09/27(月) 21:59:57 ID: Be:
    神代文字は絶対入れねえと言い切られちゃってます
    http://www.unicode.org/roadmaps/not-the-roadmap/ 

170 デフォルトの名無しさん [sage] 2010/09/27(月) 23:04:18 ID: Be:
    そんな名指しがあったのかw 

171 デフォルトの名無しさん [sage] 2010/09/27(月) 23:19:31 ID: Be:
    Klingonを入れないと決めて以来、この種の文字は全部だめになった感じ 

172 デフォルトの名無しさん [sage] 2010/09/27(月) 23:21:53 ID: Be:
    一時は実在が信じられてたんだから、
    さすがにクリンゴンと同列はちょっと凹むな… 

173 デフォルトの名無しさん [sage] 2010/09/28(火) 00:01:42 ID: Be:
    まだ、線文字Aとかインダス文字とか西夏文字とか女真文字とかロンゴロンゴ文字は入ってないんだな。

    西夏文字は入る予定? 

174 デフォルトの名無しさん [sage] 2010/09/28(火) 00:05:20 ID: Be:
    マヤ文字や梵字も入ってないな。 

175 デフォルトの名無しさん [sage] 2010/09/28(火) 00:11:53 ID: Be:
    >>173-174
    予定はあるようだ
    http://www.unicode.org/roadmaps/smp/ 

! からの記号のならびになんか由来があったんでしょか。

■_

ついったやりながらだと駄目だな。

What is Functional Programming? - Christopher Bennage - Devlicio.us - Just the Tasty Bits

Christopher Bennage ≫ What is Functional Programming?

What is Functional Programming?
関数プログラミングとはなにか?

Disclaimer: I'm still pretty green with functional programming. This is me working
out my own understanding.

Wikipedia defines Functional Programming (FP) this way:
Wikipedia では関数プログラミング (FP, Functional Programming) を次のように定義しています:

    “functional programming is a programming paradigm that treats computations as the
      evaluation of mathematical functions and avoids state and mutable data.” [reference]

      関数プログラミングとはcomputations を数学的関数の評価として扱い、
      状態と mutable なデータを排除するというプログラミングのパラダイムです。


Let's break this apart.

Programming Paradigm
プログラミングのパラダイム

What's a “programming paradigm”? It's a conceptual model for creating programs.
The most popular paradigm (at least in tongue) would be Object Oriented Programming
(OOP). Other common paradigms are Imperative Programming (I suspect a majority of the
world's code is here) and Declarative (which includes languages like html and xaml).
Here's a list of some other programming paradigms.

“プログラミングのパラダイム”とはなんでしょうか?
それは、プログラムを作るときの conceptual model です。
最も popular なパラダイム (at least in tongue) は
オブジェクト指向プログラミング(OOP Object Oriented Programming) でしょう
その他の一般的なパラダイムには命令型プログラミング
(Imperative Programming。わたしはセカイに溢れるコードの多数派これであろうと予測しています)
や
HTML や XAML のような言語を含む宣言型 (Declarative) といったものがあります。


It seems to me that most popular languages allow for the use of more than one paradigm.
You'll hear people referring to a language as “multi-paradigm”, this means it has
characteristics from more than one model. For example, F# is described as having both
functional and object-oriented characteristics. Some paradigms reinforce others. For
example, OOP tends to be Imperative and FP tends to be Declarative.


たとえば、F# は関数型とオブジェクト指向の両方の特性を持っているように説明されます。
一部のパラダイムは他のパラダイムを reinforce します。
たとえば OOP は Imperative に、FP は Declarative となる傾向にあります。

Computations

In this definition, I take the term very generically. You can interpret it to mean
“stuff the program does”.

この定義においては、わたしはこの用語を generically に捕らえます。
あなたはこれを “stuff the program does”を意味するものと解釈できます。


Evaluations of Mathematical Functions
数学的関数の評価

This is the core concept behind functional languages. In OOP we tend to think of
functions as methods that change the state of objects. We have some object, say an
order, and we call some method, like submit(), and the method changes the state of our
object. Now, in a mathematical function we don't really have the notion of an object
or even a state. Consider a function that calculates (naively) the height of a
projectile with respect to time:

これは関数型言語の背後にある core concept です。
OOP では、わたしたちは関数をオブジェクトの状態を変えてしまうメソッドとして
考える傾向にあります。


    f(t) = -4.9t2 + 19.6t + 3

With this function, we pass in a value for t and we get back a value representing the
height. There is no “state” we are modifying in this function. There's more to this
concept, but let's come back to it.



Avoids State and Mutable Data
状態と mutable なデータを排除する

This point follows naturally from the last one, however it was very confusing to my
object-oriented mind. In fact, FP sounded a somewhat contrary to my understanding of
how computers are working at a low level. Despite this, immutability is central to
functional programming. In a functional language, such as F#, you don't work with
variables. Instead you work with values. Variables (as their name implies) can change,
but values are constant.

この point はひとつ前のものから自然に導かれますが、
わたしのオブジェクト指向マインドをとても混乱させたものでした。
事実、


F# のような関数型言語では
変数 (variables) を使って何かをするようなことはありません。
その代わりに値 (values) を使います。
変数はその名が暗示しているように変更することが可能ですが、
値は constant です。


Characteristics of Functional Languages
関数型言語の特性

Even after breaking it apart, the definition is still a bit of an academic one. I
found it beneficial to see how these concepts played out into actual features in a
language. The following list is my compilation, and I'm certain it's not exhaustive.
These are common features or concepts found in many functional languages.


以下は多くの関数型言語に見られる一般的な機能 (features) や コンセプト (concepts) です。

    * First Class Functions (第一級クラスの関数)
    * Higher Order Functions (高階関数)
    * Pure Functions (純粋関数)
    * Currying or Partial Application (カリー化と部分適用)
    * Recursion (再帰)
    * Pattern Matching (パターンマッチング)
    * Memoization (メモ化)

I'll begin by discussing the first three items. The remaining will follow in
subsequent posts.

First-Class Functions
第一級クラスの関数

This means that functions are basic types and can be passed around just like integers
or strings. In C#, we have a couple of ways to do this. Here's one example, we'll
create a function and name it “add”. It will accept two integers and returns an
integer:

このことは基本的な型であり、関数が整数や文字列のようにpassed around できるという
ことを意味します。C#では、これを行うための方法が複数あります。
次に挙げるものは一つの例で、関数を作ってそれに“add”と命名していいます。
この関数は二つの整数を受け取って整数を返します:

Func<int, int, int> add = (i, j) => i + j;

This example relies on the type Func<T1,T2,TResult> introduced in .NET 3.5 and we
set the value using a lambda expression.

Update: after writing this I found this description of first-class functions on MSDN.


Higher Order Functions
高階関数

Higher order functions are functions that either take a functions as an argument or
return it as a result. Let's say that we need to write a program that takes a list of
integers and then, depending on some user choice, will either add all the numbers
together or subtract them. Building on our add function from above, we could create a
higher order function in C# like this:

高階関数は引数として関数を受け取るか戻り値として関数を返すかする関数です。


static int Reduce(Func<int, int, int> reducer, IEnumerable<int> values)
{
    int accum = 0;
    foreach (var i in values)
    {
        accum = reducer(accum, i);
    }
    return accum;
}

I named the function “Reduce” since it reduces a list of integer down to a single 
integer. You can see that the first parameter matches the type of our add function 
from above. We can call Reduce like this:

わたしはこの関数を “Reduce”と名付けました。
それはこの関数が整数のリストを一つの整数へと reduce するからです。

Reduce は次のように呼び出せます:

var integers = new[] {1, 2, 3, 4, 5};
var sum = Reduce(add, integers);

Pure Functions
純粋関数

A function is pure when it has no side effects. This mean that the function does not 
alter a state or mutate any data. For example, our add function is pure. We calculate 
a result but we do not modify any existing data. Our other function, Reduce, is pure 
too… well sort of. It's pure in the sense that - if you treat it as a black box - 
then no state is modified. However, internally it does maintain a state. That is, the 
variable accum is the internal state that we modifying for each iteration of the loop. 
We'll see how to remove the state from the Reduce function in another post.

関数が副作用を持たないときその関数は純粋 (pure) です。
純粋であるとは、その関数が状態を変更したり何らかのデータを書きかえたりしないということです。
たとえば先ほど例に出した add  関数は純粋です。
わたしたちはこの関数で結果を計算しますが、既存のデータを一切変更していません。
わたしたちの別の関数、Reduce もまた純粋です。ある意味では。
この Reduce 関数をブラックボックスとして扱うのであれば、
この関数は純粋であり、状態は変更されていません。
しかし、内部的には状態を maintain しているのです。
つまり、変数 accum は内部状態であり、そしてそれはわたしたちが
ループを繰り返す度に変更しているものだということです。
別のポストでは、このReduce関数からイカにして状態を取り除くのかについて述べることになるでしょう。


Pure functions are closely tied to the concept of Referential Transparency, which says 
that an expression is considered referentially transparent when it can be replace with 
it's value. For example,

純粋関数は Referential Transparency (参照透明性?) という concept に密接に結びついています
この conept はある式がその値と置き換えることができるときに
referentially transparent (参照透明) であると見なされるというものです
例を挙げましょう。

var sum = add(3,4);

can be replaced with
これは次のものに置き換え可能です

var sum = 7;

and there will be no change in meaning.
そして意味的には全く変わりがありません。

Continue on to Currying…
カリー化に続く

Posted 09-06-2010 11:49 PM by Christopher Bennage

■_

2010年09月26日

■_

渋谷のジュンク堂は行くまでが大変だw

■_ なぜかと問われても

Twitter / ところてん: なんで、Perlなんて無茶な言語でCGIを書こうとし ...

なんで、Perlなんて無茶な言語でCGIを書こうとしたんだろうか。当時の人たちは。明らかに
HTMLとは相性悪い言語だよね。 PHPが発明されるのも無理ないとおもうが、数ある言語の中で
なぜperlだったんだろうか。

「数ある言語」とありますけど、 実際のところ Perl 以外でどんな選択肢がある(あった)とお考えなんでしょうか。 「無茶」というのもよくわからんけど。

Ruby や Python は言語そのものの普及度が低かっただろうし、 Javaはアプレット用と考えられていた時期だろうし、 C や C++ は… あと何かあるかな。

■_ ブックオフ

たまーに掘り出し物が見つかるらしいですねえ>ブックオフ わたしはそんなお宝にめぐり合ったことはないのですが。


スレッドを立てるまでもない質問雑談スレ41 
767 仕様書無しさん [] 2010/09/23(木) 15:40:01 ID: Be:
    書籍を買うときにブックオフとか古本屋にしか買いに行かない同僚が居るんですが、
    なんか違和感を感じるのは俺だけかな。。。

    レガシーなシステム作るならまだしも
    Javaとか.Netとか新しめの技術を使う会社なんだけど・・・。

    そのせいかいつも「良い本が無かった」といって何も買わず。
    そんな感じだからスキルのほうも・・・・。 

768 仕様書無しさん [sage] 2010/09/23(木) 16:27:20 ID: Be:
    ほっときゃいいじゃん
    本人の価値観に基づいた行動なのだし
    ぶっちゃけ本なんか要らねってひとも居るんだし 

769 仕様書無しさん [sage] 2010/09/23(木) 21:49:17 ID: Be:
    Javaや.Netなんて新品だともう売ってないだろ
    都心大手ならともかく地方駅前程度ならJavaや.NETみたいな
    旬が過ぎた本なんて扱ってくれない

    ブックオフや古本屋は一度は誰かが「購入する」という選別をした本ばかり並んでいる
    古本の在庫量は世間の流通量と比例する
    つまりブックオフで入手するっていうのは世の中が良いと思った本を買うことになる

    年に数百冊読む俺でも良い本なんてその中から数冊あるかどうか
    たしかに新品を最初から選外にするのは惜しいが
    会社の命令で手っ取り早く必要な事を覚えるなら古本のほうが効率がいい

    古本でいいものを探せないヤツは新品でもいいものを探せない
    書籍もパソコンも畳も女も新しけりゃいいってもんじゃない 

770 仕様書無しさん [sage] 2010/09/23(木) 23:33:02 ID: Be:
    売ってねえとかどんな本屋に行ってんだよ
    そこらじゅうの本屋にあるじゃねえか
    それとも節穴なのかその目は 

771 仕様書無しさん [sage] 2010/09/24(金) 00:10:47 ID: Be:
    都市部の本屋でも本棚1つ分しかないよ(一番売り場面積を占領してるVBですら本棚2つ分)
    田舎なんて20冊あればいいほう
    しかも新しいものばかりで古いのは無い
    そんな中から選べるわけないじゃん
    バージョン合わせるだけで大半が候補から外れる状況なんだぜ? 

772 仕様書無しさん [sage] 2010/09/24(金) 00:28:19 ID: Be:
    ないならKonozamaで買えば? 

773 仕様書無しさん [sage] 2010/09/24(金) 03:42:37 ID: Be:
    話を聞いてなかっただろ? 

774 仕様書無しさん [sage] 2010/09/24(金) 04:52:19 ID: Be:
    購入した結果要らないと判断されるから早々に中古に流れるわけだが 

775 767 [sage] 2010/09/25(土) 13:16:21 ID: Be:
    ほっときゃいいって意見も分かるんですが、
    仕事が出来ないしわ寄せがこちらにくるので困りものなんです。
    本を買っても、「10日で覚える○○」的な本を買って
    業務中ずっとにらめっこしてるんです。

    あと住んでいるところが超田舎なので
    本屋にそもそもあまり本を置いてないので
    ブックオフなんかにいっても殆ど置いてないんです。

    まぁ本を買う買わないとかは本人の気質の行動への表れなので、
    本質的なところを改善しないとダメなんでしょうね。。。

    業界歴20年のベテランのはずなんですが。。。
    うーむ。

776 仕様書無しさん [sage] 2010/09/25(土) 13:29:31 ID: Be:
    もっと根本の問題を探したほうがいい
    どこでも一定数以上は無能が含まれるんだからしわ寄せを食らう体制に問題がある
    おまえさんがスケジュールをアウトプットしてないorコミュ不足ってところではないか?
    自分に非が無いと思うなら段取りを決めてる段階で
    「○○さんがそんな日数で仕事できるわけないですか」と上司に言ってみれば?
    打ち合わせ中だと角が立つだろうからタバコ吸ってるときとかさ

    そうではなくて技術力の底上げをしたいならおまえの本を会社に置け
    そして技術ネタを話しかけろ
    人間は毎日話題になる事は自然と吸収するように出来てる

    だいたい業務中ににらめっこしてたら「どうですか?」って話かけてやれよ
    それが出来てない会社ってどこか技術軽視してるとこがあるんだよ 

777 767 [sage] 2010/09/25(土) 14:24:11 ID: Be:
    コミュ不足というか、コミュの取りかたにも苦労してますねぇ。

    プライドが高い方なので、意見をすると不機嫌になるんです。
    相手の気を損ねないように工数の見積の甘さや
    スケジュールの遅れを指摘しても聞き入れてもらえないんです。

    仕事が出来ていない現実は見ずに
    自分は仕事が出来るんだという思い込みが強いみたいなんです。

    ちょっとした話しの中で最近のトレンドネタを持ち出すと
    そっぽむいてネットサーフィンを始めます。

    にらめっこもね、繊細な問題なんです。
    ちょっとでも声をかけると、もう自分で考えることをやめるんです。
    変数の名前のつけ方から逐一聞いてくるんです。
    自分で考えるようには伝えるんですけどね。
    本とにらめっこでだけではなく、こちらから紹介した
    ネットのマニュアルとか記事を見るとかしてほしいいんですが、見てもらえない。。。

    凄く取り扱いの難しい人なんです。

    体制の問題・・・、あると思います。

780 仕様書無しさん [sage] 2010/09/25(土) 18:03:41 ID: Be:
    >>777
    とりあえずおだてて木に登らせろ。
    後は全て丸く収まるように祈れ。w 

781 仕様書無しさん [sage] 2010/09/25(土) 18:06:44 ID: Be:
    >>777
    ていうか、あなたはそいつの居る部署の責任者なの? もしそうでないならもう考えなくていいと思う。
    で、上司に正確な情報だけ伝える。遅れているならそいつがどのぐらいの期間でどれだけ進んだか
    などを伝え、事情を知ってもらう。それでも現状は中々変化しないかも知れないがあなたが苦労して
    いることは伝わり、それによりあなたの評価は上がるだろう。

    上がらないようなら辞めろ。

782 仕様書無しさん [sage] 2010/09/25(土) 18:24:21 ID: Be:
    >>779
    9月から禁煙してるのだが値上がりする前に吸っておこうかな。 

783 767 [sage] 2010/09/25(土) 19:37:19 ID: Be:
    >>780
    とりあえず見えなくなるくらい遠くまでまで登らせときます。


    >>781
    私はただの平社員で、相手のほうがよりお責任のある立場ですw

    ですので相手のさらに上の立場の人に相談してみます。

    真摯なご意見ありがとうございます。


784 仕様書無しさん [sage] 2010/09/25(土) 20:03:44 ID: Be:
    そいつをお払い箱にして俺を雇ってくれw 

785 仕様書無しさん [sage] 2010/09/25(土) 21:31:28 ID: Be:
    >>778
    嫌いだけどあの煙の中に宝が埋まってるんだよ

    >>783
    ヘボ上司に困ってるパターン?
    だったら全部仕事奪っちゃえよ
    「ソースがこの規約通りかチェックお願いできますか?」とか
    適当に仕事ふっておけばおとなしくしてるだろうし 

なんか流れが変わってる

■_


正規表現 Part7 
506 デフォルトの名無しさん [sage] 2010/09/25(土) 01:17:42 ID: Be:
    質問です.
    「
    int int1=10;
    int int2=20;
    」
    の文字列から任意のユーザ定義語(例えばint1, int2)だけ取り出したいのですが
    どんな風に書けばよいでしょうか?
    ちなみにC#のRegexでマッチさせたいと考えてます. 

507 デフォルトの名無しさん [sage] 2010/09/25(土) 01:40:26 ID: Be:
    >>506
    int[12]

    という冗談はさておき、厳密にやろうとしたら正規表現では無理。
    yacc(bison)でも使ったら? 

508 デフォルトの名無しさん [sage] 2010/09/25(土) 10:52:29 ID: Be:
    厳密にやるのは正規表現じゃ無理なのは確かだが、

    int¥s+(¥w+)¥s+=

    ぐらいでいけそうだけどな。自分用ならyaccのたぐいを
    持ち出すよりはお手軽だ。うまくいかなかったら調整
    すればいいし。

    人様に使わせるものならそういうわけにもいかないけど。

509 デフォルトの名無しさん [sage] 2010/09/25(土) 13:52:31 ID: Be:
    >507,508
    ありがとう

    正規表現で
    語(予約語+ユーザ低語)は
    [a-zA-Z_][a-zA-Z_0-9]*
    で多分抜き出せると思うが,
    抜き出した結果がintとかswitchとか予約後の場合
    マッチングの結果から取り除く,というのを正規表現だけで
    表現できませんか? 

510 デフォルトの名無しさん [sage] 2010/09/25(土) 15:15:31 ID: Be:
    >>509
    だからそういうのは正規表現向きじゃないって。
    C#なら、予約語リストを用意しておいてそれとマッチするかチェックすればいいじゃん。
    # 予約語をDBに入れたら検索も手抜きできるけど、そこまでするかどうかは別の問題 

511 デフォルトの名無しさん [] 2010/09/26(日) 01:05:10 ID: Be:
    javascriptです。
    (hoge|omg)|poo,muu
    例えばこんな文字列で、()に囲まれた|は無視して、|を見つけるとかはできるんでしょうか? 

512 デフォルトの名無しさん [sage] 2010/09/26(日) 08:46:31 ID: Be:
    \| 

513 デフォルトの名無しさん [sage] 2010/09/26(日) 09:35:47 ID: Be:
    正規表現は数を数えられない→括弧の対応をとることはできない

514 デフォルトの名無しさん [sage] 2010/09/26(日) 10:11:13 ID: Be:
    括弧は必ず正しく対応してるという前提で。
    \|(?![^\(]*\)) 

515 デフォルトの名無しさん [sage] 2010/09/26(日) 10:41:14 ID: Be:
    どうして正規表現=有限オートマトンにはできないことを
    やらせたがる奴が後を絶たないのだろう。ちょっとは
    まじめに勉強しろよ。そう難しい話じゃないんだからさ。

516 デフォルトの名無しさん [sage] 2010/09/26(日) 11:30:28 ID: Be:
    最近の拡張ではできちゃったりするからw 

あれ。プッシュダウンオートマトンって有限オートマトンではなかったんだっけ?

それはそれとして××を正規表現でって無理目なご希望は絶えませんねえ。

■_ Mutex と セマフォ

こんなのが。


Mutex vs. Semaphore
Mutex vs. Semaphore, what is the difference?

The Toilet Example  (c) Copyright 2005, Niclas Winquist ;)

Mutex:

Is a key to a toilet. One person can have the key - occupy the toilet - at the time. 
When finished, the person gives (frees) the key to the next person in the queue.

トイレの鍵。一度に一人がこのキーを持てて、そのトイレを占有できる。
使い終わったら、その人は鍵をキューの次の人にわたす。

Officially: "Mutexes are typically used to serialise access to a section of  
re-entrant code that cannot be executed concurrently by more than one thread. A mutex 
object only allows one thread into a controlled section, forcing other threads which 
attempt to gain access to that section to wait until the first thread has exited from 
that section."

Ref: Symbian Developer Library

(A mutex is really a semaphore with value 1.)

Semaphore:

Is the number of free identical toilet keys. Example, say we have four toilets with 
identical locks and keys. The semaphore count - the count of keys - is set to 4 at 
beginning (all four toilets are free), then the count value is decremented as people 
are coming in. If all toilets are full, ie. there are no free keys left, the semaphore 
count is 0. Now, when eq. one person leaves the toilet, semaphore is increased to 1 
(one free key), and given to the next person in the queue.

identical (同一形式とでもすればいいんだろうか) な複数のトイレの鍵。
「個室」を使うときにはひとつ鍵を持って行き、
使い終わったら鍵を戻す。
未使用の鍵が残っていればあいている「個室」のどれかは使えるけど、
残っていなければだめ。
ってな感じ?


Officially: "A semaphore restricts the number of simultaneous users of a shared 
resource up to a maximum number. Threads can request access to the resource 
(decrementing the semaphore), and can signal that they have finished using the 
resource (incrementing the semaphore)."

Ref: Symbian Developer Library

■_

まだまともに読んでないや(いちおー原著読んだし)。


推薦図書/必読書のためのスレッド 57 
850 デフォルトの名無しさん [sage] 2010/09/26(日) 17:01:07 ID: Be:
    『言語設計者~』もうAmazonで売ってるよ 

851 デフォルトの名無しさん [sage] 2010/09/26(日) 17:09:08 ID: Be:
    予約のみじゃん 

852 デフォルトの名無しさん [sage] 2010/09/26(日) 18:06:18 ID: Be:
    今日、本屋に並んでなかった。並ぶの明日だね。
    Amazonは販売中のようだ。 

853 デフォルトの名無しさん [sage] 2010/09/26(日) 18:46:59 ID: Be:
    >>852
    オライリーが25日だけどあれは通販のみで、本屋は遅いのか
    本屋で買おう 

854 デフォルトの名無しさん [sage] 2010/09/26(日) 19:10:58 ID: Be:
    開発者のインタビューって探せばありそうだな。まとめてあるのが良いんだろうけど 

855 デフォルトの名無しさん [sage] 2010/09/26(日) 19:16:24 ID: Be:
    今回のだと期待外れになる可能性もあるんで
    amazonで買うのはリスクが大きすぎる 

856 デフォルトの名無しさん [sage] 2010/09/26(日) 19:16:46 ID: Be:
    なんでRubyとかアホ言語を追記したんだ?
    意味がわからん 

857 デフォルトの名無しさん [sage] 2010/09/26(日) 19:42:43 ID: Be:
    >>856
    伝説のPHP作者「Rasmus Lerdorf」名言集を聞くと嫌PHP厨がファビョる
    http://anond.hatelabo.jp/20100427231539


    これを見たらRubyの作者を抜いてPHP作者を入れるべきだったということが分かる 

858 デフォルトの名無しさん [sage] 2010/09/26(日) 19:44:13 ID: Be:
    >>850
    目次見たが、JavaとSQL以外、実務で使われていない言語の設計者ばかりでひどいな 

859 デフォルトの名無しさん [sage] 2010/09/26(日) 19:50:24 ID: Be:
    >>858
    おまいが世間知らずなことを自己紹介せんでもええ 

860 デフォルトの名無しさん [sage] 2010/09/26(日) 19:51:07 ID: Be:
    >>857
    それ名言なのか。
    さんざんdisられて、ひねてるようにしか見えない。 

861 デフォルトの名無しさん [sage] 2010/09/26(日) 19:51:38 ID: Be:
    今のプロジェクトで6つ、経験したのなら9つあるが

    1章 C++(ビャーネ・ストラウストラップ)
    2章 Python(グイド・ヴァンロッサム)
    3章 APL(アディン・D・フォークオフ)
    4章 Forth(チャールズ・H・ムーア)
    5章 BASIC(トーマス・E・カーツ)
    6章 AWK(アルフレッド・エイホ、ピーター・ワインバーガー、ブライアン・カーニハン)
    7章 Lua(ルイス・エンリケ・デ・フィゲイレード、ロベルト・イエルサリムスキー)
    8章 Haskell(サイモン・ペイトン・ジョーンズ、ポール・ヒューダック、フィリップ・ワドラー、
    9章 ML(ロビン・ミルナー)
    10章 SQL(ドン・チェンバレン)
    11章 Objective-C(ブラッド・コックス、トム・ラブ)
    12章 Java(ジェームズ・ゴスリン)
    13章 C#(アンダース・ヘルスバーグ)
    14章 UML(イヴァー・ヤコブソン、ジェームズ・ランボー、グラディ・ブーチ)
    15章 Perl(ラリー・ウォール)
    16章 PostScript(チャールズ・ゲシキ、ジョン・ワーノック)
    17章 Eiffel(バートランド・メイヤー)
    18章 Ruby(まつもとゆきひろ)

862 デフォルトの名無しさん [sage] 2010/09/26(日) 19:53:23 ID: Be:
    C++もPythonも実務では使われてないのか 

863 デフォルトの名無しさん [sage] 2010/09/26(日) 20:21:08 ID: Be:
    >>861
    Tex入れてもよかったんじゃないかなぁ。
    ちょっと毛色が違うか。 

864 デフォルトの名無しさん [sage] 2010/09/26(日) 20:31:24 ID: Be:
    クヌースはもういいよ 

865 デフォルトの名無しさん [sage] 2010/09/26(日) 20:33:03 ID: Be:
    >>856
    原著でもリストに入っていたが、Matzのスケジュールの都合で見送られたんだよ。それが
    翻訳版で実現した。 

866 デフォルトの名無しさん [sage] 2010/09/26(日) 20:37:56 ID: Be:
    UMLやPostScriptがあるなら
    TeXあってもいいよな 

867 デフォルトの名無しさん [sage] 2010/09/26(日) 20:38:45 ID: Be:
    Rubyは原著には入ってないのかよw雑魚がwww 

868 デフォルトの名無しさん [sage] 2010/09/26(日) 20:44:49 ID: Be:
    small talkもないな。 

869 デフォルトの名無しさん [sage] 2010/09/26(日) 21:33:52 ID: Be:
    去年退団したからな 

870 デフォルトの名無しさん [sage] 2010/09/26(日) 21:37:22 ID: Be:
    >>862
    C++はゲームプログラマー、PythonはGoogle以外に使っている奴いるの?w 

871 デフォルトの名無しさん [sage] 2010/09/26(日) 21:39:44 ID: Be:
    そりゃいるだろう 

872 デフォルトの名無しさん [sage] 2010/09/26(日) 21:56:32 ID: Be:
    あまりに独断的でワロタ 

873 デフォルトの名無しさん [sage] 2010/09/26(日) 22:00:04 ID: Be:
    存命していて執筆引き受けてくれた言語設計者のリストなのかな。
    C、JavaScriptもなく、そしてLisp、Scheme、Pascalもないよね。
    そしてAPLがあるのに驚き。APL使うような人種はいまではMATLAB使っているような。 

874 デフォルトの名無しさん [sage] 2010/09/26(日) 22:04:11 ID: Be:
    そりゃそうだろとしかいいようが・・・ 

875 デフォルトの名無しさん [sage] 2010/09/26(日) 22:10:59 ID: Be:
    >868
    そもそもそんな言語はないからな 

876 デフォルトの名無しさん [sage] 2010/09/26(日) 23:03:50 ID: Be:
    masterminds of programmer 買ってみたが
    興味ない人にはいらないわな。 

877 デフォルトの名無しさん [sage] 2010/09/27(月) 00:07:29 ID: Be:
    >>873
    むしろこれだけの陣容を整えただけでも異常事態というべきで、
    多少漏れがあるのは仕方ないんでは
    デニス・リッチーとかガイ・スティールとかまで呼べたら
    確かに完璧以上だったのかもしれんけどね 

Lisp と Pascal、Tcl、Fortran と COBOL があれば。という感じでしょうか。 後ろ二つは無理筋ですが。

MATLAB って良く知らないのですが、APL を置き換えるものだったんですか。 … J は?

■_ 本日の巡回から

2010年09月25日

■_

・ダムエー
ジオングは出てこないし、ドロスはわけわかな移動するしどーなってんすか → 【 安彦良和】機動戦士ガンダムTHE ORIGIN 59号

・アフタ
むげにんお休み。 ヴィンランド・サガは…

TAPL読みましょうということで企画しました。 TAPL読書会@東京 第0回 : ATND 読もうということだけが決まっていて、そのほかはぜんぜん決まってません。 解説役や講師役できる方大歓迎。
Types and Programming Languages

こっちまでいくかどうかはまったく白紙。
Advanced Topics in Types and Programming Languages

■_

Ω→最後 つーことだろか。


Omega - Language of the Future | Lambda the Ultimate
Omega - Language of the Future

When I discovered Tim Sheard's Languages of the Future, I realized that PLs do indeed 
have a future (beyond asymptotically approaching CLOS and/or adding whimsical new 
rules to your type checker). Compared to languages like Lisp, pre-generics Java, and 
Python, the "futuristic" languages like Haskell and O'Caml seemed to mainly 
offer additional static verification, and some other neat patterns, but the "bang 
for the buck" seemed somewhat low, especially since these languages have their 
own costs (they are much more complex, they rule out many "perfectly fine" 
programs).

Ωmega seems like a true revolution to me - it shows what can be done with a really 
fancy typesystem, and this seems like the first astounding advancement over existing 
languages, from Python to Haskell. Its mantra is that it's possible to reap many (all?) 
benefits of dependent programming, without having to suffer its problems, by adding 
two much more humble notions to the widely understood, ordinary functional programming 
setting: GADTs + Extensible Kinds.

以下略

■_ セマフォと Mutex の違い

Mutex って Win32 APIで見たのが初めてだったなあ。たぶん。


Difference between binary semaphore and mutex. - Stack Overflow

Is there any difference between binary semaphore and mutex or they are essentialy same?
linux operating-system mutex semaphore glossary


They're semantically the same, but in practice you will notice weird differences 
(especially on Windows).


Mutex can be released only by thread that had acquired it, while you can signal 
semaphore from any other thread (or process), so semaphores are more suitable for some 
synchronization problems like producer-consumer.

One Windows binary semaphores are more like event objects then mutants.

The Toilet example is an enjoyable analogy:

    Mutex:

    Is a key to a toilet. One person can have the key - occupy the toilet - at the 
    time. When finished, the person gives (frees) the key to the next person in the
    queue.

    Officially: "Mutexes are typically used to serialise access to a section of 
    re-entrant code that cannot be executed concurrently by more than one thread. A mutex 
    object only allows one thread into a controlled section, forcing other threads which 
    attempt to gain access to that section to wait until the first thread has exited from 
    that section." Ref: Symbian Developer Library

    (A mutex is really a semaphore with value 1.)

    Semaphore:

    Is the number of free identical toilet keys. Example, say we have four toilets with
    identical locks and keys. The semaphore count - the count of keys - is set to 4 
    at beginning (all four toilets are free), then the count value is decremented as 
    people are coming in. If all toilets are full, ie. there are no free keys left, the 
    semaphore count is 0. Now, when eq. one person leaves the toilet, semaphore is 
    increased to 1 (one free key), and given to the next person in the queue.

    Officially: "A semaphore restricts the number of simultaneous users of a 
    shared resource up to a maximum number. Threads can request access to the resource 
    (decrementing the semaphore), and can signal that they have finished using the 
    resource (incrementing the semaphore)." Ref: Symbian Developer Library

At a theoretical level, they are no different semantically. You can implement a mutex 
using semaphores or vice versa (see here for an example). In practice, the 
implementation is different and they offer slightly different services.

The practical difference (in terms of the system services surrounding them) is that 
the implementation of a mutex is aimed at being a more lightweight synchronisation 
mechanism. In oracle-speak, mutexes are known as latches and semaphores are known as 
waits.

At the lowest level, they use some sort of atomic test and set mechanism. This reads 
the current value of a memory location, computes some sort of conditional and writes 
out a value at that location in a single instruction that cannot be interrupted. This 
means that you can acquire a mutex and test to see if anyone else had it before you.

A typical mutex implementation has a process or thread executing the test-and-set 
instruction and evaluating whether anything else had set the mutex. A key point here 
is that there is no interaction with the scheduler, so we have no idea (and don't care) 
who has set the lock. Then we either give up our time slice and attempt it again when 
the task is re-scheduled or execute a spin-lock. A spin lock is an algorithm like:

Count down from 5000:
     i. Execute the test-and-set instruction
    ii. If the mutex is clear, we have acquired it in the previous instruction 
        so we can exit the loop
   iii. When we get to zero, give up our time slice.

When we have finished executing our protected code (known as a critical section) we 
just set the mutex value to zero or whatever means 'clear.' If multiple tasks are 
attempting to acquire the mutex they the next task that happens to be scheduled after 
the mutex is released will get access to the resource. Typically you would use mutexes 
to control a synchronised resource where exclusive access is only needed for very 
short periods of time, normally to make an update to a shared data structure.

A semaphore is a synchronised data structure (typically using a mutex) that has a 
count and some system call wrappers that interact with the scheduler in a bit more 
depth than the mutex libraries would. Semaphores are incremented and decremented and 
used to block tasks until something else is ready. See Producer/Consumer Problem for a 
simple example of this. Semaphores are initialised to some value - a binary semaphore 
is just a special case where the semaphore is initialised to 1. Posting to a semaphore 
has the effect of waking up a waiting process.

A basic semaphore algorithm looks like:

(somewhere in the program startup)
Initialise the semaphore to its start-up value.

Acquiring a semaphore
   i. (synchronised) Attempt to decrement the semaphore value
  ii. If the value would be less than zero, put the task on the tail of the list
      of tasks waiting on the semaphore and give up the time slice.

Posting a semaphore
   i. (synchronised) Increment the semaphore value
  ii. If the value is greater or equal to the amount requested in the post at the front
      of the queue, take that task off the queue and make it runnable.  
 iii. Repeat (ii) for all tasks until the posted value is exhausted or there are no
      more tasks waiting.

In the case of a binary semaphore the main practical difference between the two is the 
nature of the system services surrounding the actual data structure.

EDIT: As evan has rightly pointed out, spinlocks will slow down a single processor 
machine. You would only use a spinlock on a multi-processor box because on a single 
processor the process holding the mutex will never reset it while another task is 
running. Spinlocks are only useful on multi-processor architectures.
They are NOT the same thing.

Mutual Exclusion semaphores are used to protect shared resources (data structure, file, 
etc..). Binary Semaphore can be used to signal that something has happened.

While both types of semaphores have a full/empty state, their usage is very different. 
Also, a Mutex semaphore is "owned" by the task that takes it. A binary 
semaphore is not. Here are a few examples: Mutex

  Thread A                     Thread B
   Take Mutex
     access data
     ...                        Take Mutex  

Binary Semaphore

   Task A                       Task B
   ...                           Take BinSemaphore   <== wait for something noteworthy
   Do Something Noteworthy
   Give BinSemaphore             Take action    <== unblocks

Note that with a binary semaphore, it is OK for B to take the semaphore and A to give 
it. This could not happen with a Mutex. If B takes the mutex and A attempts to give it, 
A will get an error.

訳をつけてるよゆーがなっしんぐ。

■_

もうひとつ reddit から

stubborn → 頑固な,強情な,一徹な,片意地な,ひねくれた


Why are people so stubborn about Vim? : programming

Why are people so stubborn about Vim? (code.alexreisner.com)


    His successful conversion happened like this: he got MacVim, installed NERDTree, 
    used his mouse, and stayed mostly in insert mode. As the days went by he learned new 
    commands and gradually became more productive.

    If you’re a hardcore Vim user no doubt you’re leaning over to throw up in your 
    trash can right now.

I use vim, have for over a decade. I think it's the best editor out there, bar none. I 
don't judge him for how he uses it. It really doesn't enter my mind to care.

I've never seen these hardcore vim zealots that seem to cause people like the author 
such nervousness.

shrug Intetubes, I guess. Maybe somewhere there's some hardcore "OMG NO YOU MUST 
USE VIM PROPERLY" guy, but I've never met him, or seen him online.


Preface: I use vim for almost everything. Sometimes TextPad. I guess I'm a 
"hardcore" vim user. I don't give two shits what editor people use as long 
as it works for them. That said, some of his complaints are not even really applicable 
to vim. Namely:

    But along with Vim comes a dogmatic, somewhat macho, insistence that the only way 
    to use it is with the alphanumeric part of the keyboard. No mouse, no arrow keys.

If you properly configure a terminal, you can use the arrow keys, home, end, pgup, 
pgdn. I fucking HATE pure home-row navigation, I mean who wants to have to hit escape 
every time they want to move up or down a line? The whole point of the 
"improved" part of vim was to get past the rather crippling limitations of 
normal VI, like the navigation. It seems as though most of his complaints are centered 
around this "dogma", which is not a limitation of the app, but more a 
limitation of a certain subset of its users.

You don't have to go full-blown mouse navigation to at least get some sort of 
usability out of vim. The same goes for text selection.

    But moving blocks of text constitutes a significant portion of my work and I 
    always had a hard time doing it quickly in Vim.

I guess it really depends on what sort of blocks of text you end up moving. I do this 
quite a bit in vim, and using either v, CTRL-v, or ALT-v, I find that I can more 
precisely pick exactly what characters I want to grab without worrying about having to 
be particularly precise with the mouse. If I want one or two more characters, I don't 
have to concentrate really hard on my mouse movements, I just hit the arrow key a 
couple times. I find it so natural to select text in this way that I'll rarely go for 
the mouse in other apps too, I just use the shift key and arrow keys or pgup/dn to 
select what I want.

Lastly, I find it incredibly ironic that he spends the first half of the article 
bitching about vim, and the second half bitching about people who bitch about things.

何でこんなに盛り上がるんだろう…

■_

↑の火元。


Vim Heresy [Alex Reisner]

I don't expect anyone to like this article.

Nevertheless, I feel it needs to be written.

I first used Vi about 18 years ago. I thought it was pretty weird, but it was the only 
text editor I knew of on Unix so I learned the basics. My main editor, however, has 
always been one with a “normal” GUI (EditPlus, Gedit, etc). I've tried, on probably 
eight different occasions, to make Vi/Vim/Gvim my main tool, each time learning a 
little more, picking up my .vimrc from where I left off, but never successfully making 
the switch.

Until now.

以下略

■_ ポインター

ポインタを理解できないプログラマはもういらない /a>
71 仕様書無しさん [sage] 2010/09/25(土) 09:21:12 ID: Be:
    とりあえず6502でいいからアセンブラ書いてみ。
    全部ポインタの概念使うから。

    個人的にはポインタとlambda算法を理解してないヤツとは一緒に仕事はしたくねぇ。
    お荷物なのが明白だからさ。 

6502 やればまあ、ポインターがどういうものかってのは良くわかるだろうなあ。

λ算法理解しているかと問われるとあまり自信ない ○| ̄|_

■_ 本日の巡回から

■_

F# のあれ、メモを入力してまとめなおす余裕がががが。

2010年09月24日

■_

・十字軍物語1読了。 ずいぶんと少ない人数での征服行だったんだなあ。 まあ十万単位の軍勢をほいほい出せるかというと難しいんだろうけど。 しかし炎天下をあの格好で進軍する十字軍を想像するとちょっと笑えた。
十字軍物語〈1〉

・小説フランス革命
王の逃亡―小説フランス革命〈5〉 (小説フランス革命 5)
↑ をまだ読み終わってないのに(つーか積んでる)、次が出てしまった
フイヤン派の野望 小説フランス革命6 (小説フランス革命 6)

■_ boxing →

VB開発者のためのポリモーフィズム(多態性)入門 - @IT

さらに、参照型であるクラスだけでなく、値型であっても、Objectに変換することができます。
このように、値型をObjectに変換することをボックス化(ボクシング)と呼びます。逆に、ボッ
クス化されたObjectを値型に戻すことを、ボックス化解除(アンボクシング)と呼びます。

ボックス化の概要は、次の図のようになります。数値型変数aをボックス化すると、一時的にメ
モリ領域が確保され、そこにaの値5がコピーされます。Object型変数には、その領域のアドレス
が代入されるというわけです。

んーーーー、boxing/unboxing をボックス化/ボックス化解除ってやっぱ変だと思うんだがなあ。 そーすっとカプセル化あたりもひっかかるんだけど。

■_

■_

ちょっと前のですが。

だだもれ
http://www.page.sannet.ne.jp/hirasho/diary/diary1009.html#19p5

javaは参照型と値型の区別が問題だ。 intと自作クラスの何が違うのかを初心者はちゃんと理解
できているのだろうか。 そのへんが曖昧な状態でプログラムを書いてる奴が山ほどいるんじゃ
ないかと 怖くなる。新人が「javaやってました」と言った時は大抵信用できないという 話を聞
くが、たぶんそのへんだろう。 私が思うにjavaの利点は、そのへんを気にしなくてもプログラ
ムが書けることであって、 そのへんがわかっていなくてもプログラムが書けることではない。 
「気にしなくて済むから生産性が高い」は真だろうが、 「わからなくても書けるから生産性が
高い」は絶対嘘だ。 その二つをごっちゃにしてる奴が山ほどいるんじゃないかと怖くなる。

  
javaを作った奴は、C++などのそれ以前の言語の事を良く知った上で、 その欠点を改良しようと
思ってそれを作ったわけだ。 pythonだろうがjavaだろうがC#だろうが、 言語を作った奴はそれ
以前の言語のことを良く知っているはずなのである。 同時に、その言語が登場した時に、それ
に目をつけて使い出した人達もまた、 古い言語のことを良く知っていたはずだ。 そういう「わ
かっている人達」が、 「メモリを意識しながらプログラミングするなんて非効率だ」 みたいな
台詞を吐いたとして、それを額面通り受けとっていいものだろうか。 彼等はメモリを意識しな
がらプログラミングできるスキルを持った上で、 それを意識しなくてもプログラミングできる
という選択肢ができたことを 喜んでいるのだ、という文脈を踏まえれば、 それを初心者が額面
通りに受け取るのは間違いだということが すぐわかるはずである。 "


  

参照型とプリミティブな値型があるおかげで、call by value と call by reference が混乱したり。 ってこれは Java だけじゃないか。

Java の言語仕様やライブラリがなぜあのようになったのか。 ってのは追いかけてみたいんだけど、まとまった資料あるだろうか。 C++ でいう D & E のような。

■_

■_

Schneier on Security: Four Irrefutable Security Laws
September 20, 2010
Four Irrefutable Security Laws
(irrefutable →反論できない、反駁できない)

This list is from Malcolm Harkins, Intel's chief information security officer, and 
it's a good one (from a talk at Forrester's Security Forum):

  1. Users want to click on things.

  2. Code wants to be wrong.

  3. Services want to be on.

  4. Security features can be used to harm.

His dig at open source software is just plain dumb, though:

   Harkins cited mobile apps: "What kind of security do we think is in something 
   that sells for 99 cents? Not much."

Comments

Err, according to the article that's not what he said. He was specifically aiming at 
99 cent mobile apps - in other words commercial, closed source software written 
cheaply and quickly to get a high volume of products onto the app stores to take 
advantage of the short-attention-span market.

I think it's probably a fair comment that such a development cycle does not foster 
high security.

なんかマーフィーの法則的な。

■_ ネタ


スレッドを立てるまでもない質問雑談スレ41 
753 仕様書無しさん [sage] 2010/09/22(水) 03:09:20 ID: Be:
    ぶった切ってすまんけど、
    デスクトップをディスクトップって言う言うやついるじゃない?
    あれはかっこつけてるんだろうか?

    殴っていいのかな? 

754 仕様書無しさん [] 2010/09/22(水) 03:15:35 ID: Be:
    ディスクトップのスロットルにグラボを刺してドライバーをインストロールするのです。 

757 仕様書無しさん [sage] 2010/09/22(水) 11:28:51 ID: Be:
    >>753
    てめークトップディスってんのか 

758 仕様書無しさん [sage] 2010/09/22(水) 19:54:02 ID: Be:
    >>753
    デスクトップの綴りはdesktop
    eはイーって発音するでしょ?
    だから本当はディスクトップのほうが近い

    本職のキャメラマンがキャメラのことを絶対にカメラと発音しないのと同じ
    俺らはプロのITプロフェッショナルなんだからディスクトップの事を
    デスクトップなんて発音したらとても恥ずかしいことだよ 

759 仕様書無しさん [sage] 2010/09/22(水) 20:23:44 ID: Be:
    ネタなのかマジなのか判断つかん
    Dellもディルなんだろうか 

760 仕様書無しさん [sage] 2010/09/22(水) 20:28:11 ID: Be:
    >>758 desk の発音記号書いてみろw 

761 仕様書無しさん [sage] 2010/09/22(水) 21:12:13 ID: Be:
    >>760
    アメリカ人が発音記号なんて知ってるわけないじゃんm9 

762 仕様書無しさん [] 2010/09/22(水) 23:36:45 ID: Be:
    desk の発音記号は desk の e の上に ` が付いてるやつじゃないか? 

763 仕様書無しさん [sage] 2010/09/23(木) 12:45:50 ID: Be:
    >>761
    いや、デスクで発音はあってるから
    Diskと区別つかないし、Diskとな発音もあきらかに違う
    い、よりも、え、の方ご発音に近い 

765 仕様書無しさん [sage] 2010/09/23(木) 13:22:46 ID: Be:
    >>758 の理論だと a は `エイ ' と発音するから、カメラはキャメラではなくケイメラとなる。 

2010年09月23日

■_

・またひとり
横浜ベイスターズ - ニュース - 9/21(火)木塚選手が引退を表明

・個人的には
「個人的には~」という言い回しが好きじゃない。なぜかというと(省略されました)

・読んだ
発明のコモンズ〜サービスイノベーションとオープンイノベーションを促進するための知的財産制度〜 (創成社新書44)

■_ プログラマーは

arrogant → 横柄な、尊大な、無礼な


Why are so many programmers arrogant? - Programmers - Stack Exchange

Not all programmers are arrogant but most are even quiet, why?

全員が、というわけではないけれども、プログラマーって大半が態度でかくないっすか? 的な。

Are you saying it to me ?? – systempuntoout Sep 17 at 9:10

To quote Scott Adams in Dilbert Principle:

"In contrast to 'normal' people, engineers have rational objectives for social interactions:
(1) Get it over with as soon as possible;
(2) Avoid getting invited to something unpleasant;
(3) Demonstrate mental superiority and mastery of all subjects."

It is our nature. We want to be always right. We know we are always right.
The problem is this:

The world that programmers inhabit is a Boolean one - it resists shades of grey whilst 
embracing black-and-white thinking. Often we choose programming because we're 
constitutionally inclined to dichotomous thinking, and this is reinforced by our 
professional practice. This has a number of problems:

   1. We tend to think that any given viewpoint must either be true or false, correct 
      or incorrect.

   2. When we encounter two points of view, we assume that at least one is wrong.

   3. We often put a lot of thought into our own opinions, and so we assume that our 
      own opinion is the correct one.

   4. Other people often seem less logical than us, so we assume that other people are 
      often wrong.

   5. We're generally quite intelligent people, so we are actually right about things 
      quite often. This reinforces our conviction that we're likely to be right on any 
      given occasion.

   6. We're often more concerned with arguments and ideas than we are with people's 
      feelings, so we present our ideas in a way that others perceive as arrogant.

The important thing, however, is that I'm absolutely right about what I've said here. 
I must be. After all, I'm a programmer ;-)
The wild programmer (Scriptus exemplarus aspergerii) is generally a shy creature when 
in its natural habitat. While some deviant boisterous specimens do exist, they are the 
oddity rather than the rule.

He is content with spending his life staring at rectangular pieces of backlit canvas, 
and occasionally bashing on rectangular pieces of polished material. Come to think of 
it, most of his activities revolve around rectangles: the rectangular nutrient clumps 
he tends to favor eating, the rectangular primitive communication device he always 
carries around, the beige or black boxes he is so attached to, even organizing his 
workspace into cubes.

The programmer's activity involves stringing together symbols in intricate patterns 
which they place on their canvases, obeying complicated self-imposed rules. They are 
inevitably proud of their symbols and compare them among each other to advance in the 
hierarchy. Some deem their symbols so valuable that they never show them to another, 
while others do the same for fear their symbols are not up to par.

Amongst themselves, they can quickly sense when someone is inferior to the standards 
they uphold, and most often attempt to enlighten less gifted peers; the same less 
gifted peers will often not take that kindly and, in a surprising twist, both consider 
the other group arrogant and come off as arrogant themselves.

When taken out of his natural habitat however, the programmer is utterly confused and 
sees the world around him as a great challenge. Anything that does not conform to the 
patterns clearly laid out in his symbols is deemed illogical and useless, which causes 
concern among humans (which is an entirely different species, despite the similarities). 
He will often try to improve various aspects of the world around him using the methods 
learned when dealing with symbols, and usually fail; however, his failure only gives 
him reason to point out that he actually acted correctly, and that outside influences 
(which are usually humans) are to blame for everything that goes wrong. This usually 
has the side effect of the same humans considering the programmer arrogant or stupid.

When dealing with programmers it is best to avoid upsetting them; however that may not 
prove an easy task, as their minds work very differently from those of other species. 
The best defense is to arm yourself with a modicum of information about symbols (you 
don't have to understand them yourself) or even better, about specific symbols written 
by famous programmers. It's enough to mention them to calm him down and make him go 
into a lot of detail on why those symbols are completely wrong and his are better. 
This is especially useful if you happen to remember symbols from a dialect that is 
opposed or otherwise dissonant to the programmer's natural one (like C-SHARP 
[ˈsi.ˈʃaɾp] versus JAVA [ˈdʒavɐ]), although in some specimens it can also produce 
bouts of rage.

Also remember that due to his peculiar habits, programmers have a hard time 
reproducing and as such they are considered an endangered species. Efforts to 
instigate them to reproduce (much like in the case of giant pandas, Ailuropoda 
melanoleuca) have been mostly met with failure. So try to be kind to them, as they are 
generally docile and not a danger unless provoked by displays of misplaced affection 
or (what they would deem as) illogical thinking.

Programmers are part of our heritage and we should do our best to preserve this 
wondrous species for future generations.

©TLDR Inc.

    “Being a creator of software systems is like being a god. Only without the omnipotence,
      omnipresence or omniscience.”

            — Brent Snook (@brentsnook)

Arrogance for a programmer it's not a luxury but a necessity.

Larry Wall in his famous book Programming Perl said:

3 Virtues of a Programmer are:

   1. Lazines
   2. Impatience
   3. Hubris--Excessive pride, the sort of thing Zeus zaps you for. Also the quality
      that makes you write (and maintain) programs that other people won't want to
      say bad things about.

I wish all programmers would be like Larry Wall.

If I recall though, Larry Wall meant this in terms of driving force. If programmers 
are exceptionally proud of the work that they do, then they will ensure that that work 
is of the utmost quality. This doesn't mean "be proud of your work so that you 
can be an asshole to other people" :) 

Arrogance is often an indication of incomplete social skills. Like any other skills, 
social skills need to be learned and practiced and that takes time (10000-hours rule).

Most of programmers chose to spend their 10000 hours on learning programming. The same 
can be said about astronomers, authors and - unfortunately - doctors.

And given that programming as a profession constantly evolves and we have to relearn 
and reinvent the skill sets, I would suggest that even after the initial 10000 hours 
are spent, there is still better return on investment by spending extra time on 
programming than on the multiple hours required to get even 'basic' social skills 
right.

Of course, if 'people' skills become part of the deliverables, we often have to learn 
them and do learn them. I had to do tech-support for 3 years and it really did push 
some social skills on me. People now have troubles believing I really am an introvert.
I'm a programmer and I fully agree, if a doctor told you about your medical problems 
in medical jargon and treated you like an idiot for not understanding you would call 
him arrogant, most of my colleagues seem to believe that because they know the meaning 
of certain buzzwords and acronyms they're somehow superior to everyone else. It's also 
not as if any of it is really that hard to understand. Everyone would know what a 
"front-end" is if explained in plain English (or whatever your tongue may be) 
but that would demystify the entire thing.

I've seen clients make horrible business decisions, not because they didn't know what 
they wanted but because none of the tech types would explain to them in simple terms 
what exactly they'd be getting one way or another. To continue with the medical 
analogy that's like explaining with some jargon that a patient would be better off if 
he just had the leg amputated instead of putting a band aid on the wound and the 
patient trusting the experts advice.

I love programming but I hate most programmers I come in contact with exactly for that 
reason. What I think is hilarious though is that the most of the more skilled 
programmers I've come in contact with have this a lot less than the ones who got a 
degree and haven't learned anything useful since (but are still convinced that they 
know best). It seems a universal truth in business that the loudest ones make the 
rules, not the smartest ones.

Programmers are arrogant because we're the most clever people in the world.


In all honestly, I don't think it's just programmers that are arrogant, if you look at 
pretty much any career where you are able to step back at the end of the day point at 
something and say "I made that." you find at lot of arrogant people. This 
tends to be a bit worse in fields where the skills needed to succeed are not something 
that can be learned.

Furthermore, I think that programmers and those in IT tend to get a harder wrap 
because it's still a new career field and people are still getting used to the idea 
that computers are hear to stay and that in someways they are like cars - you might be 
able to fix them, but you need to go to a specialist if you have any really hard 
problems.

Who is not arrogant? Programmers? Physicists? Mathematicians? Doctors? Arrogance is 
there in every one of them.

This is just a gross generalization that programmers are arrogant, possibly because 
today posing clever arguments and humbling others and showing off your accumulated 
information as knowledge gives people kicks.

例によって適当に抜き出しました。

■_

~ed


【Perl,PHP】LLバトルロワイヤル12【Ruby,Python】 
130 デフォルトの名無しさん [sage] 2010/09/22(水) 09:34:20 ID: Be:
    Pythonはその堅さを求めて使うものって感じじゃね
    Rubyはササッと書くにはあのフリーさが丁度いいんだが
    ゴリゴリ拡張されると別言語になっちまう 

131 デフォルトの名無しさん [sage] 2010/09/22(水) 11:48:15 ID: Be:
    最初からかっちり書く奴には大差がないということ? 

132 デフォルトの名無しさん [sage] 2010/09/22(水) 13:26:48 ID: Be:
    最初からかっちり書くならどっちもどっちじゃね 

133 デフォルトの名無しさん [sage] 2010/09/22(水) 14:18:58 ID: Be:
    最初からカッチリ書くならpythonが楽に決まってんだろ 

134 デフォルトの名無しさん [sage] 2010/09/22(水) 14:35:51 ID: Be:
    pythonはカッチリしか書けないけど、rubyはカッチリ書く事もフリーで書く事もできるって感じかな。 

135 デフォルトの名無しさん [sage] 2010/09/22(水) 15:24:33 ID: Be:
    Railsが現れて頭のブレーキが外れた感があるなw 

139 デフォルトの名無しさん [sage] 2010/09/22(水) 17:22:24 ID: Be:
    >>133
    そんなことはない。俺カッチリ派だけどRubyの方が綺麗に書けると思う。楽さは
    同じか、わずかにRubyのが楽。

    Pythonは普通の関数が前面に出てくるのがいやだ。特にreversed()とlist.reverse()は
    許せん。前に誰か書いてたかもしれんけど、nose.tools.assert_equalとかも許せん。 

140 デフォルトの名無しさん [sage] 2010/09/22(水) 18:04:47 ID: Be:
    問題はカッチリじゃないコードが混じる可能性を考慮した場合なんだよね
    Rubyもみんなカッチリ書くなら大丈夫なんだが
    Pythonほど、そこの強制力がない 

141 デフォルトの名無しさん [sage] 2010/09/22(水) 18:07:17 ID: Be:
    >>139
    なんで、そんなことが許せないの? 

142 デフォルトの名無しさん [sage] 2010/09/22(水) 18:28:10 ID: Be:
    >>139
    たぶん君は 'delim'.join(lst) も許せないんだろうね 

143 デフォルトの名無しさん [sage] 2010/09/22(水) 18:41:38 ID: Be:
    >>140
    rubyはフリーとカッチリのどちらでも書けるから、みんなが同意しないと混じる可能性があるけど、
    pythonはカッチリしか書けないからこそ強制力があって、混じる可能性が無い

    ということじゃないかと思ったのだけど....。
    (pythonは詳しくないんで、漏れが間違って認識してるのだろうか?) 

144 デフォルトの名無しさん [sage] 2010/09/22(水) 18:49:10 ID: Be:
    ちなみに、

    reversed(a)というのは、aはシーケンスで、aの要素の順番を逆順に並べかえた新しいシーケンスを返す関数
    a.reverse()というのは、aはシーケンスで、aそのもの要素の順番を逆順に並び替えるメソッド

145 デフォルトの名無しさん [sage] 2010/09/22(水) 19:18:56 ID: Be:
    >>143
    pythonが書き方が一通りというのは幻想 

146 デフォルトの名無しさん [sage] 2010/09/22(水) 19:31:20 ID: Be:
    >>145
    うーみゅ、幻想なのか....。

    でも、そうだとすると「pythonは堅い(>>129,130)けどカッチリしていない言語」ってことなのかな。
    「堅い」と「カッチリ」は同じ性質を表していると思ってたけど、なんか混乱してきたw 

147 デフォルトの名無しさん [sage] 2010/09/22(水) 19:34:57 ID: Be:
    Rubyにはpublic, private, protectedの呼び出し制限があるけど
    Pythonは全部publicですから 

152 139 [sage] 2010/09/22(水) 23:23:48 ID: Be:
    >>140
    カッチリ書くことを推奨する文化はあると思うけど、強制ってのはありえん。
    import re; re.compile = 'hogehoge'
    これやれば一発で終了よ。

    >>141
    過去形と現在形だから。命名規則が謎い。名前かぶったからそうしたとしか思えない。
    あと、もいっこはassert_equalごときでimportだるい。かといってデフォのは使いたくない。

    >>142
    それは許せる。むしろRubyのArray#joinがいつも文字列を返すことの方が疑問に感じる。
    全部+して返すってのがいいと思ってるんだけど。

    >>143
    強制する言語はJavaだよ。Pythonはシンプルで明確さを求めるけど、あんまり強制みたいのはない。

    >>147
    その点に関しては実はPythonのが優れてる。Rubyのprivateはサブクラスから呼べるから、
    本物のprivateじゃない。Pythonの_は規約でprotected、__はクラス名で名前修飾するから
    継承階層での名前衝突の可能性が大幅に減少する。実質本物のprivateに近い。
    _がprotectedという規約はPythonistaならみんな知ってるはずだから、うっかり呼び出すなんて
    ことはないはず。Rubyのprivateはリファクタとかして、スーパークラス側でメソッドを切り出した
    ときに、サブクラスと衝突する可能性がある。

    >>149
    自分でも言ってるけど、それはRailsのルールを知らないだけでしょ。規約を覚えて従う
    ことで、保守性が向上するのがRails。まあ、Railsはたまに使う人のためのフレームワークでは
    ないと思う。ああ、Railsの実装の可読性が最悪なのには同意するw 

153 141 [sage] 2010/09/22(水) 23:28:53 ID: Be:
    >>152
    命名規則に関しては、元々reverse()メソッドしかなくて、
    ちょっとそいつは不便だよ、
    って話でreversed()が2.3で追加されたって経緯がある。
    その経緯を知っている俺なんかは全く違和感ないけど、
    後から覚えた人から見れば、違和感あるのかね?

    importに関しては何でもimportしなきゃならないのが、むしろPythonのいいところ。 

154 152 [sage] 2010/09/22(水) 23:43:03 ID: Be:
    >>153
    ああ、そうなんだ。情報thx
    名前ぐらい慣れればないだろうけど、それは洗脳されてるだけだよねって感じかな。

    assert_equalに関しては同意できない。何故なら、ほとんどテストクラスの中で使う
    ことが確定してるから。やはり、selfが面倒くさかったとしか思えない。

    ああ、似たので思い出したけど、TGのexpose系もおかしいよ。
    ぜったいコントローラの中で使うじゃん。意味的に考えて、スーパークラスに定義されているべき。
    無理だけど。

    関数であるべきものをimportするのは良いけど、メソッドであるべきものをimportするのはイヤ。 

183 デフォルトの名無しさん [sage] 2010/09/23(木) 12:34:23 ID: Be:
    >>139
    ls.reverse()はls自体を並べ替えろっていう「命令形」。
    reversed(ls)はls自体を並べ替えるんでなく、逆順に並べ替えたlsをくれって関数。完了形。 

184 デフォルトの名無しさん [sage] 2010/09/23(木) 13:12:30 ID: Be:
    >>183
    Rubyなら
    ・ls.reverse!()  <-- reverse!()は命令
    ・new_ls = old_ls.reverse()  <-- reverse()は関数
    になるけど、こちらのほうが自然だろってことかな。それなら自分は納得だけど。 

185 デフォルトの名無しさん [sage] 2010/09/23(木) 13:22:30 ID: Be:
    >>183
    細かいことだが、reversedって完了形というより過去分詞/受動態じゃないの?

    >>184
    命令/関数云々というより、単に破壊的操作には!をつけるという
    Lisp系の命名規則の影響と思われ
    自然というか、少なくとも分かりやすいね 

188 デフォルトの名無しさん [sage] 2010/09/23(木) 13:54:44 ID: Be:
    >>185
    受動態じゃなくて過去分詞の副詞的用法 

189 デフォルトの名無しさん [sage] 2010/09/23(木) 13:55:53 ID: Be:
    ああすまん
    過去分詞の形容詞的用法
    か 

sorted とかの名前が気になってたんだけど、183 の説明を見て納得。 いやまあ原形の名前を使うわけにいかない(被るから)ってのはあったんだろうけど。

■_ 本日の巡回から

実は二日分だったり。

■_ ここ数日

関数型言語は何故普及しないのかを考える [chaika] このスレの勢いが結構あるような。 投稿しているのは割りと少人数じゃないかという気はするのだけど。 いくつか興味深い意見もあった。

2010年09月22日

■_

あとで書く
開演直前 幻? の表紙 サインいただきました

■_

■_

2010年09月21日

■_

カラオケで河島英五でも唄いたい気分。

・これはないw
http://img.thedailywtf.com/images/200902/errord/DSC00669.JPG ネタ元は Please don't use floating-point types for currency values : programming

■_ switch case

C言語なら俺に聞け(入門編)Part 69 
424 デフォルトの名無しさん [sage] 2010/09/21(火) 12:12:27 ID: Be:
    switchのコストってcaseの数をnとしたらO(n)ですか?
    それともランダムジャンプみたいなことしてO(1)になるんでしょうか? 

425 デフォルトの名無しさん [sage] 2010/09/21(火) 12:21:50 ID: Be:
    O(log n)だったりO(1)だったりコンパイラの気分次第
    O(n)はアホすぎるだろう 

426 デフォルトの名無しさん [sage] 2010/09/21(火) 12:24:29 ID: Be:
    最適化でジャンプテーブル O(1) か二分探索 O(log n) になるんじゃないかな 

427 デフォルトの名無しさん [sage] 2010/09/21(火) 12:25:39 ID: Be:
    >>424
    条件で変わるだろうから一概には言えないと思う。
    多段ifみたいに一条件ずつチェックするならO(n)かもしれないけれど、
    nがある程度大きければcase値とジャンプ先のテーブルになるだろうからnの探索時間でO(log2(n))かな。
    さらにnが取り得る値の数に充分近いならジャンプテーブルだけになるからO(1)になると思う。

428 デフォルトの名無しさん [sage] 2010/09/21(火) 13:52:40 ID: Be:
    でも今時のCPUはパイプラインが深いからジャンプテーブルを使うとコードは
    短くなるけどパイプラインバブルが発生して結局遅くなるんだけどな

    それでも条件分岐が外れる事によるパイプラインバブルの発生確率を考えると
    賢い選択かもしれない

    どうせ分岐予測なんて当たらないだろうし 

429 デフォルトの名無しさん [sage] 2010/09/21(火) 15:16:59 ID: Be:
    二分探索に最適化って本当にしてんの? 

430 デフォルトの名無しさん [sage] 2010/09/21(火) 15:58:06 ID: Be:
    そんな大量のswtich-caseを見たことがないからなんとも言えないけど、
    逆に言えばそんなケースは多くないだろうからやってない可能性が高いなぁ。
    普通はO(n)でも充分実用だと思うし。 

431 デフォルトの名無しさん [sage] 2010/09/21(火) 16:01:02 ID: Be:
    >>429
    してる。けど、最近のVC(VS)だけだと思う。
    gccとかはやってないんじゃないかな。 

432 デフォルトの名無しさん [sage] 2010/09/21(火) 16:04:59 ID: Be:
    gccだってそれくらいはやるよ 

433 デフォルトの名無しさん [sage] 2010/09/21(火) 16:10:30 ID: Be:
    >>432
    ごめん、知らなかった。

    ちなみにgcc4以降とかですか?
    gcc(3.x系)が二分探索吐いたの見たことないんですが。
    あるいは特別不可解なオプション? 

434 デフォルトの名無しさん [sage] 2010/09/21(火) 16:19:14 ID: Be:
    >>433
    なんもオプション付けてないです gcc -S a.c だけ
    試したのは gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
    コードは http://codepad.org/lohGRGWw
    出力は http://codepad.org/1ZKAvhyw 

435 デフォルトの名無しさん [sage] 2010/09/21(火) 16:30:58 ID: Be:
    >>434
    なってますね。手元でも確認しました。
    ある程度case値が分散してないとならないようですね。まぁ当たり前か。 

436 430 [sage] 2010/09/21(火) 16:33:00 ID: Be:
    んじゃ、私も前言撤回。やるもんだ。 

437 デフォルトの名無しさん [sage] 2010/09/21(火) 16:36:28 ID: Be:
    gcc様すいませんでした。 

438 デフォルトの名無しさん [sage] 2010/09/21(火) 18:25:00 ID: Be:
    gcc様すいませんでした。 

439 デフォルトの名無しさん [sage] 2010/09/21(火) 18:26:31 ID: Be:
    gcc様すいませんでした。 

440 デフォルトの名無しさん [sage] 2010/09/21(火) 18:46:33 ID: Be:
    なんだかんだ言ってもswitchに実行効率を期待するのはジジイ系のバッドノウハウ 

441 デフォルトの名無しさん [sage] 2010/09/21(火) 20:55:25 ID: Be:
    大昔のMS Cは、等差数列で分岐が7以上だったらテーブルになってた > switch 


前世紀の Oh! X って雑誌で switch case でどういうコードを吐くかとか調べた記事があったような。 当時の gcc は 1.x だったけど、それでも定数の畳み込みだとかこの swich case とかは かなり頑張ったコードを吐いていたと思います。 比較対照だった XC がちと可哀想だったな(笑) とはいえループアンローリングなんかと同じで、 プロセッサが進化するとそれまで有効だった最適化手法が効果なくなったり、 逆効果にさえなったりすることがあるからなあ。

■_ 気力が尽きた

ぼちぼちあとで手を入れます○| ̄|_


Call By Object

Call By Object
オブジェクトによる呼び出し


    “When I use a word, Humpty Dumpty said, in a rather scornful tone, it means just
      what I choose it to mean, neither more nor less.

    The question is, said Alice, whether you can make words mean so many different things.

    The question is, said Humpty Dumpty, which is to be master ? that's all.”

From time to time, people who've read a little CS but not a lot CS (or too much of
just one kind of CS) pop up on comp.lang.python and waste a lot of energy trying to
tell everyone that Python's using some calling model that it doesn't really use. It
always turns out that they don't really understand Python's model, and quite often,
they don't understand their favourite model either.

ときおり、多少はコンピューター科学に触れているがそれほどでもない
(あるいはコンピューター科学のある特定のものだけをやりすぎている) 人たちが
comp.lang.python を pop up して、
皆に Python が使っている一部の calling model が実際に使っているものではないことを
説明しようと多大な労力を支払っています。
それは常に彼らが Python のモデルを本当には理解していないことを露にしているのです。
そして、とても頻繁に、彼らが自分たちの好んでいるモデルのいずれも理解していない
こともはっきりさせてしまうのです。
#かなりアヤシイ

But nevermind, the only thing you need to know is that Python's model is neither
“call by value” nor “call by reference” (because any attempt to use those terms
for Python requires you to use non-standard definitions of the words “-value” and
“-reference”). The most accurate description is CLU's “call by object” or “call
by sharing“. Or, if you prefer, “call by object reference”.

しかし忘れないでほしいのは、あなたが知っておく必要のある唯一つのことは Python で使われ
ているモデルは“値渡し”(call by value。値による呼び出し) でもなければ“参照渡し”
(call by reference。参照による呼び出し) でもないということです (なぜならこれらの語を
Python に対して使おうとすることは、“-value”や“-reference”という語の non-standard 
な定義を使うことをあなたが求められることになるからです)。最も accurate な記述は CLU の 
“call by object”(オブジェクトによる呼び出し)もしくは“call by sharing”(共有による呼
び出し) です。あるいは、あなたがいいと思うのなら “call by object reference”(オブジェクト参
照による呼び出し) になります。

You should also read this, if you haven't done so already.

this → http://effbot.org/zone/python-objects.htm

The following excerpts are taken from an old comp.lang.python thread. The interesting
parts are the CLU texts, which provide a very concise description of Python's calling
model.

以下で引用しているのは過去の comp.lang.python のスレッドにあったものです。
興味深いのは CLU texts の部分で、Python の呼び出しモデルを very concise に表しています。

(Some day, I'll turn this into a proper article…)


Date: Wed, 14 May 2003 08:48:08 +0200

> See
>
>   http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?call-by-value
>
> What you describe is call-by-value.

It's interesting that you quote FOLDOC, given that FOLDOC doesn't
refer to Python's model as call-by-value, as can be seen in the CLU
entry:

    http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?CLU

    "Arguments are passed by call-by-sharing, similar to
    call-by-value, except that the arguments are objects
    and can be changed only if they are mutable."

    引数は call-by-sharing によって渡されます。これは call-by-value に似ていますが、
    引数がオブジェクトであり、それらが mutable であるときにのみ変更できる点が異なります


Note the use of the words "similar" and "except".

For a brief description of CLU's object and argument passing models, see [1].
I think you'll find that it matches Python's model pretty well.

CLU のオブジェクトや引数の引き渡しモデルの簡単な説明については文献 [1] を
参照してください。


The CLU Reference Manual [2] by Liskov et al says (page 14):

    "We call the argument passing technique _call by sharing_,
    because the argument objects are shared between the
    caller and the called routine.  This technique does not
    correspond to most traditional argument passing techniques
    (it is similar to argument passing in LISP).  In particular it
    is not call by value because mutations of arguments per-
    formed by the called routine will be visible to the caller.
    And it is not call by reference because access is not given
    to the variables of the caller, but merely to certain objects."

    わたしたちはこの引数引き渡し技法 (argument passing technique) を 「call by sharing」
    と呼びます。それは引数オブジェクトが呼び出し側と呼び出されたルーチンとで共有される
    からです。この手法は大部分の traditional な引数引き渡し技法とは対応しません (LISP
    における引数渡しと似ているものです)。ことに、呼び出し先のルーチンで行われた引数に対
    する mutations が呼び出し元にも反映されることから、これは call by value ではありませ
    ん。そしてこれは call by reference でもありません。なぜなら、アクセスが呼び出し側の
    変数に対してではなく、単に特定のオブジェクトに対するものだからです。
    Note the use of "does not" and the repeated use of "it is not".
    Let me emphasise:

    "IN PARTICULAR IT IS NOT CALL BY VALUE because mutations
    of arguments performed by the called routine will be visible to
    the caller. And IT IS NOT CALL BY REFERENCE because access
    is not given to the variables of the caller, but merely to certain
    objects."

    呼び出されたルーチンでの引数に対する mutations が呼び出し元ルーチンからも可視であることから、
    これは「値による呼び出しではありません」。また、呼び出し元の変数に対するアクセスが与えられる
    わけではなく、単に(変数の実体である)オブジェクトへのアクセスが与えられることから
   「参照による呼び出しでもありません」。

CLU was designed in the mid-seventies, and this reference manual
was published in 1979.  In other literature, the CLU designers some-
times refer to this model as "call by object" [3], or they carefully
ignore the issue by talking about "objects" instead of values, and
"objects that refer to other objects" instead of references [1], but
I cannot find a single place where they've gone from "in particular
it is not call by value" to "it is call by value".

CLU は1970年代中ごろに設計されたものであり、このマニュアルは1979年に出版されたものです。
In other literature,
the CLU designers some-times refer to this model as
"call by object" [3],
CLU の設計者はこのモデルを時には "call by object" [3] とし、
or they carefully ignore the issue by talking about "objects" instead of values,
and "objects that refer to other objects" instead of references [1],
but I cannot find a single place where they've gone from
"in particular it is not call by value"
to "it is call by value".


So what's your excuse for being stuck in the early seventies? ;-)

</F>

1) http://www.cs.berkeley.edu/~jcondit/pl-prelim/liskov77clu.pdf
2) http://www.lcs.mit.edu/publications/pubs/pdf/MIT-LCS-TR-225.pdf
3) http://www.lcs.mit.edu/publications/pubs/pdf/MIT-LCS-TR-561.pdf



Date: Wed, 14 May 2003 15:49:09 +0200

> Also interesting that [call-by-sharing] is missing

did you read the "Why is this definition missing?" page?

(the FOLDOC maintainers add links to articles that should be written
some day, and keeps track of how many clicks the links get, so they
can focus on things that people really want to read about)

> For a good intro to semantics, I sugest
>
>   Essentials of Programming Languages
>   Daniel P. Friedman, Mitchell Wand, Christopher Thomas Haynes

if all you have is scheme, etc.

> I'm not familiar with CLU

I suggest reading reference 3.

    http://www.lcs.mit.edu/publications/pubs/pdf/MIT-LCS-TR-561.pdf

CLU is an important milestone in the development of OO languages;
to quote Liskov herself, from the above paper:

CLU はオブジェクト指向言語の開発における重要な milestone です。
先の論文から Liskov 自身の言葉を引用すると

    "The work on CLU, and other related work such as that on
    Alphard, served to crystallize the idea of a data abstraction
    and make it precise. As a result, the notion is widely used as
    an organizing principle in program design and has become a
    cornerstone of modern programming methodology."

if you don't know your history, etc.

> but I think this description of Python's argument-passing semantics is misleading.

did you read reference 1?

    http://www.cs.berkeley.edu/~jcondit/pl-prelim/liskov77clu.pdf

in case your PDF reader is broken, here are the relevant portions from
that document (any typos etc added by me).

    "The basic elements of CLU semantics are _objects_ and
    _variables_.  Objects are the data entities that are created and
    manipulated by CLU programs.  Variables are just the names used
    in a program to refer to objects.

    CLU の semantics の基本となる要素 (basic elements) は「オブジェクト」(objects)
    と「変数」(variables) です。オブジェクトは CLU プログラムによって生成され操作さ
    れるデータ実体 (data entities) です。変数はプログラム中でオブジェクトを参照する
    ために使われる単なる名前です。

    In CLU, each object has a particular _type_, which characterizes
    its behavior.  A type defines a set of operations that create
    and manipulate objects of that type.  An object may be created
    and manipulated only via the operations of its type.

    CLU では各オブジェクトはその振る舞いを characterizes する特定の「型」を持ってい
    ます。型はその型のオブジェクトの生成と操作の set of operations を定義します。
    オブジェクトはその型の operations と通じてのみ生成されたり操作されたりします。

    An object may _refer_ to objects.  For example, a record object
    refers to the objects that are the components of the record.
    This notion is one of logical, not physical, containment.  In
    particular, it is possible for two distinct record objects to
    refer to (or _share_) the same component object.  In the case of
    a cyclic structure, it is even possible for an object to
    "contain" itself.  Thus it is possible to have recursive data
    structure definitions and shared data objects without explicit
    reference types. /.../

    オブジェクトはオブジェクトを「参照する」ことが許されます。たとえばある record
    オブジェクトはそのレコードの components であるオブジェクトを参照します。この
    notion は one of logical, not physical, containment です。さらに、二つの異なる
    record オブジェクトが同一の component オブジェクトを参照(もしくは共有)すること
    が可能です。循環構造 (cyclic structure) の場合、自分自身を「含む」オブジェクト
    に対してさえ参照や共有が可能です。
    したがって、再帰的なデータ構造を定義したり explicit な参照型抜きで
    shared data オブジェクトを持つことが可能です。/.../

    CLU objects exist independently of procedure activations.  Space
    for objects is allocated from a dynamic storage area /.../ In
    theory, all objects continue to exist forever.  In practice, the
    space used by an object may be reclaimed when the object is nolonger
    accessible to any CLU program.

    CLU のオブジェクトは procedure activations とは独立して存在します。オブジェクト
    のためのスペースは動的ストレージ空間から割り当てられます /.../
    理論的には、すべてのオブジェクトは永遠に存在し続けます。実際にはあるオブジェクト
    によって使用されている空間はそのオブジェクトがもはやどの CLU プログラムからもア
    クセスされなくなったときに reclaimed される可能性があります。


    An object may exhibit time-varying behavior.  Such an object,
    called a _mutable_ object, has a state which may be modified by
    certain operations without changing the identity of the
    object. /.../

    オブジェクトは time-varying behavior を exhibit することが許されます。そのよ
    うなオブジェクトは「mutable」オブジェクトと呼ばれ、オブジェクトの identity を
    変更することなしに certain operations によって modify することが許される状態
    を持っています。

    If a mutable object _m_ is shared by two other objects _x_ and
    _y_, then a modification to _m_ made via _x_ wil be visible when
    _m_ is examined via _y_.  /.../

    もし mutable オブジェクト _m_ が異なる二つのオブジェクト _x_ と _y_ とに共有さ
    れていたならば、_x_ を通じて行われた _m_ に対する変更は _y_ を通じて _m_ を見
    た場合にも観測されるでしょう。

    Objects that do not exhibit time-varying behavior are called
    _immutable_ objects, or constants.  Examples of constants are
    integers, booleans, characters, and strings.  The value of a
    constant object can not be modified.  For example, new strings
    may be computed from old ones, but existing strings do not
    change.  Similarily, none of the integer operations modify the
    integers passed to them as arguments.

    time-varying behavior を exhibit していないオブジェクトは「immutable」オブジェク
    トもしくは constants と呼ばれます。constatns の例には、integers, booleans,
    characters, strings があります。constant オブジェクトの値は変更できません。
    たとえば新しい strings は古いものから computed されるかもしれません。しかし既存の
    strings は変更されません。同様に、引数として渡された integers を変更する integer
    operation は存在しません。


    Variables are names used in CLU programs to _denote_ particular
    objects at execution time.  Unlike variables in many common
    programming languages, which _are_ objects that _contain_
    values, CLU variables are simply names that the programmer uses
    to refer to objects.  As such, it is possible for two variables
    to denote (or _share_) the same object.  CLU variables are much
    like those in LISP and are similar to pointer variables in other
    languages.  However, CLU variables are _not_ objects; they
    cannot be denoted by other variables or referred to by
    objects. /.../

    変数とは CLU プログラムが実行時に特定のオブジェクトを「示す」(denote) ために使う
    名前です。「値を保持するオブジェクトである」 many common programming languages
    における変数とは異なり、CLU の変数はオブジェクトに対する参照としてプログラマー
    が使う単なる名前です。そういうことなので、二つの変数が同一のオブジェクトを示す
    (もしくは「共有」)することも可能です。CLU の変数は LISP における変数のようなも
    のであり、その他の言語におけるポインター変数に似ています。ただし、CLU の変数は
    オブジェクトでは「ありません」。CLU の変数は他の変数で示すことができませんし、
    オブジェクトから参照することもできません。

    The basic actions in CLU are _assignment_ and _procedure
    invocation_.  The assignment primitive 'x := E' where _x_ is a
    variable and _E_ is an expression, causes _x_ to denote the
    object resulting from the evaulation of _E_.  For example, if
    _E_ is a simple variable _y_, then the assignment 'x := y'
    causes _x_ to denote the object denoted by _y_.  The object is
    _not_ copied, it will be _shared_ by _x_ and _y_.  Assignment
    does not affect the state of any object.  (Recall that 'r.s :=
    v' is not a true assignment, but an abbreviation for 'put.s(r,
    v)'.)

    CLU における basic actions は 「代入」(assignment) と「手続きの起動」(procedure
    invocation) です。「x」が変数であり、「E」が式であるときの 'x := E' という
    assignment primitive は「x」が「E」を評価した結果としてのオブジェクトを denote させます。
    たとえば 「E」が単純変数「y」であったとすると、'x := y' という代入は「x」が 「y」
    によって denote されるオブジェクトを denote するようにします。そのオブジェクトは
    コピー「されず」、「x」と「y」とで「共有」されます。代入はどんなオブジェクトの状態
    にも影響しません ('r.s := v' が本当の代入ではなく、'put.s(r, v) に対する省略形
    (abbreviation) であることを思い出してください)。

    Procedure invocation involves passing argument objects from the
    caller to the called procedure and returning result objects from
    the procedure to the caller.  The formal arguments of a
    procedure are considered to be local variables of the procedure
    and are initialized, by assignment, to the objects resulting
    from the evaluation of the argument expressions.  Thus argument
    objects are shared between the caller and the called procedure.
    A procedure may modify mutable argument objects (e.g. records),
    but of course it cannot modify immutable ones (e.g. integers).
    A procedure has no access to the variables of its caller.

    手続き起動は、呼び出し元から呼び出し先手続きへ渡される引数オブジェクトと
    呼び出し先手続きから呼び出し元へ返される結果オブジェクトを involves します。
    手続きのformal arguments はその手続きの局所変数としてみなされ、
    引数式 (argument expressions) の評価の結果オブジェクトを
    代入することによって初期化されます。
    したがって、引数オブジェクトは呼び出し側と呼び出された手続きとの間で共有されます。
    手続きはmutable な引数オブジェクト (たとえば records) を変更することは許されますが、
    immutalbe オブジェクト(たとえば integers) を変更することは当然のことですができません。
    手続きはその呼び出し元の変数に対するアクセス手段を持ちません。

    Procedure invocations may be used directly as statements; those
    that return objects may also be used as expressions.  Arbitrary
    recursive procedures are permitted."

    手続き起動は式として使われることも許されるオブジェクトを返す
    文 (statements) として直接使うことが可能です。
    Arbitrary recursive procedures are permitted.

replace "CLU" with "Python", "record" with "instance", and "procedure"
with "function or method", and you get a pretty accurate description
of Python's object model.

"CLU" を "Python" に、"record" を "instance" に、
"procedure" を "function or method" に置き換えると、
you get a pretty accurate description of Python's object model.

if you don't agree, please tell us what Python does differently.  be very specific.

もしあなたがこれに納得いかないのなら、どうかわたしたちに Python がどのように
異なっているのかを、very specific に説明してください。

</F>



Date: Thu, 15 May 2003 15:55:57 +0200

Tim Peters wrote:

> So it goes -- believe it or not, sometimes different people mean different
> things by the same words <wink>.

that's why you should use URLs and URLs only to identify concepts.

> The business of warping "call by value" to mean "the internal address of
> the object is the value" doesn't seem common even in the functional world,
> though.

well, I guess you can, in theory, value an artificial number assigned
to an object as much as the object itself.

    "Joe, I think our son might be lost in the woods"
    "Don't worry, I have his social security number"

</F>



Date: Thu, 15 May 2003 23:11:53 +0200

> No, that's exactly what call-by-value means when applied to Python values
> (actually r-values).  What happens when you try this:
>
> >>> y = [1, 2, 3]
> >>> x = y
> >>> x[:] = [-1]*3
> >>> y
> [-1, -1, -1]
>
> Same behavior, no function calls.

except that "x[:] =" *is* a method call.

"x[:] =" は「メソッド呼び出し」ですから除外されます。

x[:] = [-1]*3 passes a slice object and the result of ([-1]*3) to the x.__setitem__
method, using the standard calling mechanism (that's what the "the object is
asked" stuff in the language ref means)

x[:] = [-1]*3 は、通常の呼び出し機構を使って ([-1]*3) の結果を x.__setitem__ に
スライスオブジェクトを渡します
(that's what the "the object is asked" stuff in the language ref means)。

"x.y =" is also a method call (__setattr__).

"x.y =" もまた (__setattr__に対する) メソッド呼び出しです。

so is "x[y] =" (__setitem__, again).

"x[y] =" もそうです (これは __setitem__ を呼び出します)。

however, "x = y" isn't.

しかし "x = y" はそうではありません。

(and thirty years ago, CLU also had syntactic sugar that looked
like assignments for the uninformed observer, but really was yet
another way to call a procedure.  nothing new here.)

そして30年前、CLU も uniformed observer に対する代入のように見えるけれども、
実際には手続き呼び出しの yet another なやり方であるような 構文糖
(syntactic sugar) を持っていました。新しいものはここには何もありません。

</F>


Date: Thu, 15 May 2003 23:39:30 +0200

> According to Joshua, me and R5RS.  R5RS says
>
> "When the procedure is later called with some actual
> arguments, the environment in which the lambda expression
> was evaluated will be extended by binding the variables
> in the formal argument list to fresh locations, the
> corresponding actual argument values will be stored
> in those locations, and the expressions in the body
> of the lambda expression will be evaluated sequentially
> in the extended environment."
>
> That's call-by-value by definition.

but that's not how Python works.

しかしそれは Python の動作とは異なるものです。

in Python, the variables in the formal argument list are bound to the actual argument
objects.  the objects are _shared_ between caller and callee; there are no
"fresh locations" or extra "stores" involved.

Python では、仮引数リストにある変数群は実引数オブジェクトに束縛されます。
そのオブジェクトは呼び出し元と呼び出し先とで「共有」されます。
呼び出しに際して
"fresh locations" や extra "stores" が involved されることはありません。


(which, of course, is why the CLU folks called this mechanism "call-by-sharing".
and they were real computer scientists, working for a real computer science laboratory ;-)

and btw, Python functions doesn't run in an extended environment,
either.  function bodies have very limited access to the surrounding
environment.  but that's another story.

</F>

Date: Fri, 16 May 2003 00:25:45 +0200

> It's only here that I disagree with you.  I consider Python values
> themselves to be object references

if you keep inventing your own terminology, you'll never win this argument:

    http://www.python.org/doc/current/ref/objects.html

    "Objects, values and types"

    _Objects_ are Python's abstraction for data. All data in a
    Python program is represented by objects or by relations
    between objects.

    「オブジェクト」は Python でのデータの抽象化です。
    Python プログラムにおけるすべてのデータはオブジェクトもしくは
    オブジェクト間の関係によって表現されます。

    Every object has an identity, a type and a value. An object's
    _identity_ never changes once it has been created; you may
    think of it as the object's address in memory. /.../ An object's
    _type_ is also unchangeable. It determines the operations that
    an object supports (e.g., ``does it have a length?'') and also
    defines the possible values for objects of that type. /.../ The
    _value_ of some objects can change. Objects whose value can
    change are said to be _mutable_; objects whose value is un-
    changeable once they are created are called _immutable_.

    すべてのオブジェクトは identity と type、値を持っています。
    オブジェクトの「identity」は、一度生成された後は決して変更されることはありません。
    identity をオブジェクトのメモリ空間でのアドレスと考えることもできます。/.../
    オブジェクトの「type」もまた変更不可能です。



(this is basically the same terminology as in the CLU papers, except
that they used the term "state" instead of Python's "value")

...so I guess what you've been saying all the time is that Python
uses call-by-identity, not call-by-state.  fair enough.

</F>



Date: Fri, 16 May 2003 01:05:37 +0200

> This is a description of call-by-value using CLU values (object references).

so?  if, in doug-speak, object references are the same thing as
values, that's also a description of call-by-object-reference.

is your point that you can redefine words to make them mean
whatever you want?  I think we've already noticed that...

</F>

■_ 本日の巡回から


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

ホームへ


Copyright (C) 2010 KIMURA Koichi (木村浩一)
この文書の無断転載はご遠慮ください(リンクはご自由にどうぞ)。

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