Jeffrey Snover and the Making of PowerShell

https://corecursive.com/building-powershell-with-jeffrey-snover/

by todsacerdoti • 2 years ago

262 247 2 years ago

Host here, thanks for sharing.

PowerShell faced extreme opposition at Microsoft, and its creator Jeffrey Snover was demoted for pursuing it.

Jeffrey was originally brought into Microsoft to help MS learn how to compete in the data center, but culturally they were so tied to the personal computer model of the world, that they fought him every step of the way.

Edit: Another interesting thing, is how Powershell exists because Windows isn't file based. Jeffrey's goal was server administration, but on Windows you can't just edit files to administer things, you need to call various APIs and get structured data back forth. The rich object model fell out of that. It was the only way.

( Also, apologies if the transcript has errors. I've gone from professional transcriptions to Descript and then a pass of GPT4 trying to find the right punctation breaks and then me doing a quick read through. I don't think its coming out as high quality as I'd like. )

hobs6• 2 years ago

And as far as I can tell its no longer a priority at MSFT, reading the complaints from the MVPs on Github about how MSFT promised a bunch of further investment that has not been realized, changes not implemented, good stuff just sort of left to rot on the vine.

I loved powershell with (some of) its weird warts, but I have moved on.

pletnes2• 2 years ago

My biggest gripe is that some Azure stuff seems to be available only through powershell, which is hard to install and configure (I think) in certain corporate policy-infested environments.

mike_hearn3• 2 years ago

There have been regressions even. PowerShell 7 isn't backwards compatible with PowerShell 5 and some features that used to exist are just gone with no plan for a return, due to (surprise) fights between .NET and Windows teams over API metadata formats or something. Most incredibly Microsoft situation ever.

Say what you want about bash, at least it doesn't pull stunts like that.

valiant552• 2 years ago

What have you moved on to? I don't think I could go back to bash after learning PowerShell and no longer parsing string output.

JoBrad4• 2 years ago

I’m curious about the scenarios that Powershell used to work for you in, and what tooling you’ve moved on to. Do you use something else for Write-Once-Run-(Nearly)Anywhere type scripts?

I primarily write Powershell Core scripts for scenarios where I need to execute the same commands on a variety of operating systems, and I know that the script is likely to be maintained by your “typical” sysadmin (highly technical, but not a programmer)in an environment where installing runtimes for programming languages is discouraged. I switched to macOS as my daily driver about 2 years ago, so PS fits these scenarios pretty well, and Powershell Core updated fairly regularly. Sure there are annoying bugs and misses with the built-in and add-on MS modules: networking cmdlets are an almost total miss, Get-LocalGroup (and maybe other commands?) is totally broken on some AzureAD-joined machines, and the Azure and MgGraph Powershell modules still don’t have enough coverage to move on from the legacy Windows Powershell modules (or even to rely on just one of them, for areas they supposedly cover). But overall I’ve been pretty happy that 99% of the time I can write a powershell script once, and it will run on any machine with Powershell Core, in a consistent way.

hypercube332• 2 years ago

You can tell by WinGet which is a new product not even close to supporting anything PowerShell by design and almost being anti PowerShell with its overly verbose output. Which is odd since it's right up powershells alley being a management cli tool

lhamil64• 2 years ago

What have you moved on to? I have to use Windows at work and PowerShell is way better than basic cmd, even better with Windows Terminal. I suppose you could probably install bash or another unix-y shell but that seems like it wouldn't be as integrated with Windows.

vb-8448• 2 years ago

I wonder why they chose to build something from scratch instead of using python or similar tools that existed before.

dmd• 2 years ago

Something like ksh, you mean? Like they talked about in the article?

mycall5• 2 years ago

Because .net was the center of the whole ecosystem

lozf• 2 years ago

That was a great listen, thanks.

7thaccount5• 2 years ago

If anyone from MS-PWSH team reads this, I'd love for y'all to add some basic GUI functionality that doesn't involve me having to write a bunch of .NET. I'm sorry, but the reason I like PWSH in the first place is it's a simple dynamic language with lots of easy to use commands that I can chain together. I'd love to have a new set of cmdlets for creating simple user interfaces and charts.

For example, something like the below would be so simple for Microsoft to add to the product and remove a page of boilerplate code that I don't really understand well.

Create-Chart -Type "Bar" -XAxis $Cities -YAxis $GDP -OutputFile "C:/Documents/ProjectAnalysis/CitiesBarGraph.png"

There are probably users in the millions that are ok at the basics of programming, but don't have the job role to where tools like Java or C# make sense. Python is usually a good fit here, but I really wish Microsoft had something written for us common folks and not just server admins and IT folks.

If Microsoft put some more effort into PWSH to where it wasn't turtle slow at things like parsing files and then started adding things like what I talk about above. Maybe even cmdlets for statistics and science...it could be something pretty amazing that your typical business analyst could quickly use to build some really amazing software to do their job better or a prototype for the software team to actually implement in a more robust manner. It's such a really cool technology that has a lot of missing potential IMO.

It seems like Microsoft assumes that the three options are full software developer with C#, IT stuff with PWSH, or Excel for the business folks. Excel is really great in a lot of ways, but it is also pretty limited and VBA+Excel is one of the most limited ecosystems I've dealt with. I guess third party languages like Python, R, and so on make for another fourth option, but sometimes I wish Microsoft had spent more time in this area.

RajT884• 2 years ago

You are looking for something like Kusto then.

dashgreen• 2 years ago

There are some third party tools like PowerShell Pro tools or PowerShell Ultimate (https://ironmansoftware.com/). I appreciate they cost, but if you are a builder of tools for others, they really can help massively!

hakfoo• 2 years ago

This immediately makes me think of TCL/Tk, back in the days where that was the lowest barrier to entry to get a basic X11 GUI app up.

bloopernova• 2 years ago

As someone who prefers to read interviews and articles rather than listen, I really appreciate you providing a transcript. Thank you!

thiht2• 2 years ago

I've gone from professional transcriptions to Descript and then a pass of GPT4 trying to find the right punctation breaks and then me doing a quick read through. I don't think its coming out as high quality as I'd like.

I tried reading the transcript and couldn’t reach the end, it’s a bit hard to read in my opinion. I assumed it was machine generated while reading it, but I can’t say why specifically. Maybe it needs a bit of editing to be easier to read.

Thanks for the effort anyway, it’s still better than no transcript :)

adamgordonbell3• 2 years ago

Its funny, because professional transcriber will get the same words. But with better choosen paragraph breaks, and sentence splitting and dropping filler words where it hurts readability.

Hard to get right, it seems.

heresie-dabord2• 2 years ago

the transcript has errors. I've gone from professional transcriptions to Descript and then a pass of GPT4... [...] I don't think its coming out as high quality as I'd like.

I wondered why there were so many unintelligible passages. I found it laborious to decipher. Thank you for explaining.

darksim905• 2 years ago

PowerShell faced extreme opposition at Microsoft, and its creator Jeffrey Snover was demoted for pursuing it.

That makes me sad. The dude is absolutely brilliant.

Awesome post!

justanother2• 2 years ago

I have never, and I mean never, been a Windows user, even though I've been using computers since 1982. During the rise of Wintel in the early 1990s, I followed the rise of Linux and 386BSD. When Win95 and NT ruled the business desktop in the late 1990s, I sought refuge in SPARCStations, Linux, and discontinued NeXT hardware. After the turn of the century, I adopted the newly-POSIX-compliant Mac OS. All this to say, avoidance of Microsoft products has been a cornerstone of my computing policy for nearly half a century (with the notable exception of Applesoft BASIC).

But PowerShell? PowerShell's nice.

neves2• 2 years ago

You posted just at the same time I asked. What's makes PowerShell better than bash?

oblio6• 2 years ago

1. Structured data passed along pipelines.

2. Automatic introspection/command completion for command parameters, even user-created commands.

You can argue about a lot of other things Powershell does, but these 2 things are things which if Bash were designed today by 100 top notch software developers, would probably be part of 95 of their designs.

heresie-dabord2• 2 years ago

You have long experience in computing and especially in the innovative currents that shifted the paradigm. Cheers!

Your first paragraph creates expectation that the second paragraph disappoints, though. Would you explain why you think PowerShell is "nice"?

justanother2• 2 years ago

It's a way of using Windows that is very tolerable to POSIX commandline diehards. The similarities are numerous and include enhanced scriptability and even small details like up-arrow command history. You could get all of that with Cygwin, but Powershell adds tight OS integration, access to COM objects (or whatever we're calling them this year) as well as the remoting of objects. It's a useful and powerful shell that reminds me of VMS DCL and csh.

