オブジェクト指向について

00:00

Yoshiori Shoji

これは、俺とドラフトコードが適当に雑談をするのを配信するだけのポッドキャストです。

もともとの始まりは、俺の記憶が確かならば、

ワンオンオンをやってる時に、たまに技術的な話してて、

これなんか配信したら面白いよね、みたいなのが始まりだった気がするんだけど、

そのコンテキストをもうちょっと噛み砕くと、俺の中では、

カタクロしくセミナーとかで語るやつよりも、

飲み屋とかでタメ口で、なんかこうだね、オブジェクト指向で、

ってみたいな話をするのが実は結構楽しいよね。

それ聞くのも楽しいよねっていう意味だったと思っているっていうのを、

ちょっと配信してみようかなというテストです。

これ1回で終わる可能性が大というやつ。

draftcode

最終回です。

Yoshiori Shoji

最終回という感じで、僕がyoshioriと思いまして、

draftcode

自分がドラフトコードです。

Yoshiori Shoji

で、所属会社とかどうでもいいよねっていう感じで、

適当に今日はもう話し始めると、

オブジェクト指向について話そうかっていうね、定期的に。

draftcode

さすがにオブジェクト指向で燃えることはないよね、現代。

Yoshiori Shoji

もうない。もうオブジェクト指向に対して何言ってももう燃えないでしょ。

draftcode

何言っても、もうエブジェクト指向だめだって言っても、

やっぱりオブジェクト指向だって言っても、

まだこのおっさんまだオブジェクト指向って言ってるよ。

Yoshiori Shoji

でもオブジェクト指向について語るのはやっぱり楽しいよねっていう気がしてて。

語るから昨日5分だけ調べたんだけど、夜寝る前に。

オブジェクト指向って気がついたら、

オブジェクト指向3大要素、ポリモフィズム、

カプセル化、継承みたいなのがあったりとか、

オブジェクト指向といえばソリッドみたいな話が出てたりとかするけれども、

よくよく調べると一番最初のアラン系とかが言ってたのに、

その2つとも全然言われてないっていうのに気がついて。

ソリッドはただのプログラミングパターンみたいなところから出てきた感じ。

そのパターンをさらにオブジェクト指向っぽいものだけセンスだけ取り出していって、

最終的には継承とポリモフィズムとカプセル化みたいなのが残ったのかなっていう気がしてたんだけども、

結局それも今では廃れてるよねみたいな気はしている。

draftcode

最初は描きたかったものがあって、

これを描くんだったらこういうのがあった方がいいみたいな感じで、

そうすると、これどこでも使えるじゃんみたいな感じに思い始めると、

なんとかしこうみたいな感じになったかなみたいな感じがね。

流行るとさ、特に研究者とかそうなのかなって思うんだけど、

お金を取る、研究資金を取るためみたいなのがわかんないけど、

03:02

draftcode

流行りに乗っかってさ、流行りのものに関連したものになると資金が取りやすいみたいな感じもあるのかもしれないけど、

オブジェクト思考なんとかみたいなのが流行って、

でもオブジェクト思考、やっぱり最初、何でもそうだと思うけど、ふわっとしてる。

もちろん原理とかは、一番最初にこういうふうに乗っていった人がいるかもしれないけど、

いろんな人が、これがオブジェクト思考かみたいな感じで、

私が思うオブジェクト思考みたいな感じを出し始めるから、

Yoshiori Shoji

いろんな形が出たんだよね、多分。

draftcode

それがだんだん、時が経つにつれて、

まあ、これはダメだったね、みたいな感じのものもあり、

残ったものが真に有用。

真に有用って、そうね、テストのタイミングに耐えたからといって真に有用と言っていいのかどうかはわからないけど、

少なくとも時の試練に耐えたものが今に残っているという話ではある。

Yoshiori Shoji

これちょっと面白かったのは、

この業界の面白いところって、こういう伝説の人がまだ生きていることなんだよね。

何が面白いかというと、2020年にクォーラっていうQAサイトあるじゃん。

あれでアランケイ自体が答えてたらしくて、

オブジェクト思考にオブジェクトっていう名前をつけたのはミスだったって本人が言っていて。

そうそう、これは面白いなと思って。

どういうことかっていうと、一番最初のオブジェクト思考とはみたいな話になって、

炎上しないように言うと、オブジェクト自身が何をすべきか知っているみたいなのが、

たぶんすごい一番ふわっとしたオブジェクト思考。

それがある前ってどういうものだったかっていうと、要は構造化プログラミングだったよね。

draftcode

構造化プログラミングもさ、分かんないんだよね。

Yoshiori Shoji

まず何かっていうと、CPU命令にちょっと毛が生えたぐらいのアセンブラシがみんな書いてなかったっていう、

すごい危険なプログラミングをしてて、もうちょっと足枷をつけながらも、

安全にプログラミングを書けるようにしましょうって言って始まったのが構造化プログラミングだと俺は認識してるのね。

if文とかfor文とかを書いて、無駄に余計に勝手にジャンプはできないよ、いろんなところに。

ただif文とかで特定のジャンプだけはできるようにしますよみたいな風にしたのが構造化プログラミングっていう感じ。

draftcode

今からするとさ、今で言う悪と言われてるGoToがさ、

たかが関数台でできるGoToじゃん。

なんかその構造化プログラミング以前のジャンプのっていう、

戻ってこないGoToなんだよね。

いろんなところにGoToできるみたいな感じのやつがある。

06:03

Yoshiori Shoji

それこそさ、今代、ベーシックってそうだよね。

何行目にGoToだよね。

draftcode

10、20って書いてあるあれでしょ?

Yoshiori Shoji

そうそうそうそう。

draftcode

MSXベーシックぐらいしか知らないんだけど。

Yoshiori Shoji

俺もポケコンとかで書いたベーシックしか知らないんだけどさ。

10何行目に戻る。

draftcode

あんなの理由ある。

Yoshiori Shoji

あれはちょっとさすがに1行追加するだけで全部中停とか辛いしみたいな。

なって構造化プログラミングが出てきたみたいなのがあって、

その後なんかあれだよね、ソフトウェア機器だかなんかみたいなのが俺らの生まれる前に発生したんだよね。

ソフトウェアが肥大化してって、

なんかこのまんまでもう僕らが扱えられないみたいなのが、

確か発生してまたいろいろ考え始めたっていうところの、

1個がアラン・Kのやってたやつで、

面白かったのはアラン・Kが言ってたのが、

全てがオブジェクトとかっていろいろ言ってたんだけど、

データを取り除きたかったっていうか、

データじゃなくてオブジェクトにしたかったっていう、

これデータを取り除き方かって言うと誤解になっちゃうんだけども、

プログラミング、アラン・Kがやってた頃、

オブジェクトっていう名前を付けたのは失敗だったっていうところに書いてあるんだけども、

その当時って配列以上のもの、

配列以上のデータ構造は全部オブジェクトって呼ばれてたんだって。

draftcode

配列以上ってことは配列も含むの?

Yoshiori Shoji

ごめん、配列よりもストラクトみたいなものは全部オブジェクトって呼ばれてたんだって。

だからそれ以下のものをなくしたかった。

draftcode

全てが構造体的な?

Yoshiori Shoji

そう、オブジェクトである。

って言うとすごい分かりやすいなと思ったのが、

この頃の配列だから本当にCのプリミティブな配列なのよ。

Cのプリミティブな配列って当たり前だけど配列へのポインターなだけだからさ、

その配列自身の長さすら知らないじゃん。

