オブジェクト指向って自然な文法だな 3 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2017/04/02(日) 16:30:38.65

前スレ
オブジェクト指向って自然な文法だな 2
http://echo.2ch.net/test/read.cgi/tech/1490506257/

**デフォルトの名無しさん** · 2017/05/19(金) 21:11:32.92

どうやって隠すか
ライブラリ作成側になると学びは多いよ

**デフォルトの名無しさん** · 2017/05/19(金) 22:24:14.23

>>592
スタックトレースを見るんだ

**デフォルトの名無しさん** · 2017/05/20(土) 06:03:34.30

大きなシステムとか組んだ事ないんだろ

**デフォルトの名無しさん** · 2017/05/20(土) 18:54:10.07

まあ実際の処理を隠蔽するのがまさに１つの目的だし
たらい回しというか参照辿って芋づるで引っ張れる設計じゃないし、むしろそこがオブジェクト指向のキモだからな

**デフォルトの名無しさん** · 2017/05/20(土) 19:17:55.25

実際の処理が見れないと困るケースがもしあれば
設計が既に破綻してるって話だわな

**デフォルトの名無しさん** · 2017/05/20(土) 20:09:39.79

役員が下っ端社員の細かい作業手順を知る必要ないからな。
ちゃんと結果報告が上がってくれば作業手順は他の人間に影響を与えてなければ関係無い。

**デフォルトの名無しさん** · 2017/05/20(土) 20:38:10.12

オブジェクト指向は総活躍社会

**デフォルトの名無しさん** · 2017/05/21(日) 01:27:28.98

>>597
図面的な意味で設計どうこうじゃなくて「なんかバグ出てるのはわかるんだけど
誰が調べても原因がわからん」系の状況じゃね？

継承四連打キメてて3段目で特定のタイミングのみ変数上書きワロスみたいな……

**デフォルトの名無しさん** · 2017/05/21(日) 04:39:36.10

>>597
無茶いうな

**デフォルトの名無しさん** · 2017/05/21(日) 10:57:27.44

>>600
597じゃないけどそういうのは設計が破綻していると言うと思う
図面の設計て意味じゃなくて作成者のプログラミング設計って意味で

**デフォルトの名無しさん** · 2017/05/21(日) 12:54:25.54

世の中のソースコードの90%の多段継承は既に破綻してる、もしくは今後するけどな
つまり仕組みが糞

**デフォルトの名無しさん** · 2017/05/21(日) 17:51:03.66

>>600
結局、オブジェクト指向ってただ作るだけなら得意なんだけど
正しく作っているか確認することは苦手なんだよね

そりゃあ設計はあるだろうし、設計通りに作られていれば問題ない。
でも設計通りに作られているのかの検証は、より困難になっている。

**デフォルトの名無しさん** · 2017/05/22(月) 12:24:20.53

なんか"経理部に領収書出して「清算お願いします」ってシステム"に
延々「経理部が不正やってないとも限らないよね！検証できないよね！」って
無根拠にただ喚いてる奴がいるみたいになってて相手のしようがないんだが、おまえ。

**デフォルトの名無しさん** · 2017/05/22(月) 12:36:09.78

>>605
アホ

**デフォルトの名無しさん** · 2017/05/22(月) 19:27:44.11

>>586
カプセル化が一番重要と思ってたんですが違うんですか?

**デフォルトの名無しさん** · 2017/05/22(月) 19:30:22.25

ソース付のライブラリ使えば？

**デフォルトの名無しさん** · 2017/05/22(月) 20:40:23.17

>>607
カプセル化が修正の閉鎖をもたらし
インターフェースが拡張の開放をもたらす
両方いる

**デフォルトの名無しさん** · 2017/05/22(月) 22:48:06.26

やっぱりどっちもいらない

**デフォルトの名無しさん** · 2017/05/24(水) 19:52:46.15

>>607
ゲッタセッタが生えてるプライベートフィールドはパブリックと変わらないってことだろう
要するにそれはカプセル化とは言わない
それやるぐらいならむしろパブリックの方がゲッタセッタの裏で余計なことしてない保証になる

