消えてなくなれよ >オブジェクト指向 part.2

　　　　　　　＿＿＿_
　　　　　　／＼　　／＼　ｷﾘｯ
　　　　　／　（ー）　（ー）＼
　　　　／　　 ⌒（__人__）⌒ ＼　　
　　　　|　　　　　|r┬-|　　　　|
　　　　＼　　　　 `ー'´　　／　
　　　　ノ　　　　　　　　　　　　＼
　／´　　　　　　　　　　　　　　ヽ

　　　　　　＿＿＿
　　　　　　　／　　　　＼
　　　　　／ノ　　＼　　 u. ＼　！？
　　　　／（●）　（●）　　　＼　
　　　　|　　（__人__）　　　u. 　 |　ｸｽｸｽ>
　　　＼　u.｀ ⌒´　　　　　／
　　　　ノ　　　　　　　　　　　＼
　／´　　　　　　　　　　　　　　ヽ

　　　
　　　　　　　　＿＿＿_
<ｸｽｸｽ　　／　　　　　＼！？？
　　　　　／　　u　　ノ　　＼
　　　　／　　　　 u （●）　　＼
　　　　|　　　　　　　　（__人__）|
　　　＼　　　　u　　　.｀ ⌒／
　　　　ノ　　　　　　　　　　　＼
　／´　　　　　　　　　　　　　　ヽ

11 ：デフォルトの名無しさん：2009/03/22(日) 12:05:33

ぶｗｗｗｗ　バッドタイミングｗｗ >>9スマソｗ

12 ：デフォルトの名無しさん：2009/03/22(日) 13:18:51

なんで、工数の見積もりを下げたがるの?
Cの工数と同じでいいんでないの?

13 ：デフォルトの名無しさん：2009/03/22(日) 13:23:05

>>12
それはＣ＋＋が工数に対してなんのメリットもないことを意味するけどいいの？
って話（俺は無いと思ってるけど）

14 ：デフォルトの名無しさん：2009/03/22(日) 14:25:46

むしろ増えるだろ

15 ：デフォルトの名無しさん：2009/03/22(日) 14:52:08

工数の見積もりは増やして、実際の工数は減らすのがいいことだろ?

16 ：デフォルトの名無しさん：2009/03/22(日) 15:24:37

だから、お前らはバカかと言ってるんだよ。
工数なんて古い頭の経営者の言葉なんだよ。

17 ：デフォルトの名無しさん：2009/03/22(日) 15:26:27

現場の見積もりでもバンバン出てくるけど……。
結局、何人月という数字に落とさないと、人を売る商売としては受注できない。

18 ：デフォルトの名無しさん：2009/03/22(日) 16:06:31

だからそういう経営がクソだといっている。

19 ：デフォルトの名無しさん：2009/03/22(日) 16:13:34

土方の元締めなら当たり前

20 ：デフォルトの名無しさん：2009/03/22(日) 16:35:14

そういうタコ部屋で働かなきゃならないような奴ってどれだけ対人能力低いんだろう。
普通、技術力が低くてもある程度のコミュニケーション能力があればもうちょっとマシな職場でも採用してもらえるだろうに。

21 ：デフォルトの名無しさん：2009/03/22(日) 16:37:25

>>18
はぁ？じゃどういう数字で仕事してるの？

正直、プログラマの単価がクズ過ぎて工数勝負のジリ貧状態じゃん
仕様を握ってる奴は強いけどソースしかもってない奴は明らかに弱いね
日本の開発会社なんてマジで吹けば飛ぶぐらい弱い
ああ、じゃ、明日からインド人か中国人に倍の人数使ってやらせますからいいですよ
っていわれたらそこでＥＮＤなぐらい弱い
どんな付加価値もたせたら工数計算（＝人件費）の呪縛脱出できるのかマジで聞いてみたい

22 ：デフォルトの名無しさん：2009/03/22(日) 16:40:17

>>20
腐っても一部上場企業だが、事情は大して変わらんよ。

>>21
中国の人件費と動員力は半端じゃないからな。技術力もある奴はあるし。
とっとと豊かになって人件費も上がってくれという切実な願いｗｗ

23 ：デフォルトの名無しさん：2009/03/22(日) 16:40:56

仮にＣ言語しか使えない人の単価が４０万
Ｃ＋＋が使える人の単価が４５万だったら

全部のソースをＣ言語で組みなおせといいたい
Ｃ＋＋で組むことは付加価値にはならねーよ

まったく同じ単価で
Ｃ＋＋で組むと保守とか・・・～・・・で結局Ｃ＋＋で組んだほうが安いんですよ
なんて誰が信じるか馬鹿
常識で考えろよ
っていうか会社で仕事やってから書き込んでくれマジで

24 ：デフォルトの名無しさん：2009/03/22(日) 16:44:17

>>23
その場合、Cなら４５MM、C++なら４０MMとかの見積もりになるんじゃないの？

25 ：デフォルトの名無しさん：2009/03/22(日) 16:47:24

>>24
算数もできないの？

26 ：,,・´∀｀・,,）っ-○◎●：2009/03/22(日) 16:50:34

インドのITは月1800円の下っ端に支えられてる

27 ：デフォルトの名無しさん：2009/03/22(日) 16:51:40

開発工数は言語よりも技術者の質による部分が大きいから言語比較には使えない。
OOはむしろ保守の工数で効いてくる。

28 ：デフォルトの名無しさん：2009/03/22(日) 16:56:41

>>25
MMって何か知ってるか？

>>27
まともに実装されなかったOOの悲劇もすごいよー。

29 ：,,・´∀｀・,,）っ-○◎●：2009/03/22(日) 16:58:34

man * month ?

30 ：デフォルトの名無しさん：2009/03/22(日) 17:00:48

>>29
正解！

31 ：デフォルトの名無しさん：2009/03/22(日) 17:02:49

マイクロソフトがOOで儲ける方法のお手本を見せてるじゃん

32 ：デフォルトの名無しさん：2009/03/22(日) 17:20:05

>>22
俺はSEだが、人材管理からなにから何まで任せてもらってるよ。
金金うるさく言わずにお友達みたいに楽しくやってる。

33 ：デフォルトの名無しさん：2009/03/22(日) 17:23:05

最悪、俺一人で全部やろうと思えばやれるが、プログラマには修練も兼ねて仕事させてやってるよ。

34 ：デフォルトの名無しさん：2009/03/22(日) 18:38:31

>>32
自分の恵まれた状況が他でも通用すると考えますか？

35 ：デフォルトの名無しさん：2009/03/22(日) 19:21:31

>>34
俺が技術者として経営者を育てたからこそ今の状況があるわけで、
技術者だからといって経営に口を挟まずにおとなしくしていたら余計に悪い状況になるってことだよ。

36 ：デフォルトの名無しさん：2009/03/22(日) 19:39:13

>>35
社内政治か。
気弱な俺には無理ｗ

37 ：デフォルトの名無しさん：2009/03/22(日) 21:17:33

>>35
ユーザ企業のSEか？
それなら社内の予算だからどうにでもなるだろうが。

ところでそれ、事実上SEよりちょっと上の役職じゃね？

38 ：デフォルトの名無しさん：2009/03/22(日) 22:26:27

>>35
つまり技術者が好き勝手できるようになり、給料もたっぷりもらえるようになるには
技術で頑張るより経営者を育てたほうがいいということですね。参考になります。

39 ：デフォルトの名無しさん：2009/03/22(日) 23:01:38

両方やればいいんじゃね？

40 ：デフォルトの名無しさん：2009/03/22(日) 23:20:24

技術者が経営者を育てるとかｗｗ

41 ：デフォルトの名無しさん：2009/03/22(日) 23:55:58

>>40
別に不思議なことじゃないだろ。
モノ売りは技術あってこその商売なんだから。

42 ：デフォルトの名無しさん：2009/03/23(月) 00:03:54

経営者ってのは「一番偉い人」というわけじゃない。
モノを売ることを担当している責任者というだけだ。

社長とかいうポジションを作ってる古臭い日本の会社じゃ技術者がないがしろにされるのも無理はない。
事実上、経営責任者＝社長であって、社長が技術者を傘下に置く形になるから、
技術者は対等に話をすることが出来ない。

43 ：デフォルトの名無しさん：2009/03/23(月) 00:13:12

>>42
経営を担当してるに決まってるだろ。
営業しかやらない社長ってなんだそれｗｗ

44 ：デフォルトの名無しさん：2009/03/23(月) 01:13:06

経営者としては技術者と対等に話しをしたいんだけど、
技術者の視野が狭すぎて話ができない

45 ：デフォルトの名無しさん：2009/03/23(月) 01:40:14

それを何とかするのは経営者の仕事だろうねえ

46 ：デフォルトの名無しさん：2009/03/23(月) 04:07:55

>技術者が経営者を育てるとかｗｗ
昔はあったけどね

47 ：デフォルトの名無しさん：2009/03/23(月) 15:09:16

前ｽﾚの終わり頃はいい流れだったのにな…
糞みたいな話はマ板でやれ。

48 ：デフォルトの名無しさん：2009/03/23(月) 15:13:53

前スレの終わりってどのへんよ？ｗ
前スレの終わりの流れこそ、今のこの流れとお見受けするが。

49 ：デフォルトの名無しさん：2009/03/23(月) 16:50:41

済まん、終わり頃じゃないな。
700台の後ろから800台の後ろまで。うち7割程度。

50 ：デフォルトの名無しさん：2009/03/23(月) 17:03:23

>>49
お前が良い流れと呼んでいるのもそうでないと思っている流れも全部俺が作った流れです。

51 ：デフォルトの名無しさん：2009/03/23(月) 17:26:20

脳内でな。

52 ：デフォルトの名無しさん：2009/03/25(水) 01:42:02

ケンカはやめて（＞＜）

53 ：デフォルトの名無しさん：2009/03/28(土) 04:53:32

ちなみに俺にとっても良くないと思われる流れも全部俺が作った流れです。
(オナニー回路発動)

54 ：デフォルトの名無しさん：2009/03/29(日) 19:05:24

流れを作ったというより、
火病、全レスで、スレを埋めただけでは。

55 ：デフォルトの名無しさん：2009/04/05(日) 22:39:39

OOの意義については色々議論され、答えは出尽くした感がある。
だが、大事なことがあえて黙殺されている。

それは、アマチュア避け、馬鹿避けとしての役割だ。
ど素人でも馬鹿でも、コマンド並べればプログラミングできるなら
何かしら作れてしまう。
例えば、GNU Awkはawkの分際でソケット通信ができたりするので、
素人でもなんちゃってネットワークプログラミングができる。
Tcl/Tkを使えば簡単にGUIプログラミングができる。

そういった言語が少数派なのは、素人や馬鹿に玄人と同じ物を作れてはムカつくし
玄人の多くが仕事を失うからだ。
非OOのスクリプト言語で100行以内で書ける物でも、OOで長々と書けば金が取れる。
それこそがプログラマにとっての理想なのだ。

56 ：デフォルトの名無しさん：2009/04/05(日) 22:45:51

別にそんなことないし

57 ：デフォルトの名無しさん：2009/04/05(日) 23:23:32

delphiとかで、俺みたいな雑魚でもソフト作れるからな。
プロのお前らからしたら腹立つのもわかる。
でもOOはいらんw

58 ：,,・´∀｀・,,）っ-○◎●：2009/04/05(日) 23:37:48

元々ソケットプログラムでダブルオーは要らないと思うんだが。
BSD Socket自体、クラス化されたもんじゃないし

59 ：デフォルトの名無しさん：2009/04/05(日) 23:41:34

# gawkによるなんちゃってHTTPD

BEGIN {
httpsrv = "/inet/tcp/12345/0/0"
RS = ORS = "\r\n"
while (1) {
if ((httpsrv |& getline) > 0) {
print "HTTP/1.x 200 OK" |& httpsrv
print "Content-type: text/html" |& httpsrv
print "" |& httpsrv
print "HELLO" |& httpsrv
}
close(httpsrv)
}
}

# "HELLO"と表示するだけのオモチャだが、
# 他の言語だったらもっと苦労するはず
# こんなに簡単で許されるのか？
# 必死で勉強してるプロが見たらキレるのも無理はない

60 ：デフォルトの名無しさん：2009/04/05(日) 23:46:55

perl -e `print "HELLO\n"`

61 ：,,・´∀｀・,,）っ-○◎●：2009/04/05(日) 23:49:28

#!/usr/bin/env/ruby
require 'webrick'
srv = WEBrick::HTTPServer.new({:DocumentRoot => '/home/dango/public_html/',
:BindAddress => '127.0.0.1',
:Port => 10080})
srv.mount('/hoge.pl', WEBrick::HTTPServlet::CGIHandler, 'hanami_dango_umeee.rb')
srv.start

# GAWK(笑)
# 非オブジェクト指向言語はとろくさすぎんだろｗｗ

62 ：デフォルトの名無しさん：2009/04/05(日) 23:56:04

>>61
そもそもプロと張り合ってないから。
俺はまったくの素人だし。
動きゃ何でもいいなら、素人でも作れるって例を示しただけの話なんでね。

ぶっちゃけ、「こんなんで金取るなよ」って思うような、
俺でもちょいと苦労すれば作れる程度のボログラムで金取ってる奴が許せんのさ。

何で動いてるか、どう作られたか、なんて普通の人にはどうでも良くて、
安くてちゃんと動けば良いわけ。
一般人が自力で作れる道具があれば、無駄金払わなくてすむし、
ゴミ作って金取る連中を抹殺できるわけ。
それが来るべき超情報社会の理想。

63 ：,,・´∀｀・,,）っ-○◎●：2009/04/05(日) 23:57:23

#!/usr/bin/env ruby
# の間違いですな
# ちょっと書き換えるだけでちゃんとＤocumentRootのHTMLファイルを表示させることも可能ですし
# ApacheのRewrite-Engine相当(静的HTMLに偽装)のこともできます。

64 ：デフォルトの名無しさん：2009/04/05(日) 23:59:54

>>61
webrick反則だろｗｗｗ
>>62
そのセリフは>>61と同等のHTTPサーバをgawkで「ちょいと苦労して」
動かしてから言ってみよう。安くたってちゃんと動かないと意味無いよ。

65 ：,,・´∀｀・,,）っ-○◎●：2009/04/06(月) 00:00:57

うちはもっぱらRuby on RailsとかASP.NETばっかしです。

WebまわりでCやC++を使ってるのはみたことがない
いや、いっぺん昔の上司にゴリ押しでCでCGIを作らされたが（俺はせめてPerlにしてくれと言った）
なにげに似非Ajaxにも対応した。めちゃしんどかった。

66 ：デフォルトの名無しさん：2009/04/06(月) 00:01:16

>>64
inetd叩けばシェルスクリプトでも出来っけどな

67 ：,,・´∀｀・,,）っ-○◎●：2009/04/06(月) 00:05:27

そもそも>>60のはWebサーバじゃなくてサーバで動くCGIじゃないのか？
CもCGIならソケット触る必要ないよ。

68 ：,,・´∀｀・,,）っ-○◎●：2009/04/06(月) 00:06:27

いや、単体でいけるのかな？

69 ：デフォルトの名無しさん：2009/04/06(月) 00:12:26

とりあえず、普通の会社で要求されるのは、
通信できます。管理できます。検索できます。集計できます、って類だろ。
勘定系だのだと簡単に済ませられんだろうけど、
普通の会社で業務管理やる場合に必要なのは
単純にそういった類なわけ。
文字列をチョコマカやり取りするだけのサバクラシステムだったらそれこそ
ダサいgawkでもできてしまうし、
管理できます、検索できます、集計できますという類も、
シェルスクリプトやらRDMSやらを組み合わせて使えば何となくできるわけ。

美しいかどうか、最新理論に基づいているかどうか、
そんなことはどうでもいいわけ。
結果が同じなら安くて簡単なほうがいい。

一般の人を骨抜きにして、そういった程度のことすらできない人だらけにしてしまったのは、
結果としてゴミ作ってる人の生活を保証する意味しかないだろ。

70 ：デフォルトの名無しさん：2009/04/06(月) 00:13:26

体力ある会社でも自社で専門の部署なり人なりを抱えず
未だにボッタ屋に外注してるのは何なんだろうな。

新人一年間勉強させて保守任せたら発注3割になった。
確実に効果ある。

まぁ研究所で保守専門ってのもアレだけど。

71 ：,,・´∀｀・,,）っ-○◎○ ：2009/04/06(月) 00:25:22

花見に団子どうぞ

72 ：デフォルトの名無しさん：2009/04/06(月) 00:34:53

>>69
時々awk使い人来るけど、同じ人？

とりあえずHTTPヘッダ手作りしている時点でそのノリで
作っていたら安くなるものも安くならないだろと思った。

単に例えだと言うのであれば、例が悪い。HTTP周りの
ライブラリを持つ言語に手軽さで勝てるわけがない。

73 ：デフォルトの名無しさん：2009/04/06(月) 00:37:16

メインルーチンの処理をSPE置き替えないと性能が出なかったCELLと違って、
今回変るのはグラフィック部だけだから、わりと移行は楽なんじゃないの？
GPUなんて元々超並列処理なんだし、遅延処理とか並列レンダリングみたいな、メニーコア向けにそのまま使えそうな技術もすでにある。
あ、epicがCellも絶賛してたっていうのなら話しは別。

74 ：デフォルトの名無しさん：2009/04/06(月) 00:37:42

何か定期的にgawk厨を見かけるような気がする

75 ：,,・´∀｀・,,）っ-○◎●：2009/04/06(月) 00:39:22

webrickは標準ライブラリだからな。
RailsならMongrelのほうがいいけど。

たぶんRuby最大の敵は言語仕様を気分でコロコロ変えてしまう
まつもとゆきひろ

76 ：,,・´∀｀・,,）っ-○◎●：2009/04/06(月) 00:48:13

>>73
gehanikaere

77 ：デフォルトの名無しさん：2009/04/06(月) 01:29:52

プロはOOのライブラリで儲けるもんだろ?

78 ：,,・´∀｀・,,）っ-○◎●：2009/04/06(月) 01:49:22

System.out.println("俺がガンダムだ");

79 ：デフォルトの名無しさん：2009/04/06(月) 03:36:14

会社で使われてるだけの人間が偉そうなこと言うなよｗ

80 ：デフォルトの名無しさん：2009/04/06(月) 06:51:13

rubyが一番簡単だという人は
どうしてHSPみたいなのが素人に受けるのか理解できないんだろうね

81 ：デフォルトの名無しさん：2009/04/06(月) 08:58:00

hspとかawkのソースは門外漢が見ても何やってるか検討がつくからね。
勉強してないと、rubyはよくわからん単語とコロンの羅列にしか見えない。

82 ：デフォルトの名無しさん：2009/04/06(月) 09:18:58

awkも素人にはわけわからんだろ。

83 ：デフォルトの名無しさん：2009/04/06(月) 09:35:18

いつもの人を通訳。

俺の自慢のawk！
OOPって何だかは知らないが不要！
awkで何だって出来てしまう、たぶんね！
OOPなんて威張ってるだけ、たぶんね！
おまいら俺をさっさと褒めれ！

84 ：デフォルトの名無しさん：2009/04/06(月) 09:43:43

OOマンドクセ、って言われるのは
独特の作法や世界観を学習しなくちゃならんからでそ。
構造化パラダイムまでなら、公式丸暗記して
数式並べるだけの受験数学と変わらないけど。

85 ：デフォルトの名無しさん：2009/04/06(月) 11:11:02

>>84
> 独特の作法や世界観を学習しなくちゃならんからでそ。

「lambda あれば解決なのに、なんで無名クラス作って...」とかか？

86 ：デフォルトの名無しさん：2009/04/06(月) 11:34:01

初心者にいちばんわかりやすいのはschemeだろ

87 ：デフォルトの名無しさん：2009/04/06(月) 11:54:35

ははっわろす

88 ：デフォルトの名無しさん：2009/04/06(月) 11:57:09

scheme以上に単純な言語、ほかにあるか？

まさかBrainfuckとか言うなよ。
極端なことを言うやつは誰からも信用されないぜ。

89 ：デフォルトの名無しさん：2009/04/06(月) 12:18:12

なにを以って単純というのかと小一時間。
ストレスなく書けるだの、驚き最小限だのとのたまってる
はてな辺りのRubiest(笑)と同じにしか聞こえんな。

90 ：デフォルトの名無しさん：2009/04/06(月) 12:36:09

>>89
はてな辺りのRubiest批判ｋｗｓｋ

91 ：デフォルトの名無しさん：2009/04/06(月) 12:51:33

導入の分かりやすさなら確かにそうかもしれない。
何でCやjsみたいな難解な言語が入門向けに使われるんだろう。

92 ：デフォルトの名無しさん：2009/04/06(月) 12:58:04

多数派こそ正義だから

93 ：デフォルトの名無しさん：2009/04/06(月) 13:34:38

>>89
> なにを以って単純というのかと小一時間。
実用言語としての仕様書の分厚さ

94 ：デフォルトの名無しさん：2009/04/06(月) 13:40:41

BASICよりわかりやすい言語はないと思うのだが...

95 ：デフォルトの名無しさん：2009/04/06(月) 14:25:45

Rubyは簡単に書けば他人にも分かりやすいソースが書けるが、
実際の所、標準添付ライブラリのソースは読みづらい部類。
理由は知らん。

96 ：デフォルトの名無しさん：2009/04/06(月) 15:16:14

いや、俺はrubyはわかりにくいと思う。
Haskellのほうが俺には直感的だった。

97 ：デフォルトの名無しさん：2009/04/06(月) 15:39:51

「俺には～」
少数派が良く使ういい訳

98 ：デフォルトの名無しさん：2009/04/06(月) 15:47:27

だから「俺ら」と言えと

99 ：デフォルトの名無しさん：2009/04/06(月) 19:05:38

>>96
liftやらunsafePerformIOだらけ、またはポイントフリーにこだわりすぎてわけわかんなくなってる状態のHaskell
を直感的に理解できるとはすごいですね。

100 ：デフォルトの名無しさん：2009/04/06(月) 19:26:59

モナド+遅延評価を基盤としたストリームモデル
(Haskellにもストリームという言葉はありますが、ここでは別の意味です)
でのプログラミングスタイルを理解すればデータ処理をしたいときとかはかなりシームレスに書けるよ。

101 ：デフォルトの名無しさん：2009/04/06(月) 19:32:05

お前のいう「シームレス」の定義が解らん。

102 ：デフォルトの名無しさん：2009/04/06(月) 19:47:46

>>101
シームレスとは

1. 一貫性がある
2. ハードルが低く、初心者でも違和感なく取り組める

103 ：デフォルトの名無しさん：2009/04/06(月) 19:50:54

>>100
じゃあとりあえずParsecの中身をシームレスに説明してみてくんない？
導出方法とかはいいから、GenParserとかの定義の直感的な解釈とか、
それをモナドで組み合わせる時のParsecの中身がどう展開されるかについての直感的な説明とか。

104 ：デフォルトの名無しさん：2009/04/06(月) 19:54:38

まず、なんでParsecなの？ｗ
もっとわかりやすい題材があるんじゃないの

105 ：デフォルトの名無しさん：2009/04/06(月) 19:55:26

技術的な話になるとみんなこんな感じになるのはなんとかならないの？
http://web.archive.org/web/20010602030602/www.geocities.co.jp/Bookend-Soseki/5561/

【日本語】

この状況を打破するためには早急に対策要員を選出し、その人たちができるだけ
緻密な議論を行って行く必要がある。鈴木君をプロジェクト・リーダーとして以後、
この件についての方針を模索しよう。私も状況を追いながら関わろう。

【御殿山語】

これを break threw するためには ASAPでtask fourceの team make をして、
in detail で effective な議論を go on　するのが must だ。鈴木君を
Handler としてこの issue について discuss しましょう。私も keep in touch
するから。

106 ：デフォルトの名無しさん：2009/04/06(月) 19:55:30

ただ批判したいだけのやつの質問なんか誰かが答えてくれると思ってるとしたら、お笑いだなｗ
俺って優しいなぁｗ

107 ：デフォルトの名無しさん：2009/04/06(月) 20:02:51

>>104
＞モナド+遅延評価を基盤としたストリームモデル
＞データ処理

おまえがいうそのデータ処理の一例がParsecだろwモナド+遅延評価を基盤としたストリームモデルのw
あれ、わかりやすいんじゃないの？シームレスなんじゃないの？

ちなみにHaskellは俺も好きだよ。ただ直感的だとは全く思わないけどね。

まあとりあえずここにいるみんなが直感的にわかるように説明希望。
ちなみに俺には直感的な説明はできない自身があるよ。

108 ：デフォルトの名無しさん：2009/04/06(月) 20:05:06

ASAPで頼む

109 ：デフォルトの名無しさん：2009/04/06(月) 20:28:16

石橋貴明と誰だっけ工藤静香だっけ、

110 ：デフォルトの名無しさん：2009/04/06(月) 20:28:46

>>107
> ちなみにHaskellは俺も好きだよ。ただ直感的だとは全く思わないけどね。
批判したいだけのやつがよく使うフレーズｗ
自分は理解したうえで批判しているんだってことを証明したいからそういうフレーズを使うんだろうけど、
嘘だってバレバレですからｗ

111 ：デフォルトの名無しさん：2009/04/06(月) 20:56:45

全く先入観のない素人がいろんな言語を比較したとしたら・・・

BASIC
HSP
Ruby
Python
Perl
C
C++
Java
Lisp
Prolog

この中でどれを簡単だと答えるだろう？

俺はBASICやHSPだと思う。
はい代入、ほれ表示、ここで計算しよう・・・
ってな感じで、省略がなく流れが完全にわかり、
それでいて動的型だから変数で頭を悩ませなくて済むから。

それに対し、Rubyとかは簡潔というよりも省略されすぎで
単なる記号の羅列にしか見えないだろう。
「Rubyは簡単」という人のいう「簡単」と、
アマチュア、ホビイストのいう「簡単」は意味が違うのさ。
万人に使える言語を選ぶとすれば、OOは不合格にならざるを得ない。

112 ：デフォルトの名無しさん：2009/04/06(月) 21:22:37

BASICが一番カンタンだと思うけど、
BASICがカンタンつってもさ。
それは解く問題が小さいからであって、
その小ささのほうが要因なんじゃないか？

大きいものを書こうとすると、
BASICよりRubyのほうがカンタンだし、
場合によってはJavaのほうがカンタンだ。
OOPLは抽象度を高めるし、
静的型もやはりメリットをもたらしてる。

小さい問題に特化してBASICを持ち上げても、
ちょっと複雑な問題になったときに、
他の言語がすぐ頼もしく映ってしまうはず。

万人に使える言語っていうのが、
どのていどの問題を想定してるのかしらんが。

113 ：デフォルトの名無しさん：2009/04/06(月) 22:03:30

もしもN88-BASICをソケット通信対応させたら・・・

10 URL="http://quote.yahoo.co.jp/"
20 S=Socket(tcp, 0, URL, 80)
30 PRINT "GET ", URL => S
40 WHILE (S => INPUT) > 0)
50 PRINT $0
60 WEND
70 CLOSE(S)
80 END

これを分かりやすいと見るか、分かりにくいと見るか。
それが問題だ。

114 ：デフォルトの名無しさん：2009/04/06(月) 22:06:21

最初に行番号を入れる
という概念が俺には難しすぎて昔挫折した覚えがある
C言語で復活した

115 ：デフォルトの名無しさん：2009/04/06(月) 22:10:11

最低限構造化されていることが現代的言語としては必須だろ
だから行番号BASICやHSPは論外

116 ：デフォルトの名無しさん：2009/04/06(月) 22:17:44

構造化なんて必須でもなんでもない
ただのオナニーだ

117 ：デフォルトの名無しさん：2009/04/06(月) 22:29:34

小さいサンプルみたいなコード片を題材に、
どの言語が簡単かどうかなんてナンセンスだお（；＾ω＾）。
だってさ、それが何の役に立つ？
構造化もなくて何が出来る？

118 ：デフォルトの名無しさん：2009/04/06(月) 22:32:09

NEC PC-8001 BASIC Ver 1.5
Copyright 1979 (C) by Microsoft

OK
LOAD "消えてなくなれよ >オブジェクト指向 part.2"
FOUND:消えてなくなれよ >オブジェクト指向 part.2
OK
RUN
Syntax Error in 117
OK

119 ：デフォルトの名無しさん：2009/04/06(月) 22:51:34

構造化定理
「1つの入り口と1つの出口を持つようなプログラムは、
「順次・反復・分岐」の3つの基本的な論理構造によって記述できる」

これって当たり前じゃん。

反復１（条件）
　処理１
　処理２
反復１終わり

分岐（条件）
　処理３
（条件を満たさない場合）
　処理４

こういう感じに書くなんて馬鹿でもできる。
しかし、オブジェクト指向は説明しにくい。
犬だ猫だ、車クラスに属するカローラの燃料とナンバーがどうしたとか、
馬鹿じゃねーの？
そんな説明でわかったつもりになる奴は頭が悪い。

120 ：デフォルトの名無しさん：2009/04/06(月) 22:57:18

BASICで1000行以上のプログラムなんて、既にどっかがおかしいんだよ
小さなサンプルが云々じゃなく、プログラムそのものを小さく作れるのがBASICの魅力だろ

121 ：デフォルトの名無しさん：2009/04/06(月) 23:01:52

>>119
ＳＴＧだったら自機、敵、弾クラスを作るのがオブジェクト指向だ
別に難しくもなんともねーじゃん

122 ：デフォルトの名無しさん：2009/04/06(月) 23:02:50

>>120
それはＣ言語とBASIC当たりで同じ内容のもんを書き並べて主張しろよ
大して変わらないはず

123 ：デフォルトの名無しさん：2009/04/06(月) 23:08:18

このスレの引火性の高さ、俺好きだぜ

124 ：デフォルトの名無しさん：2009/04/06(月) 23:23:19

>>122
君の意見には賛同しかねる

BASICとCを比べるのは、小便器と大便器を比べるようなもんだ
小便器でウンコする方法を考える事は無駄だろう
だからといって、大便器で小便できるから、全てを大便器でなんて事をしたら、帰省、行楽期間の高速道路は破滅する

125 ：デフォルトの名無しさん：2009/04/06(月) 23:29:41

便器クラスに大便器と小便器というインスタンス・オブジェクトが（以下略）

126 ：デフォルトの名無しさん：2009/04/06(月) 23:31:28

>>124
何が主張したいんだよｗ

127 ：デフォルトの名無しさん：2009/04/06(月) 23:34:53

>>126
つまり、年齢と共に、羞恥心を捨て去っていった勇者達のお陰で高速道路の女子トイレは破滅から救われていると...

128 ：デフォルトの名無しさん：2009/04/06(月) 23:41:05

>>127
どうした？
yourfilehostの盗撮動画でも見すぎたか？

129 ：デフォルトの名無しさん：2009/04/06(月) 23:48:54

>>128
元気だな、エロもほどほどにしなよ

130 ：デフォルトの名無しさん：2009/04/07(火) 00:16:02

時代は今やxvideosだってのに

131 ：デフォルトの名無しさん：2009/04/07(火) 01:13:39

>>128
せっかく呆けてるんだから、ちゃんと突っ込めよ
これだから、お前の作ったプログラムは使えないんだよ

132 ：デフォルトの名無しさん：2009/04/07(火) 01:15:56

オブジェクト指向の功罪は、Perl 5を見ればよく分かるだろ。

133 ：デフォルトの名無しさん：2009/04/07(火) 03:36:18

>>111
>それに対し、Rubyとかは簡潔というよりも省略されすぎで
>単なる記号の羅列にしか見えないだろう。

Rubyって何が省略されているかな？正直よく判らない。

134 ：デフォルトの名無しさん：2009/04/07(火) 03:37:57

カッコ

135 ：デフォルトの名無しさん：2009/04/07(火) 03:48:11

RubyよりPerl派な俺って異端かな？

136 ：デフォルトの名無しさん：2009/04/07(火) 04:34:56

Rubyのチュートリアルを読む　→　「分かりやすいね！」

Rubyの入門書を読む　→　「ｲｲ! これに比べりゃ、Perlはカスだね！」

Rubyで自分のツールを書いてみる　→　「そろそろRubyの時代か」

で、他人が書いたライブラリのソースを読んでみる
↓
「なんだこりゃ、Perl並に読みづらくて意味不明……」

こんな感じ。

137 ：デフォルトの名無しさん：2009/04/07(火) 04:45:50

「なんだこりゃ、Perl並に読みづらくて意味不明……」
↓
「よし、俺がきれいに書き直してやる」
↓
「できた！　さすが俺。おまいら俺のソースを参考にしていいぞ」

こんな感じ。

138 ：デフォルトの名無しさん：2009/04/07(火) 04:50:30

Perl使いの後輩「先輩、これ意味わかんねーす」

ってか、RubyってPerl経由して入る奴多いから
リアル過ぎて笑えねーな・・・。

139 ：,,・´∀｀・,,）っ-○◎●：2009/04/07(火) 07:00:45

最近はJava畑から移ってくる人もそれなりにいるよ

140 ：デフォルトの名無しさん：2009/04/07(火) 08:47:41

rubyって日本の新興宗教団体の公用語だろ？

141 ：デフォルトの名無しさん：2009/04/07(火) 10:19:46

>>128の様な空気の読めない奴がいる限り、オブジェクト指向が広まる事は無い

142 ：デフォルトの名無しさん：2009/04/07(火) 10:25:57

別に広まらなくていい

143 ：デフォルトの名無しさん：2009/04/07(火) 11:34:39

>>142が真実。

OOPが有効な場面だけ使えばいい。
有効だと判断できる人間だけ使えばいい。

無理強いしても最悪の結果になる。

144 ：デフォルトの名無しさん：2009/04/07(火) 11:37:48

その空気が読めないから現在があるのだよ

145 ：デフォルトの名無しさん：2009/04/07(火) 11:47:43

すくなくとも３０００ステップ以上はコード書かないと
OOの必要性とかわからんだろうしなぁ。
なので入門としてBASICやPHPってのはわかるが。

146 ：デフォルトの名無しさん：2009/04/07(火) 12:12:49

>145
BASICは流行らないよ。
こんな初心者っぽい言語使えるかよ、
っていう初心者が多いから。

147 ：デフォルトの名無しさん：2009/04/07(火) 13:15:14

BASICが何の略か言ってみたまえ

148 ：デフォルトの名無しさん：2009/04/07(火) 13:20:56

>>110
やっぱただの荒らしかw
「Haskell理解できる俺スゲー」って言いたかったのはわかるけどw
みっともないからやめたほうがいいよ。実際よくわかってないみたいだしw

149 ：デフォルトの名無しさん：2009/04/07(火) 13:41:13

>>148
そんな必死に自分のほうが上だって主張しなくてもｗ

150 ：デフォルトの名無しさん：2009/04/07(火) 13:43:01

喚いているだけで、主張にすらなっていない気が。

151 ：デフォルトの名無しさん：2009/04/07(火) 13:58:17

ただ自分も地味に「Haskellの直感的な説明」に期待しているんだけど。
OOPの説明で使われる犬猫の例えがしばしば評判悪いように、異なる
アイデアに基づくものを説明するには良いたとえ話や説明の方法が
必要だと思うので。

152 ：デフォルトの名無しさん：2009/04/07(火) 14:02:30

要するに一本のベルトコンベアの上に乗ってる材料を加工する工場を想像すれば良いよ。
ベルトコンベア＝遅延リスト
加工ロボット＝関数
材料＝要素

153 ：デフォルトの名無しさん：2009/04/07(火) 14:13:22

>>149
だから全然主張なんてしてないよ。
俺の主張はただ、「Haskellは直感的だとは思わない」という事。
もし直感的に理解できるんだとしたらその説明をしてくれ、という事だよ。
君の言ったモデルに完全に合致してるParsecを例にしてね。

154 ：デフォルトの名無しさん：2009/04/07(火) 14:25:30

オブジェクト指向によるプログラムなんて、空気の読める奴じゃないと無理だろ
そして、プログラマに空気の読める奴なんて居やしない

つまりは、そういう事だ

155 ：デフォルトの名無しさん：2009/04/07(火) 14:39:18

またそうやって人のせいにする。

156 ：デフォルトの名無しさん：2009/04/07(火) 14:45:38

>>148
> みっともないからやめたほうがいいよ。実際よくわかってないみたいだしw
（意訳）
お前よりHaskellに詳しい俺がお前をテストしてやろうと思って
ちょっと面倒くさい問題を出したら答えられないでやんのｗだせぇ
もちろん俺は答えを知ってるけどね。

↑お前が書けよｗ

157 ：デフォルトの名無しさん：2009/04/07(火) 14:48:10

>>156

＞ちなみに俺には直感的な説明はできない自身があるよ。
ここは読めてないのw？

158 ：デフォルトの名無しさん：2009/04/07(火) 14:48:48

>>156
何様ｗｗ

159 ：デフォルトの名無しさん：2009/04/07(火) 14:52:17

まぁ、>>110が>>148の上から目線がうざいと思ってることだけはわかった

160 ：デフォルトの名無しさん：2009/04/07(火) 14:52:45

>>156
＞お前よりHaskellに詳しい俺がお前をテストしてやろうと思って
こんな奴なら
＞ちなみに俺には直感的な説明はできない自身があるよ。
こんなこと書かないんじゃね？

161 ：デフォルトの名無しさん：2009/04/07(火) 14:58:39

>>160
じゃあこうか？
（意訳）
お前よりHaskellに詳しい俺がお前をテストしてやろうと思って
ちょっと面倒くさい問題を出したら答えられないでやんのｗだせぇ
Haskellに詳しい俺に出来ないことがお前に出来るわけないんだよ。

162 ：デフォルトの名無しさん：2009/04/07(火) 15:06:56

>>160
そういうのはいいからはやくParsecの説明聞かせてくれよ。

163 ：162：2009/04/07(火) 15:08:12

アンカミス、
>>161へのレスね。

164 ：デフォルトの名無しさん：2009/04/07(火) 15:11:39

Parsecを知っている俺スゲーって感じですかね

165 ：デフォルトの名無しさん：2009/04/07(火) 15:13:40

>>164
Haskell知ってるなら誰でも知ってると思うよw別にすごくもなんともない。

それにそういうのはもういいからはやく直感的でシームレスな説明してよw

166 ：デフォルトの名無しさん：2009/04/07(火) 15:43:35

>>165
俺はParsec以上のことを知ってるからその程度のことしか知らないやつよりスゲーんだよ、なめなんなよ
ってな感じですかね

167 ：デフォルトの名無しさん：2009/04/07(火) 15:44:54

>>166
ひょっとして面白いって思ってる？

168 ：デフォルトの名無しさん：2009/04/07(火) 15:47:13

>>167
とりあえず頭冷やしてから戻っておいで。
顔真っ赤なやつの質問にはまともに答える気になれない。

169 ：デフォルトの名無しさん：2009/04/07(火) 15:47:41

>>168
＞顔真っ赤なやつ
それは自分のことだと思うがw。

170 ：デフォルトの名無しさん：2009/04/07(火) 16:12:23

このｽﾚは小学生のしゃべり場になりました。

171 ：デフォルトの名無しさん：2009/04/07(火) 17:23:05

オブジェクト指向なんて小学生しかやらないだろ

172 ：デフォルトの名無しさん：2009/04/07(火) 17:24:07

>>170
中学生以上は帰れ

173 ：デフォルトの名無しさん：2009/04/07(火) 17:30:24

ブビ厨大暴れかと思ったが違ったなw

174 ：デフォルトの名無しさん：2009/04/07(火) 17:53:24

ブビってなに？

175 ：デフォルトの名無しさん：2009/04/07(火) 17:55:41

Visual Basicのことだよ。
Parsecのわかりやすい解説マダー

176 ：デフォルトの名無しさん：2009/04/07(火) 17:59:47

このスレ住人ってもしかしてコミュニケーション能力低いの？

> じゃあとりあえずParsecの中身をシームレスに説明してみてくんない？
> 導出方法とかはいいから、GenParserとかの定義の直感的な解釈とか、
> それをモナドで組み合わせる時のParsecの中身がどう展開されるかについての直感的な説明とか。

人に聞きたいことがあるときは、もうちょっと謙って言うものじゃないかなぁ。
聞かれたほうが答えたくなるような質問の仕方とか身についてないのかねぇ。
ほんとに、社会人だったら当然出来なきゃおかしいコミュニケーションが出来ないと見える。

177 ：デフォルトの名無しさん：2009/04/07(火) 18:07:01

オブジェクト指向
ttp://ja.uncyclopedia.info/wiki/%E3%82%AA%E3%83%96%E3%82%B8%E3%82%A7%E3%82%AF%E3%83%88%E6%8C%87%E5%90%91

178 ：デフォルトの名無しさん：2009/04/07(火) 18:39:13

空気の読めない奴にオブジェクト指向は無理

179 ：デフォルトの名無しさん：2009/04/07(火) 18:44:58

>>176
＞質問の仕方
べつに質問してないよw。
ただ直感的な説明ができますか？って言ってるだけ。

勝手に質問だと思っちゃうきみのほうがコミュニケーション能力（笑）に問題あると思うのだが。

180 ：デフォルトの名無しさん：2009/04/07(火) 18:45:58

横レスですが。

直感的とまで言うのなら、
一言でスッと答えが出てくるものかと期待してた。

181 ：デフォルトの名無しさん：2009/04/07(火) 19:37:05

横レスですが。

「直感」って言葉で説明できるものではないと思うのですが。

182 ：デフォルトの名無しさん：2009/04/07(火) 20:20:22

もうstatic使いまくるの疲れたお

183 ：デフォルトの名無しさん：2009/04/07(火) 22:16:40

やさしい Haskell 入門読んでるんだけどさっぱりわからん
入門できなさそう

184 ：デフォルトの名無しさん：2009/04/07(火) 22:19:04

横チンですが

はみ出してますよ

185 ：デフォルトの名無しさん：2009/04/07(火) 22:37:00

>>183
どのへんがわからないか書けば誰かが直感的に説明してくれるかもよ？

186 ：デフォルトの名無しさん：2009/04/08(水) 02:30:50

じゃあ。
結局副作用だらけだとモナドだらけになって
そこでバグ入りまくりhaskellは悪くありません。
って解釈でいいの？

187 ：デフォルトの名無しさん：2009/04/08(水) 02:56:29

Haskelなんて世界中で3人しか使ってない言語イラネ

188 ：デフォルトの名無しさん：2009/04/08(水) 03:49:14

３人ってだれとだれとだれ？

189 ：デフォルトの名無しさん：2009/04/08(水) 06:32:13

>>186
俺は直感的な説明はできないしHaskellが直感的だとは思わないけど、
IOモナドだらけになって副作用関連のバグがでてもそれは
他の言語と同様にプログラマが悪いってことになるよ。
「Haskellは純粋関数型言語だから副作用関連のバグは出ない」みたいに言うエセHaskell信者は多いけどねw。

190 ：デフォルトの名無しさん：2009/04/08(水) 15:26:14

つーかHaskellで一番面倒なのが意図しない副作用が発生している場合だろ。

191 ：デフォルトの名無しさん：2009/04/08(水) 15:43:03

>>190
ちょっとどういう状況かわからないから具体的なソースを出してもらえませんか？

192 ：デフォルトの名無しさん：2009/04/08(水) 15:58:01

　　　ゴガギーン
　　　　　　　　　　　　　ドッカン
　　　　　　　　　ｍ　　　　ドッカン
　　＝＝＝＝＝）　）)　　　　　　　　　☆
　　　　　 ∧_∧ |　|　　　　　　　　　／　　　　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣
　　　　　（　　　）|　|＿＿＿＿＿　　　　∧＿∧　　　＜　　おらっ！>>103 出てこいよ
　　　　　「　⌒￣　|　　　|　　　　||　　　（´Д｀　）　　　　＼＿＿＿＿＿＿＿＿＿＿＿
　　　　　|　　　/ ￣　　　|　　　　|/　　「　　　＼
　　　　　|　　　|　|　　　　|　　　　||　　　 ||　　 /＼＼
　　　　　|　　　 | |　　　　|　　　　|　　へ//|　　|　　| |
　　　　　|　　　 | | 　　　ﾛ|ﾛ　　　|／,へ＼|　　|　 | |
　　　　　|　∧　| |　　　　|　　　　|／　　＼　　/　（　）
　　　　　|　|　|　|〈　　　　|　　　　|　　　　　|　|
　　　　 / /　/ / |　　/ 　|　　　〈|　　　　　|　|
　　　 / /　 / /　|　　　　|　　　　||　　　　　 |　|
　　　/ /　/ /　=-----=--------　　　　 |　|

193 ：103：2009/04/08(水) 16:03:28

だが。ちなみに>>189とかも俺だよ。

194 ：デフォルトの名無しさん：2009/04/08(水) 16:07:01

　　　ゴガギーン
　　　　　　　　　　　　　ドッカン
　　　　　　　　　ｍ　　　　ドッカン
　　＝＝＝＝＝）　）)　　　　　　　　　☆
　　　　　 ∧_∧ |　|　　　　　　　　　／　　　　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣
　　　　　（　　　）|　|＿＿＿＿＿　　　　∧＿∧　　　＜　　おらっ！>>100 出てこいよ
　　　　　「　⌒￣　|　　　|　　　　||　　　（´Д｀　）　　　　＼＿＿＿＿＿＿＿＿＿＿＿
　　　　　|　　　/ ￣　　　|　　　　|/　　「　　　＼
　　　　　|　　　|　|　　　　|　　　　||　　　 ||　　 /＼＼
　　　　　|　　　 | |　　　　|　　　　|　　へ//|　　|　　| |
　　　　　|　　　 | | 　　　ﾛ|ﾛ　　　|／,へ＼|　　|　 | |
　　　　　|　∧　| |　　　　|　　　　|／　　＼　　/　（　）
　　　　　|　|　|　|〈　　　　|　　　　|　　　　　|　|
　　　　 / /　/ / |　　/ 　|　　　〈|　　　　　|　|
　　　 / /　 / /　|　　　　|　　　　||　　　　　 |　|
　　　/ /　/ /　=-----=--------　　　　 |　|

195 ：デフォルトの名無しさん：2009/04/08(水) 16:55:57

>>194
うるせえ　帰れ

196 ：デフォルトの名無しさん：2009/04/09(木) 11:15:40

で、何の生産的な発言も残さないHaskell厨どこいったの？

197 ：デフォルトの名無しさん：2009/04/09(木) 11:33:46

Mutable objects are the new spaghetti code
だって。オブジェクト群でシステムを構築するってのは自然だとは思える一方、
最近の関数型の流行をみているとそれだけで上手くいくってのは安直だとも思えてくる。

http://clojure.googlegroups.com/web/ClojureConcurrencyTalk.pdf?gda=o4QTWEwAAAC2LrkjeC7f10uHiY7GOiyxd8S1xIZIP7EwK5jKxASn0y1I1OtZCnFmn_w8aWW3nzHB8Gzz9WpxuUbp_zNxpCdh_Vpvmo5s1aABVJRO3P3wLQ

198 ：デフォルトの名無しさん：2009/04/09(木) 11:40:39

>>197
オブジェクト指向が自然だ～と思ってるのはUMLみたいに図で描きやすいからだろ？

199 ：デフォルトの名無しさん：2009/04/09(木) 11:44:05

UMLで使うのってクラス図ぐらいだよな

200 ：デフォルトの名無しさん：2009/04/09(木) 11:54:35

http://gigazine.jp/img/2009/04/09/why_boy_need_parent_pic/baby_19.jpg

201 ：デフォルトの名無しさん：2009/04/09(木) 17:58:33

Haskell厨が出てくるといつも不毛な議論にスレが止まってしまいますね

202 ：デフォルトの名無しさん：2009/04/09(木) 18:07:11

>>199
むしろちゃんとUMLの全機能使って描いてるやつがいたら、UML厨(笑)とか思ってしまう

203 ：デフォルトの名無しさん：2009/04/09(木) 20:41:10

みんながいうHaskell厨って>>100と>>103どっち？

204 ：デフォルトの名無しさん：2009/04/09(木) 21:14:30

>>203
両方だろ
どっちも有益な情報出してない

205 ：デフォルトの名無しさん：2009/04/24(金) 14:30:28

sage

206 ：デフォルトの名無しさん：2009/04/25(土) 21:38:54

パターンウィーバーSysML対応プレビュー版」リリース開始！
http://pw.tech-arts.co.jp/news/index.html#pwnews200904201820

207 ：デフォルトの名無しさん：2009/05/04(月) 16:32:51

　　　　　　　＿＿＿_　　　
　　　　　　／＼　　／＼　ｷﾘｯ
.　　　　　／　（ー）　（ー）＼　　　　　　
　　　　／　　 ⌒（__人__）⌒ ＼　　　　 Haskellは偉大、理解できない奴は池沼
　　　　|　　　　　|r┬-|　　　　| 　　　　
　　　　＼　　　　 `ー'´　　／　　　　　
　　　　ノ　　　　　　　　　　　＼
　／´　　　　　　　　　　　　　　ヽ　　　　　　　
　|　　　　ｌ　　　　　　　　　　　　　　＼
　ヽ　　　 -一''''''"~~｀`'ー--､　　　-一'''''''ー-､. 　　
　　ヽ＿＿＿＿(⌒)(⌒)⌒)　)　　(⌒＿(⌒)⌒)⌒))

