個人的には自己言及的で短くてマクロ使わないで読解困難という点でeastman.cがお気に入り。

http://www.ioccc.org/2011/eastman/eastman.c

そんなことはないぞ。
いまだ生きてるCOBOLの恐竜とかさ。善し悪しは別として。
あるいは数百億円投じて作られる、いわゆる基幹システムとかさ。想定する耐用年数は10年どころじゃないぞ。SAPとかEBSなんてのは、フルスクラッチなら1000億のところ、半額で作れますみたいなもんでさ。

とはいえ多くの業務アプリケーションが設計段階において耐用年数をさして考慮していないのも事実だ。想定耐用年数＝使える限りみたいな。
そんでもって将来の拡張を考慮した設計をしていない、もっといえばその能力がないのも事実だ。
そんなことを深く考えるより、お客さんのお好みが安くて早い吉野家みたいなもんになっちゃってさ。
僕らはつゆだくだのネギ抜きだのキムチ乗せだの、ほんのわずかなバリエーションはあれど、本質的にはくだらん物を量産する存在になっちまったわけだ。けどおかげさまで注文は増えたからなんとか食っていける。なんとかね。

言っとくけど、僕はそんなの良いとなんて思ってないぜ。

現実問題として、一度稼働してしまった業務アプリケーションがとっかえひっかえすることなんてほぼないですけどね。古い言語仕様、古いフレームワークのまま、年々屋根の上に屋根が重なっていく…

もちろんその屋根も青二才の書いたひどいもんなんですけどね。

こういう話はいわゆる業務アプリケーションの世界に特有なのかもね。分野によっては達人プログラマの居場所がまだまだ残ってるとこもあるんだろう。

デカくて遅いけど便利なプログラミング言語と、フレームワーク的なものの普及によって、プログラミングに関しては従来ほど経験の価値がなくなっちゃったのさ。だから青二才が見よう見まねで書いたってとりあえずは動く。

プログラミング経験の市場価値が低下している一方で、プロジェクトマネジメント面では開発現場ほどの進歩がなく、いまだ経験が（というかKKDか）幅を効かせてるから、ある程度年季の入ったプログラマはそっちに行くことを求められてる。

結局さ、僕らが追い求めてきた美しいコード、効率的なアルゴリズム等々、そんなようなものは時代遅れになっちゃったのさ。

自動車のトランスミッションだってマニュアルからオートマになっちゃったじゃん。僕らはマニュアルなのですよ。たぶん。

この話題が昼に掲載されるというのがスラドの停滞っぷりを現してる気がする。

本番環境のテーブルに対してtruncateかけるってのがよくわからん。ふつーそんなことする？
似たようなテーブルからデータを再作成って、つまりそのテーブルは不要だったかビューの類で良かったんじゃないの？

＞それはそうと、i.softbank.jp 宛ての迷惑メールが来なくなったな。
＞特に設定を変更した覚えはないのだが。

こっちはa@b.cへみんなが報告しまくったのが効いてるんじゃないですかね。

SEDなら・・・

技術的にはとても興味深いのですが、なんでこんな面倒なことしてるんですか？