なぜ「staticおじさん」は叩かれたのか？

**デフォルトの名無しさん** · 2019/02/08(金) 15:18:48.58

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

**デフォルトの名無しさん** · 2019/02/26(火) 21:49:06.18

シングルトンの話題がここまで伸びるとは・・・
まあ実際使わんからな。

正規表現をstaticにするのは悪い考えだろうか？
更に言えばstatic constなら問題無い？

**デフォルトの名無しさん** · 2019/02/26(火) 23:45:48.96

>>140
自分の意見を言えよ！（激おこ

**デフォルトの名無しさん** · 2019/02/27(水) 00:27:53.77

シングルトンと書いて"どこでもドア"と呼ぶ

**デフォルトの名無しさん** · 2019/02/27(水) 08:19:37.48

読み書きできるデータがどこでもドアなのは怖いけど副作用のないメソッドがどこでもドアなのはありがたい

**デフォルトの名無しさん** · 2019/02/27(水) 08:36:57.25

C言語のstatic宣言が、private宣言となっているのがいけない。

**デフォルトの名無しさん** · 2019/02/27(水) 17:50:25.07

シングルトンにしてはいけないものをシングルトンにする輩がそこそこいるからな

**デフォルトの名無しさん** · 2019/02/27(水) 18:43:11.68

readは別にスコープをそこまで気にせんでもいいがwriteはあかんな。
シングルトンの問題とstaticおじさんの問題は本質的には同じ。

**デフォルトの名無しさん** · 2019/02/28(木) 18:19:05.20

やっとstaticおじさんの記事見つけた。面白いな、これ。「本物のプログラマは...」ほどじゃないけど、よく煽れてる。

**デフォルトの名無しさん** · 2019/02/28(木) 18:51:23.07

> プログラムのアルゴリズムとは無関係のものである。
これは何となくわかるな。
むかし、LALRパーサジェネレータ書いたことがあって、最初OOPで書いたんだけど、あまりにも冗長になったので、ドラゴンブックに載ってるような古典で書いたら、もの凄くわかりやすくなった。

**デフォルトの名無しさん** · 2019/02/28(木) 22:23:17.58

>>130
Factoryだった

**デフォルトの名無しさん** · 2019/03/01(金) 18:22:50.40

>>100
うむうむ

**デフォルトの名無しさん** · 2019/03/01(金) 20:23:46.44

害悪はDBの正規化おじさんのが上逝ってる。

**デフォルトの名無しさん** · 2019/03/01(金) 20:25:22.77

非正規化おじさん？

**デフォルトの名無しさん** · 2019/03/01(金) 20:38:01.31

縁起の悪い呼び方やめれ

**デフォルトの名無しさん** · 2019/03/01(金) 20:44:23.08

big queryとかわざわざ非正規化させられるよな
公務員なっときゃよかった

**デフォルトの名無しさん** · 2019/03/01(金) 20:50:19.05

構造としては完全に正規化したほうがいいのに、実際には弊害が多いってことは、DBMS側の問題のような気がするのだが。
正規化しまくっても実用に耐えられるだけの速度が出せればいい。

**デフォルトの名無しさん** · 2019/03/01(金) 21:28:27.41

「構造としては完全に正規化したほうがいい」これがダウトだから速度が出ないんだろうが。
joinのコストなんてどう頑張っても限界があるわ。

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

オブジェクト指向は宗教なので

**デフォルトの名無しさん** · 2019/03/02(土) 07:50:23.86

>>157
完全に正規化してると人間にとって都合がよい。
速度が出せないのは機械の都合。

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

>>159
正規化してると人間にとって把握しやすいのはわかるがそれこそ人間の都合。
速度が出ないのは論理的必然。
という捉え方のが俺はしっくりくる。

**デフォルトの名無しさん** · 2019/03/02(土) 09:32:08.88

いやマテリアライズドビュー使えや

**デフォルトの名無しさん** · 2019/03/02(土) 10:16:35.03

下手に正規化しすぎると例えば3年前のデータを見たら現在の名称が表示されて大混乱、とかよくある

**デフォルトの名無しさん** · 2019/03/02(土) 10:40:50.67

