アカウント名:
パスワード:
https://x.com/Linda_pp/status/1847835220076384356# CHAR_BITが9の処理系もあったなぁ(GE-600シリーズとか)
ところで、皆さん、8進数使ってますか。
私は全く使わないのだが、ウィンドウズコマンドで、もどかしい。ゼロパディングした文字列と言うか数値が8進数になってしまうので、いろいろ不便。8進数に対応してなければ、気軽に0パディングの処理ができたのに。
Windowsを使って長いですが、0付きのリテラルを8進数として解釈する(余計な)機能なんてあったんですね。
PowerShellの恩恵には充分与っているつもりですが、全くPowerShellの機能を必要としないシチュエーションでは(exe実行したいだけとか)気持ちリソースをケチりたくてcmd.exeを使っちゃったりします。
# PowerShellの数値リテラルはいくつか機能盛ってあるみたいですが、それでも8進数リテラルは採用しなかったのは良い仕事と思います
CMD.exeは、今となっては何のメリットもないシロモノなので、今更論うのも可哀そう、って気がしますけどね。消費リソースの少なさはメリットですけど、そんなにリソースが気になるならもっとモダンなPC使いなさいよ、って話ですよね、今となっては。8進数問題だって、Powershellやbash程度の文字列処理ができれば何ら問題ないわけですが、CMD.exe(の前身のcommand.com)が生まれたときの標準的なPCを考えれば仕方ないことだった気もしますしね。しかも、CMD.exeの一機能であるsetコマンドの機能を論って「Windowsは」みたいに批難するのは、不当すぎてWindowsが可哀そう。
消費リソースの少なさはメリットですけど、そんなにリソースが気になるならもっとモダンなPC使いなさいよ、って話ですよね、今となっては。
そうは言っても、CLIのツールをPowerShellの支援も特に求めず実行するだけなのに、PowerShell経由はなんかなってのはあって。あと "powershell" ってタイピングが若干だるいのもあるかな。"wers"あたりとか。(昔入れ込んだ時はposhとか別名を作ったりしたこともあったかなあ?)
> CLIのツールをPowerShellの支援も特に求めず実行するだけなのに
心情的にはすごく理解できるんだけど、PowerShellもCLIの実行環境のひとつにすぎないので「shで十分なことをするだけなのにわざわざbashを使うのはなんかな」と言っているようなものですよ。
MS-DOSからの因習を引きずっているCMD.exeはもう限界が近いから、モダンなCLI実行環境としてPowerShellを作ったのはすごく納得できるし、.NETの機能をかなり使えたり、最初から強力な補完機能があるから「長いけど意味が明確なコマンド(レット)名」を使うようにしたり、個々のポイントは支持できるものが多いんだけど、その代償として複雑でわかりにくい文法、膨大すぎて何があるのかわからないコマンドレットなど、絶望的なとっつきにくさで投げ出した。
その代償として複雑でわかりにくい文法、膨大すぎて何があるのかわからないコマンドレットなど、絶望的なとっつきにくさで投げ出した。
CMD.exeの文法の方が複雑怪奇すぎて覚える気にならないけど。CMD.exeの文法を覚えることができる人なら、Powershellは難しくないと思うけどなぁ。
ヘルプやキー入力補完だってPowershellの方が強いし。
つか、exeの実行環境として使うなら、追加でPowershellの制御構文を覚えれば十分じゃね?無理にたくさんコマンドレットを使う必要もない。
いやその、ぼくは#4609555と違ってCMD.exeの代替としてPowerShellを使うことはあまり考えてないというか、それが目的ならかなりコマンド体系が違うものをわざわざ学習するほどの価値は見ていません。OSのシェルとしてCLIを使う頻度がかなり低いので割に合わない。
でもってCMDでは貧弱すぎるけどプログラムをビルドするほどでもないワンライナー的な処理をしたいときにPowershell使えるかな?と触ってみたけど投げ出した。オブジェクトのインスタンスを別のコマンドで加工して…みたいなことができるのはわかったけど、パイプ処理も可能だったりで構文が複雑すぎる。構文として意味を持つ英記号多すぎてなにやってるかわからない。Powershellの解説記事とかみても「こうすればOK」的なものはあってもゴチャゴチャ出てくる記号の意味の解説があまりない。そういう記号の意味を網羅的に日本語で説明したものが(あるのかもしれないけど)みつからない。.NET準拠だけどいちいち名前が違うので利用したい機能がPowershellではどういう名前でどういう機能があるのか調べなおさないといけない。全般的に(慣れれば気に入るかもしれないけど)最初の学習コストが高すぎ。
そしてREPLが登場してC#をコマンドライン風に使えるようになったこともあって、Powershellを使ってみたいという気持ちはほぼゼロになっちゃいました。
まあ簡単に言えば個人的にPowerShellを使わない理由は「Powershellの制御構文がわけわかんないってだけで十分じゃね?」ですね。
「英記号」ってのが何を指してるかわからないんだけど、CMD.exeの「英記号」だってなかなか複雑怪奇じゃない?「%」が一個で済むのか二個必要なのか、「CON」ってなんですか、とか。
リソースが乏しかった時代に、屋上屋を架す形で拡張されていった統一感のないcommand.comの文法を引き継いでしまったから仕方ないわけだけど、それよりはPowershellの方がスッキリしている。
とはいえ、オブジェクトがパイプを流れていくとか、その出力が、配列・単体のオブジェクト・nullの三通りに分かれることがあったり、それを統一するための@()オペレータとかは、確かに理解しにくく、もうちょっとどうにかならなかったのかとは思うね。
まあ簡単に言えば個人的にPowerShellを使わない理由は「Powershellの制御構文がわけわかんないってだけで十分じゃね?」
なんだろうなぁ。新しいものにチャレンジしない理由を探してるだけに見えるなぁ。Powershellって、パイプとかモナドとかが注目されがちだけど、それらを使わなくても書けるし、一般的な制御構文、forループ・whileループ・foreachループ・ifやswitchによる条件分岐などは、他の言語とほぼ同等に書けるし、無理に理解しづらい構文を使う必要はないんだよね。
比較演算子が難しいといえば難しいんだけど、これはBashと似た感じで、書いているうちにすぐ覚えることができる。
そういえば思い出したけど、とある仕事でBashスクリプトを書いたら、「キミの書くプログラムは難しい構文をつかってあって読めない」と言われて書き直したことがあったな。ちょっとした変数展開(${parameter#word}など)とか、IFSで区切り文字指定してreadで読み込んだりとかしたんだけど。これらも覚えるのは難しい「英記号」かもしれないけど、man bashで調べれば済むこと。しかし、それすらしない・できない人もいるのも否定しがたい事実なので、そういう人たちに合わせてあげたっけ。
でも、こいつらオレより若いくせにraw guyやな、とは思ったね。
> CMD.exeの「英記号」だってなかなか複雑怪奇じゃない?
複雑怪奇だね。あれも正直気に入らないんだけどそれがやたら増えた。それでも昔ならバッチ使った方が楽だから受け入れたけど、今だと他の選択肢も多いから複雑怪奇なものを新たに学習するのが見合わなくなった。
> オブジェクトがパイプを流れていくとか
そういうとこだね。オブジェクトをパイプで受け渡しできるとワンライナーでやれることが増えるぞ!は確かに素敵だし正常進化だと思うけど、それを実現したものを見ると「なんじゃこりゃわけわからん」になってしまう。
> 新しいものにチャレンジしない
外部コマンドの標準出力をコマンドレットにパイプすると何GBでもいったん全部バッファリングする仕様はさすが改善されたん?
それはスクリプトの書き方が悪いのかもしれないし、そのコマンドレットの実装が悪いのかもしれないし、PowerShellの問題かもしれないから、もっと具体例を出した方がよい。
ping localhost -n 10000 | %{"Ping> $_"}
これはpingのプロセスが終わるまで結果が出力されないなんてことはない。
何かコマンドレット使わなきゃ例にならないか。
ping localhost -n 10000 | %{"Ping> $_"} | Out-GridView
何をもって「なんじゃこりゃわけわからん」「猛烈なとっつきにくさ」と言ってるか、よくわからないんだけど…
読んでいて思ったんだけど、なにかPowershellのことを(ほぼ)完璧に理解してからでないと使いたくない、みたいな感じになってない?
Powershellでは、CMD.exeでやるような、外部コマンドを呼び出すプログラムは普通に書ける。かつ、一般的な制御構造も準備されてて、CMD.exeみたいな奇妙な構文でもない。その範囲で使っていれば、「なんじゃこりゃわけわからん」「猛烈なとっつきにくさ」とはならないじゃない?それでいて、CMD.exeより文字列処理や数値計算はより素直に書けるわけだし。
確かに大量にあるコマンドレットをすべて覚えるのは難しい。私もそんなことはできない。でも必要になったものから順に覚えれば十分。コマンドレットを探すには、Get-Commandを使えるし、個別のコマンドレットの使い方は-?オプションか、Get-Helpを使って調べる。なんなら、引数を入力する場所で、-の後に[TAB]を打って、どんな名前の引数があるか見れば、ざっくり想像がつく場合も多い。オブジェクトがどういう機能・プロパティを持っているかは、Get-Memberを使う。どうしてもコマンドレットを覚えたくなければ、同機能のexeを使ったってかまわない。そういう流儀なんだよ。
その言語の(ほとんど)すべてを覚えないと気が済まない、という人には、確かにPowershellは向いていない。しかしそれは、現代的なプログラミング言語全般に言えることなんじゃない?
何しろ昔の、powershell coreが5ぐらいのことなんでいまいち覚えてないんだが、バイナリのストリームを読んだ時のことだったと思うググったらstack overflowにも仕様だよて書いてあった気が
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
C++で、1バイトを8ビットにする提案がされる (スコア:1)
https://x.com/Linda_pp/status/1847835220076384356
# CHAR_BITが9の処理系もあったなぁ(GE-600シリーズとか)
Re: (スコア:1)
ところで、皆さん、
8進数使ってますか。
私は全く使わないのだが、
ウィンドウズコマンドで、もどかしい。
ゼロパディングした文字列と言うか数値が8進数になってしまうので、いろいろ不便。
8進数に対応してなければ、気軽に0パディングの処理ができたのに。
Re: (スコア:0)
Windowsを使って長いですが、0付きのリテラルを8進数として解釈する(余計な)機能なんてあったんですね。
PowerShellの恩恵には充分与っているつもりですが、全くPowerShellの機能を必要としないシチュエーションでは(exe実行したいだけとか)
気持ちリソースをケチりたくてcmd.exeを使っちゃったりします。
# PowerShellの数値リテラルはいくつか機能盛ってあるみたいですが、それでも8進数リテラルは採用しなかったのは良い仕事と思います
Re: (スコア:2)
CMD.exeは、今となっては何のメリットもないシロモノなので、今更論うのも可哀そう、って気がしますけどね。
消費リソースの少なさはメリットですけど、そんなにリソースが気になるならもっとモダンなPC使いなさいよ、って話ですよね、今となっては。
8進数問題だって、Powershellやbash程度の文字列処理ができれば何ら問題ないわけですが、CMD.exe(の前身のcommand.com)が生まれたときの標準的なPCを考えれば仕方ないことだった気もしますしね。
しかも、CMD.exeの一機能であるsetコマンドの機能を論って「Windowsは」みたいに批難するのは、不当すぎてWindowsが可哀そう。
Re: (スコア:0)
消費リソースの少なさはメリットですけど、そんなにリソースが気になるならもっとモダンなPC使いなさいよ、って話ですよね、今となっては。
そうは言っても、CLIのツールをPowerShellの支援も特に求めず実行するだけなのに、PowerShell経由はなんかなってのはあって。
あと "powershell" ってタイピングが若干だるいのもあるかな。"wers"あたりとか。
(昔入れ込んだ時はposhとか別名を作ったりしたこともあったかなあ?)
Re: (スコア:1)
> CLIのツールをPowerShellの支援も特に求めず実行するだけなのに
心情的にはすごく理解できるんだけど、PowerShellもCLIの実行環境のひとつにすぎないので
「shで十分なことをするだけなのにわざわざbashを使うのはなんかな」と言っているようなものですよ。
MS-DOSからの因習を引きずっているCMD.exeはもう限界が近いから、モダンなCLI実行環境としてPowerShellを作ったのはすごく納得できるし、.NETの機能をかなり使えたり、最初から強力な補完機能があるから「長いけど意味が明確なコマンド(レット)名」を使うようにしたり、個々のポイントは支持できるものが多いんだけど、
その代償として複雑でわかりにくい文法、膨大すぎて何があるのかわからないコマンドレットなど、絶望的なとっつきにくさで投げ出した。
Re: (スコア:2)
その代償として複雑でわかりにくい文法、膨大すぎて何があるのかわからないコマンドレットなど、絶望的なとっつきにくさで投げ出した。
CMD.exeの文法の方が複雑怪奇すぎて覚える気にならないけど。
CMD.exeの文法を覚えることができる人なら、Powershellは難しくないと思うけどなぁ。
ヘルプやキー入力補完だってPowershellの方が強いし。
つか、exeの実行環境として使うなら、追加でPowershellの制御構文を覚えれば十分じゃね?
無理にたくさんコマンドレットを使う必要もない。
Re:C++で、1バイトを8ビットにする提案がされる (スコア:0)
いやその、ぼくは#4609555と違ってCMD.exeの代替としてPowerShellを使うことはあまり考えてないというか、それが目的ならかなりコマンド体系が違うものをわざわざ学習するほどの価値は見ていません。OSのシェルとしてCLIを使う頻度がかなり低いので割に合わない。
でもってCMDでは貧弱すぎるけどプログラムをビルドするほどでもないワンライナー的な処理をしたいときにPowershell使えるかな?と触ってみたけど投げ出した。
オブジェクトのインスタンスを別のコマンドで加工して…みたいなことができるのはわかったけど、パイプ処理も可能だったりで構文が複雑すぎる。構文として意味を持つ英記号多すぎてなにやってるかわからない。
Powershellの解説記事とかみても「こうすればOK」的なものはあってもゴチャゴチャ出てくる記号の意味の解説があまりない。
そういう記号の意味を網羅的に日本語で説明したものが(あるのかもしれないけど)みつからない。
.NET準拠だけどいちいち名前が違うので利用したい機能がPowershellではどういう名前でどういう機能があるのか調べなおさないといけない。
全般的に(慣れれば気に入るかもしれないけど)最初の学習コストが高すぎ。
そしてREPLが登場してC#をコマンドライン風に使えるようになったこともあって、Powershellを使ってみたいという気持ちはほぼゼロになっちゃいました。
まあ簡単に言えば個人的にPowerShellを使わない理由は
「Powershellの制御構文がわけわかんないってだけで十分じゃね?」
ですね。
Re:C++で、1バイトを8ビットにする提案がされる (スコア:2)
「英記号」ってのが何を指してるかわからないんだけど、CMD.exeの「英記号」だってなかなか複雑怪奇じゃない?
「%」が一個で済むのか二個必要なのか、「CON」ってなんですか、とか。
リソースが乏しかった時代に、屋上屋を架す形で拡張されていった統一感のないcommand.comの文法を引き継いでしまったから仕方ないわけだけど、それよりはPowershellの方がスッキリしている。
とはいえ、オブジェクトがパイプを流れていくとか、その出力が、配列・単体のオブジェクト・nullの三通りに分かれることがあったり、それを統一するための@()オペレータとかは、確かに理解しにくく、もうちょっとどうにかならなかったのかとは思うね。
まあ簡単に言えば個人的にPowerShellを使わない理由は
「Powershellの制御構文がわけわかんないってだけで十分じゃね?」
なんだろうなぁ。新しいものにチャレンジしない理由を探してるだけに見えるなぁ。
Powershellって、パイプとかモナドとかが注目されがちだけど、それらを使わなくても書けるし、一般的な制御構文、forループ・whileループ・foreachループ・ifやswitchによる条件分岐などは、他の言語とほぼ同等に書けるし、無理に理解しづらい構文を使う必要はないんだよね。
比較演算子が難しいといえば難しいんだけど、これはBashと似た感じで、書いているうちにすぐ覚えることができる。
そういえば思い出したけど、とある仕事でBashスクリプトを書いたら、「キミの書くプログラムは難しい構文をつかってあって読めない」と言われて書き直したことがあったな。
ちょっとした変数展開(${parameter#word}など)とか、IFSで区切り文字指定してreadで読み込んだりとかしたんだけど。
これらも覚えるのは難しい「英記号」かもしれないけど、man bashで調べれば済むこと。
しかし、それすらしない・できない人もいるのも否定しがたい事実なので、そういう人たちに合わせてあげたっけ。
でも、こいつらオレより若いくせにraw guyやな、とは思ったね。
Re: (スコア:0)
> CMD.exeの「英記号」だってなかなか複雑怪奇じゃない?
複雑怪奇だね。あれも正直気に入らないんだけどそれがやたら増えた。
それでも昔ならバッチ使った方が楽だから受け入れたけど、今だと他の選択肢も多いから複雑怪奇なものを新たに学習するのが見合わなくなった。
> オブジェクトがパイプを流れていくとか
そういうとこだね。
オブジェクトをパイプで受け渡しできるとワンライナーでやれることが増えるぞ!は確かに素敵だし正常進化だと思うけど、それを実現したものを見ると「なんじゃこりゃわけわからん」になってしまう。
> 新しいものにチャレンジしない
Re: (スコア:0)
MSの伝統というか悪癖というか
アーキテクトは天才だけど実際に個々の機能を実装してるエンジニアはおそらく良く言っても世界一のアホ、そうでなければキチガイ
grepした結果をファイルにリダイレクトしようとするだけで勝手に改行しやがって、それを止めたければOut-file -width 1000してね、とかおよそ正気ではない
Re: (スコア:0)
外部コマンドの標準出力をコマンドレットにパイプすると何GBでもいったん全部バッファリングする仕様はさすが改善されたん?
Re: (スコア:0)
それはスクリプトの書き方が悪いのかもしれないし、そのコマンドレットの実装が悪いのかもしれないし、
PowerShellの問題かもしれないから、もっと具体例を出した方がよい。
ping localhost -n 10000 | %{"Ping> $_"}
これはpingのプロセスが終わるまで結果が出力されないなんてことはない。
Re: (スコア:0)
何かコマンドレット使わなきゃ例にならないか。
ping localhost -n 10000 | %{"Ping> $_"} | Out-GridView
Re:C++で、1バイトを8ビットにする提案がされる (スコア:2)
何をもって「なんじゃこりゃわけわからん」「猛烈なとっつきにくさ」と言ってるか、よくわからないんだけど…
読んでいて思ったんだけど、なにかPowershellのことを(ほぼ)完璧に理解してからでないと使いたくない、みたいな感じになってない?
Powershellでは、CMD.exeでやるような、外部コマンドを呼び出すプログラムは普通に書ける。
かつ、一般的な制御構造も準備されてて、CMD.exeみたいな奇妙な構文でもない。
その範囲で使っていれば、「なんじゃこりゃわけわからん」「猛烈なとっつきにくさ」とはならないじゃない?
それでいて、CMD.exeより文字列処理や数値計算はより素直に書けるわけだし。
確かに大量にあるコマンドレットをすべて覚えるのは難しい。私もそんなことはできない。
でも必要になったものから順に覚えれば十分。
コマンドレットを探すには、Get-Commandを使えるし、個別のコマンドレットの使い方は-?オプションか、Get-Helpを使って調べる。
なんなら、引数を入力する場所で、-の後に[TAB]を打って、どんな名前の引数があるか見れば、ざっくり想像がつく場合も多い。
オブジェクトがどういう機能・プロパティを持っているかは、Get-Memberを使う。
どうしてもコマンドレットを覚えたくなければ、同機能のexeを使ったってかまわない。
そういう流儀なんだよ。
その言語の(ほとんど)すべてを覚えないと気が済まない、という人には、確かにPowershellは向いていない。
しかしそれは、現代的なプログラミング言語全般に言えることなんじゃない?
Re: (スコア:0)
何しろ昔の、powershell coreが5ぐらいのことなんでいまいち覚えてないんだが、バイナリのストリームを読んだ時のことだったと思う
ググったらstack overflowにも仕様だよて書いてあった気が