言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
京都大学霊長類研究所
http://el.jibun.atmarkit.co.jp/pressenter/2010/11/1-828a.html
高学歴で長い経験に自信を持つエンジニアは他人の話を聞かなくなる、
というのは広く世に知られた真理の1つである。
K自動車ICTシステム部の三浦技術担当マネージャは、そのようなエンジニアの生き見本のような人だった。
初めに言葉ありき。私が聞いた三浦マネージャーの最初の言葉はこうだ。
「オブジェクト指向など、実業務では使いものにならない！」
私は思わず手を止めてしまい、壁を見つめた。
隣に座っていた男性プログラマも同じように手を止めて、まるで隣の会議室が見えるかのように壁をまじまじと見つめている。
声は続いている。
「オレはもう20年以上システム業界にいるけどな、その長い経験から言うと、オブジェクト指向なんてものは、
理論としては面白いけど、およそ実用的とは言い難いものだな。まぁ、例えばGUIのコンポーネントとかは
オブジェクト指向に基づいて作られているようだから、そういうツールとかを作る人には必要なものなのかもしれない。
しかし君たちがいずれ作ることになる業務アルゴリズムにはまったく無縁のものだと思ってもらって間違いない。
どうもこの業界、オブジェクト指向でなければダメ、というような風潮がまかりとおっているけどな、
オブジェクト指向なんか本当に使っている人はほとんどいないよ。オレも少し勉強してみたけど、カプセル化とかポリ何とかとか、
どうにも利点が理解できなかったね。実際、実業務で使ったことなどないしな……」
おいおいおいおい。私は思わず壁の向こうの顔も知らない講師に突っ込んだ。もちろん心の中で、だが。
――あなたはオブジェクト指向をほとんど使ったこともないくせに、
オブジェクト指向は「使えない！」と断言しているわけですか？
http://el.jibun.atmarkit.co.jp/pressenter/2011/02/post-6b95.html
疲労による脱落者を数人出しながらも、3月末に何とかカットオーバーした――というかさせた――新部品調達システムは、
4月1日に本番稼働した。三浦マネージャは自分の功績を大いに吹聴したらしいが、
その栄華はほとんど1日しか続かなかったとのことだった。
初日から立て続けにいくつかの機能でトラブルが発生した。最初のうちは、本番サーバと予備サーバを切り替えることでしのいでいたものの、
数日後に、とうとうシステムを停止せざるを得なくなった。同じようなコードをコピペして、複数のモジュールで使っていたため、
バグが複製されてしまったのが原因だったようだ。無用なドキュメント作成に時間を取られたために、
十分なテストができなかったことも遠因だったに違いない。数々のトラブル対して、
大量のドキュメントがまったく役に立たなかったのは言うまでもない。
それでも三浦マネージャは、「この程度のバグは、新しいシステムの初期段階では大抵起こりうる程度にすぎない」などと
強気な発言をしていたらしい。が、バグを修正することが新たなバグを作り込んでしまうという悪循環が続き、
新部品調達システムは、予定の半分以下の機能だけが辛うじて稼働しているだけになってしまった。
とうとう業を煮やした経営層が、トラブルシューティング専門のコンサルティング会社に、システム全体の調査を依頼した。
三浦マネージャはICTシステム部だけで対応できると言い張ったらしいが、すでにその言葉を額面どおりに受け取る人間は少なくなっていた。
ソースを調査したコンサルティング会社のエンジニアは、あまりに効率の悪い
前時代的なコーディングに絶句したらしい。そりゃそうだろう。私だって、事前知識なしであのソースを見たら驚く。
「時代錯誤も甚だしい」
「保守性というものをまった考慮していない」
「最低でも6カ月を要する、根本的な大改造が必要」
「オブジェクト指向など、実業務では使いものにならない！」
間違いない。あの人だ。
日記の内容はというと、「私は20年以上、企業システムのプログラミングを続けているが、
その中でオブジェクト指向などというものが役に立ったことは一度もない」と始まっていて、
「staticを使えば、わざわざインスタンスを作る必要などない」
「独自にクラスを作る必要などない。クラスは使うものだ。作るものではない」
「20年にわたる経験から明白である」
と、どこかで聞いた言葉が並んでいる。
吹き出したのは、
「……私はカプセル化もポリモリズムも意味がよく理解できなかった。従って私はこれは不必要なものだと結論づけた……」
のくだりだった。案の定、コメント欄は炎上状態だった。
最初の方では、懇切丁寧にオブジェクト指向の利点を解説してくれている人たちもいたのだが、
「あなたの経験は何年だ？ 私は20年だ」
「あなたの出身校はどこだ？ 私はT大学大学院卒だ」
「あなたはSIerだろう。私は客側の人間だ。客の言うことは絶対だ」
などのように、火に油どころか爆弾を投下するような発言が続いたため、親切なコメントはなくなっていた。
その後も、たまに覗いてみると、
「ベテランが提案する非オブジェクト指向開発」
「使えるパターンと使えないパターン」
「デザパタなどは時間の無駄である」
といったタイトルの日記が定期的に更新されていた。中身はというと、自分が理解できないことを経験だけで批判しているか、
オブジェクト指向を解説しているWebサイトのささいな誤字脱字を針小棒大に批判するか、どちらかでしかなかった。
たまに別のWebサイトのコメント欄に、オブジェクト指向批判を書くこともあった。当然、技術的な裏付けも何もない、
思い込みによる批判だから、正論で完膚なきまでに叩きのめされてしまう。正面から議論を展開できるだけの知識がないから、
スリービーチさんにできることは、「その日本語はおかしい」とか「若い人はすぐに感情的になるから議論にならない」などと、負け惜しみを書くことだけだった。
すでに俺は考えてある。
まともな職場教えてくれよ。
社内用のライブラリとか無いのか？
プロジェクトが破綻した理由とオブジェクト指向やデザパタがつながってないように見える
まず無いと思うけど、ちょっと前までは自前で作ってた。
フレームワークのコードを見ればわかるけど
継承や各種オブジェクト指向のオンパレード。
それ（フレームワーク）によって何が持たされるかというと、
大幅な開発効率の向上。
あるものを使ってるだけだと、オブジェクト指向の恩恵に
気づかないかもしれないけど、自分でフレームワークに近いものを
作るようになれば、そのメリットが分かる。
ようは下っ端はわからない。
こういった老害は、どんな方法論を与えても同じことを繰り返す
ライブラリ作るときは使いまくるけど
似た奴を２個目つくるときは再利用するだろ。で、３個目も考慮して一部ライブラリ化される。
共通部分をライブラリやフレームワークとして分離する。
そのライブラリやフレームワーク側でオブジェクト指向を使う。
だから、それらを使うだけの人は、誰かが頑張ってくれたお陰で
自分は単純に作れると知りましょう。
そうかなぁ？
それらを非オブジェクト指向でラップしちゃってもやっぱり同じことになると思うよ
オブジェクト指向関係ないじゃない
委譲を使って必要なメソッドだけを使って必要なメソッドだけを実装するほうが、仕様が爆発しなくて済む。
継承だと親のメソッドを引き継いで、下流が「なんかこんなメソッド有ったんで使っときましたよ^^」「はぁ仕様書に書いてないだろ」「いや、つかえましたよ^^」とか面倒な事が減る
javaにはC++のような多重継承がない。
これは多重継承みたいな事をやりたいときは多重委譲にしろって事なのかもね。
でも委譲で十分じゃんとは思う。オーバーライドの整合性を考える余計な労力が減るし。
俺等は使う側なので極度の抽象化は作業効率が落ちるだけ
それとライブラリ制作にもまた複数あると思う
ＭＳみたいに一度リリースしてしまったら不具合も含めて仕様・・・となってしまうライブラリ制作と
同じ会社のどっかのライブラリチームみたいに不具合がみつかり次第修正
仕様も簡単に変えて修正してもらいますじゃ適用するもんが全然違う
そりゃ、使う側から見れば
おなじに見えるだろうなｗ
だけど、作る側の開発効率がぜんぜん違うわけで。
オブジェクト指向は言語にあらず。
非オブジェクト指向言語でも
オブジェクト指向で作られてる。
オブジェクト指向で作るならば
オブジェクト指向言語が相性がいい。
じゃ、ＭＳのライブラリを使ってるという視点でみれば
必ずしもオブジェクト指向は正しい選択じゃないと
そういえるわけだよね？
> 俺はライブラリ制作側と使う側のスタイルは分けて考えないとダメだと思ってる
> 俺等は使う側なので極度の抽象化は作業効率が落ちるだけ
極度の抽象化が必要になったら、それはライブラリとして
分離するべき所ってこと。そうすればもっと作業効率が上がる。
だがまともな技術とセンスを持った人がいなければ使いにくいものができてしまう。
だけどそれはただだの、「技術力が低いと使いにくいものが出来る」という
当たり前の話しに過ぎない。
>だがまともな技術とセンスを持った人がいなければ使いにくいものができてしまう。
その場合のオブジェクト指向の使用の有無はどういう風に影響を及ぼすわけ？
とりあえず会社的には特定の技術者に特別な処置をしてもらうよりも
馬鹿を長時間働かせて解決する方向へもっていきたいと考えるようだから
ご立派な人にしか理解できないはメリットにはならないと思うが
オブジェクト指向は人を選ぶのだろうか？
それは正しいかどうかを語る資格が無いだけ。
飛行機に乗るだけの俺が
航空理論はほんとうに正しいのか？なんて
議論しても意味がないだろう？
俺は航空理論を使ってなくても、飛行機乗れるといっても
何の説得力があるだろうか。
オブジェクト指向が正しいかどうかを語っていいのは、
オブジェクト指向を適用するライブラリや
フレームワーク開発者だけだ。
だから、お前には無関係の世界なんだろ？
それだけだよ。
無関係の人は語らないでくれ。
ただ、便利なライブラリやフレームワークを
作ってる人たちに感謝するのは忘れるなよ。
お前が感謝している人たちが感謝をしている
オブジェクト指向を信じろ。
なんで怒ってるの？
ＭＳの社員じゃないと発言できないぜ？
なんで、MSの社員じゃないと発言できないって思い込んでるの？
とりあえずどの規模からフレームワークと定義するの？
俺の休日に作ったコントロールのイベントをすべて監視してログに残すdllもフレームワークでおｋ？
しない。
なぜなら「ショボチン」だから。
逆に言えば、ショボチンでなければ
ライブラリ（フレームワーク？）と表現する。
ショボチンとデカチンの基準を決めてくれるかい？
これ、オブジェクト指向だろ？ｗ
あぁ、ソムリエじゃないと
ワインの味はわからないよねｗ
それはただのアプリケーションだろ。
え？
今はライブラリやフレームワーク開発者じゃないと
このスレで語るに値しない
って発言から参加権があるかどうかを決定してるのだよ
君は話がわかっているのかい？
非オブジェクト指向言語でやるようなオブジェクト指向プログラミングを、
オブジェクト指向言語でやってたりするんだろうか。
うん。感謝はしろ。
だけど、良し悪しは語るな。
は？
日本語でおｋよ？
仕事をしていないで、
単に（オブジェクト指向で作られたものを）
使うだけのやつは語る資格ないってことだよ。
お前が便利に使っているものに
オブジェクト指向が使われてるのに
それを否定して説得力があると思うか？
関係ないラインがあるってさっき自分で言っただろｗ
だからライブラリ、フレームワーク開発者に参加者を絞ったんだろ
自分で言っといて忘れるなよクズ
発言があまりにもクズ過ぎる
コンパイラーがエラーを出さない限り正しい。
悪名が広まって結構なことだ。
ムキになって否定してそうなのが余計ムカツクこのタイプ。
こんなのがいると、ifの行の最後にに{を書く奴がマシに見えてしまう。
下手に凝って、納期を外したらあほやろ？ ニーズに応じて作りこんで行けばいい。
その次に作った Go でそういう風に構文を変更した程だぞ。
}
else if () {
}
普通降格だろ？
if () {
} else if () {
} else {
}
http://el.jibun.atmarkit.co.jp/pressenter/2010/11/1-828a.html
高学歴で長い経験に自信を持つエンジニアは他人の話を聞かなくなる、
というのは広く世に知られた真理の1つである。
K自動車ICTシステム部の三浦技術担当マネージャは、そのようなエンジニアの生き見本のような人だった。
初めに言葉ありき。私が聞いた三浦マネージャーの最初の言葉はこうだ。
「関数型言語など、実業務では使いものにならない！」
私は思わず手を止めてしまい、壁を見つめた。
隣に座っていた男性プログラマも同じように手を止めて、まるで隣の会議室が見えるかのように壁をまじまじと見つめている。
声は続いている。
「オレはもう20年以上システム業界にいるけどな、その長い経験から言うと、関数型言語なんてものは、
理論としては面白いけど、およそ実用的とは言い難いものだな。まぁ、例えばパーサコンビネータなんかは
関数型言語が向いてるみたいだから、トイ言語を作る人には必要なものなのかもしれない。
しかし君たちがいずれ作ることになる業務アルゴリズムにはまったく無縁のものだと思ってもらって間違いない。
どうもこの業界、関数型言語でなければダメ、というような風潮がまかりとおっているけどな、
関数型言語なんか本当に使っている人はほとんどいないよ。オレも少し勉強してみたけど、モナドとか参照透明性とかモノイドとかとか、
どうにも利点が理解できなかったね。実際、実業務で使ったことなどないしな……」
おいおいおいおい。私は思わず壁の向こうの顔も知らない講師に突っ込んだ。もちろん心の中で、だが。
――あなたは関数型言語をほとんど使ったこともないくせに、
Haskellは「使えない！」と断言しているわけですか？
こちらにどうぞ。
http://toro.2ch.net/test/read.cgi/tech/1331328955/
http://www.infoq.com/jp/news/2010/07/objects-smalltalk-erlang
効率が良いと思う人が使えばいいだけの話
取り除こう。
１００万行以上のプログラムを開発できるのはＯＯＰのおかげ。
世の中のOSからウィンドウシステムが消えそうだな
ウィンドウハンドラなんて概念を持ってるくらいだし、あれはオブジェクト指向じゃない。
ちまたにあふれるニセooよりよほど忠実
って例えば何だよ
public:
こんなやつ
ファイルアクセスもオブジェクト指向に近い
シェルスクリプトやバッチファイルでは非OOP的だけど
大半のプログラミング言語はOOP的なところあるよね
極めてオブジェクト指向的
どっちだよw
ストリームやファイルそのものがオブジェクト指向かどうかは関係ない。
Cのファイル操作関数は非オブジェクト指向、
Javaだとストリームはオブジェクト、ファイルもオブジェクトっぽく扱える。
しかし読み込みなどのやり方がいかにもな手続き型。
fopenでインスタンス生成
以後生成したインスタンスを渡してサービスを呼び出す
オブジェクト指向だと思うが
関数ポインタ+構造体でまんまオブジェクト指向な作りになってるよ
コンソール出力とファイル出力とパイプ出力なんて全く別のものなのに
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
datファイルを共有するP2Pソフト o2on 17dat (286)
■暗号技術【ROUNDsurea】■ (401)
Pythonについて（アンチ専用） (781)
【自動】株式トレーディングシステム Part6【売買】 (141)
おまいら最強の麻雀プログラムしてみろよ Part5 (524)
★初心者にVisual C++を教えるスレ★ Part38 (236)
--log9.info------------------
☆☆☆TH eROCKERS～SHAKIN'☆☆☆ (687)
Ｊ・Ａ・シーザー (532)
APRYL FOOL エイプリル･フール (337)
【dat落ち】ZYYG Part.4【上等】 (471)
コシミハル/越美晴 2 (241)
◆◇◆山口冨士夫◆◇◆ (949)
バービーボーイズ 37リッスン目 【復活】 (170)
[伊勢湾]音楽家としての松本亀吉[milkteens] (826)
【Long Good-bye】浅川マキ【DARKNESS】 (217)
じゃがたら ☆ お春発売記念 (321)
ＦＥＮＣＥ ＯＦ ＤＥＦＥＮＳＥ その８ (632)
■■■■■■44MAGNUM■■■■■■ (733)
【ﾔﾏｼﾞ･ｲﾄｳ】dip the flag【ﾎﾝｼﾞｮｳ･ｵｵﾊﾗ】 (584)
【CKB】 2002年夏頃までのクレイジーケンバンド (180)
プレイグス(Plagues) (272)
【ﾌﾗﾜｰﾄﾗﾍﾞﾘﾝﾊﾞﾝﾄﾞ】ジョー山中vol.3【人間の証明】 (844)
--log55.com------------------
JUDAS CODE ジューダスコード Part5
セブンスドラゴン２００２ 葬式会場 2日目
ＲＰＧにありがちなこと2
【PSP】ラグナロク～光と闇の皇女～ 5周目
【PSP】俺の屍を越えてゆけ 神様成長スレ【俺屍】:
RPGみたいな楽しい世界に生まれたかった ２周目
【PSP】エルミナージュⅢ アンチスレ【暗域直系】
【DS】アイテムゲッター【ドットも打てる】