**デフォルトの名無しさん** · 2017/05/24(水) 20:02:53.29

>>607
俺も重要だと思ってるけどその話題は荒れるので出さないようにしてる

**デフォルトの名無しさん** · 2017/05/24(水) 20:51:58.45

カプセル化の話だとデータの隠蔽のことばかりになってしまうのは残念じゃのう

**デフォルトの名無しさん** · 2017/05/24(水) 22:22:46.76

メソッドオーバーライドやインターフェース実装（具体例はJavaのinterface)も一応カプセル化の範疇だろうが
どっちかってと「継承」とか「クラス図」とか「デザパタ」の文脈で話す場合が多いかも

**デフォルトの名無しさん** · 2017/05/24(水) 23:27:44.78

>>614←こいつわかってなさそう

**デフォルトの名無しさん** · 2017/05/25(木) 00:11:42.62

詳細を隠し、結合度を弱め、変更に強くする、だっけか？
ただ、まあ面倒い

C#の新しいプロパティ構文がJavaでも使えればいいのにな

**デフォルトの名無しさん** · 2017/05/25(木) 07:20:20.62

哲学やると頭腐る

**デフォルトの名無しさん** · 2017/05/25(木) 07:29:05.76

最初から？

**デフォルトの名無しさん** · 2017/05/25(木) 14:20:37.34

>>611
データの整形はいずれにしても必要なわけで問題はどこで整形するか
クラス外で何カ所も整形の処理書くよりプロパティ内に書いた方がいいよね

**デフォルトの名無しさん** · 2017/05/25(木) 21:00:55.82

>>619
ゲッタセッタで公開されたプライベートフィールドと、書式化された文字列を返すプロパティって全然別物じゃんアホなの

**デフォルトの名無しさん** · 2017/05/25(木) 22:16:33.15

>>611
SetterGetterの殻に閉じこもってプログラミングする安心感は異常

そんな保障してなんの役に立つ
どのみちオブジェクトを関数の引数にしたら、どこで何されるかわかったもんじゃない

publicにしたら処理をフックすることもできない
へんな値が設定されたときに例外をだすこともできないし
Audio.volumeでボリューム設定なんてこともできないだろう

**デフォルトの名無しさん** · 2017/05/26(金) 12:49:01.87

セッタゲッタ作って役に立ったこともあるだろうが、無駄にコードが増えただけのこともあるだろう
無条件にやるのはただのバカ。フックいれることが予想される場合にするのはいい

**デフォルトの名無しさん** · 2017/05/26(金) 14:05:46.16

>>622
Yes

**デフォルトの名無しさん** · 2017/05/26(金) 15:13:04.21

そのクラスのユーザが自分だけじゃない場合は、とりあえず全部privateにして、getter/setter作っといた方がいいね

**デフォルトの名無しさん** · 2017/05/26(金) 16:21:29.95

getter,setterを通じて変数に触れるのであればそれはもはやprivateとは言えないと思ってる

**デフォルトの名無しさん** · 2017/05/26(金) 16:22:11.52

getterはまだ良いけどsetterは要らないなぁ

**デフォルトの名無しさん** · 2017/05/26(金) 16:37:50.24

>>625
> getter,setterを通じて変数に触れるのであればそれはもはやprivateとは言えないと思ってる
言いたいことはわからなくもないが、クライアントコードとそのクラスの接点がsetter/getterであると
保証されていれば、内部構造の変更は自由になるというのが異なる。

**デフォルトの名無しさん** · 2017/05/26(金) 18:31:35.52

確かにね
言ってることはよくわかる
だとしてもsetterは用途が限られるように感じてる

それならインスタンス生成時に必要な情報を全部ぶち込んじゃえばいいんじゃね？と最近考えてる

**デフォルトの名無しさん** · 2017/05/26(金) 19:19:04.64

class1
{
public int setInt;
public string setStr;
}

class2
{
public int setInt { set; get; }
public string setStr { set; get; }
}

この2つの違い教えて
外のクラスから参照・変更するだけなら同じ扱い？

