アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
今時の若いもの(藁)の意見 (スコア:1)
「OO言語を使うの必須だ」とは言ってません。
#俺もまたDQNかどうかは、さておくとして。
べつにLispでもいいんじゃないですか?
OOPというよりもどちらかというと、参照ベースの変数とか、GCとか、そっちのほうが
(気楽にプログラミングできるような高級な言語の)基礎としては大事な事柄で、
それこそCLOSみたいに、それらの仕組み(だけ)を駆使してライブラリレベルでOO言語風に仕立ててもいいんだし。
問題はshだとそれ「すら」旨くできない、という点だと思います。
OO「も」出来ない(やりにくい)。
そしてそれは、それ以外の色々なことも出来ない(やりに
パイプについての考え方 (スコア:1)
「結局どうやってこの分野に改革を起こすのか」というのがある。
つまり、
「ロードマップはできたけど、どうやって実装しよう」
「実装は終わったけど、どうやってみんなに使ってもらおう」
というところがある。
この問題に対するアプローチのやり方はいくつかあると思うけど、
趣味のプログラミングとしては、「現状+α+α+α+…」
といった感じで、ちっちゃい変更をどんどん加えていく方向でしか
実現はありえない、と思ってる。
そういった意味で、G7 さんの意見はしきいが高く感じちゃうなぁ。
で、そういった意味からすると r
# mishimaは本田透先生を熱烈に応援しています
Re:パイプについての考え方 (スコア:1)
うーん。Macみたいに「魅了する」って手を使いますかね(藁
>実はプログラミング言語の機能の問題ではなくて、
>それを取り巻く環境(=インストールされていない、実績がない、経験者が少ない、規模が大きい…)だ、
規模については、shだって別に小さいわけじゃないと思います。
きちんと(つまり意図通りに)動かすために覚えないとならんことは、結構多いと感じてます。
俺はshとかを覚えたのが結構後から(CやDelphiより後)だったもんで、後から覚える手間(^^;をかけたわけです。
まずshありき
Re:パイプについての考え方 (スコア:1)
それが理想的なんですけどねぇ。
> たとえばshはデータ構造を作るのが絶望的に難しい(でしたよね)のですが、
> 日常的にはそんなものは作らない、と?
いやいや、なんだか話の流れでやっとわかってきたんだけど、
みなさん sh に対して「メモリ上のデータ構造が複雑にできない」と
言っているわけですよね?
でも、sh ってそもそもメモリ上で完結する言語じゃないでしょう。
ruby にしろ Java にしろ、XML を扱うためにはライブラリが必要。
同じように sh だって適当なコマンド群さえあれば XML だって扱える
# 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しか知らないユーザに比べて、
なにか失っているものがあるか?ってーと、
("過去の資産"を除けば)あんまり無いんですよね。ここが味噌。
>本来、「プロセス」というのは(単語の意味から考えても)
>永続的な状態を保持しないものでしょう。
ああ。それはそうだと思います。
#だからviを「プロセス」で実装するのは邪道なんだよな。
#でも、じゃあエディタ(不可欠です)をどう実装すれば良かったか?というと、
#Unixは何も答えてくれないのね。
ただ、それはあくまでUnixが作られた「時代」の
ハードとかのバランスに立脚してるんだと思います。
つまり高速メモリ(揮発だけど)が悲劇的に希少だったとか、
DiskとCPUの速度「比」が今ほど悲劇的に開いて「いなかった」とか。
つまりDiskを使うことの優位性が(相対的に)今より大きかったんじゃないかと。
翻って今は、CPUとメモリの時代だと思います。
Diskも勿論健闘していますが、CPUに比べれば以下略。
まあ速度はキャッシュを使えばいいという話も有りますが、
ここでもう一方の足(?)を引っ張るのが、
昔考えられたUinxというアーキテクチャの、ファイルが無名じゃない(よね?)という足枷。
昔のバランスなら、それが絶妙の設計だったのかも知れないけど、
今だとどうかなーと。
>状態を保持するのは「ファイル」であって、
>プロセスは処理のために一時的に状態の高速なキャッシュを
>メモリ上に展開しているに過ぎない。
Unix的な理想をいえばそうですが、それを下支えする道具が弱すぎるんですよね。
例えば、じゃあなんで、C(やアセンブラ)から
Globak変数を(少なくともUnixで使うときには)排除してないのか?とかね。
そんなの悪用されるに決まってますよね。 viとかRubyとかにさ(^^;
#実のところ今俺マヂで、Global変数禁止なFrameworkの仕事(開発)してます。
#状態は全部、ファイルならぬDBに落とすしかない、という代物。
#そして所謂処理は、ラップされてますか突き詰めれば、それこそUnixのProcessです。
#で、使い心地や処理能力はというと…うーん(^^;
>使い捨てのはずのメモリに状態を乗せなければならないので
>信頼性が必要になるし、そうするとプログラムの難易度は上がってくる。
信頼性について言えば、所謂DBを知ってしまうと、伝統的なFileって笑うしかないです。
Transactionも無いじゃんか、という点で。
あと、メモリ扱いの信頼性や難易度といえば、その半分(^^;は
GCが有れば「自動的に」解決しちゃうんですよね。
ちょうどFileSystem上で消費したセクタ(ってんだっけ)の数を我々が意識せんで済むのと同じことを
GCはメモリに対してやってくれる。
GCという意味で、それを(最初に)フルに活用したLispは偉いし、
逆に、GCが有るだろうにそれを「多彩なデータ構造」のためにユーザへ解放しなかった
(つまり固定構造の変数とか文字列とかとして使うのにしか解放しなかった)
shやBASIC(^^;は、痛い言語なんです。
>俺としては「プロセスは状態を持つべきじゃない(=パイプだ)、
>それは作業用か、高速化のためのキャッシュに過ぎない」
○実際遅くてたまらないよ。
○ファイルで構造もたせるのなんて世間でロクに見たことないやん。それだけ非力だっていう傍証では?
ところで、ファイルで構造といえば、
ファイルにポインタ…つまり他のファイルのファイル名とかI-NODEとか…を
埋め込むのもUnixはサポートしていませんね。
まあアプリレベルでやれということなんでしょうが、
つまり構造のサポートは何もしてないわけで。
#ん?B-TRON?
で、それで本当に良かったのか?というと微妙に疑問です。
構造「製品」は無論OSにサポートさせるべきじゃないですが、
構造のためのインフラはOSがサポートしてても良かったろうに…。
>> また登り下りを同時に捌けなければ到底Widgetには成れないわけだし。
>まぁ「上り下りを同時に捌く」ってのはパイプが処理すればいい
同じ場所に戻ってくる(電気楽器用語でいえば Send-Return)のは
伝統的Pipeでは無理ですよね。閉路(ってんだっけ?)のあるPipelineを作れない。
まあ一連の改良案を実現すればいいんでしょうけど。
そうそう。Pipeで「再帰」をどう実装するか?ってのも問題ですね。
#背を向けるのは簡単ですが、それじゃBASICと同轍ですし。
起動していちいち終了してたら重くてたまらないし。
改良案を使って同一Processにデータを循環させるようにしたら、
データの「構造」がないUnix方式により、再帰の終端がわかるかどうか不安だし。