正規化おじさんはoracleのオプティマイザに100%の信頼置いてんのか？
いちいちヒント書くの非効率なんだが

**デフォルトの名無しさん** · 2019/03/02(土) 11:46:40.24

だからマテリアライズドビュー使え

**デフォルトの名無しさん** · 2019/03/02(土) 11:49:44.37

そうだマテリアライズドビュー使え

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

もしマテリアライズドビュー使ったら？

**デフォルトの名無しさん** · 2019/03/02(土) 14:32:26.26

待てリアライズビューが始まる

**デフォルトの名無しさん** · 2019/03/02(土) 18:49:39.39

>>129
loggerとかはシングルトンがいいんじゃねーの？

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

>>168
なかなか際どいとこだね。
分散実行するならいかんとは思うけどそこまでやるかという気もする。

**デフォルトの名無しさん** · 2019/03/02(土) 20:29:04.43

>>169
俺はアンチシングルトンおじさんなんだけど、loggerだけはいいパターン見つかんなくて妥協して使ってるんだよねぇ
あとはシステム内で共有するパラメータとかも妥協的に

なんかいい手法あるかね？

**デフォルトの名無しさん** · 2019/03/02(土) 20:53:27.86

>>170
パラメータについては引数なりクラスメンバなりで渡した方が良いとは思う(システム内で変更があるなら)
loggerについて言い訳を用意するならば、基本的な動作は追記であって変更でないから
致命的な問題になりにくいというものはあるかも。

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

ただ追記するだけのロガーなら確かにシングルトンである必要はあんまないわな
わざわざ別インスタンスを生成する理由も同様にないから、つまりそんなに悩むほど重要な問題じゃない

**デフォルトの名無しさん** · 2019/03/02(土) 21:09:02.07

>>48
非同期処理を繰り返すとき

**デフォルトの名無しさん** · 2019/03/02(土) 21:29:24.61

自分、ないしは自社で使うだけならシングルトンである必要はないんだろうけど、ライブラリとして公開するようなものなら間違った使い方をされることもありうるからシングルトンにしておきたくなったりしない？

**デフォルトの名無しさん** · 2019/03/02(土) 22:56:52.47

>>171
やっぱ引数になるよねぇ

そうすると扱いやすくはなるんだけど、深い依存メソッドまでパラメータ届けるのがどうしても嫌になっちゃう

**デフォルトの名無しさん** · 2019/03/02(土) 23:42:02.50

目的は？

**デフォルトの名無しさん** · 2019/03/02(土) 23:44:27.56

どんなアプリもシングル起動なんだから、そこに書けばいいだけだよな。

**デフォルトの名無しさん** · 2019/03/02(土) 23:48:01.36

>>163
普通信頼置かない。そもそも機械的にオプティマイズできてそれが最善で
あるなら人間いらなくなる。
ただ機械的オプティマイザーを超える方法がわからないが

**デフォルトの名無しさん** · 2019/03/02(土) 23:51:49.69

今日は2019年3月2日だ。
DBによって日付が違うと動作不良を起こすがありゃなんでだ？

**デフォルトの名無しさん** · 2019/03/03(日) 09:43:36.98

そこまでは進んでない？

**デフォルトの名無しさん** · 2019/03/03(日) 11:25:14.70

>>175
ある程度の大きさのクラスを用意するとかかね。
それを継承して使いまわすとか。。
あんま大きすぎるとstatic変数やglobal変数と変わらんしあんまり良くないかな。
後はそれでも引数で渡しまくる。
実際cのプロジェクトで全ての関数はロガーを引数にするってなところもあった。
これはこれで確かにモジュラリティーは高くはなる。が面倒でもある。

**デフォルトの名無しさん** · 2019/03/03(日) 12:46:53.97

よくわからないし想像できないが炭におけないな。そんなプロジェクト

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

炎上ののち炭になるということ？

**デフォルトの名無しさん** · 2019/03/03(日) 16:56:29.71

ネタ
https://detail.chiebukuro.yahoo.co.jp/qa/question_detail.php;_ylt=A7YWPRXdr3FTZxMA39vl_PN7?qid=11118107201

