オブジェクト指向ってクソじゃねぇかよPart4

**デフォルトの名無しさん** · 2019/04/28(日) 23:38:35.09

無理やりオブジェクト指向にしたから出てきた問題を解決して凄い凄い言ってるだけ。
単なるマッチポンプ。

カプセル化（英語：encapsulation）とは、オブジェクト指向を構成する概念の一つで、
オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、
オブジェクトの実際の型を隠蔽したりすることをいう。

偏差値の低い学校向けの情報処理系教科書において「大変すばらしいものであり絶対に使うように」と大体的に宣伝された。

一方、カリフォルニア大学バークレー校の有識者を中心としたインターネットを作った人たちは「階層化の有害性」として
「絶対に使うな」としている。大雑把にいうと、その時は良くても、将来的な改修の際に隠蔽されたデータに
アクセスできないと解決できない問題が出てきて、結果的にデスマーチに陥るというのである。

オブジェクト指向の発案者であるアラン・ケイもコーディング規約（頭文字にアンダースコアを付けるなどの命名規則）で
縛る程度にすることを推奨しており、アラン・ケイが関わったオブジェクト指向プログラミング言語にはどれも「private」
という概念はない。

https://monobook.org/wiki/%E3%82%AB%E3%83%97%E3%82%BB%E3%83%AB%E5%8C%96

前前前スレ
オブジェクト指向ってクソじゃね？
https://mevius.5ch.net/test/read.cgi/tech/1535085129/

前前スレ
オブジェクト指向ってクソじゃねぇよ？ Part2
https://mevius.5ch.net/test/read.cgi/tech/1539872441/

前スレ
オブジェクト指向ってクソじゃねぇかよPart3
https://mevius.5ch.net/test/read.cgi/tech/1542884872/

**デフォルトの名無しさん** · 2019/07/31(水) 14:38:11.20

>>549
Rustが出てきた
関数型っぽくないからノーカンみたいなくだらないルールは批判されて当然

**デフォルトの名無しさん** · 2019/07/31(水) 15:39:50.83

「関数型っぽくないからノーカン」ではなくて
「オブジェクト指向プログラミングを含んでいるからノーカン」
https://ja.wikipedia.org/wiki/Rust_(%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E8%A8%80%E8%AA%9E)

> パラダイム
> コンパイラ型言語、システムプログラミング言語、
> マルチパラダイムプログラミング、関数型言語、
> オブジェクト指向プログラミング

> Rustはマルチパラダイムプログラミング言語であり、手続き型プログラミング、
> オブジェクト指向プログラミング、関数型プログラミングなどの実装手法をサポートしている。

オブジェクト指向プログラミングは重要ってことの証明だし
そもそも関数型プログラミングのメリットを言えばいいわけで、
それにはどのオブジェクト指向言語も理解していて、オブジェクト指向に関数型を取り入れてる。

つまりは、オブジェクト指向推進はの意見は、オブジェクト指向＋関数型推奨であり、
関数型プログラミングのメリットをいわず
オブジェクト指向のデメリットのみを言って、
じゃあ関数型では「同じ問題」をどう解決するのかを言わない輩よりも
何歩も先を進んでいる。

**デフォルトの名無しさん** · 2019/07/31(水) 17:10:48.75

どう解決するのかを言う人はパラダイムではなく言語を定義するだろう
言語を定義してしまえばパラダイムの定義を言う必要はない

言語をどれにするのかを言わない輩は信用できない

**デフォルトの名無しさん** · 2019/07/31(水) 19:03:15.86

言語はオブジェクト指向でもあるRustが一番！

**デフォルトの名無しさん** · 2019/07/31(水) 20:01:32.38

>>550
それパターンのどれ？

**デフォルトの名無しさん** · 2019/07/31(水) 20:06:20.03

>>555
パターンの数なんてたかが知れてるんだから
思いついた名前を言ってみな。
これも勉強だ。

**デフォルトの名無しさん** · 2019/07/31(水) 20:09:47.68

コンポーネント…

**デフォルトの名無しさん** · 2019/08/01(木) 01:00:59.00

お前ら何と闘ってるんだ…
現実問題としてオブジェクト指向だけだとコードが複雑化しがちだから関数型の要素を各言語が取り込んで行ってるのが現状だろ
それぞれの良いところを利用すればええんや

