アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
今時の若いもの(藁)の意見 (スコア:1)
「OO言語を使うの必須だ」とは言ってません。
#俺もまたDQNかどうかは、さておくとして。
べつにLispでもいいんじゃないですか?
OOPというよりもどちらかというと、参照ベースの変数とか、GCとか、そっちのほうが
(気楽にプログラミングできるような高級な言語の)基礎としては大事な事柄で、
それこそCLOSみたいに、それらの仕組み(だけ)を駆使してライブラリレベルでOO言語風に仕立ててもいいんだし。
問題はshだとそれ「すら」旨くできない、という点だと思います。
OO「も」出来ない(やりにくい)。
そしてそれは、それ以外の色々なことも出来ない(やりに
パイプについての考え方 (スコア:1)
「結局どうやってこの分野に改革を起こすのか」というのがある。
つまり、
「ロードマップはできたけど、どうやって実装しよう」
「実装は終わったけど、どうやってみんなに使ってもらおう」
というところがある。
この問題に対するアプローチのやり方はいくつかあると思うけど、
趣味のプログラミングとしては、「現状+α+α+α+…」
といった感じで、ちっちゃい変更をどんどん加えていく方向でしか
実現はありえない、と思ってる。
そういった意味で、G7 さんの意見はしきいが高く感じちゃうなぁ。
で、そういった意味からすると r
# mishimaは本田透先生を熱烈に応援しています
Re:パイプについての考え方 (スコア:1)
> といった感じで、ちっちゃい変更をどんどん加えていく方向でしか
> 実現はありえない、と思ってる。
それってメインストリームの変更方法じゃないですか?
言ってみればC言語的な。
わたしは、むしろ趣味だからこそ全く違うものをいきなり持ってこれるのだと思います。
具体的な手法は、その言語・環境で動くキラーアプリを作るって、オープンソースで配布する。
バイナリは自分好みの設定をデフォルトにして配布する。
そうすると、その設定が気に入らない人が出てくる。
ここで、じゃあソースからいじっちゃえ、という人が出てくれば言語が広まるはず・・・と。
Re:パイプについての考え方 (スコア:1)
> 小脳に覚えさせられます。つまり無意識にやれちゃう。
あぁ、だから時々「j」とか「l」がたくさん画面に出てくるんですね(笑
> 憂鬱本の言い回しを借用するならば、
経験則だったのですが、憂鬱本でも取り上げられているのですね、
うぅ、今度読んでおかないと・・・。
> 俺はOOPで、「能動者の逆転」というパラダイムシフトがあったようには思います。
それはわたしのレベルでもOOPなものに触れていると感じるのですが、
最近ちょっと疑問を感じるようになってきました。
よく、input.clicked();なんてものがありますが、
“input was clicked.”を「inputがclickされた」と読み替えて、
click(input);
としたとして、何が悪いのか、と。
この二つは単なる表記上の違いである以上、二つに本質的な差はない。
せいぜい、click()はinputの属するクラスInputで定義されているはずだ、ですか。
#ちなみにPerl5のOOPはこれに似たものです。
#$input->clicked()とInput::clicked($input)は等しい
#っと、トップレベル関数を全廃すれば、Input::を省けますね
だから、どうしたと言われるとまだこれ以上は考えられていないのですが。
「ポリモルフィズムがOOPの本質だ」あたりにおちつきそうか・・・?
#あ、本気でOOPは表記上の違いだけだと思っているわけではないですよ、
#むしろ、表記の違いが本質的な違いを隠してしまっているのではないか、と。
> すばらしーどーさつ*50
どうもありがとうございます(笑
今思えば、VC++でテキストエディタを作ろうとして挫折したのがこれだったんですよね。
「今日の日付を編集中のテキストに挿入する」
を作りたかったのですが当時のわたしには無理でした。
今からすれば、
1. Date.nowみたいなのを探し、そこから今日の日付を取得
2. 取得した日付データを適当に加工してstringに
3. EditControlっぽいのの、valueに、加工したstringを追加
ってだけなのですが、これができなかった。
ちんたらNetBSDやってます(笑
currentのビルドがこけるー;;とか、
PCカード LANカード認識しないーとか。
前者は今も悩んでたり、後者は秋葉原を歩き回ったり。
> "VMという考え方"一般については、そんなに罠は無いのではないかと。
あったとしてもどうせくだらない特許でしょうから、潰せばいいでしょう。
まぁ、時間と金はかかりますが、、
#それに負けてSonyとかは屈しちゃう、
> それにrubyだって10語くらいでソレを書けるでしょ。
sedとの差は10文字でした;)
全くOOPしてませんが^^;;
#ちなみにperlは差1文字、「perl」は4文字だから。
Re:パイプについての考え方 (スコア:1)
はい。kも一杯並びます(藁
>経験則だったのですが、憂鬱本でも取り上げられているのですね、
>うぅ、今度読んでおかないと・・・。
うーん。憂鬱本は、確かに秀逸なんですが、
いささか旧聞すぎるかなってのと、
所詮はC++みたいなDQN言語(藁)を前提としてる限界が結構有るんで。
まあ、判った上で、「嗚呼ここの記述は古いなあ」と思いながら読めば、OKでしょう。
ただ、例えば「派生属性」のことをマヂで説明した文章を、その後なかなか見かけないような気がする、
という点では(少なくとも俺は)未だに憂鬱離れできないでいます。
世の中は、その後速やかにJava隆盛になったわけですが、
Javaで大切にされない概念…たとえば派生属性…は、世間でも蔑ろにされてる感じがします。
派生属性については、DelphiやC#の「プロパティ」という概念が
正にそれを体現してる言語仕様であり、説明の道具としても実用道具としても極めて秀逸なのですが、
困ったことにJavaは例のVisualJ++の一件で言語仕様の改善に背を向けてしまった。
(今ごろ(JDK1.5) EaseOfProgrammingなんて言っても”遅い”っつーの!!)
>click(input);
>としたとして、何が悪いのか、と。
その点については1つ問題というか誤魔化しがあるんですよね。
OOPはよく「主語が云々」という言い方をしますが、
むしろ「目的語」だと捉えたほうが良いんじゃないか?という疑問です。
まあ、
click(input)
の「中」が
input.click()
として実装されてる、つまり、
click(input)
は「主語と目的語を入れ替える、つまり立場を置換する」
という仕事(だけ)を行なっている、ということは
大いにありえるかなとは思います。
あとは多態ですかね。多態の拠り所であるObjectを
引数と切り離して特別扱いしたかったんじゃないかと。
そういう意味では、CLOSみたいにマルチプルDispatchをやり始めたら話が破綻しますんで、
結局「hoge.fuga」はシングルDispatchに特化した構文糖なんだろうなと。
>「ポリモルフィズムがOOPの本質だ」あたりにおちつきそうか・・・?
うーん。その説(よく聞きますが)は、ちょっと疑問に思っています。
他の方法論には無くてOOPにだけある「差分」としては、
ポリモルフィズムを真っ先に挙げるのが吉でしょうけど、
だから即それが本質かと言われると、首を傾げます。
ポリモルフィズムもまたOOPになるための部品の1つに過ぎないという印象を受けてます。
で、必要な全ピースが揃ってはじめてOOP。
かつ、それ以外の幾つかのピースは、OOP以外の方法論にとっても重要な部品である、
つまり兼任してる(^^;、ということが多いんじゃないかと思っています。
1つを取り出して「どうだ、これこそが本質だ!」と言えるような
発掘アクションもののハリウッド映画みたいな(藁)うまい話は
無いのかも知れない、と思っています。
>> すばらしーどーさつ*50
>「今日の日付を編集中のテキストに挿入する」
>を作りたかったのですが当時のわたしには無理でした。
その具体的事例から、前述の抽象的な問題提起(?)にまで
話を「ひきあげる」ことが出来るってのが、 (素晴らしい)洞察なのだと思います。
ところで個人的には、「一言一句を大事にしろ」という風に思おうと思っています。
つまり上記の例でも、「今日」「日付」「編集中」などとバラバラに区切って各個撃破
することを目指せばよかったわけで、
その際、「各個」を捉えるためには、上記仕様(?)の中の言葉をきちんと抜き出すという作業が
きっと必要になると思っています。
で、仕様を読む側も、そして書く側(^^;も、
一言一句をボヤかさないように留意することで、
プログラムは作りやすくなるんだろうなと…
>ちんたらNetBSDやってます(笑
や、俺も"既存OS"としてのNetBSDに恩義を感じないわけではないです。
RubyMGL2どうしたよ?とか(^^;
ただ、考えれば考えるほど、層(RubyとMGLという2つの層)を跨いだときの
Callbackの組み方やリソース解放管理で頭を抱えてしまうんで、
SqueakやSwingの「下層のWidgetを当てにしない」モデルのほうが楽かなと思ったり。