evacchi• 2 years ago

I love corecursive! Keep up the good work @adam!!

neves2• 2 years ago

I've always been curious to know. I am an experienced Bash developer, and when PowerShell was released, I was very excited. Finally, we would have a cool shell on Windows for development. However, since then, I've never managed to grok PowerShell and continue to use my good old Bash even on Windows.

What is the experience of other developers who are experts in both shells to compare them? Did PowerShell really fulfill the promise of being a more efficient and modern shell? Or people just use it because it is already installed and better than CMD?

pletnes2• 2 years ago

Exactly my experience.

langcss• 2 years ago

I find it is in a weird spot where it is more powerful than bash but you often don't need that power or if you do coding in c# might be better.

It is very good of you want to work with Azure though. You probably don't want to use bash for that. But lots of reading up each time I use it. Bash is my go to for small jobs or a command line experience.

I am not an expert in either but have used both plot to get stuff done.

simooooo• 2 years ago

Most times if I’m doing anything suitably complex it ends up as a little C# app rather than powershell.

prmoustache• 2 years ago

Well I used powershell a lot when I was managing VMWare infra. Ultimately the force of a object oriented shell is in the ecosystem, I haven't found any other use case where powershell was useful to me. I am pretty sure it is useful in an Azure context too but in the last few years I have never been in a situation where I would feel the need to install powershell on my linux workstation to use a specific module/use case.

sebstefan4• 2 years ago

I've done a lot of Bash, read some books about it, I'm a firm believer that nobody should be writing anything complex in bash. Above the ballpark of 50 lines I consider it a code smell. I have this web page saved up in case I ever need to convince anyone of this.

http://mywiki.wooledge.org/BashPitfalls

I used Powershell recently and not having to wrangle with text (commands return objects) makes it a much easier scripting language, and command line language.

The fact that they have an official way to handle argument parsing is excellent, everything is unified and the commandline window is able to have autocompletion for literally every option of everything. Bash could never even dream of having that. It is incredible and makes you extremely productive.

But type coercion manages to introduce new ways to create bugs that Bash didn't have.

Honestly at this point I prefer PWSH but still kinda dislike both. I'm waiting for the new natural evolution.

sebstefan4• 2 years ago

I forgot but one thing I also liked that made me go "Why would bash not have that?" is having a dedicated verbose,info,warn,error,debug output and a glob star *> to redirect everything. It's nice not having verbose text polluting stderr.

PeterWhittaker3• 2 years ago

I have this web page saved up in case I ever need to convince anyone of this... http://mywiki.wooledge.org/BashPitfalls

This is a great list of pitfalls, absolutely, but they are more an argument for integrating shellcheck into your IDE than avoiding bash, IMHO!

I know, I know, possible religious war, but I find that bash+shellcheck is far more often the right toolset than switching languages to avoid the pitfalls.

The immense power and expressiveness and immediacy of bash makes so many programs and so much prototype->PoC->MVP progression so easy and effortless that it is worthwhile having tooling to catch the worst of the warts.

alganet5• 2 years ago

Many of these pitfalls are not the shell, but external programs (sed, xargs, grep, etc).

I know it ends up in the same terminology bucket for the public consciousness as "CLI stuff", but there is a separation and understanding this separation is crucial for writing good sh.

The problem actually lies in bash+coreutils being some sort of de-facto standard for command line stuff. The way bash+coreutils evolved was mostly for autotools and not for humans. This ecosystem could be much better.

PowerShell has more builtins, so it relies less on external commands, therefore it is less vulnerable to pitfalls due to mismatches between different programs.

nunez7• 2 years ago

I don't know if I agree with that. I write Bash; I've written some stuff I really shouldn't have written in Bash. Writing elegant Bash is possible, though I agree it is very easy to footgun yourself with it. The problem is that Bash is right at the middle of "I need something quick" vs "I don't want to break out Golang or whatever" and Bash is installed damn nearly everywhere.

A 50-line awk script though? Get outta here with that lol

inquist• 2 years ago

I’ve spent so much time wrestling with and learning all (most) of these pitfalls, and I consider it time well spent. After my first few weeks I started dreaming in bash.

bigstrat2003• 2 years ago

I totally agree. Bash is an absolute nightmare to program in. Just an utter mess of a language, one which I avoid if at all possible. Whereas powershell is an actual sensible language. I love writing it, and honestly I wish it was popular enough in *nix land that I could feasibly use it there too.

PeterWhittaker3• 2 years ago

I started my career with a X term hosted on a SunOS pizza box, have written thousands of scripts, more than a few in the KLoC count.

Several years ago, I had to write a complex unattended robust data transfer system in PowerShell. (I know, I know, without more info these “requirements” beg many questions, but they are all out of scope for this reply.)

I enjoyed the experience so much I switched all my shells, on MacOS (my DD) and on Linux (my most common work environments) to PWSH.

What I liked most about it was the power of passing objects in pipelines, and being able to extract/manipulate some of the properties of an object in the first filter and still have access to others, along with those of objects created by that first filter, in filters later in the pipeline.

