なぜ「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 高階関数なんてありふれてるだろ。
それを偉そうにとは？
使ったことないの？ プログラミングは経験つめば抽象的な概念を使って具体的な整理がしっかりできる世界だろ。 >>84 出世するためにプログラミングしてるの？
だとしたら手段と目的を履き違えてるよ
そうでないのなら「出世するプログラム」でも書いて世の中に出したら良いｗ >>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○○なのかCreateｓ○○なのか
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だけはいいパターン見つかんなくて妥協して使ってるんだよねぇ
あとはシステム内で共有するパラメータとかも妥協的に
なんかいい手法あるかね？ >>170
パラメータについては引数なりクラスメンバなりで渡した方が良いとは思う(システム内で変更があるなら)
loggerについて言い訳を用意するならば、基本的な動作は追記であって変更でないから
致命的な問題になりにくいというものはあるかも。 ただ追記するだけのロガーなら確かにシングルトンである必要はあんまないわな
わざわざ別インスタンスを生成する理由も同様にないから、つまりそんなに悩むほど重要な問題じゃない 自分、ないしは自社で使うだけならシングルトンである必要はないんだろうけど、ライブラリとして公開するようなものなら間違った使い方をされることもありうるからシングルトンにしておきたくなったりしない？ >>171
やっぱ引数になるよねぇ
そうすると扱いやすくはなるんだけど、深い依存メソッドまでパラメータ届けるのがどうしても嫌になっちゃう どんなアプリもシングル起動なんだから、そこに書けばいいだけだよな。 >>163
普通信頼置かない。そもそも機械的にオプティマイズできてそれが最善で
あるなら人間いらなくなる。
ただ機械的オプティマイザーを超える方法がわからないが 今日は2019年3月2日だ。
DBによって日付が違うと動作不良を起こすがありゃなんでだ？ >>175
ある程度の大きさのクラスを用意するとかかね。
それを継承して使いまわすとか。。
あんま大きすぎるとstatic変数やglobal変数と変わらんしあんまり良くないかな。
後はそれでも引数で渡しまくる。
実際cのプロジェクトで全ての関数はロガーを引数にするってなところもあった。
これはこれで確かにモジュラリティーは高くはなる。が面倒でもある。 よくわからないし想像できないが炭におけないな。そんなプロジェクト 炭になってくれればいいんだけど、生焼けのままゾンビとして何年も残り続けるからタチが悪い ■ このスレッドは過去ログ倉庫に格納されています
