アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
今時の若いもの(藁)の意見 (スコア:1)
「OO言語を使うの必須だ」とは言ってません。
#俺もまたDQNかどうかは、さておくとして。
べつにLispでもいいんじゃないですか?
OOPというよりもどちらかというと、参照ベースの変数とか、GCとか、そっちのほうが
(気楽にプログラミングできるような高級な言語の)基礎としては大事な事柄で、
それこそCLOSみたいに、それらの仕組み(だけ)を駆使してライブラリレベルでOO言語風に仕立ててもいいんだし。
問題はshだとそれ「すら」旨くできない、という点だと思います。
OO「も」出来ない(やりにくい)。
そしてそれは、それ以外の色々なことも出来ない(やりに
パイプについての考え方 (スコア:1)
「結局どうやってこの分野に改革を起こすのか」というのがある。
つまり、
「ロードマップはできたけど、どうやって実装しよう」
「実装は終わったけど、どうやってみんなに使ってもらおう」
というところがある。
この問題に対するアプローチのやり方はいくつかあると思うけど、
趣味のプログラミングとしては、「現状+α+α+α+…」
といった感じで、ちっちゃい変更をどんどん加えていく方向でしか
実現はありえない、と思ってる。
そういった意味で、G7 さんの意見はしきいが高く感じちゃうなぁ。
で、そういった意味からすると ruby の問題点というのは
実はプログラミング言語の機能の問題ではなくて、
それを取り巻く環境(=インストールされていない、実績がない、経験者が少ない、規模が大きい…)だ、
ということになる。
sh はそこが優れていて、しかも日常的に要求される程度のことは一通りこなせる。たとえば、sh の言語としての最大の利点は
「可搬性(=自分に管理権限のないホストへの移植性とか)」
だろう。それは言語の機能じゃないけど、言語にとって、
とても大切なことだと思うわけ。
自分は「グッドラッパー [hyuki.com]」の考え方にちょっと興味がある。
なるほど、
> それこそ例えばRubyって、UnixのOOラッパーとして面白い(しかも実用的な)側面を色々持っていますよね。
そういう考え方でいえば、ruby もグッドラッパーなのかもしれない。でも、
> #Unixのラッパー部分が言語本体と不可分であるというRubyの実装設計が、俺は気に食わないのだが、それはそれ。
ここには微妙に同意。問題なのは
「グッドラッパーな言語とそうでない言語の両方が必要になる状況が多い」
「何がグッドラッパーなのかは、問題領域によって異なる」
ということ。
そのためにさまざまな言語があるわけだし、
中には自作する人もいるわけだけど、
のようなデフレスパイラルがよくある。
そうでなくても、
「○○には△△処理用のライブラリがあるんだけど、この言語にはないんだよねぇ」
とか。
んで、思っているのが
「本当のグッドラッパーはネットワークサービスだ」
ということ。ネットワークサービスのレイヤになれば、
ほとんど完全に抽象化されたサービスを利用者に与えることができる。
Unix であることも Windows であることもほとんど無視できる。
この立場であれば、プロトコルを適当に決めてやれば、
他のアプリケーションとの通信部分を実装するだけで、
どの言語でも(sh でも ruby でも)おなじライブラリ環境になることができる。
sh でやりにくい問題があれば、それをネットワーク経由で別の誰かに
代わりに処理してもらえばいい。
そしてパイプ。一般的なストリームを使ったネットワークサービスは、
プログラムの構造としてはパイプを使ったアプリケーションとほぼ同一。
(古来の Unix ツールはプロトコルがばらばら&めちゃくちゃ、
という問題はあるけれど、標準入出力というストリームを扱う
ツールである、という点だけであれば共通している)
プロトコルの単純さと言う意味では HTTP/0.9 みたいなのが理想的で、
そのレベルであれば十分に sh でも「対応言語」の仲間入りができるはず。
もちろん sh っていうのは最低ラインの話であって、
「sh でできるんだから C でも Java でも Ruby でも」ってことなんですけど。
> DQNはともかく少なくとも俺は、
> 「OO言語を使うの必須だ」とは言ってません。
俺もそう思います。
さっきの俺のアイディアは CORBA などで既に
実装されているものを別のプロトコルに置き換えただけだと
言い換えることもできるけど、
各言語に対して通信部分を実装する都合上、
プロトコルは単純で簡潔なのがいい。
そして CORBA はそうでないところに問題があったと思う。
あまりに OOL に便宜を図ったために可搬性が低下した、ということで。
企業の製品ならともかく、個人の趣味でやるレベルであるなら、
みんな(=趣味で開発することのできる人)に使ってもらえるか
どうか、という視点での可搬性は非常に重要だと思う。
結局いろんな人のリソースを使って開発するわけだから、
新しい言語の勉強をしないような人の開発リソースだって
含めることができるほうが有利ですよね。
言語について横断的に開発者を集められる。そうすると、
ぜんぜん違ったプログラミング言語の(宣言型言語とかの)開発者まで
含めることができて、まったく違った問題解決のアプローチを
しているプログラムを作ってくれるかもしれない。
自分はそんな言語を使ったことがなくても、それを自分の
プログラムの内部で呼び出して利用することだってできるかもしれない。
(現状だと、ライブラリという形で提供されていない場合、
そのプログラムの書かれた言語を理解しないと再利用できないですよね)
「+αで実装できる」「古来 Unix と互換性のある」
「レガシーに縛られない」「可搬性の高い」「予想外の発展の余地がある」
というのが、パイプというものを利用したプログラミングの形だと
思っているわけなんですが…
# mishimaは本田透先生を熱烈に応援しています
Re:パイプについての考え方 (スコア:1)
うーん。Macみたいに「魅了する」って手を使いますかね(藁
>実はプログラミング言語の機能の問題ではなくて、
>それを取り巻く環境(=インストールされていない、実績がない、経験者が少ない、規模が大きい…)だ、
規模については、shだって別に小さいわけじゃないと思います。
きちんと(つまり意図通りに)動かすために覚えないとならんことは、結構多いと感じてます。
俺はshとかを覚えたのが結構後から(CやDelphiより後)だったもんで、後から覚える手間(^^;をかけたわけです。
まずshありきという生活スタイルではなかった。
そんな俺から見ると、shもまた1つの、そこそこ複雑な「言語」、でしかないんですよね。
そういう意味ではVBとCとDelphiとRubyとshの間には、あまり差が無いなあと。
>sh はそこが優れていて、しかも日常的に要求される程度のことは一通りこなせる。
「要求」って何なんでしょうね?
たとえばshはデータ構造を作るのが絶望的に難しい(でしたよね)のですが、
日常的にはそんなものは作らない、と?
個人的には、3割くらいしか同意できない感じです。
俺は、何かScriptを書くときって、結構頻繁に、途中でムカついてshからRubyに書き換えたりしてます(^^;
逆にいえば、(手軽な)言語がそういう点をもっと積極的に支援してくれたなら、
もっとカジュアルにみんなデータ構造をばりばり使えるようになるんじゃないかと。
#RubyにLinkedListクラスやTreeNodeクラスが無いのが不思議なのでG7
#もちろん簡単に作れるわけですが、良質な雛形が最初から装備されてても良さそうなもんだろと…
つまり、言語は思考を規定してるんだと思います。
たとえばこの例では、データ構造を駆使しないのが「日常的な」用途だ、と規定してしまってる、と。
>グッドラッパー
ちょっとどうかなと思っています。
勿論実用的には頷ける意見なのですが、
実用的に過ぎるというか、頭隠して尻隠さずに陥る可能性が結局消えないというか。
#今月のLinuxだかなんだかの雑誌に、Smalltalk(Squeak)がDQN言語であるかのように書いてあって、がっくりしたのでG7
#少なくとも言語仕様は万全だろうに。
>ネットワークサービスのレイヤになれば、
>ほとんど完全に抽象化されたサービスを利用者に与えることができる。
いや、それもどうかと思います。
ここ [hatena.ne.jp]見てみてください。いわくEJBはもう死んでいると。
少なくとも俺は頷いた。
本当にどこでも使うくらい汎用なものは、ネット経由せずLocalなほうが(速度的に)圧倒的有利だし、
そうでないものは大抵、多少なりとも環境依存性があるもんだ、と感じてます。
というか実のところ、俺って「ネットワークサービス」って寒いなぁと思っています。
まあ粒度が充分大きければ、ああいうPipelineアーキテクチャも結構役立ちますが、
もう少し木目細かく仕事したいときには不自由します。それは例えばそれこそGUI Widgetのような、ね。
それこそ上記URLでServletを引き合いに出してるように、
shだってCGIを作れるという意味ではアレなわけです。
#てゆーか元を正せばHTTPとPipeが似てるっていうだけのこと、かな。
でも、逆にいえば、HTTP&Pipeは、所詮ソコまでのモデルだってことだと思ってます。
あと、HTTPとPipeの差としては、クライアントの頑張り度合いですね。
HTTPって、鯖は楽ですがクライアントは凄まじい仕事をする。
GUIのレンダリング云々って話もありますが、ここではそれじゃなく、
通信の登りと下りの両方を面倒観てるって点が。これはPipeには無い性質なわけで。
また前述の切り替え自在性もPipeとの大きな違いですね。
長くなりましたが、こうして書きながら考えるとつまり、
Pipeは「粒度が大きいもの専用」ってところかと。
また登り下りを同時に捌けなければ到底Widgetには成れないわけだし。
>そして CORBA はそうでないところに問題があったと思う。
>あまりに OOL に便宜を図ったために可搬性が低下した、ということで。
いやー、CORBAは、重いから駄目なんだと思います。
OOP専門は不味いかも知れないけど、少なくとも参照ベースは譲れないです。
個人的には、sh(やそれと近い立場の言語)が、参照ベースに移行してくれたら、
なんとか戦えるかなーと。
#あとは、OOPなんてのは、動的な構造体っていうかHashtableが有れば、簡単に作れますからね。
#身近な例はJavaScriptでしょうか。
Re:パイプについての考え方 (スコア:1)
それが理想的なんですけどねぇ。
> たとえばshはデータ構造を作るのが絶望的に難しい(でしたよね)のですが、
> 日常的にはそんなものは作らない、と?
いやいや、なんだか話の流れでやっとわかってきたんだけど、
みなさん sh に対して「メモリ上のデータ構造が複雑にできない」と
言っているわけですよね?
でも、sh ってそもそもメモリ上で完結する言語じゃないでしょう。
ruby にしろ Java にしろ、XML を扱うためにはライブラリが必要。
同じように sh だって適当なコマンド群さえあれば XML だって扱える。
どの Unix でも標準的に head, cut, nawk, sed なんかはあるから、
リスト、木構造程度は標準的に扱えると見ていいし、
ハッシュテープルに至っては一時的な作業ディレクトリに
ファイル名をキーとしてデータを置くだけで実現できる
(まぁ本当にそれがハッシュテーブルとして実装されるかどうか
はファイルシステム依存なんですけど)。
もちろんこれを使っての OOP も可能。
ここ数年 sh でスクリプトを書くことも多いけど、
sh は日常的な問題の9割をすばやく解決できる実用的な言語ですね。
まぁきれいではないですが。
じゃあ実用的な意味で、何が sh の問題かといえば単純に速度の
問題で、その問題のうちのほとんどはプロセス生成と初期化の
オーバーヘッドにかかっている。
本来、「プロセス」というのは(単語の意味から考えても)
永続的な状態を保持しないものでしょう。
状態を保持するのは「ファイル」であって、
プロセスは処理のために一時的に状態の高速なキャッシュを
メモリ上に展開しているに過ぎない。
もしメモリ上にどうしても状態を置きたくなった場合、
プロセスは長期間稼動することになる。
使い捨てのはずのメモリに状態を乗せなければならないので
信頼性が必要になるし、そうするとプログラムの難易度は上がってくる。
で、G7 さんとしては
「メモリに状態を乗せるならプロセスの壁が要らない」と
いうことになるんだろうし、
俺としては「プロセスは状態を持つべきじゃない(=パイプだ)、
それは作業用か、高速化のためのキャッシュに過ぎない」
ということになるのかな。
> 長くなりましたが、こうして書きながら考えるとつまり、
> Pipeは「粒度が大きいもの専用」ってところかと。
> また登り下りを同時に捌けなければ到底Widgetには成れないわけだし。
粒度が大きいもの、関係が疎なものってのはそのとおりでしょうね。
まぁ「上り下りを同時に捌く」ってのはパイプが処理すればいい
内容かなぁと思いますが。
> 個人的には、sh(やそれと近い立場の言語)が、参照ベースに移行してくれたら、
> なんとか戦えるかなーと。
sh っぽい言語が参照ベースに…
いいですねそれ、おもしろそう。
# mishimaは本田透先生を熱烈に応援しています
Re:パイプについての考え方 (スコア:1)
>言っているわけですよね?
>でも、sh ってそもそもメモリ上で完結する言語じゃないでしょう。
完結しないからこそshは駄目だ、と言っているわけです。
>ruby にしろ Java にしろ、XML を扱うためにはライブラリが必要。
XMLは、構造の名前じゃなく、構造を使った製品(劇藁)の名前ですよー。
>どの Unix でも標準的に head, cut, nawk, sed なんかはあるから、
>リスト、木構造程度は標準的に扱えると見ていいし、
head, cut, nawk, sed(とsh)を組み合わせてツリー構造ですか?
どうやりゃマトモに記述できるのか、ちょっと俺には想像がつきません。
実際、プログラムを作ってる最中に「あ、これは(例えば)ツリーが必要な課題だったのだな」と気付いて
慌ててshからRubyに乗り換える、ってことが、俺は頻繁に有ります。
いや、アクロバティックにとか、非効率でもいいとか、ということでしたら捻り出せますけど、
ちょっと日常(そう!まさに日常的プログラムつくり)的には、パズルには付き合いたくないですね。
なお、子プログラム…たとえばawkとか…の「中」でツリーを表現できました、ってのはナシですよ。
それはshじゃなくawk言語がやったことですから、shの手柄にはカウントできない。
そしてそれは恐らくXMLについても言えることです。
>ハッシュテープルに至っては一時的な作業ディレクトリに
>ファイル名をキーとしてデータを置くだけで実現できる
>(まぁ本当にそれがハッシュテーブルとして実装されるかどうか
>はファイルシステム依存なんですけど)。
ハッシュ関数かどうかはInterface的にはどうでもいいんで、
辞書として有能(^^;かどうかについてのみ注目しますが、
○ファイル名の文字制限を受けるし、そもそも文字しかキーになれないし。
rubyのHashは任意のObjectがキーになれます。
○「一時的な作業ディレクトリ」の取り扱い。
以前にも言ったように、Filesystem上に置くとGlobalというか寿命MAXになっちゃうんで、
他の奴(ローカル変数的なもの)との干渉の心配とか、
ガベコレの心配とかを、しないとならなくなる。
という辺りが、ちょっと弱い。#まあ無名ファイルをサポートするようにOSが変身してくれればOKですが。
そしてもう1つ、致命的に、
○(オンメモリより)遅い
という…
ハッシュつーか辞書って、何か高級なものと世間では思われてるようですが、
本当は、数字添え字配列と同じ程度には「お子様でもわかる」もの
なんだろうと想像しています。
なので、もっと楽に(かつ低コストに)使える環境が増えて欲しいわけです。
小学生(?)の頃から辞書型に慣れ親しんで欲しい。
で、そうすると、ファイルじゃ重いっしょ、トリッキーっしょ、という話になる…。
ちなみに余談ですが、デバッグのためになら、あらゆるデータがファイルに落ちてくれるのはとても嬉しいです。
かったるいデバッガじゃなく軽便なsh(やExplorer?)で「データのかたち」が丸見えになるんだったら、こんな嬉しいことはない。
つーか、もしそれが一般化したら、GNU DataDisplayDebugger なんて不要ですよね(^^;
うーん。これは益々、無名ファイルやオンメモリファイル(藁)が有ってくれると嬉しいなあ。
#ある意味で、「ワンレベルストア」と紙一重かな。
>ここ数年 sh でスクリプトを書くことも多いけど、
>sh は日常的な問題の9割をすばやく解決できる実用的な言語ですね。
まあそれはツリーを書きたくなる度合いが何割を占めるか、というその人の事情に依存しそう。
#てーか、なんでこんなにツリーが多いんだろう?>俺
#あ、そうか。「プログラムつくりの支援」のためにRubyすることが多いから、かも。
>じゃあ実用的な意味で、何が sh の問題かといえば単純に速度の
>問題で、その問題のうちのほとんどはプロセス生成と初期化の
>オーバーヘッドにかかっている。
前提が崩れてるので既にアレですが、それにしても、オーバーヘッドは馬鹿にならんです。
ソース中の数万件の単語をぶん回すときなんか、いちいちsedとか起動してたら
マヂで10倍くらい処理時間が変わってしまうんで…
で、一方で、例えばRubyしか知らないユーザが、shしか知らないユーザに比べて、
なにか失っているものがあるか?ってーと、
("過去の資産"を除けば)あんまり無いんですよね。ここが味噌。
>本来、「プロセス」というのは(単語の意味から考えても
Re:パイプについての考え方 (スコア:1)
> といった感じで、ちっちゃい変更をどんどん加えていく方向でしか
> 実現はありえない、と思ってる。
それってメインストリームの変更方法じゃないですか?
言ってみればC言語的な。
わたしは、むしろ趣味だからこそ全く違うものをいきなり持ってこれるのだと思います。
具体的な手法は、その言語・環境で動くキラーアプリを作るって、オープンソースで配布する。
バイナリは自分好みの設定をデフォルトにして配布する。
そうすると、その設定が気に入らない人が出てくる。
ここで、じゃあソースからいじっちゃえ、という人が出てくれば言語が広まるはず・・・と。
コンパイル型だと難しいかもしれませんが、スクリプト言語ならこのモデルでいけそうな気も。
#OpenIrvine [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カード(つまりクラス)を参照するカード、
なんじゃないかなあ?