Immensely powerful.

The consistency of commands, of error handling, and of object properties was also very nice.

Eventually, as the nature of work changed I switched all shells back to bash, as the older muscle memory asserted itself. PWSH as a shell made sense when I was working and thinking so much in that space, but when I left it, it was more effortful to think in PWSH than to resume bash.

There are times I miss it. There is nothing else in the shell space that comes close, or at least not close enough to justify the effort of switching.

ethbr13• 2 years ago

Do you remember what the common commands for pipelining you used were?

I feel like my PowerShell struggles are really about not knowing 2-5 core, general-purpose pipelining commands well enough to use in any situation.

gosub1002• 2 years ago

a few years ago I had to write a data integrity check for tens-of-thousands of files. Just crawl the dir and compute filename, size, checksum, maybe date, can't remember. I thought "ooh neat, I bet I can use some powershell trick to compute that tuple for each file", and no. Immediately ran into some obscure limitation with their "pipe" - I can't remember the details, it was like impossible to create many-things from a single-thing - and thought "how disappointing. the one time I give it an honest shake to do something entirely conceivable by the creator and it falls flat on its face.".

Kwpolska3• 2 years ago

PowerShell is more verbose than Bash, and has its idiosyncrasies (like sometimes automatically unwrapping 0/1-element arrays into scalars when you least expect it), but it is more productive and more readable. Object-orientation can be nice to produce pipelines.

For example: find potential file duplicates in a folder, recursively, by grouping by file size:

    Get-ChildItem -File -Recurse | Group-Object -Property Length | Where-Object { $_.Count -gt 1 } | Sort-Object -Property Count

No need to remember arcane `file` incantations, no need to parse textual output. You get real objects with properties, and tab completion can see their structure.

Need to parse JSON? No need to involve `jq`, just `Get-Content -Raw whatever.json | ConvertFrom-Json` and do it directly from PowerShell. Need to convert XML into CSV? ConvertFrom-Xml (or Select-Xml) -> do stuff -> ConvertTo-Csv.

Is `Get-ChildItem` too much typing? Use `gci`, or `dir`, or `ls` (by default only on Windows). Is `Where-Object` too much? Try `where` or `?`. And things are case-insensitive.

g15jv2dp5• 2 years ago

You can even simplify your `Where-Object` as

    ... | Where-Object Count -gt 1 | ...

Or, of course,

    ... | ? count -gt 1 | ...

akira25014• 2 years ago

...and how do I get a "manual page" for the command "Get-ChildItem" in the console?

omnicognate4• 2 years ago

No expert in either but I've had to use both a fair amount. Powershell fell into a few traps that rendered it awful to use IMO:

* Trying to be a .NET language. I don't know why the one-runtime-many-languages promise of .NET withered on the vine while it flowered in Java-land without the promise even having been made, but it did. If you're writing .NET code, use C#. (And I say that having worked in one of the very few teams doing large scale development in F#.)

* Failing to get the basics of being a shell right. I can't remember the details as I've left it firmly in the past now, but its handling of redirection was just broken, to the extent that things that were trivial in bash were nigh on impossible in powershell. I got the impression its developers ignored the things bash etc. did well in their enthusiasm over building something new and powerful.

* Being fetishistic about stuff like requiring Verb-Object naming for everything. It's certainly subjective and has its defenders, but IMO it renders scripts ugly, is awkward to type and doesn't materially improve discoverability or memorability at all.

Kwpolska3• 2 years ago

PowerShell isn't quite a .NET language, and you can't really write serious .NET software in PowerShell. But if you need to access the power of .NET (or heck, COM) from a script or an interactive shell, PowerShell lets you do that.

nickpeterson• 2 years ago

As someone who really likes F#, I wonder sometimes if I should just jump ship to ocaml or Haskell. What made you feel like F# wasn’t ultimately worth it?

bionhoward• 2 years ago

I don’t like powershell because it’s so surprising in a billion ways from bash. The tab being replaced with right arrow screws me up, and so does not having the normal commands, and it’s quite opinionated about naming.

That said, powershell seems more capable than bash if you know it well, because it has a better type system and arguments are easier to mess with, whereas bash things are amorphous strings.

https://github.com/bionicles/tree_plus/blob/main/tests/more_...

That’s a slightly out of date version of what I use to provision stuff on my windows machine to test things, and can show what’s possible a bit.

drsopp• 2 years ago

I used a Powershell-script in a recent project and learned some lessons. It gets some data from an API. It is run dozens of times every minute, can run concurrently with itself, has some writing to a json file cache in a race condition free way. Works mostly ok. Development has been difficult because of low volume of forums talking about Powershell. Wouldn't have bothered to make the script without ChatGPT. One time it failed by inexplicably setting system+hidden+read only flags in a project folder. Quite a head scratcher. The worst experience was a bug I still don't understand: The script failed to get an access token when running in "ordinary powershell" but managed to do so when running in Powershell ISE. I checked every possible environment difference and concluded that there was only one: powershell.exe vs powershell_ise.exe. I am not going to be making any more Powershell scripts.

GrantMoyer4• 2 years ago

I use *sh at home, and Powershell at work. Powershell has a lot of really cool and genuinely useful concepts. There's the obvious like piping objects instead of raw bytes, but there's also things like first class parameter validation, automatic array flattening, multi-threading, full .NET API interoperation, and more.

Unfortunately, it also has some real sore points for use as an interactive shell, and even some outright broken behavior. Some that I lament most frequently:

- Powershell has native tab-completion support, but the word-of-god dictated "Verb-Noun" command naming scheme means almost every command shares a common prefix with a slew of entirely unrelated commands, making tab-completion painful.

- Power shell has sparse built-in support for funtional style list manipulation or data structures beyond lists. There's a "map" command (%), but no reduce, zip, tail, etc. These feel like they'd fit in perfectly to the design of the language, but they're just missing. Also, pipes are lazy, but lists are always strict, which can cause friction.

- most operators are strangely named, such as "-eq" for ==, which hurts legibility.

- There're lots of unvoidable brackets, meaning you often need to jump around the line while writing out a command incrementally. For example, to get filenames, you either need to write `(Get-Item).Name` or `Get-Item | %{$_.Name}`. It'd be nice to have something like `Get-Item |. Name` as an option.

- It's impossible to pipe raw bytes between commands/executables; raw bytes are interpreted as strings. This means, for example, it's impossible to pipe a file to `patch`, because the contents will be decoded into strings, piped as strings, then re-encoded with line endings changed, which `patch` rightfully refuses to apply.

- Running Powershell scripts is disabled by default (WTF?)

By comparison, *sh's heavily favor interactive use. For example, you can put io redirections at the start or end of a line, tab-completion is often very good, it's often possible to avoid brackets (ex. with xargs), background/foreground job management, etc.

