昨日ネットを眺めていてPowershellに若干否定的な話しが載っていたので検証してみた。
まぁ、1.0の頃の話なので当時は今ひとつな部分もあったのかもしれないが。(私自身はすでに記憶があまりない)
否定的な部分を纏めると
- 無償の開発環境が無い
- function呼び出しの文法が違う、間違ってもエラーにならない
- 存在しないプロパティを参照してもエラーにならない
- else ifとスペースを開けるとエラーになる
- エスケープの文法がC#と違う
- ExcelのOpenが使えない
- 慣れた言語で開発したほうが早いのでPowershellを様子見のほうが良い
とこんな感じでしょうか。
ちょっと検証してみましょう。
- 開発環境についてはすでにISEが標準添付されていますので問題は無いでしょう。(現バージョンでは確かにインテリセンスとまでは行きませんがV3に期待しましょう。そもそもC#だって最初は無償の環境はなかったような・・・。)
私もいつもお世話になっているPowerGUIもありますし。
個人的にはタブ補完だけでもそれほど苦痛では無い気がしています。
オブジェクトメンバーなども、”aaa”.とやると確かに何も出てきませんが一旦変数に入れてやれば(要は実行されれば)問題なく表示されます。
私などは逆にC#を使っているとGet-Menberしたくなります。(^^; - function呼び出しについては確かに最初は紛らわしいかもしれませんが()が不要というのはタイプ量が減るので慣れればメリットでは無いでしょうか。C#などもバージョンを重ねるにつれタイプ量を減らす方向になっていますし。
また、間違ったときにエラーにならないというのも、要はPowershell的には間違っていないのだから仕方が無いとも言えます。
Powershellの引数は明示しなければオプションなので省略可能です。
なので引数を2つ指定したつもりのmyFunc($a,$b)というのは最初の引数に変数aとbの配列、2つめの引数は省略と解釈されてしまいます。
逆に、C#な人であれば変数にちゃんと型指定をすればエラーになると思いますし。 - これについては、逆にそのことによって多大な恩恵を受けているのでトレードオフでしかない。
また、現時点では「Set-StrictMode -version 2.0」とやるとそこら辺をチェックしてくれる。この設定をして、ファイルとフォルダが混在した場所で
dir | %{$_.length} とやってみた上で判断すると良いかもしれない。 - これはC#でThenと書くとエラーになるのは許せんというのと変わらないような・・・。
- Powershellはファイルを扱うことが多いのでパスの区切り文字に使われる¥を避けたは懸命では無いでしょうか。
- これは現時点では大丈夫な気がしますし当時でもPowershell自体の問題には読めなかったのですがどうなのでしょう。
- これについては、自分でBESTと思うものを使えば良いのだと思います。
ただ、部下に「このフォルダのファイル一覧をテキストに落としといて」と頼んでC#でプログラミングし始めたら「おい、おい」と言うとは思いますが。
よく言われることですが「銀の弾丸」は存在しないわけですから、適材適所で道具を使い分けるのが肝心と言う所ではないでしょうか。
どこにどの道具を使うかを見極めるのが技術者としての1つのスキルだと思います。
あくまでも個人的意見ですが、Powershell好きとしてちょっと擁護してみました。
私も使い分けすべきという意見に同感です。
返信削除よく「コマンドレットを一つも使わないスクリプトは別の言語で書いた方が幸せになれると思うよ」と言って回っています。
元々PowerShellの作られた目的が、Windowsサーバー/サーバーアプリの管理のためのシェルおよびスクリプトなので、その用途から離れれば離れるほど使いづらさが目立ってくると思うのです。
たとえばテキスト処理ならRubyなど他の言語の方が得意ですしね。
やはりPowerShellは各種コマンドレットを使った上で、それだけで処理しきれないところは各種構文や.NETクラスで補完するという使い方が本道かと思っています。通常用途ならばコマンドレットだけで完結するように作られてますし、そのためにプログラミングに精通していないITプロ、管理者の方がメインターゲットであるわけですし。
基本的に設定ファイルがテキストではないWindowsだからこそ登場した新しいシェルなので、その本来の役割通りコマンドレットを使って設定の取得設定、機能の実行をやらせることでPowerShellは輝くのかなと。
本来の用途と離れた用途で使って「使いにくい、つかえねー」と言ってる人があまりに多くて悲しいです。
UNIXシェルのWindows版代替として使おうとしてる人に特に多い意見です。
もっともWindows7というクライアントOSに標準搭載され、Windowsサーバー管理者ではないユーザー(でもローカルPCの管理者ではあるわけですが)の目に触れる機会が増えたのも原因なので仕方ない側面もあるのですけどね。これはPowerShellの知名度を上げるための施策でもあったんでしょうが、ちょっと裏目に出てる感もあります。
そういえばこの元記事では-match演算子の挙動がバグっていると指摘されていましたが、
$matches変数は最初のマッチと最初のマッチのサブパターンを格納した連想配列であるので、
他のマッチの値が得られないのは仕様だったりします^^;
というのはご本人に伝えたような気もしますが忘れました^^;