Only problem is Powershell's commands are abysmally slow in comparison to chaining together Linux terminal commands that are written in C.

Powershell is a super neat language though.... especially if the Microsoft team that manages it would work more with the team that does more for SMEs and not just DevOps. The overwhelming majority of windows users doing regular business work have to deal with crufty stuff like VBA or over engineered stuff like C#. I was really hopeful for Powershell, but it seems like it's almost entirely to serve IT administrators or software developers. I wish that very capable team would do things like add a fairly simple GUI DSL or form designer with the tool. I know it can hook into WinForms, but that's a lot of effort and requires more C# background. There are probably millions of business analysts that would love to build little simple GUI apps without investing weeks of effort. The current approach is to just use Python, but that has it's own bag of problems for those that can do a little coding, but aren't full time developers. It just seems weird that Microsoft never invested in a language for SMEs that would integrate well with the OS and Microsoft apps and tooling.

Powershell is a terrible "language". It's fine for sysadmins to do sysadmin work but why would you want to subject business analysts to that level of unix shell inspired weirdness. Microsoft already has VB.NET which would serve that market much better.

Give me C# over PS any day.

Terrible? For writing GUI yeah, sure, not that it was designed to do it. Just it's possible to tap into .net world, that's all.

VB.net is still .NET which is fairly complicated and verbose. It's basically just a visual basic skin over C# right?

It’s not Unix shell inspired at all, that’s the problem.

Oh it is, just in all the worst ways. I mean look at this:

   $value = 10
   if ($value -eq 10) {
      Write-Host "Value is exactly 10."
   }

At least it doesn't let you do this (as far as I can tell) so it seems slightly better in that aspect:

  value="1 -o 1"
  if [ $value -eq 10 ]; then
    echo "Value is exactly 10."
  fi

The syntax is terrible, though – if these operators are not actually options for a command, which is the context where the leading dash makes some kind of sense, why make them look like that?

Also, why does the documentation[0] talk about statements returning values? I've never seen the terminology used that way before. Usually expressions evaluate to a value and statements can consist of an single expression.

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

What else would the operators be? They can't use `>` because that does IO redirection, they can't use `|` for OR because that's piping.

They could use `==` for equality but then what symbols would -ceq and -ieq be?

What symbols or what else would work for `-match` and `-in` and `-cmatch`?

If they were just `eq` or did use `==` how would that work for when they are actually options to a cmdlet such as `| where-object -eq $x` ?

They didn't need to copy any awful shell syntax. We have decades of programming language development but Powershell cribs from oldest and most cobbled together environment. Give up on the old syntax for IO redirection and piping.

I also don't even like their verb-noun philosophy because it's impossible to figure out what the commands are and there are so many. It's still all objects and methods underneath but you can't auto-complete anything.

> "Give up on the old syntax for IO redirection and piping."

Handwaving away decades of muscle memory and expectations for > and | seems bad, but those are the easy cases, and you've avoided dealing with the operators which are not symbols and the case sensitive/insensitive variants of common operators. What do you suggest for syntax instead which handles all, or most, of the cases PowerShell handles?

We have had "decades of programming language development" but I'm not aware of any which do what PowerShell does. I haven't spent any time on OilShell or NuShell or other Unix-shell-modernised systems, but Python syntax and behaviour does not make for a good shell, nor do any other programming-language-with-REPL that I've used. What language are you thinking of which makes a good compromise of both shell and pipeline and programming language, which would also work in the Windows world where things aren't text (PowerShell design priority)?

> "I also don't even like their verb-noun philosophy because it's impossible to figure out what the commands are and there are so many."

On a computer system where many thousands of things are possible, specifying what to do by command line is going to require typing one thing for every option you need to specify. Whether that's in the command name, in the command options, in the arguments to the options, or externalised in some ENV variable or /sys/ namespace or some /proc/ data source or some /etc or .dotfile config option, or hiding in some JSON structure, it's only shuffling the complexity around. At least with many commands they are organised into modules, searchable, and can have associated help.

> "you can't auto-complete anything."

*date*<tab> cycles through all commands with 'date' in their name. Cmdlets and binaries and functions.

hyper-v\*failover*<tab> cycles through all cmdlets in the Hyper-V module which have 'failover' in their name.

Get-Command -Noun VHD searches for commands with VHD as the noun part of Verb-Noun.

Get-Command -Parameter VlanId searches for commands which take -VlanId as a parameter (e.g. Hyper-V\Set-VMNetworkAdapterVlan).

I actually find that very readable. What is the problem?

The weird part of PS is the piping, which doesn't always do what you think it should as everything is an object instead of text.