208 ：デフォルトの名無しさん：2009/05/07(木) 18:59:38

ハスケルはどでもいいんだが、
微分方程式の一つもたてられないような低能が
やたら OO って言いたがるのは事実だ Ww

209 ：デフォルトの名無しさん：2009/05/07(木) 20:40:51

微分方程式とプログラミングってふつうはあんまり関係しないよね。
数学分野ならまだしも。

210 ：デフォルトの名無しさん：2009/05/07(木) 21:39:52

そそプログラマが医者の診察できないじゃないか、と言ってるのと同じ

211 ：デフォルトの名無しさん：2009/05/07(木) 21:59:45

オッす、オラ低能！
数学なんて因数分解すら覚えてねえぞ！

212 ：デフォルトの名無しさん：2009/05/07(木) 22:09:11

微分方程式は忘れましたがラムダ計算は覚えています

213 ：デフォルトの名無しさん：2009/05/07(木) 22:15:26

オブジェクト指向のせいでプログラマの奴隷化が進みました。どうしてくれますか。

214 ：デフォルトの名無しさん：2009/05/08(金) 00:32:21

クライアントとしてはいいが、
実装する方は死ぬ思いする。
それがオブジェクト指向。

215 ：デフォルトの名無しさん：2009/05/08(金) 11:57:05

なんだったら良かったんだろね。

216 ：デフォルトの名無しさん：2009/05/08(金) 12:00:18

そりゃ一般人には理解できないほど難しい数式のようなプログラミング言語が良いに決まってる。
一見どんな素人でもすぐに現場に投入できそうにみえるオブジェクト指向言語なんかは間違いの元だよ。

217 ：デフォルトの名無しさん：2009/05/08(金) 12:01:05

あと、プログラマの地位と質を守るために、職業プログラマは免許制にすべき。

218 ：デフォルトの名無しさん：2009/05/08(金) 18:29:14

こりゃ無理だわ

219 ：デフォルトの名無しさん：2009/05/08(金) 22:26:20

>>209
つルンゲ=クッタ

220 ：デフォルトの名無しさん：2009/05/10(日) 00:08:36

HSPなんてゴミ言語、
シェルスクリプトなんて書く必要ない、
AWKなんて前世紀の遺物、
とかいう意見をよく耳にする。
だが、そういうプロに味噌糞言われる言語ほど
なぜかアマチュアに人気がある。

別の見方をすれば、
プロに糞呼ばわりされる言語を普及させれば
エンドユーザ・プログラミングが流行るはずなのだ。
それが良いか悪いかは別にして。

221 ：デフォルトの名無しさん：2009/05/10(日) 00:19:03

ＵＭＬが国家資格になるみたい
オブジェクト指向ブームが来る前に
勉強しちゃおうぜ
翔泳社の独習ＵＭＬいいね
ＵＭＴＰの資格も、いい本が出てる。
がんばってね

222 ：デフォルトの名無しさん：2009/05/10(日) 00:24:15

>>219
そんなの科学技術計算用の本に載ってるだろ
一般プログラマには関係ない

223 ：デフォルトの名無しさん：2009/05/10(日) 00:31:51

チンコ＝タッタ

224 ：デフォルトの名無しさん：2009/05/10(日) 00:34:23

>>220
HSPはともかくシェルスクリプトもawkも普通に使われていると
思うけどな。適材適所で。

225 ：デフォルトの名無しさん：2009/05/10(日) 00:47:54

>>220
そりゃアマチュアは微妙な要求してくる客がいないからな
かゆいところに手が届かなくても文句いうやついねーし

226 ：デフォルトの名無しさん：2009/05/10(日) 01:04:48

アマチュアなら技術的な判断でいろいろ決めていけるけど、
プロとして作る場合は技術的な判断なんて二の次で、客の要望が優先だからな。

227 ：デフォルトの名無しさん：2009/05/10(日) 02:02:55

しかも客自身何がやりたいのか判ってないこともしばしば

228 ：デフォルトの名無しさん：2009/05/10(日) 02:17:29

>>226
そういう会社に勤めてる奴は本気でかわいそうに思えるよ。
技術を売ってる会社っていうのはそうじゃないしね。

229 ：デフォルトの名無しさん：2009/05/10(日) 02:22:15

まぁそういう制限の中でどれだけ理想に近づけるかという楽しみもあるわけだが

230 ：デフォルトの名無しさん：2009/05/10(日) 02:38:09

技術を売っている会社にしても何でもかんでもHSP使ったり無理矢理
awkで開発したりはしないと思う。

231 ：デフォルトの名無しさん：2009/05/10(日) 02:53:33

またawkで十分君か。

232 ：デフォルトの名無しさん：2009/05/10(日) 02:56:23

初心者対象ならドキュメントやサポートの充実が大事
HSPはその辺がんばってる
言語仕様は文法が簡単ならOOでもそうでなくてもいいと思う

233 ：デフォルトの名無しさん：2009/05/10(日) 03:13:28

>>228
っていうか、可哀想も糞も会社の仕事だとみんなそうだろ
まず客の要望があるんだからかゆいところに手が届かないような
ツールじゃ駄目なんだよ

234 ：デフォルトの名無しさん：2009/05/10(日) 03:42:07

>>233
まずそこが違う。
客に合わせて作るんじゃなくて、作ったものをほしがってる客を探すんだよ。

235 ：デフォルトの名無しさん：2009/05/10(日) 05:43:59

うん。そのために非技術的な判断が入るのは日常茶飯事だよ。

236 ：デフォルトの名無しさん：2009/05/10(日) 07:21:47

>>234
客がほしがるように、よりエロくするのですね。

237 ：デフォルトの名無しさん：2009/05/10(日) 11:16:10

awkしか知らない人がうじゃうじゃ力説したところで、
我々プロのプログラマはOOPLを平然と選ぶ。
不便なものを選択する理由は無いからだ。

238 ：デフォルトの名無しさん：2009/05/10(日) 12:03:53

259 ：デフォルトの名無しさん：2009/04/18(土) 13:07:13
わらうw
ttp://awk.info/?doc/dsl/awkplusplus.html

object_variable = class_name.new[(optional parameters)]
object_variable.method_name(parameters)
object_variable.delete

239 ：デフォルトの名無しさん：2009/05/10(日) 12:23:00

>>237
awkは普通に便利だけどな。
それだけで何でもやろうとすると
不便になるだけで。

240 ：デフォルトの名無しさん：2009/05/10(日) 17:55:18

>>234
そんなことしてる会社長くないだろｗ
それってだって新規開拓の瞬間ぐらいじゃね？

ほらほらうちの商品こんなんですけどどない？
って売るじゃん？
でも売った後って次は「ここをこうしてほしいな～」とかいう要望を聞いて
それを金にしていくじゃん？
少なくとも新規開拓のコストや手間考えたらおいしい商売じゃん
っていうかそうやって商品や会社の信頼ってものをあげていくのが仕事じゃん？
あの会社ツール売るだけ売ってなんもサポートないよね？って思われるのってメリットないじゃん？
っていうか一度売りつけたら今度はいつまでも続くサポート地獄で儲けるのは
この業界の鉄則っていうか唯一のうまみじゃん？

例えば「○○アプリに～って機能があるけど、これをbatファイルで設定して
連続で動作できるようにしてほしい」とか「んなもん手で１００回やれよ常考」とか
切り捨てるわけにはいかないじゃん？せっかくこんな糞作業で金くれるって言ってるのに

241 ：デフォルトの名無しさん：2009/05/10(日) 18:12:28

どうも例えにawkを持ち出したり、「技術を売ってる会社」云々の
煽りに非常に既視感を感じるんだが。

242 ：デフォルトの名無しさん：2009/05/10(日) 18:24:19

>>240
～じゃん？
まで読んだ

243 ：デフォルトの名無しさん：2009/05/10(日) 18:25:11

適材適所と万能と

まぁカナヅチしか持っていない奴は、
見るものすべてが釘に見えてしまい、何でも叩こうとするってことだね

244 ：デフォルトの名無しさん：2009/05/10(日) 18:27:40

じゃんじゃん焼き

245 ：デフォルトの名無しさん：2009/05/10(日) 18:28:20

フォークで肉切ってる奴を横目に、
俺たちはナイフで肉を切る。

246 ：デフォルトの名無しさん：2009/05/10(日) 19:10:33

まぁナイフもフォークもスプーンも箸も使えた方が当然楽だし
テーブルマナーとしてもエレガント。

「用に足りる」とかいって何でもawkな人はいわば学校給食の
先割れスプーンみたいなものかな。

247 ：デフォルトの名無しさん：2009/05/10(日) 20:08:46