**デフォルトの名無しさん** · 2017/05/27(土) 10:49:30.96

>>626
後でconfigの類を入れるとか、setLoggerだとかで
必要になる場面がたまにあるかも

なおPythonでそれやろうとしてプロパティデコレータ使おうとしたら「setだけのデコレータはない」というので
またPythonの俺様仕様か……って閉口した

**デフォルトの名無しさん** · 2017/05/27(土) 10:59:35.13

setterだけってことは

obj.x = 1 #=> これは出来る
obj.x #=> 例外

になって欲しいってことか？イラネ

**デフォルトの名無しさん** · 2017/05/27(土) 11:03:59.72

メンバを個別にセットゲットする需要ってそんなにないだろう？

**デフォルトの名無しさん** · 2017/05/27(土) 11:16:48.16

>>631
obj.config = user_config

みたいなのだ
setconfig(user_config)でもよろしかろうが、readwriteとreadは機能としてあるけどwriteはない
なんて片手落ちはあんまり想像してなかった
「正しいやり方はwriteイラね」とかマニュアルに書けってよ

**デフォルトの名無しさん** · 2017/05/27(土) 11:58:55.24

getter,setterはメソッドなのでクラス中で処理してクラスとして必要な形で出し入れできる
直接さわることとは別物だよ

**デフォルトの名無しさん** · 2017/05/27(土) 12:19:45.90

>>634
それはみんな分かってるんじゃないかな
>>583あたりからの流れで、全部のフィールドにゲットセット持たせることの是非を言ってるんだと思う。

フィールド（メンバ変数）が複数あったとして、ゲットセットする需要というか意味があるのは
ごく一部なんじゃないか。

**デフォルトの名無しさん** · 2017/05/27(土) 12:38:09.02

理想： getter/setterはメソッドとすべき
setterで引数のチェック、getterでoutはコレであってるかのチェックはもれなくやるべし

現実：やらなくてもだいたい例外が飛ぶか動かないかするからわかる

**デフォルトの名無しさん** · 2017/05/27(土) 12:45:31.51

ないとバカが騒ぐから作っておけばいい
こんなつまらん事でわざわざバカにエサを与える必要はない

**デフォルトの名無しさん** · 2017/05/27(土) 17:30:05.68

ゲッタセッタにフックさせる「かもしれない」をどう受け取るかによるから不毛と言えば不毛
柔軟に拡張できると受け取れば良しとなるし、不要な可能性を残すと受け取れば悪しとなる

個人的には単純にゲッタセッタで命名しといてくれるとインテリセンスでプロパティ探す時楽だからあった方がいい
ただゲッタセッタで命名しときながら裏で全然関係なかったり重い処理してる糞コード書く奴が一定数いるのも現実

**デフォルトの名無しさん** · 2017/05/27(土) 17:46:00.50

クラス設計が下手くそなオブジェクト指向初心者なんだけど、ためになる読み物とかないですかね？
cはある程度書ける

**デフォルトの名無しさん** · 2017/05/27(土) 19:33:03.59

構造化プログラミングって何？

**デフォルトの名無しさん** · 2017/05/27(土) 19:54:27.21

>>639
うまいやつに自分が作ったモデル添削してもらえ
一瞬で上級者になるぞ

本はしらん本よみまくったけど結局それだけだとだめだった

**デフォルトの名無しさん** · 2017/05/27(土) 20:24:02.87

>>640
ダイクストラ知らないとかゆとりかよ

**デフォルトの名無しさん** · 2017/05/27(土) 20:57:24.04

老害的罵倒例

**デフォルトの名無しさん** · 2017/05/27(土) 21:35:03.31

>>639
変な意見だけどHaskellを勉強する。
割とマジで。
互いに疎とか、モナドとか高階関数は依存関係解消のヒントになる。

**デフォルトの名無しさん** · 2017/05/29(月) 03:13:17.41

>>642
自分の言葉で説明して欲しいです。

**デフォルトの名無しさん** · 2017/05/29(月) 08:38:09.71

>>645
Wikipediaとか読んで自分でそれをできるようになったがいんじゃない？