**デフォルトの名無しさん** · 2019/08/01(木) 01:51:56.19

オブジェクト指向を標榜して
コード構造をぐちゃぐちゃにするのを止めれさえすれば
それが関数型であろうが別のパラダイムであろうが良いのであって、

オブジェクト指向対関数型の対立軸に論点を移してしまうと、
工学的根拠のない都市伝説みたいな屁理屈の応酬に陥ってしまうので、
オブジェクト指向の問題点を議論する際には関数型の話を前面に出さない方が良い

**デフォルトの名無しさん** · 2019/08/01(木) 01:58:02.87

ただ淡々とオブジェクト指向はクソなんだと
問題点を指摘してさえすればよい

**デフォルトの名無しさん** · 2019/08/01(木) 08:07:45.88

オブジェクト指向が向いてるモジュールとそうでないモジュールがあるだけだろ
何でもかんでもオブジェクト指向で設計する、とか
オブジェクト指向を全面否定するから、話がおかしくなる

**デフォルトの名無しさん** · 2019/08/01(木) 11:24:12.58

>>558
そうなんだよ。

時代は、オブジェクト指向 + 関数型で、
オブジェクト指向言語は関数型の考えを取り入れていってるんだが、

時代錯誤な人間が、未だに、オブジェクト指向 VS 関数型だと思っていて、
オブジェクト指向はだめだ、これからは関数型プログラミングだ！なんて言ってるんだよ。

で、そういう輩は決まって、オブジェクト指向の問題点を指摘するが、
その指摘した部分を関数型プログラミングでどうやるのか？という答えを言わない。
解決すべき問題そのものを関数型プログラミングではなかったことにしている。

**デフォルトの名無しさん** · 2019/08/01(木) 11:49:10.23

クラスベースオブジェクト指向３本柱のうち継承についてだけはオブジェクト指向を標榜するモダン言語でも軒並み冷飯喰らわせてるな

**デフォルトの名無しさん** · 2019/08/01(木) 12:31:10.10

関数型言語でフレームワークなしにウェブアプリやゲームやシステム作れたりするものあったっけ？
結局実用的な何かを作るためにはフレームワークは必須で、オブジェクト指向ではない
（例えば継承が使われていない）フレームワークなんてあるの？

**デフォルトの名無しさん** · 2019/08/01(木) 12:40:02.99

つまりバッドプラクティスとしてクラスベースオブジェクト指向としての継承を制限している言語にフレームワークは無いと言うことだねｗ

バカ「goにフレームワークは無い！！」

**デフォルトの名無しさん** · 2019/08/01(木) 12:43:57.81

頭が悪い人は黙っていて。ここでいう継承というのはオブジェクト指向の考え方でいう継承のこと
言語で継承が実装されなくても、結局「オブジェクト指向のやり方」を使うわけじゃんっていうのが
言いたいことだから。

**デフォルトの名無しさん** · 2019/08/01(木) 12:45:13.96

オブジェクト指向デザインパターン原則
変わるものを変わらないものから分離する
インターフェイスに対してプログラミングし、実装に対して行わない
継承より集約
委譲、委譲、委譲
必要になるまで作るな

フレームワーク（）はアンチパターンだった？！
（いや>>564が継承が使われてないフレームワークなんてないって言うから…）

**デフォルトの名無しさん** · 2019/08/01(木) 12:54:39.43

バカジャね

**デフォルトの名無しさん** · 2019/08/01(木) 15:15:06.70

継承が一つだけって、当たり前な話だよな。
同じ動詞に違う意味が被ってしまったらどっちだよってなるじゃん。

**デフォルトの名無しさん** · 2019/08/01(木) 15:22:10.67

>>569
インターフェースの場合、複数あるけど、
どっちのインターフェースだよってならないの？

**デフォルトの名無しさん** · 2019/08/01(木) 15:57:20.06

>>570
インターフェースを継承するならそりゃあ同じ問題が起こるだろ。

**デフォルトの名無しさん** · 2019/08/01(木) 16:23:47.98

複数の親クラス（またはインターフェース）を継承したときに名前がかぶる可能性があるという
問題を優れた発想でうまく解決していたのがVB6で、
同じ動詞がどのインターフェースのメソッドなのか判別するために、
継承した場合は、継承元のクラス名をプリフィックスとしてつけるようにしたんだよ。

