Google のGolangは、Paul の Graham の投稿「なぜ Arc は特にオブジェクト指向ではないのか」で取り上げられている言語の問題に対処していますか?
質問する
2383 次
3 に答える
9
これに対する私の最初の気持ちは「言うのは時期尚早」です
1）字句クロージャやマクロのない静的に型付けされた言語がある場合、オブジェクト指向プログラミングはエキサイティングです。ある程度、それはこれらの制限を回避する方法を提供します。（Greenspunの10番目のルールを参照してください。）
Goは関数リテラル（ドキュメントを参照）をサポートしています。これを正しく読んでいると、他の場所で定義されているかアドホックに作成されているかに関係なく、関数をパラメーターとして渡すことができます。
2）オブジェクト指向プログラミングは、ソフトウェアの作成方法に適しているため、大企業で人気があります。大企業では、ソフトウェアは平凡なプログラマーの大規模な（そして頻繁に変更される）チームによって作成される傾向があります。オブジェクト指向プログラミングは、これらのプログラマーに規律を課し、プログラマーのいずれかが過度の損害を与えるのを防ぎます。その代償は、結果として得られるコードがプロトコルで肥大化し、重複に満ちていることです。大企業にとって、これは高すぎる価格ではありません。なぜなら、彼らのソフトウェアはおそらく肥大化し、とにかく重複でいっぱいになるからです。
この点は、答えるのに主観的ではありません。
3）オブジェクト指向プログラミングは、仕事のように見えるものをたくさん生成します。ファンフォールドの時代には、1ページに5行または10行のコードを配置し、その前に20行の精巧にフォーマットされたコメントを配置するタイプのプログラマーがいました。オブジェクト指向プログラミングは、これらの人々にとってはひびのようなものです。これにより、このすべての足場をソースコードに直接組み込むことができます。Lispハッカーがシンボルをリストにプッシュすることによって処理する可能性のあるものは、クラスとメソッドのファイル全体になります。ですから、自分自身や他の誰かにたくさんの仕事をしていることを納得させたいのであれば、それは良いツールです。
goは真のオブジェクト指向言語ではないため、快適な方法で問題を解決できる可能性があります。
4）言語自体がオブジェクト指向プログラムである場合、ユーザーはそれを拡張できます。まあ、多分。あるいは、オブジェクト指向プログラミングのサブコンセプトをアラカルトで提供することで、さらにうまくいくかもしれません。たとえば、オーバーロードは本質的にクラスに関連付けられていません。わかります。
Goは、大きなオブジェクトツリーを心配したり開発したりする必要がない、オブジェクトに対する興味深いアプローチを持っているようです。純粋なオブジェクト指向環境に縛られることなく、オブジェクト指向の方法でデータを構造化するためのツールが言語に存在するように見えます。
5）オブジェクト指向の抽象化は、シミュレーションやCADシステムなど、特定の種類のプログラムのドメインに適切にマッピングされます。
..。
于 2009-11-12T16:11:00.503 に答える
5
ポールにはいくつかの興味深い点があります。一般的に、私は彼の考えをたくさん読みました。この件に関して、私たちは同意しません。彼はリスプ ナッツであり、くだらないプログラム ナッツです。彼は、難解なプログラムを偉大なプログラマーの仕事として片付けているようです。はい、それよりも微妙な違いがあることは理解していますが、要するにそれだけです。結局のところ、あなたのコードは簡単に扱えるかそうでないかのどちらかです。そして、一部のプログラマー、Paul が優れていると考えるプログラマーは、他のプログラマーよりも多くのがらくたを我慢することができ、コードが意図することの頭や尾を作ることができます。これはスキルですが、優れたプログラマーに必要なのはスキルだけではありません。
Arc といえば最悪です。私が間違っていない限り、Lisp コミュニティの人々でさえそう考えています。
繰り返しになりますが、ポールは賢い人ですが、この特定の作品での彼のアプローチ全体は的を外れているようです。
于 2009-12-01T08:54:47.353 に答える