471–480 of 579 posts
Earlier quoted context omitted.
ah, the New Coke Gambit
Ah New Coke… Oddly I liked new coke better. My most 80s possession is a new coke can with max headroom on it. They had both new and “classic” for a while co existing.
reference: https://en.wikipedia.org/wiki/Max_Headroom_signal_hijacking
Earlier quoted context omitted.
It's been said that Python's greatest superpower is that it's the second-best language at the most stuff. No one's really developed an ecosystem for a language that's more performant that can match it, and that's all it needs to assert dominance.
I've never understood this. Python cannot be optimized like C, C++ or Rust. It cannot do advanced functional things like OCaml, Haskell or Scala. It cannot run in browsers like TypeScript. It cannot do games programming like C# and it can't do crazy macro stuff like Clojure. I don't think it's even second best at those things.
But it can do them well enough, and enough people know it that they can drag a solution across the line in most domains.
Earlier quoted context omitted.
Also, that engineer time you would spend optimizing for performance costs more than just throwing more hardware at it.
That's the thing with single threaded CPU operations, you can't throw more hardware at it
Earlier quoted context omitted.
PyPy still has the GIL so the multithreading stuff is the same problem. However, the JIT does make things much faster
What happened to the STM version of PyPy with no GIL?
Earlier quoted context omitted.
Do you have any examples that aren't because of the OS (as in, not trying to run a 90's game on Windows 11) or specialized hardware (like an old Voodoo GPU or something)?
If you restrict yourself to programs that don't need an OS or hardware, you're going to be looking at a pretty small set of programs.
Earlier quoted context omitted.
You hope it doesn't ? > [Donald Knuth] firmly believes that having an unchanged system that will produce the same output now and in the future is more important than introducing new features This is such a breath of fresh air in a world where everything is considered obsolete after like 3 years. Our industry has a disease, an insatiable hunger for newness over completeness or correctness . There's no reason we can't…
> There's no reason we can't be writing code that lasts 100 years. Code is just math. In theory, yes. In practice, no, because code is not just math, it's math written in a language with an implementation designed to target specific computing hardware, and computing hardware keeps changing. You could have the complete source code of software written 70 years ago, and at best you would need to write new code to emulat…
Earlier quoted context omitted.
This is a total red herring, x86 has over 30 years of backwards compatability and the same goes for the basic peripherals. The real reason for software churn isn't hardware churn, but hardware expansion. It's well known that software expands to use all available hardware resources (or even more, according to Wirth's law).
30 years ago, right before Windows 95 came out, Windows was a 16-bit OS and the modern versions of Windows no longer support 16-bit programs. PCIe came out only in 2003, and I don't know that PCIe slots can support PCI. SATA is also from 2003. Even USB originally came out in 1996, and the only pre-USB connector slot I have on my computer is a PS/2 port (which honestly surprises me). For monitor connections, VGA and D…
The basic peripherals (keyboard and monitor) of today still present the same interface as they did back in the IBM PC era. Everything else is due to massive hardware expansion, not hardware churn.
How often do you update your drivers compare to your typical internet connected app? Software that handles the idiosyncrasies of the hardware (aka drivers) generally has a much longer lifespan than most other software; I don't see how you can reasonably say hardware breaking backwards compatibility is why software keeps changing.
Earlier quoted context omitted.
That's the thing with single threaded CPU operations, you can't throw more hardware at it
In this situation, "more hardware" would mean throwing a faster CPU at it.