「人気のプログラミング言語、Cが4年ぶりに1位に返り咲く」記事へのコメント

オブジェクト指向言語は

[Anonymous Coward]

向き不向きがあるからな。(分野的に)
どちらかというと、不向きなものの方が相当程度に多いにも係わらず、
最近は、闇雲に採用したがるア○が多くて困ります。

そのせいかどうかしらんが、ア○PGがおおくなった。

Re:

[Anonymous Coward]

不向きって例えば？

個人的には、Perlでプログラムを書くときなんかは
ごく小規模なものとか
書き捨てで将来絶対改修や再利用しないとわかってるようなものは
OOpで書かないけど。
処理内容に比してなんだか大げさな書き方になってしまうから。

あと思いつくのはパフォーマンスが優先されるような分野だけど
そういうところではOOpはまだ忌避されてるのかな。

Re:

[Anonymous Coward]

> 不向きって例えば？

手順が重要なもの（数値演算やシーケンサーなど）
関係や制約が重要なもの（パズルなど）
アスペクト的なもの、ドメインスペシフィックなもの一般

Re:

[Anonymous Coward]

> 手順が重要なもの（数値演算やシーケンサーなど）
オブジェクト指向が不向きというりゆうが分からない。
オブジェクト指向じゃなくても作れるじゃんっていう主張ならわかるけど。

> 関係や制約が重要なもの（パズルなど）
パズルって。
学校の授業や趣味プログラミングじゃないんだから。。。

> アスペクト的なもの、
アスペクト的なものをオブジェクト指向で表現するのが難しいのはその通り。
ただ、アスペクト指向とオブジェクト指向は対立するものじゃないから。

> ドメインスペシフィックなもの一般
これは「とにかくなんでもオブジェクト指向は不向きなのっ」っていう主張だと受け取って良い？

Re:

[Anonymous Coward]

> オブジェクト指向が不向きというりゆうが分からない。

ピュアなオブジェクト指向ではifやwhileのような制御構文がなく、メッセージングで代わりをさせる必要があります。
それでは不便なのでJavaなどでは手続き指向言語から制御構文を借りてきているわけです。

> パズルって。

例につっこむのもどうかしていると思いますが、実世界では制約解消系のアプリケーションはとても重要なのです。配線やスケジューリングなど。

> これは「とにかくドメインスペシフィックなものはなんでもオブジェクト指向は不向きなのっ」っていう主張だと受け取って良い？

そうです。ピュアなオブジェクト指向はドメインスペシフィックなものをほとんど取りこぼします。ですから実際の言語ではハイブリッドなのです。(太字筆者)

例えば、a + b + cという数式をメッセージングによって表現すると、加算の可換性や結合性を取りこぼしてしまいます。

Re:

[Anonymous Coward]

わかってて住んでる世界が違う(定義がちがう)話をしているなんていけずなACですね。
世間ではオブジェクト指向言語って、ピュアオブジェクト指向ではなくて、データ隠蔽とかデータ・手続きのカプセル化とかその程度のハナシだというのも、わかってて言ってるでしょ。

アカデミア (と一部のソフトウェア工学者が対象としている「実世界」) とプラクティショナーの会話が成立しない、っつーのがこの分野の不幸の一つだと思う。

# 社会人学生なのでどっちの事情もちょっとわかる

Re:

[Anonymous Coward]

> 世間ではオブジェクト指向言語って、ピュアオブジェクト指向ではなくて、データ隠蔽とかデータ・手続きのカプセル化とかその程度のハナシだというのも、わかってて言ってるでしょ。

そういうハナシも認識はしていますが、せっかくのオブジェクト指向がデータ抽象化に退化しちゃっているのも、オブジェクト指向が向いていない領域がある証左だと思います。
たとえばJavaではオブジェクトがあるから構造体は不要として排除していますが(そういう意味ではピュアなオブジェクト指向っぽい)、不便だと思いませんか？
よりモダンなC#にもDにもGoにもあります。

Cでマクロと分割コンパイルでプラガブルモ

Re:

[Anonymous Coward]

よくわかりませんが、GraphicsFactoryクラスは必要なんでしょうか？
＃オブジェクトの生成はファクトリが行うというのを原則としてしまうのは
＃デザパタに毒されすぎじゃないかと。