**デフォルトの名無しさん** · 2017/05/29(月) 08:44:08.38

構造化プログラミングとは
関数、if、whileを使ってプログラムを書くこと

誤解を恐れず言うならswitch、forは邪道です

**デフォルトの名無しさん** · 2017/05/29(月) 11:07:58.25

はい次

**デフォルトの名無しさん** · 2017/05/29(月) 12:09:15.00

>>648
次はお前の番だよ

**デフォルトの名無しさん** · 2017/05/29(月) 12:10:47.18

おらあああ！！さっさと説明してみろや！

**デフォルトの名無しさん** · 2017/05/29(月) 12:11:45.18

>>647
wiki読んだけど、それぐらいの意図しか汲み取れなかった。

オブジェクト指向では、ポリモーフィズムとか使えるけど、それも結局はクラスでifしてるだけであって、たいして変わらないじゃんと思った。

**デフォルトの名無しさん** · 2017/05/29(月) 12:18:49.21

ポリモーフィズムとifが同等って初めて知った

**デフォルトの名無しさん** · 2017/05/29(月) 12:24:48.88

分かるだろ普通ｗ

**デフォルトの名無しさん** · 2017/05/29(月) 12:34:49.38

何を基準に普通と言ってるかは知らないけど同じ扱いをしても振る舞いが異なる事だと思ってたからなぁ

ここを見てるとどれだけ自分の頭が固いかよくわかっておもしろい

**デフォルトの名無しさん** · 2017/05/29(月) 19:29:07.89

一回、アセンブラからやらせて
自分で自分が書いたスパゲッティをメンテするところからやらせねぇと
なんで生まれてどんなメリットを目指したかわかんねぇんじゃねぇの
ゆとりには

**デフォルトの名無しさん** · 2017/05/29(月) 19:42:05.10

知らなくても組めるように発展してんだから意図なんか後から知ればいいんだよ

**デフォルトの名無しさん** · 2017/05/29(月) 20:16:08.98

いつまで経ってもオブジェクト指向の意図が理解できない変な人が湧き続けるスレで言うことか。

**デフォルトの名無しさん** · 2017/05/29(月) 22:18:26.47

オブジェクト指向の意図ってなんだよｗ
こんなものまで擬人化しないと気がすまんのかお前らｗ
キモいにも程があるｗｗｗ

**デフォルトの名無しさん** · 2017/05/29(月) 22:22:54.39

オッ

**デフォルトの名無しさん** · 2017/05/29(月) 22:25:41.12

ここまで国語力ない奴はじめてみた。

**デフォルトの名無しさん** · 2017/05/30(火) 02:01:38.87

>>652
同等じゃないよ

ポリモーフィズムはそもそも参照先が違う
演算によって処理を分けるif文とは全く違う

**デフォルトの名無しさん** · 2017/05/30(火) 02:16:15.25

>>651
呼び出す側が適宜、相手のインスタンスに「こういう動作して」って派生クラスぶっこむ場合が多いな
まぁ派生元 - 派生先でifしてるって捉え方もできようが
if - elseが下に7コ8コ並んで見難いのよりはマシだろう

**デフォルトの名無しさん** · 2017/05/30(火) 19:10:33.85

>>658
Objectの言葉の意味の通りじゃん

**デフォルトの名無しさん** · 2017/05/31(水) 17:32:41.97

オブジェクト指向開発の理解度を測るために民間団体の主催するJAVA検定を受けようと思うのですが、そもそもここの問題はオブジェクト指向となっているでしょうか

http://www.sikaku.gr.jp/js/jv/img/sample/1/jv1.pdf

過去に構造化プログラムとかクソ味噌言われていたので、オブジェクト指向に造詣の深い皆さんに評価して頂きたいです

**デフォルトの名無しさん** · 2017/05/31(水) 18:37:16.96

>>664
やめとけ

**デフォルトの名無しさん** · 2017/05/31(水) 18:46:16.77

理解度測るならフリーで仕事すればいい
稼いだ金額が理解度

