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.
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.
"Digital Transformation: Thriving Through the Transition - Jeffrey Snover, Microsoft"
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.
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?
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.
(I'm asking because I thought k8s is already devops, just as azure is if devs have some access.)
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?
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?
“.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.
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 :-)
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.
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 ACM needs an "H.P. Lovecraft Award" for such situations.
Jeffrey Snower: RE-ANIMATOR
Not gonna happen.
There's no explanation of why the demotion occurred, by whom, for what reason, when rescinded, etc., etc.
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.
@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
Probably, and what management blunder that would have been if Jeffrey had left Microsoft because of it.
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.
"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...
Flippant answer: the CapitalizationConvention-ShouldScare-EveryoneAway
- 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.
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.
Just use Get-Help and you’re off to the races.
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.
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.
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.
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.
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.
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?)
(Maybe I should xonsh instead? But the question for me isn’t “why not pwsh?” But rather “why pwsh?”)
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
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)
Technically true in some sense, but not really.
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.
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.
* 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 ended up doing a lot of testing to see what my returned results were.
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.
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.
> 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.
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.
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.
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.
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.
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.).
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.
Being able to use all of the .Net classes trivially is also staggeringly useful.
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)
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.
Passing objects by default is a nice idea to enhance pipes... but how about going beyond pipes? :)
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.
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.
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.
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.
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.
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.
> "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?
>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.
"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.
How are you defining "most"? Back in those days there was much more diversity in the computing landscape.
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!
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...
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.
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.
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.
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.
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.
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).
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.
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).
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.
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.
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.
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...
Isn't that terraform?