アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、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のほうがやってることは複雑なので、
開発者と管理者、設計者の視点の違い (スコア: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]
ついでですが、開発をする上でも管理する上でも、例外をどう扱うかは結構重要で、
シグナ