**デフォルトの名無しさん** · 2017/06/01(木) 03:12:10.50

>>664
実務でやるなら、4番のシーケンス図よろしく「N」なんて打ち込ませねぇ
そもそもあんなクソみたいな手数を踏ませるはイカれてるっていうか、ユーザーは怠惰なんス
一手で済ます
たぶんログイン画面でセッション（あるいは何らかの認証情報）を持たすのが前提だあな

っていうか「Fuckyou」とか「let me die」って打ち込んだ時どうすんだね
この図だと未定義だから何してもいいよね、俺だったら「Fuckyou」ってタイプされたら水龍敬ランド出すし
「let me die」ってタイプされたらガルパンのまほお姉さまのエロ同人誌でも表示してやるわさ
……冗談やで？

というくらいなんかアレかも

**デフォルトの名無しさん** · 2017/06/01(木) 03:35:10.17

そしてまさかのNはユーザーの氏名でした、か（今アレって思って見直したら）　orz　ごめん手抜きした
まあいいや、見直すとして……ああうんお呼びでないか

シーケンス図を（マジメに）見る限り

・初めに二回ポップアップ出す（or二発画面遷移をせよってこと、メソッドが二発あるので）
・ユーザーがNっていれたら、初めに出たのとの同じポップアップを2発やる（displayFirstMess/displayPromptMessをもう一度ぶっぱしてるから）
・imputMessageでユーザーが入力をいれたら
　まずユーザー一覧を表示するのか、「検索方法を指定してください」と出すのかして（displayFirstMessはどうもでっかく二分岐してるのかもしれん、あるいはまた「検索方法を指定してください。」と出すのか）
　そのあとでallDisplayでドカっと下に長い表示を出すのか
　この辺要確認、たぶん書き手はそんなの想像してないと思う
　たぶんGoogle検索のようなのを想定してるはずなので
・ユーザーは表示された従業員名とID突き合わせて入力欄にID打ち込んでEってタイプする
　ここも確認が必要、クリックじゃねぇの？

ああうんこれメインフレーム時代のやり方やで

**デフォルトの名無しさん** · 2017/06/01(木) 03:36:55.80

あーうん、let me dieって言われたらまほ姉がおっさんにピーされる機能は実装が必要だな
俺以外望んでないけど未定義だからいいよね（実務じゃしないよ、冗談だから）

**デフォルトの名無しさん** · 2017/06/02(金) 01:49:27.48

今Haskellとの比較にPython/Rubyに追加で究極的なオブジェクト指向言語であるsmalltalkでコマンド作るべくgnu-smalltalk勉強中なんだが、条件分岐やループまでオブジェクトへのメッセージなんで、
squeak/PharoみたいなGUIなsmalltalkじゃない事でシステムブラウザ(動的クラスリファレンス？)無しじゃ相当厳しい。

Ubuntu Linuxでsudo apt install gnu-smalltalkしただけじゃgst-browser起動しなかったから、
tar玉落としてコンパイル段階から環境構築してやっと動いた。

んで思ったんだが、やっぱオブジェクト指向ってクラス覚えないと何も出来ないんじゃね？
中途半端なオブジェクト指向言語って構造化プログラミングの文法に助けられてて、
その辺誤魔化せてるだけのような気がして来た。

**デフォルトの名無しさん** · 2017/06/02(金) 07:47:26.08

>>670
システムブラウザまで使うならなぜGNU Smalltalkみたいな変わり種Smalltalkにこだわるのかわからんけど（何かPharoやSqueakじゃ駄目な事情が？）
クラス（というか組み込みのオブジェクト）の使い方を覚えないと何も出来ないというのはかなり正しい

ただそんなこともあってSmalltalk環境は相当早い段階から組み込みの（クラスを含む）オブジェクトに対する問い合わせ
つまりイントロスペクション機能やそれをサポートする（人間の短期記憶に負担をかけないようにする）
マルチウインドウシステムが発達したわけ

だから、繰り返すけどそれらの機構を大胆に削ったのウリのGNU Smalltalkで
「Smalltalk（やそれが体現するOO）が何か」を論ずるのはちょっと違うかもと老婆心ながら