例えば、fooインターフェースのメソッドを実装するときは、foo_methodという名前で
barインターフェースのメソッドを実装するときは、bar_methodという名前で実装する。
こうすることで意味がかぶることがなくなるというわけ

また呼び出すときは、foo_methodを呼び出すんじゃなくて、fooクラスにキャストする
キャストと言っても、fooインターフェース型の変数に入れるだけだけど

fooとして扱いたいのだから、foo型の変数に入れるのは自然な発想
巧妙な手段で名前がかぶる問題を解決していたんだがこの発想に追いつける言語はまだ現れてないね

**デフォルトの名無しさん** · 2019/08/01(木) 16:25:06.77

>>572
それって集約であって継承じゃ無いんじゃね？

**デフォルトの名無しさん** · 2019/08/01(木) 16:33:40.23

>>573
不思議なことを言うな。
集約のうち（ほぼ）すべての処理を親に委譲するパターンが継承だろう
集約と継承は別々のものではなく、集約の形の特殊なパターンを継承と呼ぶだけの話だよ

**デフォルトの名無しさん** · 2019/08/01(木) 16:47:00.16

>>574
継承は文字通り親から全て継承するから継承だろ？
集約は内包するだけだからな。
むしろ内包してるクラスのオブジェクト名を省略するのが言語仕様として許されてるだけなんじゃね？

**デフォルトの名無しさん** · 2019/08/01(木) 16:50:52.50

内包するだけで、内包したものを使わないわけ無いだろ？
多かれ少なかれ、内包したオブジェクトを使用する

その時、内包したオブジェクトのほぼ全てをそのまま使用する
特殊なパターンが継承と呼ばれるだけの話

**デフォルトの名無しさん** · 2019/08/01(木) 17:19:45.56

SQLみたいにオブジェクト指向を取り入れないので継承ができないものはある
その継承できないものをそのまま使用するオブジェクトもある
継承で解決していた問題を謎のブラックボックスで解決
ブラックボックスの中身はどうなっているのか？という答えは言わない

**デフォルトの名無しさん** · 2019/08/01(木) 18:41:52.50

MFCは基本的な継承の親は１つだけど、シリアライズは多重継承してて、
それによってどんなクラスのインスタンスもバイト列で渡せただろ？

要はデザインセンスの問題で、凡人が手を出すところじゃないんだよ

凡人には凡人の仕事があるだろ？
背伸びすんなよ

**デフォルトの名無しさん** · 2019/08/01(木) 21:37:57.56

アホな言語固有の話をされても噛み合わないのは当然だよな。

**デフォルトの名無しさん** · 2019/08/01(木) 23:48:25.51

固有のバグを発見する固有のテストコードを出すのは実用的だよ
代替パラダイムの代替コードを出すよりよっぽど役に立つ

**デフォルトの名無しさん** · 2019/08/02(金) 06:32:40.37

言語特性を踏まえてのデザインと汎用的なデザインがあっても、継承は言語によって仕様が違うんだから、ある言語で例えなきゃ意味ないだろ？

Javaだったらクラスは単一の継承だけどインタフェースは多重継承だし

**デフォルトの名無しさん** · 2019/08/02(金) 11:10:29.17

ならどの言語での話か、きっちり明確にして語らないとな。

**デフォルトの名無しさん** · 2019/08/02(金) 20:36:03.50

最近のオブジェクト指向では継承は冷遇されてるな。
管理がなってない機能だから、ホワイト除外だｗｗ

**デフォルトの名無しさん** · 2019/08/02(金) 20:47:56.12

昔から継承より委譲と言っていた

**デフォルトの名無しさん** · 2019/08/02(金) 20:58:08.80

正方形が長方形の一種という現実のオブジェクト指向との矛盾を解消できずに発狂しそうになった過去

オブジェクトを更新できるから話がおかしくなる

**デフォルトの名無しさん** · 2019/08/03(土) 01:57:22.76

長方形を継承するコストが高いだけだから
富豪的スクリプト言語なら問題ない
ゼロコスト抽象化言語も正解
どっちも否定するネガティブで中途半端なやつだけがおかしくなる

**デフォルトの名無しさん** · 2019/08/03(土) 10:17:20.42