Overall, I often find Powershell more pleasant to use than *sh, especially when writing scripts. But for interactive use, I often wish Powershell was a little smarter and a little dumber at the same time.

nu11ptr3• 2 years ago

Why is automatic array flattening a good thing? This has caused more bugs than I can count. Every time I make an array I have to check if it has a length of 1 and do something special with it or else the script blows up. Best I can tell this is a huge foot gun anti-feature. What am I missing?

LeonB• 2 years ago

This works:

    Get-Item | % Name

vips7L6• 2 years ago

I switched to menu completion and the tab completion isn’t as painful with all the choices.

marcosdumay• 2 years ago

A shell is not a thing by itself. It's only as good as it integrates with the rest of the system.

So, the experience of PowerShell on Windows is unbeatable... on Windows. It's easily beaten on any other system.

delta_p_delta_x• 2 years ago

I'm not an expert, but I use UNIX/Linux at work and only Windows at home (I have a dormant Arch Linux install that I haven't touched in a couple of years), and hopefully you think I'm qualified to respond.

I feel Bash is a 'glue language' in every sense of the word, and is optimised for interactive command-line usage because of its terseness. Being remotely productive on Bash presupposes the presence of an entire UNIX subsystem and coreutils (which is why Git Bash for Windows drags along an entire `/usr/bin` directory with all the coreutils in it). You can't really do much in it without the coreutils.

I find that Bash parseability and ease-of-understanding rapidly deteriorates in scripts of increasing complexity. After about a hundred lines of code I reach for other languages. I personally dislike its unintuitive syntax, global scope, and weak, dynamic typing. The terseness that lends itself to powerful interactive command-line usage means script readability plummets. Of course, that might just mean I'm inexperienced with respect to Bash and need more practice, but I find this a fairly common opinion amongst colleagues and friends. In my opinion, Bash scripts are write-only. It is a wonder that something like neofetch[1]—which is an eleven thousand-line monstrosity—lasted this long (if I recall correctly the author stopped maintaining it because—amongst other reasons—it had just become too complicated).

I find that people understand PowerShell better when they realise it is closer to Python than any interactive UNIX shell. By default, PowerShell is more verbose than Bash; for instance, the PowerShell equivalent of the two-character all-lowercase `ls` is the thirteen-character mixed-case `Get-ChildItem`. Arguments are by default also long and verbose, with things like `-FollowSymlink`. PowerShell is generally meant to be used in executable scripts, just like how most Python isn't executed in the interactive REPL, but by running scripts. Consequently, I find this verbosity lends itself to improved readability in scripts, at the expense of some interactive productivity. That being said, common PowerShell commands have UNIX-like aliases[2] (at one point the cause of much gnashing of teeth here and at /r/programming because PowerShell aliased `curl` to `Invoke-WebRequest`[3]) to improve interactive productivity. PowerShell also supports truncating parameter names; for instance, `Get-ChildItem -Recurse -Force` can be abbreviated to `gci -r -fo`, which looks remarkably like a UNIX command now. Even so, the PowerShell ISE and the PowerShell VS Code extension both suggest that programmers use the full unabbreviated commands and arguments in `.ps1` scripts[4].

PowerShell is also dynamically typed, though semi-static typing can be opted in to[5]. That said there is some controversy about arrays decaying to scalars when they have size 1 [6]. It is easy to set up both function and script parameters with as much power and expressiveness as `argparse` for Python, but natively without involving any additional modules[7].

The real power (pun not entirely unintended) of PowerShell comes when you realise it is just another front-end to the incredibly massive .NET ecosystem. Where Bash requires a full UNIX subsystem and a collection of hundreds of additional binaries to be productive, PowerShell employs pre-compiled cmdlets[8] written in .NET (usually C#) to augment the basic language. Most 'commands' in PowerShell are cmdlets, including `Get-ChildItem`. You can write your own 'back-end' in C#, F#, C++/CLI, VB, or any other .NET language, compile it, and expose a PowerShell interface for end-users. Pretty much like how people write fast but complex code in C/C++, compile it, and expose a Python interface (Numpy, Pandas, PyTorch, etc come to mind). You can additionally directly call .NET methods in PowerShell[9].

This also means that everything in PowerShell is an object. The output of `Get-ChildItem` is a list, not a string. Likewise for `Get-Process` (UNIX equivalent: `top`). These lists may be formatted[10], filtered, parsed, modified, dumped to JSON, and otherwise manipulated like any other list data type in most other languages.

PowerShell also lends itself to the side-effect-free/functional/monadic map-reduce paradigm very well, with pipelines[11].

In my opinion, it is not merely 'better than CMD'; it blows CMD out of the water. A little less so for Bash, because Bash is augmented by the UNIX core-utils. As should now be evident, in my view the real competition to PowerShell is Python.

[1] https://github.com/dylanaraps/neofetch/blob/master/neofetch

[2] https://learn.microsoft.com/en-us/powershell/scripting/learn...

[3] https://news.ycombinator.com/item?id=12319670

[4] https://learn.microsoft.com/en-gb/powershell/utility-modules...

[5] https://stackoverflow.com/a/115815/1654223

[5] https://superuser.com/a/414666/1132163

[7] https://learn.microsoft.com/en-gb/powershell/module/microsof...

[8] https://learn.microsoft.com/en-gb/powershell/scripting/power...

[9] https://devblogs.microsoft.com/scripting/learn-how-to-use-ne...

[10] https://learn.microsoft.com/en-us/powershell/module/microsof...

[11] https://learn.microsoft.com/en-gb/powershell/module/microsof...

nunez7• 2 years ago

I was extremely well versed in PowerShell early into its development.

It was indispensable when it came out. VBscript and Cygwin were the only options; both of them sucked. The ability to use native .NET objects in scripts was insane; I definitely abused that!

Nowadays, Git Bash and WSL2 replace a lot of the value that PowerShell provided.

It's purpose was to drive Microsoft away from the GUI, and, at that, it more than succeeded.

oblio6• 2 years ago

VBscript and Cygwin were the only options; both of them sucked.

I'd challenge the Cygwin aspect. With judicious use of cygpath & co., you can go VERY far with Cygwin. I've built an entire SaaS deployment system on top of it (and Python).

gonzo41• 2 years ago

I just find everything about powershell tricky. Something just doesn't click for me. It's always a struggle.

dfedbeef• 2 years ago

Powershell is a huge improvement over cmd. However; much like Windows, it is full of complicated gotchas and edge cases. Bash has them too, but Bash makes concurrency and parallelization extremely simple, so despite it's absolutely bananas syntax and rules for hash tables and arrays, it is superior IMO. Bash also makes it simple to write your own more complex utilities in any language and call them from bash. Linux makes it simples to implement new kernel tech and Bash makes it simple to interact with the kernel.

Windows... You have to wait until someone in WDG decides some existing idea is good and then also wait for them to get support to implement the idea, then wait to see how that whole thing goes. So yeah Powershell is great for interacting with Windows. But Windows thinks you're a dumb shit so you can only do what Windows already lets you do.

ed_elliott_asc• 2 years ago

It took me about a decade to be comfortable with it :)