AWKだけの人なんていんの？
AWK使う人ってシェルスクリプトとかSQLもやってるイメージがあるんだけど。

UNIX管理者やデータベース屋なら使えて当然じゃない？
あまり使わないとしても、
あの程度使えないと恥でしょ。

248 ：デフォルトの名無しさん：2009/05/10(日) 20:14:46

必死で身に着けたawkを誇りたいんでしょ。
掛け算の七の段が得意と自称する少年がそれを連呼するように。

それを見守る周囲の人間は、ほほえましく思ってる。

249 ：デフォルトの名無しさん：2009/05/10(日) 20:20:37

>>247
過去スレにいたんだよ。社内システムをawkで内製してますawkで
いいじゃん外注してOOPなんて馬鹿でね? と騒ぎまくった人が。
Perlとawkでコード比較したりTCP80番叩いて「Webも出来る」って
豪語したりと非常に楽しいキャラクターであった。
過去形なのが残念だが。

250 ：デフォルトの名無しさん：2009/05/10(日) 21:11:34

#!/usr/bin/bash
sql()
{
mysql --user=root --password=password -e "USE jinji_kanri; $1"
}
o=$(sql "
SELECT
*
FROM
tbl_employee
WHERE
dpt_code <> 10;
")

echo "$o" | awk '$1 ~ /^104/{print}'

251 ：250：2009/05/10(日) 21:29:25

>>249
毎度どうも。
楽しいキャラでごぜえやす。
他にも中途半端ながらCやらPerlやら使いやすんで
ご期待に反してAWK至上主義者ではごぜえやせん。

所詮素人でごぜえやすから
249の先生にはかないやせんが。

あっしは別にOOPがいらねえとは思いやせんぜ。
アマとプロの技術的解離を大きくした一因だと思ってるだけでやす。

252 ：デフォルトの名無しさん：2009/05/10(日) 21:35:46

アマチュアの方がOOP理解してて、プロは理解してない奴が多いっていう現実が。

253 ：デフォルトの名無しさん：2009/05/10(日) 21:57:00

つまりOOPってそんなに必要じゃないのかな…？

254 ：デフォルトの名無しさん：2009/05/10(日) 21:58:00

OOPなんてジョークで作られたやつをセミナー屋が持ち上げただけだろ。

255 ：デフォルトの名無しさん：2009/05/10(日) 21:58:41

おまえらOOPに釣られすぎ

256 ：デフォルトの名無しさん：2009/05/10(日) 23:34:28

>>252
いや、仕事使うとその無意味さに気づく

>>253
でもこれが無意味だって気づくことでプログラミング能力は格段に上がると思う

257 ：デフォルトの名無しさん：2009/05/11(月) 01:53:45

>>256
なぜ無意味だと思うんだい？

258 ：デフォルトの名無しさん：2009/05/11(月) 02:15:18

>>257
オブジェクト指向でプログラミングしても効率よくなるなんて言葉が嘘だったことに気づくからさ

259 ：デフォルトの名無しさん：2009/05/11(月) 02:54:33

>>250
#!/usr/bin/ruby
require "dbi"
DBI.connect("dbi:Mysql:test:localhost", "root", "password") do |dbh|
　dbh.execute("SELECT * FROM tbl_employee WHERE dpt_code <> 10") do |sth|
　　puts sth.fetch_all.select{|row| row[0] == 104}.join("¥n")
　end
end

260 ：デフォルトの名無しさん：2009/05/11(月) 05:13:37

じゃあオブジェクト指向プログラミングってなんだったんだろ･･･
おもちゃ？

261 ：デフォルトの名無しさん：2009/05/11(月) 05:38:04

いろいろある方法論のひとつと認識すべき。
劇的に全てのことが幸せに変わるものではない、ってことだ

262 ：デフォルトの名無しさん：2009/05/11(月) 06:06:56

>>258
そうそう
仮にオブジェクト指向なら工数○分の１にできる？とか考えてみれば
仕様の項目から実装時間テスト時間を考えたときにオブジェクト指向にしたところで
１Ｈだって減らせないことに気づく
これではビジネスとしてまったく意味がない

263 ：デフォルトの名無しさん：2009/05/11(月) 06:36:32

unko

264 ：デフォルトの名無しさん：2009/05/11(月) 08:08:50

結局一面だけ宣伝したバカにのせられてそこだけ信じて騙された～！って騒いでるだけに見えるな（w

265 ：デフォルトの名無しさん：2009/05/11(月) 13:24:40

だからOOAの事言っているのかOOPの事言っているのか
はっきりさせようぜ。

266 ：デフォルトの名無しさん：2009/05/11(月) 13:33:22

>>264
はい、その通りです
てか、業界全体がだまされた

267 ：デフォルトの名無しさん：2009/05/11(月) 13:34:42

>>265
両方だろ、馬鹿。
だが、設計技法を発展させて一般化すればErlangにも応用可能かもな。

268 ：デフォルトの名無しさん：2009/05/11(月) 18:07:49

そういう～かもね的な意見に食傷気味

269 ：デフォルトの名無しさん：2009/05/11(月) 20:05:04

>>259
#!/usr/bin/bash
mysql --user=root --password=password -e "USE jinji_kanri; SELECT * FROM tbl_employee WHERE dpt_code <> 10;" | awk '$1 ~ /^104/{print}'

270 ：デフォルトの名無しさん：2009/05/11(月) 20:06:58

>>268
「～かもね」＝誰かやれよ

271 ：269：2009/05/11(月) 20:11:53

awkじゃなくgrepで用が足りるんだが、
>>250でawk使ってるからそれに合わせた。

短く書こうとすれば結構短くなるもんだ。

Rubyでももう少し簡潔にできるのでは？

272 ：デフォルトの名無しさん：2009/05/11(月) 20:32:55

なんで | awk '$1 ~ /^104/{print}' なんて書いてるの？
db側でやっちまったほうが手っ取り早く見えるが。
mysqlはwhere句の中で正規表現使えないのか？
postgresqlなら and foo ~ '^104'と書く。

クエリが複雑になったらRubyで書くとカンタンやね。
sshと組み合わせてリモートで処理させるときは、
シェルスクリプトでやっちゃったほうがマシなときもある。

273 ：デフォルトの名無しさん：2009/05/11(月) 20:45:15

MySQLでもREGEXPで正規表現は使えるから
そのほうが簡単だろうけど

274 ：272：2009/05/11(月) 21:24:39

あ、失礼。
> なんで | awk '$1 ~ /^104/{print}' なんて書いてるの？
部分はそもそもの発端である>>250にむけてのレス。

275 ：デフォルトの名無しさん：2009/05/11(月) 21:28:47

AWKとかどうでもいいでしょう。オブジェクト指向言語じゃないんだから。
オブジェクト指向の効率が悪いっていう証明をしてくれよ

276 ：デフォルトの名無しさん：2009/05/11(月) 21:34:40

>>272
>>250を見ると関数を定義してるから、
sql "SQL文"
で済むみたいだけど。
ruby使うともっと簡単になるの？
もし、単にSQL文並べるだけよりも楽になるなら便利だよね。

277 ：デフォルトの名無しさん：2009/05/11(月) 22:41:39

>>275
じゃあ、Ｃ言語＋構造化で組むと３ヶ月でできる仕事を
Ｃ＋＋とオブジェクト指向で組んだら何ヶ月でできる？

仕事って数字出せなきゃ駄目なんだよね・・・

278 ：デフォルトの名無しさん：2009/05/11(月) 23:11:11

>>277
おまえのところは、
アセンブラで組んだら３ヶ月でできる仕事だから、
C言語使ったら何ヶ月かかるか見積もってね
という仕事を請けてるの？

279 ：デフォルトの名無しさん：2009/05/11(月) 23:13:59

>>278
は？
お前がオブジェクト指向云々の話がしたいっていうから
比較対象でＣ言語出しただけだよ
好きなのでいいよこだわりねーし
オブジェクト指向でやると工数がどうにかなんじゃなかったの？

280 ：デフォルトの名無しさん：2009/05/12(火) 01:21:38

かくして
猿猿合戦の火蓋は切って落とされたのであった

281 ：デフォルトの名無しさん：2009/05/12(火) 04:12:27

>>272
Ruby含めてDBライブラリを持つ言語を使わないとトランザクション
とかエラー処理周りを書くのにえらい苦労すると思う。
検索専門だったりデータをガツンと丸ごとインポートする程度なら
シェルスクリプト+αもありだし実際使うけど、エラーも考慮して
継続的にデータを出し入れする「ちゃんとした」DBアプリを作るの
であればawk云々の出る幕はないと思うんだがなぁ。

とりあえず>>250はクエリで複数行を引っ張ってきてから手元で
絞り込みをかける奇妙さといい、そもそも何で正規表現使っている
のかなとか例としては謎が多すぎる。

282 ：デフォルトの名無しさん：2009/05/12(火) 09:57:10

OOPなど余計だ（キリッ）などと言っている人が、
得意満面で余計なことをAWKでしてる、という話。

283 ：デフォルトの名無しさん：2009/05/12(火) 10:07:45

>>282
いいえｗ
てか何でAWK？
俺はHaskell派なんだけど・・

284 ：デフォルトの名無しさん：2009/05/12(火) 10:18:59

>>283
お前じゃねーよｗ
>>249-251を見れｗ

285 ：デフォルトの名無しさん：2009/05/12(火) 11:50:27

企業の御用聞きにOOPは不必要だ
客に言われるがまま新しいコードを作るのにOOPなんてやってたら何時までも終わるわけがない

OOPの必要性が分かるまで、潰れないだけで、飛躍も無いけどな

286 ：デフォルトの名無しさん：2009/05/12(火) 12:12:57

レッテル貼りをした>>284が言い逃れをした、という話

287 ：デフォルトの名無しさん：2009/05/12(火) 21:37:49

使えない奴ほど偉そうだ

288 ：デフォルトの名無しさん：2009/05/12(火) 22:41:02

>>287
OO使える(と思っている)やつが、OOのメリットを明確に示せないからしかたないね。

289 ：デフォルトの名無しさん：2009/05/12(火) 23:07:05

プログラミングできる人と、プログラミングできない人じゃ同じ仕事やるのでも
まったくアプローチが違うっていうのと一緒。
プログラミングできない人は「プログラミングしなくても、Excelあれば十分じゃん」言うし、
プログラミングできる人は「awkで処理すればすぐできるのに」と思う。

290 ：デフォルトの名無しさん：2009/05/12(火) 23:22:53

小さいプログラムならOO使うまでもないわな

291 ：デフォルトの名無しさん：2009/05/12(火) 23:28:17

rubyの小さいプログラムで、ファイルの殆どを1つのアプリケーションクラスの
定義に費やして、ファイル末尾三行ぐらいでnewしてメソッド呼び出し、終了って
のを、時々見かけるけど、あのOOPは何かの役に立ってるんだろうか？

292 ：デフォルトの名無しさん：2009/05/12(火) 23:31:26

エンドユーザさんでもプログラムは組めたほうがいい。
ただ、彼らは学習に時間と金をかけられないから
何をやるにもシェルスクリプトオンリーとかawkオンリーになるわけだ。

たとえ面倒でも、他人に頼らずに目的を達することができるなら、
それはそれでアリだろう。
何でも同じ包丁で調理するのは我々から見ればナンセンスだが
彼らの立場では合理的選択なのさ。

293 ：デフォルトの名無しさん：2009/05/13(水) 05:35:27

>>291
役に立っていないと思うよ。
トップレベルの名前空間を汚したくないからクラスに隔離している
だけだと思う。今のところRubyではこれが一番簡単な方法。
グローバル変数とかの類は気分的に気持ち悪い人も多いかと。
書き捨てならともかく再利用したり他人の目に触れる可能性がある
プログラムならなおさらね。

294 ：デフォルトの名無しさん：2009/05/13(水) 05:35:27

295 ：デフォルトの名無しさん：2009/05/13(水) 07:30:23

>>288
馬の耳に念仏って言葉、知ってるか？

296 ：デフォルトの名無しさん：2009/05/13(水) 09:22:59

豚「真珠？　そんなもんイランわい！　食えるもんもってこいや！」

297 ：デフォルトの名無しさん：2009/05/13(水) 10:26:37

豚耳東風

298 ：デフォルトの名無しさん：2009/05/13(水) 11:44:05

馬の耳を付けたら、東から風がﾌｩ～っあqwsなわけねだろ～！

299 ：デフォルトの名無しさん：2009/05/13(水) 18:38:55

俺、関数型言語やったらOOのメリットわかった。
たとえば、関数型の高階関数をOOでどうやってやるんだって考えてたら
抽象メソッドを継承するって思いついた。

300 ：デフォルトの名無しさん：2009/05/13(水) 20:16:08

OOPL

301 ：デフォルトの名無しさん：2009/05/13(水) 21:26:56

>>299
関数型言語やったことねぇだろwwww

302 ：デフォルトの名無しさん：2009/05/14(木) 20:20:56

抽象メソッドを継承するって言い方初めて聞いたよ

303 ：デフォルトの名無しさん：2009/05/14(木) 23:30:06

そうやって用語がゴチャゴチャしてるのがOOのクソさ。
関数型なら引数に関数を取れる、で一発

304 ：デフォルトの名無しさん：2009/05/15(金) 02:35:47

だから、おまえは手続き型言語とOOPLを一緒にして話すなって。

305 ：デフォルトの名無しさん：2009/05/15(金) 02:38:37

オブジェクト指向って手続きの中でしか実現できない概念じゃん。
だからOOPLは手続き型言語の一種

306 ：デフォルトの名無しさん：2009/05/15(金) 03:31:36

何か変なのが沸いてきたな

307 ：,,・´∀｀・,,）っ-○○○：2009/05/15(金) 07:32:56

岡村は一応関数型かつオブジェクト指向

308 ：デフォルトの名無しさん：2009/05/15(金) 07:59:55

黎明期のOOってCLOSとかFlavorみたくLISPベースが多かったのはガン無視ですか？
現代的な言語に絞っても、Haskellにも型クラスの継承関係あるし
PrologにもOO拡張が存在するし

309 ：デフォルトの名無しさん：2009/05/15(金) 08:07:33

継承が有るとOOなんですか。斬新な考え方ですね。

310 ：デフォルトの名無しさん：2009/05/15(金) 08:30:08

継承があればOOなんて、誰がどこに書いてる？

311 ：デフォルトの名無しさん：2009/05/15(金) 09:14:31

（ﾟ∞ﾟ）ﾍﾟｰﾁｭﾝﾁｭﾝ

312 ：デフォルトの名無しさん：2009/05/15(金) 14:04:11

C++をOOと言い出した奴が悪い

313 ：デフォルトの名無しさん：2009/05/15(金) 15:33:08

C++はOOというよりマルチパラダイム指向な

禿が言ってる

314 ：デフォルトの名無しさん：2009/05/15(金) 15:36:14

ハゲ？
　　∧＿∧
　ミﾟДﾟ彡
　　∪　∪
　　し―Ｊ

誰がハゲにゃねんっ！
　　(　⌒　)
　　 | | /
　 γ⌒`ヽぷんぷん
⊂ミ,,ﾟДﾟ彡　
　/　　ﾉ∪ 　
　し―Ｊ ∥|
　　　　　ﾍﾟｼｯ!!
　　_） ∧＿∧ （_
　　⌒）　　　（⌒
　

　 γ⌒`ヽ
　ミﾟДﾟ彡
　　∪　∪
　　し―Ｊ

315 ：デフォルトの名無しさん：2009/05/16(土) 21:06:31

ならOOはどれ？

316 ：デフォルトの名無しさん：2009/05/17(日) 13:39:39

Smalltalk

317 ：デフォルトの名無しさん：2009/05/18(月) 20:48:28

OOプログラミングは、まあ役に立つこともあるんだけど…

OO分析とかOOデザインとか言ってる奴等にかぎって役に立たないのはなぜ？？？

318 ：デフォルトの名無しさん：2009/05/18(月) 21:03:27

OOはチーム全員が理解してないとあまり意味がない
理解できない子はとりあえず取り替えないとチームが成立しない

319 ：デフォルトの名無しさん：2009/05/18(月) 21:08:51

> 理解できない子はとりあえず取り替えないとチームが成立しない
その昔
「アホでも使えるようになるからOO分析とかOOデザインをやれ」
って聞いたぞwW

320 ：デフォルトの名無しさん：2009/05/18(月) 21:13:20

「パターン指向リファクタリング入門」
なんかでも作りこみすぎはダメてなことが載ってる。
時代的にまた一回りしてきたってとこかね。

321 ：デフォルトの名無しさん：2009/05/18(月) 21:55:13

>>32
まぁね、UML とか言っても、まだハード屋が使ってるビヘイビア記述に
追いついてないような気がするし、記述方法とかを理解できる奴の範囲
が限られるし…
ソフト畑って、未だにベース部分のばらつきが大きすぎるんだと思うよ

ゆとりとか何とか言ったって、ハード屋の方が粒がそろってるように見える

322 ：デフォルトの名無しさん：2009/05/18(月) 22:25:34

あのさ、「ゆとり」って言葉は元々政府の教育戦略なんだけど、
それを無能世代の別の言い方にしてしまったのは団塊世代なんだぞ。
ゆとり教育世代を批判しまくって人材を安く買いたたくためでしかない。
未だにゆとりがどうのこうの言ってるやつはそろそろ団塊世代に踊らされていたことに気づけ。

んで、当の団塊世代が定年などで一線から退いたら、今度は手のひらを返したように「今の若い人は優秀で自分たちがいかにボンクラだったか思い知らされる」
などと言っている訳なんだよ。
結局、優秀なやつは優秀で無能なやつは無能というだけ。
その数に世代は関係ないみたいだね。

323 ：デフォルトの名無しさん：2009/05/18(月) 23:15:36

>>321
文系なのにハード屋ってのはまだ少数派だろう。

324 ：デフォルトの名無しさん：2009/05/18(月) 23:52:09

>>319
OOライブラリを使わせるだけならそうだろうけど
使うだけの側のプログラマーって現実的にはありえないし

325 ：デフォルトの名無しさん：2009/05/19(火) 00:23:05

>>318
生産効率下がるじゃん

326 ：デフォルトの名無しさん：2009/05/19(火) 01:02:39

オブジェクト脳に犯されすぎて関数型に切替えるのに苦労してます(´・ω・｀)

327 ：デフォルトの名無しさん：2009/05/19(火) 02:26:04

意味不明

328 ：デフォルトの名無しさん：2009/05/19(火) 04:45:23

本物のOOはよいRubyは偉い
でもオブジェクト指向の本来はインスタンス指向なのに
巷ではすっかりクラス指向になってしまった
せっかくの良いアイディアが腐ってしまった
元を質せばC++がOOと相性の悪い静的型付けマンセーだからだ
つまり禿が悪い

329 ：デフォルトの名無しさん：2009/05/19(火) 05:04:58

関数とか変数とか名前付けるのメンドクセ

それだけのためにクラスを使っている。
他の面倒な機能は使っていない。

330 ：デフォルトの名無しさん：2009/05/19(火) 05:12:19

消えてなくなれよ->オブジェクト指向(2);

331 ：デフォルトの名無しさん：2009/05/19(火) 08:05:17

インスタンス指向って何の事？
Scalaみたいなやつ？

332 ：デフォルトの名無しさん：2009/05/19(火) 08:52:57

>>328
何言っているんだ?
インスタンス指向とクラス指向って何がどう違うんだ?
俺にはどちらも同じに感じるのだが

333 ：デフォルトの名無しさん：2009/05/19(火) 11:12:20

インスタンス指向とかいうのはケイによるプロトタイプベースのOOの別名だろう
クラス指向っていうのは多分、すっぽすっぽ先生の抽象型によるOOのこと
あと一つなんかあった気がするけど忘れた

334 ：デフォルトの名無しさん：2009/05/19(火) 12:25:31

>>325
だからイマイチ流行らねんだ。

335 ：デフォルトの名無しさん：2009/05/19(火) 13:13:31

プトタイプとクラスは違うと気が狂ったように言う奴がいるが
そいつの説明を聞いても、単なる言い方の違いとしか思えないのだが...

336 ：デフォルトの名無しさん：2009/05/19(火) 13:16:19

>>335
無いわー
JavaやC#やってた人がJavascriptに違和感なく入れるっていう人くらい詐欺話だわー

337 ：デフォルトの名無しさん：2009/05/19(火) 14:51:09

>>336
Javaやってる人がC#に違和感無く入れるって?

338 ：デフォルトの名無しさん：2009/05/19(火) 16:49:59

C#やってたけどJavascriptに違和感なく入れたよ

339 ：デフォルトの名無しさん：2009/05/19(火) 17:58:38

>>335
クラスはコンパイル時に静的に決定される。

340 ：デフォルトの名無しさん：2009/05/19(火) 19:30:01

>>339
それは静的型付けクラスベースの場合だけ。

341 ：デフォルトの名無しさん：2009/05/19(火) 20:20:29

>>339
静的とか動的と言う言葉の定義がわからん

342 ：デフォルトの名無しさん：2009/05/19(火) 21:33:33

型システムなんてコンパイラが十分賢ければ
静的だろうが動的だろうがどうでもいい

今時、最低点の型推論もしないような糞コンパイラは捨てろよ
高級言語名乗る資格なし >> ほとんどの C++

# C は高級アセンブラなので許す

343 ：デフォルトの名無しさん：2009/05/19(火) 22:06:49

C++やJavaのオブジェクト指向は整数も関数もオブジェクトではなく
クラスを持つものだけがオブジェクトという糞設計で改悪どころではないんだよ

メッセージ通信による弱い結合で柔軟に記述できるはずが
継承を繰り返して親クラスの親クラスの..とあちらこちらに依存しているという
情けないことになってしまった

Smalltalkにあったクロージャやダックタイピングというオブジェクト指向の
重要な機構は無断でどこかに捨ててしまったくせに
オブジェクト指向という名前だけちゃっかり借用してるんだ

しまいにテンプレートだジェネリクスだとマクロの変種を持ち出し
例外処理という名のGOTO文やシングルトンと呼ばれるグローバル変数を乱用し
一体どこまで悪くすれば気が済むんだか

消えてなくなるべきは紛い物のオブジェクト指向もどきだよ

344 ：デフォルトの名無しさん：2009/05/19(火) 22:12:32

完全なオブジェクト指向があったとして、誰がどう幸せになれるわけ？

345 ：デフォルトの名無しさん：2009/05/19(火) 22:15:04

>>344
「ピュアピュアリスプ
計算なんかはできないの」
ってのと、おんなじ

346 ：デフォルトの名無しさん：2009/05/19(火) 22:21:03

>>343
純血オブジェクト指向じゃ組みにくいよ
ジェネリクス・例外処理は便利

347 ：デフォルトの名無しさん：2009/05/19(火) 22:26:38

>>342
プロトタイプベースは動的バインディングでないと無理だと思う。

348 ：デフォルトの名無しさん：2009/05/19(火) 22:45:05

>>346
組みにくいなら海外でRubyがうけたりしないよ
生産性の高さ"だけ"ならRuby最強だと思ってる
Smalltalkの変態構文のこと言ってるんでしょうけどね

349 ：デフォルトの名無しさん：2009/05/19(火) 22:56:51

>>348
Rubyにbegin rescueあるだろ。
動的型付けだからジェネリクスはないが。
Rubyの生産性が高いのは認める。

350 ：デフォルトの名無しさん：2009/05/19(火) 23:27:04

>343
ダックタイピングで思い出したが、Scalaの静的ダックタイピングが超便利。

351 ：デフォルトの名無しさん：2009/05/20(水) 00:02:12

>>349
勿論、実行時にしかわからない動的な処理を行うなら
例外機構が必要なのは分かってるが
単にエラーコードを戻せばすむようなケースまで
乱用されるようになってしまったのは禿げがキチンと
説明しなかったせいじゃないかと思ってる
自分はあんまりraiseしないで使えてるし

352 ：デフォルトの名無しさん：2009/05/20(水) 08:33:56

>>343
> 例外処理という名のGOTO文やシングルトンと呼ばれるグローバル変数を乱用し

Smalltalk否定ですか。
例外処理は例外がエスケープしなければ構造化を壊さないし、
Singletonを禁じ手にしたらSmalltalkのMetaclassをどう定義しますか？

353 ：デフォルトの名無しさん：2009/05/20(水) 08:49:33

>>351
例外を嫌う理由がわからん。
メソッド呼び出しの深いところでエラーが発生したら、
いちいちエラー処理するレベルまで呼び出しを逆にたどって
エラーコードを戻すのってうっとしくないか？

354 ：デフォルトの名無しさん：2009/05/20(水) 08:55:28

例外がどういうときに例外なのか作ったやつに聞いてみないとわからないのが嫌いだな俺は
大抵わかんねーし
馬鹿に限ってドキュメントかかねーし
普通にFALSE返せばいいようなのを例外で返ってくるようなのもあるしね

355 ：デフォルトの名無しさん：2009/05/20(水) 12:11:24

>>353
それぞれの関数でエラー処理するだけだろ。
関数作るときに、それがどのくらいの深さで呼ばれてるとか
意識するべきではないし。

356 ：デフォルトの名無しさん：2009/05/20(水) 12:36:07

ドキュメンテーションされていないと使い物にならない
のは例外も関数内でのエラー処理も一緒だと思うけど。

357 ：デフォルトの名無しさん：2009/05/20(水) 12:42:54

コード＝ドキュメント

358 ：デフォルトの名無しさん：2009/05/20(水) 12:44:03

>>355
エラー処理の実装を関数側に書きたくない事って多いと思うけど。
コンソールに吐きたいとかログに吐きたいとかダイアログ出したい
とか見ないふりして先に進みたいとか、呼び出し側で決めたいこと
は少なく無いと思う。

関数内で確保したリソースの解放とか、関数内で出来る後始末だけ
してもらって後はさっさと例外投げてもらった方が使い勝手が良い
し再利用性も高いと思うけど。

359 ：デフォルトの名無しさん：2009/05/20(水) 12:47:56

メイヤーのオブジェクト指向入門の一冊目か二冊目にその話題なかった？
エラーを関数内で処理してしまうつくりは良くないとかなんとか。

360 ：デフォルトの名無しさん：2009/05/20(水) 12:56:49

>>355
＞関数作るときに、それがどのくらいの深さで呼ばれてるとか
＞意識するべきではないし。

だから例外処理がいいんだろ。
それぞれの関数でエラー処理ってそらないわ、358の言うとおり。

361 ：355：2009/05/20(水) 15:01:11

エラー処理って、関数内で確保したリソースを開放して
エラーコード返すくらいだけど？
エラーコードをどう処理するかは呼び出し側の関数で決めればいいこと。

362 ：デフォルトの名無しさん：2009/05/20(水) 15:42:34

>>361
355は直接呼び出したメソッドでエラー処理しているらしいことはわかった
おれは同じようなエラー処理をあちこちに書きたくないから例外を使う

363 ：デフォルトの名無しさん：2009/05/20(水) 17:22:38

>>361
呼び出し関係が深くなっていった場合を考えよう。
それぞれの呼び出し側でエラーを認識して、そのまた呼び出し側にそのエラーを正しく伝えなければならない。
そんなことするぐらいなら、例外で1つのハンドラで包んだほうが構造として正しいと思わないか？

364 ：デフォルトの名無しさん：2009/05/20(水) 20:08:53

>>328
Rubyってクラス指向でしょ。
クラスとインスタンスは明確に区別されている。

365 ：デフォルトの名無しさん：2009/05/20(水) 21:24:47

そういうことじゃないだろう

C++はSimulaゆずりのクラス中心の言語なのに対して、
Rubyはインスタンス中心の言語にみえる。

もともとC++やSimulaは、抽象データ型言語であっても
オブジェクト指向言語とは言われてなかった。誰かが故意に
オブジェクト指向の意味を拡大解釈したんだろうね
>>313 のマルチパラダイム指向言語ならまだ許せる

366 ：デフォルトの名無しさん：2009/05/20(水) 21:50:38

>>350
うほっScala知らなかったよ。禿が無断で削除した重要な機能が全部カムバックしとるw
関数はオブジェエクトだし、ジェネリクスはあるけどまともに型を認識する
C++のグチャグチャなエラー吐くマクロもどきはなくなってるじゃん

367 ：デフォルトの名無しさん：2009/05/20(水) 21:54:52

>>365
365の言うインスタンス中心の言語って何だよ
おれはインスタンス指向といえばJavaScriptをイメージした。
C++とRubyは静的型付けか、動的型付けかの違い。

368 ：デフォルトの名無しさん：2009/05/20(水) 22:34:34

>>363
俺は>>355とは違う人だけど
呼び出し側でそんなことする意味あんの？
仮に１００回その関数を記述したら１００箇所で同じ処理書くってことでしょ？
エラーはあくまで関数内で処理を決めるべきだと思う
そうしないと上記手間が増えるし、呼び出し側で正しいエラー対処をしないと・・・ってのがなんか気になる
だったら関数内でしかるべき処理しろよって思う

俺の理想は関数はあくまで成功したか失敗したかを呼び出し側に通知して
詳細なエラー処理はあくまでテメーでなんとかしろってのが俺流
もし、その関数の失敗の仕方が仕様に関わってくるならそれはもう
その関数は失敗していないんじゃないかと俺は思う（意味わかるかな？）

369 ：デフォルトの名無しさん：2009/05/20(水) 22:44:15

>>367
C++はまずクラスを作りそれを型紙としてインスタンスを生成する
Rubyはまずインスタンスを作りメンバーを追加する
書式を似せて同じように見せているが中身が全く違う
Rubyのクラスというのはデフォルト実装の指定であって
動的型付け言語というより型の無い言語と考えるべき
C++に後からメンバ関数を追加する簡単な方法はない

370 ：デフォルトの名無しさん：2009/05/20(水) 23:11:16

Pythonはどっちに似てる？

371 ：デフォルトの名無しさん：2009/05/20(水) 23:29:19

>>368
俺は>>363とは違う人だけど

＞呼び出し側でそんなことする意味あんの？
そんなこっとってエラー処理だよね

＞呼び出し側に通知して
＞詳細なエラー処理はあくまでテメーでなんとかしろって
これって呼び出し側でエラー処理しろってことだよね

言ってることがよくわからん。

372 ：デフォルトの名無しさん：2009/05/20(水) 23:54:37

>>371
違うってだから例外で色々キャッチさせるだろ？
こっちが例外を全部処理しなきゃいけないみたいによ
でも実際に必要なのは

BOOL transXXXX()

これ↑このBOOLだけじゃん
詳細な情報ってのは関数の中でやればいいじゃん
（だって決まったエラー対応してほしいんでしょ？）

373 ：デフォルトの名無しさん：2009/05/21(木) 00:09:55

>>367
簡単に言うと、RubyではクラスCのインスタンスaとbがあったとして、aにのみ実行中にメソッド（メンバ関数）を追加できる。
Javascriptと同様にインスタンス指向の言語と呼べると思う。

374 ：デフォルトの名無しさん：2009/05/21(木) 00:14:28

>>372
関数内でエラーが発生したら戻り値をfalseにするというのはわかった。
例えば通信用の送信関数でBOOL SendMessage(string message);
て感じのものがあって、呼び出し側SetupDeviceは何回かSendMessageを呼ぶとする
エラーリターンの場合は
int SetupDevice() {
if (!SendMessage("Init")) return false;
if (!SendMessage("Set1")) return false;
if (!SendMessage("Set2")) return false;
return true
}
void main() {
if (!SetupDevice()) printf("通信エラー");
//後続処理
}

375 ：デフォルトの名無しさん：2009/05/21(木) 00:14:44

>>337
わざとなのかもしれんが意味不明で滑ってる

376 ：デフォルトの名無しさん：2009/05/21(木) 00:18:18

つづき、例外なら
void SetupDevice() {
SendMessage("Init");
SendMessage("Set1");
SendMessage("Set2");
}
void main() {
try {
SetupDevice();
//後続処理
} catch() { //通信の例外が発生
printf("通信エラー");
}
}
で、楽だと思う

377 ：デフォルトの名無しさん：2009/05/21(木) 00:19:55

>>372
詳細な対応をしたいときはどうする？

378 ：デフォルトの名無しさん：2009/05/21(木) 00:22:56

>>377
ありえない（俺の経験上）
それは結局他の呼び出し箇所でもやらなければいけない内容であって
関数の中でやれと思う

379 ：デフォルトの名無しさん：2009/05/21(木) 00:24:26

オブジェクト指向の言語だからと、例外を使う必要は必ずしもないということか。

380 ：デフォルトの名無しさん：2009/05/21(木) 00:25:00

さらにもし、この関数がステータスを返してそのステータスの内容によって
処理を変えることが必要であるなら
そもそもこの関数はfalseを返してはいけない
この関数がfalseを返すときは出力のすべてが無効のときでなければならない・・・はず

381 ：デフォルトの名無しさん：2009/05/21(木) 00:27:43

>>373
了解、特異メソッドはインスタンス指向だと思う
objectのインスタンスに特異メソッドを追加するだけの方法で
プログラミングできるとも思う。

自分はあまり特異メソッドを使っていない。
クラス指向で組んでいる。

rubyはどちらにもなると言うことか

382 ：デフォルトの名無しさん：2009/05/21(木) 00:27:53

>>376
SetupDeviceが例外を吐いてくれるかどうかはそのソースのどこで判断するの？
後続処理のどれかが吐いてる例外かもしれないんでしょ？

383 ：デフォルトの名無しさん：2009/05/21(木) 00:41:17

>>382
だから後続処理で通信エラーが発生しても例外処理が1つで済むんだよ
SetupDeviceだけ通信エラーをトラップしたいなら
void SetupDevice()
{

384 ：デフォルトの名無しさん：2009/05/21(木) 00:43:27

>>383
そんなこと聞いてないよ
初見でみた人がSetupDeviceが例外を返す仕様かどうかをどうやって判断するか聞いてるんだよ

385 ：デフォルトの名無しさん：2009/05/21(木) 00:46:39

途中で送信してもた
だから後続処理で通信エラーが発生しても例外処理が1つで済むんだよ
そんなニーズはあまりないが、あえてSetupDeviceだけ通信エラーをトラップしたいなら
例外処理をmainからSetupDeviceに移して
void SetupDevice()
{
ｔry {
SendMessage("Init");
SendMessage("Set1");
SendMessage("Set2");
} catch() { //通信エラー
printf("通信エラー");
}
}

386 ：デフォルトの名無しさん：2009/05/21(木) 00:47:59

>>385
さっきから勝手に質問を曲解してうぜぇけど
誰もそんなこと聞いてねぇよ

387 ：デフォルトの名無しさん：2009/05/21(木) 00:49:37

>>384
ドキュメント

388 ：デフォルトの名無しさん：2009/05/21(木) 00:52:43

>>387
アフォだな
確実にセンスのねぇクラスとメソッドだな

if(!SetupDevice()){
　//エラー
}

こう書いてあったほうが何倍も読みやすいじゃねーか
例外かいて仮にこれが省略できたとしても
この仕様でソース書き続けたらクラス使ってあるたびに
元のソースかドキュメント確認して例外かえすかどうか確認しなくちゃいけないんだぞ
超面倒くせぇセンスねぇ時間ばかり使ってぇなにも産まねぇｗ

389 ：デフォルトの名無しさん：2009/05/21(木) 00:58:21

>>383
初見でみた人がSetupDeviceの戻り値が成否を返す仕様かどうかをどうやって判断する？

390 ：デフォルトの名無しさん：2009/05/21(木) 00:59:22

>>388
Win32APIってそういう形式だよね

391 ：デフォルトの名無しさん：2009/05/21(木) 01:02:34

>>390
成功のときが0で失敗のときがエラーコードのときもあるから
結局仕様を確認しないといけないから手間かかるけどな。
あげくにBOOL型を返しつつ
BOOLの中身が0と負数と正数の三種類の値を返すときもあるから
型も信用できない

392 ：デフォルトの名無しさん：2009/05/21(木) 01:17:50

>>388
俺もそのスタイルの方が、だんぜんにエラー処理がやりやすい。

結局、マジメにエラー処理をしたいかどうか、の違いだと思う。
例外ってエラー処理をマジメにやらないで済ませるためのものなんだよね。
エラー時の処理が全部同じならまとめてしまえ、っというのが例外の狙い。

だから、例外の種別ごとに処理しよう、とかマジメにやろうとすると
基本設計と矛盾しちゃうのでかえって分けの分からないことになってしまう

393 ：デフォルトの名無しさん：2009/05/21(木) 01:32:02

>>389
普通、関数のコメントに書くだろ。doxgen形式か何かで。

394 ：デフォルトの名無しさん：2009/05/21(木) 01:33:32

>>393
どういう例外を投げるかの仕様もまた同じことだろうね。

395 ：デフォルトの名無しさん：2009/05/21(木) 01:39:31

このスレは結構勉強になりますね

396 ：デフォルトの名無しさん：2009/05/21(木) 01:39:43

SetupDeviceでは例外をthrowしていないばあいでも、
SetupDeviceが使っているSendMessageが呼び出す関数が例外を投げるように
なるかもしれないというのはある。

397 ：デフォルトの名無しさん：2009/05/21(木) 03:44:54

返値がnullだったり-1だったりEOFだったりしたらエラーかも
しれない、なんて一種の暗黙知というか風習の類。

そうではない場合も少なからずあるし、結局例外にせよ返値に
せよ、どちらもドキュメントやコメント読まないと意味がない。

ただ言語によって異なるけどJavaなんかだと文法的に例外処理を
強制しているので、どのような例外が投げられるか把握して
いないとそもそもコンパイルが通らない。
なので最低限メソッドがどんな例外クラスを投げるかの情報は
コンパイラのエラー出力を読めば分かるし、メソッドのシグネチャ
にも明記してある点では分かりやすい。

398 ：デフォルトの名無しさん：2009/05/21(木) 03:50:01

>>391
>成功のときが0で失敗のときがエラーコードのときもあるから

横だが
俺いつもそれで困る。

0がエラーだったら
if（!DoHoge()）の！がびっくりした感じでなんとなくエラーっぽい外観でわかりやすいんだけど
この表記が成功だったり失敗だったりで紛らわしい。
同じ関数内で混在すると特に。

0が成功だと
if(DoFoo())のあとにエラー処理書くのがなんとなく気持ち悪い。

>>388の例みたいに
//エラー処理
って冒頭に書けばいいだけかもしれんけど

399 ：デフォルトの名無しさん：2009/05/21(木) 04:12:43

>>388
SetupDeviceがSetupDevice1を、SetupDevice1がSetupDevice2を、と深く呼び出していって、
SetupDevice10が実際にデバイスとIOしているとしよう。

おまえの書き方だと、SetupDevice1からSetupDevice9の定義は
int SetupDevice1(void) {
　　code =SetupDevice2()
　　if (code) {
　　　　do_other_initialization1();
　　}
　　return code;
}
みたいになって、9箇所でエラー処理部分と正常処理部分を切り分けなきゃならない。
そして、どのレベルでどのようなエラー回復がされるのかが見えなくなる。

例外処理を使ってかけば、エラー処理は実際にハンドラを定義している部分だけで
余計なif (code)は不要になるし、ハンドリングしている箇所を追いかけるのも、
IDEがちゃんとしていれば指定された例外をハンドラ定義している部分を簡単に見つけられる。
if (code)では一般のif文だからそうはいかない。1つ1つ関数を読んで確認しなければならない。

400 ：デフォルトの名無しさん：2009/05/21(木) 06:06:21

>>399
つ longjmp

てのはおいておいて、状況によるんじゃないの?

何らかの言語のソースをパースしているときの EOF の扱いとかだと,
EOF を読み出す状況(ソース中の位置に)よって対応が変化するので
try {
if ((token = read_token(...)) == EOF) {
eof の処理
}
} catch (io_error e) {
エラーの処理
}
の, 形で書けた方が直感的.
java みたく EOFException で返されるとソース読みにくい
慣れの問題なのかも知れないが...

401 ：デフォルトの名無しさん：2009/05/21(木) 06:10:27

>>399
はぁ？何を心配してるのかさっぱりわからない
SetupDeviceの中身なんて関係ねーんだよ
呼び出し側優先で考えて作ってくれよ

402 ：デフォルトの名無しさん：2009/05/21(木) 07:32:50

>>396
それ最悪だよね
マジでなにを確認したらいいのかわからなくなる
SetupDeviceの仕様もドキュメントも変わってないのにある日突然よくわからないタイミングで例外降ってくるよね

403 ：デフォルトの名無しさん：2009/05/21(木) 07:34:23

エラーコードだけで対応するんじゃなくて例外使った方が柔軟に対応できると思う

404 ：デフォルトの名無しさん：2009/05/21(木) 07:35:52

>>399
下手な書き方だな。

405 ：デフォルトの名無しさん：2009/05/21(木) 07:50:06

関数内でエラー処理を一ヶ所にまとめるために例外を使うことはあっても、
関数の外に例外を投げることは極力やらないようにしてる。

関数外に例外を投げるのは、例外を出す関数と例外を処理する関数が密接に関連してて、
どういうケースでどういう例外が出て、どう処理すればいいのかをそれらの関数全体で
設計するときくらいかな。

406 ：デフォルトの名無しさん：2009/05/21(木) 07:57:31

ときくらいかな
じゃなくてそんなことしないほうがいいんじゃないの？

407 ：405：2009/05/21(木) 08:04:58

そういう設計したほうがエラー処理がスマートになるときだけ。

408 ：デフォルトの名無しさん：2009/05/21(木) 08:22:01

mainでは例外が発生したら例外オブジェクトが持っているメッセージを表示するだけ。
それでは済まない場合、例えばデータベースの処理でロールバックしなきゃいけないなど、
そんなときだけ途中レベルで例外処理して、例外を再送出している。

例外使っててドキュメントが増えて難儀するなんてことはない。

>>402
396のSendMessageが呼び出す関数で例外が発生するようになるというのは仕様変更
関数の仕様変更に呼び出し側が対応するのは例外・エラーリターンどちらでも同じ

409 ：デフォルトの名無しさん：2009/05/21(木) 08:25:48

これぐらいのレベル（エラーが起きたら終わっちゃえ）ぐらいの
志しでいい場合は例外でもいいかもね

410 ：デフォルトの名無しさん：2009/05/21(木) 08:32:31

>>409
エラー起きても終わらせたくないときは途中レベルで例外処理
エラー処理を荒くもできるし細かくもできる

411 ：デフォルトの名無しさん：2009/05/21(木) 08:34:42

失敗するかもしれない関数の返値で今一番かっこいいのは、
ScalaのOption、HaskellのMaybeみたいな奴だろ。C#のNullableも近い。

412 ：デフォルトの名無しさん：2009/05/21(木) 08:35:39

>>408
それは、エラーハンドリングしなくていいプログラムの場合だろ？
SendMessageのような通信もののばあい、エラーが起きたらそのコマンド
再送するけど、数回繰り返してだめだったら最初からリトライする。
というようなわりとめんどうなエラーハンドリングしないといけないことがおおい。

413 ：デフォルトの名無しさん：2009/05/21(木) 09:02:45

この人たちは、なんで「例外処理は場合による」って言い合ってるの?
お互いに、「そうじゃない、例外処理は場合による」なんて言ってたらまとまる訳無いじゃん

414 ：デフォルトの名無しさん：2009/05/21(木) 09:07:51

>>413
前提の整理がされてないから当然の流れ

415 ：デフォルトの名無しさん：2009/05/21(木) 09:49:36

>>369
「インスタンスを作って」って言ってるけどさ、処理の内容はソースで書くじゃない
動的な配列の確保と違って、その場限りって事は無いだろ

416 ：デフォルトの名無しさん：2009/05/21(木) 09:59:50

なんだかんだ言ってもオブジェクト指向の意味がよーわからんよ。

417 ：デフォルトの名無しさん：2009/05/21(木) 10:09:35

誰も解ってないから大丈夫。

418 ：デフォルトの名無しさん：2009/05/21(木) 10:11:35

今日本で1番わかっているOOの権威って誰だろ？

419 ：デフォルトの名無しさん：2009/05/21(木) 10:32:58

ほとんどの言語で例外は非常にコストの高い処理、ということは知ってる？
俺は、プログラムが異常終了しないようにする保険みたいなものと考えてるけど

420 ：デフォルトの名無しさん：2009/05/21(木) 12:24:50

例外はメリットないな

421 ：デフォルトの名無しさん：2009/05/21(木) 15:23:45

標準入出力にstdoutとstderrの二つがあるように、関数呼び出しの
結果を戻す方法に返値と例外の2ラインがあるだけでも使い勝手が
あると思うけど。

例えば正常な返値としてnull等々も返しうる関数で、しかも時には
エラーも返したい、という場合はどう書くのかな。

422 ：デフォルトの名無しさん：2009/05/21(木) 17:47:16

>>401
> SetupDeviceの中身なんて関係ねーんだよ
> 呼び出し側優先で考えて作ってくれよ

>>399の例で言えば
SetupDevice1からSetupDevice9まで
全部「呼び出し側」なことに気付けカス

423 ：デフォルトの名無しさん：2009/05/21(木) 17:49:18

>>421
例外を投げるように作っておけば、
エラーコードを返すほうのバージョンは簡単にラッパーで書ける。

424 ：デフォルトの名無しさん：2009/05/21(木) 17:56:56

>>422
はぁ？
なんで関数の中までみないといけないの？
この時点でおかしいじゃん
馬鹿なんじゃない？

425 ：デフォルトの名無しさん：2009/05/21(木) 18:00:57

メソッドチェーンして使うような関数のエラーは例外で返して
ほしいかなぁ。
チェーンの途中でnullとか出力されるとヌルポが怖くて使えん。

426 ：デフォルトの名無しさん：2009/05/21(木) 18:20:06

>>422
>>424は関数の内部の実装なんか知ったこっちゃねぇ、ただ
APIとしてユーザに公開される関数に関しては例外を投げるな、
エラーコードで戻せ、と言いたいんじゃ無いのかな。

気持ちとしては分からないでもない。
でもどちらが良いかは実際の関数の使われ方によるんじゃないのかな。
例外で投げてもらった方が使い勝手が良い場合もあるし。

427 ：デフォルトの名無しさん：2009/05/21(木) 19:22:45

>>426
使われ方？はぁ？
言葉に気をつけろよ
１回潜ったら１００回潜っていく必要があることと等価だろ？
関数が呼んでる関数の中で呼んでる関数の仕様に翻弄されてちゃ
いつまでたっても完成なんかしないよ

428 ：デフォルトの名無しさん：2009/05/21(木) 19:51:42

そもそも例外ハンドルだらけのソースになって、美しくないんだよね
Javaもその点が残念すぎる

429 ：デフォルトの名無しさん：2009/05/21(木) 20:40:57

>425
ヌルポも立派な例外だろ。

430 ：デフォルトの名無しさん：2009/05/21(木) 23:10:09

>>419
例外処理は重いというのは良くみるけれど、今ひとつぴんとこない。
従来の関数の戻り値を見るやり方に比べて重いのは、例外発生時に例外オブジェクトを
newするという点だけだと思うんだけど間違ってる?

431 ：デフォルトの名無しさん：2009/05/21(木) 23:26:51

例外の速度なんて気にしてるのキチガイだろ
かまうな
レスをつけるな

432 ：デフォルトの名無しさん：2009/05/21(木) 23:33:35

富豪的

433 ：デフォルトの名無しさん：2009/05/21(木) 23:46:16

例外って局所的なエラーチェックに用いるものじゃないでしょ
拾い溢しを防ぐような使い方がいい

先にアプリケーションがあって、ライブラリが後から実装みたいな開発の仕方なら
例外中心のほうがいいけど

434 ：デフォルトの名無しさん：2009/05/22(金) 00:00:11

>>430
Javaの場合スタックトレース（呼び出し階層）を生成するから遅いよ。

復帰可能かつ精度が求められない演算（たとえばストリーミングで動画再生とか）での
エラー処理って言うのは、わざわざスタックトレース生成せずにそのブロックだけ
空の値を返すとか前回の演算結果をそのまま返すとかしたほうがいい。

結局はエラー処理をどう扱うかなんてケースバイケースなんだけど、
そのケースの要件とか許容範囲を精査せずに実装すると切ないことになる。

435 ：デフォルトの名無しさん：2009/05/22(金) 00:11:19

>>434
誰もそんなこと聞いてねぇよ
消えろよ馬鹿

436 ：デフォルトの名無しさん：2009/05/22(金) 00:14:48

いつの間にか「消えてなくなれよ＞例外処理」になってるｗｗｗ

437 ：デフォルトの名無しさん：2009/05/22(金) 00:42:47

>>432
時代遅れ

438 ：デフォルトの名無しさん：2009/05/22(金) 00:46:13

人間の負荷を1番気にしてください　＞＜

439 ：デフォルトの名無しさん：2009/05/22(金) 05:26:49

結局、例外ハンドラを設定し忘れてバグ出したクズPGが
自分の失敗を例外処理のせいにしてヤツアタリしている、

ということで了解。

440 ：デフォルトの名無しさん：2009/05/22(金) 06:15:39

>>439
は？
日本語読めないクズは黙ってろよ

441 ：デフォルトの名無しさん：2009/05/22(金) 06:18:58

>>388でＦＡ

442 ：デフォルトの名無しさん：2009/05/22(金) 07:20:25

だな

443 ：デフォルトの名無しさん：2009/05/22(金) 07:47:06

>>388
アフォだねえ

> if(!SetupDevice()){
> 　//エラー
> }

エラーは一種類しかないのかいw

> この仕様でソース書き続けたらクラス使ってあるたびに
> 元のソースかドキュメント確認して例外かえすかどうか確認しなくちゃいけないんだぞ

どんなポンコツIDE使ってんだよ。
どのメソッドがどんな例外をthrowするかなんてIDEがチェックできるだろ。
そのためのthrows句だ、カス。

そもそも、エラー返す場合のほうがどの関数がどんなエラーコードを返すか、
元のソースかドキュメント確認しなきゃならないだろ。

> 超面倒くせぇセンスねぇ時間ばかり使ってぇなにも産まねぇｗ

その言葉、そっくり
> if(!SetupDevice()){
> 　//エラー
> }
こういうアフォなことやる底辺PGに返してやるよ。

444 ：デフォルトの名無しさん：2009/05/22(金) 07:55:16

388に賛同する香具師って、ロクにエラーチェックもせずに垂れ流してるデジドカなんじゃね？

445 ：デフォルトの名無しさん：2009/05/22(金) 08:06:05

例外使う派だが
JavaのEOFや、VB6のCollectionのキーのない要素にアクセスしたときの例外は
例外の乱用だと思う。

446 ：デフォルトの名無しさん：2009/05/22(金) 08:06:12

>>388に賛同する奴は例外を使ったことないんだろうな

447 ：デフォルトの名無しさん：2009/05/22(金) 08:35:46

>>445
下手にNullなんぞ返されるより、例外を上げてもらったほうがナンボかマシだなあ。

448 ：デフォルトの名無しさん：2009/05/22(金) 08:36:19

>>443
一連のレスを読めばその辺の返答は全部書いてあるんだけど？

449 ：デフォルトの名無しさん：2009/05/22(金) 08:41:07

>>448
そのことごとくが的外れであることが指摘されているわけだが？

450 ：デフォルトの名無しさん：2009/05/22(金) 08:50:36

一方は、「例外を使う必要が無いところで例外を使うな」
一方は、「例外を使う必要が有るところで例外を使おう」

お前ら馬鹿だろ?

451 ：デフォルトの名無しさん：2009/05/22(金) 08:53:24

プログラマに1番大切なのは日本語コミュ力だというのは良く分かった。

452 ：デフォルトの名無しさん：2009/05/22(金) 08:57:15

あえて普及しているオブジェクト指向を見直すのがこのスレなんだし
例外についても見直せて良かったんじゃない？

やっぱりおれは例外使うけど

453 ：デフォルトの名無しさん：2009/05/22(金) 10:19:04

自演じゃなかったのか？

454 ：デフォルトの名無しさん：2009/05/22(金) 10:58:24

>>450
その前に、OOの話をしていて唐突に例外に話題が移る時点で。

455 ：デフォルトの名無しさん：2009/05/22(金) 11:04:28

>>443
> どのメソッドがどんな例外をthrowするかなんてIDEがチェックできるだろ。
> そのためのthrows句だ、カス。
どの関数が throwするかじゃなくて、実行時にどの関数が実行されるかが問題。

456 ：デフォルトの名無しさん：2009/05/22(金) 11:27:08

>>454
インスタンスが分からない人たちだからしょうがないね

457 ：デフォルトの名無しさん：2009/05/22(金) 11:39:29

例外自体は悪くないが例外の実装が悪いので使えない
言語境界とかOS境界を越えて同じバイナリを使うのが困難すぎる

458 ：デフォルトの名無しさん：2009/05/22(金) 12:02:34

なるほどね。

メソッドの実装を変更すると、投げられる可能性のある例外が変わる。
その例外を垂れ流せばインタフェースが変わってしまう。

でも、インタフェースが実装に依存するのはよくないから、
全ての例外をメソッドの内部でcatchしておくべき。

問題は、何かのミスで例外が外に漏れ出したりしないことを保証できるかどうか。

459 ：デフォルトの名無しさん：2009/05/22(金) 12:15:48

>>458
何番のレス？
＞問題は、何かのミスで例外が外に漏れ出したりしないことを保証できるかどうか。
全ての例外を握りつぶすことは簡単、例外が発生したらreturn falseするのも簡単
} catch {
return false;
}

460 ：デフォルトの名無しさん：2009/05/22(金) 12:27:15

>>459
処理系にもよるだろうけど、
中でスレッド起こしてたら、例外は別ルート通っていってキャッチできなくね？

461 ：デフォルトの名無しさん：2009/05/22(金) 12:36:13

>>460
例外ってスレッドで独立してないか？
呼び出したルーチンに例外は漏れんと思うが

462 ：デフォルトの名無しさん：2009/05/22(金) 12:45:31

結局>>388だな

463 ：デフォルトの名無しさん：2009/05/22(金) 12:51:05

>>461
だから、処理系によると書いた。
少なくとも、g++では別スレッドからの例外はキャッチできずにプログラム自体が落ちた経験がある。

464 ：デフォルトの名無しさん：2009/05/22(金) 12:51:09

で、例外とオブジェクト指向に何の関係があるの？

465 ：デフォルトの名無しさん：2009/05/22(金) 12:57:12

>>464
メソッドがどんな例外を投げるか
っていうのは、インタフェースに関わることで、
インタフェースはオブジェクト指向の本質と言っても過言ではない。

466 ：デフォルトの名無しさん：2009/05/22(金) 12:57:16

とりあえず、例外云々で議論する人たちは、オブジェクト指向どころか、構造化すら解ってない予感

467 ：デフォルトの名無しさん：2009/05/22(金) 13:00:50

>>465
> インタフェースはオブジェクト指向の本質と言っても過言ではない。

なぜか、オマイのことだけは信用していい気がした。

468 ：デフォルトの名無しさん：2009/05/22(金) 13:05:03

インターフェースってjavaのあれ？
C++やLispでCLOSを使ってると出て来ないよね？

469 ：デフォルトの名無しさん：2009/05/22(金) 13:10:35

>>419
例外は例外的な事態が発生した時に発生させるものなので、
基本的にパフォーマンスは問題にならない。
もそパフォーマンスが問題になるほど頻繁に例外を発生させてるのなら、
例外の使い方が間違ってる。

470 ：デフォルトの名無しさん：2009/05/22(金) 13:18:00

んなこたない

471 ：デフォルトの名無しさん：2009/05/22(金) 13:24:35

文字列パースする為のメソッドなんかは、例外を吐くやつと、
速度重視で真偽値を返す奴との2通り用意してある事が多いでしょ。

472 ：デフォルトの名無しさん：2009/05/22(金) 13:31:39

エラーが予測できる場所は if を使うべき
予測可能な例外って意味わかんないよ！

473 ：デフォルトの名無しさん：2009/05/22(金) 13:38:00

>>472
いや、ifを書くとコードがごちゃごちゃするから、例外でまとめてキャッチするという手段を使うと良い場合もあるんだよ。

474 ：デフォルトの名無しさん：2009/05/22(金) 13:39:46

エラーが発生→スレッドを殺す→新しいスレッドを作成
ってやった方がシンプルで安全な場合もある。

475 ：デフォルトの名無しさん：2009/05/22(金) 13:56:53

>>473
ifが嫌ならswitchを使うといいwww

476 ：デフォルトの名無しさん：2009/05/22(金) 13:58:43

>>475
根本解決になってない

477 ：デフォルトの名無しさん：2009/05/22(金) 13:59:07

>>473
ま、キレイに書きたい気持ちは分かるけど…
本当にそれは例外じゃないとだめなの？

478 ：デフォルトの名無しさん：2009/05/22(金) 14:03:52

>>477
お前に言われたくないが、
ErlangスタイルでC++とかでプログラミングするなら例外を使うときれいにまとまるな。

479 ：デフォルトの名無しさん：2009/05/22(金) 14:11:19

広い範囲をtry{}で囲むとすっきりするが
例外がどこから飛んできたのかわかりにくくなる。

全然関係ない場所から偶然同じ型の例外が飛んできたら嫌じゃん

480 ：デフォルトの名無しさん：2009/05/22(金) 14:23:07

>>479
必要があれば部分的に例外処理、荒くも細かくもできる

481 ：デフォルトの名無しさん：2009/05/22(金) 14:23:23

>>479
例外が投げられた場所に応じた細かい対応を記述したいの
なら狭い範囲を囲めばいいじゃん。
広い範囲を囲むのは、その範囲内で投げられた例外に対して
同じ処理で対応出来る時。

所詮書き分けで対応出来る話でしょ。

482 ：デフォルトの名無しさん：2009/05/22(金) 14:34:35

例外処理は、BASICのON ERROR GOTOを思い出してダサいなぁと思ってしまう

483 ：デフォルトの名無しさん：2009/05/22(金) 14:39:53

コンストラクタの中から
BadArgumentExceptionとかするのはいかがなものか。

484 ：デフォルトの名無しさん：2009/05/22(金) 14:41:50

>>482
そりゃ例外云々じゃなくてGOTOだからダサいんでしょ。
関数呼び出しのたびにIF書いてGOTO飛ばしたらもっとダサくなる。

>>483
素敵だと思うけど。

485 ：デフォルトの名無しさん：2009/05/22(金) 14:56:42

>>484
ON ERROR GOTOは、GOTOと書かれてるからダサいんじゃない、エラー処理の本質がGOTOだって事を嫌でも思い知らされるからダサいんだよ

486 ：デフォルトの名無しさん：2009/05/22(金) 15:06:02

ttp://msdn.microsoft.com/ja-jp/library/cc440185.aspx
オブジェクトプロバイダのガイダンス

例外を、単なる別のエラー処理技法のように扱ってはいけません。
エラーコードを返したり、グローバル変数の設定したりすることと同レベルだと思ってはいけません。
例外は、それを取り巻くコードの構造と意味を、根底から覆します。
例外は、プログラムの実行時セマンティックを一時的に繋ぎ変え、通常実行しているコードを迂回し、
こういう状況でなければ決して実行されないコードを動作させます。
例外は、エラー状態を認知させ、プログラムの死という罰則を用いてその状態を改めようとします。

このように、例外には単純なエラー処理を超えた特性があります。
これらの特性を必要としない、理解しない、あるいは文書化したくないなら、例外をスローしてはいけません。
例外以外のエラー処理技法を探してください。

スローすることに決めたなら、すべての因果関係を理解してください。
あなたの設計が、あなたのコードを使用する他のユーザーに、潜在的に多大な影響を与えることを承知していてください。
例外はインターフェイス契約の一部なのです。
どの種類の例外をインターフェイスからスローするのか、どのような場合に例外をスローするのか、
なぜスローするのか、これらを完全に文書化しなければなりません。
そして、その文書を例外仕様として、コードの中に記述することを十分考えてください。

487 ：デフォルトの名無しさん：2009/05/22(金) 15:10:19

ON ERROR GOTOは紛れも無く例外処理だろwww

488 ：デフォルトの名無しさん：2009/05/22(金) 15:11:54

>例外はインターフェイス契約の一部なのです。

ですね
わかります

489 ：デフォルトの名無しさん：2009/05/22(金) 15:12:14

例外を使うコードは見づらくてよくない。
エラーの発生した処理と遠く離れたところにcatchがあるのは
現代のスパゲティプログラムといえるね

490 ：デフォルトの名無しさん：2009/05/22(金) 15:16:01

>>486
こうも書いてあるね

>例外をスローすべき十分な理由があるなら、進んでその例外をスローして、
>それを文書化すればよいのです。例外をスローするのが当然の場面で、
>例外のスローを回避する方法を発明する必要はありません。

491 ：デフォルトの名無しさん：2009/05/22(金) 15:47:41

例外をスローするのが当然の場面、って何だろうな。

仕様、仕様とあるように、例外を投げる仕様と、
投げなくて問題があれば単にnullを返す仕様。

どちらが当然か、という話になるのか？
そういう話じゃないのか？

492 ：デフォルトの名無しさん：2009/05/22(金) 16:03:49

いいこと思いついた
引数で「例外ファクトリ」を指定する仕様にすればスローするのが当然だよね

493 ：デフォルトの名無しさん：2009/05/22(金) 18:13:48

ああーやっぱり明確な仕様の記述なしに例外投げんなでＦＡか
まあ、そうじゃねぇと邪魔でしょうがねぇよな

494 ：デフォルトの名無しさん：2009/05/22(金) 19:39:15

ドキュメントをまったく書くつもりのない俺は例外を書く資格なしということで
このスレの例外議論を終了したいと思います。2009年5月22日（金）

495 ：デフォルトの名無しさん：2009/05/22(金) 19:52:02

C++が最強

496 ：デフォルトの名無しさん：2009/05/22(金) 21:35:47

ABIがCな時点でCが最強なんだよタコ

497 ：デフォルトの名無しさん：2009/05/22(金) 21:37:45

お前はABIが何か分かってないな

498 ：デフォルトの名無しさん：2009/05/22(金) 21:37:49

C++にしても基本はCだからね

499 ：デフォルトの名無しさん：2009/05/22(金) 21:55:13

なんだか、継続の代わりに例外を使ってる人が居そう。

500 ：デフォルトの名無しさん：2009/05/22(金) 22:03:55

え？ｗ

501 ：デフォルトの名無しさん：2009/05/22(金) 22:10:28

失敗を恐れているんじゃねぇよ。
エラーになるかもなんていっていたら何もできやしない。
俺はエラー処理なんて一度も書いたことねぇ。
やれるって信じたら絶対できる。

502 ：デフォルトの名無しさん：2009/05/22(金) 22:20:20

最適化と同じで、エラーを気にしだすときりがない気はする

503 ：デフォルトの名無しさん：2009/05/22(金) 22:30:20

例外処理ってビミョーだよな。

投げる側では「ある条件のとき例外を投げる」
として、普通におもっくそ想定を置いている。
例外でもなんでもない。
ゼロで割る？　ファイルがない？　数値化できる文字列じゃない？

んなもん事前に調べれ。

504 ：デフォルトの名無しさん：2009/05/22(金) 23:18:44

例外なんて投げたことないな。
そんな機能があったことも忘れたよw

505 ：デフォルトの名無しさん：2009/05/22(金) 23:30:10

>>503
ファイルの存在を確認してから
開くまでの間に消されるかもしれないじゃないか。
そんなのどうやって事前に調べるんだよ

506 ：デフォルトの名無しさん：2009/05/22(金) 23:31:26

ライブラリが下手に例外投げる仕様だと
受け手がいなくて死んだりする
リンクのミスとかで他の不具合も出る
投げないにこしたことない

507 ：デフォルトの名無しさん：2009/05/22(金) 23:32:39

落ちなければいいってわけでもないが

508 ：デフォルトの名無しさん：2009/05/22(金) 23:37:36

>>505
それは「ファイルを消すな」という問題じゃね？
プログラムが責任を持つのはせいぜい、
プログラム内での排他処理でよくね？

OSレベルのことで困れば、
オチてプログラム呼び出し側で責任取らせればよくね？

呼び出し元の事情を気にするのは、
よくない設計じゃね？

509 ：デフォルトの名無しさん：2009/05/22(金) 23:45:48

次のfreadがしける程度だろ？

510 ：デフォルトの名無しさん：2009/05/23(土) 03:37:44

例外イラネとか言ってるやつのどれだけが、
malloc()の返り値のNULLチェックをやっているのやら。

511 ：デフォルトの名無しさん：2009/05/23(土) 04:13:00

>>503
> ゼロで割る？　ファイルがない？　数値化できる文字列じゃない？
> んなもん事前に調べれ。

文句言うまえに、そんな糞パラメータ送ったおまえが調べろよ。

512 ：デフォルトの名無しさん：2009/05/23(土) 04:47:38

例外は"スタックを調整してデータを積んでGOTOしてるだけ"なので

a();
v = f();
b();
c(v);

一見正しくみえるが、f()が例外を飛ばすのを忘れていると
例外自体は他でキャッチするのでテストはキチンと失敗するにも関わらず
f()が失敗したのに誤ってa()したり、誤ってb()しなかったりする

OO的に

Any f() {
if (!hoge()) reterun new Error("Can't hoge!");
return fuga();
}

のように正常な経路でメッセージを戻せばその種の不整合問題は発生しづらい
エラー処理を忘れたらc(v)の内部でとまるので原因はすぐわかる
実際はc(v)内部で引数のチェックくらいするからエラーを記録して何もしないという選択もできる

例外投げたらそこで終了だよ

513 ：デフォルトの名無しさん：2009/05/23(土) 05:33:56

>>512
Javaの場合、トラップするべき例外をトラップしていなければ
コンパイラがそれを指摘してくれますが何か？

返り値でエラーコードを返す場合にはそうはいきませんなあ。

で、君はmalloc()するたびにちゃんとNULLチェックしてるの？

514 ：デフォルトの名無しさん：2009/05/23(土) 05:38:46

>>512
おまえ、本当にマか？

> Any f() {
> if (!hoge()) reterun new Error("Can't hoge!");
> return fuga();
> }

コンパイラさんからreterunって何？って叱られるぞw

> のように正常な経路でメッセージを戻せばその種の不整合問題は発生しづらい

f()の返り値がおかしいかどうかちゃんとチェックしていなければ、
原因をトレースするのが厄介になるぞ。c(v)が悪いのかf()が悪いのかa()が悪いのか
ワケワカラン状態になるのがオチだ。
例外を使えばちゃんとスタック保存してくれているから原因は一目瞭然。

> 実際はc(v)内部で引数のチェックくらいするからエラーを記録して何もしないという選択もできる

空のハンドラ渡すのと何が違うの？

515 ：デフォルトの名無しさん：2009/05/23(土) 05:41:47

>>512
>f()が例外を飛ばすのを忘れていると
処理に失敗したのにも関わらず例外を投げ忘れたf()は、返値
として一体何を返すの?

>if (!hoge()) reterun new Error("Can't hoge!");

ここでエラーを返すか例外を投げるか、それだけの違いでは。
if (!hoge())をチェックすべきことが分かっているか否か、大切
なのはその事であって、この事に気づいていればエラーを返す
とか例外投げるとかは単に実装の違いに過ぎないと思う。

>f()が失敗したのに誤ってa()したり、
関数の呼び出し順が間違っているのでは。a()の実行の前提と
してf()の成功が必要なら、f()の後にa()呼ぶでしょ。
これは例外とか返値云々とは無関係な、因果律の問題。

>誤ってb()しなかったりする
何のためにensureやfinallyがあると思っているんだ。

>c(v)の内部でとまるので原因はすぐわかる
止まったときには結局例外が投げられるんじゃない?

>Any f() {

言語にもよるけど、静的型付けの言語の場合には結果と
詳細なエラー情報を共に返値で返すとなると返値の型や
セマンティクスで悩むことは少なく無いと思う。
Anyですか。そうですか。

516 ：デフォルトの名無しさん：2009/05/23(土) 05:50:56

>>515
> 言語にもよるけど、静的型付けの言語の場合には結果と
> 詳細なエラー情報を共に返値で返すとなると返値の型や
> セマンティクスで悩むことは少なく無いと思う。

そうそう。存在しないキーでハッシュマップ引いた時に
例外を投げずにNullを返しちゃったりしたら、
ハッシュマップで対応する値がNullだったのか、
ハッシュマップで対応する値がなかったのか、
判別つかないんだよな。
その判別をするための特殊なクラスをつくると、
とたんに返り値の型が問題になる。
Objectとかにしたら、今度は使う側でナローキャスト
してやらなきゃならなくなって静的型のメリットがなくなるし。

517 ：デフォルトの名無しさん：2009/05/23(土) 06:27:10

>>515
f()が例外を返すことを書いた時は覚えていた
その例外は別の階層でトラップされるから正しい記述である
が翌日忘れてあるいは別人が修正したとするそんな感じのバグが生まれる話
言語仕様が関数が例外を投げると宣言することを強制しても
例外を戻す関数が他にあれば紛れてしまうでしょ

a()の位置が違うのは分かってワザとそこに書いたの
v=f()のところにエラー処理の記述があればレビューの時に誰か気付くんだよ

518 ：デフォルトの名無しさん：2009/05/23(土) 07:33:56

>>516
C#の場合だが例外を発生させないためにTryGetValueがある。
bool result = dictionary.TryGetValue(key,out val);
キーのない値をひくのは通常処理の場合が往々にしてあるからこれも必要と思う

519 ：デフォルトの名無しさん：2009/05/23(土) 08:49:42

お前らが言ってるのは、例外処理以前の話じゃん

「ドキュメントやコメントをちゃんと書きやがれ」

って次元の問題じゃん

520 ：デフォルトの名無しさん：2009/05/23(土) 09:50:34

Cだったら戻り値の意味書くぐらいでいいのに例外だと説明すんのがめんどくさいんだよね

521 ：デフォルトの名無しさん：2009/05/23(土) 09:52:13

GetValueとFindがあればいいだけの話。
GetValueは例外、FindはNo Such Keyを表す何かを返す。

522 ：デフォルトの名無しさん：2009/05/23(土) 10:23:07

どんどん話が低脳者の会話になっていってるな
もうオブジェクト指向が無くなれとか言う問題じゃなくなってるwww

523 ：デフォルトの名無しさん：2009/05/23(土) 10:40:46

>>518
outがなければ例外を投げればいいじゃない(ｷﾘｯ

524 ：デフォルトの名無しさん：2009/05/23(土) 11:30:50

例外は>>486で結論出てるのにな…
ライブラリが例外を返すようなコードを書くな。書くならそのリスクを覚悟しろってことだ

525 ：デフォルトの名無しさん：2009/05/23(土) 12:49:19

>>524
486のリンク先は言ってることが良く分からない。
内容が有益であるのなら、だれか要点をまとめてくれない?

# だらだらした文書である上、罰則だの精神とかの妙な単語が頻出していて
# 頭のおかしなやつが書いたようにしか見えなかった…
# (ソースのインデントの仕方も一番ダメだと思っているスタイルだったし…)

526 ：デフォルトの名無しさん：2009/05/23(土) 13:00:45

>>518
実際例外使わないバージョンを書くときにその手の事前チェックの
関数と実処理の関数に分けることは常套だけど、前提もある。

一つはそのハッシュがスレッド間で共有されてたり、データが実は
ネット上にあってそれを参照しに行くような実装ではないこと。
チェックしてから実処理するまでの間にハッシュの内部状態が変わる
可能性があるからね。

もう一つは事前チェックが非破壊的に、しかも低コストで行える事。
例えばXML等のパース。事前に「パース可能か」なんて確認しよう
と思ったら、その後のパース本番と併せて2度XML文書をスキャン
する事になる。

つまり何時でも使える手ではないし、それを回避するために色々工夫
するよりは(ハッシュのロックを取得する関数を追加したり、パース後
にエラーを取得する関数を追加したり)サクッと例外を投げる仕様に
した方が見た目も使い勝手もシンプルになるケースもある。

527 ：デフォルトの名無しさん：2009/05/23(土) 13:23:27

>>525
しっかり読んだうえでまだなにかあるなら
正規ＯＳ買ってＭＳにメールだせよｗ
だいたいあの程度の文章理解できないってありえないだろ
英文なわけでもないし
捻った表現してるわけでもない

528 ：デフォルトの名無しさん：2009/05/23(土) 13:24:11

>>525
結局のところは>>450って事だろ

529 ：デフォルトの名無しさん：2009/05/23(土) 13:25:17

>>528
全然違うよ
読んでないなら無理やりレスをつけるな

530 ：デフォルトの名無しさん：2009/05/23(土) 13:26:13

大雑把にまとめちゃうと

そんな細かいこと気にしてるから禿げるんだよ!!!

ってこった

531 ：デフォルトの名無しさん：2009/05/23(土) 14:34:01

>>521
> GetValueは例外、FindはNo Such Keyを表す何かを返す。
そしてFindはGetValueを使って実装されている。
例えばPythonなんかはそういう実装。

532 ：デフォルトの名無しさん：2009/05/23(土) 14:58:56

その関数内でのエラーの発生が引数に対して非決定的であるときは例外を使う

533 ：デフォルトの名無しさん：2009/05/23(土) 15:38:21

>>532
日本語でおｋ

534 ：デフォルトの名無しさん：2009/05/23(土) 16:58:12

public static int parseInt(String s)
throws NumberFormatException

パラメータ:
s - 構文解析対象の int 表現を含む String
戻り値:
10 進数の引数で表される整数値
例外:
NumberFormatException - 文字列が構文解析可能な整数型を含まない場合

こういうときは例外のほうが素直な気がするね。
intでどうのこうのやりくりしたりするよりは。

535 ：デフォルトの名無しさん：2009/05/23(土) 17:14:35

>>534
文字列の数値変換なら、変換不能な場合は素直に0を返したほうが良くね?
例外にする意味が分からん...
エラーとして扱うにしても、エラーにする意味も分からん...

536 ：デフォルトの名無しさん：2009/05/23(土) 17:18:37

0が渡されたのか、解析不能な文字列が渡されたのかわからんやん。
解析不能は0として扱うでいい場合もあるけど。

537 ：デフォルトの名無しさん：2009/05/23(土) 17:27:37

そこで多値ですよ

まあ現実的にはWin32APIみたく戻り型をBOOLにして
引数側で結果を受け取れば問題ないね

538 ：デフォルトの名無しさん：2009/05/23(土) 17:29:16

>536
そういうのは、Javaなら参照型のInteger、C#ならNullable型とかの抜け道があるし。

539 ：デフォルトの名無しさん：2009/05/23(土) 17:33:01

ここまでオブジェクト指向とは全く関係ないな
既に消えてしまったようだ

540 ：デフォルトの名無しさん：2009/05/23(土) 18:47:32

例外なんて元をたどればC言語に出て来るlongjumpがルーツなんだけど
間にobjectのnewとかdeleteが入るとまずいってんでthrow catchにしたわけですよ。

例外を使いたくない奴は使わない、使いたい奴は使うということでいいんじゃないの？

でもthrowした奴は投げっぱなしじゃなくて責任持ってcatchしろよなボケ！

541 ：デフォルトの名無しさん：2009/05/23(土) 18:58:11

>>523
例外を返したければインデクサをそのまま使えばよい
C#では２種類用意されていると言うこと

＞outがなければ例外を投げればいいじゃない(ｷﾘｯ
キーが存在して、値がnullの場合があるからそれじゃダメなんだよ
516も読んでるか？

542 ：デフォルトの名無しさん：2009/05/23(土) 19:03:11

>>540
BASICのON ERROR GOTOが先じゃね?

543 ：デフォルトの名無しさん：2009/05/23(土) 19:04:37

ハッシュとかの場合はノードそのものを返すようにするんだよ
受け側はノードが返ったら値を得る
見つからなかったらNULLでいいじゃない
特殊なクラスだとか、おまえら頭悪すぎですよ

544 ：デフォルトの名無しさん：2009/05/23(土) 19:08:24

>>543
ちょっとした工夫だな。でも、それでいいと思う。

メソッドの返り値がすべてその仕組みになってたら、
nullか否かで全部扱えるのにな。例外なく。

545 ：デフォルトの名無しさん：2009/05/23(土) 19:29:26

>>543
自己紹介乙

546 ：デフォルトの名無しさん：2009/05/23(土) 19:31:13

>>543
ノードそのものを渡してしまうと、ちんたらしている間に
ノードの中身を他スレッドとかに書き換えられる恐れも
あるんだよね。

1) Node node = map.getNode(key);
2) if(node != null){
3) chintara();
4) chintara();
5) chintara();
6) chintara();
7) return func(node.value);
8) }else
9) return ERROR;