**デフォルトの名無しさん** · 2019/03/03(日) 20:04:38.79

炭になってくれればいいんだけど、生焼けのままゾンビとして何年も残り続けるからタチが悪い

**デフォルトの名無しさん** · 2019/03/03(日) 20:56:46.98

>>12
コードは書くがプロジェクトに参加できない、
参加したとしても下っぱでしかやってないような視野の連中多かったイメージ

**デフォルトの名無しさん** · 2019/03/05(火) 02:04:13.63

>>39
早期リターン禁止してネスト深くするのは耐え難いわ

**デフォルトの名無しさん** · 2019/03/05(火) 03:44:36.46

嫌ならgoto使え

**デフォルトの名無しさん** · 2019/03/05(火) 09:37:57.33

動きゃいいんだよ。
ろくに動かないもんいつまでもデバッグしてるよりマシ

**デフォルトの名無しさん** · 2019/03/05(火) 10:52:58.78

アーリーリターンがダメだからgoto使うとか、アホやかと
gotoこそ有無を言わさず全面禁止にするべきようなものなのに

**デフォルトの名無しさん** · 2019/03/05(火) 11:29:06.76

馬鹿には無理

**デフォルトの名無しさん** · 2019/03/05(火) 12:34:15.96

returnは関数の最後に集約して、帰る時はgotoで飛ばすのが正しいスタイル
アーリーreturnが悪いわけじゃなくて、アーリーgotoラストreturnがより良いってだけの事

**デフォルトの名無しさん** · 2019/03/05(火) 12:49:30.50

その使い方なら確かにgoto使うのが一番スッキリするな
アホがむやみに使うせいで悪者扱いされるgotoさんは本当に気の毒だ
つっても最近の言語だとそもそもgotoが存在しない言語も多いけど

**デフォルトの名無しさん** · 2019/03/05(火) 14:00:42.08

行き先不明のgotoより、明確に行き先が分かるreturnの方が遥かに安全だろ。

**デフォルトの名無しさん** · 2019/03/05(火) 14:46:08.15

phpにgotoがあることを今知ったわ
一律禁止しておかないと地獄のようなコードが量産されそうだなw

**デフォルトの名無しさん** · 2019/03/05(火) 22:05:45.65

大域脱出をググっているんだが
英語でなんていうのか出てこない

**デフォルトの名無しさん** · 2019/03/05(火) 22:38:10.58

staticでいいよ
オブジェクト指向が綺麗にハマるパターンなんてほとんどない

**デフォルトの名無しさん** · 2019/03/05(火) 22:48:09.33

>>196
C言語のsetjumpとlongjump？

**デフォルトの名無しさん** · 2019/03/06(水) 17:31:56.59

GOTO禁止という余計な知識は知っていても
そのGOTOがどの言語のものを指し、なぜ言われていたのかを理解していない者は少なくない
理由も経緯も理解せず、ただそれが正しいものだと信じるのであれば、それは単なる信仰にすぎない

間違っている例
「昔の8bitマイコンで動いてたようなBASICは構造化されてないからGOTOでスパゲッティになる」
「構造化されているC言語ではGOTOを使うべきではない」

GOTOを使うべきではないと”有名な論文”で言われていたのは
論理IF文(IF～ELSE～THEN)すらなく、何をするにもGOTOで溢れかえっていた
古い規格のFORTANがほぼ前提になっている事を理解しなければならない

**デフォルトの名無しさん** · 2019/03/06(水) 17:38:09.02

FORTRANのGOTO禁止なんてFOR-NEXT外から中への突入だけだろ
それ以外は禁止なんてされてない

**デフォルトの名無しさん** · 2019/03/06(水) 17:42:00.64

まあ今時の言語なら大抵のケースにおいてgotoより良いやり方が用意されてるからな
一つ間違えたら大惨事を引き起こしかねないような代物をあえて使う理由もない

◆QZaw55cn4c · 2019/03/06(水) 18:27:54.11

>>201
＞今時の言語なら大抵のケースにおいてgotoより良いやり方

そんなものがあるのでしょうか？かなり疑問です…

**デフォルトの名無しさん** · 2019/03/06(水) 18:39:59.24

