> Typescript and C# have demonstrated that MS can design good languages

I would make a slight correction, Typescript and C# have proven that Anders Hejlsberg can design good languages, not MS.

Honestly, Hejlsberg is like the Midas of programming languages.

That man is a language designing genius.

He is the main designer behind:

Delphi (which inspired VB6, Microsoft's DOMINANT language through the 90's. But it's so similar to Delphi, that you can pretty much credit Hejlsberg for it's success), C#, and Typescript

Sometimes whole companies get credit for the genius of what is really just one or two architects.

When it comes to Apple innovations, it's Jobs

And when it comes to MS language innovations, with the exception of F#, it's Hejlsberg.

Visual Basic pre-dates Delphi. Remember VB6 was the 6th iteration of Visual Basic and VB hadn't really changed that much since at least Visual Basic 3 (which was the earliest version I used).

I always thought Visual Basic got unfairly mocked because it was a fantastic language and framework for non-computationally expensive workloads.

Delphi, on the other hand, I struggled to enjoy. I really wanted to love Delphi because Pascal was one of my favourite languages but Delphi just didn't gel with me and it's hard to explain why. However Hejlsburg was also the author of Turbo Pascal and that achievement alone deserves to put him in the history books in my opinion.

It's also worth noting that your Apple/Jobs comment should probably acknowledge Steve Wozniak instead.

s/Jobs/Wozniak/

True. As far as I know Jobs created almost nothing by himself but he was very good at recognizing and selling good things.

I love what Jobs did and I like Apple way better when he was there but Jobs didn't do it all by himself, he decided. So, I think that's different from 1 genius software architect building it directly.

I used to spend a lot of time writing Powershell (b/w versions 3-5). Absolutely loved the language, but my love for it fell off after learning more commonly-used scripting languages like Python and Ruby.

It's the best native scripting platform you can get on Windows, but some of its primitives (functions, classes) are weird, parallelism (at least in the v5 days) was massively hacky (process-based instead of thread-based through the PSJob abstraction, though you can use native threads if you put in some work) and its syntax and overall behavior makes it feel more like a scripting language than something you'd use to build real apps (even though you can). This makes it a really tough sell to use on MacOS and Linux, even though it's based on .NET Core and you totally could.

You expect powershell to be like C#,typescript or python when it is more akin to bash. It is a scripting language specifically designed for a command interpreter.

I have to say some of the things that I assumed were quirks turn out to be well engineered decisions once I learnt powershell in full.

For example I started appreciating the way output in PS1 works only after using the parallel for each and was floored by how everything fell in place.

Take this from a full time Linux user, if you're not using powershell you're using an inferior shell.

One major downside for cli warriors though- it takes a couple of seconds to start. (at least 6, I don't knoe about 7).

I would agree that Powershell has less quirks than bash which sometimes feels like one big quirk. But I think they could do much better. During my project we ran into a ton of issues around scope, return values from functions and other stuff that were really hard to deal with. You don’t see that with small scripts but our project has thousands of lines and becoming hard to manage. Now some smartass will say that Powershell is not designed for a project of that size but the cmdlets almost force you to use it for certain types of tasks. It would be pretty difficult to rewrite that code in another language.

Once you realize that you need classes to return values and functions don't return values I (admittedly not an expert) don't see anything more complex beyond that.

This thing itself seems like a quirk but again I'm not an expert so don't know how this was designed.

I wrote quite a lot of PowerShell code. I really like the language, except when I don't. And return and outputs in general are among the most infuriating points.

> In PowerShell, the results of each statement are returned as output, even without a statement that contains the Return keyword. Languages like C or C# return only the value or values that are specified by the return keyword.

I don't want all output, no, please, I don't want it. I want something specific and not all the junk around it. So you have to turn into ugly measures like out-nulling everything or searching through your output because there is always possibility that some commandlet outputed something you were not expecting and it will return before the value you actually wished to returned.

And classes are nice and all, but lot's of stuff are not compatible PowerShell 5. And there is also the added complexity.

https://docs.microsoft.com/en-us/powershell/module/microsoft...

Reading through the examples of the unexpected behavior in so many cases is flabbergasting.

Function return values is among the worst ideas the PowerShell designers dreamed up. A function will (more or less) return anything output to the terminal. This is a particularly bizarre decision considering how difficult it can be to get many Windows commands to be completely silent. Error handling, redirecting output, etc. all fail in many circumstances. It was completely aggravating. It has been a few years, so hopefully that's changed.

Of course it didn't, look at my sibling comment for a link to the updated doc.

I don’t remember the exact details but for example loading classes that reference each other was hard unless they were all in the same file. I ended up writing a preload step that would combine all library files into one big file and execute that. In general I found it hard to write reusable code once that code started referencing each other. Maybe there are ways around that but it seems kind of stupid to create a new way of achieving what other languages have already solved decades ago.

If cmdlets were easier to use i would probably have used a proper language like csscript or C# instead of Powershell.

With modules my pwsh 6 usually starts between 700ms - 2s. Not a big deal to me though.

Cold start? My cold start is 20 seconds but after that about the same as you so I did a rough "average" to try to convey that :)