だからオブジェクトが自分自身のことを知らないっていう意味になっちゃうんだよね。

オブジェクト思考的なこと。

そういう意味で言うと、ただのそういうプリミティブなデータじゃなくて、

ちゃんと配列だったら配列を表現しつつ、自分自身の長さもそいつが分かってるみたいな、

ものを表しましょうが始まりなんじゃないかなっていう、

いろんなものを読んだ俺の解釈。

draftcode

なるほど、思ったよりも結構素朴なオブジェクト。

Yoshiori Shoji

そうそうそうそう。

draftcode

オブジェクトって言うと、もっと高機能オブジェクト的なものを考えてしまう。

その観点で言うとあれだよね。

どちらかというと、イントとかロングを使ってタイムスタンパー直すんじゃなくて、

タイムスタンパー直すんじゃなくて。

そういう感じの話。

Yoshiori Shoji

そうそうそうそう。

だからプログラミングのメインがプリミティブな値をどんどんどんどん使い回すんじゃなくて、

09:02

Yoshiori Shoji

多分オブジェクトとしていろいろ使い回していこうねっていう。

draftcode

なるほどね。

Yoshiori Shoji

のが多分始まりだったんじゃないかなっていう、いろんな歴史を紐解いて言ってること、

アラン・Kが言ってることとか言うと。

しかもアラン・Kがそれを言い始めたオブジェクト思考パラダイムなんだよって言ったのが1960年らしいんだよね。

draftcode

1960年。

Yoshiori Shoji

まあ、とからしいので。

当たり前だけど俺らも全然生まれてないから何もわかんないからさ。

らしいとしか言えないんだけど。

draftcode

当時いてもね、なんか。

Yoshiori Shoji

そうそうそう。

draftcode

わかんないよね。

Yoshiori Shoji

あ、じゃあ1990年だ。

draftcode

さすがに60、60はすごい。

Yoshiori Shoji

60年は。

draftcode

C、だってCの作品とかは89とか90とか。

Yoshiori Shoji

そうだね、ごめんごめん、俺が完全に間違えた。90年。

draftcode

まあでもオブジェクト思考。

あとあれだよね、こういうオブジェクト思考って言われて、なんかいろんな想像ができちゃうじゃん。

Yoshiori Shoji

そうそうそうそう。

draftcode

オブジェクト思考って言った時に、みんないろんなことを考えてしまうから、同じことを話しているのかみたいな。

Yoshiori Shoji

たぶん始まりは本当にそこで、たぶんアラン・K自身ももうちょっとそこで付け足していったと思うんだよね。

それがたぶんスモールトークとかのさ、言語の設計思想にもなっていったりとかして、っていうのだと思うんだけど、始まりはそうだったんだなっていう。

draftcode

そうだね。

Yoshiori Shoji

メッセージパッシングとかも。

draftcode

そうだよね、だって愚直にさ、全部メッセージパッシングです。

いや、愚直にメッセージパッシングって言ってもいいかもしれないけどさ、なんか本当にそのメッセージっていうのが飛んでみたいな感じの愚直にプログラミング。

コンセプトとしてメッセージパッシングっていうのであってみたいな、そういう。

Yoshiori Shoji

それで言うとスモールトークは本当にその何だろう、愚直、愚直まではいかないけどメッセージパッシングをちゃんとしっかりやってて。

フォー分とかイフ分もないんだよね、スモールトークは。

俺もスモールトークなんかちょっと1日こうスモールトークの偉い人たちが集まってるところで、初心者向け勉強会やってやるぜって言ってたから、じゃあやらせてくださいって言って遊びに行って勉強しただけだから、そんなに細かくは知らないけれども。

でもイフ分もある、何だろう、トゥルーオブジェクトのイフトゥルーとかイフフォルスとかっていうメソッドがあるわけじゃん。

もともとブリエーオブジェクトにそういうメソッドが生えてて、その実態がトゥルーだったときはイフトゥルーが実際に実装されて、フォルスだったときはイフフォルスが実行されるみたいな。

だからトゥルーとかフォルスのオブジェクトに対してイフトゥルーっていうメッセージをこの引数の処理ブロックとともに渡すっていうメッセージパッシングなわけじゃん。

draftcode

なんかそれ聞くとあれだね、自分はあれだね、スモンドークとかじゃなくてなんかスキームとかCS教育のあれだけど。

Yoshiori Shoji

そうだよね、パソコン教室。

draftcode

パソコンの学位持ってるんで。

12:01

draftcode

パソコン詳しい学位あるからね。

パソコン学位ってひどい言い方だな。

Yoshiori Shoji

CSの学位ね。

draftcode

トゥルーとかは例えば2つ引数を取って前を最初のやつを返すやつ。

フォルスとかは後ろ返す関数で。

そうすると全部関数になるでしょみたいな。

確かにコンセプトとしてそういうふうにまとめると研究としてしやすいみたいな。

なんか全部関数なくはいいでしょみたいな。

それでも関数なんだみたいな感じに。

まあそうですね、そういう意味では愚直な感じなのかもしれない。

Yoshiori Shoji

でもそれは確かにちょっとそうやってみるとさっき話してたさ、

構造化プログラミングになってデータだけだと辛いからクラスができてっていうところから、

一瞬構造化プログラミングからの離脱がちょっと見られるわけじゃん。

全てがメッセージパッシングになるとさ。

っていうのはちょっと面白いなと思いつつ、

でもそれ流行んなかったなって思う。

なんかそのアルゴル系のプログラミングの公文がやっぱり一番人間はしっくりくるんだろうなって思った。

結局そっちだよね。

draftcode

結局やっぱ公文って重要なのかね。

やっぱり重要なんだろうなっていう感じもするけどね。

そう。

そうね、スモールトーク。

でも自分触った、なんかおわそびでちょっと触ったことあるぐらいだからなんか分かんないな。

Yoshiori Shoji

いや、まあ俺もおわそびなんだけど。

いや、なんかスモールトークはほら、環境ごと作るじゃん。

うん。

なんだろう。

draftcode

IDEよね。

Yoshiori Shoji

IDEの中に実行環境もあってそれ全部を持っていくっていうだけじゃん、ほんとになんか。

draftcode

うんうん。

Yoshiori Shoji

なんかそれはなんかすごい衝撃的でなんかすごいなと思った。

で、あそこの世界にいっぱい大パーツが埋まってるのも分かってるんだけど。

なんか僕はちょっとあそこでは生きていけないなっていう。

うん。

draftcode

なんか今更掘り出さなくてもいいかなみたいな感じはあるかもしれないけど。

Yoshiori Shoji

水清すぎて魚住めずじゃないけど。

あの水俺が住むにはちょっと綺麗すぎてちょっと無理だなっていう。

Emacsでコード書かせてよって思っちゃったから。

draftcode

自分もさ、ちょっとなんか脱線するけどそのエフェクト思考とか。

この前の近藤西ぐらいでTLAプラスって。

Yoshiori Shoji

はいはい。

draftcode

モデリチェックっていう分野があってそこで使う言語なんだけど。

言語とか言語書、よく分かんないや。

Yoshiori Shoji

抽象プログラミング言語って言うんだっけ。なんだっけ。

draftcode

言えばいいのかな。

まあスペシフィクションマンゲージっていうのが多分正しいんだけれども。

そこはどうでもよくて。

なんかそれがJavaで書かれたらIDがあるのよ。

JavaというかEclipseだね。

そのEclipseプラットフォームで僕のIDが配置されていて。

