I commiserate with your frustration with developers writing things suboptimally all too often. However, I disagree with the assumption that it's a JS/Python vs C issue.
Example: when VS Code came out, it was much, much faster, more responsive and stable than Visual Studio at the time. Despite being based on Electron, it apparently was much better on architecture, algorithms and multithreading than VS with its C++ and .NET legacy codebase. That really impressed me, as a C++ programmer.
Overall, it feels like folks who idealize bygone eras of computing didn't witness or have forgotten how slow Windows, VS, Office etc. used to feel in the 90s.
> Overall, it feels like folks who idealize bygone eras of computing didn't witness or have forgotten how slow Windows, VS, Office etc. used to feel in the 90s.
Let’s normalize speed over time like we do dollars, so we are talking about the same thing.
Given the enormous multiplier in CPU and storage hardware speeds and parallelism today vs. say 1995, any “slow” application then should be indistinguishable from instant today.
“Slow” in the 90’s vs. “Slow” in 2025 are essentially different words. Given unclarified co-use pushes several orders magnitude of either speed or inefficiency difference under the rug.
The promise of computing is that what was slow in the 1960s and 1970s would be instant in 1990. And those things were instant, but those things aren’t what people did with computers anymore.
New software that did more than before, but less efficiently, came around, so everything felt the same. Developers didn’t have to focus on performance so much, so they didn’t.
Developers are lazy sacks who are held skyward because of hardware designers alone. And software developers are just getting heavier and heavier all the time, but the hardware people can’t hold them forever.
This cannot continue forever. Run software from the 1990s or 2000s on modern hardware. It is unbelievably fast.
Maybe it was slow in the 1990s, sure. I ask why we can’t (or won’t) write software that performs like that today.
The compiler for Turbo Pascal could compile something like a million lines per second in 1990. We have regressed to waiting for 60+ minute C++ compile times today, on even moderate project sizes.
Debugging in visual studio used to be instant when you did things like Step Over. You could hold the Function key down and just eyeball your watch variables to see what was going on. The UI would update at 60FPS the entire time. Now if I hold down that key, the UI freezes and when I let go of the key it takes time to catch up. Useless. All so Microsoft could write the front end in dotnet. Ruin a product so it is easier to write… absolute nonsense decision.
All software is like that today. It’s all slow because developers are lazy sacks who will only do the minimum necessary so they can proceed to the next thing. I am ashamed of my industry because of things like this.
“Developers are lazy sacks who are held skyward because of hardware designers alone”
As a programmer who studied computer and electrical engineering in university, never before have I been so offended by something I one hundred percent agree with
Counterpoint: single threaded performance hasn't improved much in the past 20 years. Maybe 5x at best. And virtually every UI programming environment still has problems with work done on the main thread.
RAM parallel bandwidth, increased caching levels and size, and better caching rules, instruction re-ordering, predictive branching, register optimization, vector instructions, ... there have been many advances in single thread execution since the 90's. Beyond any clock speed advances.
Multiple targets is definitely the plan, and GLSL is my next priority. Metashade can currently generate HLSL for the DX12 version of https://github.com/ppenenko/glTFSample/tree/metashade_demo, and there's also a Vulkan version of that demo using GLSL. So implementing GLSL generation for that would be a great proof of concept and a test bed: HLSL and GLSL generated from single source and producing identical rendering results.
The diagram on slide 31 of my presentation shows how implementation is currently inherited between the Metashade packages. The future GLSL generators should inherit common functionality from the "rtsl" package, just like the existing HLSL generators. However, I expect heavy refactoring to be necessary because I was initially targeting just one language and so not all code is implemented at the appropriate level.
Agreed that the ability to just run on the CPU is valuable. Metashade doesn't support that yet and its codegen syntax doesn't look like regular Python code (everything codegen-related is prefixed with `sh.` etc.) but it's certainly possible to write a generator that would just execute the code "in the immediate mode" or generate C/C++ code for the CPU.
Regarding templating functions with functions - in Metashade you can just specialize the generated code however you see fit, with Python as the meta language. E.g. Python's `if` statements can act like `#ifdef`s or `if constexpr`, and you can certainly pass around callables to parameterize behavior.
No, I don't believe Jinja would suffice. For starters, how would you abstract out the syntax differences between, say, HLSL and WGSL? Jinja's approach seems to be taking the syntax of the target language and embedding templating into it. But with Metashade, we're replacing the different syntaxes of individual target languages with that of Python. Since this approach is largely agnostic of the target language syntax, new targets can be added in the future without rewriting target-independent, polymorphic code implementing rendering or compute techniques.
Example: when VS Code came out, it was much, much faster, more responsive and stable than Visual Studio at the time. Despite being based on Electron, it apparently was much better on architecture, algorithms and multithreading than VS with its C++ and .NET legacy codebase. That really impressed me, as a C++ programmer.
Overall, it feels like folks who idealize bygone eras of computing didn't witness or have forgotten how slow Windows, VS, Office etc. used to feel in the 90s.