If you have modules in your module path that don't declare their exports in the manifest, PowerShell has to inspect everything to find all the cmds. This is often what is going on when you have terrible startup times.

Look who's here! Everybody Jeff is the chief architect of Powershell and someone pretty high up Microsoft right now.

Jeff hello, if it's alright i wanted to discuss the target audience of Powershell.

As I understand Microsoft is currently targeting azure users and enterprise sysadmins. I would like to propose that You add features to it that bash and zsh power users take for granted and target the linux community so that it gets more cred and in the open source hackers community and consequently more usage by regular people. Basically the developers developers developers thing from your old boss...

To be honest, right now I can recall anything I'm missing, fzf works, so does z. I will look at the startup time issue (my biggest one right now, I literally had PS1 as my login shell briefly ) ...

Step by step we've been doing more and more focused on Linux users. If you take a look at our telemetry - it is clear something is working because Linux usage is through the roof!!!

https://aka.ms/psgithubbi

I don't want to make any news here but in a bit, the team will publish a blog articulating where we'll be focusing our next release. I think you'll like the direction we are taking.

Jeffrey Snover [MSFT]

That's great to hear, thank you. I look forward to more command line warrior friendly features

Yes that is cold start. I wonder where your slow down is. I only use 2 modules and have a rather small profile to load though.

I have noticed that profile scripts slow down my startup a lot.

I was happily surprised by Alacritty that launches Powershell much faster than Powershell itself (??) on my laptop at least.

PowerShell is a shell - a program that takes input, does work, and returns output.

Alacritty is a terminal - a container that transports user inputs to programs (like shells) and prints program outputs to the screen. The terminal owns the actual graphical window you interact with.

The default terminal on Windows is the Windows Console. Windows comes with two shells, the Command Prompt (cmd.exe) and PowerShell. Both of these run on top of the Windows Console.

There is also a new terminal in development by Microsoft, called the Windows Terminal. It's much more modern due to not having to be backwards compatible.

The start time is a major disadvantage behind Powershell. It takes 3 seconds to load even if you disable profiles completely versus <1 second for Python, Ruby or Bash.

Process creation on Windows has always been significantly slower than Unix. That is why PowerShell is skewed towards "built-ins" vs launched applications. The ramification of that is slower startup times.

Interesting note - it is also the reason why PowerShell was able to adopt the more natural Verb-Noun model for cmd naming. In Unix, this would produce a huge # of files OR and you couldn't do "VERB NOUN" because then you would have to multiplex on the VERB. Unix's "NOUN VERB" is the result.

BTW - VMS DCL stepped on all these rakes which is why it is have VERB/NOUN and half NOUN/VERB. A complete mess.

Jeffrey Snover [MSFT]

Would you consider a powershell server process to speed up startup?

This is an idea we've discussed, but not something we're investing in right now. It could also solve the sudo/elevation problem for cmdlets. However a privileged service would also bring more security concerns.

Hey Steve you're doing a great job with PS! Thank you for all the hard work you and your guys are doing. You are also exceptionally responsive on GitHub.

Yeah, it makes it useless for short scripts. But I think a lot of that’s the .NET runtime start-up time. So getting rid of it might be challenging.