マジ懐かしいなって思いながらポチポチポチポチしてたんだけど。

15:01

draftcode

さすがにこれ無理だなと思って。

他にいないかなと思って探したらVS Codeプラグインとか。

VS Codeプラグイン。

さすが。TLプラスレスリランクも作ってたんで。

マイクロソフトリサーチ禁制だけども。

VS Codeプラグインがあるって。めっちゃ便利。

やっぱりこうIDっていうのは興味はやんねえぜ。

と思ってしまったことだよね。

Yoshiori Shoji

なるほどね。

draftcode

ちょっと脱線したけどね。

Yoshiori Shoji

一応ID派の人をフォローしておくと、

俺は未だにJava書くときはIntelJを使ってます。

IntelJ便利。

draftcode

世界で5人しかいないと呼ばれてるビームでJavaを書く。

Yoshiori Shoji

俺ビームでJava書くのはドラフトコードぐらいしか俺知らねえ。

Emacsは2人知ってるわと。

EmacsでJava書いてる人は2人知ってるわ。

draftcode

なんかの表紙にトレジャーデータの人とご飯に行ったときにね。

IDを使わずにJavaを書く人5人目ですみたいな。

Yoshiori Shoji

世界で5人しかいないんだなって思った。

オブジェクト思考に戻すと、

現代で言うと多分継承はしたれたよね。

draftcode

そう継承、給食にしたれたよね。

Yoshiori Shoji

給食にしたれた。

継承が若干人類には難しいかなって

多分みんなオブジェクト思考で燃えた後に

オブジェクト思考で大事になるのはカプセル化と継承と

継承がタダになってくると難しいなみたいな。

思っていたらすっとGoとかラストとかが

継承もうないわっていう言語を出してきて。

draftcode

継承と例外だよね。

この2つは急に無くなってしまった感じになる。

Yoshiori Shoji

例外のスロー、例外が無くなったというか

draftcode

例外のスローが無くなった?

そうだね、例外を構造化例外。

スローをしてスタックを上がっていく

っていうスタイルが伝わって

どちらかというと明治的に。

ラストだったらもっと綺麗になるけど

Goだったらタチでやるとかそういう感じに。

Yoshiori Shoji

スローっていわゆる構造化プログラミングに

唯一残ったGo2みたいな感じだったじゃん。

draftcode

虚勢されたGo2と言われている。

Yoshiori Shoji

そうだよねって言われればそういうことか

っていう気もするけれども

確かに例外もそうだね。

draftcode

難しい要素がどんどん。

例外もさ、難しい。

機能としては簡単だよと

案内するだけだから

ちゃんと一貫性のある使い方をする。

18:02

Yoshiori Shoji

一気通貫な設計をするのがまず難しいよね。

draftcode

設計上も概念としては簡単。

機能としては。

簡単かと言われてもあれかもしれないけど

ちゃんと使うのが難しい。

そういった人類が早すぎる機能っていうのは

言語からなくなっていくんだなっていう。

Yoshiori Shoji

いらなかったんやっていう気づきが。

継承でやりたかったことってさ

よくあるやつで言うと

哺乳類っていうのがあって

それを継承した人間と犬がいてぇみたいなさ

哺乳類で犬のショップがあってみたいなさ

を表したいだったんだよね多分。

draftcode

いやーわからんなってそんなことしないじゃん。

Yoshiori Shoji

それが正しいとされてた時期はあったわけじゃん。

draftcode

考え方として。

Yoshiori Shoji

考え方として正しいとされてた時期はあって

でも実際に人間が

人間というかプログラマーがやりたかったことって

なんか処理の使い回しをしたかっただけなんじゃねーの?

っていうさ。

親クラスで定義したメソッドを

こっちでもこっちでも使いたかっただけなんじゃね?

っていう感じになっていて実は

だから実は継承を

現実世界の親のオブジェクトがあって

それを子が引き継ぐっていうために

使うんじゃなくて

このメソッドを使いたいからこれを継承しますみたいな

モデリングのためではなくて

実装継承になっちゃっていて

そのせいで逆にプログラミングがどんどんどんどん

いろんなものに依存し始めて

破綻することが増え

やっぱ継承なんかがあるから

そもそもこんなことみんなし始めんじゃない?ってなって

終わってったのかな。

draftcode

実装継承をする人たちがいるという側面もあるし

実装継承に限らず

継承といった時に

言語によって何を継承と言うかっていうのは

ちょっと違うから

インターフェースを実装する

Javaで言うところでインターフェースを実装するっていうのを

C++だと一応継承

使うから

ここで言う継承って言うのは

実装継承みたいなものが結構多くて

そうじゃなくて

単純にインターフェースみたいなものを実装するみたいな

表面的な

表面的なというか

入り口と出口だよね

みたいなところを指定するだけで

良かったんじゃないのっていう感じになるかな

Yoshiori Shoji

インターフェースは大事

インターフェースというか決め事だよね

そうだね

大事だよね

21:00

draftcode

自分の中でオブジェクトスクールを

様々な継承とかを取り除いた結果

最終的に

契約による設計

残ってしまった

契約による設計をオブジェクトスクールと言うのも

ちょっと

ハテナみたいな感じがするけれども

発明されたのは

オブジェクトスクールのコンテクスト

バートランドメイヤーの方なんだけれども

一応そういう風に言ってるんだけれども

ただ契約による設計って

結局その入り口と出口をきちっと

入力と出口をきちっと

インターフェース切りましょうっていう話だよね

決めの問題っていう感じの話だから

そんなのオブジェクトスクールと言って

いいのかって言うと

そうじゃないとは思うんだけど

みたいな感じはするけどね

その上で

その入り口と出口を決めましょう

その入力と出力をきちんと決めましょう

って言った上で

どういう入力と出力にするといいのかな

っていう風になって

今だと流行るのが

イミュータブルというか

関数型言語の考え方

イミュータブルオブジェクトを入れて

イミュータブルオブジェクトを返すやった

これでもう何もステートがないぜ

っていう感じの

Yoshiori Shoji

嬉しいのが最近は

値を変えたいときは

オブジェクトの中身の値を変えるんじゃなくて

値を変えた新しいイミュータブルオブジェクトを返す

みたいな

draftcode

つくりにするっていうやつだよね

もちろん原則というか

基本はそういう考え方をする

という話だから

Yoshiori Shoji

イミュータブルなものでも

draftcode

あると思うんだけど

基本はというところ

Yoshiori Shoji

そうなると

バリュー

オブジェクト的なものと

関数の集合がプログラミングである

みたいな世界に

draftcode

近づいてきてる

これは

この話をするときに

記憶を読み覚まして

一つなんだけど

大学の

児童教員であった渡辺先生の

教員なんですけど

関数型プログラミングというのは

値によるプログラミングだという風に

確か

これはたぶん渡辺先生が

なるほどな

関数型プログラミングって言って

一番しっくりくる

値によるプログラミング

その普遍なもの

値による

ミュータブルオブジェクトによるプログラミングを

ベースにしようというプログラミング

であるという

だから

その上にもちろん

関数によって

マップとかリデュースみたいな

関数型プログラミングでマップリデュースを

Yoshiori Shoji

出てくるのもおっさんなんだけど

draftcode

まあ

その上で関数みたいなものを

Yoshiori Shoji

関数型プログラミングって言うと

普通なんかみんなが

思い浮かぶのが

オブジェクト思考と同じ話になると思うんだけど

関数型プログラミングって

言われて一番最初に出てくるのが

関数が第一期オブジェクトである

