1. 14
    1. 8

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

      • Execs told Snover “Which part of fucking Windows is confusing you?” when he proposed more CLI tools
      • Snover took a pay cut, and title drop, to work on PowerShell
      • The project was kicked out of Windows during the Longhorn reset
      • It took years of battles to get back into Windows

      Meanwhile, the architecture of Powershell was structured around requiring as little from various product teams, and testing teams as was possible, because getting help was always a challenge, as everyone was overcommitted all the time.

      1. 7

        Another interesting thing, is how Powershell exists because Windows isn’t file based. Jeffrey’s goal was server management, 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.

        1. 4

          That seemed to be a big issue with MS that they’re trying to overcome now, although not completely. Microsoft has always been “developers first”, but their definition of “developer” is “developers we home-grew on our stack”, not existing developers. Developers targeting Windows don’t get Vim or C, they get Visual Studio and Visual Basic. And everything is a GUI, don’t even think about touching that scary black box with the blinking cursor in it, or even manually editing project files. People think Apple is the GUI king, but I feel like MS is way more psychotically obsessed with GUIs than them.

          PowerShell, VSCode, .NET Core were a breath of fresh air, ~2016 was a super exciting time for me and I was in awe of the future with the new open Microsoft. After they tried to lock .NET Hot Reloading behind VS, and with their irritating obsession with forcing Clippy 2.0 on everyone, I’ve fallen back out of love, probably for good this time. But it was a really exciting time for that brief moment when MS did genuinely want to attract developers.

          1. 2

            There are still corners of .net that are frustratingly backwards compatible where msft refuses to evolve despite being “open source” and PowerShell 7 was this breaking point for me. We had an opportunity to fix some big bugs in a major version bump that eventually went nowhere because msft developers did their own thing at the expense of the engaged, professional users in the open source project.

            1. 1

              Microsoft has always been “developers first”, but their definition of “developer” is “developers we home-grew on our stack”, not existing developers. Developers targeting Windows don’t get Vim or C, they get Visual Studio and Visual Basic.

              I mean, do as the Romans do, right? I wouldn’t complain developing Unix applications there is no robust GUI builder or whatever. Windows isn’t Unix, and the existing environment is productive for building Windows applications. There’s a reason why MS was dominant in your typical line of business application.

              (I consider that period of Microsoft you’re enamoured with to be not so hot - .NET Core was a mess compared to Mono, Visual Studio was not so hot, etc. It feels weird to miss the Ballmer era, but the developer tools worked better and they weren’t focused on trying to be Unix tools but worse at it.)

              1. 1

                There’s a reason why MS was dominant in your typical line of business application.

                It was NOT because being a Windows admin was an awful experience.

          2. 3

            Powershell makes me sad. It was such a wasted opportunity. Windows provided a real API based on objects and handles. You didn’t have to marshal stuff through text streams. .NET pushed that even further. Corman Lisp was able to speak COM natively so you could call DLLs and define callbacks in Lisp interactively. Powershell could have been a Smalltalk style graphical environment to interact with that. Instead we got a reinvention of the mistakes of the Unix shell.

            1. 2

              While I respect Snover personally, the choice to build a shell on .NET seems to me like a serious negative. It makes interactive use “laggy”, and requires substantially more memory and CPU than a native shell would. This is something I cared enough about to write my own truly native Windows shell.

              Accounts like this make me wonder if it was more of a political decision than an architectural one: if BillG is pushing for .NET, and the .NET team need an application to showcase its framework, it provides a refuge for command line tools that the Windows team see as not part of their vision. Edit: see the comments about Notepad for example, which which mirror my opinion/experience.

              Although I still use Powershell a bit for scripting and administration, its .NET dependency limits where it can run. The PS team may not have foreseen phones, containers, rented cloud VMs whose cost is proportionate to size, preinstallation environments or even security environments where any surface area that can be removed is; but the end result has been many “alternate” tools for basic administration.

              1. 1

                I’m not sure what being on .NET has to do with PowerShell’s performance? .NET has pretty close to native performance when it comes to raw execution (it does basically just JIT compile CIL to native code, so the startup time is trash but the execution time is fine), really the biggest bottleneck is the GC. I can’t vouch for PowerShell’s overall quality and performance, but I don’t think being on .NET impacts it that much, unless they’re just really under-utilizing it. As a comparison, ASP.NET was largely considered one of the most performant web servers available. On the other hand, I’ve seen demos from C# video games about how badly the GC can throttle performance if you’re creating and destroying many entities rapidly, which a web server or a shell wouldn’t need to do.

                1. 3

                  I’m not sure what being on .NET has to do with PowerShell’s performance? … startup time is trash

                  That’s basically it. The first launch of a new shell takes a long time, and operations take a long time until it’s done JIT-ing whatever you regularly use. My biggest peeve is the speed of the first tab in tab completion, which can take seconds. But if you leave the shell running for an hour, I agree performance is fine. (Memory consumption in that case is still awful.)

                  1. 1

                    Pretty sure .NET supports pre-JIT’ing binaries into some kind of executable cache which should make startup performance fine, although nobody ever really messes with it outside of iOS (since iOS bans JIT’ers). But yeah memory usage probably isn’t great, that’s another downside.

              2. 1

                This was a great episode!