Re:オブジェクト指向言語は

[Anonymous Coward]

> よくわかりませんが、GraphicsFactoryクラスは必要なんでしょうか？

べつにGraphisクラスでも構いませんが、実行時に何らかのオブジェクトが描画主体のGraphicsオブジェクトを生成するする必要があります。(大文字にしてしまいましたが、意図としてはファクトリーオブジェクトです)

Cではソースに手を入れなくてもコンパイルオプション-DWIN32などで切り替えられます。もちろん動的に変更することはできませんが、同一のソースで異なるプラットフォーム用にコンパイルしたいいうことであればこれで十分でしょう。

ここでの違いは、プラットフォームの切り替えの責任を誰が負っているかです。
JavaであればGraphicsFactoryオブジェクトであり、Cであればコンパイルする人です。純粋なオブジェクト指向は「コンパイルする人」というメタなものの扱いが苦手だということがおわかりかと思います。
また、描画主体はJavaではGraphicsオブジェクトであり、Cでは実行している環境を陰に指定しています。

私はCスタイルを好みます。なぜなら外部環境で決まるものまでオブジェクト世界に持ち込みたくないからです。メタな「それ」は「それ」として陰的に扱いたいのです。

デザインパターンのかなりの部分はバッドノウハウですから、毒されるという表現は非常に的確です。

Re:

[Anonymous Coward]

ここでの違いは、プラットフォームの切り替えの責任を誰が負っているかです。
JavaであればGraphicsFactoryオブジェクトであり、Cであればコンパイルする人です。純粋なオブジェクト指向は「コンパイルする人」というメタなものの扱いが苦手だということがおわかりかと思います。

機種依存を排除するためのJava VMとJITですから、バイトコードが機種依存というのでは、Javaを使うメリットが半減します。そもそもOSを意識しなくても書けるようになっているので、Cなら機種ごとに書かなければいけない部分も、Javaでは書く必要がないことが多いと思います。

Javaでも環境を意識する必要はありますが、Cでも、コンパイル時に解決できない(or しない)環境依存の部分は動的に解決するしかないですよね。動的に決定するものは、オブジェクト指向の方が楽だと思いますよ。

Re:

[Anonymous Coward]

私はたとえが下手ですね。

> 動的に決定するものは、オブジェクト指向の方が楽だと思いますよ。

オブジェクト指向のほうが楽なことが多いことは否定しません。オブジェクト指向が苦手な動的なことがらもあると主張しています。

ただのフックや関数ポインタやデレゲートが欲しいときでも、Javaなどではオブジェクトをでっちあげる必要がありますよね。
Smalltalkのブロックなどは、インプリシットに規定される「環境」を持ち、メッセージパッシングから外れた不純物です。

Re:

[Anonymous Coward]

うーむ。この人はただの繰り返し処理が欲しいときでも関数型言語では再帰をでっちあげる必要があるとか言うのだろうか?

Re:

[Anonymous Coward]

関数型言語でループだと末尾再帰ということでしょうが、でっちあげ感は否定できませんね。
なぜならループは逐次的な制御ですが、関数型パラダイムでは逐次実行という概念がありませんから、状態をすべて引数で受け渡す必要があります。俺はこんなことがしたいんじゃないんだ感はバリバリですよ。

むろん再帰がフィットする局面も多いです。

Re:

[Anonymous Coward]

Haskellのモナドは理論的背景もばっちりで、ただの逐次処理をはるかに超える強力なメカニズムです。
しかしモナドといえば難解で有名ですから、お世辞にも「Haskellは逐次処理が得意」とは言えないでしょう。
(できるから偉いと言い出せばアセンブリ言語最強になってしまいます)

マップのような非ループ的なもので方がつくことのほうが多いでしょうけどね。

Re:

[Anonymous Coward]

構造体、デレゲート、クロージャなど昔からある概念で、C#やDではオブジェクトにする必要がないものまでJavaではオブジェクトにする必要があります。
両者ともJavaより新しい言語であり、そういう非オブジェクトが「やっぱり必要」だと判断されたわけでしょう。

ですからJavaでは非オブジェクト的なものをオブジェクトで書かざるを得ないがためのオブジェクトのでっち上げといって差し支えはないでしょう。