**デフォルトの名無しさん** · 2017/06/02(金) 07:58:55.45

Smalltalkがウンコなだけだよ
アランケイにも捨てられたゴミ

**デフォルトの名無しさん** · 2017/06/02(金) 08:32:54.40

>>671
> 何かPharoやSqueakじゃ駄目な事情が？

すみません。ちゃんと理由が書いてありましたね。^^;
>>670
> コマンド作るべく

ただ最終的にGNU Smalltalkを使うにしても、まずはSqueakやPharoから入るのがいいかとは思います

>672
> アランケイにも捨てられたゴミ

アラン・ケイが Smalltalk を見捨てた発言をするのは宮崎駿の引退宣言みたいなもので
最初は1976年ごろからはじまって、10年ぶり5度目とかの恒例です

**デフォルトの名無しさん** · 2017/06/02(金) 09:09:40.41

ほい(おそらくガセ)

http://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html

**デフォルトの名無しさん** · 2017/06/02(金) 09:10:16.04

SmalltalkはIDEがなきゃCよりも書きにくく、
IDEを使うためにはヘンテコなOSモドキの使用を強制され、
それを我慢して使っても他の言語より書きやすいわけでもなく
マイナー言語なのでライブラリも少ない

まさにゴミ

**デフォルトの名無しさん** · 2017/06/02(金) 09:36:01.61

>>675

まあそう言わんと

ただヘンテコなゴミだと簡単に切り捨てるより、いろいろ調べて学びを得た方が面白いですよ

同時期に登場したStar、Cedar、Interlisp-D等、同様のOSモドキはいくつか生み出されましたが、
結局生き残って今も使われ続けているのはSmalltalkだけです

たまたま選ばれたということ（ジョブズやゲイツがそのルック＆フィールを模倣して広めてくれたということも含め）
もあるかもしれませんが、ホストOSに寄生する“異物”という宿命を背負いながらも変化を続け
趣味はあってもスタートアップで言語として選択される程度に有用であることは
ケイらの遅延結合性の徹底というコンセプトの有効性を示すよい例かとも

Smalltalkの底を流れる設計思想 - ダン・インガルス
http://web.archive.org/web/20041016084842/http://marimpod.homeip.net/chomswiki/24#

「ソフトウェア工学」は矛盾語法か？ - アラン・ケイ
http://metatoys.org/oxymoron/oxymoron.html

**デフォルトの名無しさん** · 2017/06/02(金) 10:52:54.67

>>673
いあ、昔squeakやってたし、当時はクラスブラウザと自由自在Squeakあれば十分なくらい独学しやすい言語だと思ってた。
当時はJavaのクラスリファレンス(とら本)も分厚いのを上下巻2冊で売ってたし、クラスたくさん覚えて行くのが当たり前と思ってたからね。

HaskellもLispも、関数覚えておけば便利だけど、覚えてない知らない場合も自分で自作しやすい。
そう言う意味じゃCとかの構造化プログラミングも関数やクラスを基本にするんじゃなくて、Goto使わなくて済む構文によってスパゲティコードを無くすっていう自作し易さを目指す進化だったんよね。

**デフォルトの名無しさん** · 2017/06/02(金) 11:34:30.40

何というか、オブジェクト指向って出来合いの機能をたくさん用意する事で自作する機会を減らす方向の進化で、自作のし易さを加速させる、根源的な生産性を上げる進化じゃ無い気がして来たのよな。

**デフォルトの名無しさん** · 2017/06/02(金) 11:53:23.75

>>677
Squeakは経験済みでしたかそれは失礼いたしました

ただSqueak等でちょっと調べてみれば分かりますが、他の言語やそのIDEのやり方とは違いSmalltalk環境のGUIツールは基本
クラスを含むオブジェクトの持つイントロスペクション機能にちょっとしたGUIのガワをかぶせただけシンプルなしくみで動いています
それはつまりGNU Smalltalkでも、Squeak等が“GUIのガワ”が中でやっていることを式で書いてやればそれなりのことは事足りるということです