確かにrustでも継承ないな。
trait、impl組み合わせて頑張ればそれっぽいことできるけどアンチパターンだろうな。

**デフォルトの名無しさん** · 2019/08/03(土) 12:06:59.36

インターフェイスをそんなに気にするならユニットテストももちろん書くよね。
それでほとんど解決だよ。
机上で考えてる奴はわからんだろうが。

**デフォルトの名無しさん** · 2019/08/03(土) 12:12:21.88

ユニットテスト書くから解決ってなにが？

下手なやつのユニットテストはひどい。
ユニットテストじゃなくて、取りあえず動くコードを書く
何をテストしてるのかわからない。とりあえず動けばOKというテストコードを書くから
レビュー不可能なものになる。

それを解決するのが、適切なインターフェースなんだが

**デフォルトの名無しさん** · 2019/08/03(土) 19:03:52.95

>とりあえず動けばOKというテストコードを書くからレビュー不可能なものになる。
こんな奴がまともにインターフェイスを使えるわけねーだろ。
レビュー不可能になる前に一言言えや。
それでダメならプログラムかかせる方が間違ってる。

**デフォルトの名無しさん** · 2019/08/07(水) 19:12:26.40

>>534
関数型プログラミング？迷惑かけんな。そんなのは愚かなオモチャだ！
生産性が急落する！
https://medium.com/better-programming/fp-toy-7f52ea0a947e

**デフォルトの名無しさん** · 2019/08/07(水) 19:17:16.57

>>591
それ皮肉記事？どっちかよくわからんし、面倒くさいから要点だけ書いて

**デフォルトの名無しさん** · 2019/08/07(水) 21:30:40.25

関数型をやらない自由があったから関数型の損失は出なかった
対案を出す義務を植えつけようとしても対案が全然出てこないのも自由だからだな

**デフォルトの名無しさん** · 2019/08/11(日) 13:24:29.24

FP is great! Invest some time into learning functional programming,
and you will be ahead of most of your peers.

**デフォルトの名無しさん** · 2019/08/11(日) 17:38:01.23

リンク先見たけど
関数型なら直ぐに大丈夫みたいに
最初に思わせる様に書いて有るけど
結局どうすればいいのか?
という点に全く答えてない

ただオブジェクト指向プログラミングの現在の問題点は上手く突いているとは思う
動物の例えも
本来知らなければいけない要素とは関係無い物を持ち出して来て
混乱している
というのは確かにそうだ

オブジェクト指向プログラミングは
上手く使えるとかなり効果的だけど
その効果的を得る為に必要な
手法
方法論
教育教科課程
これ等が無いのが現状一番問題でそれを
生涯学習だ
等と言っている様だね
オブジェクト指向プログラミングを活用する説明が何らかの形でそのうち出てくるだろう
と思っていたけど
現状ですら出てこないのが一番の問題で
各種言語がオブジェクト指向プログラミングから離れていっている

関数プログラミングについては知らないけど
感覚的には多くの人(プログラムする人の8割くらい)にはオブジェクト指向プログラミングより更に
使う事は出来ない
と思うな
オブジェクト思考プログラミングは活用方法の習得方法が開発されれば多くの人が使えるようになると思う
関数型とオブジェクト指向型の差はそこにあると自分は見ている

**デフォルトの名無しさん** · 2019/08/11(日) 17:42:04.59

>>595
リまで読んだ

**デフォルトの名無しさん** · 2019/08/12(月) 13:18:21.11

ダメなヤツはmainだけで書かれたコードを関数に分割することもできない
C言語でそれすら出来ないヤツは思った以上にいる
構造体の使いどころも分からんやつもいる

ベースの脳みそがそんなのなんだから教育方法の有無は幻想だ

**デフォルトの名無しさん** · 2019/08/12(月) 13:51:24.42

>>596
ごくろう。
「る」まで読みたまえ。

**デフォルトの名無しさん** · 2019/08/12(月) 15:54:01.17

その「る」は未定義だ。

**デフォルトの名無しさん** · 2019/08/17(土) 01:34:52.52

オブジェクト指向って作りやすいクラス設計と使いやすいクラス設計が対立しない？
両立させようとすると泥沼にはまる

**デフォルトの名無しさん** · 2019/08/17(土) 08:18:00.38