っていうんで

24:00

Yoshiori Shoji

関数をつなげた処理を書くのが

関数型プログラミングであるみたいな

印象だと思うんだよねみんな

どっちかっていうと

こうなんか視点というか

何だろうそのフォーカスが関数に向いてる

と思うんだけど

渡辺先生が言ってる

値にフォーカスを

持ってってるっていうのはちょっと

なんか珍しい視点というか

俺は聞いたことなくて

でも言われると確かにしっくりするね

そうだよね

draftcode

その値をこうね

そうだね値を変換していくという過程が

重要なんで逆に言うと

関数がいくら第一期オブジェクトであっても

その中で

ミューテーションを行っている中で

何かが変化しているっていう

のだと

それはちょっと

関数型プログラミングの

意図

っていうものの定義っていうのを

オブジェクト思考の定義というのと

同じように様々な表現ができるし

第一期オブジェクトである

というのは全然あり

もちろん全然

そういう表現の仕方が

いろんな表現の仕方があるんだけれども

値によるプログラミングっていう側面は

非常に

自分の中ではしっくりくる

っていう感じの

それはやっぱりさっき言ったように

契約によるプログラミングと

そんなに

直行するとき

全然違うレベルのものなので

何か組み合わせて使うのが

自分の中で

なるほどなみたいな感じの

プログラミング

Yoshiori Shoji

そういう意味で言うとさっきの話で言うと

オブジェクト思考も何かどんどん

気がついてたら

バリューオブジェクト

イミュータブルなバリューオブジェクトと

関数の頭になってきたよねみたいな

関数型プログラミングと

何か結局たどり着いてきている

draftcode

人間の

処理できる

を求めていくと

それぐらいが一番処理できやすくて

できやすくていいんじゃないかなみたいな

Yoshiori Shoji

いやでもさ

それこそさ

draftcode

ドラフトコードは昔ハスケルやってたわけじゃん

Yoshiori Shoji

やってないよ

インターネットでやってたって言うと

あれかもしんないけど

そういう意味で言うと俺もちょっとだけ

リスポをかじってたの

本当に

20年くらい前って

関数型言語の方が人類には

難しいって言われてたと思うのよ

draftcode

あーそうね

Yoshiori Shoji

言われてたよね

言われてた

draftcode

モナドなんか理解できないとかさ

モナドの解説が100個くらいあったみたいな

Yoshiori Shoji

モナドの解説の

ブログが上がると毎回

ホットエントリーに上がるみたいな

draftcode

ホットエントリーがまずおっさんだけどさ

モナドは象であるって

Yoshiori Shoji

モナドなんて幼稚園でも分かる概念であるみたいな

昔はそっちが難しいって言われてたわけじゃん

でもなんか

結果なんかみんな

こっちに寄ってきたよねみたいなさ

のあってちょっと

draftcode

そうだね

27:00

draftcode

分かりやすい

分かりやすい部分を持ってきている

Yoshiori Shoji

っていう感じかも

お互いに分かりやすい部分に

落ち着いてきた感があるよね

ミュータブルなオブジェクトは

使うのが難しいっていうのはさ

イミュータブル前世になった今は

そりゃそうだよなってみんな思うわけじゃん

draftcode

そうだよね

いろんなところでね

ミュータブルな

ステートを持つっていうのがやっぱり

Yoshiori Shoji

辛いんだよね

draftcode

そうだね

Yoshiori Shoji

なんかね

どっかで

忘れちゃったんだけど

どっかの記事でアランKもステートについてきたんだよね

ステートあんまり持ちたくないみたいなことを言っていて

うん

それは面白いな

昔からそうだったんだやっぱ

って思ってて面白いなと

確かにね

そもそもでいうとさ

オブジェクト思考ってさ

GUI設計と話せない

draftcode

そうだね結構

トラディショナルな

GUIフレームワークってやっぱり

C++の

すごい

リジットっていうクラスを検証したみたいな

Yoshiori Shoji

そうそうそうそう

ね

あの頃のオブジェクト思考とか

デザインパターンとかもそうだけども

ウェブ前のその辺ってやっぱ

GUIのためみたいなの多いんだよね

MVCとかもそうだけどさ

そうだね

面白かったのはオブジェクト思考は

そもそもGUI開発から

生まれてきたのに

今リアクトとかってさ

オブジェクト思考ではないじゃん

draftcode

そうだね

Yoshiori Shoji

どっちかって言うと関数型に近いじゃん

draftcode

うん

毎回

全部呼び出してるわけじゃないけども

キーを作るみたいに

Yoshiori Shoji

上から

draftcode

全部レンダリングするものを

Yoshiori Shoji

みたいな感じの話よね

でなんかこう

ミュータブルなデータを保持する場所を一箇所に

貯めておいてそこのデータが変更された

イベントを契機にそこが書き変わる

みたいな

どっちかって言うとこうなんか

データと関数みたいなのが

切り離されてるし

オブジェクト思考とは逆に

言ったよね結局

draftcode

そうだねリアクトも

一応そのクラスベースの書き方も

あるじゃん

自分いつも関数コンポーネントしか

書いてないんだけど

リアクトもそんな時代はあったけど

今みんな

関数コンポーネントベース

って書くよね

だと思う

Yoshiori Shoji

じゃないとあんまり

draftcode

利点ないよね

そう

そういう風になるよね

Yoshiori Shoji

そうそう

それは結構面白いよねGUI

のために作られた

ものもやっぱそっちになってきたから

結局世の中全て

これは関数型プログラミングって

言っていいのか分かんないけど

それに準ずるものに

draftcode

その似たスタイルに

Yoshiori Shoji

似たスタイルに

30:00

draftcode

そうだね

なんか

もうオブジェクト思考

ないね

これからオブジェクト思考

継承があるプログラミング言語が

流行るっていうその未来が

想像できないから

Yoshiori Shoji

分かんないよでもさ

20年前にさ

継承がないプログラミング言語

なんか使えんだろうって思ってたかもしんない

draftcode

じゃん

Yoshiori Shoji

いやだってさ

未だにさ

GOがすごい特徴的だから

GOがよくさ槍玉にあげられるけどさ

GOのエラー処理がひどいって

draftcode

言われるじゃん

Yoshiori Shoji

スローとかライズに

慣れちゃった人

ちょっとしたGO2に慣れて

しまった人からすると

draftcode

しかもさGOのすごいところってさ

両サイドから批判を受けるんだよね

片方はさ

スローとかに慣れた人だからさ

こんな基本的な雰囲気もない

今までのプログラミング言語

全部無視しているみたいな感じ

こう批判受け

でもう片方からはさ

ラストとかさそういう人からさ

えっジェネレックスもないし

マジエラー処理も

ちゃんと返すんじゃなくて

アイゾンみたいな感じで

返すんじゃなくて

鉢で返してこっちがニルだったら

こっちがエルみたいな感じで返すの

意味わからなくないみたいな

今までのプログラミング言語

全く無視しているみたいな

両側からバンバンバンバン

批判されるプログラミング言語だよね

Yoshiori Shoji

そうな

でも悪くはないとは思うんだよね

うん

draftcode

面白いなーって思った

そう

そう言われてみるとなぜあれが

流行った

流行っていると言えるのかは

Yoshiori Shoji

不思議と言われまして

ラスコック先生が

draftcode

いやでも

ネームバリューだけではないような

Yoshiori Shoji

気がするんだけどね

そうだよね

それこそさ

言い方悪いけどさ

Google様が

使っていますっていう言語だと