zamalek• 2 years ago

I have used it for nontrivial stuff. The idea of streaming objects has a lot of potential, but I think the "enterprise crowd" had a really good crack at it - especially the syntax. Not having to resort to grep, jq, cut, and the host of tools required to (often fragile) parse out whatever specific format the tool you are calling is giving you.

Put another way, you could feel free to parse the output of ls in powershell - because it's already been done for you.

rewgs• 2 years ago

They should have called it PowerScript, because it's a perfectly decent scripting language and an absolutely horrendous interactive shell language.

spicyusername• 2 years ago

I'll agree with some of the other sentiments here that whenever my career brought me close to Windows administration I absolutely loathed the experience.

PowerShell however was actually pretty great to use, despite everything else on Windows being extremely clunky. It always felt very thoughtfully designed.

Linux is great, and I'll always use it as my daily driver for work, but using bash is absolutely horrible. But because it's always everywhere, it's something that everyone reaches for first, and so we'll probably still be dealing with bash scripts in 2100, warts and all.

zlies• 2 years ago

I love this podcast!

useerup• 2 years ago

So much was so right about PowerShell. But it failed to attract a wider audience, and in their quest to woo Linux devs Microsoft has been undermining PowerShell lately. Knowing what PowerShell offers, falling back to bash CLI tools feels like two steps back.

Just some of the stuff PowerShell did right:

- PowerShell cmdlets are self-describing and rich in information. Rather than each command doing its own parsing of parameters, cmdlets describe parameters and delegates the actual parsing to the shell. The shell understands data types, parsing rules, e.g. how to parse a UUID or a date. Not only does this ensure a consistency that was never in *sh shells, but it also enables cool stuff like e.g. autocomplete, predictive input, help instructions etc. almost for free.

- "Simulation" mode (-Confirm and -WhatIf) where a cmdlet can describe the action it is about to take, and the mode of the shell may decline everything (effectively a "simulation mode") or may actually ask the user for permission (-Conform) for each action.

But, alas, PowerShell never caught on outside Windows, and now MS is leaving it to wither in their quest to not upset a wider non-Windows community.

iso8859-1• 2 years ago

Nushell is based on it, and it is picking up steam.

https://www.nushell.sh/book/

So in the end, PowerShell doesn't need to catch on.

vips7L6• 2 years ago

Nushell isn’t anywhere near as powerful as PowerShell.

rr808• 2 years ago

I used to be a hardcore Windows dev but never figured out powershell. I actually ended up writing scripts in C# and had a utility to load and run it.

martinsnow3• 2 years ago

Good news. You can write C# that powershell will compile on the fly. It's so ingrained in Microsoft applications that even MSSQL Server will do it as well, if you want to go down that route.

oblio6• 2 years ago

How?

rqtwteye• 2 years ago

That's what they should have done. Have a C# interpreter with maybe a few extensions for shell stuff. Powershell is not a good .NET language and not a good shell. It's just a weird beast.

A while ago I worked on a project to do pretty complex configuration on Windows machines. Everybody thought Powershell would be perfect for this. It turned into a complete nightmare with tons of oddities to work around. I myself barely can make sense of the code and I bet nobody else can.

Next time I would do either Python or write the whole thing in C#.

johng• 2 years ago

I once had 2 microsoft engineers call me for help with qmail because I was active on the qmail mailing list. They couldn't wrap their heads around how svc and daemontools worked.. the good old days! I never asked why 2 microsoft engineers were working with qmail. I think I was 20 at the time and I was just happy to be on the phone with people from Microsoft even though I was very much a Linux guy.

arunsivadasan• 2 years ago

Would have loved to hear why he made the move to Google considering that he became a Technical Fellow and very popular in the community

alganet5• 2 years ago

PowerShell is very comfortable in interactive mode.

For scripting, I don't get it. It's not designed to be a simple text-based glue like the bourne shell is, so it feels weird in many places (quoting, escaping, even more than sh is). It's very good for glueing Windows stuff though, like .NET libraries and so on.

mike_hearn3• 2 years ago

Huh I always found that to be the opposite. PowerShell is clearly designed to be a programming language not an interactive environment.

E.g. 'wget' exists but run it on its own and it doesn't save the file to disk or print it out, it prints an object as a table, which is about the most useless output possible. I know why this happens but that doesn't make it helpful.

Reading about the dysfunction inside Microsoft makes it clear why it ended up this way though!

alganet5• 2 years ago

I don't want an object oriented language to glue stuff, I want a glue language.

Want the result of wget in memory instead of print or disk? Write it to memory:

    page_contents="$(wget -O- some_page)"

It doesn't try to apply some default structure, so I don't need to rely on MS doing a fancy special wget for me that calls thousands of lines Invoke-WebRequest in the background.

nunez7• 2 years ago

Does the ISE still take forever to spin up?

gavindean902• 2 years ago

I think everyone just uses VSCode now

briHass2• 2 years ago

The ISE is deprecated, and MS guidance is that it should be uninstalled. Defender endpoint management flags it as a mild security risk.

axpvms• 2 years ago

PowerShell helped me a lot in my earlier career, bash always felt like banging rocks together in comparison.

jiggawatts• 2 years ago

Something that is under-appreciated is that if you need to write your own command-line tool with a "proper" programming language such as C/C++ or whatever, then there is a vast difference in productivity between writing for traditional shells or PowerShell.

I've never been able to make a generally useful CLI tool in under a few thousand lines of messy code. You typically have to deal with: pipeline inputs, optional parameters, parameters with values, defaults with overrides, "dry run" mode, and the various output formatting requirements, and so on. You end up with 90% fluff and 10% action.

With PowerShell, a C# module is basically 20 lines or so of overhead, and the rest is all action. It's mindblowing how productive this is! You get parameter validation, parameter name tab-complete, pipeline input, pipeline output, formatting, strong typing, globbing, etc... all for free.

theimposter2• 2 years ago

While I've never used C#, I agree with you. I've moved more and more to compiled or interpreted languages versus CLI tools for maintenance and administration.

nu11ptr3• 2 years ago

Powershell wasn't awful when I wrote it but I never understood why arrays of length 1 removed the array and become the contained type. This caused a huge # of bugs as you suddenly had to care how many items could potentially be in the array and check each time you modified vs. handling them generically. Does anyone know WHY they did this?

sgbeal• 2 years ago

Does anyone know WHY they did this?

That sounds like a classic case of software trying to be "too clever," nine times out of ten of which will invariably backfire.

