アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
今時の若いもの(藁)の意見 (スコア:1)
「OO言語を使うの必須だ」とは言ってません。
#俺もまたDQNかどうかは、さておくとして。
べつにLispでもいいんじゃないですか?
OOPというよりもどちらかというと、参照ベースの変数とか、GCとか、そっちのほうが
(気楽にプログラミングできるような高級な言語の)基礎としては大事な事柄で、
それこそCLOSみたいに、それらの仕組み(だけ)を駆使してライブラリレベルでOO言語風に仕立ててもいいんだし。
問題はshだとそれ「すら」旨くできない、という点だと思います。
OO「も」出来ない(やりにくい)。
そしてそれは、それ以外の色々なことも出来ない(やりに
パイプについての考え方 (スコア:1)
「結局どうやってこの分野に改革を起こすのか」というのがある。
つまり、
「ロードマップはできたけど、どうやって実装しよう」
「実装は終わったけど、どうやってみんなに使ってもらおう」
というところがある。
この問題に対するアプローチのやり方はいくつかあると思うけど、
趣味のプログラミングとしては、「現状+α+α+α+…」
といった感じで、ちっちゃい変更をどんどん加えていく方向でしか
実現はありえない、と思ってる。
そういった意味で、G7 さんの意見はしきいが高く感じちゃうなぁ。
で、そういった意味からすると r
# mishimaは本田透先生を熱烈に応援しています
Re:パイプについての考え方 (スコア:1)
> といった感じで、ちっちゃい変更をどんどん加えていく方向でしか
> 実現はありえない、と思ってる。
それってメインストリームの変更方法じゃないですか?
言ってみればC言語的な。
わたしは、むしろ趣味だからこそ全く違うものをいきなり持ってこれるのだと思います。
具体的な手法は、その言語・環境で動くキラーアプリを作るって、オープンソースで配布する。
バイナリは自分好みの設定をデフォルトにして配布する。
そうすると、その設定が気に入らない人が出てくる。
ここで、じゃあソースからいじっちゃえ、という人が出てくれば言語が広まるはず・・・と。
Re:パイプについての考え方 (スコア:1)
> > といった感じで、ちっちゃい変更をどんどん加えていく方向でしか
> > 実現はありえない、と思ってる。
> それってメインストリームの変更方法じゃないですか?
書き方が悪かったですね。
システムの規模が問題だと思っています。
少なくとも、OS から一切別のものを作るようなアプローチはありえない、と。
> ネットワークでなくとも、
> .NETにおけるF# [microsoft.com] (OCaml)やNemerle [nemerle.org]とかそうですね。
そうです。
そして .NET のようなやり方が気に入らない
(ライブラリ
# mishimaは本田透先生を熱烈に応援しています
Re:パイプについての考え方 (スコア:1)
いやー、それこそ趣味なら、ちんたらSqueakするのもアリじゃないかと。
#世間じゃさぞ「ちんたらLinux」「ちんたらBSD」と思われてるでしょうね。
>そして .NET のようなやり方が気に入らない
>(ライブラリに依存する、ライブラリに囲い込まれる、状態がメモリ上)
>からこそ、こういう提案をしているわけで。
.NET方式をそう呼ぶ(批判する)のは的外れだ、と俺は思いますね。
ライブラリ依存云々については「じゃあ"Unixという考え方"に依存してるアレは何?」ですし、
メモリは今やトレンドでしょで話は終わりだし。
>「もう一つの .NET の実装を作るにはどうしたらいいの?」
>「それは俺が/あなたがやろうとしてできること?」
もう1つのUnix実装を作ったフィンランド人は偉人扱いされています。
同じことでしょう。
既に使える実装がFREEで転がってるか?という話ならば、
VMだってそういうものが幾つか有るわけで。
>まぁ、引っかかるのは開発規模だけではなく、特許がらみの話も
>あるかもしれないけど。
.NETという設計自体は罠つきも知れないけど、
"VMという考え方"一般については、そんなに罠は無いのではないかと。
>> それよりも、初心者ができないのって、問題の分割なんですよね。
>そう。初心者はそれができない。OOP 以前の段階で躓く。
>だからこそ OOP は初心者には難しい、といっているわけです。
>初心者でも OOL を使うことはできる。でも OOP はできない。
待てコラ(^^;。それじゃ"馬鹿三段論法"っす。
それ言ったら、shだってBASICだって、使えない初心者は使えないっすよ。
つまりshの基盤である「手続き指向」だって、
人間の本能だけで使えるものではない、ということです。
手続き指向もOOPも、どちらも「訓練」によって使えるようになるものです。
王道は恐らく無いはずです。
>「このテキストファイルの中の A という文字列を B に置き換えたい」
>なんていう問題に対しては、sed の方が覚えることは少なくて
>済むでしょうね。
ダウト。sedはヘビーっすよ。
それにrubyだって10語くらいでソレを書けるでしょ。
逆にいえば、その用途だけならばsedよりtrのほうが遥かに「判りやすい」はずだし。
つまりsedだって、無数に有る「難しさレベル」のうちの1つに過ぎないんです。
もし貴方が今、「rubyは難しすぎる」&「trは単純すぎて、やれることが少ない」と思ったならば、
その視点はあくまで相対的でしかないことを、一度思い出してください。
>さらに言えば、プログラミングの教科書で教える解法はいつも
>「与えられた入力(=関数引数)に対して結果を戻り値で返す」
>という手法。
>でも、たいていプログラマに与えられる問題の規模は
>これを遥かに上回ってる。
そういう「上を向く」志向をなさりたいなら、尚の事、 OOPは避けて通れませんよ。
そういう「上」な話を、より楽に解決するために、OOPは有るのですから。
ちょうど、少々長い手続きプログラムを「(手続きの)構造化」により折り畳むように、ね。
OOPはOOPで、ある(メタな)問題を解決します。
(手続きの)構造化は(手続きの)構造化で、ある (メタな)問題を解決します。
それだけ。
>例えば OOL としては理想的な smalltalk では、
>「オブジェクトにメッセージを送信する」ことを文法として
>サポートしたわけだけど、そのアプローチが最適でない問題と
>いうのは多々あるわけで(例えば、テキストファイルの中にある
>文字列 A を B に変えたいんだけど、とかいう問題)。
ん?どこが最適でないんだろう?
それに最適とか言うんならtrを持ち出すなり、
アセンブラを持ち出すなり(だってそのほうが「最適」でしょ?なにせ速度において一番最適だもの)
をしなきゃ。
あー。つまりですね、最適ってのは、「何について最適」なのか、常に考えなきゃです。
#「ファイル圧縮ソフトは、サイズについて最適化するソフトだ」といった知人が居た。名言なり。
で、ですね、
もしかして「Unix志向に対して最適化」じゃ、この場合は議論にならんのです。
また、OOPか否かは、tr的問題(^^;から見れば、測定誤差範囲内の差じゃないですか?
だからこそruby屋は今日も「"hoge".sub(/A/, "B")」と書いてるわけで。
#この部分だけ見れば、rubyって、「AWKの語順を変えただけ」なんだよな。
>ある実行環境だけで問題解決できることはそんなに多くない。
>必ず別の環境/OS/言語/etcとの連携を前提の仕組みが必要だろう
>(たとえばコンパイル時の autoconf + make のような)と
>思うんだけど、この連携を本当の意味で「シンプル」に
>実装したものを見たことないんだよねぇ。
うん。俺もあまり見たことが無いです。
UnixとかいうOSもイマイチだったしなあ。部品化とか言っているんだけど、
その部品化Framework自体がギコチナクて、解ける問題の範囲が狭すぎてさ(ぉ
"考え方"が違うと、連携しようにも旨くできない、ということがしばしば起きます。
連携のコストを払うくらいなら、仕掛けを全部自分で持ったほうが楽、ってことね。
で、だからって"考え方"を1つに限ったらパラダイスか?ってーと、
そうでもないから悩むわけです。
たとえばUnix方式では足りないとかね。