オブジェクト指向システムの設計 174 [無断転載禁止]©2ch.net
レス数が1000を超えています。これ以上書き込みはできません。
ドックフード
意味の説明もさることながら、どこの業界の用語か知りたい >>912
作る人がいることの証明にはなってるが
使う人がいることの証明になってないよ
誰も使って無くても、更新し続けることはできるんだから たとえばMatzはRubyをほとんど使わないけどRubyに変更を加え続けていたしそれは容易だ
Rubyに限らず通常の言語の場合たとえ使う人がゼロでもリリースし続けることは理論的に可能
しかしSmalltalkの場合、Smalltalkを使わずにそれに変化を加えることはできないんだよ >Smalltalkの場合、Smalltalkを使わずにそれに変化を加えることはできない
それが正しいとしても
Smalltalk処理系の開発者はその処理系を使い続けている
ってことになるだけで
Smalltalk処理系の開発者以外の人がその処理系を使い続けている
かどうかは分からないよな RubyにできてSmalltlkにできないはずがない >>922
他の言語では 処理系開発者＝利用者 には必ずしもならないが
Smalltalkではその特殊性から 処理系開発者＝利用者 がほぼ成り立つ
したがって、Smalltalkは更新されリリースされていれば利用者は必ずいる
上にもあるがこれだけだよ君はいったい何と戦っていて何を証明したいんだ？
「利用者」の定義をしぼればいつかはSmalltalkの利用者はゼロにできるけど
それだと「俺ほどの人間のアンテナにひっかからないSmalltalkは死滅しているも同然」という情弱識者とたいしてかわらんぞ
もし本当にSmalltalkが実務等で使われているか知りたければ sorabito "smalltalk" とかでググるか
http://pharo.org/success/ にアクセスして事例を精査してみればいいと思うけど
実際のところSmalltalkがどうあろうが端から興味なんてないんだろ？ >>911
プロトタイプベースでもコンストラクタ定義すればいいだけだよな Pharoを使っているのはPharoを開発している人たちだけってことか
https://pharo.org/ >>926
たぶん>>924 の ＝ の誤りの指摘だと思うんで念のためお詫びと訂正しておくと、
これは「〜ならば」の間違いなので申し訳ないけど適宜読み替えてほしい
Smalltalkであっても利用者 ＝ 処理系開発者 の関係は必ずしも成り立たない
ついSmalltalkのメッセージ式っぽく考えて交換法則を忘れてしまった^^;
まあ屁理屈をこねればSmalltalkにおける開発とはすなわち言語や環境の拡張に他ならないので
利用者はすべて処理系開発者だとも言えなくもないけどそれはさすがに言い過ぎだろうしここで主張したいことではない Smalltalkは
海外だと事例けっこうあるんだけどね
日本だとあんまり使われてない xがSmalltalk処理系の開発者ならばxはそのSmalltalk処理系の利用者である
というのが正しいとしても、処理系開発者以外に利用者がいるとは言えない
>>908や>>920が言ってるのも「処理系開発者以外の利用者」についてだと思う Objective-Cに吸い取られ、吸い取ったObjective-Cも死にかかっている悲劇の言語 >>929
こだわるね^^;
では処理系開発者をその言語の利用者にカウントしてはいけない合理的な理由を述べてよ 処理系開発者をユーザーにカウントしてもいいなら多分Dもユーザーおるな >>931
>処理系開発者をその言語の利用者にカウントしてはいけない
誰もそんなことは言っていないわけだが
利用者が処理系の開発者だけの状況を、その言語は現役とか
その言語は普及しているとか言わないだろ
>>908や>>920が言ってるのもたぶんそういうこと >>933
まず君の思う「現役」の定義を明確にしてよ
これまで誰も主張していない「普及」をいきなり持ち出してきたけど、それが答え？
もし一定のシェアをとっていない言語を「現役」と言ってはいけないって法があるなら
今のSmalltalkは誰が見ても明らかに違うだろうこれで満足？
ただシェアこそないがコミュニティはかつてないほど活発だしまして「死滅」からほど遠いのも事実
これをもって「今でも現役」と表現することも決して間違いではないと思うが違うのか？
そもそも>>900の「現役」は>>899を受けての「死滅」なぞしていないという意味でしかない
その文脈を読めてない>>901が自分の考える「現役」と違うってだけの単純な話を
なにをそんなにこだわって執拗につっかかり続けるのかわからん
Smalltalkが今も「現役」を名乗ると個人的になにか不都合でもあるの？ Objective-CがiOS絡みで再び出てきた時に自分が理解できず
「変態言語！変態言語！！」ってほざいてた頭ゆるいアンチApple老人が
いやあれはねとsmalltalkerが擁護するの見て
『ならsmalltalkも俺の敵だ！』ってやってるだけだからw >>934
912>更新（変化）し提供され続けていることは少なからぬ人に使われている証拠として十分だ
とか言い出すからおかしくなる
処理系が更新されてるから少なからぬ人に使われているのは間違いない、だから現役だって主張だろ
「少なからぬ人に使われている証拠」とかいうのがあるなら最初からそれを出せばいい
処理系が更新されているからと言って現役ということにはならないのだから >>936
なるほど「少なからぬ」を文字通り「普及」や相応のシェアを持っているという主張だと短絡して反発したわけね
これもやはり 「死滅」＝利用者ゼロあるいは数名 に対し「そんな少なくはない」という程度の意味だと思うけど
では何人くらいが使っていれば「現役」を名乗っていいわけ？とにかくそれを明確にしてよ >>937
知らん
俺が言いたいのは
処理系が更新されているからと言って「少なからぬ人に使われている」ことにはならない
「少なからぬ人に使われている証拠」とかいうのがあるなら最初からそれを出せばいい
ってだけだし、>>908や>>920が言ってるのもたぶんそういうこと ってか利用者ゼロもしくは数名じゃないなら現役なんだったら、やっぱりDは現役じゃん >>938
改めて訊くけど処理系開発側になったらもう利用者としてカウントされなくなるのはなぜ？
利用者が処理系の気にくわない部分に手を加えてそれが採用されるパターンとかよくあると思うんだけど
それともその程度なら開発側とは考えなくても良いの？その場合の線引きは？ >>941
なぜたったこれだけのことを理解できないのだろう
>処理系が更新されているからと言って「少なからぬ人に使われている」ことにはならない
>「少なからぬ人に使われている証拠」とかいうのがあるなら最初からそれを出せばいい Smalltalk や Pharo をGoogleトレンドで調べてみると、Windows 95の 1/3 でWindows 3.1 やD languageと同等くらい
（なお、言語だけじゃなくOSと比較したのはSmalltalkは環境であるってのに敬意を評して）
https://trends.google.co.jp/trends/explore?q=Smalltalk,Windows%2095,Windows%203.1,Pharo,D%20Language
Smalltalk、もしかしたらWindows 3.1と同じくらいのユーザ数に使われてるかも知れんね。凄いね！ 「売れてるアニメが勝ちなんだから売れてる証拠をおまえが出せよな！」
(相手にされない)
「ほらDVDの円盤の販売数を調べたぞ！ほっら売れてないからおまえの負け〜俺の勝ちー！」
(一同失笑) 脈絡なくアニメで例え出すのも意味不明でキメェし、
別のSmalltalkerがそれに普通に乗っかるのもキメェ >>941
> 改めて訊くけど処理系開発側になったらもう利用者としてカウントされなくなるのはなぜ？
「処理系開発側になったらもう利用者としてカウントされなくなる」とは言っていない
話の順番が逆で
先にお前が「処理系開発側を利用者としてカウントする」などと
おかしなことを言ったから、お前の間違い指摘しただけ
ここでお前が言ったことを改めて言い直してみようか？
「利用者数がわからないので、処理系開発者を利用者に含めていいですか？」
良いというわけがなかろう？ Smalltalk = Windows 3.1
www メーリングリストの投稿者数（重複除く）から見積もると
Pharo Smalltalkの利用者は数千人くらいはいる
Haskellのだいたい半分くらい 少し前のデータだけどHaskellもSmalltalkもさして利用者数に増減はないとして参考にすると
Smalltalk利用者の規模はHaskellのおおよそ半分というのは別の解析でも同じ
http://www.dataists.com/2010/12/ranking-the-popularity-of-programming-langauges/ それ人気が低い順にランキングで並べて表示してるだけで、利用者数の絶対値じゃないよ
Smalltalkは約20位でHaskellが約40位だけど、これはSmalltalkとHaskellの間に他の言語が20個あるという意味でしかない
そのリンクの下方にrawdataがあるけど（http://www.dataists.com/wp-content/uploads/2010/12/language_ranks1.csv）、
この中で絶対値はtagcountだけで、それだとsmalltalkが189に対しHaskellが1896で10倍の差がある 複数のプログラミング言語を使いこなしてる奴なんて世界でも僅かだろ。
比較する資格すら持たない連中がシェアなるもので一喜一憂するのは何で？ GitHubのリポジトリーで直近１ヶ月の開発者の数を比べてみると
こちらもくしくもてGlasgow Haskell Compilerの36名に対しPharo Smalltalkの16名と約半分だった
https://github.com/ghc/ghc/pulse/monthly
https://github.com/pharo-project/pharo/pulse/monthly >>924
"sorabito smalltalk" でググったら、
ベンチャーで最初にいたエンジニアがsmalltalkerでsmalltalkを採用したとか、
そのエンジニア（元CTO）は去年12月に辞めたとか、
いまの採用ページにはsmalltalkに一言も触れてないとか、
色々あったんだろうなって想像できて面白かったわ。ありがとうw Smalltalk = Windows 3.1 = D オブジェクト指向言語でメンバ変数やメソッドをpublicにすべきかprivateにすべきかは
長年議論されてきてることだけど、中には
「privateで変数やメソッドを宣言するくらいならその部分をクラスにまとめて外に追い出してしまえばいい」
「洗練されたプログラムは変数・メソッドともにpublicだけで十分」
という意見もあるんだけどこれってどう思う？ > 「洗練されたプログラムは変数・メソッドともにpublicだけで十分」
洗練されて無くてもpublicだけで十分といえるので
「洗練されたプログラムである」という判断が別に必要になる プロパティがあるならとりあえずpublicにしといたらいいんじゃない？ publicもprivateも両方とも有るのが良いよ
選択肢が無くなったり少なくなったりすると利用し難くなる事も有るし
使う人のレベルや理解度もまちまちなんだから
staticだらけでやる人がいても構わないし
どちらか一方になって片方が使えなくなる方がやだな
洗練されているかどうかは悦に浸っている人が勝手に浸かっていればいいし SmalltalkはTcl/Tk未満のゴミってことか…
オブジェクト指向の面汚しだな。死滅してくれて良かった 世のプログラム言語のほとんどがALGOL系といわれているがALGOLを使った事ない人がほとんどなのと同じじゃね？ ちなみにSmalltalkが目指した遅延結合重視のメッセージングのオブジェクト指向は
C++で再定義され現在主流の抽象データ型のオブジェクト指向とはほぼ別物だから
アンチSmalltalkが「オブジェクト指向の面汚し」とか言ってもいまいち響かないよ >>969
言語はもちろん、コンセプトも主流から外れちゃったって>>.970は言ってるよ
もう完全消滅だね そうなんだよすっかり主流から外れて久しいのにいまだにオブジェクト指向というと
メッセージを送るのがどうとか遅延結合がどうとか説明し出す自称識者が多くて困るよ
ほんと聞き手が混乱するだけだからやめてほしい
Smalltalkくらい遅延結合性を実践していればわからんでもないけどあれすら肝心のメッセージは非同期じゃないし >>972
Erlangのメッセージが本物
Smalltalkのは偽物 ゲイツもMSもGUIの模倣でこそジョブズやAppleに遅れをとったけどその後はSmalltalkから学んでいる
アラン・ケイも .NET のことは Java よりはマシと言ってた
http://tech.nikkeibp.co.jp/it/members/ITPro/ITARTICLE/20030605/1/
ジョブズも表層のGUIだけパクって終わりにしたLisa/Macを反省してNeXTSTEPを作らせたけどね
http://web.archive.org/web/20121016134054/http://americanhistory.si.edu/collections/comphist/sj1.html#soft >>974
メッセージに関してはそうだろうね
ケイもAltoにもっとパワーがあったらErlangみたいなのを試したかったって言ってたし
ただシステム全体としての動的性に関してはErlangやそれで作られたものとは比較にならない 「クラスにメソッド送るシステムなんていまじゃ壊滅してる！
21世紀の現代の主流はC ++！」って5ちゃんねるで喚いてる人とか
そりゃ誰も相手したくねぇよw メッセージングのパラダイムを持ち出しておいて
メソッドとメッセージの区別すらついていない人がよくいるけどここにもいたかｗ
あと現在主流なのはクラスやそれに準ずるエンティティで抽象データ型を実現することで
その出自がC++というだけだよその程度の区別もつかないのか
たった２行の煽りでここまで致命的に間違えられるとかどんな才能だよ… はいはい、「俺の宗教の教義では俺の信じてるものは俺の神から、
俺の信じていないものは敵の神からもたらされたと決まっているから。」
いただきましたw >>979
まあまあ、しょせんSmalltalkのメッセージはニセモノの出来損ないなんだから
細かいことに目くじらたてるもんじゃ無いよ ほんとにメソッドとメッセージの区別がついていないらしい… Erlangという本物を持ち出されてSmalltalkerサンぐうの音も出ないらしい Erlangはオブジェクト指向というよりメッセージ指向 メソッドとニセモノのメッセージと本物のメッセージの3パターンで説明お願いね メッセージはオブジェクトに送られる情報（多くの場合はエンティティ）
Smalltalk-72ではトークン列
Erlangなどではデータ列
Smalltalk-76以降はセレクター（多くは呼び出しが期待されるメソッド名）＋引数（オブジェクト）
奇妙だけど他の言語でもSmalltalk-76以降に準じた解釈（メソッド名＋引数）をそう称する場合が多い
一部の宗派でセレクター（メソッド名）のみをメッセージと称する場合もある（Objective-Cでよく見られる〕
メソッドはオブジェクトがメッセージを受けて行う操作
Smalltalk-72ではメッセージにパターンマッチする記述（リーダーマクロのようなもの）
Erlangには無いが、強いて当てはめればメッセージを受けたときの処理部分
Smalltalk-76以降ではクラスに属する関数がそれに当たる
もともと「メソッド」はメッセージを受け取った際に目指す状態である「ゴール」を記述する場とする予定だったが
Smalltalk-76でSimula-67スタイルのクラスとそれに内包される関数を用いる機構を採用したため
クラスに内包される関数とメソッドとの間に明確な差はなくなった
とか、とりあえずこんな感じで つまり、本当に非同期にメッセージパッシングしてるErlangは特別だけど、
Smalltalkのメッセージはメソッドコールと変わんないってことですね メッセージがエンティティであることが重要で同期か非同期かは後付けでなんとかなる問題
たとえばIoなんかはそうなっているし、Concurrent Smalltalkという方向性もある
メソッドコールについてはさすがに静的に決定しているそれをメッセージと呼ぶのは滑稽だろう
動的メソッドコールについても例えば期待するメソッドが存在しない等で失敗したときに
メッセージを第一級オブジェクトとして参照可能な機構が組み込まれていないなどサポートを欠いていれば
その言語での動的コールをメッセージと称することはちょっと無理があるような 同期を非同期に変えるのに比べたら、静的なのを動的に変える方が簡単だし、後付けでどうとでなる問題だよ いずれにせよメッセージと称したい情報を必要なときにエンティティとして扱えるしくみがあればどうとでもできるよ メッセージがメソッドコールだとしても、基底クラスに共通メソッドとして実装されているならそれはメッセージで間違いないだろ。 メソッドコールと違いメッセージというからには送り手はその都合で情報を勝手に送りつけるわけだから
それを受け手がどう処理するかについて関知しないスタンスがとれなければさすがにダメだろう そんなん待ち行列になってんじゃね？
つか、メッセージの実装って、結局メソッドコールなOSばかりだしな。 Smalltalkのメッセージを全部非同期にしたら、信じられないくらい遅くなるかブッ壊れると思うよ
だからSmalltalkはメッセージの受け手が即座に処理してくれる事を期待してるし、何も関知してないなんてウソだよ Smalltalkじゃなくても全部非同期なんかにしたら遅くなるか破綻するだろう 「関知しない」は「どう処理するか」で「いつ処理するか」だけに限らない
SmalltalkでいえばdoesNotUnderstand:（Rubyならmethod_missing）相当の機構と
その際処理したいメッセージをエンティティとして扱える機構がないといろいろ厳しかろうという話 このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 199日 5時間 25分 16秒 レス数が1000を超えています。これ以上書き込みはできません。