As a software developer, one should always resist the temptation to make their software "too clever."

AndrewDucker• 2 years ago

Agreed. This drives me crazy. You have to work around it in a script of any complexity. It's probably my least favourite thing about PowerShell.

JoBrad4• 2 years ago

This is so annoying. I’ve started using the preceding comma hack to force an array.

  $Ary = @(, "value")

One cool feature for creating arrays (especially larger arrays, for performance improvements over using +=) is to assign your array to a for loop. It wasn’t an obvious method of populating an array to me, but is definitely handy.

  $Ary = foreach ($Obj in $Objs) { @{ foo = $Obj.foo } }

jmull• 2 years ago

I think @("value") is enough.

I use

    [array]$Ary = "value"

gugagore• 2 years ago

This is reminiscent of MATLAB where there is no distinction between a scalar and a 1x1 matrix.

jdbebdjjd• 2 years ago

A scalar _is_ a 1*1 matrix

A scalar however is not a tuple of length 1

low_tech_punk2• 2 years ago

It feels like a half baked feature. The other (missing) half would be automatically converting a single value into an array of length 1 when the receiving end expects an array.

CyberDildonics2• 2 years ago

Niche languages seem to end up with insane quirks like this every time. It's like the tragedy of sisyphus that things like lua exist, but instead of using it directly or modifying it slightly, then having a dead simple, tight, small, elegant, consistent language, people reinvent the wheel and never make it round.

thiht2• 2 years ago

Lua is not perfect either. Having a specific keyword to make variables local was a mistake. Variables should be local by default. Oh, and 1-indexed arrays are annoying.

Arnavion2• 2 years ago

There's looseness around arrays because the API for emitting outputs from commandlets is also loose around arrays. There is just one function `WriteObject` that writes the value you give it as the output of your commandlet. If you call it once, then that's your output. If you call it multiple times, then the shell has no choice but to then make your output an array of all the values you write.

So if one invocation of your commandlet only calls `WriteObject` once and the other calls it twice, the shell in the first case doesn't have the knowledge that it should've wrapped that one output in an array too. And it can't always wrap commandlet outputs in arrays because that would be disruptive for commandlets that semantically only have one result and so always write only one output (like `Get-Date`).

And for whatever reason, they didn't want to complicate the API to let commandlets themselves be able to express whether they'll semantically write only one output or multiple, regardless of how many times they actually call `WriteObject`. Such an API can't be a static attribute on the commandlet because commandlets can have wildly varying output based on their parameters. It can't be an overload of `WriteObject` like `(Object, bool iMightWriteMoreValues)` because it has to work for empty arrays. So it would have to be a separate `IWillWriteMultipleValues()` function probably.

Edit: Also explained here: https://news.ycombinator.com/item?id=40874873

theimposter2• 2 years ago

PowerShell, is still the best way to scale your workload, administering a Windows server environment on premise. For Azure, there were features that were present in the Graph API that were not in PowerShell.

I haven't checked back in a while, but I think most new features in PowerShell are just pointing back to the Graph API.

Pet_Ant• 2 years ago

Honestly I love Powershell and run it on Linux or OS X. Being able to access fields instead of having to play with `cut` to get the data I want is priceless. Just feels cleaner and more maintainable.

nunez7• 2 years ago

I met Snover at a DevOps Days forever ago. We were talking about PowerShell, and I didn't know he was at our table. Super nice dude.

munchler• 2 years ago

This is a great story of finding a way to be productive inside a giant, impersonal machine like Microsoft.

That said, it did nothing to convince me to invest more mental energy in PowerShell. Every time I use it, I have the same “meh” reaction: The learning curve is too steep and the syntax is too ugly. It doesn’t ever “stick” with me, so I end up starting from zero every time I encounter it again.

I think the fundamental problem is that PWSH inhabits a dark valley between quick-and-dirty scripting and I’m-serious-about-this programming. It really needed to pick one side or the other to win people over, but never did.

jodrellblank6• 2 years ago

PowerShell is MIT licensed, cross-platform Windows, Linux, macOS compatible, and you can download it in various installers and packages here: https://github.com/PowerShell/PowerShell/releases

