アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
今時の若いもの(藁)の意見 (スコア: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 も多少の拡張はあるわけですが、
# 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アプリには同期信号入出力は無いしなあ(^^;
#改行とかを検知して同期信号をでっち上げるラッパーProgramは作れるかも知れませんが。
あと、根本的な問題として、OOPに出来てProcessに(工夫しないと)出来ないこととして、
複数のメソッドの存在があります。
内部状態に対するアクセス手段が「複数」有るかどうかって話。
#餓鬼のころ、これのせいで、C言語のLocal Static変数で悩まされました。
Pipelineなんだからソコまで期待するなっていう話もありますが、
そもそも状態が気にならないならPipeの実行時着脱なんて不要(誰も悩まない)なんですし。
なので、そもそも、次世代Pipe(?)を実現してドレだけ嬉しいか?というのは未知数。
>開発者「テキストエディタの『状態』はファイルだろう」
>利用者「どのファイルを編集しているか、だって重要な『状態』だよ!」
それはLisp的(?)に考えればいいんじゃないかと思っています。
というか伝統的な言い方をすれば設定ファイル。
(エディタプログラム名 設定ファイル名 データファイル名)
みたいな。
#GUI的には、設定ファイルとデータファイルをまとめてDropとか、
#DblClickの際のデフォルト設定ファイルを決めとくとか、することになるでしょうね。
そんなの当たり前じゃないかと思われるでしょうけど、これが意外と理解されてない。
たとえばブラウザ(少なくともIE(藁))は、複数窓を同時立ち上げすると、
しばしば、 Cookieとかによるwebサイトへのログイン状態(コンテキスト)を「区別」できなくなる。
(Webアプリの終了後に「ブラウザ窓を"全部"閉じてください」と要求するWebアプリがしばしば有る。)
これも上記のような手で解決できるだろうと思っています。
(ブラウザプログラム名 コンテキスト記録ファイル名 起点URL)
とすればいいじゃん?
こうすれば、たとえ同じURLなWebアプリに対してでも、別セッションでログインできる筈…なのに。
(少なくとも俺には)プロセスの壁はどうでも良くなりました。
#余談ですが、IEを強制終了するとき、窓単位じゃなく全IE窓が一斉に落ちるのも、むかつきます。
問題は、じゃあそれ以外の壁は要らないのか?という点だと思います。
例えば上記は、コンテキスト単位で仮想的な壁が有るようなものです。
>うーん、基本的に俺が考えているのが「小規模」「バグあり」
>「ユーザサイド」なアプリを対象に、
>「エンドユーザがプログラムの修正を簡単に行うためには」
>「ゼロからの実装を簡単にするには」
>「再設計無しに(または変更を最小限に)大規模まで拡張するには」
>みたいなことだというのが自覚できたような気がします。
それ、誰もがそうだったりしませんか?(^^;
ちなみに「規模」という概念は、どこで切るか?という問題が常につきまといます。
例えばOS(やライブラリ)が無ければ我々の大抵のアプリは動きません。
OSは大抵大規模です(偏見?)。
一方OSが高機能なら恐らく我々のアプリ自体のコードは小さくなるでしょう。
これは大規模なのか小規模なのか?ってのは、
線をどこに引くかによって違ってきます。
というか、階層ですね。
個々の階層は小さい(薄い)けど、稼動するまでの全部をいっぺんに見れば結構分厚い。
ところで、OOPやLispだと、層という言葉が馴染むかどうかは微妙だと感じてます。
層構造じゃなくNetwork構造をしばしば使うという意味でもそうですし、
やれCallbackだTemplateMethodだClosureだ(実は全部同じもんですが)とやることで
IoC(Inversion Of Control)は頻繁に発生するわけで。
またInterfaceのせいで依存関係(≒層関係)も間接的にぼかされますし。
#書籍「オブジェクト脳の作り方」に、
#単純な上意下達ツリー構造を成すC言語関数方式よりも、Network構造とInterfaceによって層を崩すOOPのほうが
#変更に強いぞ、とかいう主張が有ったと記憶しています。
まあ、規模を測る単位は、層でなくてもなんでもいいんですが。