"I Contribute to the Windows Kernel. We Are Slower" (2013)

I'm hoping for a Python version that makes this zen item [1] the number one priority:

> "There should be one-- and preferably only one --obvious way to do it."

[1] https://peps.python.org/pep-0020/

I've used Python for more than a decade on Arch Linux, across many machines at home and work. For essentially all of that time, I've been "sudo pip install"-ing to my heart's content. The number of times this has actually caused problems with my own Python scripts is less than the number of times I've had to help colleagues figure out venv bullshit in the past six months alone. The number of times that "sudo pip install" has caused breakage of anything except my own scripts is zero in ten years.

AFAICT the Python core team has essentially no understanding of the level of sophistication and the actual pain points experienced by 95% of Python users. Python is the software equivalent of duct tape, and it is used accordingly. Putting the duct tape in a box that is hard to open and covered with warning labels is not a meaningful improvement.

That company later set up hackathons: A time-boxed escape from scrum, you can write whatever you want, and if the team likes the look of the hacky prototype afterwards it's adopted. Some things don't sound good before you write code, or some programmers can't tell the right story before writing code, not sure what, it doesn't matter anyway.

It's remarkable when you look at the landscape of Linux and Mac device drivers.

Can you run non-kernel drivers for Linux 2.6 on 6.6? Can you install a device driver from 2007 on a modern MacOS? Well, many Windows 7 drivers also work on 11. That's stability.

And I can run any win32 binary, regardless how old is it. Try that on Linux.

> That would destroy backwards compatibility

People who weren't bitten by it rarely understand that.

> PowerShell v1 and especially v2 were brilliant, elegant, and beautiful

Oh yes! One thing what I really liked is what an extremely big part of PS... was written in PS! You literally could drill down some system cmdlets to see, learn and adapt! It started to dwindle down with PS5, sadly, with performance requirements.

For example they can't make NTFS fast, and they can't seem to make ReFS (their post-NTFS effort) backwards compatible, so now they're shipping it as "Dev Drive". A Dev Drive is the same thing as a normal drive, but not as slow, because they concluded that only developers care about filesystem performance:

https://learn.microsoft.com/en-us/windows/dev-drive/

But the userspace also has a lot of weird performance problems, many introduced by their sandboxing efforts. For example their FS broker was extremely slow for a long time, maybe still is.

I'm a grey-haired .NET dev (pushing 50 now!) and for me that comment means there is no desire for new devs to learn beyond what they need for the day-job!

As an example: I learned programming in the 90s at a time when computer resources had to be managed - You couldn't just throw more servers at it since they cost so much money and you had to host them on-prem at the time.

So I learned the OS inside out. I knew how Windows worked to quite a low-level - Not Mark Russinovich levels but way, way more than colleagues did and all my code, even today, has an eye on performance all the time!

Back then, when I learned SQL, I spent lots of time tweaking SQL to get it to run faster - I mean the tables, indexes and such, as well as the SQL queries that I had to fix (I wasn't coding then but I had to fix much of the $hit that third parties produced).

Fast forward to now and you are lucky if 20% of our devs at my company understand SQL properly. They can write basic SQL statements but that's it! They all learned to program using ORMs and can't troubleshoot slow queries. I'm not joking! I had to fix a system that used EF and one of the queries that EF generated caused the DB to try to sort through 14B rows of data when we don't even have that much data in the DB! Our largest database had almost no indexes on it and they kept adding more CPU's to get it to run faster... it didn't! I've subsequently fixed it and we've dropped the CPU count quite a bit too.

I think Scott Hanselmann talked about it a few years ago. The analogy he used was to do with the kitchen taps in his house: they broke, and his wife's understanding of how the plumbing worked stopped at the point where the pipe went into the wall, so she had no idea what could be wrong! His argument (if I remember correctly) was that if you just try to understand what happens when the pipe goes into the wall then you'll open up a whole new world of understanding.

So I agree with the sentiment: we live in a world of abstraction and new devs are coming onboard without that desire to know what happens under the covers and it'll bite us in the ass when guys like me retire.

As an end user though I imagine most people use bash or some other unix-world shell, especially post WSL. The "Git Bash" distribution is surprisingly useful as an everyday Windows shell.