たとえば Integer >> #factorial というメソッドのソースが読みたければそれに methodSourceString というメッセージを送る
(Integer >> #factorial) methodSourceString
といった調子で、そしてこれがSmalltalkのシステムブラウザがやっていることのほぼ全てです

じゃあ、factorial や Integer はともかく、>> だの methodSourceString だのはどうやって分かるかというと
もちろん GNU Smalltalk のリファレンスをググるのも手ではありますが
#>> implementors で実装クラスを一覧したり、
#>> implementors anyOne methodSourceString で定義を見たりするのがSmalltalkでのやり方になります

覚えておくよりはその都度オブジェクトたちに尋ねるという彼らとの対話の妙をぜひお試しあれかし

**デフォルトの名無しさん** · 2017/06/02(金) 12:43:16.45

>>678
> オブジェクト指向って出来合いの機能をたくさん用意する事で自作する機会を減らす方向の進化

出来合いの（組み込みの）機能といっても、元は自作なんですよ（少なくともSmalltalkにおいては）
それらを簡単に実装できるという精神はHaskell、ひいてはFPに通じるところはあると思いますよ

それにHaskellにしてもパターンマッチや型クラスを含む型システムなどの便利な組み込みの機能の助けなしに、あるいは
リストなどのモナドの拡充なしに自作のしやすさの加速ができるわけでもないような気がしますが…違いますかね

**デフォルトの名無しさん** · 2017/06/02(金) 12:44:30.15

>>677
オブジェクト指向は、複雑さ、巨大さとどう戦うかというのが進化の方向
HaskellやLispでデカくて複雑なプログラム書いてみたら、オブジェクト指向にも有用な部分があることを理解できるんじゃない？
ちょっとしたコードの書きやすさだけで言語の良し悪しは決まらないよ

**デフォルトの名無しさん** · 2017/06/02(金) 13:19:41.98

Objective-Cにも動的にクラスに「おまえなにできるの？」って聞くメッセージあるし
基本的にあの辺りはインターネットみたいな動作しっぱなしの世界で
クラスってノードを動作中に抜き差しするみたいな感覚を指向してるからなぁ。

**デフォルトの名無しさん** · 2017/06/02(金) 13:25:35.15

インタフェース以外の継承はすべて糞

**デフォルトの名無しさん** · 2017/06/02(金) 13:27:17.37

>>679
その都度オブジェクトたちに尋ねるのが、まさにsmalltalkがオブジェクト指向の最たるものの所以で、当時も今もそこについては変わらないんですけどね。
さすがにgnu-smalltalkでは一覧性に難ありな所が＾＾；

逆です。
その便利な機能のみで、入出力とかはともかく、自分がこう動いて欲しいと望む機能を実現できる。
そこに関してsmalltalkとFPに通じる所があるのも同意します。
ただあれはsmalltalkであってsmalltalkじゃ無いというか。。。

smalltalkって制御構造もメッセージで実現してるけど、Haskellと同じで構造化プログラミングを模倣してるだけで、やや普通のオブジェクト指向言語より構造化プログラミングから逸脱してる気もしますし、確かに生産性は高いんですけど。

ただ、既存の関数やメソッドを一切使わず新しい機能を実現する手間は、その基本的な便利機能の充実度から、Haskellのが生産性は高いかと。
探すより作った方が早い場面もありますし。
(いあ、smalltalkは探すスピード上げる方向の進化と考えれば、作った方が早いって場面も少ないんでしょうが)

**デフォルトの名無しさん** · 2017/06/02(金) 13:33:45.72

>>681
昔はGUI部分も同じ言語で書いてたからオブジェクト指向が有用だったですが、今はGUI部分はHTMLなりXAMLで書くことも増えて来ましたし、複雑な部分はDSLに任せて分担作業が、複雑巨大なプログラムに対する解の様に思います。

**デフォルトの名無しさん** · 2017/06/02(金) 13:46:34.00

遅延結合って、実行時に型を調べて処理を分岐してるだけでしょ？

**デフォルトの名無しさん** · 2017/06/02(金) 13:57:11.97

>>684
> さすがにgnu-smalltalkでは一覧性に難ありな所が＾＾；
> ただあれはsmalltalkであってsmalltalkじゃ無いというか。。。

具体的にはどういったところがでしょうか？　後学のため教えていたければ幸いです

> smalltalkは探すスピード上げる方向の進化と考えれば、作った方が早いって場面も少ないんでしょうが

SmalltalkがOSモドキと忌み嫌われつつもイメージベースで居続けるのはこの利便性を捨てないためです
ユーザー定義のものも組み込みのものも区別せずにオブジェクトストアに保持し、OODBのように探せます

**デフォルトの名無しさん** · 2017/06/02(金) 14:05:56.39

>>686
実行時についてはそうなのですが、それを設計や運用時にも徹底する（それをサポートできるシステムであること）がミソです
決定をできるだけ先送りにして固定化しない、ぎりぎり直前でも（場合によっては事後でも）差し替え可能に保ちます
基本的な考え方はこちらに書かれていますのでよかったら読んでみてください

「ソフトウェア工学」は矛盾語法か？ - アラン・ケイ
http://metatoys.org/oxymoron/oxymoron.html

アラン・ケイもよく言っていますが、これができるのはおそらくLISPとSmalltalkくらいかと

**デフォルトの名無しさん** · 2017/06/02(金) 15:12:57.10

>>687
あれ。
Squeakの時に低レベルのもの書く時って、それ用のsmalltalk無かったでしたっけ？
名前忘れたけど。。。

gnu-smalltalkみたいなのが主流にならないと、結局OSモドキに引き篭もって外とやり取りなんですよね。。。
例えば鯖のログを必要な箇所だけ見れる様に加工したいって時でシェルやLLが使われますが、smalltalkはその代替えにならない。
その為だけにOSモドキを立ち上げる手間が壁になる。

まあ、それはHaskellも微妙な立場なんですが、シェル知らなくても、各種LL(HaskellはLLじゃ無いけど関数知らなくてもって意味でHaskell自身の関数も含む)の関数やクラス知らなくても、Haskellなら、自分の発想でこういう加工したいってすぐに自作出来ます。
ただ、コンパイルが遅いので、LLとどっちが便利かが微妙になるだけで。。。

smalltalkはOSモドキと一体の生産性ですが、現実問題、言語は問題解決の手段であって、手段を使用する事自体に手間が掛かってしまっては元も子もないと考えます。

。。。Haskellもその点で微妙ですけどね。
(runghcでLLとして実行しても型検査はするから起動がLLより遅い)

Haskellのパターンマッチや遅延評価やモナドは作り手の知識が少なくても「作りやすい」仕組みだと感じます。
一方のsmalltalkは知識が少なくても「探しやすい」仕組み。
そう感じました。

LLはどっちも80点だけど、総合点で上回る的な。
でも規模が大きくなると型付言語が欲しくなる。。。

**デフォルトの名無しさん** · 2017/06/02(金) 17:01:43.90

>>689
> シェル知らなくても、各種LL(HaskellはLLじゃ無いけど関数知らなくてもって意味でHaskell自身の関数も含む)の関数やクラス知らなくても、
> Haskellなら、自分の発想でこういう加工したいってすぐに自作出来ます。

つまりHaskellでは組み込みの関数をいっさい知らなくとも（使わなくても）ログの整形作業が自作できるのですか？
それは驚きですね（反語的に）

**デフォルトの名無しさん** · 2017/06/02(金) 17:24:22.28

出来ますね。
結局ライブラリ使った方が早いんですが、学習しながら作ると言う意味では即戦力です。

だからなんだと言われればそれまでですが、GUIとかのライブラリがポトペタで作れたりしないので開発環境としてはまだまだですが、言語としての学習コストは低いと思ってます。

**デフォルトの名無しさん** · 2017/06/02(金) 17:35:52.70

>>691
そんなことが可能な言語がこの世に存在するとはにわかには信じられません
実際に動作するコードを見せてもらうことは出来ますか？