流行るみたいなのは

流行らないっていうのが

draftcode

ダートで実証された

そう

ダートは流行らなかったし

Googleが流行ってるんだったら

Pythonも流行ってたもんね

そうね

そういったらね色んなものが流行って

終わったわけですよ

独自言語

PythonはGoogleの独自言語って言われていた

知識もあったわけですけど

Python流行っているけど

流行った理由はGoogleじゃなくて

Yoshiori Shoji

機械学習だもんね

そうそう

draftcode

Goはロボパイク先生

Goはまあ

様々な人だと思うけど

そこら辺の人が

中心になって

大御所感があるよね

Yoshiori Shoji

大御所感はある

draftcode

ミーハー

Yoshiori Shoji

今時こんなミーハーいないのかな

33:00

draftcode

プログラミングミーハー

Yoshiori Shoji

言語マニア

言語マニアからすると

あの人たちが強くて

draftcode

ニューゲームやってる感はすごいあった

そうそう

今時いないのかな

こんな感じでミーハーになるの

今ね

本もね

プログラミング言語とか

本がたくさんあって

本がありすぎるから

採断スキャンしようと思って

いろいろ見てるんだけど

ストラウストアップ先生が書いた

シンプルアトラクションの歴史本みたいなのが

たぶん

絶版本だったと思うんだけど

これはちょっと採断できねえな

って思いながら

これは

読んでないんだけど

ストラウストアップ先生の

分厚いシンプルアトラクションの本

って思いながら

Yoshiori Shoji

それは大学時代に

draftcode

手に入れたの?

大学時代とかに買ったやつ

多いかな

シンプルアトラクション書かないのに

シンプルアトラクションの本たくさん持ってるからな

Yoshiori Shoji

あと

プログラミング言語の

新しい言語が出てくるペースが

draftcode

減った?

減ったのか

われわれが

プログラミング言語とみなして

Yoshiori Shoji

なんかもう

われわれのアンテナが衰えたか

draftcode

どれかかもしれないですけど

あんまね

見新しいなみたいな感じの

Yoshiori Shoji

なんかジップって出たよね

draftcode

あれ

Yoshiori Shoji

あれもう半年くらい前?もっと前?

draftcode

もっと前じゃないかな

プログラミング言語

プログラミング言語に興味が

Yoshiori Shoji

なくなってきたのかも

何だろう

でもさ

Goとかラストの話ばっかりしてて

完全に今俺も忘れてて

今やっと思い出したんだけどさ

Swiftも新しい言語だよね

draftcode

Swift

ね

なるほどね

Swiftの現状っていうのも

こう

そもそも

でもあれですよね

みなさん

iOSアプリが書くときは

Swiftを使わないといけないはずだから

でもあんまりこう

一時期サーバーサイド

Swiftなんて話もあったじゃん

Yoshiori Shoji

あったあった

draftcode

それもあんまもう

効かない気はするねっていう感じは

Yoshiori Shoji

でもSwiftが

オブジェクティブ式だったのあれだよね

オブジェクティブCが

クソだった

オブジェクティブCで書くのが辛すぎたから

そういう人が出てきたときにこうなんか

なんだろう

オブジェクティブCってこうなんかさ

なんだろう

draftcode

スモールトーク

Yoshiori Shoji

スモールトーク

36:00

Yoshiori Shoji

スモールトークなんだけどCが

透けて見えすぎるんだよね

裏側のCを

もうちょっと隠してほしいぐらい

draftcode

あと独特

独特だよね

Yoshiori Shoji

独特独特

本当にさっき言った

ストレクトなメッセージパッシングを

表しちゃってたからさオブジェクティブCとか

オブジェクトに対するメッセージで

メッセージで

その後引き進むみたいなさ

書き方とかもやっぱ

特殊だったよねちょっと今の

言語からすると

draftcode

そう

Yoshiori Shoji

っていうのとかCが透けすぎるのがあって

そういう人が出てきたときは超感動したっていう

draftcode

こう

見た目があれっていう面では

自分は最初さJSXとか

見たときえーって思ったもん

Yoshiori Shoji

JSXめっちゃ思った

draftcode

JavaScriptの中にSQL書いちゃうの

みたいな

Yoshiori Shoji

てかさいまだに

あの

イフ文を書きたいとき無理やり

参考演算子的に書かなきゃいけないのとかさ

draftcode

あーまあ

イフ文が出てきた時点で

もうちょっと

もうちょっと頑張ってこの上の

Yoshiori Shoji

上の層でなんとかしろっていう話だっていうのは

理解しつつもさ

とはいえ現実世界としてみんな

draftcode

書くじゃん

Yoshiori Shoji

まあね

あれは衝撃だったよね

draftcode

あー

やっぱり年寄って

一面タグっぽいものが

急に出てきて

これパースがまずできるの?

Yoshiori Shoji

みたいな

文字列エスケープとかなんもされてない

draftcode

って

Yoshiori Shoji

これなに?みたいな

draftcode

今思うと

いやこれは確かにすごいいいなって思うんだけど

そうそうそうそう

初めて見たときはなんかえーまじか

Yoshiori Shoji

そうなんか気が狂ってると思ったよね

そう

なんか断片を見せられてる感が俺はすごいあって

最初JSX見たとき

こうなんか1ファイルの中に

断片しか書いてないと思って

え?なにこれ?

って思った記憶だけめちゃめちゃある

すごいね

今見るとめちゃめちゃいいんだけどね

draftcode

あれもう今思うとあれ

PHPの逆だよね

PHPとかが

HTMLの中にこうやって書いてる

あれもなんかテンプレート言語かなぁ

っていう感じに思うとそうだけど

やっぱり逆が良かったんだ

表現言語にならないHTMLを埋め込むのが良かったんだ

みたいな感じの

逆転の発想すごいなっていう

自分はね絶対なんか

Yoshiori Shoji

思いつかない

思いつかないし

思いついた人がいても

draftcode

多分最初バカにするもん俺

そう

Yoshiori Shoji

え?まじで?

draftcode

それはねえだろって

普通にテンプレート言語作って

Yoshiori Shoji

なんかした方が良くない?みたいな

draftcode

そうそうそう

Yoshiori Shoji

そうだって

なんかさ

その頃

当たり前だけどさ

39:00

Yoshiori Shoji

感覚として

ビューを表すもの

表現するものとロジック的なものは

切り離すべきだ

原則みたいなの

draftcode

脳内にあるじゃん

Yoshiori Shoji

っていうので言うと

ロジックの中にビューコードがめちゃめちゃ入ってるじゃん

ダメじゃない?みたいなさ

draftcode

そうだね

そう

そういう面ではこういう

MVCみたいな

そういう話も聞かなくなったね

なんか

今もしてるのかな?

Yoshiori Shoji

ほらアンドロイド開発とか

iOS開発とかだとまだあるのかもしれない

draftcode

なるほどね

俺らはウェブに系統し続けて

Yoshiori Shoji

ウェブだと

完全なくなったよね

draftcode

っていう気が

そうだよね

だから

クライアントが

今クライアントって言って指すものがウェブフロントエンド

ウェブフロントエンドっていうものが指すのがさ

本当に

ウェブページの

一昔前はさ

フロントエンドって言うとさ

HTMLをレンダリングするバックエンドサーバーのことを

フロントエンドって呼んでた気がする

今フロントエンドって言うと

JavaScriptとかの方なんですよね

の方にとりあえず

グラフィックURLでJSONを

最初にやり取りしたら

