(原文: OOP Isn't a Fundamental Particle of Computing)
この25年にわたるプログラミングで最も大きい変化は今日、あなたが役に立つ、柔軟なデータ型を操作するということです、そして、25年前、あなたは自分自身でそれらのデータ型を造ることに無駄に高い時間を費やしました。
当時の標準言語 である、CとPascal は、少しの機械指向の型を提供しました：数、ポインタ、配列、文字列の空想、複数の値を結びつけるレコードまたは構造体。そして、より面白い型(スタック、木、連結リスト、ハッシュテーブル、リサイズ可能な配列)のようなより面白い型を設計するためにこれらの基本型を使うことが重要でした。
PerlまたはPythonまたはErlangにおいて、私はこのものについて考えません。彼らがどれくらいの要素を含むか、また、データがどこから来るか心配することなく、リストと文字列と配列を使います。私は辞書を使うときに、そのサイズやハッシュの衝突がどのように操作されるかといったような詳細について時間を費やすことはありません。
私はまだ新しいデータ型を必要とします、しかし、カスタム解決を巧みに作るより、すでにそこにあるものを再利用することが多いです。任意の次元のベクトルは、配列です。RGBカラーは、3つの要素の組です。多項式は、各値が係数で、インデックスを次元とする組、か、ペア{係数, 次元} のリストです。私が大学で取ったデータ構造コースから、重労働を、配列と組とリストと辞書がとり除いてしまったのには驚きです。バランスした木を実装するときの焦点はバランスした二分木がどのように働くかであり、もつれ合ったポインタ操作の苦しみではない。
新しい何かへ既製の建築用ブロックを配置する方法を考えることは、それが最初に現れるより急進的に変わります。それらの建築用ブロック自体が生まれる方法は、もはや主要な懸念でありません。多くのプログラミング・コースとチュートリアルでは、オブジェクトとコンストラクタと抽象基本クラスとプライベートメソッドといった、言葉の突然の減速バンプがあります。それから次の宿題で、RGBカラーを表す単純な3つ組は、ゲッターとセッターと複数のコンストラクタと ― 最も悪いことに ― もっとより多くのコードのClassに置き換えられてしまいます。
これは誰かが必死に、入って、これが間違ったアイディアで楽しみを殺してしまうということを説明する必要があるところです、しかし、それはめったに起こりません。
それは、オブジェクト指向プログラミングが悪い、あるいは欠陥があるということでありません。オブジェクト指向プログラミングは、何人かの人が望む計算の基本要素でないということです。やみくもに任意の複雑さの問題に適用されるとき、オブジェクト指向プログラミングは冗長であり、不自然になります。それでも、すべての対象の美的な強調がしばしばずっと下にあります。そのことでオブジェクト指向スタイルが全体的な単純さと理解の容易さを本当に理解することを難しくさせていることが、とても残念です。(Consider this Part 2 of Don't Distract New Programmers with OOP.)
2012年11月15日木曜日
2012年11月13日火曜日
VirtualBox上のWindows 7 のHDD容量を増やす
仮想ディスクを作ったときにFixed size(固定サイズ)ではなくDynamically allocated(動的割り当て)にしていれば、仮想環境を壊すことなく、あとからHDD容量を変更することができる。しかし、勝手に自動的にサイズが増えるわけではなく、次の手順を踏む必要がある。
仮想マシンのWindowsが終了している状態で、ターミナルを起動して次のコマンドを打つ。今までの30GBでは足りなかったので、50GBになるように(50 * 1024)の値を--resizeオプションで指定した。
しかし、これだけではWindowsのドライブの容量は変わらない。Windowsを起動してディスクのパーティションを変更する必要がある。Windows 7 では「コンピュータ」を右クリック→「管理」ででてくる「コンピュータの管理」画面の「ディスクの管理」項目で簡単に変更ができる。
そこに先ほど増やした分(20GB)の未割り当て領域が見えているはず。ここで、既存のCドライブの領域「C:」を右クリックして「拡張」を選択すると、Cドライブのサイズを増やすことができる。
参考サイト:
仮想マシンのWindowsが終了している状態で、ターミナルを起動して次のコマンドを打つ。今までの30GBでは足りなかったので、50GBになるように(50 * 1024)の値を--resizeオプションで指定した。
$ cd ~/VirtualBox\ VMs/MyWin7
$ VBoxManage modifyhd MyWin7.vdi --resize 51200
しかし、これだけではWindowsのドライブの容量は変わらない。Windowsを起動してディスクのパーティションを変更する必要がある。Windows 7 では「コンピュータ」を右クリック→「管理」ででてくる「コンピュータの管理」画面の「ディスクの管理」項目で簡単に変更ができる。
そこに先ほど増やした分(20GB)の未割り当て領域が見えているはず。ここで、既存のCドライブの領域「C:」を右クリックして「拡張」を選択すると、Cドライブのサイズを増やすことができる。
参考サイト:
2012年10月14日日曜日
UbuntuでPDFファイルを画像へ変換する
PDF形式のファイルを、jpgやpngなどの画像形式に変換、またはその逆の変換をするために、Ubuntuではimagemagickというソフトウェアが便利です。
imagemagickのインストールはapt-getで簡単。
インストールできたら、端末から convert というコマンドが使えるようになります。
例えば myfile.pdf という名前のPDFファイルがあったとき、この5ページ目を myfile.jpg という名前の画像ファイルに変換したい場合は次の様に入力する。
逆の場合(myfile.jpg というファイルから myfile.pdf を作成する)場合も簡単
imagemagickのインストールはapt-getで簡単。
$ sudo apt-get install imagemagick
インストールできたら、端末から convert というコマンドが使えるようになります。
- PDFからjpgへの変換
例えば myfile.pdf という名前のPDFファイルがあったとき、この5ページ目を myfile.jpg という名前の画像ファイルに変換したい場合は次の様に入力する。
$ convert myfile.pdf[5] myfile.jpg
- jpgからPDFへ変換
逆の場合(myfile.jpg というファイルから myfile.pdf を作成する)場合も簡単
$ convert myfile.jpg myfile.pdf
2012年8月31日金曜日
Ubuntuのmercurialで「No module named hggit」と出る問題
- Ubuntu 12.04
- Mercurial - (バージョン 2.0.2)
- mercurial-git (Version: 0.3.1-1ubuntu0.1)
の環境で起きた問題。
ある日、hg-git (パッケージ名:mercurial-git) をインストールした。
$ sudo apt-get install mercurial-git
$ vi ~/.hgrc
~/.hgrcに次の2行を追加した。
[extensions]
hggit=
これで、hg-gitが使えるようになったはずと思ったら、hgコマンドを実行する度に
*** hggit のインポートに失敗: No module named hggit
とでてしまう。
ググってみると、現パッケージの場合は.hgrcのhggitに次のパスを指定する必要があるそう。
[extensions]
hggit=/usr/share/pyshared/hgext/git
これで、警告は出なくなった。
参考:
2012年8月23日木曜日
なぜオブジェクト指向はクソなのか by Joe Armstrong - 勝手に翻訳
(原文はこちらです。 Why OO Sucks by Joe Armstrong)
(訳注: 原文はけっこうテキトーな文章なのでテキトーに解釈しました。)
私が最初にオブジェクト指向プログラミングの考え方に導入されたとき、何故だか分からないが、私は懐疑的だった。 - それは "間違っている" と感じた。その後、オブジェクト指向プログラミングは非常に人気となり（理由は後で述べる）、オブジェクト指向プログラミングの批判はむしろ "教会の宣誓"(swearing in church) のようなことだった。オブジェクト指向は、すべての立派な言語が持つようになった。
Erlangは普及するようになったとき、我々は、よく「Erlangはオブジェクト指向ですか？」と聞かれた。 -まあ、正解は「もちろん違います」だったのだが、我々はこれを大声で言うことはなかった。それが(あなたがたくさん手を振ったとき)Erlangはオブジェクト指向(の一種)であるように印象づけ、(あなたが私たちの実際に行ったことに耳を傾け小さな活字を読んだとき)本当はそうではないというように設計された慎重な方法だった。（イミフ）
この点で私は、IBMの当時の上司がパリ第7回IEEEロジックプログラミング会議で聴衆に宛てた基調講演を思い出す。IBM prologは、オブジェクト指向の拡張機能の多くを追加したが、その理由を尋ねられると、彼はこう答えた。
「 我々はオブジェクト指向prologを作ったので、わが社の顧客は、オブジェクト指向prologを望んでいた。 」
私は「どれくらい単純か、良心の呵責はない、無反省、「これが何のために正しいかと」と尋ねないこと...」と思ったことを覚えている。
オブジェクト指向プログラミングに私の原則異議が関与の基本的な考え方にまでさかのぼり、私は彼らにこれらのアイデアといくつかの問題点を概説する。
オブジェクトは分割できない単位で関数とデータ構造に結びつける。関数とデータ構造は全く異なる世界に属しているので、これは根本的なエラーだと思う。なぜか。
関数は、出力に入力を変換するブラックボックスとして理解される。私は、入力と出力を理解すれば、関数を理解した。 これは私が関数を書くことができると言っているわけではない。
関数は、通常、型T1のデータ構造からに型T2のデータ構造へ変換するという計算システム内のものであることを観察することによって理解される。
関数とデータ構造は、完全に異なる種類の動物であるので、同じケージにそれらを閉じ込めることは根本的に間違っている。
"時刻" について考えてみよう。オブジェクト指向言語では "時刻" はオブジェクトである必要がある。しかし、非オブジェクト指向言語では "時刻" は、データ型のインスタンスである。例えば、Erlangで時刻の異なる種類がたくさんあるが、これらは次のような型宣言を使うことで、明らかで明瞭に指定することができる。
これらの定義は、どんな特定のオブジェクトにも属していない。彼らはシステム内のあらゆるところで使え、時刻を表すデータ構造体は任意の関数で操作することができる。
付随するメソッドは存在しない。
オブジェクト指向インタプリタ言語のデータ型の定義ではオブジェクトに属している。だから私は一箇所ですべてのデータ型定義を見つけることができない。ErlangまたはC言語では、単一のインクルードファイルやデータディレクトリ内にすべてのデータ型を定義することができる。あるオブジェクト指向プログラミング言語では、それができない - データ型の定義は、あらゆる場所に広がってしまう。
この一例を挙げる: ユビキタスデータ構造を定義すると仮定する。 ユビキタスデータ型は、システム内の "すべての場所" で発生するデータ型である。
Lispプログラマは長い間知っているように、ユビキタスデータ型のたくさんの数のデータ型と少ない数の関数を持つことより、少ない数のデータ型とそれらに働く少ない数の小さな関数を持つ方がが良い。
ユビキタスデータ構造は、連想リストや、配列やハッシュテーブルまたは、より高度な時刻または日付やファイル名などである。
あるオブジェクト指向プログラミング言語では、ユビキタスデータ構造を定義するための基礎オブジェクトを一つ選ぶ必要があり、このデータ構造を使用したいすべてのものは、このオブジェクトを継承しなければならない。もし "時刻" オブジェクトを作りたいと思ったとき、それぞれのデータ構造はどのオブジェクトに属するべきか？
状態はすべての悪の根である。副作用のある特定の関数は避けるべきである。
プログラミング言語では状態は望ましくないのだが、現実世界では状態であふれている。私は自分の銀行口座の状態に興味があり、私が銀行からお金を預けたり引き出したとき、自分の銀行口座の状態が正しく更新されることを期待する。
現実世界に状態が存在するとき、それらを扱うためにプログラミング言語はどのような機能を提供する必要があるだろうか？
システムのグローバルな状態は、すべての関数に運ばれ、すべての関数から出てくる。関数型プログラミング言語におけるモナドや論理型言語に置けるDCGsのようなメカニズムは、プログラマから状態を隠し、 "まるで状態は重要ではないように" プログラムできるが、状態へのアクセスはできなければならない。
オブジェクト指向プログラミング言語によって選ばれる"プログラマから状態を隠す"オプションはより悪い選択肢である。状態を明かにし、状態への迷惑を最小限に抑えることをせず、状態を離して、見えなくしてしまう。
私は1と2の根拠は見たことが無い。理由は技術の原動力であるように見える。ある言語が、その言語自身の問題を解決するための産業を作り出す場合、それを作るということは利益を出したい輩に対して良いアイディアであるに違いない。
これはオブジェクト指向プログラミングの背後にある真の原動力となっている。
(訳注: 原文はけっこうテキトーな文章なのでテキトーに解釈しました。)
なぜオブジェクト指向はクソなのか by Joe Armstrong
私が最初にオブジェクト指向プログラミングの考え方に導入されたとき、何故だか分からないが、私は懐疑的だった。 - それは "間違っている" と感じた。その後、オブジェクト指向プログラミングは非常に人気となり（理由は後で述べる）、オブジェクト指向プログラミングの批判はむしろ "教会の宣誓"(swearing in church) のようなことだった。オブジェクト指向は、すべての立派な言語が持つようになった。
Erlangは普及するようになったとき、我々は、よく「Erlangはオブジェクト指向ですか？」と聞かれた。 -まあ、正解は「もちろん違います」だったのだが、我々はこれを大声で言うことはなかった。それが(あなたがたくさん手を振ったとき)Erlangはオブジェクト指向(の一種)であるように印象づけ、(あなたが私たちの実際に行ったことに耳を傾け小さな活字を読んだとき)本当はそうではないというように設計された慎重な方法だった。（イミフ）
この点で私は、IBMの当時の上司がパリ第7回IEEEロジックプログラミング会議で聴衆に宛てた基調講演を思い出す。IBM prologは、オブジェクト指向の拡張機能の多くを追加したが、その理由を尋ねられると、彼はこう答えた。
「 我々はオブジェクト指向prologを作ったので、わが社の顧客は、オブジェクト指向prologを望んでいた。 」
私は「どれくらい単純か、良心の呵責はない、無反省、「これが何のために正しいかと」と尋ねないこと...」と思ったことを覚えている。
なぜオブジェクト指向はクソなのか
オブジェクト指向プログラミングに私の原則異議が関与の基本的な考え方にまでさかのぼり、私は彼らにこれらのアイデアといくつかの問題点を概説する。
問題点1 - データ構造と関数は一緒にするべきではない
オブジェクトは分割できない単位で関数とデータ構造に結びつける。関数とデータ構造は全く異なる世界に属しているので、これは根本的なエラーだと思う。なぜか。
- 関数はなにかを行う。関数は入力と出力を持っている。入力と出力はデータ構造であり、関数によって変わる。ほとんどの言語では関数は、命令列からなる。 "これをして、次にこれをして..." 機能を理解するには、物事がが行われる順序を理解する必要がある（Lazyな関数型プログラミング言語と論理的言語ではこの制限が緩和される）。
- データ構造はちょうどそれ自身である。彼らは何もしない。彼らは本質的に宣言的である。データ構造を "理解" するのは、関数を "理解" よりもずっと簡単である。
関数は、出力に入力を変換するブラックボックスとして理解される。私は、入力と出力を理解すれば、関数を理解した。 これは私が関数を書くことができると言っているわけではない。
関数は、通常、型T1のデータ構造からに型T2のデータ構造へ変換するという計算システム内のものであることを観察することによって理解される。
関数とデータ構造は、完全に異なる種類の動物であるので、同じケージにそれらを閉じ込めることは根本的に間違っている。
問題点2 - すべてをオブジェクトにしなければならない
"時刻" について考えてみよう。オブジェクト指向言語では "時刻" はオブジェクトである必要がある。しかし、非オブジェクト指向言語では "時刻" は、データ型のインスタンスである。例えば、Erlangで時刻の異なる種類がたくさんあるが、これらは次のような型宣言を使うことで、明らかで明瞭に指定することができる。
-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()}.
...
これらの定義は、どんな特定のオブジェクトにも属していない。彼らはシステム内のあらゆるところで使え、時刻を表すデータ構造体は任意の関数で操作することができる。
付随するメソッドは存在しない。
問題点3 - オブジェクト指向プログラミング言語では、データ型の定義があらゆる場所に広がってしまう
オブジェクト指向インタプリタ言語のデータ型の定義ではオブジェクトに属している。だから私は一箇所ですべてのデータ型定義を見つけることができない。ErlangまたはC言語では、単一のインクルードファイルやデータディレクトリ内にすべてのデータ型を定義することができる。あるオブジェクト指向プログラミング言語では、それができない - データ型の定義は、あらゆる場所に広がってしまう。
この一例を挙げる: ユビキタスデータ構造を定義すると仮定する。 ユビキタスデータ型は、システム内の "すべての場所" で発生するデータ型である。
Lispプログラマは長い間知っているように、ユビキタスデータ型のたくさんの数のデータ型と少ない数の関数を持つことより、少ない数のデータ型とそれらに働く少ない数の小さな関数を持つ方がが良い。
ユビキタスデータ構造は、連想リストや、配列やハッシュテーブルまたは、より高度な時刻または日付やファイル名などである。
あるオブジェクト指向プログラミング言語では、ユビキタスデータ構造を定義するための基礎オブジェクトを一つ選ぶ必要があり、このデータ構造を使用したいすべてのものは、このオブジェクトを継承しなければならない。もし "時刻" オブジェクトを作りたいと思ったとき、それぞれのデータ構造はどのオブジェクトに属するべきか？
問題点4 - オブジェクトが非公開な状態を持つ
状態はすべての悪の根である。副作用のある特定の関数は避けるべきである。
プログラミング言語では状態は望ましくないのだが、現実世界では状態であふれている。私は自分の銀行口座の状態に興味があり、私が銀行からお金を預けたり引き出したとき、自分の銀行口座の状態が正しく更新されることを期待する。
現実世界に状態が存在するとき、それらを扱うためにプログラミング言語はどのような機能を提供する必要があるだろうか？
- オブジェクト指向プログラミング言語では、 "プログラマから状態を隠す" と言う。状態は隠され、アクセス関数だけを通して見ることができる。
- 従来のプログラミング言語（CやPascal）は、状態変数の可視性は、言語のスコープ規則によって制御されていると言う。
- 純粋な宣言型言語では、状態は存在しないと言う。
システムのグローバルな状態は、すべての関数に運ばれ、すべての関数から出てくる。関数型プログラミング言語におけるモナドや論理型言語に置けるDCGsのようなメカニズムは、プログラマから状態を隠し、 "まるで状態は重要ではないように" プログラムできるが、状態へのアクセスはできなければならない。
オブジェクト指向プログラミング言語によって選ばれる"プログラマから状態を隠す"オプションはより悪い選択肢である。状態を明かにし、状態への迷惑を最小限に抑えることをせず、状態を離して、見えなくしてしまう。
なぜオブジェクト指向は人気だったか？
- 理由1 - 学習が容易であると考えられた。
- 理由2 - コードの再利用を容易にすると考えられた。
- 理由3 - 売り込まれた。
- 理由4 - 新しいソフトウェア業界が作成された。
私は1と2の根拠は見たことが無い。理由は技術の原動力であるように見える。ある言語が、その言語自身の問題を解決するための産業を作り出す場合、それを作るということは利益を出したい輩に対して良いアイディアであるに違いない。
これはオブジェクト指向プログラミングの背後にある真の原動力となっている。
2012年8月22日水曜日
2012年6月21日木曜日
Ubuntu 12.04 でAltキーでHUDの表示を無効にする
Ubuntu 12.04でHUDという機能がAltキーで表示されるようになりました。
カーソル(フォーカス)が左上の「コマンドを入力」という領域に移動して、メニュー項目の実行を素早く行うことができます。
しかし、terminalやemacsを使っている人にはこれはやや不便です。
無効にする、またはキーバインドを変更するためには「CompizConfig設定マネージャ」が必要です。
これはUbuntuソフトウェアセンターから簡単にインストールできます。インストール済みの場合次のようにチェックが付きます。
CompizConfig設定マネージャの起動には左上のUbuntuボタンから「設定マネージャ」で起動できます。
起動したら「フィルタ」にUnityと入力するなどして「Ubuntu Unity Plugin」を探して選びます。
そこで、「Key to show the HUD」という項目に<Alt>が割り当てられているのでここを無効にするか変更する。
以上.
カーソル(フォーカス)が左上の「コマンドを入力」という領域に移動して、メニュー項目の実行を素早く行うことができます。
しかし、terminalやemacsを使っている人にはこれはやや不便です。
無効にする、またはキーバインドを変更するためには「CompizConfig設定マネージャ」が必要です。
これはUbuntuソフトウェアセンターから簡単にインストールできます。インストール済みの場合次のようにチェックが付きます。
CompizConfig設定マネージャの起動には左上のUbuntuボタンから「設定マネージャ」で起動できます。
起動したら「フィルタ」にUnityと入力するなどして「Ubuntu Unity Plugin」を探して選びます。
そこで、「Key to show the HUD」という項目に<Alt>が割り当てられているのでここを無効にするか変更する。
以上.
登録:
投稿 (Atom)