いいえ、対立しません。

**デフォルトの名無しさん** · 2019/08/17(土) 12:48:55.33

作りやすいが何を意味して言ってるのか分からないよな。
コピペで乱立出来るから作りやすいのか、コード量が少なくて済むから作りやすいのか。はたまた

**デフォルトの名無しさん** · 2019/08/17(土) 14:22:45.34

作りやすいクラスは、抽象クラスのことを言っているのかな？

他人が作ったものをあれこれ言っても仕方ない。

**デフォルトの名無しさん** · 2019/08/17(土) 18:58:53.08

作りやすいクラスなんかくそくらえ
使いやすいクラスを作ってこそのオブジェクト指向

そのためのコストは安くない

**デフォルトの名無しさん** · 2019/08/17(土) 20:35:53.17

オブジェクト指向はユーザーに機能の実現以上のことを提供する
データを保護し抽象依存を押し付け
ユーザー、つまりオブジェクト利用者の誤りを防ぐんだ

だが一度きりの使い捨てプログラムや時間に追われた日々の開発で
そんなこと考えてる暇が、テストしてる暇があるか？

**デフォルトの名無しさん** · 2019/08/17(土) 20:45:37.32

その結果が 7pay である。

**デフォルトの名無しさん** · 2019/08/17(土) 21:02:59.46

オブジェクト指向が防ぐのはプログラマの誤りだ
悪意からシステムを守る力はそんなにない

**デフォルトの名無しさん** · 2019/08/17(土) 21:43:02.97

それもほとんど防げちゃいないがな。

**デフォルトの名無しさん** · 2019/08/17(土) 21:46:31.20

配列と一緒に長さを別引数で渡さなきゃいけなかった時代のことを忘れない

**デフォルトの名無しさん** · 2019/08/17(土) 22:01:15.42

今思えば0ターミネートよりマシだったのかもしれない

**デフォルトの名無しさん** · 2019/08/17(土) 22:06:30.35

そら、配列に0入れることもあるんだから
0ターミネートなんてできるわけないやろ

**デフォルトの名無しさん** · 2019/08/17(土) 22:20:11.14

ごめん間違えたわ

**デフォルトの名無しさん** · 2019/08/18(日) 01:03:18.50

また髪の話してる…

**デフォルトの名無しさん** · 2019/08/18(日) 06:51:17.86

ゼロに意味があるバイナリデータが正しく扱えない仕様はいかがなものかと。

**デフォルトの名無しさん** · 2019/08/18(日) 07:06:47.98

>>614
シェルスクリプト「さーせんｗｗｗ」

**デフォルトの名無しさん** · 2019/08/18(日) 10:47:50.36

クライアントサーバの業務アプリをよく受託するけど、
15年前にVB6で作っていた頃の生産性と
今のVB.NETの生産性を比べても
実際よくなってはないというかむしろ生産性落ちてる気がする

優秀な人がたくさん集まれば生産性上がるのかねえ？

**デフォルトの名無しさん** · 2019/08/18(日) 11:37:53.97

>>616
マイクロソフトの.NET Frameworkはクラスを継承して作るというより、ライブラリを使用して作るものになっているからね。

**デフォルトの名無しさん** · 2019/08/18(日) 11:46:36.91

>>616
生産性が上がらないって…どんな環境で作ってるわけ？

**デフォルトの名無しさん** · 2019/08/18(日) 11:49:37.88

>>610
そりゃ単なるqueueとかstackなら使い方間違うことないだろうが、
オブジェクト指向マンセー厨がやると変に恣意的かつ複雑なインターフェイスを
やり始める。
オブジェクト指向の問題ってのはそういう詰め込みすぎなクラスを作る傾向が強くなる点だな。

**デフォルトの名無しさん** · 2019/08/18(日) 11:49:50.78

>>618
どちらもやりなれていれば同じということだと思うよ。VB6.0は止まっているからやりやすい部分もある。

**デフォルトの名無しさん** · 2019/08/18(日) 11:50:36.51

> オブジェクト指向マンセー厨がやると変に恣意的かつ複雑なインターフェイスを
> やり始める。

そうか？ちょっとRubyかJavaScriptで例を見せてよ

**デフォルトの名無しさん** · 2019/08/18(日) 11:54:41.01