あと全部レンダリングするっていう感じ

すごくな世界観で

全てが回っている感じがして

いや回ってないかもしれないですけど

俺の半径

5cmぐらいの

Yoshiori Shoji

そんな感じで回った気がします

分かる分かる

だからなんか

グラフQLとリアクトと

あと

言ってしまうとグラフQLのJSONのクライアントの

Apolloクライアント

あたりの連携が

気持ち良すぎて

すごいなと思って

さっきの

あの

やべこれおっさんなんで忘れちゃった

契約ベース

でこの

いわゆるフロントエンドとバックエンドの

契約がグラフQLのスキーまで

されるわけじゃん

あそこの完全

分業感もすごいいいよね

そうだね

draftcode

自分はもともと

プロトコルバッサーで

そうだよね

っていう感じはするけど

ちゃんとそれがねフロントエンドで

達成できているっていうのは

良いところだよね

あとささっきの

Apolloクライアントがっていう話だったけどさ

その

スモアでトークとかの

環境そのエコシステム

そういうの

でその

スモアでトークの場合全部いいの

実行環境と

開発環境とみたいな

そういうのがエコシステムだったんだけども

今は

ライブラリを取り巻く様々なエコシステム

とかテクノロジーを取り巻く様々な

エコシステムっていうのはやっぱり

42:00

draftcode

こう重要なんだなっていう感じが

すごく

ある気はしていて

どんな言語そんな新しい

言語でもやっぱり

パッケージマネージャーとかさ

リンターとかさ

全部ついてくんだよね

Yoshiori Shoji

最初からリンターがあるじゃん

draftcode

フォーマットタウンマットとかね

こういうのが

流行る

それがあるから流行るってわけじゃないんだけども

それがない言語はあまり

採用されないのかもねっていう感じが

Yoshiori Shoji

最初はなかったよね

本当の最初は

一番最初に

発表された時やっぱさ

その頃はさマニアだったからさ

いきなり触ったらさ

まずコンパイラーがCPUごとに違ったじゃん

はい

だから

僕のCPUはこれだから

このコンパイラーを使ってみたいな

自分でスクリプトファイルを書いてさ

コンパイルするぐらいだったから

そもそもパッケージマネージャーとかも

なんもなかったのよ

draftcode

でも結構なんか

最初って言ってはダメだな

GOMOとか入っても結構あったもんね

でもGOGETとか

でもやっぱりそういうのが

必要なんだなっていうのが

言語としてオフィシャルに

何かサポートするっていうのが

必要なんだなっていう感じが

すごく

Yoshiori Shoji

あるかな

オフィシャルな言語の管理が

それがオフィシャルかどうかは別としても

ほぼ業界標準になってるみたいなのが

あるっていうのは結構いいなと思ってて

それこそJava

とかはなかったんだよね

今だと一応

Mavenのリポジトリを使おうねっては

言ってはいるけれども

Mavenがやっとデフォルトスタンダード

になったけどさ

昔はANT使ってたりとかさ

あったりとか

多分JS

ノード周りはまだちょっと

もうヤーンで落ち着いたの

draftcode

今逆に

Yoshiori Shoji

ヤーンじゃなくて

draftcode

NPMになったの

Yoshiori Shoji

ノードはやっぱ結局また落ち着いてないじゃん

draftcode

そうなのかもしれないけど

そう

Yoshiori Shoji

でもなんか

ラストとかGOは落ち着いてるし

draftcode

ラストとかはすごいよくできてるよね

Yoshiori Shoji

うん

ラストになってパッケージマネージャーあるでしょ

バンドラー

draftcode

作った人でしょ

Yoshiori Shoji

カーゴ作ったのは確かバンドラー作った人

draftcode

じゃないかな

転生して

Yoshiori Shoji

強くNew Gameだったし

draftcode

強くNew Gameだったね

Yoshiori Shoji

これ洋出展なんだけど

確か一緒だったはず

draftcode

やっぱりね

2回目だといいっていうのが

いいかもね

Yoshiori Shoji

そうだね

初めて触るときに

困らないのがいいよね

draftcode

そうだね

環境が育っているっていうのは

Yoshiori Shoji

だいたい言語を入れると一緒に

入ってくれるとかさ

迷わずに

フォーマットもね

フォーマットもさ

45:00

Yoshiori Shoji

昔はさ

いや俺はなんか

if分の後ろにカッコを付けないとか

いやif分の後ろのカッコは

まず開業すべきだみたいな人とかいて

そういうオプションに対応した

フォーマットをいっぱい用意しろみたいなさ

世界だったじゃん

フォーマッターはいろんな

フォーマット用のコンフィグファイルがあって

無限にいろんなコンフィグをかけて

我が社のコーディング規約は

これですみたいになってたわけじゃん

でも今もうなんかさ

言語が標準で出してくれるとさ

いやもうあなたの趣味とかどうでもいいです

標準に従いましょう

draftcode

っていうのができるのは

そう

Yoshiori Shoji

それはでも迷わなくていいよね

draftcode

そうそうそうそう

Yoshiori Shoji

そうなるとみんなが

書き方揃うからさ

GitHubとかで検索したときも読むのも楽だしさ

draftcode

そうそうそうそう

なんかちゃんと

こう

そういうのをしっかりしてる

レポジトリってやっぱり

この人が書いたコードだなっていうの分かんないんだよね

こう全部同じだから

なんかそういうのをしっかりしてないと

この人が書いたコードだなって

分かっちゃう

そういうのがねちゃんと全部だけ乗ってて

こう読みやすくなってるのは

全部揃ってるっていうのは

Yoshiori Shoji

非常にいいよね

だいぶオブジェクト思考から離れたな

だんだんプログラミング

オブジェクト思考はやっぱり

契約による設計か

draftcode

そうね

Yoshiori Shoji

っていう風に戻すか

draftcode

継承

何が難しかったのかっていうと

なんか

一番難しかったのは

ソリッドの中の

なんかあれかな

リスク不知観原則

リスク不知観原則が一番

これが一番重要だと思うんだけどね

Yoshiori Shoji

それが一番重要は分かるよ

draftcode

そう

これちゃんとしてないからさ

ちゃんとしてないと

破綻っていうか

意味が分からないじゃん

そういう風に継承してくれないのは

なんかもう

良くなかったなっていうのが

自分の中の

Yoshiori Shoji

オブジェクト思考ですね

本当に

オブジェクト思考は

何だろう

多分いったら

哺乳類の話じゃないけどさ

問題とかをちゃんとモデリングをするために

使いたかったんだよね

多分ね

多分本当は

気がついたらただ単に

draftcode

関数を共通化したいために

Yoshiori Shoji

使われてたんだよね

っていうので

使われた結果

この関数とこの関数を

一緒に使いたいから

でも多重継承この言語はできないから

同じ親につけとくかみたいな

draftcode

なんか

Yoshiori Shoji

カオスが発生し

このオブジェクトは何でこれを継承してるんだ

draftcode

みたいな

よく分からない継承が

Yoshiori Shoji

あり

処理も追うのが大変でみたいになって

48:00

draftcode

だんだん紙クラスみたいなのもできてきたり

Yoshiori Shoji

そうゴットクラスできる

draftcode

そう何でも入ってるみたいな感じの

何でもこれからアクセスできるぞみたいな

このオブジェクトさえ持ってれば何でもアクセスできるみたいな

Yoshiori Shoji

そうそう

でなんかさ継承が多段になってくるとさ

なんだろう

このインスタンス変数

は

どの中間クラスが

