Jeffrey Snower was originally demoted over PowerShell(twitter.com)
twitter.com
Jeffrey Snower was originally demoted over PowerShell
https://twitter.com/jsnover/status/1523010444570419200
152 comments
> For recent years, L68 all-in comp is probably right around $1mm a year,
This is in stark contrast of how people below 67 got paid. Their packages have been visibly smaller than those of similar roles in FANNG-like companies. I think this is because resources will concentrate to the top as a company becomes bigger and older most likely because visibility disappears quickly among lower ranks and what they do individually hardly matters. If the theory is correct, the natural conclusion is that one should really seek a career in a fast-growing company unless they are great at navigating a big co's dynamics.
This is in stark contrast of how people below 67 got paid. Their packages have been visibly smaller than those of similar roles in FANNG-like companies. I think this is because resources will concentrate to the top as a company becomes bigger and older most likely because visibility disappears quickly among lower ranks and what they do individually hardly matters. If the theory is correct, the natural conclusion is that one should really seek a career in a fast-growing company unless they are great at navigating a big co's dynamics.
Also very interesting details on his presentation:
"Digital Transformation: Thriving Through the Transition - Jeffrey Snover, Microsoft"
https://youtu.be/nKyF8fzed0w
"Digital Transformation: Thriving Through the Transition - Jeffrey Snover, Microsoft"
https://youtu.be/nKyF8fzed0w
I'd like to know why Snower accepted abuse from corporate overlords for 5+ years (according to the thread). Being "in the dog house" for that long is ridiculous on the surface. That would never stand in today's world of tech. Is he just oldschool and had the mindset of "the company is always right"? Is he just a company man with intense loyalty? I would understand the company not adopting it and having to spend five years advocating for new tech in a company that large. But I can't understand why being demoted and punished for 5 years. I grew up with a major emphasis on work ethic but I can't wrap my mind around this.
Probably he was still getting paid a lot? It is MSFT after all.
I imagine that a certain kind of person, willing to write tooling and even get demoted for it, is willing to stick around with a bit of a pay cut anyways.
I imagine that a certain kind of person, willing to write tooling and even get demoted for it, is willing to stick around with a bit of a pay cut anyways.
The Microsoft of that time period was infamous for deliberately paying less than other tech giants.
Absolutely true.
They had an actual formula for it, and I'm forgetting what the number was. Like 80% of some metric of other tech giant comp?
66th percentile of the industry for equivalent positions is what was reported.
Anybody who could get more than the 66th percentile elsewhere, more power to them. Anybody who thought that "66th percentile" meant they were being paid less than average, well, their departure was probably regarded as good attrition with a chuckle.
Anybody who could get more than the 66th percentile elsewhere, more power to them. Anybody who thought that "66th percentile" meant they were being paid less than average, well, their departure was probably regarded as good attrition with a chuckle.
They make a joke of it in Silicon Valley, "Rest and Vest" check out this clip:
https://www.youtube.com/watch?v=y30pML-AW4k
It's because he was interested in philosophy (particularly Leibniz). He also left a job he liked just to develop PowerShell at MS. (he wrote an entire manifesto about it)
What makes you think he didn't try to change jobs? It's not like tech interviews are designed to detect this kind of talent.
andrew_(1)
Live in California long enough and your work ethic will melt and your life will become much more interesting.
I find this twitter thread frustrating.
Q: What was the justification for the demotion? What became of the leaders that made that decision?
A: It was stranger than you can possibly imagine
I think the gist of the story is that he was assigned to work on X but worked on Y instead. Notwithstanding how great Y idea turned out to be it seems he was demoted for insubordination?
Q: What was the justification for the demotion? What became of the leaders that made that decision?
A: It was stranger than you can possibly imagine
I think the gist of the story is that he was assigned to work on X but worked on Y instead. Notwithstanding how great Y idea turned out to be it seems he was demoted for insubordination?
Twitter threads are frustrating no matter the content, after two replies I get a banner that blocks me from reading until I register.
Not gonna happen.
Not gonna happen.
Click on the banner to login, the page will change to a login form with an [X] close button; click that to cancel and you'll be returned to the content to scroll a couple more replies until it tries again and you get bored.
Nitter is your friend if you care (while it lasts). Nitter.net or nitter.eu usually work for me.
Using Nitter is as easy as replacing twitter.com with e.g. nitter.net or .eu:
https://nitter.net/jsnover/status/1523010444570419200
https://nitter.net/jsnover/status/1523010444570419200
Yep, I'm doubly less likely to sign up when you pull that crap.
This particular "thread" is simply two tweets.
There's no explanation of why the demotion occurred, by whom, for what reason, when rescinded, etc., etc.
There's no explanation of why the demotion occurred, by whom, for what reason, when rescinded, etc., etc.
Ok, even that was obfuscated for me.
Firefox in a private browser window seems to get past the registration popup for me. You have to close and reload the private window periodically because it somehow starts to fingerprint you as a user and starts showing the popup after some time.
If there's a way to configure a specific site to never ever store any cookies or send them under any circumstance that might be the next thing to try. Make twitter think you're friggin curl. Unbelievable we have to do this nonsense just to read the site.
If there's a way to configure a specific site to never ever store any cookies or send them under any circumstance that might be the next thing to try. Make twitter think you're friggin curl. Unbelievable we have to do this nonsense just to read the site.
use nitter.net instead.
IIRC powershell came about in the mid 2000s when it was the peak Steve Balmer and Windows Vista era for Microsoft. Absolutely none of the senior leaders at that time survived at the company in the long run, at least no one in the Windows organization. Jim Allchin, Steve Sinofsky, etc.
> What became of the leaders that made that decision?
@Dejify: Not sure if you can speak to this, but it'd be nice to know what happened to those who dinged you? - https://twitter.com/Dejify/status/1523025584749629440
@Jsnover reply: "Retired" with a picture of Donald Trump on the Apprentice captioned "Fired" - https://twitter.com/jsnover/status/1523031601390571520
@Dejify: Not sure if you can speak to this, but it'd be nice to know what happened to those who dinged you? - https://twitter.com/Dejify/status/1523025584749629440
@Jsnover reply: "Retired" with a picture of Donald Trump on the Apprentice captioned "Fired" - https://twitter.com/jsnover/status/1523031601390571520
> it seems he was demoted for insubordination?
Probably, and what management blunder that would have been if Jeffrey had left Microsoft because of it.
Probably, and what management blunder that would have been if Jeffrey had left Microsoft because of it.
They would never have known. When you cook the goose, you get a nice meal but you never know about the golden eggs that never got laid as a result. Everyone thinks they did the right thing except for the goose.
Yeah, but almost always geese lay regular eggs. You cannot just never kill geese in the offchance one lays golden eggs. The maintenance costs get astronomical.
There are probably several thousand, if not more, other former Windows platform admins like me that are absurdly grateful that Snover stuck with his vision, giving us a path to being automation and, later, cloud experts. I've since branched off into DevOps, but up to about 2011/2012, was pigeon-holed as a Windows admin. Doing a few clever things with PowerShell and Active Directory led to my being chosen to work on my company's Skype for Business deployment, then Azure, which led to Kubernetes and DevOps.
Having an immediate work-related reason to learn a powerful scripting language means a lot in particular for people who don't have a lot of time to learn things outside of work, like parents (especially mothers) of young children.
Having an immediate work-related reason to learn a powerful scripting language means a lot in particular for people who don't have a lot of time to learn things outside of work, like parents (especially mothers) of young children.
what does DevOps mean in this context?
(I'm asking because I thought k8s is already devops, just as azure is if devs have some access.)
(I'm asking because I thought k8s is already devops, just as azure is if devs have some access.)
Today's tech worker would have quit and launched a startup and have Powershell become the Enterprise "Ansible" add-on of Windows to then subsequently be acquired by Microsoft for [m|b]illions..
I like the regex touch
I've often wondered why powershell hasnt taken off on linux/mac. I'd guess MS would have a good case for investing there (given, eg., linux usage on azure).
Particularly in the recent history of "every day, another shell" on linux/mac. Powershell seems to solve the problem being resolved in rust,go,scala,... over-and-over. Why not just use that?
Particularly in the recent history of "every day, another shell" on linux/mac. Powershell seems to solve the problem being resolved in rust,go,scala,... over-and-over. Why not just use that?
Look, I’ve written a lot of powershell, and I don’t mind it at all, but its not surprising at all to me.
Powershell isn’t in the same problem domain as rust/go/Scala/python.
The niche it fills is “calling windows apis from c++” or, more recently, c#.
It’s less effort than that, so it’s useful, on windows.
It is not less effort than using say, a bash script on other platforms because it:
- does not provide unique access to proprietary windows apis (they don’t exist)
- is not installed by default
- does not conform to any standards other than it’s own
- no package manager that works
The question you should ask is: why given that, would you, given that you must install something, choose to install and use powershell instead of python?
There’s no reason. You’d have to specifically like powershell to bother.
Most people don’t care enough to be bothered. Surprise level: 0.
Powershell isn’t in the same problem domain as rust/go/Scala/python.
The niche it fills is “calling windows apis from c++” or, more recently, c#.
It’s less effort than that, so it’s useful, on windows.
It is not less effort than using say, a bash script on other platforms because it:
- does not provide unique access to proprietary windows apis (they don’t exist)
- is not installed by default
- does not conform to any standards other than it’s own
- no package manager that works
The question you should ask is: why given that, would you, given that you must install something, choose to install and use powershell instead of python?
There’s no reason. You’d have to specifically like powershell to bother.
Most people don’t care enough to be bothered. Surprise level: 0.
Also if you look at interactive shells, which have the lower bar to people trying them out (as seen by fish, nushell, etc. picking up users in recent years), powershell is actually quite clunky as an interactive shell. It doesn't appear to have completions matching those shells, the command names are quite tedious for those that don't have built in unix-y aliases, it doesn't provide a facility for common shell shortcuts like "run this one command with a modified environment", etc.
> It doesn't appear to have completions matching those shells
What kind of completions do you mean? PowerShell has completion for commands, parameter names and arguments. You can define arbitrary script blocks to do custom completion (or for simple cases just use `ValidateSet`). They can be defined either in the script/function itself, or separately with `Register-ArgumentCompleter` (that also works for non-PowerShell programs).
What kind of completions do you mean? PowerShell has completion for commands, parameter names and arguments. You can define arbitrary script blocks to do custom completion (or for simple cases just use `ValidateSet`). They can be defined either in the script/function itself, or separately with `Register-ArgumentCompleter` (that also works for non-PowerShell programs).
In fish, if I type ls -<tab>, I get a history based autocomplete suggestion (ls -l), and also a summary of options with brief descriptions:
In Powershell, if I type Get-ChildItem -<tab>
It just cycles through options apparently abitrarily. The first suggestion is "-Path", and it offers no facility to provide explanatory information.
ls -l
-1 (List one entry per line)
-A --almost-all (Show hidden except . and ..)
-a --all (Show hidden)
-B --ignore-backups (Ignore files ending with ~)
…and 51 more rows
In Powershell, if I type Get-ChildItem -<tab>
It just cycles through options apparently abitrarily. The first suggestion is "-Path", and it offers no facility to provide explanatory information.
If you use `Set-PSReadLineKeyHandler -Key Tab -Function MenuComplete` it will show the options and the types of the arguments, but yeah, I don't think there is a completion function available that orders them based on history or shows the docstrings.
In principle there isn't anything that would stop one from making that. PowerShell has history info available, and help messages/docstrings can be given for parameters (`Get-Help command -full` will show them if available).
In principle there isn't anything that would stop one from making that. PowerShell has history info available, and help messages/docstrings can be given for parameters (`Get-Help command -full` will show them if available).
Perfectly stated! Powershell is fantastic…for windows.
"Here is a revolutionary new thing that does everything better."
"No it doesn't, because it's not exactly like the thing that I am used to. In fact, it doesn't have solutions for the limitations it eliminates! Poor."
I heard the same arguments when, for example, SolidWorks with its true construcive solid geometry (CSG) 3D modelling swept away the old 2D "electronic paper" tools such as AutoCAD. The old guys complained in exactly the same way.
"What if I just want to draw the outline by hand? SolidWorks is terrible at that!".
"Umm... it can draw arbitrary cross-sections automatically in seconds!"
"Yes, but I can't control things the way that I'm used to!"
Etc...
"No it doesn't, because it's not exactly like the thing that I am used to. In fact, it doesn't have solutions for the limitations it eliminates! Poor."
I heard the same arguments when, for example, SolidWorks with its true construcive solid geometry (CSG) 3D modelling swept away the old 2D "electronic paper" tools such as AutoCAD. The old guys complained in exactly the same way.
"What if I just want to draw the outline by hand? SolidWorks is terrible at that!".
"Umm... it can draw arbitrary cross-sections automatically in seconds!"
"Yes, but I can't control things the way that I'm used to!"
Etc...
PS is a far cry from Ammonite (a Scala-based scripting package/environment/thing, with an easy deployment one-liner, easy access to allll of the Java ecosystem packages, compile time type checks, and so on)
Passing objects by default is a nice idea to enhance pipes... but how about going beyond pipes? :)
Passing objects by default is a nice idea to enhance pipes... but how about going beyond pipes? :)
+ telemetry-spewing ms products give some of us the willies.
Powershell is a shell. Shells don’t do package management. Do you mean sth like ZSH plugin installers?
As a mac user, I was going to provide a flippant answer, but I decided to look into it instead. Personally, I use zsh or a custom built shell scripting library inside swift. Always like to see improvements to shells though. Googled for it and got a dozen guides on how to install it in mac, but none that actually explained how to use it. (One video result looked like it might have some info, but to me that doesn't count as documentation). All the documentation on powershell is targeted at windows devs, and it's just a very different culture.
Flippant answer: the CapitalizationConvention-ShouldScare-EveryoneAway
Flippant answer: the CapitalizationConvention-ShouldScare-EveryoneAway
I'm certain I once wrote a long rant about why I think the concept of PowerShell (using objects instead of text as interface) is interesting but it fell flat on execution and felt like something in the uncanny valley between *nix shells and Python/Perl, with a thousand papercuts. I'm not gonna dig that out, but to add some points I can remember at the moment to yours:
- Write-Output and friends try to be smart and print different things situationally. I hate "smart".
- Try to get something akin to set -e -o pipefail, i.e. exit if a command fails. Pain.
- Try to get something akin to set -x for tracing. There's Set-PSDebug, but the trace level also applies to all the cmdlets, so say you use Expand-Archive, suddenly you have a million lines of crap in your trace you don't give a shit about.
In general, IMO the biggest advantage of PowerShell compared to scripting languages like Python/Perl is the ability to natively interact with Windows' COM stuff. That advantage is nonexistent on *nix.
- Write-Output and friends try to be smart and print different things situationally. I hate "smart".
- Try to get something akin to set -e -o pipefail, i.e. exit if a command fails. Pain.
- Try to get something akin to set -x for tracing. There's Set-PSDebug, but the trace level also applies to all the cmdlets, so say you use Expand-Archive, suddenly you have a million lines of crap in your trace you don't give a shit about.
In general, IMO the biggest advantage of PowerShell compared to scripting languages like Python/Perl is the ability to natively interact with Windows' COM stuff. That advantage is nonexistent on *nix.
I agree that 'set -x' is the shell superpower, as it shows your scripts behaviour but not the inside of the tools you call.
I'm quite sad that gdb doesn't have something similar: 'step in my application only' no I don't want to step into the STL shared pointer dereference implementation for the n-th time!
I'm quite sad that gdb doesn't have something similar: 'step in my application only' no I don't want to step into the STL shared pointer dereference implementation for the n-th time!
And even the com integration is poor. Trying to script anything to do with Outlook is so failure prone and unreliable it turned me off powershell altogether.
I've actually installed Powershell on my Linux PC last year. I daily drive a Linux box, but I sometimes have to interact with my employer's MS ecosystem (that's technically not my job, so running Linux is fine most of the time).
After waiting for the installation to do god knows what for what felt like ever (and I was running an 8 core Xeon with a fast NVMe drive at the time...) I attempted to connect to the Office 365 tenant to do something.
Since it was my first attempt at running this on Linux, I was following along with the MS docs (actual docs.ms, not the TechNet circus) and I started getting uncomfortable with statements along the lines of "this should work". I mean, if you're not sure, who can be?
Anyway, it managed to install whatever libraries it wanted, so I was ready to go. But everything ended abruptly with some "incorrect credentials" or similar. The credentials were, of course, OK (they worked fine in the web-based admin console). But after some digging, it turned out that, contrary to what the MS docs said, you can't connect to Office365 from linux...
After waiting for the installation to do god knows what for what felt like ever (and I was running an 8 core Xeon with a fast NVMe drive at the time...) I attempted to connect to the Office 365 tenant to do something.
Since it was my first attempt at running this on Linux, I was following along with the MS docs (actual docs.ms, not the TechNet circus) and I started getting uncomfortable with statements along the lines of "this should work". I mean, if you're not sure, who can be?
Anyway, it managed to install whatever libraries it wanted, so I was ready to go. But everything ended abruptly with some "incorrect credentials" or similar. The credentials were, of course, OK (they worked fine in the web-based admin console). But after some digging, it turned out that, contrary to what the MS docs said, you can't connect to Office365 from linux...
Incidentally, I needed to teach myself PS for an azure-focused client of mine -- and I did so on mac (incidentally, making notes in a jupyter notebook with PS backend).
It's a weird language, but I always reminded myself of its competitor: bash -- which is perhaps an order of magnitude more weird.
It feels like it could be a "shell language for the cloud", ie., the language for cross-OS cloud automation work.
It's a weird language, but I always reminded myself of its competitor: bash -- which is perhaps an order of magnitude more weird.
It feels like it could be a "shell language for the cloud", ie., the language for cross-OS cloud automation work.
Is it possible to "learn" Powershell?
My very limited experience has been: look up problem, find likely solution, enter 60-character command specific to this niche issue that I'll only ever have to use again in this exact situation, which is now solved until next reinstall.
Having said that, those are the only situations in which I've needed to use powershell.
My very limited experience has been: look up problem, find likely solution, enter 60-character command specific to this niche issue that I'll only ever have to use again in this exact situation, which is now solved until next reinstall.
Having said that, those are the only situations in which I've needed to use powershell.
To be fair, as a native of Windows, you seem to be describing the process I need to go through for stuff like maintenance of my home Plex server (which runs on Linux).
I'd even argue that, between PowerShell's kinda-guessable commands and parameter names (as contrasted to bash/linux) and ubiquitous --help, PS makes it easier (relatively) to discover a solution on your own.
I guess a big part of this is what your native language is.
I'd even argue that, between PowerShell's kinda-guessable commands and parameter names (as contrasted to bash/linux) and ubiquitous --help, PS makes it easier (relatively) to discover a solution on your own.
I guess a big part of this is what your native language is.
> I'd even argue that, between PowerShell's kinda-guessable commands and parameter names (as contrasted to bash/linux) and ubiquitous --help, PS makes it easier (relatively) to discover a solution on your own.
Yeah, if I'm trying to find something out on Unix-y world I have the escalation tree of
1. Tab Completion shows summaries
2. Still not clear? --help will usually print out an overview
3. Really still not clear? "man" to the rescue.
Yeah, if I'm trying to find something out on Unix-y world I have the escalation tree of
1. Tab Completion shows summaries
2. Still not clear? --help will usually print out an overview
3. Really still not clear? "man" to the rescue.
there are wonderful books, that go deep into the language, or provide bunch of solutions to practical problems.
Pick your poison:
Powershell in Depth [1]
Powershell Cookbook [2]
[1] https://www.manning.com/books/powershell-in-depth
[2] https://www.oreilly.com/library/view/powershell-cookbook-4th...
Powershell in Depth [1]
Powershell Cookbook [2]
[1] https://www.manning.com/books/powershell-in-depth
[2] https://www.oreilly.com/library/view/powershell-cookbook-4th...
> It feels like it could be a "shell language for the cloud", ie., the language for cross-OS cloud automation work.
Isn't that terraform?
Isn't that terraform?
Imo your flippant answer is bang on
You really don’t need any online documentation.
Just use Get-Help and you’re off to the races.
Just use Get-Help and you’re off to the races.
This, in conjunction with the cmdlets and their parameters being something approximating English, with semi-standard verbs, makes things a lot more discoverable than Linux seems to me.
Would want to look at how people use Power Shell on Windows and compare to how people use bash/tools/procfs/Python/C on *nix.
I think that, on *nix, Power Shell loses to cli tools/bash/procfs for trivial problems, to Python for simple problems, and to native strongly typed languages for complicated problems.
Many Windows APIs are COM based, for both arguments and results, so an OO-based scripting language is helpful.
Unix APIs tend to be less strongly typed. Mostly lists of lists of strings and ints.
Is there really a recent increase in shells on Linux? I can only think of zsh and fish.
I think that, on *nix, Power Shell loses to cli tools/bash/procfs for trivial problems, to Python for simple problems, and to native strongly typed languages for complicated problems.
Many Windows APIs are COM based, for both arguments and results, so an OO-based scripting language is helpful.
Unix APIs tend to be less strongly typed. Mostly lists of lists of strings and ints.
Is there really a recent increase in shells on Linux? I can only think of zsh and fish.
Debian moved to dash as the default shell a few years ago, nushell gets some users, fish has moved from niche to one of the big players, and yes, some people also use powershell on Linux.
You could argue it's just a changing of the guard as things like csh or ksh die off on Linux and get fish/pwsh take their place as the second tier shells in popularity, but it did feel like many years we were in a bash monoculture with zsh only surviving by being sufficiently compatible.
You could argue it's just a changing of the guard as things like csh or ksh die off on Linux and get fish/pwsh take their place as the second tier shells in popularity, but it did feel like many years we were in a bash monoculture with zsh only surviving by being sufficiently compatible.
In mixed enviroments being able to use Powershell on both Linux and Windows allows for people to only have to learn one scripting environment, and allow you to share functions, modules, and tooling between the systems.
that alone is a big WIN for PS imo
Also I find Powershell to be more enjoyable to use (I like the verbosity, the help system, and passing objects instead of text streams.. I know I am crazy), and easier to train new Admins on PS than bash or python.
that alone is a big WIN for PS imo
Also I find Powershell to be more enjoyable to use (I like the verbosity, the help system, and passing objects instead of text streams.. I know I am crazy), and easier to train new Admins on PS than bash or python.
I don't have any experience with iOS, and haven't scripted in anger in powershell.
Linux and its ecosystem evolved alongside bash. If somebody tried to make a thing, and said thing was difficult to script with bash, nobody used the thing. They would say it's "hard to use". So system facilities and applications that don't script well with a shell script like bash (or csh or zsh to tcsh...) never survived.
Basically, everything in linux automation is a nail, and bash is a very good hammer. DOS/Windows has had .bat scripts forever, which is not a particularly good hammer, but more importantly, Windows automation is very much not-nail like. You need a wrench and a socket set for many tasks, and CMD simply doesn't do that very well. (neither does bash for that matter) So powershell is a godsend. Meanwhile, us linux folks are sitting here with our hammer and all of our nails, and ... well, while I see that sometimes, it's maaaaybe nice to have a screwdriver as well, I certainly don't see the need for powershell.
> Particularly in the recent history of "every day, another shell" on linux/mac.
You'll note that all of these shells try to be a better hammer. None of them go in the direction that powershell goes in.
Linux and its ecosystem evolved alongside bash. If somebody tried to make a thing, and said thing was difficult to script with bash, nobody used the thing. They would say it's "hard to use". So system facilities and applications that don't script well with a shell script like bash (or csh or zsh to tcsh...) never survived.
Basically, everything in linux automation is a nail, and bash is a very good hammer. DOS/Windows has had .bat scripts forever, which is not a particularly good hammer, but more importantly, Windows automation is very much not-nail like. You need a wrench and a socket set for many tasks, and CMD simply doesn't do that very well. (neither does bash for that matter) So powershell is a godsend. Meanwhile, us linux folks are sitting here with our hammer and all of our nails, and ... well, while I see that sometimes, it's maaaaybe nice to have a screwdriver as well, I certainly don't see the need for powershell.
> Particularly in the recent history of "every day, another shell" on linux/mac.
You'll note that all of these shells try to be a better hammer. None of them go in the direction that powershell goes in.
wokwokwok, cobbal and oefrha made excellent points in the sibling comments.
The only thing new PowerShell brings to the table is to pipe structured objects instead of only arbitrary data. And for that you don't need PowerShell itself: The power of the Linux shell isn't really the shell itself, it's in the powerful tools you can call from it and how you can interact with the Kernel and other components of the OS. The shell just gives you a simple interface and the ability to glue lots of small tools together. I think the reason we don't have a popular PowerShell clone, a "shell-with-objects", is that we would need to change how a lot of these tools handle basic data IO. I would love to see that, because sometimes parsing text is annoying, mental overhead; especially when filenames containing whitespaces are involved; but then there are always scripting languages waiting to help out (e.g. I tend to use perl kind of "super powerful shell script").
Also, what's "every day, another shell"? I have been using bash nearly two decades now, with the odd script written for pure sh in case it might be shipped to a customer. After Manjaro duped my into using zsh (I think they changed the default) I am now growing fond of the improved completion and history; but I could still stick to bash without being on a deprecated track.
The only thing new PowerShell brings to the table is to pipe structured objects instead of only arbitrary data. And for that you don't need PowerShell itself: The power of the Linux shell isn't really the shell itself, it's in the powerful tools you can call from it and how you can interact with the Kernel and other components of the OS. The shell just gives you a simple interface and the ability to glue lots of small tools together. I think the reason we don't have a popular PowerShell clone, a "shell-with-objects", is that we would need to change how a lot of these tools handle basic data IO. I would love to see that, because sometimes parsing text is annoying, mental overhead; especially when filenames containing whitespaces are involved; but then there are always scripting languages waiting to help out (e.g. I tend to use perl kind of "super powerful shell script").
Also, what's "every day, another shell"? I have been using bash nearly two decades now, with the odd script written for pure sh in case it might be shipped to a customer. After Manjaro duped my into using zsh (I think they changed the default) I am now growing fond of the improved completion and history; but I could still stick to bash without being on a deprecated track.
Powershell runs on Linux and macos too because of .NET Core/5+. The real reason is likely the same sort of people that are still typing Micro$oft in <current year> and keep spreading FUD that .NET isn't OS.
I have never heard anyone "spreading FUD that .NET isn't OS" but I have heard plenty of times from Mac and Linux users, "why would you want to use PowerShell" and I am mining this thread for answers, because I honestly don't know for myself.
And it's objectively true that .NET/PowerShell is targeting Windows users, (which if you're Microsoft, why wouldn't you do that?) so, assuming that you don't care about interoperability with Windows users, don't use Windows yourself, don't have any customers asking for PowerShell support for whatever XYZ widget you build... what are the compelling reasons to run PS on Linux or Mac?
Setting up .NET is an investment, and learning to program it is an investment, people invest in the Go, Rust, Ruby, Python, TypeScript, JS ecosystems because they are generally useful, and that extends to Windows people, but if I'm building a product targeting Mac or Linux (servers), what is the incentive for me to make my customers install the .NET runtime at the proper version and fiddle with .exe files (or am I completely off base about how it works?)
And it's objectively true that .NET/PowerShell is targeting Windows users, (which if you're Microsoft, why wouldn't you do that?) so, assuming that you don't care about interoperability with Windows users, don't use Windows yourself, don't have any customers asking for PowerShell support for whatever XYZ widget you build... what are the compelling reasons to run PS on Linux or Mac?
Setting up .NET is an investment, and learning to program it is an investment, people invest in the Go, Rust, Ruby, Python, TypeScript, JS ecosystems because they are generally useful, and that extends to Windows people, but if I'm building a product targeting Mac or Linux (servers), what is the incentive for me to make my customers install the .NET runtime at the proper version and fiddle with .exe files (or am I completely off base about how it works?)
.NET is still ignored a lot as consequence of FUD. But you are right, there is not much FUD.
The rest is spot on. Powershell has it space when you need manage windows and Linux Server using a shared platform. And that is where Microsoft puts it. As a .NET based management platform for services and operating systems on both, Linux and Windows.
The rest is spot on. Powershell has it space when you need manage windows and Linux Server using a shared platform. And that is where Microsoft puts it. As a .NET based management platform for services and operating systems on both, Linux and Windows.
> I have never heard anyone "spreading FUD that .NET isn't OS"
Observe /r/programming or HN for long enough.
> .NET/PowerShell is targeting Windows users, (which if you're Microsoft, why wouldn't you do that?)
Azure, for one. Azure's primary and preferred method of interaction instead of it's UI is with it's API, which is also available fully wrapped up as Powershell cmdlets which again run on all three OS's.
> Setting up .NET is an investment, and learning to program it is an investment,
> make my customers install the .NET runtime at the proper version and fiddle with .exe files
You don't, you either get them to install it's APT .deb file or <insert distro packaging format here> or wget the dotnet-install script. OR, you just build your app with .NET runtime packaged in .so file alongside your app.
Running the applications involves typing ./my-application which then runs the ELF binary. There is no .exe unless it's on Windows. It's the same install and run story that any of the other languages listed mentioned.
Observe /r/programming or HN for long enough.
> .NET/PowerShell is targeting Windows users, (which if you're Microsoft, why wouldn't you do that?)
Azure, for one. Azure's primary and preferred method of interaction instead of it's UI is with it's API, which is also available fully wrapped up as Powershell cmdlets which again run on all three OS's.
> Setting up .NET is an investment, and learning to program it is an investment,
> make my customers install the .NET runtime at the proper version and fiddle with .exe files
You don't, you either get them to install it's APT .deb file or <insert distro packaging format here> or wget the dotnet-install script. OR, you just build your app with .NET runtime packaged in .so file alongside your app.
Running the applications involves typing ./my-application which then runs the ELF binary. There is no .exe unless it's on Windows. It's the same install and run story that any of the other languages listed mentioned.
> Observe /r/programming or HN for long enough.
Well, I haven't seen those commenters before, and I'm still not excited about using .NET, (and I'm the type of person who you'd expect to be getting excited about a strongly-typed shell) so either that's not the driving factor here, or...
> Azure, for one. Azure's primary and preferred method of interaction instead of it's UI is with it's API, which is also available fully wrapped up as Powershell cmdlets which again run on all three OS's.
I have been getting into Azure, and I've found the `az cli` somewhat lacking, for example "why is the default 'get' behavior emitting a huge blob of JSON instead of printing a table that humans can read?" and I thought, maybe this is a reflection of the fact that they'd prefer you write an API client and build it into a portal for your customers rather than asking people on your team to use the CLI directly?
Seems you've confirmed this for me here. It would be nice to use a strongly typed interface rather than parsing JSON blobs, maybe I will end up checking that out!
Thanks :)
> > make my customers install the .NET runtime at the proper version and fiddle with .exe files > > You don't, you either get them to install it's APT .deb file or <insert distro packaging format here> or wget the dotnet-install script. OR, you just build your app with .NET runtime packaged in .so file alongside your app.
My point was, they do need to have or obtain the correct version of the runtime to go with your app, and if there are different apps with different maintenance cycles, that might mean you need multiple runtimes installed and a way of switching between them. That's a big deal!
If I want to adopt a runtime, I hope I'm adopting it for more than just one app. Now all of these apps need to be on the treadmill, actively maintained, or some upgrade might break, pinning me to a particular version, and then I'm stuck.
If there was ever a compelling problem to solve, it's here, although based on the breadth of languages and frameworks that still experience this problem in one way or another, I think it's likely unsolvable. You either need someone (a distro) running the compilers and checking that things still work together in concert with the maintainers of the upstream software, or you need to be statically linking, or get yourself something like venv/rvm that makes managing multiple versions of a runtime a low-overhead activity (so you can have 4 versions if that is what is required for your different maintenance cycles across different services, without needing to break those services out onto four separate servers just to accommodate the language runtime differences.)
Not to rule it out, does the .NET ecosystem have a great answer to this already?
(Edit: I guess "the web application" is the answer, broadly speaking! "Users" don't have to install anything besides a browser.)
> Running the applications involves typing ./my-application which then runs the ELF binary. There is no .exe unless it's on Windows. It's the same install and run story that any of the other languages listed mentioned.
So I'm assuming you can also statically link your .NET binaries and emit a fat binary that will work anywhere, but at tremendous cost in terms of disk usage, (but you makes your choices and you takes your chances) – like I was saying, this is not a problem unique to .NET either, Go binaries from the likes of GCloud and Azure for interacting with their APIs are all enormous, because they want to avoid this problem with their users and they have lots of libraries to pull in.
For me, the killer feature that makes Ruby ecosystem "worth adopting" is open source. You know how rare it is to encounter some Ruby gem which is not open to changes and inspection? I can think of exactly one time I found this, it did block me from using some software (AppDynamics bundled a native ext. with their Rubygem, it had wicked thread safety issues if you upgraded Ruby past a certain version... they did not provide the source, so enterprising customers couldn't fix the problem for themselves and contribute it upstream...) I've been using Ruby professionally for about 14 years, and I saw this issue exactly once.
And that was a choice that one vendor made, and such a rare event that I would never think to let it reflect badly on the language. Go does not seem to have these issues as commonly (where somebody distributes a go package as binary-only) even though the language is not interpreted so it can happen and it wouldn't be unusual or even "against the grain."
This is why I thought of Ruby being primarily executable as an interpreted language as "the guard" against this sort of thing happening in Ruby ecosystem.
Well, I haven't seen those commenters before, and I'm still not excited about using .NET, (and I'm the type of person who you'd expect to be getting excited about a strongly-typed shell) so either that's not the driving factor here, or...
> Azure, for one. Azure's primary and preferred method of interaction instead of it's UI is with it's API, which is also available fully wrapped up as Powershell cmdlets which again run on all three OS's.
I have been getting into Azure, and I've found the `az cli` somewhat lacking, for example "why is the default 'get' behavior emitting a huge blob of JSON instead of printing a table that humans can read?" and I thought, maybe this is a reflection of the fact that they'd prefer you write an API client and build it into a portal for your customers rather than asking people on your team to use the CLI directly?
Seems you've confirmed this for me here. It would be nice to use a strongly typed interface rather than parsing JSON blobs, maybe I will end up checking that out!
Thanks :)
> > make my customers install the .NET runtime at the proper version and fiddle with .exe files > > You don't, you either get them to install it's APT .deb file or <insert distro packaging format here> or wget the dotnet-install script. OR, you just build your app with .NET runtime packaged in .so file alongside your app.
My point was, they do need to have or obtain the correct version of the runtime to go with your app, and if there are different apps with different maintenance cycles, that might mean you need multiple runtimes installed and a way of switching between them. That's a big deal!
If I want to adopt a runtime, I hope I'm adopting it for more than just one app. Now all of these apps need to be on the treadmill, actively maintained, or some upgrade might break, pinning me to a particular version, and then I'm stuck.
If there was ever a compelling problem to solve, it's here, although based on the breadth of languages and frameworks that still experience this problem in one way or another, I think it's likely unsolvable. You either need someone (a distro) running the compilers and checking that things still work together in concert with the maintainers of the upstream software, or you need to be statically linking, or get yourself something like venv/rvm that makes managing multiple versions of a runtime a low-overhead activity (so you can have 4 versions if that is what is required for your different maintenance cycles across different services, without needing to break those services out onto four separate servers just to accommodate the language runtime differences.)
Not to rule it out, does the .NET ecosystem have a great answer to this already?
(Edit: I guess "the web application" is the answer, broadly speaking! "Users" don't have to install anything besides a browser.)
> Running the applications involves typing ./my-application which then runs the ELF binary. There is no .exe unless it's on Windows. It's the same install and run story that any of the other languages listed mentioned.
So I'm assuming you can also statically link your .NET binaries and emit a fat binary that will work anywhere, but at tremendous cost in terms of disk usage, (but you makes your choices and you takes your chances) – like I was saying, this is not a problem unique to .NET either, Go binaries from the likes of GCloud and Azure for interacting with their APIs are all enormous, because they want to avoid this problem with their users and they have lots of libraries to pull in.
For me, the killer feature that makes Ruby ecosystem "worth adopting" is open source. You know how rare it is to encounter some Ruby gem which is not open to changes and inspection? I can think of exactly one time I found this, it did block me from using some software (AppDynamics bundled a native ext. with their Rubygem, it had wicked thread safety issues if you upgraded Ruby past a certain version... they did not provide the source, so enterprising customers couldn't fix the problem for themselves and contribute it upstream...) I've been using Ruby professionally for about 14 years, and I saw this issue exactly once.
And that was a choice that one vendor made, and such a rare event that I would never think to let it reflect badly on the language. Go does not seem to have these issues as commonly (where somebody distributes a go package as binary-only) even though the language is not interpreted so it can happen and it wouldn't be unusual or even "against the grain."
This is why I thought of Ruby being primarily executable as an interpreted language as "the guard" against this sort of thing happening in Ruby ecosystem.
My answer is: I’ve been using sh/csh/tcsh/bash/zsh/fish for almost 30 years at this point. I’ve used powershell on windows, and it’s not bad, but it doesn’t give me anything useful on Linux I don’t already have with bash or zsh. And whenever a script needs more power, I reach for Python.
(Maybe I should xonsh instead? But the question for me isn’t “why not pwsh?” But rather “why pwsh?”)
(Maybe I should xonsh instead? But the question for me isn’t “why not pwsh?” But rather “why pwsh?”)
The actual real reason is *nix had mature shell scripting many years before powershell was conceived.
For powershell to "take off" on non-Windows platforms, many people need to adopt it and for many people to adopt it, it needs to solve some critical problems the existing solutions don't solve well.
I think pretty clearly, powershell doesn't do that.
(I think I personally would be an easy candidate to use it on Mac... I know/use powershell pretty much daily at my day job -- so there's a minimal learning curve and I still haven't seen any reason to use it on various Mac side projects and jobs. I just do bash/zsh scripts. If it was built in maybe I'd reconsider.)
For myself, I know powershell reasonably well from my day job
Sometimes people will switch to something new just because it's new, but for , generthe new thing has to have some
For powershell to "take off" on non-Windows platforms, many people need to adopt it and for many people to adopt it, it needs to solve some critical problems the existing solutions don't solve well.
I think pretty clearly, powershell doesn't do that.
(I think I personally would be an easy candidate to use it on Mac... I know/use powershell pretty much daily at my day job -- so there's a minimal learning curve and I still haven't seen any reason to use it on various Mac side projects and jobs. I just do bash/zsh scripts. If it was built in maybe I'd reconsider.)
For myself, I know powershell reasonably well from my day job
Sometimes people will switch to something new just because it's new, but for , generthe new thing has to have some
In the late 2000s or early 2010s is when I first read about PowerShell (v1? it was still bleeding edge) and my jaws dropped.
Ability to work with both .NET and COM objects? Piping objects and not strings?
Absolutely amazing and useful tech, and I had to reread to make sure I wasn’t reading about some future plan.
I wonder which division pushed hard to demote; the Windows division?
Ability to work with both .NET and COM objects? Piping objects and not strings?
Absolutely amazing and useful tech, and I had to reread to make sure I wasn’t reading about some future plan.
I wonder which division pushed hard to demote; the Windows division?
I have worked at Microsoft off and on for more than 20 years and it is insane how many disaster stories boil down to super horrible Windows management.
“.NET cross platform?” -> Windows screwed it up
“Phones” -> Windows screwed it up
“Azure Linux VM” -> Windows screwed it up (but thankful we fired them and fixed it)
One of best things Satya has done is essentially fire almost all of these morons.
“.NET cross platform?” -> Windows screwed it up
“Phones” -> Windows screwed it up
“Azure Linux VM” -> Windows screwed it up (but thankful we fired them and fixed it)
One of best things Satya has done is essentially fire almost all of these morons.
"Remember the human". Do you start with the assumption that the product has to fit into Windows and do things the Windows way? Or do you start with the assumption that humans are going to use the product and make it in such a way that people can and want to use it.
Question for the more seasoned Mac/Linux folks on HN:
Powershell has been a gift in getting things accomplished in Windows. But one thing I've also come to enjoy using it for is quick and dirty interactions and scripting with REST APIs.
Things like Invoke-WebRequest, ConvertTo-Json/ConvertFrom-Json, Export-CSV, piping between almost everything, and the results being passed around like an object that I can use SQL-ish Select queries against, etc.
I find myself feeling like I'm missing something helpful when I'm on a Mac/Linux device. Is there a similar go to in the Mac/Linux world for this type of stuff? My current thinking is that I either have to start picking up Python or building a mental map of wget/awk/grep type commands that can be chained together for a similar effect, but I thought it best to try to learn from the wisdom of others first :-)
Powershell has been a gift in getting things accomplished in Windows. But one thing I've also come to enjoy using it for is quick and dirty interactions and scripting with REST APIs.
Things like Invoke-WebRequest, ConvertTo-Json/ConvertFrom-Json, Export-CSV, piping between almost everything, and the results being passed around like an object that I can use SQL-ish Select queries against, etc.
I find myself feeling like I'm missing something helpful when I'm on a Mac/Linux device. Is there a similar go to in the Mac/Linux world for this type of stuff? My current thinking is that I either have to start picking up Python or building a mental map of wget/awk/grep type commands that can be chained together for a similar effect, but I thought it best to try to learn from the wisdom of others first :-)
Curl, jq is the good answer here.
More from the fringe, I'm quite enjoying zx, a really nodejs powered scripting environment. https://github.com/google/zx
Covered somewhat in ZX 3.0 https://news.ycombinator.com/item?id=28195580 (189 points, 8 months ago, 163 points)
More from the fringe, I'm quite enjoying zx, a really nodejs powered scripting environment. https://github.com/google/zx
Covered somewhat in ZX 3.0 https://news.ycombinator.com/item?id=28195580 (189 points, 8 months ago, 163 points)
These are only vaguely comparable. It’s like saying assembly language is a substitute for something elegant in Haskell.
Technically true in some sense, but not really.
Technically true in some sense, but not really.
Zx really intends to be a scripting language (and i think it does a good job) that happens to be javascript.
Personally I feel like thenbiggest missing piece ZX would beed to be a good straight up competitor to bash or zsh would be better interactive modes. A node repl.os ok, uses libreadline & has lots.of capabilities, but zx feels biased towards scripting, not am actual shell.
I dont see why you think zx couldnt be a substitute. Particularly & especially in the context of a discussion on powershell, where we are clearly already opening the gates of heterodoxy already.
Personally I feel like thenbiggest missing piece ZX would beed to be a good straight up competitor to bash or zsh would be better interactive modes. A node repl.os ok, uses libreadline & has lots.of capabilities, but zx feels biased towards scripting, not am actual shell.
I dont see why you think zx couldnt be a substitute. Particularly & especially in the context of a discussion on powershell, where we are clearly already opening the gates of heterodoxy already.
One of the other responses mentioned Nushell, which is a direct substitute for PowerShell in a meaningful sense: an interactive shell, structured pipelines, formatting as the final step of a pipeline, etc...
Anything else tends to be either a random bag of unrelated tools sticky-taped together, OR a heavyweight programming language.
The equivalent of JavaScript or Python is C#, CS-Script, or F# Interactive. Those are also full-featured programming languages.
I can process files in just a couple of lines of C#, but I still reach for PowerShell when doing this kind of thing unless I really need higher throughputs or complex processing.
Anything else tends to be either a random bag of unrelated tools sticky-taped together, OR a heavyweight programming language.
The equivalent of JavaScript or Python is C#, CS-Script, or F# Interactive. Those are also full-featured programming languages.
I can process files in just a couple of lines of C#, but I still reach for PowerShell when doing this kind of thing unless I really need higher throughputs or complex processing.
I feel like ZX has these features already. Rather than choosing to believe there is a meaningful unbridgeable hard fast line, I think it's beneficial to consider case-by-case what features & capabilities are important & what enables smooth, light operation.
Node still isnt `perl -pie` level easy & hybrid, but again I think it's altogether pretty slick & simple with zx today.
The interactive repl doesnt look like a shell but it has quite advanced editing, comes out ahead in many ways (value previews). There's no ability to generate new autocompletion capabilities in the built in repl, but one could potentially yse an IDE and LSP with a repl. The potential for non-monolithic shells is interesting, that a shell might be separated into editor, engine, & plugins.
There is pretty ok pipeline handling via streams, which finally have decent & well embraced standards. https://github.com/google/zx/blob/main/docs/pipelines.md
Formatting as final step Im not as familiar with but it sounds like one could easily map or swizzle their stream output pretty easily. Particularly with better ndjson I think the potential here is high.
Overall I think there are distinctions, characterizations between shell and other languages, but it's less inherent to me; we simply havent spent much effort identifying what it is that makes operating the command line easy, flexible, and have even less work trying to port those ideas & riff off them. Even an early simple thin standard library like zx achieving so much success at becoming putty or glue, alike a shell, so quickly, indicates to me that it's worth doubting our long held certainty that these things are absolutely apart & different.
Node still isnt `perl -pie` level easy & hybrid, but again I think it's altogether pretty slick & simple with zx today.
The interactive repl doesnt look like a shell but it has quite advanced editing, comes out ahead in many ways (value previews). There's no ability to generate new autocompletion capabilities in the built in repl, but one could potentially yse an IDE and LSP with a repl. The potential for non-monolithic shells is interesting, that a shell might be separated into editor, engine, & plugins.
There is pretty ok pipeline handling via streams, which finally have decent & well embraced standards. https://github.com/google/zx/blob/main/docs/pipelines.md
Formatting as final step Im not as familiar with but it sounds like one could easily map or swizzle their stream output pretty easily. Particularly with better ndjson I think the potential here is high.
Overall I think there are distinctions, characterizations between shell and other languages, but it's less inherent to me; we simply havent spent much effort identifying what it is that makes operating the command line easy, flexible, and have even less work trying to port those ideas & riff off them. Even an early simple thin standard library like zx achieving so much success at becoming putty or glue, alike a shell, so quickly, indicates to me that it's worth doubting our long held certainty that these things are absolutely apart & different.
Is there a similar go to in the Mac/Linux worlds? Yeah, it's called Powershell 7! Powershell was ported to cross platform dotnet a few years back. Currently running some Powershell scripts in production on a Linux box.
"You can use powershell" isnt quite the same as asking what the open source world does. Adoption of powershell on Linux/Mac is tiny. If you show up on a random system, it almost certainly will not be available.
It's good to know powershell is cross platform now. Good to know this can be an option. But I'd also say the original question still deserves more exploration & thought, that asking what the romans do in rome is good to know too.
It's good to know powershell is cross platform now. Good to know this can be an option. But I'd also say the original question still deserves more exploration & thought, that asking what the romans do in rome is good to know too.
[deleted]
That random system might only have the dash shell and busybox. What are you going to do then?
This is the fundamental differentiation of Powershell, right? UNIX operates on text streams while Powershell operates on structured data. It is in a better position to do this kind of stuff.
That aside, a lot of contemporary cloudy CLIs will now speak json on stdin/out and JQ will make any json transformations you can imagine.
That aside, a lot of contemporary cloudy CLIs will now speak json on stdin/out and JQ will make any json transformations you can imagine.
There are a few projects that take inspiration from PowerShell, but they haven't got mass adoption. I have hopes that Nushell will be a success when it gets to 1.0:
https://www.nushell.sh/
https://www.nushell.sh/
Powershell 7 is cross-platform.
Yes, you can use Python just about anywhere, and it is arguably more sane/readable. Prefer httpie over curl at the command-line as well.
curl, jq
Not a seasoned mac/Linux user, but would powershell core not work? I believe it's cross platform?
Question for the PowerShell afficionados: Do you consider PowerShell to be "something we can count on to exist on Windows systems, in the absence of Bourne-like shells" - or is it "a superior alternative to Bourne shells which only got traction on Windows because Bourne is too deeply embedded in the Unix world"?
the latter, though I may have some Stockholm syndrome. killer features:
* objects are streamed, not text. I look upon sed and awk and their ilk as stone knives and bear skins. why not just dot into fields?
* first-class interaction with libraries. I can import managed DLLs and call their methods. I don't have to build weird little one-off tools or expose porcelain. I can get at everything, it's profoundly hackable in an un-Windows way.
* the language is vectorized - basically like broadcast operators in something like NumPy. $x.foo gives you x's foo if x is an object, or an array of foos if x is an array of objects. it's really really nice.
* separate commands in one binary and argument (sets) are first-class. there's consistent rules about what "-i" will be short for. personally, I can pull all the valid commands and arguments automatically into my accessibility software for voice typing. the whole standard "verb-noun" thing also makes commands be what you expect and discoverable.
things I don't like include the language itself, its weird bindings to .NET (it predated the C# dynamic support and modern collection types), the restriction to .NET, bad support for streams (not sequences), the slowness, and the syntax looks a bit goofy. but it's worth the warts.
* objects are streamed, not text. I look upon sed and awk and their ilk as stone knives and bear skins. why not just dot into fields?
* first-class interaction with libraries. I can import managed DLLs and call their methods. I don't have to build weird little one-off tools or expose porcelain. I can get at everything, it's profoundly hackable in an un-Windows way.
* the language is vectorized - basically like broadcast operators in something like NumPy. $x.foo gives you x's foo if x is an object, or an array of foos if x is an array of objects. it's really really nice.
* separate commands in one binary and argument (sets) are first-class. there's consistent rules about what "-i" will be short for. personally, I can pull all the valid commands and arguments automatically into my accessibility software for voice typing. the whole standard "verb-noun" thing also makes commands be what you expect and discoverable.
things I don't like include the language itself, its weird bindings to .NET (it predated the C# dynamic support and modern collection types), the restriction to .NET, bad support for streams (not sequences), the slowness, and the syntax looks a bit goofy. but it's worth the warts.
I found -- when I last did anything in Powershell years ago -- that third point of yours to be incredibly frustrating. I wanted to iterate over a list, but sometimes I would get back a non-iterable solo object, or a None-like object, and my iteration would fail.
I ended up doing a lot of testing to see what my returned results were.
I ended up doing a lot of testing to see what my returned results were.
As with any large software project, there are at least few features in PowerShell that are confusing, inconsistent, or both.
Auto-vectorization is one of them; usually it "just works", but can be a PITA when dealing with, e.g., pipelines returning sequences you'd prefer to keep separate.
Another is that PowerShell error handling, while robust and powerful, can be difficult to implement properly, especially when "the right thing" isn't what PowerShell expects. Case in point: originally, PowerShell handled standard error output from external commands specially, wrapping lines of stderr output in error objects. While convenient in some cases, this made it unnecessarily difficult to work with external commands that output to stderr in non-failure cases, and was therefore changed in newer versions of PowerShell.
A final, non-language example is cmdlet availability on non-Server Windows versions. While PowerShell mostly has feature parity between desktop and server SKUs, there are at least a few non-Server-specific cmdlets that only work with Windows Server. The only example that comes immediately to mind is the ...-WindowsFeature set of cmdlets to manage installed Windows features; while present on client Windows systems, they fail with an error message unless the target system is running Windows Server. This is a particularly mystifying omission because dism.exe provides an equivalent command-line interface that works everywhere.
Auto-vectorization is one of them; usually it "just works", but can be a PITA when dealing with, e.g., pipelines returning sequences you'd prefer to keep separate.
Another is that PowerShell error handling, while robust and powerful, can be difficult to implement properly, especially when "the right thing" isn't what PowerShell expects. Case in point: originally, PowerShell handled standard error output from external commands specially, wrapping lines of stderr output in error objects. While convenient in some cases, this made it unnecessarily difficult to work with external commands that output to stderr in non-failure cases, and was therefore changed in newer versions of PowerShell.
A final, non-language example is cmdlet availability on non-Server Windows versions. While PowerShell mostly has feature parity between desktop and server SKUs, there are at least a few non-Server-specific cmdlets that only work with Windows Server. The only example that comes immediately to mind is the ...-WindowsFeature set of cmdlets to manage installed Windows features; while present on client Windows systems, they fail with an error message unless the target system is running Windows Server. This is a particularly mystifying omission because dism.exe provides an equivalent command-line interface that works everywhere.
I love the idea of PowerShell, especially as scripts become more complex, having something closer to a “real” language and with decent debugger support is great.
However it’s just unintuitive enough, with enough sharp corners, to be a real pain. I find if I haven’t used it for more than a couple weeks, then even doing trivial things require significant time and about a dozen browser tabs of docs.
That said, trying to remember how to use the various *nix tools like curl, find, tar, etc. and wrap them in a bash script isn’t easy either. No free lunch I guess.
However it’s just unintuitive enough, with enough sharp corners, to be a real pain. I find if I haven’t used it for more than a couple weeks, then even doing trivial things require significant time and about a dozen browser tabs of docs.
That said, trying to remember how to use the various *nix tools like curl, find, tar, etc. and wrap them in a bash script isn’t easy either. No free lunch I guess.
Cygwin has been a reliable features-complete alternative IMHO
How is Cygwin comparable? That's like saying Wine can be compared to cmd.exe.
Cygwin brings me a compatible-enough layer on top of windows that I can reuse scripts. It is comparable as it gives me a CLI, and to hen as it is not infected by Microsoftisms it gives me a warm feeling of safety..
... Neither?
It's a superior alternative to cmd.exe. bash has never been a serious contender for Windows. Before PS you always wrote .bat scripts for cmd.exe (or .vbs for cscript.exe if you were really depraved). Nobody except Linux-first FOSS authors would expect Windows users to have cygwin / msys / mingw32 installed.
PS gave us a saner choice, though we would still usually bundle it with a .bat wrapper, just to a) make it double-clickable and b) set `-ExecutionPolicy Unrestricted`.
If you're asking "is PS better than bash", then sure it's better in some ways and worse in others, but that question only makes sense on Linux where bash is actually an option.
It's a superior alternative to cmd.exe. bash has never been a serious contender for Windows. Before PS you always wrote .bat scripts for cmd.exe (or .vbs for cscript.exe if you were really depraved). Nobody except Linux-first FOSS authors would expect Windows users to have cygwin / msys / mingw32 installed.
PS gave us a saner choice, though we would still usually bundle it with a .bat wrapper, just to a) make it double-clickable and b) set `-ExecutionPolicy Unrestricted`.
If you're asking "is PS better than bash", then sure it's better in some ways and worse in others, but that question only makes sense on Linux where bash is actually an option.
But instead of coming up with PS, it would have been pretty straightforward to just install bash on Windows. Someone chose to go the PS way rather than the bash way. My question is what the reason was for making this choice.
> Nobody except Linux-first FOSS authors
Bourne shell and its predecessors and successors are traditional and common on most computer systems since the early 1970s (starting with the Thompson shell in 1971; see: https://en.wikipedia.org/wiki/Unix_shell )
so, I would argue actually the other way around. "Everybody except Windows-only closed-source authors would expect people to have bash or similar shell working." The question is, why go for PS instead of adopting a regular shell.
> Nobody except Linux-first FOSS authors
Bourne shell and its predecessors and successors are traditional and common on most computer systems since the early 1970s (starting with the Thompson shell in 1971; see: https://en.wikipedia.org/wiki/Unix_shell )
so, I would argue actually the other way around. "Everybody except Windows-only closed-source authors would expect people to have bash or similar shell working." The question is, why go for PS instead of adopting a regular shell.
J. Snover started out bringing Unix (VMS) shell to Windows, and it isn't a good fit. Everything isn't text and so the Unix shell tools are pretty limited. So they made something which is a good fit for Windows everything-is-an-API instead.
> "The question is, why go for PS instead of adopting a regular shell."
The question is, why stick with 1970s stuff when you can have progress?
> "The question is, why go for PS instead of adopting a regular shell."
The question is, why stick with 1970s stuff when you can have progress?
I'm really not sure what your point is.
>Someone chose to go the PS way rather than the bash way.
Are you asking about users or the Microsoft employees who work on Windows? Users don't want to install either bash or PS, which is why before PS existed all scripts were written for cmd.exe which was guaranteed to be available. Microsoft employees would have no benefit from adding bash to Windows given its license, and PS integrates better with the OS anyway. The author of PS is already on record that one of the original reasons was to integrate better with WMI etc [1]; given how hard / impossible it is to munge the output of ls etc in bash it should be no surprise than an object-based shell with saner expansion rules works better.
>> Nobody except Linux-first FOSS authors
>Bourne shell and its predecessors and successors are [...]
You don't have to give me a history lesson. What you said has nothing to do with the fact that the only people who expected Windows users to have bash were Linux software authors, because their software only supported being built by bash scripts (and required make, configure, perl, what have you). Windows software itself, whether open or closed source, was built using cmd.exe scripts or VS project files.
[1]: https://stackoverflow.com/a/573861/545475
>Someone chose to go the PS way rather than the bash way.
Are you asking about users or the Microsoft employees who work on Windows? Users don't want to install either bash or PS, which is why before PS existed all scripts were written for cmd.exe which was guaranteed to be available. Microsoft employees would have no benefit from adding bash to Windows given its license, and PS integrates better with the OS anyway. The author of PS is already on record that one of the original reasons was to integrate better with WMI etc [1]; given how hard / impossible it is to munge the output of ls etc in bash it should be no surprise than an object-based shell with saner expansion rules works better.
>> Nobody except Linux-first FOSS authors
>Bourne shell and its predecessors and successors are [...]
You don't have to give me a history lesson. What you said has nothing to do with the fact that the only people who expected Windows users to have bash were Linux software authors, because their software only supported being built by bash scripts (and required make, configure, perl, what have you). Windows software itself, whether open or closed source, was built using cmd.exe scripts or VS project files.
[1]: https://stackoverflow.com/a/573861/545475
Let's be real honest here, bash sucks.
"common on most computer systems since the early 1970s" yes, that's exactly the problem, it still thinks spaces on filenames are an "exception", just as a start. It knows about lines but barely.
PS has native json support.
"common on most computer systems since the early 1970s" yes, that's exactly the problem, it still thinks spaces on filenames are an "exception", just as a start. It knows about lines but barely.
PS has native json support.
> most computer systems since the early 1970s
How are you defining "most"? Back in those days there was much more diversity in the computing landscape.
How are you defining "most"? Back in those days there was much more diversity in the computing landscape.
Simply because on Unix, configuration is text files; bash and the gnu utils work with text. In Windows, it's an API driven O/S; powershell uses objects, but will coerce output to strings to allow text parsing if needed.
Bash as a shell is not so outstanding. It is the gnu tools and the other command line first Landscape. So bash on windows can never fly because these tools are not natively present (cygwin and friends are just awkward).
So Powershell (and the new terminal) gives us this whole package with its build-in, service and windows provided commandlets.
Consequently: bash will never beat PS on Windows except when someone provided a gnu tools and hundreds of other command line tools for windows.
So Powershell (and the new terminal) gives us this whole package with its build-in, service and windows provided commandlets.
Consequently: bash will never beat PS on Windows except when someone provided a gnu tools and hundreds of other command line tools for windows.
On the topic of Powershell on Linux I think the story there could be different, however Powershell violates the core philosophy of Linux so hard (mit vs. GPL, pipe-and-filter vs loaded DLLs, ...) that Powershell will never be something integral and natural fitting there.
> mit vs. GPL
By this measure, we shouldn't be using X or Wayland because they're MIT.
> pipe-and-filter vs loaded DLLs
At first I didn't understand what you were referring to, but I realized you were talking about cmdlets. In that regard, PowerShell is more like a scripting language than it is like a traditional Unix shell.
The more "Unix-like" approach would be to write thin command-line wrappers around the libraries you want to use. If I'm not mistaken, this is how projects like LAME and FFmpeg are implemented.
By this measure, we shouldn't be using X or Wayland because they're MIT.
> pipe-and-filter vs loaded DLLs
At first I didn't understand what you were referring to, but I realized you were talking about cmdlets. In that regard, PowerShell is more like a scripting language than it is like a traditional Unix shell.
The more "Unix-like" approach would be to write thin command-line wrappers around the libraries you want to use. If I'm not mistaken, this is how projects like LAME and FFmpeg are implemented.
Regards the licencing: you are right. I was a vit blinded by the core gnu tools.
Tiny wrappers do not work since .NET, while being very Performanz will never be C like tiny.
Tiny wrappers do not work since .NET, while being very Performanz will never be C like tiny.
> Tiny wrappers do not work since .NET, while being very Performanz will never be C like tiny.
I meant tiny wrappers around non-.NET libraries, to approximate the functionality you get in PowerShell in a traditional UNIX shell.
I meant tiny wrappers around non-.NET libraries, to approximate the functionality you get in PowerShell in a traditional UNIX shell.
[deleted]
WSL2 availability makes powershell redundant for most server oriented dev tasks.
Translation: WSL2 makes running traditional tools for managing *nix servers easier from a Windows machine.
Dev tasks. Yes. Admin tasks: not so much. The ask is not to create a windows client env to administer Linux machine. The ask is one management surface for Linux and Windows servers.
PowerShell works on fundamentally different principles than do traditional Unix shells. Unix shells are for loosely coupling small "do one thing and do it well" programs. PowerShell can kinda do this, but its strengths lie in the "object streaming" features which aren't based on external processes at all but on loading .NET libraries with a special API, called cmdlets. In this respect PowerShell is a bit more like the VMS command processor, or using Python or Tcl as a shell. To add a command to a Unix shell, you need but drop an executable in your path. To add a command to PowerShell that takes advantage of PowerShell's features, you need to write a cmdlet in a language like C# and then install the cmdlet. This is also why PowerShell takes so long to boot up: it's probing for and loading installed cmdlets.
For these reasons I do not consider PowerShell to be directly comparable to Unix shells, but it is an essential part of the Windows toolkit because no one wants to use the MS-DOS-like cmd.exe for anything serious.
For these reasons I do not consider PowerShell to be directly comparable to Unix shells, but it is an essential part of the Windows toolkit because no one wants to use the MS-DOS-like cmd.exe for anything serious.
Honestly I enjoy writing powershell more than bash scripts. Bash syntax is arcane and sometimes inconsistent where as powershell 7+ is fairly comfortable syntax.
However, powershell does often feel cludgy and I often have have to figure out how to do more complex things. Not a perfect solution but it integrates with Windows nicely.
However, powershell does often feel cludgy and I often have have to figure out how to do more complex things. Not a perfect solution but it integrates with Windows nicely.
> "Do you consider PowerShell to be "something we can count on to exist on Windows systems"
Once, yes; then they renamed it "Windows PowerShell" and deprecated it so it's no longer being developed. Instead they started trying to appeal to Linux users with new cross-platform "PowerShell" which you have to install separately. Windows PowerShell is increasingly falling behind that in performance and compatibility. We're heading away from "PowerShell included" back to the old world of "if you have to download and install something to get away from this abandonware legacy thing, why not Python or node.js?".
> "a superior alternative to Bourne shells which only got traction on Windows because Bourne is too deeply embedded in the Unix world"?"
It's a superior alternative to Bourne shells on Windows, and because it's basically Microsoft-Perl or Microsoft-Clunky-Python as well as being a shell, as in - it's more capable than Unix shell because it's a kitchen sink of scripting and programming language as well as command line.
Once, yes; then they renamed it "Windows PowerShell" and deprecated it so it's no longer being developed. Instead they started trying to appeal to Linux users with new cross-platform "PowerShell" which you have to install separately. Windows PowerShell is increasingly falling behind that in performance and compatibility. We're heading away from "PowerShell included" back to the old world of "if you have to download and install something to get away from this abandonware legacy thing, why not Python or node.js?".
> "a superior alternative to Bourne shells which only got traction on Windows because Bourne is too deeply embedded in the Unix world"?"
It's a superior alternative to Bourne shells on Windows, and because it's basically Microsoft-Perl or Microsoft-Clunky-Python as well as being a shell, as in - it's more capable than Unix shell because it's a kitchen sink of scripting and programming language as well as command line.
(Not an aficionado) I feel like it is superior in many ways, but the syntax and case sensitivity have always been a barrier for me. It’s still worth it though when it’s the right tool. I don’t do Windows stuff often though so it’s always jarring coming back to it from bash.
> syntax and case sensitivity have always been a barrier for me
Can you clarify that a little? PowerShell isn't case sensitive, and the syntax is just a mixture of traditional shell syntax (pipes, operators like -eq/-ne/-lt/-gt, etc.) and conventional C#-like syntax (if/elseif/else, switch, ?:, ??, try/catch/finally/throw, etc.).
Can you clarify that a little? PowerShell isn't case sensitive, and the syntax is just a mixture of traditional shell syntax (pipes, operators like -eq/-ne/-lt/-gt, etc.) and conventional C#-like syntax (if/elseif/else, switch, ?:, ??, try/catch/finally/throw, etc.).
There’s some gotchas with case sensitivity that I honestly can’t remember but I think it was related to some of the more C#-y bits.
As for syntax it really is the .NET elements & the relative verbosity of common things you’d interact with that just make it feel very foreign to me personally. This probably has more to do with Windows and .NET than PowerShell itself though.
As for syntax it really is the .NET elements & the relative verbosity of common things you’d interact with that just make it feel very foreign to me personally. This probably has more to do with Windows and .NET than PowerShell itself though.
> in the absence of Bourne-like shells
I never had "Oh I would really liked to have *sh on this Win machine". Some GNU tools, like grep (just because findstr has it's own arcaneties) or sed - but neither of them is the part the shell itself.
Sure, before 2012 if you wanted a little more flow control than provided by cmd you had not really many options (and if you needed portability you would need to use VB/Jscript, not a 3rd party tool), but since then you have PS3 at worst (on 2012/R2), or at least PS5.1 everywhere else, including client SKUs.
And writing even not a complex script with a bunch of if..else is way, way easier in PS, be it for a Win or a *nix machine.
I never had "Oh I would really liked to have *sh on this Win machine". Some GNU tools, like grep (just because findstr has it's own arcaneties) or sed - but neither of them is the part the shell itself.
Sure, before 2012 if you wanted a little more flow control than provided by cmd you had not really many options (and if you needed portability you would need to use VB/Jscript, not a 3rd party tool), but since then you have PS3 at worst (on 2012/R2), or at least PS5.1 everywhere else, including client SKUs.
And writing even not a complex script with a bunch of if..else is way, way easier in PS, be it for a Win or a *nix machine.
Dealing with objects rather than strings and parameter autocompletion give massively better discoverability than other shells I've used.
Being able to use all of the .Net classes trivially is also staggeringly useful.
Being able to use all of the .Net classes trivially is also staggeringly useful.
The latter. I say that as someone who only works with nix systems for the last 5 years. I still write some powershell for stuff at home. I prefer Hyper-V as a hypervisor and use it there.
But the current state makes sense. Everything in Windows is COM, .NET, or a derivative thereof. Having a scripting language that natively speaks to these technologies in a flexible manner is a natural extension.
nix is a lot more of the file based stuff and so a shell language that makes it easy to run a series of tools that operate on text is natural (I.e. awk, sed, grep, xargs)
But the current state makes sense. Everything in Windows is COM, .NET, or a derivative thereof. Having a scripting language that natively speaks to these technologies in a flexible manner is a natural extension.
nix is a lot more of the file based stuff and so a shell language that makes it easy to run a series of tools that operate on text is natural (I.e. awk, sed, grep, xargs)
It's a better design, imo.
Have you ever wanted to write a command line executable and gotten hung up on I/o and parameter parsing?
With PowerShell you can write a cmdlet in C# as a PowerShell module and have strongly typed input and output parameters for free. It's a revelation.
As as scripting language, it's fine but for me the killer feature is being able to easily extend it in a non-scripting language.
Have you ever wanted to write a command line executable and gotten hung up on I/o and parameter parsing?
With PowerShell you can write a cmdlet in C# as a PowerShell module and have strongly typed input and output parameters for free. It's a revelation.
As as scripting language, it's fine but for me the killer feature is being able to easily extend it in a non-scripting language.
Its far superior, like light years superior. PowerShell will exist, entire MS ecosystem is now based on it. That fear has passed years ago, especially when it got cross-platform. I expect actually to see more pwsh on linux and even OTB pwsh linux distribution (heck, I will make it myself if needed when I get retired).
Title has a typo: It's "Snover".
If I had to guess why, maybe because PowerShell is a little “busy”. It always feels unclear whether he was trying to make something similar to Unix Shell or a shell for the .NET environment. It’s greyed somewhere in between in a confusing and inconvenient way. Something as simple as a diff requires using objects, it just doesn’t feel like it was designed with SysAds in mind.
My guess was it had to do with marketing, sort of like how JS started off as a Scheme dialect, but higher ups enforced Java Syntax. .NET was pretty new at the time.
My guess was it had to do with marketing, sort of like how JS started off as a Scheme dialect, but higher ups enforced Java Syntax. .NET was pretty new at the time.
As a sysadmin, you can pull pwsh from my cold dead hands. Evrything being an object is a feature, not a bug. Going back to bash feels like going back a half century.
It has its rough eges though. The one that pisses me off is psremote. Complex to set up, takes forever to come online after a reboot, runs in a network context which isn't allowed to interact with certain windows APIs, not the least windows update. How you create a remote shell that cannot do something as simple as updating the OS is beyond my comprehension.
Interesting story. I have a love/hate relationship with Powershell. I was proficient in the CMD batch language, but decided to develop a set of SQL scripts in Powershell. With the object integration, it's a good enviornment for Windows; if I need to do anything in Windows, for example color-coded error output, PS does that for me.
The object-oriented .NET design did not work for me in preprocessing text files for those SQL queries. PS takes 15 minutes to do what Strawberry Perl (the Windows port of Perl) does in 3 seconds with a one-liner regex. Perl is a better choice for that kind of thing, I know, but the orders of magntiude difference in processing files line-by-line was surprising.
I've been contemplating migrating scripts to Python so that we would be environment agnostic, but it's not a priority. (Turns out a LInux cloud instance costs more than a Windows instance. Our company signed a huge deal with Microsoft and everything is being pushed in that direction now.)
The object-oriented .NET design did not work for me in preprocessing text files for those SQL queries. PS takes 15 minutes to do what Strawberry Perl (the Windows port of Perl) does in 3 seconds with a one-liner regex. Perl is a better choice for that kind of thing, I know, but the orders of magntiude difference in processing files line-by-line was surprising.
I've been contemplating migrating scripts to Python so that we would be environment agnostic, but it's not a priority. (Turns out a LInux cloud instance costs more than a Windows instance. Our company signed a huge deal with Microsoft and everything is being pushed in that direction now.)
In the cosmic sense, the demotion was lenient, considering that he breathed new life into something which is mostly an abomination, & should have been put out of our collective misery long ago. The cybersecurity industry would be a shadow of its current self if it weren't for good old Windows.
The ACM needs an "H.P. Lovecraft Award" for such situations.
Jeffrey Snower: RE-ANIMATOR
The ACM needs an "H.P. Lovecraft Award" for such situations.
Jeffrey Snower: RE-ANIMATOR
I wonder if this was some kind of corporate camouflage. EVERYONE LOOK, WE ARE DEMOTING JEFFREY, cool stuff you're doing, keep doing it.
[deleted]
So the implication of the title is that Powershell is being embraced and loved. Not sure I love it personally Wonder what HN thinks?
[deleted]
What surprises me is everything not said here - I know a number of MS Partner-level folks, and they all strike me as perfectly capable of funding and hiding a reasonable-sized team to work on anything they think is important; in fact reducing and removing precisely this practice is one of the reforms Satya has made — getting upper echelon fiefdoms more aligned.
So, I think the full story is actually a lot more interesting than the tweets. I’d personally like a short memoir instead of the tweets. In any event, don’t feel too bad for him - he did fine, and PowerShell is one of the features that let Windows stay competitive with Linux as the world transitioned to the cloud.