アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
今時の若いもの(藁)の意見 (スコア:1)
「OO言語を使うの必須だ」とは言ってません。
#俺もまたDQNかどうかは、さておくとして。
べつにLispでもいいんじゃないですか?
OOPというよりもどちらかというと、参照ベースの変数とか、GCとか、そっちのほうが
(気楽にプログラミングできるような高級な言語の)基礎としては大事な事柄で、
それこそCLOSみたいに、それらの仕組み(だけ)を駆使してライブラリレベルでOO言語風に仕立ててもいいんだし。
問題はshだとそれ「すら」旨くできない、という点だと思います。
OO「も」出来ない(やりにくい)。
そしてそれは、それ以外の色々なことも出来ない(やりに
パイプについての考え方 (スコア:1)
「結局どうやってこの分野に改革を起こすのか」というのがある。
つまり、
「ロードマップはできたけど、どうやって実装しよう」
「実装は終わったけど、どうやってみんなに使ってもらおう」
というところがある。
この問題に対するアプローチのやり方はいくつかあると思うけど、
趣味のプログラミングとしては、「現状+α+α+α+…」
といった感じで、ちっちゃい変更をどんどん加えていく方向でしか
実現はありえない、と思ってる。
そういった意味で、G7 さんの意見はしきいが高く感じちゃうなぁ。
で、そういった意味からすると r
# mishimaは本田透先生を熱烈に応援しています
Re:パイプについての考え方 (スコア:1)
> といった感じで、ちっちゃい変更をどんどん加えていく方向でしか
> 実現はありえない、と思ってる。
それってメインストリームの変更方法じゃないですか?
言ってみればC言語的な。
わたしは、むしろ趣味だからこそ全く違うものをいきなり持ってこれるのだと思います。
具体的な手法は、その言語・環境で動くキラーアプリを作るって、オープンソースで配布する。
バイナリは自分好みの設定をデフォルトにして配布する。
そうすると、その設定が気に入らない人が出てくる。
ここで、じゃあソースからいじっちゃえ、という人が出てくれば言語が広まるはず・・・と。
コンパイル型だと難しいかもしれませんが、スクリプト言語ならこのモデルでいけそうな気も。
#OpenIrvine [osdn.jp]に開発者が集まらないのはDelphiだからと同時に、
#Delphiがコンパイル型なのも一因だろう、と。
> 「本当のグッドラッパーはネットワークサービスだ」
それってSOAPですよね?
もはや‘Simple’ではなくなってしまいましたけれども。
> ぜんぜん違ったプログラミング言語の(宣言型言語とかの)開発者まで
> 含めることができて、まったく違った問題解決のアプローチを
> しているプログラムを作ってくれるかもしれない。
ネットワークでなくとも、
.NETにおけるF# [microsoft.com] (OCaml)やNemerle [nemerle.org]とかそうですね。
ネットワークよりもVMを使った方が圧倒的に速いかと。
ところで、このNemerleって出来て1年経ってないんですよね。
1歳未満なのに.NETの巨大なライブラリを使えるというのは素晴らしい。
> たとえばshはデータ構造を作るのが絶望的に難しい(でしたよね)のですが、
> 日常的にはそんなものは作らない、と?
わたしは未だにshを使えませんね。
そもそも、平気で配列やハッシュを使っちゃうので・・・。
> RubyにLinkedListクラスやTreeNodeクラスが無いのが不思議なのでG7
あぁ、同感です。
W3C DOM非対応なREXMLを標準ライブラリにするくらいなら、
いっそ言語自体にREXMLを組み込んで欲しい。
> グッドラッパー
うーん、やっぱり、TeXはXSLなどで、sendmailはpostfixなどで置き換えちゃった方がいいように・・・。
しかし、emacsはバッドノウハウだけれどviはそうでもないんですかね。
###
そういえば、ふとソフトウェア配線 [no-ip.com]を思い出しました。
結局今の話って目指すところはこれと同じですよね?
> また、古典的手続き指向が「(初心者に)楽」かと問われると、俺にはさっぱりそう思えません。
OOPって初心者にとって難しいんですかね?
どうもJavaやC++の難しさをOOPの難しさと混同していたり、
そもそもの設計の難しさをOOPの難しさと混同しているような感じがします。
極端な話、OOPってpush(array,element)がarray.push(element)になっただけじゃないですか。
それよりも、初心者ができないのって、問題の分割なんですよね。
Aという問題をA1,A2,A3に分割できれば、
def A; A1(); A2(); A3(); end
で終わりなのに、それができない。
このレベルではOOPも何もないわけで。
#とりあえず、何もプログラミング言語を知らない人にRubyをいきなりやらせてみよう、
#というのは近々やってみたいと思っていたり。
Re:パイプについての考え方 (スコア:1)
> > といった感じで、ちっちゃい変更をどんどん加えていく方向でしか
> > 実現はありえない、と思ってる。
> それってメインストリームの変更方法じゃないですか?
書き方が悪かったですね。
システムの規模が問題だと思っています。
少なくとも、OS から一切別のものを作るようなアプローチはありえない、と。
> ネットワークでなくとも、
> .NETにおけるF# [microsoft.com] (OCaml)やNemerle [nemerle.org]とかそうですね。
そうです。
そして .NET のようなやり方が気に入らない
(ライブラリに依存する、ライブラリに囲い込まれる、状態がメモリ上)
からこそ、こういう提案をしているわけで。
別の言い方であれば
「もう一つの .NET の実装を作るにはどうしたらいいの?」
「それは俺が/あなたがやろうとしてできること?」
ってところ。
まぁ、引っかかるのは開発規模だけではなく、特許がらみの話も
あるかもしれないけど。
> OOPって初心者にとって難しいんですかね?
> それよりも、初心者ができないのって、問題の分割なんですよね。
> Aという問題をA1,A2,A3に分割できれば、
> def A; A1(); A2(); A3(); end
> で終わりなのに、それができない。
> このレベルではOOPも何もないわけで。
そう。初心者はそれができない。OOP 以前の段階で躓く。
だからこそ OOP は初心者には難しい、といっているわけです。
初心者でも OOL を使うことはできる。でも OOP はできない。
この手の議論では、「OOP ができる」ということと「OOL が利用できる」ということが
いつもごっちゃになっているような気がします。
「このテキストファイルの中の A という文字列を B に置き換えたい」
なんていう問題に対しては、sed の方が覚えることは少なくて
済むでしょうね。
さらに言えば、プログラミングの教科書で教える解法はいつも
「与えられた入力(=関数引数)に対して結果を戻り値で返す」
という手法。
でも、たいていプログラマに与えられる問題の規模は
これを遥かに上回ってる。
入力が引数以外で与えられる、出力を戻り値以外で返さなければならない、
外部のリソースへのアクセスが必要だから同期制御が必要になる、
ブロッキングによって停止する…などなど。
こういった複雑性を排除して、いかに教科書で最初に教えるような
単純な状況を作り出すか。そしてもし単純化できない問題があれば
それをどうやって明示的に言語の重要な要素として抜き出すか。
そこが「問題に対して適切な言語」「そうでない言語」の違い
だろうと思います。
言語の文法レベルでサポートするのとライブラリがサポート
するのとでは、状況はまったく異なっているわけで。
例えば OOL としては理想的な smalltalk では、
「オブジェクトにメッセージを送信する」ことを文法として
サポートしたわけだけど、そのアプローチが最適でない問題と
いうのは多々あるわけで(例えば、テキストファイルの中にある
文字列 A を B に変えたいんだけど、とかいう問題)。
ある実行環境だけで問題解決できることはそんなに多くない。
必ず別の環境/OS/言語/etcとの連携を前提の仕組みが必要だろう
(たとえばコンパイル時の autoconf + make のような)と
思うんだけど、この連携を本当の意味で「シンプル」に
実装したものを見たことないんだよねぇ。
大手ソフトウェアベンダが標準化するから、みんな複雑なものになっていく。その上重い。
だからいろいろな言語で「ライブラリを多くしてこの言語だけで
何もかもできるようにしよう」的なアプローチが発生するんだろうと。
# 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の語順を変えただけ」なんだよな。
>ある実行環境だけで問題解決できること
Re:パイプについての考え方 (スコア:1)
まあviもそんなに美ではなくバッドでしょうね。
ただ、やたらと多いルールを「大脳が」覚えるか「小脳が」覚えるか、
という違いは有るような気がします。
emacsは知りませんが、viだと、その操作体系のうちかなりの割合を
小脳に覚えさせられます。つまり無意識にやれちゃう。
そして意識は(無意識層の存在を意識せず)対象であるファイルと交信しようとしますから、
結局vi方式は、意識と対象物との間の「BUS」が広くなるんですよね。
#少なくともカーソル移動キーの個数が 約4 vs 約100 では、勝負になりませんね>世間の多くのカーソルキー依存エディタ
>そういえば、ふとソフトウェア配線 [no-ip.com]を思い出しました。
>結局今の話って目指すところはこれと同じですよね?
あはは。どうでしょうか…
#ところであの家主氏、言ってることを結局理解してくれたんだろか??
ソフトウェア配線については、例の業務屋さん(藁)が推してる一連の奴(DIconとかいう奴)が、
結果的に近いかなとも思っています。
まあ実際「DIconはDelphiと似てるよね」という問いにはYESという解答を貰っているんで、
たぶんそうなんでしょう。
>そもそもの設計の難しさをOOPの難しさと混同しているような感じがします。
う。素晴らしいどーさつ。
憂鬱本の言い回しを借用するならば、
「今まで見なかったことにしていた「設計の難しさ」が OOPで隠せなくなった」
といった所かな。
>極端な話、OOPってpush(array,element)がarray.push(element)になっただけじゃないですか。
まあ字面は飾りで、偉い人にはそれが判らんのです。
#ここで某氏の名前を挙げたくなる黒い悪寒…
俺はOOPで、「能動者の逆転」というパラダイムシフトがあったようには思います。
OOPは「される」の世界なんですよね。イベントが飛んできてCall「され」て初めてお仕事します的世界。Callback世界。
#そういう意味では、DIconのDI(DependencyInjection)の前身であるInversionOfControlってのは噴飯モノです。
#Callback、つまりOOPやWindowsやMac(藁)の時点で既に、ControlはInvertしていたっていうのに。
#気付いてくれてありがとう、っていうか初手で気づけよ>ファウラーたん
余談ですが、Rubyが気楽だと言われる所以の1つに、この「逆転」を無視したければ無視できる、
という点が有ると感じています。
つまるところ「main」が我が手に有るか否かの差なのですが、
RubyはScript言語らしく、まずmain相当物がユーザに開放されています。てゆーか何も考えずに書けばmainになる。
とりあえず命令(手続きやMethodのCall)を書ける、ということは、とりあえず自分が「する」側に立てる、ということです。
これがノーコストでやれるのがRubyです。あまりOOPくさくない、「する」側の視点で、とりあえず書ける。
で、ちょっと気のきいたことをしたくなったら、さりげなく「される」側に回ればいい。(これも、無料ではないが低コストで回れる)
「する」と「される」の駆動比率を、自在に(かつ楽に)加減できる。
>それよりも、初心者ができないのって、問題の分割なんですよね。
>Aという問題をA1,A2,A3に分割できれば、
>def A; A1(); A2(); A3(); end
>で終わりなのに、それができない。
すばらしーどーさつ*50
正にソレです!!
ちなみに俺の近所にそういう奴らがいない保証は無いです(T_T)
UseCaseをIncludeで分解することすら出来ないし。
てか、既にそういう仕様書が山のように蓄積してるし(T_T)
これ、どう始末しろってのよって感じぃ…鬱…
#今日煩悶したネタも、そういや突き詰めれば「問題分割」ネタだったよなあ…(T_T)
初心者という呼称は不適切だと最近思っています。
経験した「時間」も短くないし、まして「心」なんて初心から遥かに離れているわけですが、
それでも出来てない奴らってのは、
○初脳者
○初能者
とでも呼べばいいんでしょうかね…
#先輩や上司は、こういう奴らを"刈ら"ないと駄目だって。刈るのは首である必要は無いけどね。
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でも手続き指向でも、機能分割だってやりますよね。
問題は機能なりなんなりを「どういう単位で」区切るか、なんですけどね。
あとクラスとオブジェクトを混同しないことですかね。
クラスは所詮はオブジェクトのプロトタイプでしかない、と悟れるかどうか。
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を当てにしない」モデルのほうが楽かなと思ったり。
Re:パイプについての考え方 (スコア:1)
プログラミング言語初心者を一人確保したので、
Rubyを教えることで主張「初心者にとってOOPは難しくない」
が正しいか確かめてみることにします。
現在考えているのは、「CGI/RubyによるWebチャットの実装」
という課題を通して、プログラミングが出来るようになろうと。
CGI/Rubyというあたり微妙ですが、本人が作ったものを自発的に改良してもらい、
その過程で力をつけてもらいたい、という方針なので、
本人の興味のある、これに落ち着きました。
#本当はいきなりNemerleをやらせてみたかったのですが、この理由で流れました
経歴は、
C言語に挑戦したものの、Hello,Worldすら知ることなく挫折
とのことなので、白紙と考えてよさそうです。
まずは、問題分割~設計あたりから始めることにして、
実際にRubyをいじらせるのは先にしようと思っています。
#しかし他のコメントでも書きましたが、
#何が出来たらOOPができたことにしていいのですかね?
Re:パイプについての考え方 (スコア:1)
微妙ですねえ。
CGIって、もろにPipeモデルのWebへの焼き直しで、
#Pipeの合間にユーザ操作が挟まった感じ?
OOPの出番があまり無いとも言えるんですよね。
もっとOOPするには、
こんな風にしないとならないだろうな、と思っています。
http://hpcgi2.nifty.com/guion3/tiki/tiki.cgi?c=v&p=WebDesktopServer
まあこんなToyライブラリはどうでもよくて(^^;、もっとマシ(恐らく)なDivとかを使うほうが良いのかも知れませんが、
いずれにせよPipeと遷移の世界ではOOPには近づかないんじゃないかと。
もちろんOOPを使ったコーディングも出来ますが、
あくまで「使う」だけっていう感じだし、
「される」感じにもなり難そうだし。
>まずは、問題分割~設計あたりから始めることにして、
俺も未経験なんでアレですが、CRCカードなんかどうなんでしょうか?
ただ、CRCだと、RolePlayingGameじゃなくClassPlayingGameになっちゃう危険が
あるような気はしますが。
プレイヤ各自が持つのは、CRCカードそのものじゃなく、CRCカード(つまりクラス)を参照するカード、
なんじゃないかなあ?