持ってるインスタンス変数なの

みたいなのが

分かんなくなったりとかさ

継承を辿ってる途中で

一番親クラスを僕は継承しとけばいいかな

シンプルで済むからと思って継承して

新しいの作り始めたら

あれこの変数ないんだけどこれってどこにあるの

みたいな

これこいつが継承してる3つ目のここにあったわ

じゃあここまでは継承しなきゃいけないんだ

このメソッドいらねーのになみたいな

draftcode

結構

親クラスのさ

フィールドを使うのもなんかウッていう感じがする

Yoshiori Shoji

ウッてなるそう

だから結局

なんか継承はやめて

モジュール的なのをインジェクションして

値を持たないものの

関数群みたいなのだけ

なんか

共有化するみたいな

なってくるよね

draftcode

この2人はね

おっさんだから

DI万歳みたいな

Yoshiori Shoji

そういう

draftcode

ね

たぶんね

DIまでウッていう人はね

かなりの数いるんだよね

分かんないっていう人もいるんだけども

分かった上で

ウッていう風に思う人もいるので

なんかね

Yoshiori Shoji

DIもそれでいうとさ

DIはまた別の日に話すから

別の日に話すか

draftcode

DIって

Yoshiori Shoji

オブジェクト思考と同じで

DIも設計思想から使われる方が変わってきた気がするのよ

それもまた別の

draftcode

そう

Yoshiori Shoji

なんかDIの

原則ってほら

依存性の逆転みたいなところがあるわけよ

draftcode

もっというと

DIライブラリを使わなくても

DIできるっていうの

DIっていうのはそのパターンだけで

それをサポートするだけの

そうそう

最初

Yoshiori Shoji

っていうのでまたこれは別途できそうなので

一旦終わっておこう

draftcode

笑

まあね

Yoshiori Shoji

オブジェクト思考

オブジェクト思考は難しい

オブジェクト思考は難しいよねという話

draftcode

でももう誰も

継承しないからね

Yoshiori Shoji

継承しないから良くなった

draftcode

これでさ別の世界でさ

オブジェクト思考がすごい

爆大

すごい

突っ切ってしまってさ

このオブジェクト

30個ぐらい

33個ぐらい継承してるんだけどみたいな

やばかったし

笑

Yoshiori Shoji

継承が難しいんだよね

オブジェクト思考がっていうよりは

継承が難しい

とさっきの話でいうと

エラーのスローか

51:00

draftcode

まあエラーは

オブジェクト思考とはちょっとあれだけど

Yoshiori Shoji

ちょっとまた別だから

これもまた機会があったら別で

draftcode

いやー

エラー処理もさ

やってるとさエラー処理ばっかりしてるじゃん

わかるわかる

エラー処理とテストと

デプロイと

みたいな感じで

みんなさ

みんなコメントしたかった

別に

Yoshiori Shoji

そうね

draftcode

まあいいね

オブジェクト思考なくなって

なくなってって言ったら失礼だね

Yoshiori Shoji

あまり

draftcode

形が変わって

Yoshiori Shoji

関数型っぽくなったよね

draftcode

っていう

やっぱ古いコードを読むと

ああ古いなーって

同じ言語でも思うもんね

やっぱプログラムアップサイド変わったんだなっていう風に

思うわ

Yoshiori Shoji

継承の全てが悪だとは言わないけどさ

うん

なんか

まあなんか多段継承してると

悪だなって思われる

draftcode

逆にさ

ここで継承

使っててすげーなんか

確かにこれは

一番いい使い方だなみたいなのって

あった?なんか

ぱっと思いつく

継承でか

なんか何でもさこれはやっぱりしっかり来たんだな

っていう感じでさ

なんか

Yoshiori Shoji

今

単純にすごい思い浮かんだのは

あれだよね

Rubyの

アクティブモデル

アクティブリレーション

要は

アクティブリレーションを定義した

モデルさんは

FindByとかWhereとかそのなんだろ

SQL的なのをそのオブジェクトから

組めるっていう

なんかあの継承は

draftcode

ミックスインみたいな感じかな

Yoshiori Shoji

そうミックスインみたいな感じだね

うん

draftcode

でもなんか

Yoshiori Shoji

多分あれも

オブジェクトの内部的にはさ

ただの関数群だけじゃなくて

いろんなオブジェクトも

持ってると思うのよそのデータベースのコネクションとかさ

そう

っていうのを持ってると思うんだけど

それは別になんかすごい違和感のある使い方ではないけれども

例えば

なんかアクティブレコードを継承した

まあだいたいRailsって

こうジェネレートするとさ

アクティブレコードを継承した

自分専用アクティブレコードができて

それを継承した例えばユーザーとか

レシピとかっていうモデルが作られていくんだけど

その

自分のアクティブレコードを継承した

ユーザーとかまでだよね

継承で許されるの

あーはいはいはい

なんかアクティブレコードを継承した

ジェネリックレシピみたいなクラスができ

それを継承したレシピみたいなのができ始めると

もうは?ってなるよね

draftcode

あのデータベースのさ

テーブル感とかさってさ

なんか継承みたいな

54:00

draftcode

の表現

できたりするじゃない

この同じ

同じフィールドがあって

なんかその

Yoshiori Shoji

ポリモ

draftcode

ポリモフィックに

データベースのレコードと

ワンマッパーとかの兼ね合いでなんか表現できるっていう

これも

いや自分自身はこれ使ったことがないことはあるんだけど

なんか旗から見てて

うーん難しそう

みたいな

イメージしかなかったけれども

これも

やってるんですかね皆さん

Yoshiori Shoji

どうなんだろう

俺2,3個それをポリモフィック感をやめた

っていうコードを書いたことはある気がする

draftcode

あー

まあねちょっと

Yoshiori Shoji

うん

でポリモフィックのデータベースって

タイプみたいな絡むができるわけじゃん

あー

でなんか上手くウェアークとか書くときに

そこを関連したインデックスとかをちゃんと

作っとかなきゃいけないとかいろいろ難しいんだよね

結局

なんかあこれポリモフィックだからこれも

インデックスに入れとかなきゃいけなかったのねみたいなのも出てくるからさ

あ使いにくいんじゃないかな

っていう気がするけれども

本当にちゃんと設計してポリモフィック関連を

作ったことは俺逆にないので

見た瞬間にあこれはなんか近寄らんとこ

使わないじゃんあれ

draftcode

なんかね

Yoshiori Shoji

複雑なもの

draftcode

やばいスメルがすると思うじゃん

なんか

複雑なものとか

こう

まあ

複雑な問題に対して

複雑なツールを使うっていうシチュエーションは

全然あるんだけども

どうしてもやっぱこうメンテナンスを

考えてしまうと

複雑なものをずっと複雑なままで

いくのって辛いよねみたいな感じ

そうね

だからだったらまあ

こう簡単なツールで何とかできないかな

みたいな感じに

どうしても考えてしまう

Yoshiori Shoji

なんとかシンプルに

するとか

なんとか依存関係を

薄くするとか

考えるかな

draftcode

依存関係とかはね

こうああっていう感じは

Yoshiori Shoji

そう

これは真に独立して生きていけるモデルなのか

そうではないのかみたいなのを考えたりとか

親がいないと存在できない

モデルなのかとか

は結構こう設計の時に考えるよね

みたいな話

はあるが

だんだんちょっとモデル設計とか

モデル設計の感じですか

draftcode

いやオブジェクト式をどうしてもさ

あのほら

オブジェクト式を設計というかさ

Yoshiori Shoji

