現代のオブジェクト指向の class の割れ窓化と宣言的プログラミング

オブジェクト指向には、カメラがやっとついたころのガラケーのイメージがある - きしだの Hatena の件。基本的には同意。ただちょっと切り口が違うので自分の意見を言っておく。ただ、このテーマで何度か書こうとして失敗していて、今回も成功しているとはいえない。 宣言的プログラミングの時代 現代の主流は「宣言的プログラミング」であると思っている。これはリソースの宣言と、その状態遷移の手続きや振る舞いの付与が中心にある。 宣言型プログラミング - Wikipedia その代表的な例がフロントエンドの React と、バックエンドの k8s で、どちらも時系列に基づいた状態の宣言と、フレームワーク側による状態遷移処理、 Reconcillation(調停) が基礎にある。 フロントエンドとバックエンドという両極端な世界で、この変化が起きたのがこの時代を反映したものであると思う。 例えば、jQuer

[noseld]

この話題は人によってオブジェクト指向の話してるのかクラスの話してるのかごっちゃになって議論しづらい。フロントエンド自体が１つの関数だからフロントエンドは関数型と相性いいよね。

[t-tanaka]

現状で最も成功している宣言的プログラミング言語であるところのSQLの闇の深さを見るに，人間の思考にあってるのは手続き型言語の方だと思うんだけどなあ。

[mizchi]

ポエム書いた

[Dragoonriders]

“人間は継承ツリーでコードを管理できるほど賢くなかった” はい。継承は使い物にならない。ファイル管理の手間だけが増え閉口させられた記憶しかない。

[turanukimaru]

goの構造体もScalaとかのtraitも間違った使い方を防いでくれないのでClassより良い気がするのは気のせい。今OOPに必要なのは言語で副作用を禁止する機能、例えば ineffective とかをつけたメソッドの状態変更をエラーにするとか

[baronhorse]

とうとう詳しくないとこに言及しだしたかな

[nazoking]

その関数が副作用なしであることをマークできる何か、それで統一されたライブラリ郡と副作用あり関数にピュアマークつけるとエラー出すコンパイラ欲しいですね

[ssids]

もともと class は巨悪のグローバル変数 / static 変数を限定された範囲に押し込めておく「警察が監視できる範囲で目こぼししてる反社組織」ぐらいの位置づけだったかと（極論

[jay-es]

読み手のバックグラウンドによって評価が大きく分かれそう

[trashtoy]

PHP 5.4 が出たばかりの時に trait を実践で試したことがあるけれど, 既存のコードの保守がとても面倒になることがわかり, 安易な使用は良くないという結論になった

[masa8aurum]

同意。 ・宣言的Pには予測可能性、参照透過性が大事 ・classのインスタンス参照や関数参照はシリアライズできないので宣言的Pの邪魔になる ・副作用の組合せ爆発を防ぐためにノイズは消すべき ・CQS有用

[qtamaki]

合意

[sds-page]

SQLが宣言的プログラミング言語であったか。Tsurugiの中の人がSQLパーサの闇に触れて曇ってたのでやはりどんな言語でも人口に膾炙するとクソ化する運命からは逃れられない

[zyzy]

JSはclass式のオブジェクト指向があまりよい文化に結び付かないと言われだしたあたりで、class式のオブジェクト指向を導入したので、今ようやくこの話題になった感はある

[hamamuratakuo]

宣言的に書く＝「MECE」が重要。処理の失敗は副作用がある部分（I/O→APIサーバからの応答遅延等）でのみ生じる。失敗した場合の例外処理（リトライ）が重要。圏論や集合論を土台にすればクラスの代わりに型を使える？

[Rishatang]

ブコメで「Markdownエディタのエディタ部分がtextareaなのが手抜き」ってあるけど、Markdownエディタでtextarea以上に凝りようあるのか…？ってなった。

[NOV1975]

システムアーキテクチャとプログラミング手法は不可分の物、と考えるとこの話自体は納得感がある。JavaにしたってSpring BootのServiceクラスの考え方はおおよそそういうことだって思うわけで。

[quick_past]

これ、関数型で実装できる部分は関数型でいいよね。ってだけの話になんない？実装に関しての高い水準での理解と実装の困難さをどうバーターするかって問題になりそう。Webには適してるのかな。

[xlc]

30年前のLispこそが正道の話に逆戻りしてるのでは？

[tor4kichi]

classは「入力→処理→出力」と「状態A→状態B」のどっちも出来ちゃう器用な奴。だけど、時々その器用さが牙を剥く。ライブラリとアプリとで使う言語機能が違うんだけど、言語自体は様々な利用パターンをカバーしてる

[doko]

だめださっぱりわからん

[t_motooka]

継承とかの仕組みがあるからこそ簡単に作れるものって色々あるはずだと常々思うところだけども、副作用のくだりは本当にそう。

[rin51]

先日からのこの話題は概念の話題とプログラミング言語の機能の話題と実装の話題が混ざっていて理解が追いつかない

[otihateten3510]

えー、「少リソース時代→仮想化時代」ってざっくりし過ぎじゃ無い？その中間時代がOOPだと思ってた／OOPと宣言的が対立構図になってるのが理解できない。補助や拡張という認識で、使い過ぎると難解になるイメージある

[tossy_yukky]

やっぱりこの人はこうやって問題提起というか、人にコメントさせて元の小さな火を大きく衆目に晒すのが上手い。この才能ほしい。

[rgfx]

ですよね

[als_uz]

コードレビューで指摘続けたり、体感してもらったりしてもらわないとわからないのかも

[kamocyc]

主にフロントエンド周りの話だけど、自分も宣言的なものが好きなので共感。 / SQLはNULLの扱いとか構文はアレなところがあるけど、DB的なものにアクセスするには(手続き的に書くより)良い言語と思っている

[onesplat]

goやrustのstructはそれ自体で言語機能としてmutableであることを強制しないしclassが無ければいいってもんでもない。あと副作用云々の話は遥か古代から言われてきたことでぶっちゃけReactやk8sとかあんまり関係ないこじつけ。

[findup]

プログラミング言語論や設計論をあれこれ小難しく語らなくても、簡単に読みやすいコードでやりたいことが実現できる世界になったらいいな。

[mr-csce]

オブジェクト指向が悪いんじゃなくて状態数が多いのがつらくてミュータブルなオブジェクトが悪い。

[yarumato]

“どの状態から状態へ遷移するか意識不要にし、ゼロから状態を作っていい＝宣言的プログラミングがReactの意義。サーバーも設定を変更していく運用ではなくコンテナを常に作り直すk8s。継承とGoFのデザパタをけなす本”

[aceraceae]

継承を全否定はしないけど自明なものに留めるべきで基本的には「平たい」ものであるべきだと考えている。

[ch1248]

同意できる意見だった。

[kabisuke]

この解説に納得。OOPから関数型へじゃなくて、classから宣言的へ、という話かなと。宣言的が使い物になったのは富豪的にリソース使えるようになったから。宣言的なのが難しいと思われちゃうのは馴れの問題もありそう

[masa_w]

宗教を熱く語られるとなぁ…という元記事含めての感想

[NetPenguin]

継承については、型の継承はよいけど、実装の継承はよろしくないという認識。まぁ、型の継承もツリーを作るというよりも、もとめられる特徴にあわせた複数のインタフェースを実装するのが多いけど。scalaのtraitとかも

[dalmacija]

様々な実態がどうかはともかく、語っているコンセプトは妥当でわかりやすいのでは

[kmaebashi]

と、思ったら、その辺はReactの仮想DOMですか。なるほど。