>>621
一般に出回ってる枯れたコードはそういう部分は少ない。
まあそれでもpythonのpandasとかでも十分インターフェイスの統一感はないし、
結果が副作用なのか戻り値なのかわかりにくい。
オブジェクト指向信者が考えるほどこの辺のAPI設計てのは楽じゃない。

**デフォルトの名無しさん** · 2019/08/18(日) 12:21:38.25

業務アプリ屋さんにとっては、同じことをやるにしても
VB.NETになってコードが膨らんだだけだもんな

.NET Frameworkが出たころはセンセーショナルに宣伝されたり、
したり顔の人がマンセー記事書いたり、そんなに凄いのかと思ったよ

でも、VB6.0の参照設定やポトペタで十分だったよ、平均的な開発者にとっては

あくまでもライブラリ「利用者側」の意見だけど

**デフォルトの名無しさん** · 2019/08/18(日) 12:24:03.47

>>618
今も昔もVisual Studioでしょ？違うの？

**デフォルトの名無しさん** · 2019/08/18(日) 12:33:43.15

優秀じゃない人にかぎって、オブジェクト指向言語を変に持ち上げるんだよね

職業でやってるんだから、同じことが簡単にできればそれでいいんだよ

できないのに、さもエレガントに開発できるよ、できないのは勉強不足だとか
いいだすバカがたくさん沸いて困るよな
そいつが有名なライブラリでも開発してるんならともかく

**デフォルトの名無しさん** · 2019/08/18(日) 12:54:31.50

>>622
オブジェクト指向は素晴らしい。

作る時間がない人は、使うだけでもいい。
使うだけなら作る問題は一切関係ない。
使うだけでオブジェクト指向はのすばらしさが分かるだろう。

**デフォルトの名無しさん** · 2019/08/18(日) 12:55:36.10

>>625
> 優秀じゃない人にかぎって、オブジェクト指向言語を変に持ち上げるんだよね

罠かな？ｗ

（優秀な人 + 優秀じゃない人）＝すべての人がオブジェクト指向言語を持ち上げてる
っていうのが正解だろ？

**デフォルトの名無しさん** · 2019/08/18(日) 13:03:50.16

>>616
> 実際よくなってはないというかむしろ生産性落ちてる気がする

生産性が上がらないっていうのはこういうことだよ。

例えば、パソコンを使えば電卓よりも遥かに生産性が上がるだろ？
だがパソコンを使えない人にとってはどうか？電卓のほうが速いだろう？

生産性っていうのは単に道具を入れたら、それだけであがるってものじゃない。
生産性を上げるには使う側の能力もあげなければいけない。

電卓でもなんとか検定があるように使う側が能力を上げれば生産性はあがるが
限界ってのが存在する。どんなに頑張っても限界以上あがらない。
優れた道具はその限界を引き上げる。ただし限界を引き上げるだけなので
使ってる人間が頑張らなければ、今と変わらない。

だから能力があるプロ集団の生産性は著しく向上し、
能力がない素人集団は道具を使えずに生産性が落ちることになる。
出来るところと出来ない所で差がどんどん広がってるんだよ。

**デフォルトの名無しさん** · 2019/08/18(日) 14:09:04.96

責任を人が無能なせいしにして
生産性が上がらないという事実に目をつぶろうとする究極無能

この手の無能は本当に厄介
自分だけ破綻すればいいのに周囲を道連れにする

**デフォルトの名無しさん** · 2019/08/18(日) 15:31:43.72

生産性を上げるにはどうするかの話やで？
道具を入れたら生産性が上がると勘違いしてるのは誰や？

**デフォルトの名無しさん** · 2019/08/18(日) 17:16:26.08

>>624
その機能が違う

**デフォルトの名無しさん** · 2019/08/18(日) 17:38:49.42

どんだけVSに良い機能が追加されたとしても、
それを使わないなら、なんの生産性も上がらないのは当たり前だな

**デフォルトの名無しさん** · 2019/08/18(日) 17:45:52.31

具体的にどの機能が良いの？

個人的には非接続型のADO.NETとか、メリットがよくわからないわ
昔のADOでも非接続が必要なら手段はあったし

日本の平均的なプログラマーには高度でメリットが享受できないんじゃね？
欧米は知らんけど

**デフォルトの名無しさん** · 2019/08/18(日) 18:06:24.72