ちんたらするんじゃね～とも言いたくなるけど、3～6の間に
node.valueの値が書き換えられたりnode自体がmapから
removeされていても、文句は言えん。
仮にmap自身が自前で排他制御して複数スレッドのアクセスを
認めるマルチクライアントな実装になっていても、これでは
殆ど意味がない。結局node.valueを取得するまでmapをロック
するコードを毎度クライアント側で書く必要がある。
nodeへの参照ではなくコピーを返すのも一つの手だけど、
それだと処理値をエラーコード付きの構造体でラップして
返すのと大差無いような気もする。

547 ：デフォルトの名無しさん：2009/05/23(土) 19:39:32

管理の基本は、何かをした人が、責任を持って後始末することだろ?

548 ：デフォルトの名無しさん：2009/05/23(土) 19:39:36

543, 544についつられてしまうところだった

549 ：デフォルトの名無しさん：2009/05/23(土) 19:43:50

冷害最高
楽楽マルチインスタンス

継承はまああってもいいんじゃない？

550 ：デフォルトの名無しさん：2009/05/23(土) 20:21:51

>>546
そんな構造にしてるやつはアフォ
そうしないといけない構造はこの世にない

551 ：デフォルトの名無しさん：2009/05/23(土) 20:47:41

>>546はスレッド間の排他の話ではあっても、
例外の話ではない。