なんかモデリングみたいな

draftcode

モデリングが結構繋がってくるしね

さっきのさ

現実世界をモデリングするっていう

話だけどさ

かなり

現実世界を

そのまま愚直に

プログラミング言語の世界に

残していくとはまるよね

Yoshiori Shoji

はまるね

draftcode

これもみんな

57:00

draftcode

たぶん一回やって

ダメだみたいな

なったことがあると思うんだけど

やっぱ

プログラミング言語上における

何かのモデリング

クラス設計とか

やっぱりちょっと

現実世界をきちんと

理解しているってことは大事で

それを理解してないとできないんだけど

それを踏まえた上でどういったものを

プログラミング言語の

プログラムの世界で

表現しないといけないのかっていうのは

ちょっと違う話だよね

さっきの哺乳類を

検証してっていうの

はぁーんみたいな

思っちゃうね

Yoshiori Shoji

そう

現実世界にある複雑なものを

抽象化することも大事だし

さらにそれを

簡略化する

扱えるように

どれだけ簡略化できるかっていうのも

すごい大事な気がするんだよね

その辺がやっぱ設計の

肝だし面白いところかなっていう

気はする

この辺の話はね

具体例を出し始めると面白いんだけどね

具体例を出し始めるとね

いろいろ言えないことが増えるからね

これをさ

ちょっと話しとんでいい?

draftcode

今言いそうになってたけどいい?

Yoshiori Shoji

オブジェクト思考の話を

この辺をまとめてと思ったのがさ

20年くらい前にさ

インターネットでスタティック王子さんっていたじゃん

draftcode

懐かしい言葉だ

Yoshiori Shoji

スタティック王子さん

みんなボコボコに叩かれてたじゃん

スタティック王子さん

draftcode

スタティック王子さんのさ

復習して

スタティック王子さんってさ

Yoshiori Shoji

どこの部分のスタティックのこと言ってたんだっけ

スタティック王子さんは確か

スタティックな関数だけで

全部作りゃいいんじゃないかみたいな

オブジェクトわざわざ入る必要ないんじゃないか

draftcode

みたいなことを言ってた気がするんだよね

私オブジェクト思考ってしっくり来ないんですよね

そうそうそう

Yoshiori Shoji

懐かしい

だからスタティックメソッドばっかりを

こうなんかやって

それが2010年らしいんだけど

draftcode

おお

わざと

最近って言っちゃダメなのか

12、13年

Yoshiori Shoji

でも10年前

でもさ

今日の話を統括すると

あの人の言ってることそんな間違ってなかったんだなっていう

draftcode

一面ではそうだけど

Yoshiori Shoji

多面

draftcode

多面的にはね

何がダメだったのかっていうと

多分

ステイトですというか

そうだね

スタティックであるっていうのは

そうなのかもしれない

何か変わっていくものではない

っていうのは

多分最近の流行りだし

いいと思うんだけども

逆にスタティックな

ものしか使わない

1:00:01

draftcode

だからさっきの

Yoshiori Shoji

イントとかロングじゃなくて

draftcode

データになっちゃうからね

その部分が

今時みんな全部

Yoshiori Shoji

イント

それは無理よ

さっき言ったさ

デュレーションとか使わないで

期間をイントで表すとかさ

ないから

draftcode

なんだけど

半分なってたっていうのは

Yoshiori Shoji

あそこまでボコボコに

される話じゃなかったなっていうのを

ちょっと思って

draftcode

みんな

悔いものがあったのかな

そんなに

10年前ってそんなにオブジェクト思考

そんなにみんな継承継承してたっけ

してないんじゃない

Yoshiori Shoji

10年前

は継承継承してたのかな

10年前はしてたんじゃない

draftcode

まだだってGOもないでしょ

Yoshiori Shoji

GOってないんだっけ

ギリギリ出る前ぐらい

draftcode

ギリギリあったかもしれないしなかったかもしれないぐらい

あったよ

だって

自分は社会人になって9年目

Yoshiori Shoji

でも2009年だよ

GO

2009年

11月だから

draftcode

あったあっただって

自分の終始論文とか

GOっぽい感じの言語を

作るみたいな感じの話だったから

全然GOあったよ

Yoshiori Shoji

2009年11月10日に出てて

staticoyさんが2010年って

draftcode

言ってたから

Yoshiori Shoji

そうだね

draftcode

そんなに

でもGOが流行ってた時にさ

流行ってた言語って

Rubyとか

Yoshiori Shoji

そうだね

draftcode

あの当時ってまるで流行ってた

でもあの時は

あの時はLightweight Languageがすごい流行ってたっていう

Yoshiori Shoji

イメージがあるね

draftcode

流行ってた流行ってた

あとあれじゃない

Node.jsでサーバーサイドコード書くっていうのが

ちょっと流行った感じの

Yoshiori Shoji

あと一方でScalarが流行ってたね

draftcode

かもね確かにね

Yoshiori Shoji

確かにね

draftcode

ちょっと

ちょっと古いかもしれないけど

あれだね

オブジェクト志向の

まだ香りがしていたぐらい

Yoshiori Shoji

香りがしていた

draftcode

時期かもね

半分合ってたとも言えるし

そうでもないとも言える

Yoshiori Shoji

なんか

俺個人の反省として

あの時むちゃくちゃ俺も

何言ってんだこう言っちゃってめちゃくちゃ思ってたんだけど

もうちょっと冷静になると

全体的には間違ってんだけど

ボコボコにされるほど

間違ってはいねえなっていうのが

まあ

そうね

draftcode

そこでさ

ここまでさこういう系譜があって

オブジェクト志向とかこういうのがあって

っていうのが分かった上に

オブジェクト志向ってしっくりいかないんですよね

っていうのと

そういうの全く一致して

いやもう全部Cみたいなやつでいいんじゃない

1:03:01

Yoshiori Shoji

みたいな

draftcode

オブジェクト志向ってしっくりいかないんですよね

Yoshiori Shoji

って言われるのと

いやちょっと違いますよね

いやだからさ

ドラフトコードとかもさ

CSの学位持っててさ

そっちをこうやってずっと学んできてたから

こういう話が通じて

ほぼもうスタティックでいいんじゃないの

なんかだせえけどとりあえずユーティビティクラスで

そこに関数だけ置いておきゃいいんじゃないのっていうのもさ

draftcode

通じるじゃん話として

Yoshiori Shoji

まあそうだよねっていう

それがさ

こうなんか

そこまでちゃんと

歴史を知らない人にさいきなりそれを教えちゃっていいのか

っていう怖さはあるよね

それスタティックメソッドで作ったらいいんじゃないのっていうさ

draftcode

いやそれはねやっぱり

あれだよ

老害あるあるで

俺が通ってきた道を通ってきてほしい

通ってこないとだめなんだ

Yoshiori Shoji

通ってきてほしいとは思わないのよ

思わないんだけど

いや

なんだろうね

ちゃんとそれは

draftcode

失敗してほしいよねやっぱり

さっきのさ

いや現実世界を

愚直にモデル化するとだめなんですよっていうのもさ

1回くらい失敗してほしいなっていう

Yoshiori Shoji

そうそうそうそう

でなんかさ

失敗した後にさ

いやでも実はこうやったほうがいいと思うんだよね

俺っていうのもさ

えじゃあ最初に教えてくださいよって

思われそうだなと思うしさ

難しいなって思う

draftcode

スター

メッセージを送信

Yoshiori Shoji

draftcode

スター

コメント

こちらもおすすめ