try～catchとか後藤さんが嫌われて活躍してるじゃん。

◆QZaw55cn4c · 2019/03/06(水) 18:44:25.89

>>203
try～catch＝SetJumpLongJmp ですか…たしかに一本とられました

**デフォルトの名無しさん** · 2019/03/06(水) 19:25:13.11

「GOTOを地上から消し去れ！とにかくGOTO表記を消し去れ！聖典にそう書いてあるというのを聞いたことがある！！」
置き換え可能な全ての機能をGOTOで置き直せ、と強制されているわけでもないのに
GOTOの4文字を目にした途端に発狂して「GOTOは悪魔の文字だ！使うな！」とわめき始める

GOTO否定教の信者さんは大変だな

**デフォルトの名無しさん** · 2019/03/06(水) 19:42:48.36

ラベル付きの break, continue が現れたことで goto 文は息の根を止められたのでは?

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

下向きgotoはそこまで悪いとは思わない
gotoと並行してフラグ変数作りまくるのを勘弁して欲しい

**デフォルトの名無しさん** · 2019/03/06(水) 20:17:08.11

後藤「差別やめれ」

**デフォルトの名無しさん** · 2019/03/06(水) 20:40:00.08

本当はメソッドに切り分けまくれば良いんだが
一番キツイのはメソッドの名前を考えること
カプセル化は名前を考える労力を減らすってのが一つの役割かもしれん

◆QZaw55cn4c · 2019/03/06(水) 20:45:55.18

>>206
そのラベル付き、というのは goto に「言語上の」縛りを加えただけなのでは？バイナリーでは単なる jmp 文であるところにお節介な縛りをつけただけなのでは？

**デフォルトの名無しさん** · 2019/03/06(水) 20:52:20.84

後藤さんは関数内ならどこにでも飛べちゃうから嫌われるんだよ。
あれが無けりゃいい奴なのに。

**デフォルトの名無しさん** · 2019/03/06(水) 20:53:23.93

昔のBASICはIF　THENのあとに行番号を書いておけばそこにジャンプした
実際はGOTO
それを利用してGOTOを排除したって言ってた人がいて雑誌にそのプログラムが乗ってた

編集者も意地悪だなってｵﾓﾀ

**デフォルトの名無しさん** · 2019/03/06(水) 21:56:50.08

自分がプログラム始めたての頃にgoto文を知ったときは、なるほどコレを使って処理を分けていけばいいんだな！と思ってgotoだらけになったからな。
その辺がgotoが悲劇を生み出す背景な気がする。

**デフォルトの名無しさん** · 2019/03/06(水) 21:59:49.13

Learn C the hard wayが昔は無料で読めたんだけど、その中ではgotoをエラー時にリソース開放で使ってたな
あれは用途が明快で構造をシンプルに保つ唯一の手段だと納得した覚えがある

**デフォルトの名無しさん** · 2019/03/06(水) 23:18:10.15

後藤さんは上向きに移動できる時点で使ってはいけないもの

**デフォルトの名無しさん** · 2019/03/07(木) 10:59:20.21

finallyみたいなもんか

**デフォルトの名無しさん** · 2019/03/07(木) 14:05:33.75

goto禁止なのはCPUの先読みキャッシュ再読み込みのペナルティが増えるからだろ

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

>>217
そんなの普通にループ処理でも分岐処理でも発生してるがな。

**デフォルトの名無しさん** · 2019/03/07(木) 21:55:15.93

アセンブラレベルではgotoのようなものしかないけどな

**デフォルトの名無しさん** · 2019/03/07(木) 22:02:14.39

もともとgotoみたいなものしかないけど意味レベルで使い方を分ければ素のgotoは使いどころが少ないので
なるべく使わないでねって事

◆QZaw55cn4c · 2019/03/07(木) 22:31:49.66

>>220
その「意味レベルでの使い分け」とか本当に意味のある縛りなんですか？

**デフォルトの名無しさん** · 2019/03/07(木) 22:32:42.31

ダイクストラさんがこの現状見たら泣くぞ。。

**デフォルトの名無しさん** · 2019/03/08(金) 02:37:01.56