> 結局node.valueを取得するまでmapをロック
> するコードを毎度クライアント側で書く必要がある。

あくまでそういう処理ならば、そう書くしかないのでは。

552 ：デフォルトの名無しさん：2009/05/23(土) 21:30:18

>>551
その通り。だからノードを渡す、という動作は値を渡す、という
動作をそのまま置き換えるものではない、ということ。
ノードを渡すことによって確かに例外いらずになるかもしれない。
でも異なるものを渡す以上別のところで振る舞いが変わってくる
可能性もあって、例えばスレッドが絡んできた場合などがその一例
ということ。

553 ：デフォルトの名無しさん：2009/05/23(土) 21:48:44

抽象論はきらいです
消えてなくなれー

554 ：デフォルトの名無しさん：2009/05/23(土) 21:50:05

抽象論なんて、片手間で理解できなきゃプログラマーと言えん。

555 ：デフォルトの名無しさん：2009/05/23(土) 21:54:01

ある事柄を説明するためには、必要以上に抽象的な概念を仮定するべきでない。

556 ：デフォルトの名無しさん：2009/05/23(土) 21:58:33

オッカムの剃刀は「必要以上に多くの実体を仮定するべきでない」だけど、
抽象は多くのものをひとくくりにする技術だから、
結局のところ多くの実体を仮定しているのと同じことなんだよ。

557 ：デフォルトの名無しさん：2009/05/23(土) 22:00:55

メタ抽象論

558 ：デフォルトの名無しさん：2009/05/23(土) 22:11:45

おまえら、プログラミングそのものが象徴されたものの操作に他ならないのをわかってるのか。
データは現実の有り方のひとつの象徴だし、プログラムによる操作は、現実を象徴化した
モデルの操作なんだよ！

559 ：デフォルトの名無しさん：2009/05/23(土) 22:25:39

既に、例外の話でもなくなっている...
どんなけメス会話してるんだよ...

560 ：デフォルトの名無しさん：2009/05/23(土) 22:30:28

象徴ww
抽象だろうが馬鹿が

561 ：デフォルトの名無しさん：2009/05/23(土) 22:46:25

単純に、不必要な情報を見えないようにするとか言えばいいのに
余計な意味を加えて
これは抽象化、モデル化、象徴化なんだよ！
っていうのが怪しい。

562 ：デフォルトの名無しさん：2009/05/23(土) 22:47:33

>>560
大差なくね？
というか一般層が考える抽象の意味よりは象徴の方がまだ意味が近い気がする。

まぁ真の意図は>>558に聞かんとわからんが

563 ：デフォルトの名無しさん：2009/05/23(土) 23:00:49

>>562
学が無さ過ぎだろ。
抽象と象徴は日本語でも英語でも意味が違うし、具象と対をなす概念だ。
象徴の対義語は具象ではない。しっかり自分で調べてこい。

564 ：デフォルトの名無しさん：2009/05/23(土) 23:26:38

>>563
一般層の話な。

565 ：デフォルトの名無しさん：2009/05/23(土) 23:32:06

まぁプログラマ以外に抽象を説明するときは困るな。
大抵、いい加減とかそういう意味に取られる。
いい加減自体の意味も厳密に言い出すとキリがないが…

566 ：デフォルトの名無しさん：2009/05/23(土) 23:38:43

ノードにアクセスしてるときは基本アクセスできねぇだろ
っていうか仕様どおりであってその辺の仕様があいまいなのを
プログラムに押し付けること自体すでに間違いだろ

何をいってるのかさっぱりわからない
頭悪いのにえらそうにしてるやつはずかしいから発言やめろ

567 ：デフォルトの名無しさん：2009/05/23(土) 23:46:14

>>565
>まぁプログラマ以外に抽象を説明するときは困るな。
ちょっと理解しがたいシチュエーションだな。
>>564 の必死な弁解に付き合う必要はないと思うが。

568 ：デフォルトの名無しさん：2009/05/23(土) 23:53:16

むしろプログラマに通じなくて困る
俺の会社だが

569 ：デフォルトの名無しさん：2009/05/24(日) 06:57:02

>>543
> ハッシュとかの場合はノードそのものを返すようにするんだよ

毎回ノードをインスタンス生成しますか？
それともハッシュマップ中のノードをそのまま返して、
どっかのアフォがノードの中身を書き替えて、
滅茶苦茶トレースしにくいバグを作り込む元をつくりますか？

570 ：デフォルトの名無しさん：2009/05/24(日) 06:58:23

>>540
longjumpは例外というより継続なのだが。
まあ継続で例外を実装することは可能だけど、
例外の元になったのがlongjumpかと言われると
それは間違いと答えるしかない。

571 ：デフォルトの名無しさん：2009/05/24(日) 10:31:21

>>569
アクセスと切るまで他の人間はアクセス不能（もしくは読み取り専用）
っていうか仕様はどうなってるの？

572 ：デフォルトの名無しさん：2009/05/24(日) 10:40:01

このペースで行くと、人間がプログラムすることが悪って話になるな

573 ：デフォルトの名無しさん：2009/05/24(日) 10:41:57

マルチスレッドのプログラムの複雑さをオブジェクト指向のいいわけに使うやつがいるけど
大抵は仕様が決まってないことが問題でオブジェクト指向とはなんの関係もないよね？
問題の切り分けもできない人が現場で報告もせずに勝手に騒ぎ立てるとか結構多い

574 ：デフォルトの名無しさん：2009/05/24(日) 11:29:32

仕様を厳密に決めることと
仕様を抽象的にすることは
両立できるのか？　という話だな。

まず厳密さだけ考えて、後でリファクタリングするとか。

575 ：デフォルトの名無しさん：2009/05/24(日) 12:16:21

>>573
>いいわけに使うやつがいるけど
幸いにして、そこまでの莫迦は見たことがない。
>オブジェクト指向とはなんの関係もないよね？
肯。

576 ：デフォルトの名無しさん：2009/05/24(日) 12:21:10

>573
マルチスレッドで思い出したけど、最近は並行処理にはオブジェクト指向的な
解決法より関数型言語のやり方の方がうまくいくって風潮じゃない？

オブジェクト定義するにしても可能な限りimmutableにしたりして、従来とは
ちょと違うよね。

577 ：デフォルトの名無しさん：2009/05/24(日) 12:39:17

>>576
そういう風になることは１０年以上前から予測済み。
オブジェクト指向に期待したことなんて今まで一度もなかった。
単にセミナー屋が騒いでるな　ぐらいにしか思わなかったからな。

578 ：デフォルトの名無しさん：2009/05/24(日) 12:52:02

最初から関数型言語をやってればよかったけど
当時はVBとC++とfortran、pascal、機械語、あとはlisp 2とprologぐらいしか知らなかったので
仕方なくVC6を使って未完成のC++と腐ったOOPの狭間で藻掻いてた
でもlisp 2やprologの存在を知っててSchemeやMLとかMirrandaにまで至らなかったのは俺のミスだ…

579 ：デフォルトの名無しさん：2009/05/24(日) 12:58:49

>>578
そこが英語が得意な奴と苦手な奴の差

580 ：デフォルトの名無しさん：2009/05/24(日) 14:00:53

>>578
Mirrandaなんかに騙されたのか？かわいそうな奴だ。
俺はちゃんとMirandaを使ってたぞ。

581 ：デフォルトの名無しさん：2009/05/24(日) 16:03:08

Mirandaってみんな処理系買ってやってた？

あとどんくらい実用的なアプリ作ってた？

582 ：デフォルトの名無しさん：2009/05/24(日) 16:36:27

>>581
学校がサイトライセンス持ってた。
それで関数型言語の処理系を書いた。

583 ：デフォルトの名無しさん：2009/05/24(日) 16:48:46

なるほど考えてみればああいうのに手をだすのって学校とか研究関係だもんな。

俺みたいな趣味の人はMirandaなんてHaskellが有名になってきてから初めて知ったわ。

584 ：デフォルトの名無しさん：2009/05/24(日) 16:51:58

ただ近年になって一般人に関数型言語が注目されたのは大きいね。
Haskellは院時代に講義で使ったけど、なんでHaskellが一般人に流行ったのか
分からん。そういう俺はOCaml使い。

585 ：デフォルトの名無しさん：2009/05/24(日) 16:53:35

>>583
Haskellも有名じゃないと思うんだが・・
どっちかというとOCamlの方が有名じゃないか

586 ：デフォルトの名無しさん：2009/05/24(日) 17:01:09

Haskellは2004年のICPCで有名になった

587 ：デフォルトの名無しさん：2009/05/24(日) 17:05:29

>>585
むしろ東大がOCamlをで講義に使ってるから東大生の間では有名に見えちゃうだけじゃないすか？
プログラミング言語の講義で最初にPrologやったら「ああ、みんなPrologでソフト作ってるんだなー、へー」
みたいに思っちゃうのと同じ。

