アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
UNIX での代替品 (スコア:5, 興味深い)
UNIX だと、同様のことはテキストベースでコマンド+sh スクリプトということになりますが、もういい加減標準 sh 用シェルスクリプトを書きたいとは思えないとか、テキストのパーズで思いもよらぬバグに直面したりとか、とても21世紀の環境とは思えない。
一方で、例えば常に irb (Ruby の対話シェルみたいなの) の中で生きていく、というような手法もあるかもしれません。irb のコマンドプロンプトを普通のシェルのようにして、一通りのコマンドを用意すれば、多分生活に充分なシェル環境が作れるし、スクリプトを書く上では sh よりはるかに優れた言語を使うことができます。問題は他のアプリケーションとの連携ですが、bonobo との通信をサポートするといった、かなり面倒そうな解決方法しか思いつきません…。
Re:UNIX での代替品 (スコア:5, 参考になる)
オライリーのPython本の中で、そのような使い方が提示されてた記憶があります。
Pythonは、引数なしで起動すると、対話シェルなので。
Monad改めWPSが、従来のUNIXシェル+パイプと大きく違うのは、MSのドキュメントにある
> Windows PowerShell では、パイプラインのコマンド間でデータを受け渡すのに、テキストではなくオブジェクトが使用されています。
ってところだと思います。
UNIXシェルだと、パイプはバイトストリームなので、上流のプロセスが、出
KISS という言葉がありますが (スコア:2, 興味深い)
>
> パイプの段数が深くなるほど、後者の方がパフォーマンス的に優位だと思います。
そのかわり、バイトストリームなら簡単に実現できた可用性
(ファイルに保存して別ホストに転送とか)や互換性(.NET 以外のフレームワーク、
たとえば ruby とか java とか)がなくなるんじゃない?
それに、 OS と違って、VM ってまだまだ安定しているとは言いがたい。
一つの VM にあんまり依存しちゃうのは、信頼性の面から見てちょっと心配なところがある。
大抵の場合は、単純なシステムを高並列化して性能を上げる方が
簡単だし障害が少ない。
ほんとに、そんなパフォーマンスが重要な局面ってあるのかなぁ?
かえって保守不能な複雑化を抱えこんじゃう気がしないでもない。
#でも保守不可能な難解プログラム書くの好きな人多いんだよなー
# mishimaは本田透先生を熱烈に応援しています
それはKISSではない (スコア:1, 興味深い)
挟まる必要がなく「素通し」することが出来るアーキテクチャより、
フクザツなんじゃないでしょうか?
むしろUNIXが、プロセスという考えかたに拘泥した副作用ですよね、伝統シェルのマーシャリング必須性(という複雑さ)は。
その縛りをなくしてあげよう、というわけなんじゃないでしょうか?>PowerShell
既存のシェルのやりかたを「単純で愚直」だと思うのは、単なる刷り込みじゃないでしょうか?
>単純なシステムを高並列化して性能を上げる方が簡単だし障害が少ない。
というわけで、UNIX shのほうがやってることは複雑なので、
仮に他の条件が全部同じなら、PowerShell方式のほうが勝つんじゃないでしょうか?
これは予想というよりは経験的事実ですね。
当たり前といえば当たり前なのですが、おおむね同じ処理を
Rubyなどの高機能Script言語で書くと
結構高速に処理できるんだけど、
sh(とコマンドPipeline)で書くと
やっぱりいちいち文字列にしてIOを通すせいか、
凄く処理に時間がかかる、
っていうものは多いです。
grepもsed(gsub)もbasename/dirnameも
何から何まで子プロセスに振ってたら、
そりゃやっぱり重いわけですよ。
>そんなパフォーマンスが重要な局面ってあるのかなぁ?
うん。それは確かに少ないです。
ただし、そのトレードオフを悩むべきなのは、「パフォーマンスのために扱いやすさが犠牲になる」場合ですよね。
軽い奴が扱いも別に全然難しくないなら、諸手を挙げてソッチを使えばいいんです。
PowerShellの考え方、なにか難しいですか?
私もshにはすっかり馴染んでる人間ですが、それでも、
sort の引数で
「ええとソートさせたい部分は何カラム目だっけな」
と文字数を数えたり、
ls -lの出力から
「ファイル名とサイズだけを抽出するのは、ええとどういうgrepやsedをすればいいんだっけ?」
と正規表現を思い出す(正規表現も私は馴染んでいますが、それでもね)
っていう手間を考えると、
ソート要素やファイルサイズをカラム名で一撃で選択できるPowerShellのほうが遥かに理解容易だと思えます。
いやほんと、生Objectをやり取りするというドラスティックな変化は我慢するとしても、
やり取りするデータにカラム名がついてるっていう点だけでいいから、
今すぐに見習いたい!と思いました。
だって、データにカラム名もついてないということは、
我々のshのコードの中身はマジックナンバーだらけだった、
ということなのですから…。
>バイトストリームなら簡単に実現できた可用性(ファイルに保存して別ホストに転送とか)
きっとVistaではObjectがファイルにも
そのまま保存できるようになるのですよ!(違
別ホストですか。気にしてないんじゃないですか?
MSはPowerShell(.NET)で地続きにならないOSなんか
OSに非ずと思っているでしょうし、
そういう必要な場合だけマーシャリングする
(しかも何時必要なのかの判断は隠蔽されて自動化される)
というようなCmdletを作れば済むことでしょうし。
>ruby とか java
前述のように外部コマンドのラッパーは
マーシャリングで解決してもいいですし、
あるいは逆にRubyやJava側に拡張を突っ込んで
PowerShellのオブジェクトを直接食べれるようにしてあげる
っていう手もありそうですよね。
DotNetSystem.out.print(object1);
なんて書けるようにクラスDotNetSystemを書けばいいんです。
便宜というか慣れにあわせてprintと書きましたが、
実際にtoStringする必要があるかどうかは
このoutオブジェクトが知っている、ってわけです。
ああ。あれですよ。
標準入出力2.0
とでも呼べばいいんじゃないでしょうか?
出力するときに何でもかんでもtoStringするという
画一方式から脱却するのですから、
なんか本当に2.0っぽくありませんかね?
開発者と管理者、設計者の視点の違い (スコア:1)
プログラムが暴走したとき最小限の被害で止める方法が
確立されてなかったり、バージョンごとで違ったり、
VM ごとで違ったり、被害がでかかったり。そういうのを管理するのはつらい。
C 言語やシェルスクリプトは、そこで悩む必要がない。
> >そんなパフォーマンスが重要な局面ってあるのかなぁ?
> うん。それは確かに少ないです。
> ただし、そのトレードオフを悩むべきなのは、「パフォーマンスのために扱いやすさが犠牲になる」場合ですよね。
いやいや、システム管理のことも、さらに上流のことも考えてほしい。
システム管理ではまだ枯れてない .NET を扱うのに手間がかかる。
システム設計では、複数のアーキテクチャを同時に扱う状況がよくある。
この状況は 10 年経ってもあまり変わらないんじゃないだろうか。
そういう状況の中での、VM への集中を促す、この Windows Power Shell の試み。
こりゃ、Windows 全体を、OS ではなく VM と考えて、
TCP/IP というストリーム経由で入出力を行え、ということなんじゃないだろうか。
Windows そのものが、一個のプログラムという考え方。
Xen とかの仮想環境で、プロセスを起動するように Windows を立ち上げる。
そこまで含めての「標準入出力2.0」なのかも知れない。
問題は OS のライセンスかな…
# mishimaは本田透先生を熱烈に応援しています
Re:開発者と管理者、設計者の視点の違い (スコア:0)
そもそもそうそう暴走しますかね?
>C 言語やシェルスクリプトは、そこで悩む必要がない。
●C言語は暴走します(^^;
●よく言われる話ですが、暴走を食い止めることが出来るわけじゃなく、
暴走すればお客様の玉稿(データとかコンテンツ)は結局失われるのです。
プロセス保護を以って「最小限の被害」なんていう言い草のほうが余程、
最も上流(お客様)の視点を理解してないのじゃないか?と
しばしば思います。
そういう意味では「Cは悩む必要がない」ってのは酷い話。
#どっちかっていうと現状の多くのケースでデータの安全を最終的に担保してくれてるのは、Databaseですよ
Re:開発者と管理者、設計者の視点の違い (スコア:0)
> #どうせFilesystemにはCommit/Rollbackも無いんです。
> #それで安全性云々言ったらDBに鼻で笑われてしまう。
オフトピ失礼。
Vista からですがNTFSにCommit/Rollback が実装されます。
TxF vistaの検索結果 [google.com]
ついでですが、開発をする上でも管理する上でも、例外をどう扱うかは結構重要で、
シグナ