誰？

◆QZaw55cn4c · 2019/03/08(金) 02:41:59.12

>>223
https://ja.wikipedia.org/wiki/%E3%82%A8%E3%83%89%E3%82%AC%E3%83%BC%E3%83%BB%E3%83%80%E3%82%A4%E3%82%AF%E3%82%B9%E3%83%88%E3%83%A9

**デフォルトの名無しさん** · 2019/03/08(金) 08:51:45.91

ダイクストラはかく語りき

**デフォルトの名無しさん** · 2019/03/08(金) 09:03:00.94

gotoが悪玉視されたのは、関数やサブルーチンって概念が薄くて巨大な関数が鎮座するプログラムが横行していたからじゃないのかな？
１０００行のメソッドの中のgotoなど地獄でしか無い

**デフォルトの名無しさん** · 2019/03/08(金) 09:08:17.49

1000行のメソッド自体が地獄

**デフォルトの名無しさん** · 2019/03/08(金) 09:26:43.81

>>226
昔はもっとすごいよ。goto文で前のループにつっこんだり、前のifにつっこんだりと本当のスパゲティが存在した。

**デフォルトの名無しさん** · 2019/03/08(金) 10:04:51.16

2019年にもなってgotoに執着してるのはやばいだろ、逆張りにもほどがある

**デフォルトの名無しさん** · 2019/03/08(金) 10:43:55.93

二重三重のループから脱出する手段としてはgotoとreturn、フラグの３択となる場合が多いが
gotoにしてメソッドの数を減らすやり方があってもいいとは思うんだけどね
俺はなんとなくreturn使っているが

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

>>230
戻り先が明確なreturnが一番安全安心。
gotoなんてその時良くても、手が離れて改修されて何年か後に見てみたら違う意味になってたりするから怖いわ。
フラグは時系列的に前後関係がある場合には仕方ないから使い方次第だ。関数内スコープしか無いフラグは面倒なだけだわ。

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

>>231
それだよな。
gotoは書いたその瞬間だけは別に問題がないけど、どこかに変更が加わった瞬間に魔物と化すリスクが大きすぎる。

**デフォルトの名無しさん** · 2019/03/08(金) 13:54:56.17

gotoはウィザードにしか使いこなせないがウィザードはgotoの危険性も別の安全な手段も熟知しているので使用しない
結論としてgotoはいらない子

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

>>228
そりゃすごい...というか、それならgotoは有害、って言われるのも頷ける

>>233
例外禁止/例外がない言語だとリソース解放はgoto一択では？

**デフォルトの名無しさん** · 2019/03/08(金) 14:25:55.23

gotoじゃリソース解放してくれないだろ。

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

リソースの開放を忘れて、return で上位関数に戻るよりは、
リソース開放の処理を、関数末尾に集めて、
goto で必ずそこを通るようにしてから、
関数の終わりで上位関数に戻るようにした方が、良いのでは？
という意味なんだと思いますよ。私は。

**デフォルトの名無しさん** · 2019/03/08(金) 15:09:24.29

goto自体がリソース解放の命令だなんて言ってないよｗ
エラー時のリソース解放にgotoが有益、っていう話

if ((err = create_resource_00(args..., &res00)) goto error_00;
if ((err = create_resource_01(args..., &res01)) goto error_01;
if ((err = create_resource_02(args..., &res02)) goto error_02;
...
return 0; // success
...
error_02: destroy_resource_01(res01);
error_01: destroy_resource_00(res00);
error_00:
return err;

という感じで

**デフォルトの名無しさん** · 2019/03/08(金) 15:16:05.87

上のやつはまとめてリソースを確保するだけの処理と仮定してるので、+αで何らかの処理まで行うなら>>236の言う通りです

**デフォルトの名無しさん** · 2019/03/08(金) 15:17:16.15

COBOL級のレガシー言語ならしかたない

**デフォルトの名無しさん** · 2019/03/08(金) 15:37:58.89

リソースハンドル捕まえてんだからそう慌てて解放する必要も無いんだぞ。
何らかの準備処理に失敗して戻って来たら、後片付け処理呼べばいいだけだからな。