for anyone who wants to try the newer version on Windows, get either Windows Terminal (from Microsoft Store or Github releases: https://learn.microsoft.com/en-us/windows/terminal/install) or Visual Studio Code. The classic Windows' command prompt console host engine just can't do Unicode and fonts and colours and Unix shell escape sequences.

After that, find something which will immediately trigger you to froth at the mouth, hurry onto some Microsoft forum and post about how Microsoft is the devil. Here's some popular choices, many of them valid complaints: ('curl' and 'wget' on Windows override the real programs with M$ imposters). (gci doesn't support the parameters of either dir or ls). (aliases work differently to Unix shells). (almost everything works differently to Bash). (gci -recurse is frustratingly slow). (it doesn't have a CLI text editor like nano). (you don't understand that GNU and Unix utilities aren't "Bash"). (PowerShell remoting with enter-pssession and invoke-command aren't SSH). (there isn't any sudo because Windows isn't Linux). (Execution policies are annoying). (it doesn't use UTF8 everywhere always). (backslash, the one true Unix escape character isn't PowerShell's escape character). (Line endings aren't Unix line endings). (having to use sigils to disambiguate between shell and code is worse than Python for coding and worse than Bash/cmd for shelling). (You want > to be both numeric comparison and/or Unix shell IO redirect and it's not). (you hate Verb-Noun and the one true way is Noun-Verb). (byte streams don't pipeline well or quickly). (It's verbose which you hate, but the elastic syntax one-liners are unreadable which you hate, it should have exactly the right amount of verbosity which coincidentally is exactly the amount you are comfortable with).

Moving on from there, avoid falling for the tempting usermode filesystem equivalent, which is abandoned and only exists for backwards compatibility making everything slower. Avoid falling for the declarative host config system Desired State Configuration (DSC) which is semi-abandoned and only hangs around for backwards compatibility. Control your enthusiasm about .NET/C# LINQ in a shell, because nope. Prepare yourself for the weirdness of a programming language which has shell style dynamic scoping instead of lexical scoping, shell style output handling where all output goes to the pipeline, pipeline obsessed array unrolling which spills the contents of containers all over the floor if you aren't paying attention, having to learn that there's more to output than just stdout and stderr and that the host and pipeline are different outputs, and that there's a lot of non-powershelly .NET and Windows stuff poking through everywhere. Prepare your armoured-toe boots for a large number of footguns and bugs in what is an intricate and complex shell/scripting language mashup.

Moving on from there, it's a REPL:

    $x = 5
    $x + 3

Numeric literals in hex and binary:

    0xff
    0b1010

Strings in single quotes are literal:

    'foo $bar'

Strings in double quotes are not literal:

    $bar = 'hello'
    "foo $bar $( 4 + 3 )"

It's a shell:

    ping google.com

It's introspective:

    gcm ping    # get-command details of ping
    gcm p*      # commands starting with pi
    help gcm

Function calls don't use () or "return" because shell-style usage and behaviour, variable names and function calls aren't case sensitive:

    PS C:\> function test($Left, $Right) { $left + $right }
    PS C:\> test 4 6
    10

    PS C:\> test -Left 4 -Right 6  # named parameters
    PS C:\> test -L<ctrl+space>    # autocomplete

Reach for .NET libraries:

    PS C:\> [System.Ma<ctrl+space>  # autocomplete to explore and find System.Math
    PS C:\> [System.Math]::<ctrl+space>  # autocomplete to find e.g. [System.Math]::Pow(4, 5)

Basic data types:

    $array = 1,2,3
    $array | foreach { $_ }

    $hash = @{KeyA = 4; KeyB = "b"}
    $hash.keyC = 5
    $hash['keyD'] = get-childitem

    $x = 'KeyA'
    $hash.$x   # oooh

on Windows:

    gci | ogv    # out-gridview

Text filter ("grep ish"):

    gc words.txt | sls '[iou]'    # get-content and Select-String

Objects:

    ls | select Las<tab>  # tab complete will pickup the available properties
                          # on the objects coming through the pipeline, where possible

    ls | select LastWriteTime, FullName    # two properties, kept separate, no text parsing

    ls | % {$_.LastAccessTime.DayOfWeek}   # the access time is a .NET System.DateTime,
                                           # not a timestamp or text string.

    ipcsv data.csv | select col1, col3     # import-csv, select-object

    $hash = @{KeyA = 1; KeyB = "foo"}
    [pscustomobject] $hash                 # casting

(Objects are used as containers for multiple properties and keeping them separate; it's not a full "object oriented programming with inheritance and interfaces" kind of shell/language, although it has some nods to that).

rcarmo• 2 years ago

I am not a fan of PowerShell, but I am a fan of Jeffrey--he toiled and talked sense at a time way before Azure was a thing, but everything since he shipped has proven he was right.

UweSchmidt3• 2 years ago

Powershell was truly a product of Microsoft monopolistic confidence. To create a language that allows absolutely no syntactical carryover from any other langauge is wild. You couldn't guess or assume any command, parameter or flag. Even with Microsoft's ambition they should have realized that legions of admins and programmers had to learn and maintain scripts in both Powershell and bash for a few decades at least.

The extreme verbosity of the syntax may look good for a presentation to the committee, but dealing with it regularly collides with well-researched and understood limits of the human brain, where information of a certain size, and delays of a certain length break the state of flow and requires concentration, explicit memorization and double-takes. Even with practice one could never quickly execute the common shell incantation to turn a thought into reality, instead one would have to wrestle with syntax, even if it's just waiting for autocomplete to appear and deciding to accept the next word of a multipart command.

Let's try the start menu and search for "pow..", chose between 4 amazing options, Powershell or Powershell ISE, both in regular and x86 flavour. Either would take a while to load, breaking flow. The ISE shows a little splash screen that jumps to a second location. Another dialog shows up and informs you that you've closed the last session without saving the unnamed script files. But it opens them anyway, as you would expect. So why scold me for this? Because, you know damn well that saving the textfile is trouble: I can type or copy, and then execute any kind of evil code imaginable, but saving the file and then running it as a .ps Script triggers the ridiculous execution-policy song and dance. Probably trauma from Microsoft's bad security reputation of early Internet Explorers and Windows versions.

I tried to love it anyway but one day my script encountered filenames with square brackets. Powershell implicitly interpreted those [1] and [2] as iterators somehow (https://stackoverflow.com/questions/21008180/copy-file-with-...). Sorry but dealing with files is the one job a scripting language has, filenames are beyond the control of script authors, and the space of valid filenames on Windows should be known. This gave me some long lasting trust issues with that language.

(The Azure team aparently had enough power within Microsoft to create their own, sane and readable syntax: "az find vm", "az account show".)

oblio6• 2 years ago

Powershell was truly a product of Microsoft monopolistic confidence. To create a language that allows absolutely no syntactical carryover from any other langauge is wild. You couldn't guess or assume any command, parameter or flag. Even with Microsoft's ambition they should have realized that legions of admins and programmers had to learn and maintain scripts in both Powershell and bash for a few decades at least.

Um... no. Powershell was inspired by shell, Perl and a bunch of other languages, you see it in its design. The other part was just a desire for consistency, since *NIX knowledge is just brute forced. Yeah, -v is generally verbose and -h is generally help, but in practice you can't rely on anything.

UweSchmidt3• 2 years ago

Could you illustrate how any other language inspired Powershell in any way, beyond the most basic concept that it is a scripting language?

In bash/unix, I feel -l often stands for list, -a for all, -f for force, -q quiet or slient, -r recursive, -d debug. A modern approach could have been for Microsoft to clean it up and make it more consistent. But no.

DrTung• 2 years ago

I think PowerShell is a bit scary, for example I could never get curl to work in it, say a simple POST command: curl -X "POST" google.com should return Error 411 (Length required) from google (as it does in CMD.EXE)

When I try it in PowerShell I get: Invoke-WebRequest : A parameter cannot be found that matches parameter name 'X'. and some more error messages

even curl -X "GET" doesn't work :-(

skowalak• 2 years ago

That is because `curl` is an alias for the builtin Invoke-WebRequest and not the actual curl program.

https://learn.microsoft.com/en-us/powershell/module/microsof...

martinsnow3• 2 years ago

Well that's just plain stupid

gabrielsroka• 2 years ago

It was at one point, but they took it out because it was stupid.

saghm• 2 years ago

It says a lot about the uphill battle that he faced when the first two sentences Jeffrey says in the podcast are "By the way, is it okay to swear?" and "You know, I had executives say, ‘Jeffrey, exactly which part of fucking Windows is confusing you, Jeffrey?’".

bluedino• 2 years ago

Unless I'm interacting with some Windows subsystem, and need the specific Powershell commands, I just think "why the fuck am I not using Python?"

It's also way too verbose and slow for 90% of the stuff I'd use Bash for (or would have used Perl in another life)

I often wonder why Microsoft didn't base it on Python, Node, or something else. I can't remember when PS was first released so I'm not sure what would have been ideal at the time.

oblio6• 2 years ago

Powershell predates Node by 3 years.

They probably didn't base it on anything else since they control .NET.

I doubt it's slow because of .NET, it's slow because of either its design or because of under-investment in performance.

However... which version of PS are you using? As far as I remember the newer versions are quite fast.

dopylitty• 2 years ago

Python's default REPL is godawful. It's also just not designed for the kind of console work that PowerShell excels at because you have to do things like managing file handles rather than just getting the file content and piping it to another command.

PowerShell is great because it's a swiss army knife that has a very nice REPL with autocomplete, no weird whitespace behavior, readline[0], and can do anything .NET can do if you need to do anything more complicated.

Plus it's object oriented so you can focus on doing the tasks you actually need to do rather than trying to figure out how to use archaic utilities to parse the text based output of other archaic utilities.

0: https://learn.microsoft.com/en-us/powershell/module/psreadli...

thesuperbigfrog3• 2 years ago

> I often wonder why Microsoft didn't base it on Python, Node, or something else. I can't remember when PS was first released so I'm not sure what would have been ideal at the time.

They originally based it loosely on Perl and the Korn shell. In the first edition of "Powershell in Action" by Bruce Payette there is a sidenote that states:

'PowerShell uses the "at" symbol ("@") in a few places, has $_ as a default variable, and uses "&" as the function call operator. These elements lead people to say that PowerShell looks like Perl. In fact, at one point, we were using Perl as a root language, and these elements stem from the period. Later on, the syntax was changed to align more with C#, but we kept these elements because they worked well. In Perl terminology, they contributed significantly to the "whipupitude quotient" of the language.'

It also states:

'The core PowerShell language is based on the POSIX 1003.2 grammar for the Korn shell. Originally, Perl idioms were appropriated for some of the more advanced concepts such as hash tables. However, as the project progressed, it became clear that aligning PowerShell syntax with C# was more appropriate.'

ilrwbwrkhv• 2 years ago

Big fan of PowerShell. Such a shame that being in Microsoft, you aren't allowed to do great work. That is why hackers shouldn't join large companies. You can create much more value working for yourself or joining a small startup.

low_tech_punk2• 2 years ago

The Monad Manifesto mentioned in the podcast:

https://jsnover.com/Docs/MonadManifesto.pdf

meisel• 2 years ago

Why wouldn’t they just replicate bash or some other UNIX shell, along with the basic UNIX tools like cp and find with matching APIs? Huge mistake there imo, even if they did add a few bells and whistles with powershell

eigenvalue• 2 years ago

Seems so weird in retrospect that Microsoft wouldn’t have seen the value of an easily composable and programmatic way to configure anything in Windows and their other important enterprise applications like Active Directory and Exchange. The idea that connecting with Remote Desktop and clicking around with a mouse was suggested as an alternative strikes me as absurd. Especially because automating that sort of thing (at least based on my experience using autohotkey and window spy) is horrendously difficult and annoying.

akira25014• 2 years ago

an easily composable and programmatic way to configure anything in Windows

There's an entire industry of consultants and software vendors that don't want that outcome.

connecting with Remote Desktop and clicking around with a mouse

This generates a lot of hours.

is horrendously difficult and annoying.

It is ironic that this is probably the main reason that alternative operating systems even exist.

generalizations• 2 years ago

Piling on, it's that industry of consultants and software vendors that keep windows in use. Microsoft protects those consultants, and those consultants protect Microsoft's market share.

jen20• 2 years ago

Even crazier is that the “click around” mentality made its way into azure too - back in the day (a decade ago, to be fair) I had a serious suggestion from a technical support agent there that the best way to automate some setting was with Selenium…

siriushacker• 2 years ago

Favorite line:

"I’ve never seen anybody use a GUI in a clever way. Ever. There’s no cleverness to it. No, like, Oh my God, you should see the way Adam clicked that mouse. Oh my God. Guys, guys, guys, guys, come on, check it out. Adam’s going to click the button. Oh my God. That’s amazing. It just doesn’t happen."

aragonite• 2 years ago

To be fair, a GUI can be used in a very clever and skillful manner. It's called keyboard shortcuts (and, to a lesser extent, mouse gestures). You can't deny an Excel world champion uses its GUI in a highly impressive way. And features like multiple carets editing (as popularized by Sublime Text) makes it possible to perform some remarkable editing feats. :)

dwoldrich• 2 years ago

At $dayjob I am blessed with the task of wrangling a 20+ year old codebase of SQL Server stored procedures. It's around 300k lines of monkey tested, business-critical code that:

* wasn't source controlled

* was never tuned (properly) for performance

* deployed into environments by editing/executing sql in SSMS.

* of course, no automated tests, etc...

It's a windows shop, I am developing on a Mac, and we do linux on Github Actions.

I selected tools like PowerShell Core, sqlcmd, docker for running Windows SQL Server instances, RedGate SQL Compare for extracting existing schema and code from the legacy servers, tSQLt for unit testing, TSqlLint for code compliance, SQLFluff for style compliance, and Flyway for deployments.

We quickly discovered PowerShell Core was the most interoperable cross-platform scripting shell when Windows had to be one of the platforms.

It wasn't pleasant to code in. The regex engine comes from .Net, which has bad catastrophic backtracking problems, and the array situation was goofy. Launching executables with any sort of control over the launch and capturing the output stream was hit or miss - I would often have to launch a process, redirect its output to a temp file, and then read the temp file after the child exited. So piping around with child's stdout into a string variable was always more trouble than it should have been.

BUT, PowerShell Core executes fast (nice job M$FT, if there's one thing you do well, it's micro-optimizing!) It has nice tools for interacting with the user, like ascii art list pickers and easy input prompt generators. And, most of the strange quirks in dealing with the Windows file system are papered over if one avoids folders with locked files.

Anything you want to achieve can probably be done if you search hard enough. Recommended!

pjmlp7• 2 years ago

Besides the whole interesting story background, yet another confirmation of the anti-.NET bias by WinDev during the Longhorn efforts.

Instead of uniting and having everyone collaborating into a common like Google with Android making it happen no matter what, or how Bell Labs tried with Inferno / Limbo, the active fight against .NET, and anything related.

To what ended up being the WinRT failure.

Ironically, WinDev is now shipping JavaScript and Webview2 all over the place on Windows 11.

desktopninja• 2 years ago

I wonder how many engineers use AWS's Powershell cmdlets?

They are incredibly well built and feel first class/more polished than a lot of AWS tools.

imperialdrive• 2 years ago

Thanks for this. Just seeing the word "PowerShell" gets me excited every time... been using it for hours a day for years and it's so much fun. It's how I first learned to code, professionally. Kudos and Cheers!

dangus• 2 years ago

I found the most interesting part about this article how it kind of makes a direct line from UNIX’s place as a place for programmer system admins versus professional services-driven servers.

These people at Microsoft knew that they’d wipe the floor with the professional services folks by getting that professional services cost out of the picture by providing the small UNIX-like toolbox to do sysadmin work via automations.

Of course, PowerShell being API-based instead of file-based was what came out of that.

It’s interesting because what has survived has essentially been Windows and UNIX (via Linux being able to drop all the proprietary baggage of UNIX solutions). Everything else that was built to sell professional services is dead.

Jeffrey Snover and the Making of PowerShell

Related Stories