Perl users feel right at home.

That is actually an advantage.

It’s not when they came up with something worse. With the exception of object pipes.

Thanks! I think the team we're on has a very clear focus on making developers happy. Like, we're all ourselves, developers, so a lot of it is very self-serving. Anything we can do to make our own lives better is probably going to be a good thing for a lot of other developers too.

Shame the rest of the company is dedicated to making users unhappy to scrounge a few extra pennies. Users include developers of course.

(See the transcript of Security Now 958 for recent details.)

I use WSL2 a lot because my current employer is a "Microsoft" shop (despite all the code being deployed in Linux containers).

For us developers, the changes in Windows to support WSL2 weren't really an enhancement of Windows, it's now just a really complicated way to run Ubuntu. As in, Windows 11 is the biggest Linux bootloader in history.

sudo for Windows...can't even see a use for it any more.

you are lucky, where I work WSL2 is blocked for security reasons

WSL 1 is allowed luckily, but it's kinda meh

Windows change is welcoming, yet still not quality. As stated by someone below, sudo is https://www.sudo.ws/. Microsoft should give it a proper distinctive name lie wsudo or psudo. Little thinks like is compounds the issues with Windows / Microsoft.

Even continually sticking to old design patterns causes issues in development and deployment. Big name companies do not trust applications running on hosted Windows because of their current business practices. Microsoft does not even have a means to provided ease of deployment for air-gap system. This is the only way some big business will let products hosted on Windows to be in their facilities.

Windows as become more problematic for me because of all the layers of security that need to be applied for companies to trust Windows. This causes issues such as having to stop typing because Visual Studios or VSCode cannot process key strokes in real time.

Localization translation text standard still does not allow for containing singular and plural in the same key. Translations should be easily to update so the client can improve wording on the fly. Microsoft still recommends using resx and compiling a DLL.

.....

Is that really what companies have to do to "trust Windows"? From my experience, it's rather driven from the need to look compliant. Thus, managers without in-depth knowledge decide to buy "endpoint security solutions", the more the merrier, deploy them to your machine, and that brings things down to a crawl.

Why to a crawl? Well, I've witnessed multiple antivirus products go bezerk on your dev folder if you compile C++. Turning them off for this folder increased performance by a factor, which is what's typically done and completely subverts the purpose of these products. Also, I witnessed a certain product with a bird of prey that would run for hours and then just crash on a directory with a few million files.

This combination of sub-par quality of "security" products and performative deployment of endpoint security is a bane, at least for me as an enterprise software developer. I don't see Microsoft being primarily at fault there.

Most businesses that use Windows and/or Microsoft products do no go through all of that. The main benefit of using Microsoft is all of the integration between development products and DevOps. Most of the solutions for security are not provided by Microsoft, and often are looking to check off boxes to make auditors feel better, without actually enhancing anything. I've had to create some bizarre workarounds just to get past auditors, and in the end the solution was no more secure than doing nothing at all.

>Windows as become more problematic for me because of all the layers of security that need to be applied for companies to trust Windows. This causes issues such as having to stop typing because Visual Studios or VSCode cannot process key strokes in real time.

This is a big issue for me. I'm stuck using Windows for work, and it runs like an absolute dog even on good hardware.

winget has Python 3.12.2 at the moment, which has been released two days ago.

And you don't have to use --id - you can do `winget install 7zip` etc in cases where there's no ambiguity.

It doesn't turn up here, maybe I'm on the wrong website? https://winget.run/search?query=python%203.12. For that matter 7zip doesn't show up in that search either.

I was able to find the 7zip page by googling for it: https://winget.run/pkg/7zip/7zip

But as with Python the default suggestion is `winget install -e --id 7zip.7zip`. If I can just do `winget install 7zip`, why can't they show that command? Why is the complicated way the default and the simple, intuitive method optional and not easily discoverable?

There's lots of room for improvement.

> But as with Python the default suggestion is `winget install -e --id 7zip.7zip`. If I can just do `winget install 7zip`, why can't they show that command? Why is the complicated way the default and the simple, intuitive method optional and not easily discoverable?

Those sites give you the command line exact match (-e) --id as a safety precaution so that you install exactly what you were looking at on that website and not a fake or similarly named but different installer or a different version than what you expected.

The complicated way is optional, you are using two different options: -e and --id. The CLI's default is actually sloppier when you don't use those two options in that way.

It seems easily discoverable from `winget --help` to me. But I tend to use `winget search` rather than websites, so maybe I'm just more familiar with it.

winget.run is no longer updated. Try https://winstall.app