エスカレーターで
狭い通路でも頑として並んで歩いているカップルが
エスカレーターにさしかかるや一列に(二人並ぶだけの幅は十分にあります)。
恐るべしエスカレーター(違)
2012年夏のプログラミング・シンポジウム
以前から翻訳作業がなされているという話は洩れ伝わってきていましたが
わりと広く知られるイベントがあった模様。
日本語版でるまでに読書会完走できるかしらん ○|￣|＿
おや?
PFSD も途中で放置してるなあ(読書会も…)
この二つどこが違うんだろ?
版が改まったにしては時期の差がそれほどではないし、
ハードカバーとペーパーバックなら値段の差が?
あら、
ペーパーバック: 232ページ
ハードカバー: 232ページ
飽きたのでこの辺で投げるw
Why OO Sucks by Joe Armstrong
Why OO Sucks by Joe Armstrong
なぜオブジェクト指向は××なのか
(Note: This is a copy of the original that used to live at http://www.bluetail.com/~joe/vol1/v1_oo.html )
When I was first introduced to the idea of OOP I was skeptical but didn't know why -
it just felt "wrong". After its introduction OOP became very popular (I will
explain why later) and criticising OOP was rather like "swearing in church".
OOness became something that every respectable language just had to have.
最初にオブジェクト指向プログラミングの考えを intoroduce したとき
わたしは懐疑的だったのですが、それがなぜかはわかりませんでした。
ただ単に「間違っている」と感じたのです。
オブジェクト指向プログラミングが非常にポピュラーなものになり
(それがなぜかは後で説明します)、
criticising OOP was rather like "swearing in church" のあとでは
オブジェクト指向性 (OOness) は rspectable なプログラミング言語すべてが
持っていなければならないものとなりました。
As Erlang became popular we were often asked "Is Erlang OO" - well, of
course the true answer was "No of course not" - but we didn't to say this
out loud - so we invented a serious of ingenious ways of answering the question that
were designed to give the impression that Erlang was (sort of) OO (If you waved your
hands a lot) but not really (If you listened to what we actually said, and read the
small print carefully).
Erlang がポピュラーなものになるにつれ、
わたしたちはしばしば「Erlang はオブジェクト指向プログラミング言語なのか」という
質問を頻繁に受けるようになりました。
もちろんそれに対する回答は "No of course not" でしたが、
わたしたちはそれを直接大声で主張することはせず
so we invented a serious of ingenious ways of answering the question that
were designed to give the impression that Erlang was (sort of) OO (If you waved your hands a lot)
but not really (If you listened to what we actually said, and read the small print carefully).
ですからわたしたちは発明しました
その質問に回答する
serious of ingenious way
を
Erlang はオブジェクト指向(の一種)ではあるけれども
そのものではない
At this point I am reminded of the keynote speech of the then boss of IBM in France
who addressed the audience at the 7th IEEE Logic programming conference in Paris. IBM
prolog had added a lot of OO extensions, when asked why he replied:
ここでわたしが
IBM prolog はたくさんのオブジェクト指向拡張を追加されていて
それがなぜかと尋ねられたときに彼はこう返しました
"Our customers wanted OO prolog so we made OO prolog"
我々の顧客がオブジェクト指向 prolog を望んだ。であるから我々はオブジェクト指向 prolog を作ったのだ
I remember thinking "how simple, no qualms of conscience, no soul-searching, no asking
"Is this the right thing to do" ...
Why OO sucks
なぜオブジェクト指向は(略)なのか
My principle objection to OOP goes back to the basic ideas involved, I will outline
some of these ideas and my objections to them.
Objection 1 - Data structure and functions should not be bound together
異論 1 データ構造と関数は一緒にまとめるべきではない
Objects bind functions and data structures together in indivisible units. I think this
is a fundamental error since functions and data structures belong in totally different
worlds. Why is this?
オブジェクトは独立した unit の中で関数とデータ構造とを一緒に結び付けます。
わたしはそれが根本的な過ち (fundamental error) であると確信しています。
なぜなら関数とデータ構造は根本的の異なる世界に属するものだからです。
なぜこうなっているのでしょうか?
Functions do things. They have inputs and outputs. The inputs and outputs are data
structures, which get changed by the functions. In most languages functions are built
from sequences of imperatives: "Do this and then that ..." to understand
functions you have to understand the order in which things get done (In lazy FPLs and
logical languages this restriction is relaxed).
関数は仕事をします。関数には入力と出力があります。関数の入力と出力はデータ構造であり、
関数によって変化するものです。大部分のプログラミング言語では、関数は「これをやって、
次にあれをやって…」といった命令の並びから構成されています。
関数を理解するためにはそういった命令がどのような順番で行われるのかを理解しなければなりません
(lazyな関数プログラミング言語や論理プログラミング言語ではこの制限は緩和されます)。
Data structures just are. They don't do anything. They are intrinsically declarative.
"Understanding" a data structure is a lot easier than "understanding" a
function.
データ構造は単に存在しています。
データ構造はなにもしません。
データ構造は intrinsically declarative です。
「データ構造を理解すること」は「関数を理解すること」よりもずっと易しいことです。
Functions are understood as black boxes that transform inputs to outputs. If I understand the
input and the output then I have understood the function. This does not mean to say that I could
have written the function.
関数は入力を出力へと変換するブラックボックスとして理解されます。
もしわたしが入力と出力とを理解していればその関数を理解していします。
これはその関数を記述ということは意味していません。
Functions are usually "understood" by observing that they are the things in a computational
system whose job is to transfer data structures of type T1 into data structure of type T2.
関数は通常、型 T1 のデータ構造を型 T2 のデータ構造へと変換する働きをする
computational システムにおける things であるということを
observing することにより「理解」されます
Since functions and data structures are completely different types of animal it is
fundamentally incorrect to lock them up in the same cage.
関数とデータ構造とは完全に異なる動物なのですから、同じ檻 (cage) に放り込むことは
根本的に間違っていること (fundamentally incorrect) なのです。
Objection 2 - Everything has to be an object
異論 その2 すべてがオブジェクトでなければならない
Consider "time". In an OO language "time" has to be an object. But
in a non OO language a "time" is a instance of a data type. For example, in
Erlang there are lots of different varieties of time, these can be clearly and
unambiguously specified using type declarations, as follows:
「時間」について考えてみましょう。
オブジェクト指向言語においては「時間」はオブジェクトであるべきものです。
しかし、非オブジェクト指向の言語においては「時間」はあるデータ型のインスタンスです。
たとえば Erlang では時間について a lots of differnt varieties があって、
以下のような type declarations を使った明快かつ曖昧さのない指定が可能になっています。
-deftype day() = 1..31.
-deftype month() = 1..12.
-deftype year() = int().
-deftype hour() = 1..24.
-deftype minute() = 1..60.
-deftype second() = 1..60.
-deftype abstime() = {abstime, year(), month(), day(), hour(), min(), sec()}.
-deftype hms() = {hms, hour(), min(), sec()}.
...
Note that these definitions do not belong to any particular object. they are
ubiquitous and data structures representing times can be manipulated by any function
in the system.
これらの定義がなんら特定のオブジェクトに属していないということに注意してください。
これらの定義は ubiquious (どこにでもある) なものであり、
データ型はシステムに存在する任意の関数によって操作が可能な時間を表現しています。
There are no associated methods.
データ型に結び付けられたメソッドはありません。
Objection 3 - In an OOPL data type definitions are spread out all over the place
異論 3 オブジェクト指向言語におけるデータ型の定義はすべての場所に spread out される
In an OOPL data type definitions belong to objects. So I can't find all the data type
definition in one place. In Erlang or C I can define all my data types in a single
include file or data dictionary. In an OOPL I can't - the data type definitions are
spread out all over the place.
オブジェクト指向プログラミング言語における型定義はオブジェクトに属します。
そのため、一箇所ですべてのデータ型の定義を見つけるということができません。
Erlang や C では、自分のすべてのデータ型をひとつの include file だとか
data directionary で定義できます。
オブジェクト指向プログラミング言語ではそれはできません。
オブジェクト指向プログラミング言語におけるデータ型の定義は
all over the place に spread out してしまうのです。
Let me give an example of this. Suppose I want to define a ubiquitous data structure.
ubiquitous data type is a data type that occurs "all over the place" in a system.
ひとつ例を出します。ある ubiquitous なデータ構造を定義したかったとしましょう。
その ubiquitous なデータ型は、あるシステムにおいて "all over the place" に
登場するデータ型です。
As lisp programmers have know for a long time it is better to have a smallish number
of ubiquitous data types and a large number of small functions that work on them, than
to have a large number of data types and a small number of functions that work on them.
Lisp プログラマーが昔から知っているように、
少数の ubiquitos なデータ型とそれに対して作用する多数の小さな関数を持つことは、
多数のデータ型とそれに対して作用する少数の関数を持つことよりも良いのです。
A ubiquitous data structure is something like a linked list, or an array or a hash
table or a more advanced object like a time or date or filename.
ubiquitous なデータ構造は linked list だとか、あるいは配列、ハッシュ、テーブル、
さらには時間だとか日付、ファイル名のような、もっと高度なオブジェクトのようなものです。
In an OOPL I have to choose some base object in which I will define the ubiquitous
data structure, all other objects that want to use this data structure must inherit
this object. Suppose now I want to create some "time" object, where does
this belong and in which object...
オブジェクト指向プログラミング言語では、自分が定義する ubiquitous な data structure を
使うためにほかのすべてのオブジェクトがそれを継承しなければならないようななんらかの
base object を選択しなければなりません。
わたしがそういった役割を果たす "time" オブジェクトを作りたいと仮定しましょう
Objection 4 - Objects have private state
異論 4 オブジェクトは private な状態を持っている
State is the root of all evil. In particular functions with side effects should be avoided.
状態とは諸悪の根源 (root of all evil) です。特に副作用を伴う関数は排除すべきものです。
While state in programming languages is undesirable, in the real world state abounds.
I am highly interested in the state of my bank account, and when I deposit or withdraw
money from my bank I expect the state of my bank account to be correctly updated.
プログラミング言語における状態とは undesirable なものでありますが、現実世界は状態に囲まれています。
わたしは自分の銀行口座の状態にとても関心がありますし、
銀行口座に入金したり、あるいは口座から引き出したときには
自分の口座の状態が正しく更新されることを期待します。
Given that state exists in the real world what facilities should programming language
provide for dealing with state?
OOPLs say "hide the state from the programmer". The states is hidden and visible
only through access functions.
オブジェクト指向プログラミング言語は「状態をプログラマーから隠している」と主張しています。
状態は隠蔽され、アクセス関数を通してのみ見ることが可能です。
Conventional programming languages (C, Pascal) say that the visibility of state variables is
controlled by the scope rules of the language.
(C や Pascal のような) conventinal なプログラミング言語は状態変数の可視性 (visibility) は
言語のスコープ規則によって制御されると主張しています。
Pure declarative languages say that there is no state.
純粋な宣言型プログラミング言語は状態は存在しないと主張しています。
The global state of the system is carried into all functions and comes out from all
functions. Mechanisms like monads (for FPLs) and DCGs (logic languages) are used to
hide state from the programmer so they can program "as if state didn't matter"
but have full access to the state of the system should this be necessary.
グローバルなシステムの状態はすべての関数に carried into されまたすべての関数から comes out されます。
関数プログラミング言語のためのモナドや
論理プログラミング言語のための DCG はプログラマーから状態を隠すために用いられていて、
「状態が問題でないかのように」プログラムできますが、
state of the system へのフルアクセスを持っています。
The "hide the state from the programmer" option chosen by OOPLs is the worse
possible choice. Instead of revealing the state and trying to find ways to minimise
the nuisance of state, they hide it away.
オブジェクト指向プログラミング言語によって選択された
"hide the state from the programmer" option
(「プログラマーから状態を隠すという」選択) は非常に悪いものです。
状態を revealing (露出させる? )したり
nuisance of state を最小化する手段を探そうとするのではなく、
状態を隠してしまっています。
Why OO was popular?
なぜオブジェクト指向は popular だったのでしょうか?
Reason 1 - It was thought to be easy to learn.
学習が簡単であると考えられた
Reason 2 - It was thought to make code reuse easier.
コードの再利用を簡単にすると考えられた
Reason 3 - It was hyped.
Reason 4 - It created a new software industry.
新しいソフトウェア industry を作り出した
I see no evidence of 1 and 2. Reasons seem to be the driving force behind the technology.
If a language technology is so bad that it creates a new industry to solve problems of its
own making then it must be a good idea for the guys who want to make money.
わたしは 1 と 2 の証拠となるものを見たことがありません。
理由はテクノロジーの背後に隠された driving force のようです。
もしある言語テクノロジーが自分が作った問題を解決するための新しい industry を作り出すほどに
悪いものであるのなら、それは金儲けをしたい連中にとっては優れた考えであるに違いありません。
This is is the real driving force behind OOPs.
これこそが、オブジェクト指向プログラミングの背後にある本当の driving force なのです。
