As I said in the other threads, the language is great, the performance has been abysmal in relation to batch (at least for me, having started with Powershell in its first release in Vista).
With PowerShell level of slowness it starts to matter. Even very basic commands seem to sometimes take many seconds to run. In the middle of intense workflow it becomes a problem.
What could a shell possibly do so that a basic command would take many seconds?
Currently, "many seconds" is enough time to run an interpreter on the command, connect to a remote machine in Iceland, spin up a new virtual server there, send the command there to be executed, review the execution results for possible exceptions, run a malware scan, fetch the response back, execute the command again on your computer, translate the command and results to Klingon, send them to NSA for archiving, play a quick game of chess with another instance of the shell, and play a congratulatory tune.
Seriously, computers nowadays are fast enough to run a partial compile of your code at every single keystroke while you're writing it. It takes special effort to make a scripting language unusably slow - even an unoptimized interpreter that itself runs on a different interpreter should do just fine.
Care to give examples? I know that the language isn't fast, but afaik nearly all shells are interpreted. There have been performance problems with break/continue in earlier versions as they were implemented using exceptions internally. But that doesn't really qualify as "basic commands", I guess. Cmdlets should be not much slower than running the equivalent C# code yourself.
Hmm, I can't seem to reproduce many such issues with this machine, except Get-Help the first time I tried it. I think it could be that the cmdlets are only slow on the first run (enough to leave me with a bad experience), or the SSD on my PC masks the problem. It's good to know that it's not always super slow.
If it's slow on the first run, then it might be loading a large interpreter from disk. If so, MS might have let the interpreter get a bit ungainly -- you might argue.
I use Powershell for many administrative tasks at work, and it can be annoying if querying data from a single machine takes 5+ minutes. Which it does sometimes.
For simple use cases I still use batch files as the performance is much greater. Powershell feels too heavy when I just want to run a build with some parameters and a couple of other commands.
I think it's really interesting the way programmers will use phrases like, "it feels heavy", as a way to describe using programs that contain unused features. I'm guilty of the same. Powershell "feels heavy" because it is a lot more sophisticated than batch, you can do all sorts of cool things with WMI or use data structures, but in the end, what does programming in batch actually gain you? If performance is such a problem that you notice a performance penalty when switching between shells, something is seriously wrong.
But I'm guessing you don't really notice the performance difference, you just feel the weight of unused features.
The opposite effect is, IMO, how things like node.js gain in popularity - the environment "feels fast" and "feels simple" [for the simple use cases that are always at the start of things].
Totally agree. Powershell is what you need to use on windows. It's been available on the default server install since 2008 R2. No need for batch scripts anymore.
This sounds like you're saying that it suits your needs, therefore we should take that as meaning it fits our needs. Unfortunately, things are not that simple.
I needed to do something and looked at using powershell, but in the end I couldn't just distribute it and have it work for whomever would be using my project. It needed to be signed or something. On the contrary, the bat script I wrote just worked and would just work for anyone who used the project.
Powershell is not a magical solution that suits everyone's needs. This kind of blanket statement helps no-one.
There's a config switch to allow execution of scripts. I agree it's a complete pain (literally falling at the first hurdle), but it is a one-time thing change.
I had mixed opinions of powershell when I tried my hand at it. The naming convention and documentation system were well designed, piping objects is an interesting concept, and IDE support was great for a terminal (step through debugger, intelligent auto complete). Despite this, there were numerous quirks and ugly spots that diminished the experience. I felt it was a missed opportunity. This was powershell 3, I can't speak for later versions
Thanks for this candid impression. I had some slight interest in learning PowerShell, but it looked like a little bit too high of a learning curve, given that I had other scripting languages I could use (including bash in Cygwin). Piped objects struck me as interesting when I read about it in a magazine, too, but somehow they aren't needed to perform all kinds of scripting in *nix, so I wonder if they might be more complex than the problem called for. I get the impression that PowerShell may suffer from having come from Microsoft -- a company with bottomless pockets to spend on developing software and probably little need to stop smallish system utilities from becoming ornate.
On the contrary, one of the first things I do on a Windows box is open up a powershell window. Especially on Win 8+, it's a lot easier to do "logoff" or "Stop-Computer -Force" or "Restart-Computer" than to try to navigate the mess of Metro to find the GUI menu options. Moving files around on the PS command line is much more efficient than using Explorer, just like bash/Terminal on the Ubuntu desktop. It's just a matter of getting used to it (and learning the different syntax from Unix shells).
PS cmdlets in generally are quite consistent: there is a [Verb]-[Noun] naming convention (eg, "Stop-Computer" above) and full tab completion, so if you forget the exact name of a cmdlet you can do Get-[tab] and cycle through every Get-* cmdlet that exists. Even command line switches tab complete, just type a hyphen and then you can tab-cycle through every command line switch that particular cmdlet supports. There's also Remote Powershell, which is like SSH but also built-in. I can sit in a Powershell window and connect to a Windows server anywhere just like SSH on Linux, or even compose a script block, assign it to a variable, then send it over the wire to be executed remotely (or to a group of machines in a foreach loop). It's pretty slick, and all this is built into the shell--no third-party tools required.
I'm not a big fan of MS, but I'm willing to give them kudos on the rare occasion that they build something nice. Powershell has it's quirks like anything, but it's a damn nice piece of engineering and a godsend to anyone who has to administer Windows boxes. Why anyone would continue with the anachronism of (essentially DOS) cmd.exe is beyond me.
I beg to differ, and not only because I code-golf in PowerShell. Aliases and the ability to shorten arguments while they're unambiguous both are features that have no use for scripts, but are very handy for an interactive shell. I never type things like
Get-ChildItem -Path ~ -Recurse
if I can help it, instead it almost always is something like
ls ~ -r
I guess -Recurse only ever appears there if I hit [⇄] for parameter completion.
Sadly there are far too many people who only know bash and see straightforward conversions of VBScript into PowerShell and think the language sucks or is too verbose.
