I haven't met a single person who likes PowerShell. It's perhaps the textbook example of ugly design that looks technically consistent but utterly unfriendly and mind bogglingly verbose. I am not saying Windows command line is great or bash is best, but at least those things are designed for humans at certain extent. I have written few ps scripts and virtually every line, every step, every task almost always required googling. I don't know anything about Snover but my image of PowerShell designer was someone who couldn't write more sophisticated parser and compensated that lack of skills and creativity to solve fundamental challenges in designing OO shell by offloading complexity and unfriendlyness on users. Basically just reverse of Steve Jobs.
It was aweful when PowerShell team tried to shove their ugly creation down people's throats by removing Shift+right click menu for "Command prompt here" by "PowerShell here". Not a sign of good product when you have to force it upon people. The designers of this thing should have been demoted, let alone making them "Distinguished Engineer".
Now that I'm a PowerShell expert, the idea of dropping down to a *nix shell that only knows how to pass text around is appalling. Like, "the 1970's called, they want their shell back" kind-of appalling. And so what if it's a few extra characters to script stuff in it? I can make aliases for whatever I want, there's tab-completion for everything, everything is self-discoverable, there's Get-Help and Get-Command (alias gcm) to find everything that's available to me, and, by the way, it's all just a language projection on top of .NET... it's all great.
It's like any other language... until you bite the bullet and really learn it, you don't know. And the idea that Windows isn't built for scripting is from the 1990's. For the last 15 years, there's (almost) nothing that Microsoft ships that can't be automated/scripted/controlled from a command-line.
Well, C is pretty bad, compared to modern languages. It's full of buffer overflows, undefined behaviour, etc. Just because something is popular doesn't mean it is well designed.
Man, will this sentiment ever die... You know Stroustroup, there are only two kinds of languages: The ones everybody bitches about and the ones nobody uses.
Please guys, demonstrate a better way. Make that better language.
There is a reason most kernels are developed in C, most databases are developed in C, most (AAA) games are developed in C. And it's not "C has the necessary mind share". Man, these people make tons of scripting and DDL languages to get their game done. If they knew a better (more practical) approach than using C in the critical places, they would do it.
Yes, you get buffer overflows and memory management bugs. Much more so if you are a beginner, but also if you're very experienced. But people just haven't found a practical alternative.
How would you even be able to define what a valid buffer region is, if so many functions are basically custom allocators, declaring a certain sub-slice of the buffer they were given (taking pointers / indices), and handing it to the next function? It's just not practically possible to make a formalism that guards against buffer overflows here. You could make a "slice"/"buffer" datatype, but that would just just increase the line noise and keep the bugs at the countless locations of wrapping/unwrapping.
> There is a reason most kernels are developed in C, most databases are developed in C, most (AAA) games are developed in C. And it's not "C has the necessary mind share".
The only thing that is still pretty much all C is kernels. Game engines are usually C++ (a much safer language). Databases are written in all sorts of languages. Sure the big old ones are C or C++, but that's because they are old!
> But people just haven't found a practical alternative.
They have. Garbage collection works in a lot of cases. Rust has its lifetime & borrowing system. C++ has proper smart pointers (finally).
> It's just not practically possible to make a formalism that guards against buffer overflows here. You could make a "slice"/"buffer" datatype, but that would just just increase the line noise and keep the bugs at the countless locations of wrapping/unwrapping.
I take it you haven't used Go. It has slices. They work fine. No buffer overflows.
If you carefully read my post, you noticed C here means actually C(++). And a great majority of developers from these domains actually write C++ like this: C(++).
Rust, Go, Swift. Show me the serious kernels, databases, AAA games. Rust hasn't even descended the hype train.
Garbage collection is a bit like exceptions. It works for some cases, but not for serious engineering of long-lived applications. If you have ever written a Java application with millions of little objects, you know what I mean. For starters, we can not even afford to pay for the extra memory overhead that comes with each object. For the advanced, at some point we want the application to do exactly that: advance, instead of doing GC only.
> I take it you haven't used Go. It has slices. They work fine. No buffer overflows.
These slices all come with the (huge) overhead of adding a reference to the original runtime object, and on top of that each array access is checked. Correct?
> but not for serious engineering of long-lived applications
Oh come on. Does Lucene (or Solr or Elasticsearch built on top of it) not qualify as serious engineering? Elasticsearch is quite successful, and is indeed intended to be used a long-lived application!
Does this mean that the likes of Lucene don't run into GC issues? Of course not. I've certainly diagnosed problems in Elasticsearch related to GC (which, more often then not, is a symptom of something else going wrong), but saying it's not qualified for "serious engineering" is just patently ridiculous.
And that's only one example. There are loads more!
> These slices all come with the (huge) overhead of adding a reference to the original runtime object
Yes I knew I should not pull the "serious engineering" card going in... But there I go, giving a mostly clueless answer to a high-profile HN user :-)
I don't know elasticsearch, but if this is something like a database where millions of objects are tracked (like in an RDBMS, or in a 3D Game if coded by an unexperienced coder who likes to isolate everything down to the Vertex or scalar level into "objects"), then I would assume at least one of the following applies
- The objects in the datastore are not represented as individual runtime object after all
- The GC for objects in the datastore is highly tuned (GC only done manually, at certain points),
and the memory space overhead of having individual DB objects represented by runtime objects
is just accepted.
I mean, I did finish said Java application, but I got good performance from it only after transforming it into an unreadable mess based on SOA's of int[] (which means unboxed integers, not objects) and lots of boilerplate code. Would have been easier to do in C, hands down (language was not my own choice).
> and object/GC overhead? It's GC tracked objects after all, right? (again, I admit to knowing next to nothing about Go's runtime)
Go has value semantics. So when you have a `[]T` ("slice of T"), then what you have is 24 bytes on the stack consisting of the aforementioned `SliceHeader` type. So there's no extra indirection there, but there might be a write barrier lurking somewhere. :-)
> I don't know elasticsearch, but if this is something like a database where millions of objects are tracked
Elasticsearch is built on top of Lucene, which is a search engine library, which is itself a form of database. I don't think there's any inherent requirement that a database needs to have millions of objects in memory at any given point in time. There are various things you can ask Elasticsearch to do that will invariably cause many objects to be loaded into memory; and usually this ends up being a problem that you need to fix. It exposes itself as "OMG Elasticsearch is spending all its time in GC," but the GC isn't the problem. The allocation is.
In normal operation, Elasticsearch isn't going to load a millions of objects into memory. Instead, its going to read objects that it needs from disk, and of course, the on disk data structures are cleverly designed (like any database). This in turn relies heavily on the operating system's page cache!
>I have written few ps scripts and virtually every line, every step, every task almost always required googling.
In what way? I use PowerShell daily and hardly ever have to Google [things that I've used more than once]. I imagine if I picked up another language, I'd be Googling furiously, but that shouldn't disqualify the language.
>I find this hard to believe unless your use is limited to "dir this" and "ping that".
as opposed to bash/posix with its confusingly named utilities?
want to rename something? it's mv
want to tell the time? it's date
why is the command to download something curl/wget?
what's the difference between if [[ stuff ]] and if [ stuff ] anyways?
the list goes on. and no, man pages don't help if you don't even know which command to look for. at least powershell has a somewhat consistent naming convention for its commands (verb-something) so you can at least sort of guess what the command is.
There is a rename command as well. But apart from the first time I tried to rename a file I've never had trouble remembering it. There is a good reason for it to, internally it is a move operation.
> want to tell the time? it's date
Is this different in powershell? Some quick googling indicates the Get-Date is the method you want and being .net based everything deals with DateTime objects.
> why is the command to download something curl/wget?
I find this easier to remember than Invoke-WebRequest, or is it Invoke-RestMethod?
If they were so hard to remember that could be aliased to something similar, but I've never seen anyone bother.
Edit - I mean I've never heard anyone going the other way and suggest doing "alias Invoke-WebRequest=\"curl\"" in bash.
> why is the command to download something curl/wget?
I find this easier to remember than Invoke-WebRequest, or is it Invoke-RestMethod?
easier to remember: maybe, but much less discoverable than Invoke-WebRequest/Invoke-RestMethod. this seems to be the overall trend for linux shell commands. a few characters long for easy typing, but otherwise arbitrary strings that you have to remember and have 0 discoverability. GGP's comment was about how you had to search for how to do everything in powershell, so in that respect powershell is at least not worse than bash.
want to rename something? it's Rename-Item, unless you also want to put it somewhere else, in which case you need Move-Item (it won't figure it out for you.)
want to tell the time? it's Get-Date ("time" won't work, neither will "get-time")
why is the command to download something Invoke-WebRequest?
what does '&"C:\Program Files\TortoiseSVN\bin\TortoiseProc.exe" /command:about' do?
and if you want to complain about ridiculous syntax, why the hell is ` the escape character instead of \ like every other language?
>want to rename something? it's Rename-Item, unless you also want to put it somewhere else, in which case you need Move-Item (it won't figure it out for you.)
so... working as intended? (unless you subscribe to the belief that rename is the same operation as moving)
>want to tell the time? it's Get-Date ("time" won't work, neither will "get-time")
fair point, although at least it doesn't alias any existing commands (typing time will get you a confusing output of 0 user, 0 kernel, 0 real)
>what does '&"C:\Program Files\TortoiseSVN\bin\TortoiseProc.exe" /command:about' do?
& = run program in specified path. i agree this isn't used in any other shell language, but then again all the linux shells are fairly similar to start with. it's probably there because otherwise it won't be able to differentiate between a command that you want to execute, and a string literal.
also for windows command line programs, it's fairly stander to use /arg:value for command line arguments instead of --arg value
>and if you want to complain about ridiculous syntax, why the hell is ` the escape character instead of \ like every other language?
probably because \ is used in windows paths, so to avoid unnecessarily quoting every path, they chose an odd line continuation character.
also, about what you were responding to for the last two points: that was more a poke at how '[' isn't actually part of the syntax, but in fact an alias for test.
Or.. you could actually encourage people to use sane path separators. The rest of the world uses a normal slash which works most of the time in Windows too.
CP/M lost. URLs won.
It's like UTF-16. They somehow had the means to replace Windows-1252 with UTF-16, but they can't bring themselves to move to UTF-8 which everyone else and the web uses instead.
PowerShell has a few rough edges, but once you get over those it's super easy. Even when you can't remember the exact syntax for a command, the built-in help makes it quick to look up.
What tool(s) have you tried using to write PowerShell scripts?
Powershell has some good ideas, they just didn't come together as a whole. The idea of piping objects rather than lines of text might be good (I'm not convinced in either direction there) and probably much more efficient, but it's integration with .net hurt it. .Net code is just way to close to the "enterprise" spectrum of languages and way to terse for a shell. The powershell language itself inherits this lack of terseness.
When it launched there also wasn't a whole lot you could do with it, windows wasn't built to be automated by scripts like this. This hurt the uptake right of the bat and it never really reached that critical mass to become adopted.
A decade after powershells creation I still write batch files for windows specific things and stick to cygwin/bash for everything else. It's not even a familiarity thing, I learned (or at least tried to) powershell before I (properly) learned to use bash.
MS would have been better off creating language/environment independent binaries to manipulate windows.
> Not a sign of good product when you have to force it upon people.
This sums it up nicely, the only reason PS has any use whatsoever is because it has the MS name attached.
But it's hard to understand what you're saying as .Net's not a language, which one are you talking about?
I feel like I should stick up for C# as it's probably one of the best languages available today. I'm biased as I prefer statically typed languages so none of my brain is taken up by utterly useless information like having to remember the names of properties, methods, method signatures, etc. which the computer should bloody well tell me.
It might not be a language, but the .net object model/environment brings about as much joy to powershell scripting as the browser document object model brings to javascript...
I have tried PowerShell a few time and every time I hated it. I know people who like it though.
I am doing a lot scripting now with CSScript. It's much nicer than PowerShell. The main advantage of PowerShell is interop with .NET so why not use C#?
Because you need to compile your C# source first. With PowerShell you just write and run. Also in a PowerShell shell you can fart about and test stuff without actually having to write a fully working script in a file, i.e. it's got its own REPL.
Yes, I know, I was addressing your question and explaining why:
> The main advantage of PowerShell is interop with .NET so why not use C#?
Anyhow, I've written tens of thousands of lines of CScript and PowerShell over the past 15-20 years, give me PowerShell any day of the week for automation and admin tasks. Why anyone would persist with CScript/WSH for sysadmin tasks and automation (unless you're still managing an ancient fleet of Windows 2003/2000/NT) makes my mind boggle.
Also you there's a reasonably useful IDE with ships with PowerShell so you can actually set breakpoints, step through your code and inspect variables (though I prefer to use PowerGUI). That alone is a massive productivity booster.
Really? I'm guessing you haven't spoken to many people who are proficient in it. I'm certainly not, but I can still appreciate the fact that you are working with Objects instead of text blobs, you have access to a decent IDE and a great help doc system.
While I'm sure that's partly sampling bias. The truth is, Powershell has a lot of flaws. Both in the program itself, as well a the language decisions.
And I _REALLY_ like the idea of an object-oriented piping system. I would love to have that built into Linux/bash/etc instead of every program having to have some sort of "human readable" mode and (if you're lucky) a "machine readable" mode. Except every machine readable mode is different and still requires a parsing pass to get it filtered into your program correctly. I find it fun and even relaxing to design parsing passes to bring say, smem, into a Python script. But that's because (Thank God) I don't have to do it for a living. [And the newest era of "some" programs supporting JSON or XML output but there's still no easy tools for filtering through it into the next program--requiring yet another translation layer.]
Now back to Powershell. It's fun to learn the first day. And then after that, it's just an 80 degree walk uphill after you learn one stupid idea after another. You want to do something insanely simple in concept and you're pouring through ours of documentation and examples for the exact use-case.
Personally, I've started using Python2/3 for scripts lately. Most systems I use already have Python, and Python is easily 10x-100x faster in many situations and that's not even using a compiled variant. And while I enjoy C variant programming, Python is still a huge step up from all those stupid Bash idiosyncrasies like string -eq non-string but wait, you added a space before the equals, so it explodes anyway. (I can't remember a great example off-the-top-of-my-head, but anyone who has used Bash has had those days of an obscure error being related to a single incorrect whitespace.)
Object-oriented piping is actually somewhat problematic, because objects carry behavior, not just data. This means that everyone in the pipeline now has to agree on the semantics of that behavior - in case of PowerShell, they need to understand and talk the .NET object model, for example.
A much more lightweight approach is to exchange structured data. This can even be easily done on top of existing byte streams, just standardizing the format.
FreeBSD started adopting this approach via libxo for its base utilities: https://github.com/Juniper/libxo. I hope it spreads into Linux.
> And the newest era of "some" programs supporting JSON or XML output but there's still no easy tools for filtering through it into the next program--requiring yet another translation layer.
As someone who's been working with aws command line tools quite a bit recently that accept and emit lots of json, I've found jq to be a life saver! https://stedolan.github.io/jq/
>>> And I _REALLY_ like the idea of an object-oriented piping system. I would love to have that built into Linux/bash/etc instead of every program having to have some sort of "human readable" mode and (if you're lucky) a "machine readable" mode.
That's sort of what ansible/salt do. Provide the most useful system commands with structured arguments as input and output, instead of crazy text everywhere.
> I haven't met a single person who likes PowerShell.
The only thing I like about it is it's object oriented nature. That everything is an object ( PSObject ) that can be piped is very nice.
However, the shell itself is slow, ugly and cumbersome. I just don't understand why windows can't create a shell like bash. The old cmd shell was horrible. PowerShell is a step up but it's still lightyears behind all the terminals we have in linux/bsd/etc.
> mind bogglingly verbose.
It's verbose if you don't use the aliases. But I don't mind the verbosity as you can understand the command just from the name.
I like the idea of powershell ( OO, Verb-Noun commands, etc ). But the execution has been disappointing.
It was aweful when PowerShell team tried to shove their ugly creation down people's throats by removing Shift+right click menu for "Command prompt here" by "PowerShell here". Not a sign of good product when you have to force it upon people. The designers of this thing should have been demoted, let alone making them "Distinguished Engineer".