なぜ「staticおじさん」は叩かれたのか?
■ このスレッドは過去ログ倉庫に格納されています
staticおじさん(読み:すたてぃっくおじさん)とは、2010年に@ITに「実はオブジェクト指向ってしっくりこないんです![1]」
と投稿して炎上したおじさんのことである。
staticおじさんが爆誕した2010年ごろのIT土方界隈ではJavaを中心としたオブジェクト指向が主流であり
「なんでもかんでもオブジェクト指向」という風潮があった。
このためstaticおじさんは多勢に無勢でボロクソに叩かれる結果となり、さらにはプログラミングそのものの
話を飛び出してオブジェクト指向推進派による学歴差別などに発展したすえに無事炎上した。
それからわずか数年後、staticおじさんの主張に「極力static変数は使わない」「関数ポインタを多用する」
というコーディング規約を加えた「関数型プログラミング」がJavaScript界隈を中心に爆発的に流行し、
その流れに乗るかたちでこれら規約を半ば強制する仕様の「関数型プログラミング言語」も多数登場するなど
世界的に一大ブームになった。
ちなみにstaticおじさんの主張と非常に酷似したものが、staticおじさんの登場より遥か昔、インターネットを
支える中核技術である「IP」のRFC(仕様書)にも「階層化の有害性」として書かれていたりする。
また、海外でも同様の主張を面白おかしく書いた「Bjarne Stroustrup インタビュー」なる怪文書が出回り、
こちらも大炎上した。
https://monobook.org/wiki/%E3%82%B9%E3%82%BF%E3%83%86%E3%82%A3%E3%83%83%E3%82%AF%E3%81%8A%E3%81%98%E3%81%95%E3%82%93 別に一般的な意見では?以下関数プログラミング実践入門より引用:
再帰関数は、物事を数学的に捉えた定義通りに書けることが多いためわかりやすいのですが、Haskellに慣れてくると直接的に再帰関数を書くのは避けるようになっていきます。
それは、再帰関数は便利であるのと同じくらい、危険でもあるからです。
停止しない再帰関数をうっかり書いてしまうこともあるでしょう。
とくに再帰関数を直接書くということは、時に必要となるものの、アセンブラを直接書くような低級な行為と認識されます。
データの構造に依存し、それを気にしたプログラミングを要求されるからです。
理想的にはデータの構造を気にせずに、全体に丸々変換をかけられるような関数だけを組み合わせて望む処理を書きたいのです。
そのために、再帰関数を直接利用せずにどうするかというと、次節で説明する高階関数をうまく利用するようになっていきます。
リストなど多くの再帰的に定義されたデータ構造に対しては、それを便利に利用するための計算パターンが用意されており、それらの計算パターンは高階関数として与えられています。
自分で再帰を書くのではなく、再帰部分は高階関数がやってくれるようになっています。 そもそもこのスレではみんなの想定する「再帰」という言葉の定義からして違いそうなのは伝わってくる 永遠に噛み合わない水掛け論やってないでStaticおじさんの話をしてやれよ >>72
これも当てはまる
ループ処理は、物事を数学的に捉えた定義通りに書けることが多いためわかりやすいのですが、Haskellに慣れてくると直接的にループ処理を書くのは避けるようになっていきます。
それは、ループ処理は便利であるのと同じくらい、危険でもあるからです。
停止しないループ処理をうっかり書いてしまうこともあるでしょう。
とくにループ処理を直接書くということは、時に必要となるものの、アセンブラを直接書くような低級な行為と認識されます。
データの構造に依存し、それを気にしたプログラミングを要求されるからです。
理想的にはデータの構造を気にせずに、全体に丸々変換をかけられるような関数だけを組み合わせて望む処理を書きたいのです。
そのために、ループ処理を直接利用せずにどうするかというと、次節で説明する高階関数をうまく利用するようになっていきます。
リストなど多くのループ処理に定義されたデータ構造に対しては、それを便利に利用するための計算パターンが用意されており、それらの計算パターンは高階関数として与えられています。
自分でループを書くのではなく、ループは高階関数がやってくれるようになっています。 >>76
雑すぎる…
> ループ処理は、物事を数学的に捉えた定義通りに書けることが多いため
数学の教科書読み直せw
> Haskellに慣れてくると直接的にループ処理を書くのは避けるようになっていきます。
Haskellはそもそもループ書けないぞw 再帰する関数の定義がばっちりと決まってて動かしようがないならそっちに吸い寄せられて書くけど
漏れがありそうな場合は再帰は使わない
普通のAPIで仕様的に再帰とは指定されてこないしね…(来たら死ねと思うわ) 関数型なんかは結局書ける奴が少ない
それでは業務はこなしきれない
それが解らない奴はただのアホです
自分は凄い事が出来ますよ〜
って自慢したいだけ そんなことないだろ。別に数学のすごい理論完璧に把握してなきゃ関数型書けないって訳でもないし。
OOP真理教の経典暗記のほうがよほど辛い。
慣れてないだけ。難しいと思い込んでるだけ。 ネタにマジレスかもしれないが、
未だにこんなこと言ってるバカいるんだな。
今、誰でも名前知ってる大企業から受託案件受けてるけど、
一番チェックされるのは「オブジェクト指向設計になっているか」だぞ。
上でも出てるけど、staticおじさんの主張と関数型言語は何の関係もない。
関数型言語の本質は参照透過性。
「public static宣言した共有変数」なんて、
参照透過性を妨げる最たるものだろwww そのオブジェクト指向もできないのが多すぎるから問題なんだよな
オブジェクトが分かってないからデザインパターンなんてもんも理解できるわけもない
つまり話は巡り巡ってstaticおじさんにたどり着くわけだ
オブジェクト指向もできなければ関数型でもないただのウンコード量産機がstaticおじさん でもこのstaticおじさん順調に出世して今では大手の本部長だかCTOだかなんでしょ? 高階関数って偉そうに言ってるけど具体例出さない時点でエアプだろw 高階関数なんてありふれてるだろ。
それを偉そうにとは?
使ったことないの? プログラミングは経験つめば抽象的な概念を使って具体的な整理がしっかりできる世界だろ。 >>84 出世するためにプログラミングしてるの?
だとしたら手段と目的を履き違えてるよ
そうでないのなら「出世するプログラム」でも書いて世の中に出したら良いw >>90
落ち着け。その解釈はメモリ破壊系のバグが発生してる可能性高い。 >>91
等価じゃないものを等価と判定してるから、そこら辺のロジックにバグがありそうだな テストコードちゃんと書く奴ならstatic変数もオブジェクト指向も
ある点で問題あることは理解できるもんだが。
そういう意味では関数型のが有害性は低いか。
たまに何でもかんでも再帰で書こうとして逆に可読性低くする馬鹿もいるが。 なんだかんだ出世高給取りのstaticおじさん勝ち組だわ さんざんメソッド移動して最後のメソッドでreturnだけして値返すだけなのにたどり着くと殺意が湧く 関数型の話をすると
関数書けない言語なんてあるんですかねと返されたことを思い出す >>83
ま、その通りだよな。
「public static宣言した共有変数」なんて、
オブジェクト間のメッセージパッシングができないアホ
(別名「オブジェクト指向もできなければ関数型でもないただのウンコード量産機」)
が頼ろうとする手段の最たるものだからな。 また今日もValueHolderモデル使わないで直にget/setやるうんこちゃんと仲良くコード書かなきゃ
はぁまじはぁ 勘違いしてるやつ多いけど
statucおじさんはJavaじゃなくてC#だぞ
Javaプログラマのryoasaiがハッスルしただけで Cで構造体を引き回して管理するタイプのライブラリはオブジェクト思考と言えるだろうか? XWindowライブラリは一般にはオブジェクト指向だと言われとる。
どこまでシンタックスでカプセル化対応するか、どこまで動的なものにするかってのが
議論の分かれ目じゃないかね。 違うだろ
Cの構造体と糞みたいに長い名前のXwindow関数群がいやだから
オブジェクト指向に移行したんだろ >>107
そんなしょうもない理由じゃねーわ。
だからオブジェクト指向論者とは関わりたくねーんだわ。 ハンドラに関数ポインタ持たせて、でその関数の変数にハンドラのポインタを渡しておけばさすがにオブジェクト指向と言えるか?
こうなるとハンドラじゃなくてthisとかselfって呼びたくなるな。 >>108
関わりたくないとか言いながら自らアンカしてかかわっていくスタイルすごい斬新ですね オブジェクト指向ならメソッド名などのメンバー名があいまいでもエディタである程度関数名がでてくる
構造体+グローバル関数だとアホみたいに出てくる候補から選ばなくてはならない
昔はその候補すら出ないので正確な名前が必要だった
だから分厚い辞書みたいな本や紙の束を持ってプログラムしていた
それでもミスする
コンパイルエラーでそんな関数ないよって言われてばかり 設計書の機能一覧のどこのメソッドなのそれ?
これがわからないとどんなに高機能になってもゴミ
マイクロソフトはofficeとvisualstudioの統合を早急に行うべき 昔は紙の束やノートや本をもってコードを書いていたんだよ
冗談抜きで
その本は洋書だた
教授の本棚から借りてくるの メソッド名が○○createなのか○○Createなのかcreate○○なのかCreate○○なのかcreates○○なのかCreates○○なのか
Cだと○○creatという線もある
○○.create最強すぎる gccオプションでstaticを封じるとかあればいいのにw 仮想関数技術でstatic関数みたいにできなかったっけ?
staticも静的占有修飾子という名称を聞いたことあるだけで
あんまくわしく知らない。違うところのファイルも仮想関数
使うとstaticとおんなじようにできるんじゃなかったっけ? algol60で新しく導入された従来の構文とは直交(orthogomal)する
ブロック(block)構文内で計算した結果を保存するために
一緒に導入されたのが占有修飾子own。だけれども実装に
あたっては仕様が曖昧で動的、静的、中間解釈と三通りに
解釈があって大論争。最終的にownの解釈は静的(static)
です、でstaticになった。
Simulaとかはそもそもブロック(block)の計算結果を捨てる
からいかんのだ、であんまりプログラマーになじみのない
例を題材に並列化をといてたりするからクラスベースのOOには
staticは実は固有の用語だね。 クラスがあればstaticなんて不要だよな。
逆にクラスが無いならstatic使うしか無い。 コメントに
// これはシングルトンで使ってください
って書いてけばおk リソース競合怖いならセマフォで排他すりゃいいしな。
待たせたいなら待たせればいいし。 シングルトンってどこで使うんだ?インスタンスを直接生成させたくないならManager使えばいいじゃん トンチンカンだったらすまんけど、例えばオーディオ操作するクラスとかはシングルトンだった。オーディオAPIを複数のインスタンスから叩かれてどうなるかよくわからないし。 >>131だけど正確にはCでシングルトン的な実装をしてた。classとか紛らわしい言葉使ってすまない。 Cならむしろシングルトンがデフォルトだろ。
あれで別オブジェクト同時に動かすには工夫が要るからな。 例えばタイマー機能を持つライブラリなんかはいろんなスレッドで別々に使用したくなるから別オブジェクトで同時に動かしたりするな。別オブジェクトというか別ハンドラ構造体だが。 シングルトンをどう作るor使うって、言語によってあまりにも違いすぎるから一般化無理だろw 結局どこでインスタンス生成するかを決めきれてないところがシングルトンが必要になる理由で
それは設計を見直すっていうのが根本的な治療な訳だ。 >>137
言いたいことはわかるが、「起きてはいけないことは起こらないようにする」ということを好むプログラマーがいて、彼らが作ったのがシングルトンなんじゃないの?
だからシングルトンが必要なわけでもないし治療が必要なわけでもない。 シングルトンの話題がここまで伸びるとは・・・
まあ実際使わんからな。
正規表現をstaticにするのは悪い考えだろうか?
更に言えばstatic constなら問題無い? 読み書きできるデータがどこでもドアなのは怖いけど副作用のないメソッドがどこでもドアなのはありがたい C言語のstatic宣言が、private宣言となっているのがいけない。 シングルトンにしてはいけないものをシングルトンにする輩がそこそこいるからな readは別にスコープをそこまで気にせんでもいいがwriteはあかんな。
シングルトンの問題とstaticおじさんの問題は本質的には同じ。 やっとstaticおじさんの記事見つけた。面白いな、これ。「本物のプログラマは...」ほどじゃないけど、よく煽れてる。 > プログラムのアルゴリズムとは無関係のものである。
これは何となくわかるな。
むかし、LALRパーサジェネレータ書いたことがあって、最初OOPで書いたんだけど、あまりにも冗長になったので、ドラゴンブックに載ってるような古典で書いたら、もの凄くわかりやすくなった。 big queryとかわざわざ非正規化させられるよな
公務員なっときゃよかった 構造としては完全に正規化したほうがいいのに、実際には弊害が多いってことは、DBMS側の問題のような気がするのだが。
正規化しまくっても実用に耐えられるだけの速度が出せればいい。 「構造としては完全に正規化したほうがいい」これがダウトだから速度が出ないんだろうが。
joinのコストなんてどう頑張っても限界があるわ。 >>157
完全に正規化してると人間にとって都合がよい。
速度が出せないのは機械の都合。 >>159
正規化してると人間にとって把握しやすいのはわかるがそれこそ人間の都合。
速度が出ないのは論理的必然。
という捉え方のが俺はしっくりくる。 下手に正規化しすぎると例えば3年前のデータを見たら現在の名称が表示されて大混乱、とかよくある 正規化おじさんはoracleのオプティマイザに100%の信頼置いてんのか?
いちいちヒント書くの非効率なんだが >>129
loggerとかはシングルトンがいいんじゃねーの? >>168
なかなか際どいとこだね。
分散実行するならいかんとは思うけどそこまでやるかという気もする。 >>169
俺はアンチシングルトンおじさんなんだけど、loggerだけはいいパターン見つかんなくて妥協して使ってるんだよねぇ
あとはシステム内で共有するパラメータとかも妥協的に
なんかいい手法あるかね? ■ このスレッドは過去ログ倉庫に格納されています