>>3
どんな底辺環境だよ

>>5
デザインパターンとか分かる人いる？

>>9
オブジェクト指向＝デザインパターンじゃないし読んで破壊せずに書ければ問題ないぞ
うちの職場にはDPを使って書ける人はそこそこいる

>>9
さすがにいないは中々ないでしょ
最近はUnityみたいなゲームエンジンですら
シングルトン推しが熱いのに
新人がちんぷんかんぷんなのは多いけど
ほとんどみんな良く使うものは覚えてるよ

>>8
内部処理的なものじゃないの？

>>10
オブジェクト指向を理解してないんだから黙ってなよ

>>14
まともなアプリ書いたことないのがばればれだなあ
まともなアプリ書けば、一体何をオブジェクトにすりゃいいの？ってなる

>>15
何もかも継承が悪いのは同意だが
封印するほど悪くもないのが難しいところだな

>>23
純粋関数型は宗教みたいなものあふぃ
普通はマルチパラダイムだから副作用は減らしたほうがいいよねくらいに思っとけば十分

>>26
オブジェクト指向を隅々まで徹底すると速度は出ないという妄想について解説しろや
ぼっこぼっこにしてやるからｗｗｗ

>>24
排便しないなら人間ではないのでそもそも人間クラスを継承するのが間違い

>>44
1年目のプログラマか
Cのような旧石器時代の言語に囚われた人間
が大体お前のような感想を持ってる

>>48
それは変態

>>48
お前何か勘違いしてるだろ
C言語は関数型言語じゃないぞ

>>48
どうなんだろうなぁ
C言語から入るのはいいと思う
構造体の利点が理解出来るようになると相当でかい
説明すると
int kokugo,sansu,rika;
func(kokugo,sansu,rika)
ってのがあるとして
ここに、syakaiとかを追加する時すべての引数を書き直す必要があり
さらにシーケンスフラグとか、他の情報とかも全部いちいち書き直す必要がある
これを構造体で kamoku kamoku;
func(kamoku)
みたいにこれだけで終わり
追加する時も構造体の中に追加するだけ
さらに関数が増えていくとfuncが増えるんだけどいちいち書き直したりコピペしたり
そもそも同じところに書くなよ問題になる
クラスにしたら、クラスの中に新しくfuncを定義するだけでいい
一つずつ何のためにあるの？ってのがC言語からやるとわかる

>>48
どうして当初の話題からどんどんズレちゃうん？
僕たち企画の立案から会議、アルファ版、ベータ版に進むにつれて嫌になるほど
ズレるのを体験してるはずなのに
いつの間にかレスバスレになっちゃうん？

>>48
>>73
ああ、間違えて安価つけてしまった

>>60
テキストボックスに入力された生SQLをボタンを押したときDBに投げ付けるだけのデスクトップアプリが思い浮かんだあふぃ

>>63
なにそれこわい

>>72
販売とか人事とかのシステムで必要な程度のアルゴリズムと具体化してるんだから分かれよ

>>72
それが実装できるのがプログラマーの技量になると俺は思っている
四則演算は簡単だよね。四則演算して画面に表示とか
入力されたものに結果を出すとか、電卓とか
電卓と言っても超高機能な物からWEBブラウザで動くもの、ウィンドウズアプリ、スマホアプリ
これらをどれだけ実装できるか？（アルゴリズム）がプログラマの技量
だと俺は思っている
みんな動くソースコードを持っているんじゃないだろうか？俺も持ってる

>>74
バッチ処理なら許す

>>82
関数型の時代は来てないし永遠に来ないぞ

>>92
純粋関数型言語は永久に流行らないという話

>>96
あんな難解な言語が流行るわけがない

>>105
いやだからオブジェクト指向しかつってねーって
理解できてねーとか云ってる時点でもう議論に参加する余地ない

>>115
今死人を生み続けてるわ
動的型付けは悪

>>116
sleep(dog, hours)がdogに対するsleep処理の記述でさえあればOOPなんだよなぁ
あくまでも運用上でそうできるってだけで文法上のサポートがないってだけで

>>121
レスを欲しがっているだけだと思うが？

>>121
OOPかどうかは賛否が割れると思うが
いずれにしてもdog.sleep(hours)と比べると記述としてはかなり曖昧だな

>>125
そりゃあOOPに特化したOOP言語と比べりゃそうだろうよ
だが実際、Perlのように a->Class::method(b) が Class::method(a, b) のシンタックスシュガーでしかなくどちらでもよい言語はある