一般的に満たらHaskellのほうが全然有名だと思うなー。

http://www.google.com/trends?q=Haskell%2COCaml&ctab=0&geo=all&date=all&sort=0

と思ってみたらやっぱHaskell圧勝ですたw

588 ：デフォルトの名無しさん：2009/05/24(日) 17:14:02

>>587
おまえ頭悪いな。
Haskellは地名や人名でありふれているから、そんなものは全く比較にならないぞ。

589 ：デフォルトの名無しさん：2009/05/24(日) 17:57:59

>>588
じゃあどうやって比較すればいいか示してみろよ。

すぐ「おまえ頭悪いな。」とか言っちゃう所がアレだよねw

590 ：デフォルトの名無しさん：2009/05/24(日) 18:03:17

人名、地名であふれてると言ってもHaskellで検索して上位にくるのはやっぱり言語のHaskellばかりだし
全くアテにならないってことはないと思うよ。

591 ：デフォルトの名無しさん：2009/05/24(日) 18:06:10

>>589
人に責任転嫁するな。お前が勝手に比較しようとしたんだろうが。
俺は比較しろなんて一言も言っていない。

何も考えずにGoogle Trends使ってデータを出して、確認もせずに
「と思ってみたらやっぱHaskell圧勝ですたw」
なんて言うような奴は頭が悪いとしか言いように無いだろうが。

592 ：デフォルトの名無しさん：2009/05/24(日) 18:10:28

>>591

wがついてるからある程度シャレなわけだが。
別に厳密に比較する方法なんて無いことは最初から分かってるわけだし、

＞お前が勝手に比較しようとしたんだろうが。
>>585氏の
＞どっちかというとOCamlの方が有名じゃないか

こういう発言をうけて試しにGoogle trendで比較してみただけなんだが。

なんかOCamlのほうが有名じゃなきゃ困るのw？

593 ：デフォルトの名無しさん：2009/05/24(日) 18:11:52

>>590
Google TrendsはPageRankを使っているわけではない。
そもそもノイズレベルがどの程度か分からなければデータをアテに出来るわけないだろ。

594 ：デフォルトの名無しさん：2009/05/24(日) 18:12:47

>>592
実際にOCaml使って開発している会社は知ってるけどHaskellで開発してる会社は知らないぞ。

595 ：デフォルトの名無しさん：2009/05/24(日) 18:15:06

>>593
俺はシャレのつもりで>>587を書いたからべつにアテにしたくなかったらしなきゃいいじゃんw

一般的に見たらHaskellのほうが全然有名だとは思ってるけど、こんなの調査する方法ないでしょ。
なんでそこまで本気なのよ？

否定したいならOCamlのほうが有名だと思うなーとか書いてみればいいだけじゃない？

596 ：デフォルトの名無しさん：2009/05/24(日) 18:15:15

>>592
お前のようにwを使う奴が低能だということは分かった。

> なんかOCamlのほうが有名じゃなきゃ困るのw？
誰がそんなことを言ったんだ？妄想も大概にしておけ。

597 ：デフォルトの名無しさん：2009/05/24(日) 18:16:52

>>596
君は結局何がしたかったの？
ただgoogle trendを出した俺を叩きたかっただけかな？

それとも何か主張があったの？

598 ：デフォルトの名無しさん：2009/05/24(日) 18:18:27

>>595
シャレで言った割に随分と偉そうなレスをする奴だな

599 ：デフォルトの名無しさん：2009/05/24(日) 18:20:24

>>598
だっていきなり「おまえ頭悪いな。」とか喧嘩売ってくる奴何なのって感じじゃないすか？

何かそんなに相手を怒らせるようなことしたか？

600 ：デフォルトの名無しさん：2009/05/24(日) 18:20:49

>>597
頭の悪いレスをする奴を叩きたかっただけだよ。
シャレと言いながら本当に必死にレスする奴だな。

601 ：デフォルトの名無しさん：2009/05/24(日) 18:22:37

>>587
俺は東大生じゃないけど、俺へのレスでなんで東大生に限定して言うのかね？
このスレはむしろ東大以外の奴の方が多いんじゃないか。
もしかして、あまり論定的思考に慣れていない方ですか？

602 ：デフォルトの名無しさん：2009/05/24(日) 18:23:47