ちょっとは調べろよ…

**デフォルトの名無しさん** · 2019/08/19(月) 20:24:40.67

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　.　　　　　　　　　　　　　　,　　　　　　　　　　　　　　　　　　　ｬ　　ｨE5!..　　　　　　　　　　　　　
　..　　　　　　　　　　　,,.e;〆　　　　　　　　　　　　.、　　　w===|====!.　　　　　π　.e､ｘ＆　　　　　　　　　　　　　
　..　　　　　　　　　　^~　！　　　　　　``=　　　　π　　　　　,,　ｶ.　_　　　　_￣ｵ⌒|!　`ﾍ　　　　　　　　　　　　　　　　　　
　.　　　　　　　　　fラ⌒￣l｢~~~＾.　　　　　　　　,.ﾀ.　　　　　.ﾙ　.ll　~＼_　　　〃　〃.　　＾..　　　　　　　　　　　　　　　　　　
　.　　　　　　　　　　　　　.ｵ..　　　　　　,...＿_,xｆ~.　　　　　　^　　f!　　､　　　　　　　　　　　　　　　
　.　　　　　　　　　　　　'^´　　　　　　　　￣￣..　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　．.　　　　　　　　　　　　　　　　　　　l|..　　　　　　　ｒ=キ'⌒..　　　　　　　　　　　
　.　　　　　　　　　`!、　　　　　　　　~~~~~~⌒...　　　　l｝　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　⌒ｈeィ~.　　　　　.+ｓ_、_e.　　　　　.＾+--w=ｆ　　　`ｦse､._　_、...　　　　　′　　　　　　　　　　

**デフォルトの名無しさん** · 2019/08/19(月) 21:20:36.58

チンポがシコシコするのは、チンポ自身が独立した生き物であり、チンポ自身の意思であり自己決定である。

**デフォルトの名無しさん** · 2019/08/19(月) 21:41:01.59

復活しなくていいよちんぽ

**デフォルトの名無しさん** · 2019/08/21(水) 12:52:57.62

機械語やアセンブリ言語から副作用はあれど式を導入して(x = x + 1)手続き型言語が誕生したと考えると、
手続き型言語も機械語から数学に寄ってきた言語で、関数型言語はそれを推し進めた言語とも言える。
(手続き型言語やOOP言語は式と命令が混ざっていると考えれば、純粋手続き型言語はアセンブリ言語？)

ただ、無限ループに関しては遅延評価を取り入れた言語(Haskellなど)がさらに数学に寄った極端な例で、
OCamlやSMLみたいな先行評価な関数型言語は無限ループに関しては手続き型言語と大差無い。

以下のHaskellコードはcycleのみが無限ループの構造だが、他のコードは線形。
(先行評価では無限ループの局所化は無理)

import Data.List
import System

main = mapM_ put $ zip hellos marks

hellos = (cycle.tails) "Hello World!!"

marks = cycle ["/","|","\\","--"]

put (x,y) = do putStrLn (x ++ "\n" ++ y)
mapM_ (\_ -> putStr "") [1..50000]
system "clear"

cyycleは組込だが、定義はこんな感じ。

cycle xs = xs ++ mycycle xs

**デフォルトの名無しさん** · 2019/08/21(水) 12:59:12.68

そして関数型言語に足りないのは構造の記述力
手続き的なものはかけるが、それを分割構成するための
構造の記述力が欠けている。

だから大型アプリには適さない。
そして構造の技術力に強いオブジェクト指向言語は
その内部の手続の記述に矛盾なく関数型言語を
取り入れることが出来ている。

**デフォルトの名無しさん** · 2019/08/21(水) 14:21:32.40

Haskellが基にした圏論はまさしく構造を記述する為に生まれた数学だが。。。

大規模開発とかはimportとかのパッケージの話じゃ無いかな？
だったら、別に言語に差異は感じないが。。。

**デフォルトの名無しさん** · 2019/08/21(水) 19:10:28.30

無職が開発を語るのはやめよう

**デフォルトの名無しさん** · 2019/08/21(水) 20:09:12.59

推し進めたんじゃあなくて関数型のラムダ計算が一番最初に出来上がったんじゃあないの？

**デフォルトの名無しさん** · 2019/08/21(水) 21:04:56.39

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　.　　　　　　　　　　　　　　,　　　　　　　　　　　　　　　　　　　ｬ　　ｨE5!..　　　　　　　　　　　　　
　..　　　　　　　　　　　,,.e;〆　　　　　　　　　　　　.、　　　w===|====!.　　　　　π　.e､ｘ＆　　　　　　　　　　　　　
　..　　　　　　　　　　^~　！　　　　　　``=　　　　π　　　　　,,　ｶ.　_　　　　_￣ｵ⌒|!　`ﾍ　　　　　　　　　　　　　　　　　　
　.　　　　　　　　　fラ⌒￣l｢~~~＾.　　　　　　　　,.ﾀ.　　　　　.ﾙ　.ll　~＼_　　　〃　〃.　　＾..　　　　　　　　　　　　　　　　　　
　.　　　　　　　　　　　　　.ｵ..　　　　　　,...＿_,xｆ~.　　　　　　^　　f!　　､　　　　　　　　　　　　　　　
　.　　　　　　　　　　　　'^´　　　　　　　　￣￣..　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　．.　　　　　　　　　　　　　　　　　　　l|..　　　　　　　ｒ=キ'⌒..　　　　　　　　　　　
　.　　　　　　　　　`!、　　　　　　　　~~~~~~⌒...　　　　l｝　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　⌒ｈeィ~.　　　　　.+ｓ_、_e.　　　　　.＾+--w=ｆ　　　`ｦse､._　_、...　　　　　′　　　　　　　　　　

