アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
今時の若いもの(藁)の意見 (スコア:1)
「OO言語を使うの必須だ」とは言ってません。
#俺もまたDQNかどうかは、さておくとして。
べつにLispでもいいんじゃないですか?
OOPというよりもどちらかというと、参照ベースの変数とか、GCとか、そっちのほうが
(気楽にプログラミングできるような高級な言語の)基礎としては大事な事柄で、
それこそCLOSみたいに、それらの仕組み(だけ)を駆使してライブラリレベルでOO言語風に仕立ててもいいんだし。
問題はshだとそれ「すら」旨くできない、という点だと思います。
OO「も」出来ない(やりにくい)。
そしてそれは、それ以外の色々なことも出来ない(やりに
Re:今時の若いもの(藁)の意見 (スコア:1)
まず、ご存じないような感じがするのでirbの紹介
http://www.rubyist.net/~matz/?date=20030815
これを使ってUnixのコマンドを呼べばかなりのことができそうに感じます。
Windowsでしたら、ActiveScriptRubyをいれれば、一通り遊べます。
http://www.geocities.co.jp/SiliconValley-PaloAlto/9251/ruby/
もっとも、Rubyからでは標準出力と標準エラー出力を同時に取れなかったと思うため、
完璧なものではないでしょうけれども。
###
個人的に「UnixのOOラッパーとしてのRuby」という言い回し
Re:今時の若いもの(藁)の意見 (スコア:1)
や、俺もよく判っていません。
このmishimaさんの数年来のm(__)m日記を手繰って読んでるだけです。
#そういや、日記へのコメントのページから、作者の記事一覧ページへ、行けるリンクが無いような…>スラド
>まず、ご存じないような感じがするのでirbの紹介
>Windowsでしたら、ActiveScriptRubyをいれれば、一通り遊べます。
あう。名前は知っていますが使ったことが無いもんで言及しませんでした。
そういやLispつーかSchemeな人々が時折言ってますね、
「いっそLispをコマンドラインにしたらどう
Re:今時の若いもの(藁)の意見 (スコア:1)
> 起動時に接続を決定せざるを得ず、後から切り替えることすら出来ない。
> こんなもんが「部品化」と呼べるのか?ってのは、かなり疑問です。
同意。
一番必要なのはその部分だと思ってます。
ま、着脱用の処理をするプロセスを一個はさんで
無理矢理着脱可能にしちゃえばいいと思ってるのですが。
(統一的にそういうものを扱うツールというのがいままで Unix に
なかったのが不思議)
> #GUIアプリの「fork」が見てみたいのでG7
> #やっぱり、同じ窓構成を持ったプロ
# mishimaは本田透先生を熱烈に応援しています
Re:今時の若いもの(藁)の意見 (スコア:1)
>無理矢理着脱可能にしちゃえばいいと思ってるのですが。
Unixのプロセスの管理形態とパイプとの関連性って、どうなってるんでしたっけ。
すみません、いまだによく判ってなくて。
つまり、親子関係だったかな?という話です。
Unixのプロセスって親子関係の縛りがキツイですよね。
親子関係自体を自由自在に乗り換えれるといいんでしょうけど、なんかそうじゃないようで。
つまり着脱をOSのアーキテクチャが許してくれるかな?という話です。どうでしたっけ?
OOPの場合は、基本的に親子関係なんてものはアテにしない、
ネッ
Re:今時の若いもの(藁)の意見 (スコア:1)
G7 さんは SysV 系統のアプローチなんですな。
俺は BSD なアプローチの方が好みです。あくまで感覚的ですが。
結局のところ、プログラム開発ってのは複雑性の管理に他ならんわけです。
で、その複雑性を誰が面倒を見るか、という部分で
安定性=障害耐性や保守性、可用性、移植性、性能、開発効率
なんかが変わってくると。
Unix は「複雑なもの(=ファイル構造のネットワーク化とか)は
面倒見切れん、必要ならあとはユーザ空間で工夫してやれ」と
切り捨てたところがプロダクトとして最も良い部分でしょう。
そんな Unix も多少の拡張はあるわけですが、
利用者(=アプリ開発者)にとっての機能重視で拡張する
アプローチはどちらかといえば SysV 風、シンプルに実装側に
とって分かりやすい形で拡張するアプローチが BSD 風だと
(勝手に)思ってます。
> Unixのプロセスの管理形態とパイプとの関連性って、どうなってるんでしたっけ。
> つまり、親子関係だったかな?という話です。
そですね。名前つきパイプでない限りはそうなります。
名前つきパイプについてはその後 G7 さんが書かれたとおり。
> つまり着脱をOSのアーキテクチャが許してくれるかな?という話です。どうでしたっけ?
基本的には OS は許してくれません。必要ならユーザ空間で工夫してやれ、と。
そしてそれはそんなに難しい話ではないでしょう。
> #これだと大量に使いたいときや動的に割り当てたいとき、名前の衝突を管理するという手間が増えて困る。
> #つまりNamedPipe風だが無名なPipeを(しかももちろん一般ユーザ権限で)作るのが楽でないと困る。
まぁ現実的には「アプリケーション側にはパイプに見える
ストリームだけど、実は TCP or UNIX ソケットの接続でした」
とかいうアプローチで十分だと思いますよ。
自分の書いた「プロセスを一個はさめば着脱可能」ってのも
その方法で実装してます。
もし本物のパイプでやるとしても、BSD 的アプローチなら例えば
「プロセス ID ごとのディレクトリを作って、その中に作ればいいんだよ~!」
「名前がかぶったら .1, .2, .3, ... みたいな拡張子をつければいいんだよ~!」
とか答えるところ。
> #そして、もしそれを作っても、今度は無名のソレを誰がいつ解放責任を取るか?っていう問題が発生する。
> #親プロセスが責任取るのか?でもそれじゃ結局親子問題が再燃だ。うーんうーん…
これも、BSD 的アプローチなら
「cron で定期的に使われてなさげなパイプを削除するプログラムを動かせばいいんだよ~!」
とか答えるところです。
> 問題は、アプリ設計者(?)が、「何が状態なのか」をどう考えるか、って点だけです。つまり設計ね。
> カーソル位置を保存するエディタと、しないエディタがある。その程度の差異です。
ここで開発者側と利用者側の視点の差が出てしまうところが
(GUI に限らず) UI のもってる問題じゃないかなぁ。
開発者「テキストエディタの『状態』はファイルだろう」
利用者「どのファイルを編集しているか、だって重要な『状態』だよ!」
みたいな。
うーん、基本的に俺が考えているのが「小規模」「バグあり」
「ユーザサイド」なアプリを対象に、
「エンドユーザがプログラムの修正を簡単に行うためには」
「ゼロからの実装を簡単にするには」
「再設計無しに(または変更を最小限に)大規模まで拡張するには」
みたいなことだというのが自覚できたような気がします。
# mishimaは本田透先生を熱烈に応援しています
Re:今時の若いもの(藁)の意見 (スコア:1)
いや、別に俺は「拡張」したいわけではありません。
必要な機能は欲しいし、不要ならば要りません。それだけ。
それがUnixと重なってる部分が有るか無いかってのは
俺としては関心事から比較的遠いです。
例えばProcess壁とかは要らないと思ってますし。
理由は前述のとおり。Process間通信の"必要"性は、Object間通信のコストを増やすだけだから(^^;
余談ですが
バッファオーバーフロー攻撃などの昨今の頻出を見れば、
Process間にさえ壁を作ればいいというUnix風の「セキュリティ」モデルは、
野暮ったいんだろうと思います。
もっと小さい単位…たとえばStringとかArrayとか…の不正使用を抑止するほうが
余程大事なんじゃないかと。
よーするに鯖プログラムを全部Java(笑)とかに置き換えたらどうよ?と。
#もちろんCベースでもそれらを実現する手段が幾つか有るようなんですが、
#どうせCではそれ以外にも苦労が多いんで、どっかでまとめてリプレースしたいなあと。
#ExceptionとGCのない言語環境で「アプリ」を作るなんて、もう嫌です(T_T)
あと、C主義の限界ってのもありますね。 C主義ってのは、
(記憶が正しければK&R2の冒頭の宣言ですが)プログラマは何をするかを自分自身で判ってる、という前提
です。
一見正当な主張に聞こえますが、
OOPの多態とか、Callbackとか、Closureとか、GCとか、といったもの(の恩恵)を考えると、
なんでもプログラマ本人に責任取らせようとすると、却って「プログラムモデルが」煩雑になる、
という側面があるように感じています。
if文の洪水を自分で管理するより、Objectに管理させたほうが良い、とか。
メモリ解放の複雑怪奇な手順(複雑なデータ構造では複雑な解放が必要ですよね)を機械任せにする、とか。
以上のことはOSじゃなくライブラリが出来る仕事かも知れません。
ですが、Process壁みたいに、「邪魔」なものもカーネルには有るわけで、
それを外すところまで視野に入れたいです。
Unixも、べつに必ずしもシンプルってわけじゃないと思います。
壁作ったり、色々大変でしょう。
むしろUnixユーザのほうが、Unixの各種機能を最早空気のように意識してない(ので「シンプル」だと感じる)
というだけのことだったりしませんかね…
>基本的には OS は許してくれません。必要ならユーザ空間で工夫してやれ、と。
>そしてそれはそんなに難しい話ではないでしょう。
どんな工夫が要るかをちょっと考えたんですが、概念的には結構すごい換骨奪胎だったりしませんかね?
親子関係を無くすためのラッパーは結局、
「shell配下の全てのProcessはshell直下の子にする」
ことになるんじゃないかと思います。
そして、子Processのstdin/outをPipe(のようなもの)に接続しちゃう。
これで、shellは必要(?)に応じてPipe同士のつながり関係を替えちゃうことが出来るようになる。
で、問題は、shellがやらないとならない仕事が結構凄くなっちゃうんじゃないか?という点でして。
まずマルチスレッドでないとならないでしょうし
(それともselect()で足りるだろうか?…待てよ、selectって後から待ち受け数を増減できないですよね??)、
接続関係の変更の要求を子Processから(当然shellへ)投げるための手段も考えてあげないとならない。
あ。新たなProcessの生成の手段も違ってきますね。"自分の"子(つまりshellの孫)を作っては
イケナイんだから。まあそういうのはLocalProcessとでも呼べば良いのかも知れませんが。
あと、出力のmergeとかみたいに、もうちょっと気の利いた世界を目指すなら、どうすりゃいいか
っていう問題もあります。
Unixの出力データフォーマットは「構造化」されてないので、
mergeといっても単純にbyte(または行)単位で混ぜる羽目になる。
で、単純に混ぜちゃったら意味不明データにしかならないから、無価値。
無論、混ぜたものを後から分けるのも無理。
混ぜるっていうか、複数の流れを「同期」したいときが有ると思うんですが、
同期のための手段がアプリ依存では価値が低い。全アプリ共通であって欲しい。
でも今のままだとお手上げ。
#往年のMacのMidiManagerってのが参考になりそう。
#Midiアプリ同士をそれこそPipeで繋ぎまくれる。稼動中も切り替えできる。
#なんとご丁寧に、MIDI信号入出力だけじゃなく、同期のために同期信号入出力ってのも有り、これも繋ぎまくれる。
#ちなみにMacなのでGUIでサクサク切り替え可能。
#翻って、現状のUnixアプリには同期信号入出力は無いしなあ(^^;
#改行とかを検知して同期信号をでっち上げるラ