@Edward de Jong / Beads Project "Nowadays with gigantic memory stores, worrying about how big a box to store is of minor importance for 99% of programs" I've heard some variant of this statement for 25+ years now ("computers are / will be faster so maximum efficiency is less important"), and it always turns out to be wrong. For one, as computers grow in ability, we simply want to do more complex things with them. Give programmers space, and they will fill it up until things get slow. A more efficient language gives more room to grow. More deeply, a faster language can be said to be more "high level" than a slower language since the programmer doesn't need to worry about performance consequences so much. My simple, brute force C++ algorithm may be smaller, simpler and faster than your complex Python algorithm 🙂

"Nowadays with gigantic memory stores, worrying about how big a box to store is of minor importance for 99% of programs" I've heard some variant of this statement for 25+ years now ("computers are / will be faster so maximum efficiency is less important"),

Is it wrong? The majority of apps in the world run in JavaScript in browsers or webviews which fits the description of "99% of programs". Maybe quibble with 99% to just "the majority of programs" I'm a game programmer so I generally hate inefficiency and am super sensitive to how inefficient things are but here I am in this app called slack that is written in JavaScript (the client side at least) running in a browser on my desktop or a webview on my phone. I use gmail, google docs, google sheets, all the time. I use VSCode also written in a browser in JavaScript. The majority of games today are written in managed C# (Unity) so while it's true we could get 5x to 25x more efficiency if we used the right techniques it still seems true that for "most software" those things don't matter.

we're now getting into definition territory, but I would argue that the amount of apps that could benefit from more speed / a faster language is waaaay more than that 1%, and that includes many web apps.

These environments\platforms\engines (Unity, browser, electron) are now focusing on making it possible (if not easy) to get the extra 5x-25x more efficiency by adding new low level constructs that are more efficient

Most of those technologies you mention are actually arguments FOR needing faster languages 🙂

oh yeah that was my point 🙂

I don't feel like claiming a game engine written in C# would suck is an example of anything really. There was a game engine written in C# though, XNA, and plenty of games shipped with it. In any case we optimize the parts that are too slow. Tons of scientists use python and numpy to do science. Does the fact that their python code would use less memory and run faster mean they should be programming in assembly language instead? No, they get stuff done by using what they consider to be a productive language, python, and having it call out to custom more optimized solutions when they need to (numpy). This is arguably the same for most apps. They don't need ultimate efficiency. In fact I'd argue if they prioritized efficiency of CPU execution and efficiency of memory they'd lose on efficiency of developer time which would effectively make software less useful. Lowering developer efficiency means less features, less bug fixes, etc...

In my Discus labeling product, which sold a million copies, it was written in a very efficient medium level language called Modula-2. But after profiling it, i found that certain operations were sluggish because it involved triple loops, with per-pixel calculations. Those operations were rewritten in assembler for that 4x speedup which only comes with hand tuning which registers hold which values, and taking advantage of the many weird quirks of the i386 architecture. So i say use the most efficient for programmer time language you have available, and only after the product is in testing do you run benchmarks, identify the slow parts, replace them. A huge fraction of a program is not performance sensitive, and the programming cost especially in elapsed time, is often of great importance. People are way too harsh about performance, and way too liberal with their time. There is undisputed evidence that a person writes about the same number of lines per day of debugged code regardless of the language, so leverage is applied by using a higher level, more powerful language. If you work for Adobe and are in charge of the Gaussian blur function, you will spend man years making it work on 20 core machines, but for most of us regular folk, getting our product out the door with few to no bugs is the overriding goal.