**デフォルトの名無しさん** · 2019/08/25(日) 18:30:08.01

haskellのようなオブジェクト指向じゃない言語でも結局オブジェクト指向と同等のことをできるようにするために四苦八苦してる

**デフォルトの名無しさん** · 2019/08/25(日) 18:40:55.15

>>644
>haskellのようなオブジェクト指向じゃない言語でも

オブジェクト指向は俺の股間に付いているのだからな！！！

**デフォルトの名無しさん** · 2019/08/27(火) 22:21:22.91

これからはプロトコル志向の時代だ

**デフォルトの名無しさん** · 2019/08/29(木) 10:31:53.66

最近クラス名で悩むことが増えた
仕事や責務でクラス分けするとうまい名前がなかなか出てこない
単なるデータクラスならこんなに悩まないのに

**デフォルトの名無しさん** · 2019/08/29(木) 11:37:15.24

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　.　　　　　　　　　　　　　　,　　　　　　　　　　　　　　　　　　　ｬ　　ｨE5!..　　　　　　　　　　　　　
　..　　　　　　　　　　　,,.e;〆　　　　　　　　　　　　.、　　　w===|====!.　　　　　π　.e､ｘ＆　　　　　　　　　　　　　
　..　　　　　　　　　　^~　！　　　　　　``=　　　　π　　　　　,,　ｶ.　_　　　　_￣ｵ⌒|!　`ﾍ　　　　　　　　　　　　　　　　　　
　.　　　　　　　　　fラ⌒￣l｢~~~＾.　　　　　　　　,.ﾀ.　　　　　.ﾙ　.ll　~＼_　　　〃　〃.　　＾..　　　　　　　　　　　　　　　　　　
　.　　　　　　　　　　　　　.ｵ..　　　　　　,...＿_,xｆ~.　　　　　　^　　f!　　､　　　　　　　　　　　　　　　
　.　　　　　　　　　　　　'^´　　　　　　　　￣￣..　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　．.　　　　　　　　　　　　　　　　　　　l|..　　　　　　　ｒ=キ'⌒..　　　　　　　　　　　
　.　　　　　　　　　`!、　　　　　　　　~~~~~~⌒...　　　　l｝　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　⌒ｈeィ~.　　　　　.+ｓ_、_e.　　　　　.＾+--w=ｆ　　　`ｦse､._　_、...　　　　　′　　　　　　　　　　

**デフォルトの名無しさん** · 2019/08/30(金) 10:14:22.26

**デフォルトの名無しさん** · 2019/08/31(土) 10:16:13.46

>>627
いや優秀な人は「ｵﾌﾞｼﾞｪｸﾄ指向を変に持ち上げない」ねたしかにｗ
ｷｰﾜｰﾄﾞを妙に大事する時点で文系脳というか