I'd love to get more of your thoughts around how PowerShell might be more useful for the kinds of scenarios you're thinking about. We see a lot of folks writing portable CI/CD build/test/deploy scripts for cross-platform apps (or to support cross-platform development), but we're always looking to lower the barrier of entry to get into PowerShell, as it can be quite jarring to someone who's used Bash their whole life (myself included).
Structured shells have so much potential outside of that, though. I find myself using PowerShell to "explore" REST APIs, and then it's easy to translate that into something scripted and portable. But I'd love to get to a place one day where we could treat arbitrary datasets like that, sort of like a generalized SQL/JSON/whatever REPL.
Plus, PS enables me to Google regex less :D
Microsoft has always had this problem, but with PowerShell -- which is supposed to be this unified interface to all things Microsoft -- it is glaringly obvious that teams at Microsoft do not talk to each other.
To this day, the ActiveDirectory commands throw exceptions instead of returning Errors. Are you not allowed to talk to them?
The Exchange "Set" commands, if failing to match the provided user name, helpfully overwrite the first 1,000 users instead because... admins don't need weekends, am I right? Who doesn't enjoy a disaster recovery instead of going to the beach?
I'm what you'd categorise as a power user of PS 5.1, having written many PS1 modules and several C# modules for customers to use at scale. I've barely touched PowerShell Core because support for it within Microsoft is more miss than hit.
For example, .NET Core has caused serious issues. PowerShell needs dynamic DLL loading to work, but .NET Core hasn't prioritised that, because web apps don't need it. The runtime introduced EXE-level flags that should have been DLL-level, making certain categories of PowerShell modules impossible to develop. I gave up. I no longer develop for PowerShell at all. It's just too hard.
It's nice that Out-GridView and Show-Command are back, but they launch under the shell window, which makes them hard to find at the best of times and very irritating when the shell is embedded (E.g.: in VS Code)
The Azure commandlets are generally a pain to work with, so I've switched to ARM Templates for most things because PowerShell resource provisioning scripts cannot be re-run, unlike scripts based on the "az" command line or templates. Graph is a monstrosity, and most of my customers are still using MSOnline and are firmly tied to PS 5.1 for the foreseeable future.
Heaven help you if you need to manage a full suite of Hybrid Office 365 backoffice applications. The connection time alone is a solid 2 minutes. Commands fail regularly due to network or throttling reasons, and scripts in general aren't retry-able as mentioned above. This is a usability disaster.
Last, but not least: Who thought it was a good idea to strip the help content out and force users to jump through hoops to install it? There ought to be a guild of programmers so people like him can be summarily ejected from it!
I don't know how recently you've tried PS7, but the back-compat (particularly on Windows) is much, much better[1]. And for those places where compatibility isn't there yet, if you're running on Windows, you can just `Import-Module -UseWindowsPowerShell FooModule` and it'll secretly load out-of-proc in Windows PS.
Unfortunately, the .NET problems are outside my area. I'm definitely not the expert, but I believe many of the decisions around the default assembly load context are integral to the refactoring of .NET Core/5+. We are looking into building a generalized assembly load context that allows for "module isolation", and I'd love to get a sense in the issue tracking that[2] whether or not fixing that would help solve some of the difficulties you're having in building modules.
For Azure, you should check out the PSArm[3] module that we just started shipping experimentally. It's basically a PS DSL around ARM templates, as someone who uses PS and writes the Azure JSON, you sound like the ideal target for it.
As for the help content, that's a very funny story for another time :D
[1]: https://aka.ms/psmodulecompat
As far as module problems are in question, this is IMO not really fair - you can't expect that every team there have the same standards regarding how modules should work, no matter if the team is from Microsoft or not. The best you could do is perhaps form a consulting / standards enforcing team for MS grown modules.
I love PowerShell, its really poster child for how projects should be done on GH.
And I agree with you about REST API - I never use anything else to explore it (including postman and friends) - I am simply more productive in pwsh. We love it in company so much that we always create powershell REST API client for our services by hand (although some generators are available) in order to be in spirit of the language; all automatic tests are done with it, using awesome Pester 5.
Thanks for all the great work. PowerShell makes what I do joy to that point that I am always in it.
I’ve used powershell regularly since way back when (it was still called monad when I first tied it).
I’m extremely comfortable in the Windows environment but even yesterday I found it easiest to shell out to cmd.exe to pipe the output of git fast-export to stop powershell from messing with stdout (line feeds)
I really like the idea of a pipeline that can pass more than text streams but it absolutely has to be zero friction to pipe the output of jq, git (and awk, sed etc for oldies like me) without breaking things.
If you're seeing issues within PowerShell 7, please file issues against us at github.com/powershell/powershell
A couple of more specific points I'd like to add after experience writing non-trivial PS scripts:
- Tooling is still spotty. Last I used the VS Code extension, it was flaky and provided little in the way of formatting, autocomplete or linting. AIUI PowerShell scripts should be easier to statically analyze than an average bash script, so something as rigorous as ShellCheck would be nice to have too.
- Docs around .NET interop still appear to be few and far between. I recall having to do quite a bit of guesswork around type conversions, calling conventions and the like.
It's nice to see the docs have had a major overhaul since I last dug into them though :)
apt search powershell returns no meaningful result on Debian unstable. I think that's a big barrier to entry, at least for me and people who deploy using docker images based on Debian and Ubuntu.
Our setup today is simply to add an apt repo[1] (of which there is just one domain for all Microsoft Linux packages), and then you can `apt install`.
We also ship pretty minimal Ubuntu and Debian (and Alpine and a bunch of other) container images here.[2]
Oh, and we ship on the Snap Store if you're using Snapcraft stuff.
Edit: unless you are also responsible for DSC, than I'll take it back. It's terrible.
It's intended as a shell semantic where anything bare on the command line just gets run, no matter your scope.
However when we introduced classes, we thought it was a more "dev-oriented" semantic, so we changed return there.
This will only return 'this will return':
class foo {
[string] ReturnTest() {
'this will not return'
return 'this will return'
}
}
([foo]::new()).ReturnTest()You should! It was definitely a compliment.
> I'd love to get more of your thoughts
On a technical level, i would say PowerShell is a breakthrough because it democratized the concept of structured data REPL as a shell. This pattern was well-known to GNU (and other LISP) hackers but not very popular otherwise, so thank you very much for that. Despite that, having telemetry in a shell is a serious problem in my view. That, and other technical criticisms others have mentioned (see previous HN discussions about PowerShell) is why i don't use PowerShell more.
On a more meta level, i'd say the biggest missing feature of the software is self-organization (or democracy if you'd rather call it that). The idea is great but the realization is far from perfect. Like most products pushed by a company, PowerShell is being developed by a team who has their own agenda/way and does not take time/energy to gather community feedback on language design. I believe no single group of humans can figure out the best solutions for everyone else, and that's why community involvement/criticism is important. For this reason, despite being much more modest in the current implementation, i believe NuShell being the child of many minds has more potential to evolve into a more consistent and user-friendly design in the future.
Beyond that, i have a strong political criticism of Microsoft as part of the military industrial complex, as a long-standing enemy to free-software (still no Github or Microsoft XP source code in sight despite all the ongoing openwashing) and user-controled hardware (remember when MS tried to push for SecureBoot to not be removable in BIOS settings?), as an unfair commercial actor abusing its monopoly (forced sale of Windows with computers is NOT ok, and is by law illegal in many countries) and more generally as one among many corporations in this capitalist nightmare profiting from the misery of others and contributing its fair share the destruction of our environment.
This is not a personal criticism (i don't even know you yet! :)) so please don't take it personally. We all make questionable ethical choices at some point in life to make a living (myself included), and i'm no judge of any kind (i'll let you be your own judge if you let me be mine). In my personal reflection about my own life, I found some really good points in this talk by Nabil Hassein called "Computing, Climate Change, and All our Relationships", about the human/political consequences of our trade as global-north technologists. I strongly recommend anyone to watch it: https://nabilhassein.github.io/blog/computing-climate-change...
> how PowerShell might be more useful for the kinds of scenarios you're thinking about
I don't think i've seen any form of doctests in PowerShell. I think that would be a great addition for many people. A test suite in separate files is fine when you're cloning a repo, but scripts are great precisely because they're single files that can be passed around as needed.
> Structured shells have so much potential outside of that, though.
Indeed! If they're portable enough, have some notion of permissions/capabilities and have a good type system they'd make good candidates as scripting languages to embed in other applications because these applications usually expose structured data and some form of DSL, so having a whole shell ecosystem to develop/debug scripts would be amazing.
I sometimes wonder what a modern, lightweight and consistent Excel/PowerShell frankensteinish child would look like. Both tools are excellent for less experienced users and very functional from a language perspective. From a spreadsheet perspective, a structured shell would for example enable better integration with other data sources (at a cost of security/reproducibility but the tradeoff is worthwhile in many cases i think). From a structured shell perspective, having spreadsheet features to lay data around (for later reuse, instead of linear command history) and graph it easily would be priceless.
> I'd love to get to a place one day where we could treat arbitrary datasets like that, sort of like a generalized SQL/JSON/whatever REPL.
Well that's precisely what nushell's "from" command is doing, supporting CSV, JSON, YAML, and many more! https://www.nushell.sh/book/command_reference.html no SQL there yet ;-)
PS: I wish you the best and hope you can find some time to reflect on your role/status in this world. And i hope i don't sound too condescending, because if you'd asked me yesterday what i would tell a microsoft higher-up given the occasion, it would have been full of expletives :o... so here's me trying to be friendly and constructive as much as possible, hoping we can build a better future for the next generation. Long live the Commune (150th birthday this year)!