アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
今時の若いもの(藁)の意見 (スコア:1)
「OO言語を使うの必須だ」とは言ってません。
#俺もまたDQNかどうかは、さておくとして。
べつにLispでもいいんじゃないですか?
OOPというよりもどちらかというと、参照ベースの変数とか、GCとか、そっちのほうが
(気楽にプログラミングできるような高級な言語の)基礎としては大事な事柄で、
それこそCLOSみたいに、それらの仕組み(だけ)を駆使してライブラリレベルでOO言語風に仕立ててもいいんだし。
問題はshだとそれ「すら」旨くできない、という点だと思います。
OO「も」出来ない(やりにくい)。
そしてそれは、それ以外の色々なことも出来ない(やりに
パイプについての考え方 (スコア:1)
「結局どうやってこの分野に改革を起こすのか」というのがある。
つまり、
「ロードマップはできたけど、どうやって実装しよう」
「実装は終わったけど、どうやってみんなに使ってもらおう」
というところがある。
この問題に対するアプローチのやり方はいくつかあると思うけど、
趣味のプログラミングとしては、「現状+α+α+α+…」
といった感じで、ちっちゃい変更をどんどん加えていく方向でしか
実現はありえない、と思ってる。
そういった意味で、G7 さんの意見はしきいが高く感じちゃうなぁ。
で、そういった意味からすると r
# mishimaは本田透先生を熱烈に応援しています
Re:パイプについての考え方 (スコア:1)
> といった感じで、ちっちゃい変更をどんどん加えていく方向でしか
> 実現はありえない、と思ってる。
それってメインストリームの変更方法じゃないですか?
言ってみればC言語的な。
わたしは、むしろ趣味だからこそ全く違うものをいきなり持ってこれるのだと思います。
具体的な手法は、その言語・環境で動くキラーアプリを作るって、オープンソースで配布する。
バイナリは自分好みの設定をデフォルトにして配布する。
そうすると、その設定が気に入らない人が出てくる。
ここで、じゃあソースからいじっちゃえ、という人が出てくれば言語が広まるはず・・・と。
Re:パイプについての考え方 (スコア:1)
> 少なくとも、OS から一切別のものを作るようなアプローチはありえない、と。
あ、プラットフォームレベルの話ですか。
それだと互換性がって話ですか?
作業量的な話でしたら、その作業は本当に一人でやるものなのか、と。
> ライブラリに依存する、ライブラリに囲い込まれる
ライブラリ(=.NETアセンブリ)に依存するのと、UnixToolsに依存するのって、
そんなに違いますか?
OpenBSD一味がgzipやgrepを置き換えるのと同程度の労力で、
ライブラリの一部を私家版に置き換えることは可能だと思うのですが。
> 状態がメモリ上
わたしの中では、
メモリ:一次保存用、HDD:短期保存用、CD-R:長期保存用
なので、状態がメモリ上なことに違和感はないです。
また、/tmpをRAMディスクにして、そこに状態をおいたらどうなの?とか、
Googleのキャッシュや(もしかしたらGmailも)が全てRAM上に置かれている~
という話も考えると、そこが問題になるのはなんかナンセンスかな、と。
って、これは脱線か。
結局、状態を一時メモリにおくか保存用メモリに置くかって話なのでしょうか。
ところで、ふと、思ったのですが、mishimaさんは、
UnixToolsはすでに存在するもの、Rubyや.NETはまだ存在しないもの、
として扱っているように感じます。
Rubyも.NETもすでに存在していますよ。
#RubyVMやParrotはまだですが。
> だからこそ OOP は初心者には難しい、といっているわけです。
えっと、今の「初心者」ってOOP初心者でなく、プログラミング初心者ですよね?
オブジェクト指向が、手続き型志向のオプションならば、
たしかに要素が一つ増える分難しくなるのでしょうが、
オブジェクト指向が、手続き型志向に対して直行ならば、
OOPの方が非OOPよりも難しいとは言えないはずです。
むしろわたしはOOPの方が非OOPよりもやさしいと思っています。
> 「このテキストファイルの中の A という文字列を B に置き換えたい」
えぇと、sedだと「sed -e"s/A/B/" this.txt」ですか、
Rubyだと「ruby -pe"gsub!('A','B')" this.txt」ですね。
Rubyでこれを書くのに必要なのは、
* Rubyのコマンドライン引数
* gsub!関数について
の知識でしょうか。
> 「OOP ができる」ということと「OOL が利用できる」
「 「OOL が利用できる」⇒「OOP ができる」 」
は必ずしも成り立たない、は同意です。
ただ、まともなOOLなら使っているうちにOOPが出来るようになるはず。
#そもそも「OOPができる」をどう定義するかがまず問題ですが。
#「Smalltalkが使えるようになったら」とか(笑
> 必ず別の環境/OS/言語/etcとの連携を前提の仕組みが必要だろう
これは今、続々と‘実現’されている話ですよね。
ということは、問題となるのは、
> この連携を本当の意味で「シンプル」に
というところなのでしょうか。
けれど、シンプルに実装することが可能かは少々疑問があります。
例えば、公約数を小さめに取って、そこだけ標準化し、
拡張部分はベンダー独自に実装、とすれば規格はシンプルに出来ます。
しかし、その後に待っているのは実装ごとに分岐させた怪コードの山・・・。
また相互運用する場合はどうしても規格を厳密に定めねばなりません。
さもないと実装ごとに微妙に挙動が異なることになり、
やっぱり実装ごとに分岐して対処しないといけないことになります。
#例えばCSS(==
> だからいろいろな言語で「ライブラリを多くしてこの言語だけで
> 何もかもできるようにしよう」的なアプローチが発生するんだろうと。
あれ、この話は何を念頭においていらっしゃいます?
.NETだとすると、多言語連携が一応可能ですし・・・。
RubyWayなるものを時々振りかざすRubyとかでしょうか。
Re:パイプについての考え方 (スコア:1)
記憶については、ハード媒体の違いは(抽象化可能であるので)どうでもよくて、
問題は名前にどうbindするかっていう点だと思います。
無名であることを許してくれるかとか、という点です。
そういう意味で伝統的な「ファイル」は無名にならないんで困ります。
パイプは無名だけど、引き換えに着脱が不自由で使えないし。
あと無名の副作用(^^;としてGCも欲しいですねえ。
あとObjectやClosureみたいに、複数の処理や状態を束ねる道具が欲しいです。
ディレクトリでも良いのかも知れないけど、無名になれるのか?とか、
GCはどうする?とか(ハードリンクが使えるならば参照係数法を採用できるんですが、
ディレクトリはサポートされてないわけだし)…
なお無名とかGCとかClosureを、かくも自信を持って(藁)お勧めするのは、
これらがSchemeの必須機能に挙げられている機能だからです。
つまりプログラミングをまともに支援するための必須アミノ酸。
>UnixToolsはすでに存在するもの、Rubyや.NETはまだ存在しないもの、
>として扱っているように感じます。
というか、存在を「無視してもいいと思ってる」かどうかの差、という印象。
>むしろわたしはOOPの方が非OOPよりもやさしいと思っています。
やっぱりTaoOfObjectsの話が魅惑的ですね(^^;。たしかこんなの:
「ある日私は、知人の医者にObject指向について説明した。
すると医者答えて曰く、
「よく判らないな。
じゃあそれ以前はどうやってプログラムを作っていたんだい?
想像がつかないなあ。」」
>ただ、まともなOOLなら使っているうちにOOPが出来るようになるはず。
余談ですが、C++は駄目だし、
Javaも今(もっとマシな言語が実用速度で動く時代)となっては怪しいですね。
特にC++は以前から苦々しく思っていました。
原作からしてそうなのか、アホな周囲の参考書執筆者たちが悪いのか、は把握してませんが、
とにかく、
○「オブジェクト」という言葉を使うべきところで「クラス」という単語を使う。
(判りやすい)最悪の例が、「クラスを作る」という言葉。
クラスのコーディングをするって意味じゃなくnewするっていう意味でこの言葉を使うから、駄目すぎ。
なんていう現象が観測できるのは、本当に頭が痛いです。
>#そもそも「OOPができる」をどう定義するかがまず問題ですが。
「オブジェクトは機能である」みたいなことを言わなくなったら、ですかね(藁
ですから、かなりの割合の参考書執筆者も失格です。
だって、機能っていう説明のしかたでよいなら、手続き指向だって同じ「機能」なんですから。
OOPでも手続き指向でも、機能分割だってやりますよね。
問題は機能なりなんなりを「どういう単位で」区切るか、なんですけどね。
あとクラスとオブジェクトを混同しないことですかね。
クラスは所詮はオブジェクトのプロトタイプでしかない、と悟れるかどうか。