　　　　　ｶﾀｶﾀ
　　||￣ Λ＿Λ
　　||＿（Д`；　）　「なに？このスレ・・・」
　　＼⊂´　　　）
　　　　（　　┳'

603 ：デフォルトの名無しさん：2009/05/24(日) 18:23:51

学歴コンプなんだろ
だから頭悪いって言われて血が昇ってるんだよ

604 ：デフォルトの名無しさん：2009/05/24(日) 18:25:19

俺は京大だけど東大より上だと思ってるっｗ

605 ：デフォルトの名無しさん：2009/05/24(日) 18:30:19

>>600
なんだwwwそれを聞いて安心したよwww

>>601
こういうスレの雑談で論定的思考とか言ってる人って普通に雑談することできなそうだな。

俺はOCamlの存在を東大の人から聞いて知ったんだ。Haskellはその前から知ってたけど。
そいつはOCamlのほうが関数型言語として有名だ、と言ってた。そんな感じかと思っただけ。

>>603
違いますよw

606 ：デフォルトの名無しさん：2009/05/24(日) 18:33:26

>>605
「2chでは批判することに価値がある」

607 ：デフォルトの名無しさん：2009/05/24(日) 18:35:44

で、HaskellとOCamlどっちが有名なの？

608 ：デフォルトの名無しさん：2009/05/24(日) 18:38:50

どうしても知りたかったら電話アンケートでもとれよ
誰もそんな足を使った調査していないから、記事にして売り込めるぞ

609 ：デフォルトの名無しさん：2009/05/24(日) 18:39:59

Objective Camlって何となくプリウスみたいだよな

610 ：デフォルトの名無しさん：2009/05/24(日) 18:41:55

オブジェクト指向機能が付いているから移植しにくいライブラリでも、
最悪の場合はオブジェクト指向で実装すればいいという保険が付いているからHaskellより安心できるよね。

611 ：デフォルトの名無しさん：2009/05/24(日) 22:53:16

Ocaml愛好家の常識ではOcamlのオブジェクト指向は使ってはならないらしい

612 ：デフォルトの名無しさん：2009/05/24(日) 23:34:08

だったらなんでcaml使わないんだって話
要するに保険が重要だからOCaml使ってる奴が多いんだろ

613 ：デフォルトの名無しさん：2009/05/25(月) 05:19:05

実用品（っぽい）アプリや商用アプリが書かれたって話は、OCamlの方が
何倍も聞く気がする。
ただ、InfoQにちょっと前に掲載されてたHaskellのえらい人のインタビューでは
Haskellもメインストリーム狙いで行くぜ！って言ってた。

まあ、このスレ見てるような人達は、ScalaとF#の発展に期待した方が
いい気がする。

614 ：デフォルトの名無しさん：2009/05/25(月) 08:35:49

Erlangの話題が出てこないことに絶望しますた。

615 ：デフォルトの名無しさん：2009/05/25(月) 11:54:24

javaの没落と同様にscalaなんかに誰も期待していません

616 ：デフォルトの名無しさん：2009/05/25(月) 12:02:59

ErlangはcleanのようにHaskellに食われるべき

617 ：デフォルトの名無しさん：2009/05/26(火) 07:29:02

Cを簡易アセンブラって言う人はC言語とアセンブリ言語両方で本気モードの
プログラムを組んだ経験がない人だと思う。

618 ：デフォルトの名無しさん：2009/05/26(火) 07:38:27

Cをポータブルアセンブリ言語だと言う人はみたことあるけど、
簡易アセンブラなんて言う人は見たこともない件について。

619 ：デフォルトの名無しさん：2009/05/26(火) 07:40:46

>>617
おまえスレ違いだぞ

620 ：デフォルトの名無しさん：2009/05/26(火) 08:15:53

結論言っていいか。

オブジェクト指向だろうが関数型言語だろうが、
それぞれのプログラミングパラダイムには、それぞれの長所と欠点がある。
本物のハカーはどれか1つに固執したり毛嫌いしたりしない。
適材適所で使うものだ。

これは例外処理でも同じこと。ソフトウェア開発に銀の弾丸はない。

621 ：デフォルトの名無しさん：2009/05/26(火) 08:20:12

>>620
そんなこと分かった上で色々議論していると思うんだが。
オレオレ結論をわざわざここに書くなよ。

622 ：デフォルトの名無しさん：2009/05/26(火) 08:43:09

なるほど。

>>577
> そういう風になることは１０年以上前から予測済み。
> オブジェクト指向に期待したことなんて今まで一度もなかった。
> 単にセミナー屋が騒いでるな　ぐらいにしか思わなかったからな。

623 ：デフォルトの名無しさん：2009/05/26(火) 19:26:14

適材適所って意味解らんな
結局は自分に合ってるかどうかだろうが
オブジェクト指向が合わない奴にとってはどのような局面においてもオブジェクト指向は不要

624 ：デフォルトの名無しさん：2009/05/26(火) 19:35:37

コボラーの言い訳に使えそうだな。

625 ：デフォルトの名無しさん：2009/05/26(火) 19:38:11

オブジェクト指向を使ったソースと使わないソースを書き比べてみれば
いかにオブジェクト指向がハッタリ設計思想かわかるよ
工数は１Ｈも削れない

626 ：デフォルトの名無しさん：2009/05/26(火) 19:41:52

>>623
個人の問題じゃないんだよ

627 ：デフォルトの名無しさん：2009/05/26(火) 19:42:43

>>625
それは、設計が下手だから。

628 ：デフォルトの名無しさん：2009/05/26(火) 19:45:21

急にレスがつき出したｗ

おまいら潜伏してたんだな(　´ｰ｀)y─┛~~

629 ：デフォルトの名無しさん：2009/05/26(火) 20:15:43

>>627
落ち着いて考えればわかるけど
設計によって仕様が消えることはないよ

630 ：デフォルトの名無しさん：2009/05/26(火) 21:20:49

Design by Contractとセットじゃないと使い物にならない
が、まともにそれをやると面倒臭くて仕方がない

631 ：デフォルトの名無しさん：2009/05/26(火) 22:08:19

対話環境のない言語はクソ

632 ：デフォルトの名無しさん：2009/05/26(火) 23:08:37

>>631
最近プログラミング始めたけど、はるか前に学んでた人たちは
ビルド→実行をひたすら繰り返してたんだよな。
何て忍耐強いんだって思う。皮肉じゃなくて

633 ：デフォルトの名無しさん：2009/05/26(火) 23:28:48

>>632
そんなことはない。BASICというものが何十年も前から存在しているからな。

634 ：デフォルトの名無しさん：2009/05/27(水) 01:46:22

>>632
うん、ちょっとしたプログラムのビルドに
15分とか、かかってた。

635 ：デフォルトの名無しさん：2009/05/27(水) 07:34:37

今度はインタプリタ対コンパイラか？
これも適材適所、どこが適所かわからない奴は才能ないから転職汁、で終了だろ。

636 ：デフォルトの名無しさん：2009/05/27(水) 08:53:38

身も蓋もない

637 ：デフォルトの名無しさん：2009/05/27(水) 10:28:05

>>632
オブジェクト指向も無かったんだぜ
あれは幸せな時代だった

638 ：デフォルトの名無しさん：2009/05/27(水) 10:33:33

オブジェクト指向が無かった時代の方が良い物が多い気がする。

639 ：デフォルトの名無しさん：2009/05/27(水) 10:48:37

怪しいのはオブジェクト指向分析とかであって、オブジェクト指向でコードを
書くのが悪いわけではない。

640 ：デフォルトの名無しさん：2009/05/27(水) 11:08:49

>>639
どう考えても逆だろ

641 ：デフォルトの名無しさん：2009/05/27(水) 11:16:36

>>640
逆な理由をきっちりと説明してもらおうか。

オブジェクト指向分析なんてほとんど詐欺じゃないか。
そんなことを謳ってる会社ってろくでも無いことがほとんどだろ。

642 ：デフォルトの名無しさん：2009/05/27(水) 11:34:28

オブジェクト指向分析というか、オブジェクト指向設計のことだが、
かつてソフトウェアの設計において体系化された数少ない設計技法の一つ。
これはソフトウェア工学の資産だよ。
でもオブジェクト指向プログラミングはいまいちパッとしないね。
クラスがあって、クラスの中の変数をクラスの中の関数で弄って・・ってあまり洗練されているようには思えない。
メッセージを送るんじゃなくて、それはただの関数呼び出しだからｗ
「継承」もイマイチだね。
オブジェクト自体が単独で動いているわけじゃないから違和感があるんだろうね。
Erlangみたいにプロセスで平行して動いているなら本当のオブジェクトっぽいんだろうけど。

643 ：デフォルトの名無しさん：2009/05/27(水) 11:48:01

オブジェクト指向の説明は闇鍋に似ている
何が飛び出てくるか全く予測がつかない

644 ：デフォルトの名無しさん：2009/05/27(水) 11:53:41

>>643
意味不明

645 ：デフォルトの名無しさん：2009/05/27(水) 11:55:03

俺はオブジェクト指向が理解できませんでした、と言いたいのか？

646 ：デフォルトの名無しさん：2009/05/27(水) 12:00:48

>>642
> かつてソフトウェアの設計において体系化された数少ない設計技法の一つ。

有用そうなものを掻き集めて見ました。
うまく組み合わせれば、それなりに使えるかも知れません。

てな、感じにしか見えないぞ

647 ：デフォルトの名無しさん：2009/05/27(水) 12:05:28

>>646
もっと良い設計手法を知っているなら教えてください

648 ：デフォルトの名無しさん：2009/05/27(水) 12:34:40

クラスは代数構造で、継承とか移譲、使用みたいな関係を射とする圏
みたいな構成はできるんだろうけど、そういう考え方が未だに一般に知られない時点で
綺麗な構造を作る事に関しては絶望的なんだろうなぁ

649 ：デフォルトの名無しさん：2009/05/27(水) 12:45:50

>>642
つ Actor

650 ：デフォルトの名無しさん：2009/05/27(水) 12:50:34

俺はOOPL信者だが、OOA/OODはクソだと思う。

651 ：デフォルトの名無しさん：2009/05/27(水) 12:51:30

>>648
それ、OOつーよりERDだろ。

652 ：デフォルトの名無しさん：2009/05/27(水) 13:02:04

>>648
数学的に書き下すことと、それを現場が使える設計手法として
ブレイクダウンするまでの間には結構距離があるんだな。
「一般に知られていない」なんて嘆いているヒマがあれば何故
一般には知られていないのかどうすれば広く知られるように
なるのか考えてみると面白いのでは。

653 ：デフォルトの名無しさん：2009/05/27(水) 13:13:37

圏って所詮はグラフだろ

654 ：デフォルトの名無しさん：2009/05/27(水) 18:19:09

面白がってる場合じゃないんだよ
明日役に立たない物はゴミなんだよ

655 ：デフォルトの名無しさん：2009/05/27(水) 18:46:13

>>652
そうだろう、そうだろう。
数学的に書き下したものを仕様書の中に含めたら、
「意味がわからん！！！書き直せ！！！」
と大いばりで言う自称 SE が良くいるもんな

656 ：デフォルトの名無しさん：2009/05/27(水) 18:56:55

>>643
気持ちはわかる。
今の時代、何が飛び出てくるかを
追いかけるのは、もう量的に無理に
なってきているから、そういうものを
気にしない OO で行こうってことなんだろう。

657 ：デフォルトの名無しさん：2009/05/27(水) 18:57:36

>>655
あのな、お前らコーダーがSEの仕事に口を出すから「意味がわからん書き直せ」なんて言われるんだよ。
お前がSEになれば良いだけのことだろ。
コーダーはプログラムを書くのが仕事。

658 ：デフォルトの名無しさん：2009/05/27(水) 20:26:37

設計とコーディングを別に分けるからおかしくなるんだよ。
一人で設計＆コーディングやればいいだけの話なんだが。だから日本は駄目なんだ。

659 ：デフォルトの名無しさん：2009/05/27(水) 20:37:32

>>658
もちろんSEもプログラムは書くけど、コーダーはもっと細かいところを書く印象だな。

660 ：デフォルトの名無しさん：2009/05/27(水) 20:57:57

>>659
それなら結構まともかもね。コーディング出来ないSEとかいるしな。

661 ：デフォルトの名無しさん：2009/05/27(水) 21:04:13

>>660
そんな中小企業はどうでもいいです

662 ：デフォルトの名無しさん：2009/05/27(水) 21:41:45

>>661
東証一部上場企業の話だぞ。聞いた話であって実際見たわけじゃないが。
企業規模だけでしか物を見れない奴って本当に低能だな。

663 ：デフォルトの名無しさん：2009/05/27(水) 22:02:58

聞いた話を鵜呑みにするなんて
めくそハナクソですよね

664 ：デフォルトの名無しさん：2009/05/27(水) 22:08:23

聞いた話をすべて信用しない奴って友達いないんだな

665 ：デフォルトの名無しさん：2009/05/27(水) 22:19:55

事実確認もしないで信用するなんて俺にはとてもできないけどな
査定に引っかからないなら立ち回りが上手いんだろうそのSEは

666 ：デフォルトの名無しさん：2009/05/27(水) 22:36:25

コーダーに権限と責任を与えないから悪い。だから日本は駄目なんだ

667 ：デフォルトの名無しさん：2009/05/27(水) 22:39:34

結局、ＯＯじゃ工数を１Ｈも削減できないってのが金も人も集まらない理由だよね
結局、最後は数字
これは俺の陰謀じゃなくて上が求めてくるものね
俺も会社も遊びで付き合ってるわけじゃないからなぁ・・・

668 ：デフォルトの名無しさん：2009/05/27(水) 22:40:21

すべてにおいて事実確認をしないと信用できない原理主義者かお前は
設計だけやってコーディングは子会社丸投げということだ。
立ち回りがどうこうではなく組織の問題。

669 ：デフォルトの名無しさん：2009/05/27(水) 22:41:21

>>666
給与を抑えるためにコーダーとSEを分離したのが悲劇の始まり。

670 ：デフォルトの名無しさん：2009/05/27(水) 22:42:56

>>667
というよりOOで設計出来る奴が少なすぎるのが問題ってことだろ。
みんながOOで設計出来れば工数関係無しにそれなりに使われているはず。

671 ：デフォルトの名無しさん：2009/05/27(水) 22:48:10

>>667
いや、工数を削減する能力がないだけ。

672 ：デフォルトの名無しさん：2009/05/28(木) 00:13:47

>>670
ＰＧの単価なんて削ってどうしようっていうのか？
ただでさえ安いもの削る必要なんかない
ＯＯ使って組んだら理解できる人間が少なくなるならそれは単に非効率なだけだろ

>>671
いや、物理的にありえない
だって工数って何で決まるよ？
仕様の数や内容じゃねぇのけ？
ＯＯって単なる実現手段で工数決める場に出てこないし
ってことは使っても使わなくてもなんもお金に影響ないってことだよね

673 ：デフォルトの名無しさん：2009/05/28(木) 00:14:35

SEなんて営業にハクをつけるために作った言葉じゃん。
プログラム書けないのも当り前だよ
仕様も理解できないから工数とかも客の言いなりになってる奴も結構いるよ

674 ：デフォルトの名無しさん：2009/05/28(木) 00:24:38

つか、工数は多く見積もって、少ない工数で作り上げるものなんちゃうの?

675 ：デフォルトの名無しさん：2009/05/28(木) 00:30:49

>>674
だから少なくならないって
仕様を箇条書きで書き出して一つ一つＯＯで工数が削れるものをピックアップしてみろ
おそらく１つもないはず

676 ：デフォルトの名無しさん：2009/05/28(木) 00:31:26

>>672
お前安価間違えてないか？

OO設計とプログラミングを混同してる奴って・・・
論点をずらすなよ

677 ：デフォルトの名無しさん：2009/05/28(木) 00:34:19

>>676
俺はＯＯはどうせ使うなら仕様書で見える概念を
ソースにまでクラスって形でもっていけるのが唯一の利点だと思ってるから
同じだと思うし同じでないとメリットないと思うけど
君は違うの？
違うってことはソースと仕様書に大きく乖離があるってことだから多分君は設計が下手糞なんじゃないかな？

678 ：デフォルトの名無しさん：2009/05/28(木) 00:46:59

> 俺はＯＯはどうせ使うなら仕様書で見える概念を
> ソースにまでクラスって形でもっていけるのが唯一の利点だと思ってるから
> 同じだと思うし同じでないとメリットないと思うけど
本気でそう思ってるならもう一度勉強し直してこい。

679 ：デフォルトの名無しさん：2009/05/28(木) 00:52:35

>>672
> ＯＯって単なる実現手段で工数決める場に出てこないし
そりゃそうだ。

> ってことは使っても使わなくてもなんもお金に影響ないってことだよね
同じお金もらえるんなら、工数少なくてすむ実現方法の方がいいよね。

680 ：デフォルトの名無しさん：2009/05/28(木) 00:55:20

>>675
設計に失敗して、火を吹いてるプロジェクトは結構見かけるが。

681 ：680：2009/05/28(木) 01:01:58

OO使わなくても、きちんと設計されてるのならそれでいいんだろうけど、
設計するのならOOは有効な設計ガイドラインだと思うよ。

682 ：デフォルトの名無しさん：2009/05/28(木) 01:12:13

どうでもいいけど、はやく消えてなくなれよ、オブジェクト指向なんて。
人類の負の遺産だわ。不良債権処理しなきゃ。

683 ：神と言われたヲトコ ◆vBOFA0jTOg ：2009/05/28(木) 01:28:51

OOイラネっていっている奴は数十万ステップとか数百万ステップのコードを開発したことないやつだろ。

684 ：デフォルトの名無しさん：2009/05/28(木) 01:37:44

神ならOOなんていらねえだろｗ
1億ステップのスパゲッティコードにバグ一つ入らん

685 ：デフォルトの名無しさん：2009/05/28(木) 01:50:52

>>683
人力車が現れたときの駕籠かき、タクシーが現れたときの車夫。
酸っぱい葡萄だよ。

686 ：デフォルトの名無しさん：2009/05/28(木) 03:10:32

>>667
お前はOOなんて使わなくても今まで業界でやってきて見積り精度にも
自信があるんだろうが、お前の下についた若いプログラマは
「プロジェクト仕切ってる上司が時代遅れすぎてありえねぇ。無駄な作業多すぎて鬱」
って２ちゃんねるで愚痴ってるかもしれないぞ。

687 ：デフォルトの名無しさん：2009/05/28(木) 03:53:50

ここで今愚痴ってる奴は底辺ですよ
おれ無職だから説得力あるよね

688 ：デフォルトの名無しさん：2009/05/28(木) 04:29:43

>>672
設計することと理解することは全く別。
今時OOで書かれたプログラムを読んで理解出来ない奴を雇っていることこそが
非効率の元凶であってOOが問題ではない。

689 ：デフォルトの名無しさん：2009/05/28(木) 07:47:18

>>672
> ＯＯ使って組んだら理解できる人間が少なくなるならそれは単に非効率なだけだろ

逆だ。クズPGを排除することで効率化が実現される。

プロジェクト管理の肝は、できないPGが足を引っ張るのに対してどう対処するかにある。
できないマネージャーはできないPGを教育しようとしたり、できないなりの仕事をさせる。
一方で、できるマネージャーはチーム内からできないPGを排除する。
すると、マネージャーもできるPGも快適に作業を進めることができる。

690 ：デフォルトの名無しさん：2009/05/28(木) 09:22:33

>>689
>クズPGを排除することで
そして誰もいなくなった、的な。

691 ：デフォルトの名無しさん：2009/05/28(木) 09:28:28

> 俺はＯＯはどうせ使うなら仕様書で見える概念を
> ソースにまでクラスって形でもっていけるのが唯一の利点だと思ってるから

このパターンだよな。この手の人が気軽にOO批判する。

692 ：デフォルトの名無しさん：2009/05/28(木) 09:47:42

おまいら OOがどうこう言ってる奴
まずオブジェクト指向が何なのか説明汁ボケ！

693 ：デフォルトの名無しさん：2009/05/28(木) 09:51:31

　　ﾊ,,ﾊ
　（ﾟωﾟ )　　>>692お断りします
＿(__つ/￣￣￣/＿
　　＼/　　　　 /

694 ：デフォルトの名無しさん：2009/05/28(木) 10:36:15

>>692
ググレカス

695 ：デフォルトの名無しさん：2009/05/28(木) 10:40:41

>>690
いるいる。チームから気に入らないＰＧを排除して自分勝手に進めるやつ
プロジェクトが成功すればいいけど、失敗したら何も残らない…

696 ：デフォルトの名無しさん：2009/05/28(木) 11:27:51

おまえらオブジェクト指向でプログラムするとき
どんな言語使ってる？

697 ：デフォルトの名無しさん：2009/05/28(木) 11:33:25

クズＰＧはｏｏというか言語仕様を活用しまくってる複雑なソースにはさわれんが、
単価の安いＰＧなんて、そんなのばっかりだろ。

出来る人にベースを作らせて、クズＰＧにはｏｏとか意識させずに「この手順でやってください」
手順を明示しても出来ないクズは流石に切った方がいい

698 ：デフォルトの名無しさん：2009/05/28(木) 12:18:07

設計はプロパーがやります。協力会社の方はコーディングだけしてください。
というような変な分業体制作っちゃったから日本の技術力が落ちたんだけどね。

699 ：デフォルトの名無しさん：2009/05/28(木) 12:39:50

建築家と大工を分業しているのに日本の建築技術は世界一ぃぃ
何でだ？

700 ：デフォルトの名無しさん：2009/05/28(木) 13:03:35

日本に限らず、依存性逆転なんて言ってるやつらは
コーディングしやすさを考えて設計したら駄目
と思ってんじゃねーの

701 ：デフォルトの名無しさん：2009/05/28(木) 15:04:13

>>699
プログラミングにおいて設計変更は日常茶飯事だからな。
一部金融系なんかの仕様書ガチガチな業務システムを除いては
設計しながらコーディングというのがあるべき姿であって、
分離する事自体が間違い。

つーか日本のブルーカラーの勤勉さは世界一と言っても過言じゃないぞ。
その代わり給料もそれなりにもらってるがな。

702 ：デフォルトの名無しさん：2009/05/28(木) 15:06:19

日本にはブルーもホワイトもないと思う。

703 ：デフォルトの名無しさん：2009/05/28(木) 15:24:25

仕様書ガチガチだと、プログラミング段階ではオブジェクト指向の恩恵を感じにくいかもなー

704 ：デフォルトの名無しさん：2009/05/28(木) 15:27:31

それはあるだろうね。

705 ：デフォルトの名無しさん：2009/05/28(木) 17:52:17

>>693 >>694
お前ら本当に"オブジェクト指向"をちゃんと定義できるの？

俺が今まで見た中で一番マトモなオブジェクト指向の定義はこれだが
ttp://practical-scheme.net/trans/reesoo-j.html
はっきり言ってこんなの未定義と不定と実装依存を足して３で割ったようなもんだと思う

もっと見事な定義ができるとか、ググればマトモな定義が見つかるっていうなら
是非見せてもらいたい。

706 ：デフォルトの名無しさん：2009/05/28(木) 18:00:58

>>705
それよりよほどましな定義
http://e-words.jp/w/E382AAE38396E382B8E382A7E382AFE38388E68C87E59091.html

707 ：デフォルトの名無しさん：2009/05/28(木) 18:01:23

708 ：デフォルトの名無しさん：2009/05/28(木) 18:09:28

>>706
その定義はC++やJavaなどに毒されているんじゃないか
オブジェクトに対するメッソッドじゃなくて
オブジェクト間のメッセージが本流だろ

709 ：デフォルトの名無しさん：2009/05/28(木) 18:19:33

有名なまとめ
http://d.hatena.ne.jp/sumim/20040525/p1

710 ：デフォルトの名無しさん：2009/05/28(木) 18:28:37

>>709を読むと、>>642がいかにAlan Kayの言う「オブジェクト指向」に
毒されているのが良く分かるな。

711 ：デフォルトの名無しさん：2009/05/28(木) 18:35:37

オブジェクト指向の定義を決めるところから始めなきゃいけないのか

712 ：デフォルトの名無しさん：2009/05/28(木) 18:52:15

>>710
逆だろw >>642がイメージしているのはKay的OOとは正反対だ。

713 ：デフォルトの名無しさん：2009/05/28(木) 19:05:10

俺定義：
オブジェクト指向：ツリー型

714 ：デフォルトの名無しさん：2009/05/28(木) 19:12:34

>>712
それはまったく違うぞ。
>>642の脳内での「オブジェクト指向」の定義はKay的OOだが、
オブジェクト指向「プログラミング」はC++的なものだと思ってるってことだ。

715 ：デフォルトの名無しさん：2009/05/28(木) 20:31:55

"メッセージ"とかご大層なもののように言うけど、単に遅延束縛だろ。いや、ちがう、メッセージとはメタファーでｺﾞﾆｮｺﾞﾆｮとか言うなよ、あくまでプログラミングが便利になる機能かどうかの話だからな。

716 ：デフォルトの名無しさん：2009/05/28(木) 20:37:05

メッセージなんて単にシンタックスシュガーに過ぎん。所詮は関数呼び出し。

717 ：デフォルトの名無しさん：2009/05/28(木) 21:09:35

>>715
> "メッセージ"とかご大層なもののように言うけど、単に遅延束縛だろ。
うんにゃ、メッセージってのは、「ノイズも含めて」ただの信号だ
信号処理系をどうデザインするかは、手法によって変わるんだろうけど

少なくともOOAとかOODって言ってる奴等は
「ノイズも信号のうち」
って、当たり前の事実が分かってない

718 ：デフォルトの名無しさん：2009/05/28(木) 21:11:26

メッセージってどうやって送んの？>>716の言うように関数呼び出し？

719 ：デフォルトの名無しさん：2009/05/28(木) 21:14:03

>>718
単なる関数呼び出し。Objective Cのコードとか見てみろって。

720 ：デフォルトの名無しさん：2009/05/28(木) 21:14:27

>>717
うけねらい？それともOO信者お得意のメタファー？
ネタなら、ごめん。意味分からん。
たとえ話なら、そんなのいいからプログラミングの機能の話がしたい。

721 ：デフォルトの名無しさん：2009/05/28(木) 21:22:30

>>720
OO信者というより、通信理論や信号処理をかじった奴が能書き垂れてるだけだろ。
とんだお笑いものだがな。

722 ：717：2009/05/28(木) 21:24:39

>>720
いや、厳然たる事実

OOA とか OOD とかやってる連中って、やたら例外を作る
「ノイズも信号のうち」と考えてデザインすると
物事はもっと簡単になったりする

# もとハード屋のつぶやきだ

723 ：デフォルトの名無しさん：2009/05/28(木) 21:36:16

>>722
じゃあどう簡単になるのか設計の具体例を挙げてみてよ

724 ：デフォルトの名無しさん：2009/05/28(木) 21:57:14

722じゃないが
nullで例外出さないでNullableで演算を最後まで通してしまうとかかな

725 ：717：2009/05/28(木) 22:38:47

>>724
ソフト的に考えたらそうなんだろうけど

ノイズそのものも評価対象にいれるってゆうか…

ハードつくる場合って例外事象への対応はとってもコストが
かかるんで、伝達関数書くときに外乱を意味する変数を作って、
それも一緒に処理の中に含めるってゆうか…

外乱とかノイズとかも最初から入力の一つの要素として扱う
ってのが、賢いハード屋

726 ：デフォルトの名無しさん：2009/05/28(木) 22:52:03

>>725
だからソフトウェア開発でお前の言った方法論が適用出来る具体例を挙げろよ

727 ：717：2009/05/28(木) 22:54:55

だからゆってんじゃん
例外扱いしなきゃいいって

728 ：デフォルトの名無しさん：2009/05/28(木) 22:57:51

言ってねーだろうが

具体的に何を例外扱いせずにどう処理するんだよ

729 ：717：2009/05/28(木) 23:08:14

>>728
例外事象も入力のうちって捕らえたら
out = f (in, exception-case)
の関数だよな. 内部の状態は適当に隠蔽するとして…

後はカリー化して1入力-1出力の関数になるだろ？

730 ：デフォルトの名無しさん：2009/05/28(木) 23:09:03

>>699
製造業や建設業における設計が、ソフトウェアでは設計＋実装に当たるから。
ソフトウェア産業での「製造工程」ってのは、ビルドフェーズになる。
つまり、既に自動化されている。

731 ：デフォルトの名無しさん：2009/05/28(木) 23:10:42

例外モナドですねわかります

732 ：デフォルトの名無しさん：2009/05/28(木) 23:30:30

nullをNullableで通すっていうのは、maybeモナド

733 ：デフォルトの名無しさん：2009/05/28(木) 23:37:20

exception handling considered harmfulとかありそうで無い

734 ：デフォルトの名無しさん：2009/05/28(木) 23:53:16

>>729
だから入力がfで処理できないようなものだったらどうするのか、ってことなんだが。

735 ：デフォルトの名無しさん：2009/05/29(金) 00:06:34

>>732
C#だとNullableがあってもRoundなどNullable用のメソッドがないから
自分で作っていたが
もしかしてMaybeモナドってそんなことしなくてすむようになるんかな
だとしたらHaskellすごい

736 ：デフォルトの名無しさん：2009/05/29(金) 00:06:38

>>729
で、それがオブジェクト指向とどう関わりがあるんだ？

737 ：デフォルトの名無しさん：2009/05/29(金) 00:11:44

OOってさ、データ構造と手続きを一緒にして何が嬉しいの？
カプセル化？データ構造や内部関数の隠蔽ならMLのモジュールでもできるよ。
逆にデータ構造と手続きを分離できないから、visitorパターンなんていうばかばかしい
テクニックを使わなきゃいけなくなる。
データと手続きを一緒にする意義ってあるの？正直ナンセンスだよ。

738 ：デフォルトの名無しさん：2009/05/29(金) 00:20:18

オブジェクト指向って意味がわかんないんですけど、
サブルーチンのカタマリにしてくってことですか？

739 ：デフォルトの名無しさん：2009/05/29(金) 00:23:32

>>737
カプセル化だけがOOだと思ってるなら勉強不足にも程がある

740 ：デフォルトの名無しさん：2009/05/29(金) 00:25:13

そうそう、そんな感じ。実際にはもっと難解で無意味だから近寄らないほうがいいよ。
おっと、こんな時間にだれかk(ry

741 ：デフォルトの名無しさん：2009/05/29(金) 00:25:57

>>737
データと手続きを分離した場合、無制限に操作を許すと
「システムとして有り得ない状態」を作り出しやすいんだよね。
もしくは、状態を多数つくって管理が破綻するとか。
敢えて制限をかけることで制御のし易さを得ることができるというわけ。

742 ：デフォルトの名無しさん：2009/05/29(金) 00:26:33

構造化言語や構造化設計の経験からOOやOOPに入ったら。
OOの方がいいと思うけど。OOから入った人は、OOが当たり前に有るから。
その欠点しか見えないかもしれないね。これもゆとりの･･･

743 ：デフォルトの名無しさん：2009/05/29(金) 00:26:47

>>739
OO信者最強の武器「勉強不足」www

744 ：デフォルトの名無しさん：2009/05/29(金) 00:27:47

>>741
ジェネリックプログラミングは型の型による制約で分離しつつもそれを防いでいる

745 ：デフォルトの名無しさん：2009/05/29(金) 00:30:13

>>743
アホか？信者じゃねーぞ
批判するならOOを知った上でないと>>737みたいな勘違い批判になるってことだ

746 ：デフォルトの名無しさん：2009/05/29(金) 00:34:04

カプセル化は結果だと思っている

747 ：デフォルトの名無しさん：2009/05/29(金) 00:37:59

>>745
737は勘違いなのか？データと手続きは分離したままで、「システムとして有り得ない状態」
が出ないように隠蔽できるというMLの型システム(モジュール)を知っての上での批判だと思うが。

748 ：デフォルトの名無しさん：2009/05/29(金) 00:38:22

>>744
ジェネリックプログラミングとOOは排他的な概念じゃなかろうもん。

749 ：デフォルトの名無しさん：2009/05/29(金) 00:43:41

MLでも依存型とか型族持ってこない限り力不足は否めないけどな
その意味ではコンストラクタとデストラクタ間で制約を設けられるような類のOO言語の方が有利な場合もある

750 ：デフォルトの名無しさん：2009/05/29(金) 00:45:50

>>747
そんなことは言っていないぞ。

MLのモジュールシステムは基本的に関数やデータタイプを個別の名前空間に閉じ込める
だけだから、「システムとして有り得ない状態」を防げるわけではない。

> データと手続きを一緒にする意義ってあるの？正直ナンセンスだよ。
なんて言う時点で勘違い。

751 ：デフォルトの名無しさん：2009/05/29(金) 00:48:52

>>749
力不足というのは同位
>コンストラクタとデストラクタ間で制約を設けられるような類のOO言語の方が有利
ここ、もちょっとkwsk

752 ：デフォルトの名無しさん：2009/05/29(金) 00:52:39

>>750
>MLのモジュールシステムは基本的に関数やデータタイプを個別の名前空間に閉じ込める
>だけだから、「システムとして有り得ない状態」を防げるわけではない。
そこまで知ってるなら、なぜシグネチャーを知らない？

753 ：デフォルトの名無しさん：2009/05/29(金) 01:15:35

>>750
当然知ってるが。シグネチャは結局モジュールの受け付ける型を制限するだけで
あって、静的型チェックはC++やJavaでもやってること。

754 ：デフォルトの名無しさん：2009/05/29(金) 01:29:43

>>753
http://www.geocities.jp/m_hiroi/func/ocaml09.html
「シグネチャとデータ抽象」あたりを読むべし。

755 ：デフォルトの名無しさん：2009/05/29(金) 01:40:41

>>754
何が言いたいんだ？3行で説明してみろよ。

756 ：デフォルトの名無しさん：2009/05/29(金) 01:53:37

こういうリンクだけ貼って自分の言葉をもってないようなのは人として駄目だよね
せめて引用したい部分だけでも貼れって思う

仮に
>>754
http://www.ntv.co.jp/sekaju/student/20050115/03_0201.html

とかやったら俺のいうことを理解できるまで上記リンクを最後まで読むんだろか？ｗ

757 ：デフォルトの名無しさん：2009/05/29(金) 04:46:28

メッセージ送信と関数呼び出しの区別がつかない人はLuca Cardelliを読め。

758 ：デフォルトの名無しさん：2009/05/29(金) 05:04:48

>>757
違いを具体的に説明出来ないのなら、それは理解していないのと何ら変わりない。

759 ：デフォルトの名無しさん：2009/05/29(金) 05:13:29

>>758
違いはinclusion polymorphismだ。あとは自分で調べろカス

760 ：デフォルトの名無しさん：2009/05/29(金) 05:25:46

>>759
結局説明できないんだな。知ったかのクズが

761 ：デフォルトの名無しさん：2009/05/29(金) 07:18:41

>>759でちゃんと説明になってるだろ。どこまでゆとりなんだ？

762 ：デフォルトの名無しさん：2009/05/29(金) 07:32:24

用語を一つ挙げただけで説明になると思ってるとは、おまえがゆとりそのものだな
曖昧さのないように３行で説明してみろやボケが

763 ：デフォルトの名無しさん：2009/05/29(金) 08:35:29

>>762
人にモノを訊くときにはまず自分で調べてからにしろ。クズ。

764 ：デフォルトの名無しさん：2009/05/29(金) 08:59:42

何度もクソレスする暇はあるのに、単なる定義の違いについて説明するのを
ここまで渋るとは、お前は本当に説明出来ないんだな。
だったら最初から偉そうな物言いをするなよ。

人の名前や述語を挙げて後は調べろで煙に巻くような輩に碌な人間はいないな。

765 ：デフォルトの名無しさん：2009/05/29(金) 09:02:34

かといって、何から何まで教えてくれる暇人がいるとでも？
最低限の知識を踏まえていない人間が議論で相手にされるとでも？

766 ：デフォルトの名無しさん：2009/05/29(金) 09:17:07

>>757のように決して広く一般的に認識を共有されているとは思えない主張を
するのならその根拠を説明するのは当然だろうが。そんなことも理解できないのか？

767 ：デフォルトの名無しさん：2009/05/29(金) 09:23:03

ここまで来ると正直うざいわ
もう>>757は嘘ということで終わりな

768 ：デフォルトの名無しさん：2009/05/29(金) 09:23:40

Luca Cardelliのどの論文を指すのか

769 ：デフォルトの名無しさん：2009/05/29(金) 09:45:54

今のプログラミング言語では Erlang とかの一部の例外を除けば、メッセージングと
称される機構は、ちょっと回りくどい関数呼び出しに過ぎないですよ。それは Smalltalk も同じ。

Smalltalkはあくまで暫定的な仕様のシステムだったのだけれども、いろいろあって途中で変化を
やめてしまった。にも関わらず、それを完成された形と勘違いした多くの言語作者が
この関数のことをメソッドだとかその呼び出しをメッセージ送信だとか、ひそみに倣い
はじめたからおかしな事になったわけです。

ただやっかいなことに、しくみは古いままでも、それをメッセージングだと見なしてプログラミングしたり
そうした思考や行為をサポートする主にメタな機構・ツール・環境を充実させてみると、（領域によっては）
目を見張る生産性を発揮することも分かった。暫定ダイナブックOSとしてのSmalltalkはその実証でもあるわけです。
20年以上再起動することなしに動き、拡張され続けているシステムって、メッセージングのアイデアの
源でもあるインターネットシステムを除けば、Smalltalkの他にないのではないでしょうか。

そんなケイが「メッセージング」を介して本来目指したものや、Smalltalkによって得られた成果についての
ケイ自身の総括みたいなものはここで読めます。
http://metatoys.org/oxymoron/oxymoron.html

以上、長くなりましたがケイの「メッセージングのＯＯ」の参考まで。

770 ：デフォルトの名無しさん：2009/05/29(金) 10:06:10

>>757は真っ赤な顔をしてこのスレから去っていきました

771 ：デフォルトの名無しさん：2009/05/29(金) 10:14:06

>>705
リンク先にもきちんと書いてあるだろ？
元々 well-defined じゃない。

772 ：デフォルトの名無しさん：2009/05/29(金) 13:46:01

アラン・ケイの言うメッセージングなんて、OSに必要なもので、言語に求めるものじゃないだろ

773 ：デフォルトの名無しさん：2009/05/29(金) 17:53:53

カーデリの代表作といったらアレしかないだろw

774 ：デフォルトの名無しさん：2009/05/29(金) 18:44:54

いや代表作とかどうでもいいから関数、
メッセージングの違いとかinclusion polymorphismの話題を含むやつを具体的に

775 ：デフォルトの名無しさん：2009/05/29(金) 18:52:36

アランケイはオブジェクト指向の発起人じゃないよ。

776 ：デフォルトの名無しさん：2009/05/29(金) 19:29:22

OO批判の連中は、どいつもこいつもイニシャル実装の事しか考えて無いんじゃなかろうか。
『作った後で要求がガンガン変わる』という事例にまで頭が回っていないように見える。

777 ：デフォルトの名無しさん：2009/05/29(金) 20:35:28

>>776
http://www.ntv.co.jp/sekaju/student/20050115/03_0201.html

778 ：デフォルトの名無しさん：2009/05/29(金) 20:52:40

OOの考え方って、メッセージングだとかメタファーだとか、とにかくサイエンスやテクノロジーの土俵にのらないから嫌い。

779 ：デフォルトの名無しさん：2009/05/29(金) 20:52:55

結局偉そうなこと言う奴って付け焼き刃だってことが良く分かった。

780 ：デフォルトの名無しさん：2009/05/29(金) 21:48:23

アスペクト指向についてどう思ってる？
あれは、メッセージングの仕組みはオブジェクトの責任分担について一方面しか切り出せず、
横断的な関心事に無力であり、その不便を解消したいという問題意識と捉えると、メッセージ
ングの本質的な弱点を指摘していると思う。

781 ：デフォルトの名無しさん：2009/05/29(金) 22:29:59

>>780
アスベスト？

782 ：デフォルトの名無しさん：2009/05/29(金) 22:53:45

解消できないから横断的って言うんですよ

783 ：デフォルトの名無しさん：2009/05/30(土) 00:13:04

>>778
純粋サイエンスのまま実用的になった技術って正規表現くらいじゃね？

784 ：デフォルトの名無しさん：2009/05/30(土) 00:29:04

正規表現のどこがサイエンスですか。
あれはただの技術ですよ。

785 ：デフォルトの名無しさん：2009/05/30(土) 00:32:01

ム板で語れるサイエンスって数学しかないような。

786 ：デフォルトの名無しさん：2009/05/30(土) 00:42:01

メソッドやらメッセージングやらを見てると
再利用性云々の話は眉唾に聞こえてきてしまう

型エラーにならなけりゃとにかく使いまわせる関数型アプローチにはそういう意味ではかなわないなと

787 ：デフォルトの名無しさん：2009/05/30(土) 00:44:05

>>784
お前ネタで言ってるのか？
正規表現は数学者Kleeneが数学用のツールとして考案したものだ。

788 ：デフォルトの名無しさん：2009/05/30(土) 00:49:01

>>783
サイエンスまでいかなくても、まっとうな議論ができる土台でコンピューター技術に
応用されているものをぱっと思い付きで挙げると、
λ計算、オートマトン、関係代数、述語論理、π計算、圏論、グラフ理論

789 ：デフォルトの名無しさん：2009/05/30(土) 00:53:56

オブジェクト指向＝文系

790 ：デフォルトの名無しさん：2009/05/30(土) 00:59:32

>>787
> ツール
科学じゃねーじゃん

791 ：デフォルトの名無しさん：2009/05/30(土) 01:01:39

>>788
それそれ。
メッセージングだとか多態性だとかカプセル化だとか、本質的にはオブジェクトを物とみなしてだとか、
OOは全然サイエンス的な議論ができないじゃん。だから嫌い。

792 ：デフォルトの名無しさん：2009/05/30(土) 01:03:26

えーと、結局、継承はオブジェクト指向自体とは無関係って事でOK？

793 ：デフォルトの名無しさん：2009/05/30(土) 01:04:57

科学＝解き明かし体系化された概念

794 ：デフォルトの名無しさん：2009/05/30(土) 01:28:20

>>790
馬鹿か？Kleeneの論文読んでこい。

795 ：デフォルトの名無しさん：2009/05/30(土) 01:35:17

あのね、決まり事を作るのは科学じゃないのね。
科学っていうのは解き明かすことが重要なの。

796 ：デフォルトの名無しさん：2009/05/30(土) 01:41:17

>>791
そうか、だからOOはなんとなく宗教チックなんだ。言うことがいちいち大袈裟だし。
長年のもやもやがスッキリした。

797 ：デフォルトの名無しさん：2009/05/30(土) 01:46:19

>>795
お前が言っていることは、数学は科学で無い、と同じ位荒唐無稽な主張だ。
正則表現の定義から導き出される数々の定理を知った上で言っているのか？

798 ：デフォルトの名無しさん：2009/05/30(土) 01:49:03

>>791
まぁエンジニアリング上の問題だからな。
どうしても人間による認識が入ってくるのは仕方ない。

799 ：デフォルトの名無しさん：2009/05/30(土) 01:49:57

>>797
> 正則表現の定義から導き出される数々の定理を知った上で言っているのか？
知らないので教えてくださいｗ

800 ：デフォルトの名無しさん：2009/05/30(土) 01:50:54

>>791
OOはベースになる理論が弱すぎるからな。
あと、いい加減なことを言う商売人が多すぎるのも問題。

その点、関数型は理論に裏打ちされていて良い。

801 ：デフォルトの名無しさん：2009/05/30(土) 01:56:52

>>799
正則表現と有限オートマトンの等価性
Pumping Lemma

802 ：デフォルトの名無しさん：2009/05/30(土) 03:02:31

>>800
OOにベースとなる理論なんてあるの?
基本的に経験則から導き出されたノウハウ的なものだと捉えてるんだけど?

803 ：デフォルトの名無しさん：2009/05/30(土) 03:13:01

つーかOOもそうだがソフトウェア工学全般が胡散臭いっていうか
大した成果が出てないっていうか。研究するには筋の悪い分野だな。

804 ：デフォルトの名無しさん：2009/05/30(土) 05:25:21

>>794
Kleeneのどの論文か言わないとCardelli厨と同一判定されますよw

805 ：デフォルトの名無しさん：2009/05/30(土) 07:46:37

ML系の言語（Haskell, Standard ML, OCamlなど）はλ計算、論理学、圏論を
土台にきちっとした議論ができるから好き。

806 ：デフォルトの名無しさん：2009/05/30(土) 07:49:43

>>804
突拍子もない主張ではないのだからCardelli厨と一緒にするのはやめてくれ。

これが当該の論文だ。わざわざpdfのリンクまで貼ってやったのだから
>>790はこれを読んで荒唐無稽な主張を取り下げること。

KLEENE, S.C.
Representation of events in nerve nets and finite automata.
In Automata Studies, C. E. Shannon, and J. McCarthy, Eds,
Princeton University Press, 1956, pp. 341.

http://www.soe.ucsc.edu/classes/cmps130/Spring09/Papers/kleene_1956.pdf

807 ：デフォルトの名無しさん：2009/05/30(土) 08:58:15

理論が正しくても、それが必要とは限らない。そこで騙される人間もいる。

808 ：デフォルトの名無しさん：2009/05/30(土) 09:10:37

>>792
ほぼOKだけど、文脈による。

ケイのOO（メッセージング指向のOO）やプロトタイプベースのOOでははなから関係ない。
クラスを含め、あってもいいが、無くても成り立つ。

http://www.purl.org/stefan_ram/pub/doc_kay_oop_en

ストラウストラップのOO（クラス指向のOO）では当初中核をなす概念だったが、クックらの指摘で
クラス継承だけでは型安全性が確保できないことが知られるようになってからは
インターフェイス継承や、委譲に軸足が移っている。

http://www.research.att.com/~bs/whatis.pdf
http://ctp.di.fct.unl.pt/mei/talmp/docs/InheritanceIsNotSubtyping.pdf

809 ：デフォルトの名無しさん：2009/05/30(土) 10:03:16

>>805
確かにそうだけど、そこまで理解している人となら何について話しても
論理的な議論が出来そうだな。

810 ：デフォルトの名無しさん：2009/05/30(土) 10:24:00

議論の余地がないから論理的って言うんですよ

811 ：デフォルトの名無しさん：2009/05/30(土) 10:30:55

>>810
また馬鹿が湧いたのか？

812 ：デフォルトの名無しさん：2009/05/30(土) 10:35:12

サイエンスができる人はλ計算や論理学を使ってちゃんとOOの意味を探ろうとしているのに、
OOの定義にしがみついているやつらときたら不毛な論争ばかり。
いい加減気づけよ。

813 ：デフォルトの名無しさん：2009/05/30(土) 10:41:56

お前は妄想もいい加減にしろ。俺は>>800を書いたわけだが。
そもそもラムダ計算でどうやってOOの意味を探るんだ？

> 議論の余地がないから論理的って言うんですよ
一体>>809のどの部分に対して言っているんだ？

814 ：デフォルトの名無しさん：2009/05/30(土) 11:10:42

設計には正解がないから難しいという考え方と
正解を導く理論を知らないだけだという考え方がある。

前者の立場では、非論理的な部分こそが議論のテーマになるってことかな。

815 ：デフォルトの名無しさん：2009/05/30(土) 11:41:01

>>814
正解を導く理論を知ろうとしないから前者の立場になるのでは？

816 ：デフォルトの名無しさん：2009/05/30(土) 12:49:54

>>813
まあ、型システムの整合性とかはよく型付きラムダ計算で論じられるけどね。

ともあれ、抽象データ型タイプのOOについてはそれこそカーデリのシグマ計算、
メッセージングについては方向性が変わってしまうけれどアクター理論とかパイ計算がある
ってあたりで勘弁してくれよ。

817 ：デフォルトの名無しさん：2009/05/30(土) 13:16:06

俺はOOできるてるって奴にかぎって

型付きラムダ計算もそカーデリのシグマ計算もアクター理論もパイ計算も

＊知らない＊のはなぜ？

818 ：デフォルトの名無しさん：2009/05/30(土) 13:18:58

メジャーなOOPLには
本流の計算科学を勉強しなくてもいい製品が作れる方法を
という目的の元育ってきたという側面もあるから

819 ：デフォルトの名無しさん：2009/05/30(土) 13:19:00

道具としての技術と
学問としての技術のちがい？
みたいな？

820 ：デフォルトの名無しさん：2009/05/30(土) 13:19:17

「できるてる」ってどういう意味だ？

つまり、情報系の学科出てない奴等がOOを異常に信奉してるんだろ。

821 ：デフォルトの名無しさん：2009/05/30(土) 13:22:17

>>820
そんな感じがするね。
自分にも最新の技術がわかる→計算機科学なんて大したことないｗ
と思ってる奴が多すぎる気がする

822 ：デフォルトの名無しさん：2009/05/30(土) 13:25:36

OOのユーザーだから。

おれ自動車の運転上手いって奴にかぎって古典的なニュートン力学も
燃焼工学も制御理論も知らないのは何故?って説いても無意味でしょ。
その制御理論を知る人に対して、何で数多の制御デバイスを実装する
半導体物性論も知らないの?と聞くのもまた無意味。世の中分業だし。

なので知っている人はそういう数学的な理屈を上手くラップして
そういうものを知らない人でも広くOOを利用出来るようにデザイン
してあげると良いんじゃないのかな。それが工学ってものでしょ。

823 ：デフォルトの名無しさん：2009/05/30(土) 13:27:04

>>822
> おれ自動車の運転上手いって奴にかぎって古典的なニュートン力学も
> 燃焼工学も制御理論も知らないのは何故?
全然話が違う

824 ：デフォルトの名無しさん：2009/05/30(土) 13:28:05

知らなくていい、というのも恩恵。

825 ：デフォルトの名無しさん：2009/05/30(土) 13:28:25

>>823
どう違う?

826 ：デフォルトの名無しさん：2009/05/30(土) 13:29:10

>>823
そうだよな、うまく載れてないもんな

827 ：デフォルトの名無しさん：2009/05/30(土) 13:29:36

>>825
たとえが全く違う。的外れ。

828 ：デフォルトの名無しさん：2009/05/30(土) 13:31:17

電子工学科では制御方面に行く人間も半導体物性の初歩は学ぶヨ
あと職人って言うような類の人でも理論的な事も勉強してる人は多い
表向きは「勘でやってる」とか言ってるような旋盤工のおっさんでも、
本棚にはボロボロになるまで使われた金属学の専門書があったりする

829 ：デフォルトの名無しさん：2009/05/30(土) 13:31:42

>>827
だからどういう文脈で的を外しているのか、それを聞きたいのだが。

830 ：デフォルトの名無しさん：2009/05/30(土) 13:31:44

怒らないでマジレスしてほしいんだが

型付きラムダ計算やらカーデリのシグマ計算やらが出来たら
もっと上手くOOPできるようになんの？

831 ：デフォルトの名無しさん：2009/05/30(土) 13:34:15

世間で言われてるようなOOPはできないかも知れんがOOPの目的は達成できるようになる
そういう手法を自分で構築できるようになる、それを他人に教えることもできる

832 ：デフォルトの名無しさん：2009/05/30(土) 13:36:40

>>822の例えの良し悪しは置いておくとしても、素人談義に首を突っ込んでも
時間の無駄ってことだけは言えそうだな。

833 ：デフォルトの名無しさん：2009/05/30(土) 13:39:14

設計と実装を分業してたらOOPのメリット無いかも。
実装をラクにするために、柔軟に組んでいけるように、設計を工夫するんだろ。

肝心の実装を人任せにするんなら、設計はもはや他人事。

実際に実装で悶々しながら設計し、
実装で手ごたえを感じてまた設計に反映させる。

これが一番おいしいOOPじゃないかな。
非OOPでももちろん設計と実装の関係は同じことが言えるけど、
OOPならそこから先にまだちょっと伸びしろがあり、そこが醍醐味。

834 ：デフォルトの名無しさん：2009/05/30(土) 13:41:13

>>830
まず、OOPを支持すること自体が無学の証というわけなんだよ。
全然形式化されていない手法を支持するって怖くないの？
形式化されていないということはその先の発展性が無いんだよ、OOPは。

835 ：デフォルトの名無しさん：2009/05/30(土) 13:41:30

>>831
世間で言われてるようなOOPが出来ないってことは
既存のOOP言語使えなくなるんと違うの？

836 ：デフォルトの名無しさん：2009/05/30(土) 13:44:26

言語はあくまで道具だ

837 ：デフォルトの名無しさん：2009/05/30(土) 13:46:30

>>834
>全然形式化されていない手法を支持するって怖くないの？

全然。

>形式化されていないということはその先の発展性が無い

形式化されていないこととその後の発展性の因果がよく
分からない。
そもそも何をもって「発展」とするのか、形式的な定義が
与えられていないのでよく分からない。

838 ：デフォルトの名無しさん：2009/05/30(土) 13:48:49

いったんOOで作ったらあとは部品を使い回すだけで
楽できるのに。

839 ：デフォルトの名無しさん：2009/05/30(土) 13:49:22

>>837
「形式化」という言葉も理解できていない様子ですね。

840 ：デフォルトの名無しさん：2009/05/30(土) 13:51:37

>>838
というのはセミナー屋のプロパガンダに過ぎないね。
どうも洗脳されている奴が多すぎて困る。
ちゃんと計算機科学を勉強して博士号を取得した奴以外喋るなよ。

841 ：デフォルトの名無しさん：2009/05/30(土) 13:51:51

このスレで、計算機科学勉強した人でOO信者いる？

842 ：デフォルトの名無しさん：2009/05/30(土) 13:53:26

>>840
そうそう、セミナー屋とか似非コンサルタントに騙されてる奴等多すぎ。
まあこのスレがどの板にあるのか考えたら仕方ないのかもな。

843 ：デフォルトの名無しさん：2009/05/30(土) 13:55:22

この業界、セミナー屋がずいぶん幅をきかせてるよな・・
流行って全部セミナー屋が作ってるようなもんだし。
今度は関数型言語が食い物にされるのか・・　ウザ

844 ：デフォルトの名無しさん：2009/05/30(土) 13:57:00

>>839
うん。説明してみて。

845 ：デフォルトの名無しさん：2009/05/30(土) 13:59:50

>>844
大学院行って勉強してこい

846 ：デフォルトの名無しさん：2009/05/30(土) 14:01:13

>>845
それは高等教育を受けた者の姿勢としては負けだと思うな。
理解しているのなら、説明できるでしょ。

847 ：デフォルトの名無しさん：2009/05/30(土) 14:03:31

>>846
じゃあググれ
ここで書けるぐらいのことならググった方が早い
ここで書けないぐらいのことなら大学院で勉強しろ

以上

848 ：デフォルトの名無しさん：2009/05/30(土) 14:04:58

日本でHaskellが流行ったといっても、その何割がWadlerやFokkingaの名を知っているのかとか考えると
食い物にされる可能性は高いだろうね

849 ：デフォルトの名無しさん：2009/05/30(土) 14:05:26

院生連投頑張り杉

850 ：デフォルトの名無しさん：2009/05/30(土) 14:06:43

誰が何をどうやって食い物にするんだよ。
で、それによって誰がどういう原理で困るんだよ。困らないのか？

851 ：デフォルトの名無しさん：2009/05/30(土) 14:11:47

>>847
ケチだなぁ。お薦めのポインタすら貼らないとは。
学んだことを社会に還元できなくっては、国が高等教育に予算を
注ぐ意義も無くってよ?

>>848
WadlerやFokkingaとか知っているとどうして食い物にならないの?

852 ：デフォルトの名無しさん：2009/05/30(土) 14:11:53

>>850
プロパガンダで信者を増やす→信者が信者を増やす→セミナー屋がっぽり

853 ：デフォルトの名無しさん：2009/05/30(土) 14:16:31

目的の違う人間同士で”俺の目的の方が正しい、お前の目的は間違ってる！”って訳ですね判ります

854 ：デフォルトの名無しさん：2009/05/30(土) 14:18:10

>>834
形式化されてないと嫌だってのは、ナイーブに過ぎるな。
それと、形式化されている手法を使ったとしても
いいプログラムが書けるとは限らないことも知っておこう。

855 ：デフォルトの名無しさん：2009/05/30(土) 14:19:41

OOって一言で言ってもいろんな文脈がある。全然一緒に語るのは無理がある。

"勉強してこい"って言っている人は、学問的には通じるのかも知れないが、エンタープライズアプリにはきっと誰も耳をかしてくれない。想像力を働かせて簡潔な説明がないと普及しない。

856 ：デフォルトの名無しさん：2009/05/30(土) 14:32:51

>>855
> エンタープライズアプリ
の現場が、破綻してるからこんなにスレが延びてるんちゃうの？

857 ：デフォルトの名無しさん：2009/05/30(土) 14:36:52

>>856
同意

858 ：デフォルトの名無しさん：2009/05/30(土) 14:37:35

>>855
計算の可能性に興味があって金儲けには全く興味なし。

859 ：デフォルトの名無しさん：2009/05/30(土) 14:38:57

>>858
そういう貴方にスレの大半の住民は興味なし。

860 ：デフォルトの名無しさん：2009/05/30(土) 14:41:54

>>856
それは違うぞ、きっと………

OO やりたい奴は、意地でも OO したいらしい

ある FX がらみのシステムで数学的にちゃんとしたバックグラウンドが
あって、発注側から実現するために必要な要素がほとんどすべて、数式
で与えられたのにもかかわらず、OO 分析しますとか言ってる奴もいるから

861 ：デフォルトの名無しさん：2009/05/30(土) 14:42:06

もう素人には勝手にあーだこーだ言わせとけばいいよ。
正則表現を技術だなんて言うくらいなんだから、理論的な話をしても無駄。

862 ：デフォルトの名無しさん：2009/05/30(土) 14:47:28

もう院生さんには勝手にあーだこーだ言わせとけばいいよ。
理論を実践に応用する議論をする気も皆無だろうから、現場的な話をしても無駄。

863 ：デフォルトの名無しさん：2009/05/30(土) 14:48:41

関数型言語で意地でもポイントフリーで書くのとか
証明で背理法使えば楽なのに意地でも使わないで証明するのと似ている
自分の慣れた理解しやすい世界で処理した方がわかりやすいからなるべくそうしたい
ってのは誰にでも、どんな世界にでもある傾向だよ

864 ：デフォルトの名無しさん：2009/05/30(土) 14:48:55

>>860
数式計算を実装するのと、システムを設計するのはまったく別の話しであることがわからないの？

865 ：デフォルトの名無しさん：2009/05/30(土) 14:53:19

形式化なんか必要ないと思っているOO信者が沸いているようだが、
形式化は計算機科学の進歩の要であって非常に重要なことだぞ。
というのも、なぜ形式化をするかというと、要はプログラムのデバッグを自動化したり、
プログラム自体を自動的に生成したりしたいからなんだよ。
金儲け主義のプログラマさんだってバグ探しとか大変でしょ？
バグ探しにしてもプログラムの解析が必要だけど、
もし形式化されていなかったらプログラム自体を解析するプログラムをどうやって作ればいいのかわからないよね。

866 ：デフォルトの名無しさん：2009/05/30(土) 14:53:59

>>864
言っとくけど、数値計算的な意味での数式じゃないからな

顧客が要求する、システムの振る舞いが数式出来ていされているのに
それを OO 分析してなんか意味があるの？

「お前らはこれを実装しろ」と、顧客は言ってるのに
知恵たらずの OO 分析溶かしても意味ないじゃん

867 ：デフォルトの名無しさん：2009/05/30(土) 14:56:31

>>863
ポイントフリーで書けないHaskellプログラマは頭が悪いと見なされて差別の対象になります

868 ：デフォルトの名無しさん：2009/05/30(土) 15:01:53

OOってデザインのメソッドだからね。

例えば、建築デザインの手法について議論する場で、
「そんな理論的裏付けの貧弱な手法より、この建築構造の方が理論として優れている」
と言われても、切り込み方がおかしいとしか思えないのと同じだな。

869 ：デフォルトの名無しさん：2009/05/30(土) 15:02:58

OO議論の時もOOPを指すのかOOAとかOOMを指すのかはっきり
させろというツッコミが多かったが、形式さんも何の形式化の事を
話しているのかはっきりして欲しい。

870 ：デフォルトの名無しさん：2009/05/30(土) 15:04:47

>>869
オブジェクト指向の数学的モデル化

871 ：デフォルトの名無しさん：2009/05/30(土) 15:05:39

ソフトウェア開発そのものが形式化(キリッ！

872 ：デフォルトの名無しさん：2009/05/30(土) 15:06:12

よく分からんが
関数も、変数も、定数も、なんもかんも全部オブジェクトなんじゃないの?

873 ：デフォルトの名無しさん：2009/05/30(土) 15:06:51

>>872
オブジェクト(物体)なら触れるはず
つまりオブジェクトなんて最初から無かったんだよ！

874 ：デフォルトの名無しさん：2009/05/30(土) 15:07:46

>>870
その「数学的にモデル化されたオブジェクト指向」とやらで設計された
プログラムが本当に用件から見て正しいのか、どう確認すればよいのか。

875 ：デフォルトの名無しさん：2009/05/30(土) 15:07:57

ではワタシはこちらで構えておりますので、
どうぞ屏風からOOを追い出してください。

876 ：デフォルトの名無しさん：2009/05/30(土) 15:08:38

>>862
コピペはお断りします。

877 ：デフォルトの名無しさん：2009/05/30(土) 15:09:35

オブジェクト指向のオブジェクトって鋳造とか言う意味じゃないの?
物体なんて捉えてたら、理屈が通らないと思うのだけれども

878 ：デフォルトの名無しさん：2009/05/30(土) 15:10:36

>>874
要件　ね。
要件自体を形式的に定義できる手法が存在する。
その要件とプログラムに整合性があるかどうかを検証するプログラムを使えばいい。
でもオブジェクト指向だとどんな風にそんなプログラムを作ればいいのかまだ誰も解らない。

879 ：デフォルトの名無しさん：2009/05/30(土) 15:12:22

要件を叙述可能な形にする段階までが要件定義

880 ：878：2009/05/30(土) 15:14:06

俺が言っていることは実際にJRのシステム開発で行われたことがあるんだよ。

881 ：878：2009/05/30(土) 15:14:48

JRじゃないな。旧国鉄か・

882 ：デフォルトの名無しさん：2009/05/30(土) 15:15:39

>>877
オブジェクトは多くの場合クラスまたはインスタンスを指す曖昧な言葉
mayerのOOSCの最初の7章あたりの議論にその辺の問題に関するmayerの見解が詳しく載っている

883 ：デフォルトの名無しさん：2009/05/30(土) 15:17:34

>>880
ひょっとしてProlog使って実装したシステム？

884 ：デフォルトの名無しさん：2009/05/30(土) 15:18:49

>>883
そうそう

885 ：デフォルトの名無しさん：2009/05/30(土) 15:21:00

>>878
要件だね。
>要件自体を形式的に定義できる手法が存在する。
うん。なので聞いた。どこの形式化を指しているのか。

でも、この仕組みで行くと要件自体が形式化されていないと
「数学的にモデル化されたオブジェクト指向」とやらには現場的
にはまるで意味が無いじゃない。移行コストが面倒なだけで。

鶏と卵でいけば要件はソフトウェアを作る上であからさまに鶏
なので、そっちにも積極的にツッコミを入れないと。
ただ現場で使われている方法論を叩いたところで賛同は殆ど得ら
れないと思う。実益無いんだもん。

886 ：デフォルトの名無しさん：2009/05/30(土) 15:22:31

>>882
だから、鋳造という言葉なんでしょ?
鋳造という言葉だけでは、鋳型の作成なのか、鋳造物なのか、鋳造物を作る工程なのかさっぱり解らないでしょ

887 ：デフォルトの名無しさん：2009/05/30(土) 15:22:32

>>881
古い話みたいだけど、その開発手法が何故普及しなかったか
分析とかは無いの?

888 ：デフォルトの名無しさん：2009/05/30(土) 15:23:17

lojbanが標準語になってかつ述語論理の概念を全員が共有できればあるいは…

889 ：デフォルトの名無しさん：2009/05/30(土) 15:26:33

>>885
実益はある。
曖昧な仕様で開発を始めると仕様バグに悩まされることになるぞ。

仕様バグだけでなくプログラムのバグに関しても、
変なところで無限ループしていたり、デッドロックしていたり、いろいろあるけど
そういうバグの解析にも形式的モデル化が役に立つね。

890 ：デフォルトの名無しさん：2009/05/30(土) 15:27:15

>>887
失われた１０年

891 ：デフォルトの名無しさん：2009/05/30(土) 15:28:11

要件が形式的に表現される案件では有効かもな。そんな案件はめったにないけど。

892 ：デフォルトの名無しさん：2009/05/30(土) 15:30:51

>>891
原因は一つ。
SEが無学な文系だったということ。

893 ：デフォルトの名無しさん：2009/05/30(土) 15:32:03

つまり誰にも現状と実現可能な理想が見えてないような状況で開発が行われている…と
そりゃ方法論以前の状態だな

894 ：デフォルトの名無しさん：2009/05/30(土) 15:32:17

要件をいかにして形式的に表現するかに知恵絞るのがまっとうな設計屋なのでは？

かりに、今抱えてる案件でなおかつ今の俺では力足らなくてもだ

895 ：デフォルトの名無しさん：2009/05/30(土) 15:33:58

形式的なモデル化と、OOによる設計は対立する概念じゃないだろ。

896 ：デフォルトの名無しさん：2009/05/30(土) 15:34:31

JR総研は今でもVDMなどの形式手法を取り入れている。
OOにしろFMにしろ、否定する奴はバズワードふり回して
「こんなのはバズワードだ」とトートロジーかます奴が多い。
その手の輩が20年前に現われていたら構造化を否定していただろう。

897 ：デフォルトの名無しさん：2009/05/30(土) 15:35:25

>>895
全く矛盾しないどころか、現代的な形式的手法の多くにはOO拡張が存在する。

898 ：デフォルトの名無しさん：2009/05/30(土) 15:35:26

>>895
オブジェクト指向が形式的にモデル化できていない現状では何ともいえない。
関数型言語は明確にモデル化されている。

899 ：デフォルトの名無しさん：2009/05/30(土) 15:36:27

OO分析は非形式的にも程がある手法

900 ：デフォルトの名無しさん：2009/05/30(土) 15:39:20

言語と設計手法と要件を混同してないか?

901 ：デフォルトの名無しさん：2009/05/30(土) 15:39:56

ソースが仕様（笑）

902 ：デフォルトの名無しさん：2009/05/30(土) 15:41:50

>>896
構造化⊆オブジェクト指向

903 ：デフォルトの名無しさん：2009/05/30(土) 15:42:27

テストコードが仕様(笑)
仕様→実装　（笑)
型が仕様でコードは証明(笑)

904 ：デフォルトの名無しさん：2009/05/30(土) 15:43:12

つまり、構造化がウンコならオブジェクト指向もウンコ

905 ：デフォルトの名無しさん：2009/05/30(土) 15:44:47

>>896
う～ん、実績があるにせよOO云々を駆逐するほど普及しないのには
何か見えないコストや難点があるんでないの?
人材コストっていう説明でもよい。その場合の解決策は教育システム
と言うことになるから。一体何なんだろう。

906 ：デフォルトの名無しさん：2009/05/30(土) 15:46:11

ここの人達ってOO嫌いで関数型大好きみたいなんだけど
ふだんどんなプログラム作ってんの？
HaskellとかでOSSのアプリ作ってる人達ばっかなの？

907 ：デフォルトの名無しさん：2009/05/30(土) 15:46:38

>>905
> 何か見えないコストや難点があるんでないの?
あるよ。
ただ単純に、仕様記述言語の書き方が理解できる奴が少ないってこと。
仕様記述そのものがプログラムに見えなくもない。

908 ：デフォルトの名無しさん：2009/05/30(土) 15:53:50

仕様記述言語による記述に要件とのずれがあったらどうするんだろう。

909 ：デフォルトの名無しさん：2009/05/30(土) 15:55:28

>>906
Haskellは使うけど、型クラスは使わないんだろうなw

910 ：デフォルトの名無しさん：2009/05/30(土) 15:56:58

先にＣ言語の工数見積もられてオブジェクト指向ならＮ分の１にできる？
って言われてＮが２以上にできたら勇者だよね

911 ：デフォルトの名無しさん：2009/05/30(土) 15:58:40

C言語でオブジェクト指向が出来ないような物言いだ。

912 ：デフォルトの名無しさん：2009/05/30(土) 15:58:50

>>907
人材も揃わないような技術は使い難いなぁ。正直サイズの合わない
ネジみたいなものじゃん。

あと「理解出来る奴が少ない」と言うのは単にマイナーだから?
あるいは高度な訓練や素養が必要だから?
前者なら単に教育のマスを増やせば解決するけど、後者だとすると
なかなか人材コストが下がらないから結局普及は難しいような。

913 ：デフォルトの名無しさん：2009/05/30(土) 15:59:34

>>910
開発工数は言語や方法論よろもまず技術者の質がモノを言う。と答える。

914 ：デフォルトの名無しさん：2009/05/30(土) 16:07:59

>>911
グダグダな設計を、OO的にまともなものに変更してメンテナンス工数を1/5にしたことならあるよ

915 ：デフォルトの名無しさん：2009/05/30(土) 16:40:42

>>914

それは OO を使わなくても可能な範疇だろ?
実質的には OOA とか OOD とかって全然こなれてないじゃん

OOP は使いどころによっては結構役に立つけど, C++ とか Java みたく
関数がファーストクラスじゃない言語だと, あちこち不細工になるじゃん

916 ：デフォルトの名無しさん：2009/05/30(土) 16:46:19

>>914
OO的ではないがまともな設計に直してたら1/6になってたりして。
いずれにしても工数が減らせるかどうか説得力のある説明をするのって
難しいよね。
(過去の事例からデータを取るのも難しいし、実験するにもコスト、時間がかかりすぎる。)

917 ：デフォルトの名無しさん：2009/05/30(土) 16:49:00

918 ：デフォルトの名無しさん：2009/05/30(土) 16:49:31

とても大事な事だから

919 ：デフォルトの名無しさん：2009/05/30(土) 17:15:07

>>914
以前動いていたシステムの設計を変更して、その後でもちゃんと動くかどうか保証できるのか？

920 ：914：2009/05/30(土) 17:23:23

そのためのテストパターンだろ。
設計変更するついでに既存コードにあるバグもけっこう見つかったけどな。

921 ：デフォルトの名無しさん：2009/05/30(土) 17:35:13

絶対に嘘っぱちだから安心して読めるなｗ

922 ：デフォルトの名無しさん：2009/05/30(土) 17:36:26

仮にこれが証明できたとしても

じゃ、次からは工数５分の１でやってもらうからｗ
あ、給料はそのままねｗ

なんて未来しか見えないから激しくどうでもいい

923 ：デフォルトの名無しさん：2009/05/30(土) 17:36:50

>>916
> OO的ではないがまともな設計に直してたら1/6になってたりして。

今さら仮定の話を持ち出しても。。。

> いずれにしても工数が減らせるかどうか説得力のある説明をするのって
> 難しいよね。

実績を示した人に対して仮定の話を持ち出して揶揄する人がいるから
じゃないかな。

924 ：デフォルトの名無しさん：2009/05/30(土) 17:53:51

>>922
工数がそのまま給与に反映されるとか、どんだけ零細なところで働いてるんだよ？

925 ：デフォルトの名無しさん：2009/05/30(土) 17:56:59

>>920
たとえばなぜ銀行のシステムが未だにCOBOLを抜け出せないのか解らないのか？

926 ：デフォルトの名無しさん：2009/05/30(土) 17:59:20

>>924
だから反映されないだろｗ
５倍働いても給料はそのままだよｗ

927 ：デフォルトの名無しさん：2009/05/30(土) 18:07:50

給料は日給月給だから、1/5の工数で終われば、その分遊べるんじゃね?

どうせ8時間は拘束時間だし

928 ：デフォルトの名無しさん：2009/05/30(土) 18:08:05

まともに動いてるCOBOLコードを直す必要なんて無いからじゃね。

929 ：デフォルトの名無しさん：2009/05/30(土) 21:39:50

結局あれだ
アムロもカミーユもニュータイプでエースパイロットだが
その前は自前でロボット作ってたって話だよ

930 ：デフォルトの名無しさん：2009/05/30(土) 22:09:21

シャアも自前でロボット作ってたの？

931 ：デフォルトの名無しさん：2009/05/30(土) 22:14:01

関数型言語には、フローチャートや
UMLみたいな設計の図解方法はあるの？

932 ：デフォルトの名無しさん：2009/05/30(土) 22:24:59

どちらもガンダムの強奪をやらかした生粋のハッカーで
しかもカミーユは後にZガンダムの設計までやってる
素質としてはカミーユの方が数段上かもしれない
こんな奴等が、他人の作った機体をコロコロ乗り換えるだけのシャアや
雑魚をけしかけて遠くから眺めるだけのシロッコに負けるわけがないだろう

オブジェクト指向を使うってことは、足がなくても100%だとか主観で
格付けする整備士の戯言を真に受けるようなものだ

933 ：デフォルトの名無しさん：2009/05/30(土) 22:44:06

確かに、自前で作れれば現場に文系が多かろうが
マイナー言語でライブラリ書く奴が少なかろうが
何の問題もないからな。

934 ：デフォルトの名無しさん：2009/05/30(土) 22:53:17

>>932
はっきり言う。気に入らんな

935 ：デフォルトの名無しさん：2009/05/30(土) 22:55:51

何でも使えそうな文だな

関数型言語を使うってことは、足がなくても100%だとか主観で
格付けする整備士の戯言を真に受けるようなものだ

936 ：デフォルトの名無しさん：2009/05/30(土) 23:06:50

大佐なら上手くやれますよ！

937 ：デフォルトの名無しさん：2009/05/30(土) 23:10:54

>>935
関数型言語は数学的な裏付けがあるから例えとしては合わないのでは。

938 ：デフォルトの名無しさん：2009/05/30(土) 23:17:40

>>931
> フローチャート
無駄なものの筆頭

> UMLみたいな設計の図解方法
ハード屋が使ってる似たような図にはバックグランドに
それなりの理屈はあるが、UML の図って奴等が理屈を
視覚化するための使ってる図の、見た目だけの劣化コピー

実質的に、まともに使えてシステムを表現してるのは
ステートダイアグラム程度じゃねぇの

939 ：デフォルトの名無しさん：2009/05/30(土) 23:19:59

>>937
自前で処理系作る話だ。
ベーパーウェアでは話にならん。

940 ：デフォルトの名無しさん：2009/05/30(土) 23:37:44

>>822 に対する >>827 の説明はまだなの？

941 ：デフォルトの名無しさん：2009/05/31(日) 00:00:39

フローチャートもＵＭＬも欲しい資料ではないよなぁ
いるいらないも判断せずにこういうの一生懸命作っちゃうやつってすげー嫌い
フローも業務フローはいるけどソースのフローはいらねぇよなｗ
ＵＭＬも仕様に近いもんならほしいけどクラスを機械的にかいたもんはお断りしたいｗ

942 ：デフォルトの名無しさん：2009/05/31(日) 00:08:41

コードのフローチャートは論外として、UMLで書いてコードに直接落とし込む
ようなツールをセミナー屋や商社代理店がよく宣伝してたが、実際に今でも
使ってる奴っているのか？そして実際にどれ程効果があるのか教えてほしい。

943 ：デフォルトの名無しさん：2009/05/31(日) 00:13:18

>>942
あー役にたつっちゃやくにたつし、たたないっちゃたたない

本質的にどうモデル化するかの方が大事で、その部分は全く経験則の塊
ゴミ突っ込みゃゴミが出てくる

944 ：デフォルトの名無しさん：2009/05/31(日) 00:14:20

図を書くのにエラい時間がかかるし、そもそもクラスの雛形を作る時間が短縮できても
全体の作業量には殆んど影響しないのでむしろ効率が落ちるという…

945 ：デフォルトの名無しさん：2009/05/31(日) 00:17:57

ネジにもいろんな種類がある事を知らない奴らが、オブジェクト指向は使えないって言うんだよ

946 ：デフォルトの名無しさん：2009/05/31(日) 00:18:01

プロジェクトでたま～に必要になる大改造で
図とソースで整合性が合わなくなったときの面倒臭さは異常
ただでさえ忙しいのにそんなのかまってらんねー

947 ：デフォルトの名無しさん：2009/05/31(日) 00:21:37

>>945
> ネジにもいろんな種類がある
当然その中には OO で作れないネジもある事も理解して言ってるんだよな？

948 ：デフォルトの名無しさん：2009/05/31(日) 00:22:56

>>947
ネジはどんな形でもネジだと言う事も知らないらしい...

949 ：デフォルトの名無しさん：2009/05/31(日) 00:23:41

>>945
ほう・・・
じゃあ、工数いくつ削れるの？

950 ：デフォルトの名無しさん：2009/05/31(日) 00:27:40

セミナー屋がどうとか言ってる奴がいるけど、そんなセミナー受けなきゃいいだけじゃん。
どうせこの業界でのセミナーなんて役に立たないのはわかってるんだし。

951 ：デフォルトの名無しさん：2009/05/31(日) 00:30:39

UMLは、ホワイトボード使って議論するときに共通知識として使えるってのが一番の使い道。

952 ：デフォルトの名無しさん：2009/05/31(日) 00:31:51

>>951
はぁ？

953 ：デフォルトの名無しさん：2009/05/31(日) 00:33:34

お絵かきで物事を伝えなければならないときに一応よく知られた書き方
として使えるメリットはあるよね>UML

954 ：デフォルトの名無しさん：2009/05/31(日) 00:35:51

そうそう、こういう生産性に何の寄与もしないツールを高額で売りつける
ベンダーや代理店が多すぎること、そしてそれにすぐ騙される奴が多いから
OO自体胡散が臭く思われる。

955 ：デフォルトの名無しさん：2009/05/31(日) 00:36:09

仕様書あるなら仕様書使って説明すればいいじゃん
ないならＵＭＬなんて書いてる場合じゃないんだよ

956 ：デフォルトの名無しさん：2009/05/31(日) 00:37:17

>>954
ホントだ
詐欺ばっかりだったよなー
１００万近くもするクズツール平気で売りつけるヤツとかホント酷い

957 ：デフォルトの名無しさん：2009/05/31(日) 00:37:18

クラス図: 出来の悪いブロックダイアグラム
シーケンス図: さらに出来の悪いタイミングチャート
状態遷移図: まぁ、許してやろう

他になんかあったっけ？

958 ：デフォルトの名無しさん：2009/05/31(日) 00:38:46

>>955
その仕様に関してどうすればいいかを議論する場だよ。

959 ：デフォルトの名無しさん：2009/05/31(日) 00:38:56

俺はセミナーと言えば、MSとOracleの無料セミナーしか行った事無いから、
セミナー屋云々の話がいまいちよく分からない。

960 ：デフォルトの名無しさん：2009/05/31(日) 00:46:51

>>959
オブジェクト指向関連のセミナーにいっては駄目とだけ覚えておけ

961 ：デフォルトの名無しさん：2009/05/31(日) 00:49:11

>>960 >>959 ではないが
会社が金払って一日寝ててもいいって言うてくれるんだから絶対に行くw

962 ：デフォルトの名無しさん：2009/05/31(日) 00:58:41

クラス図やアクティビティ図シーケンス図は
考えを整理するときにコピーの裏に思い切りインフォーマルなやつをちょこちょこと書くぐらい

963 ：デフォルトの名無しさん：2009/05/31(日) 01:10:07

>>950
違うね。セミナー屋のやり口はそれだけじゃない。
派遣やら本書きやら大学・専門学校での講義や資格セミナーや有名人を取り込んでブログや本書きなどで宣伝させたり、あの手この手でプロパガンダを広めていくのがセミナー屋の恐ろしいところ。

964 ：デフォルトの名無しさん：2009/05/31(日) 01:11:08

特にオージス総研はウンコ

965 ：デフォルトの名無しさん：2009/05/31(日) 01:57:41

オブジェクト指向関連のセミナーいって
「で？工数はいくら削れるんです？」とか具体的な質問してくるといいよ
だってこんなのビジネスの席で用意してねーほうが悪いんだから
積極的に聞いて良し（これでまともな答えを返せるやつがいたらそのセミナー参加してみたい）

966 ：デフォルトの名無しさん：2009/05/31(日) 02:02:47

セミナー嫌いをやたら表明してる奴は、何か痛い目にあったのか？

967 ：デフォルトの名無しさん：2009/05/31(日) 02:07:56

>>965
そんなこと言っても、大抵は、

「システム稼働までの工数削減だけでなくメンテナンスフェーズまで考えた
トータルでの効率化を実現するものです。お客様がご所望のシステムを分析
しないと細かく見積りは出来兼ねますが総工数が1/nになった事例もあります。」

とか適当に煙に巻き続けるだけだろ。口だけは上手いからな。

968 ：デフォルトの名無しさん：2009/05/31(日) 02:32:08

>>965
逆に、君が推奨する方法を採用すれば、採用していないときと比べて
工数がどれだけ減るのか聞きたい。

969 ：デフォルトの名無しさん：2009/05/31(日) 02:57:01

>>968
俺が推奨する方法？
普通に組むの一択だろ
もう末端ＰＧは汎用化なんて気にしなくていいんだよ
逆に気にすることで工数が無駄にかかってしまっている
何もするなといいたい
ひたすらベタで書け

970 ：デフォルトの名無しさん：2009/05/31(日) 03:13:49

>>966
おおかた高いツールを買わされたはいいが、きっと能力不足で使いこなせなかったんだろうな。

971 ：デフォルトの名無しさん：2009/05/31(日) 03:27:36

>>969が、プロジェクトやチームで一番要らない人間に思えて仕方が無い

972 ：デフォルトの名無しさん：2009/05/31(日) 03:47:55

>>969の下で育った後輩が可哀想だ。

973 ：デフォルトの名無しさん：2009/05/31(日) 06:14:16

>>937
君さあ、関数型言語は数学的裏付けがあるなんて呑気に言ってるけど、
型推論はNP完全だということが証明されている件についてはガン無視ですか？