> the "winning" strategy is to have high-level scripting languages where you can ignore most of the details
From personal experience, I don't believe this works in practice. Invariably, some level of logic is implemented in said scripting language, and it becomes a huge bottleneck. Counterintuitively, when you have a central thread dolling out work to many subroutines, the performance of that thread becomes more critical as opposed to less.
From personal experience, I don't believe this works in practice.
From personal experience, this works in practice.
It works well for web or other server-side tasks where your database is doing the "heavy lifting" computationally.
I believe you, though, when you say that you've seen failures of this paradigm.
It's pretty common to see issues where an inexperienced programmer is doing a bunch of data manipulation in 200 lines of Python/Ruby/PHP/whatever that could have been accomplished more easily, more performantly, and with more atomicity in 10 lines of SQL. I wouldn't say that means it's a busted paradigm. I don't consider bad implementations of a particular paradigm to equal refutations of that paradigm.
I do appreciate that there are probably arenas (scientific computing?) where maybe this approach doesn't work at all.
If you aren't using the scripting language enough for it to get in the way, you're probably not using it enough for it to make things easier either.
Just to be clear, I'm not saying it's impossible to strike the balance where it makes sense. I'm just saying I've yet to see it work, and I would, therefore, not assume such a balance is given by default, or even easy to achieve.
I agree with you. There’s also the additional cost of maintaining more than one language which makes the balance that much harder to do. I could see utility in the high level language to do something with the result if it’s not computationally intensive.
Have a look how games work. They are very performance critical - you have to calculate your simulation and draw it 60 times per second. That only works, if you have high performance low level libs.
It is very common to mix C++ with lua.
So yes, it is about balance, but it is standard procedure by now.
And with wasm (or even webGPU) one can do now the same with javascript and the web. Some logic in scripting is fine, but the heavy calculations should be lower level if one is aiming for performance.
The theory is that 99% of the code is in the high level language, and 1% is in the low level language.
In my experience, that means that 80-90% of the developer effort goes into getting the FFI bindings to not be terrible. (In fairness to things like python, most of my FFI experience is with Java, which is notoriously bad at such things)
From personal experience, I don't believe this works in practice. Invariably, some level of logic is implemented in said scripting language, and it becomes a huge bottleneck. Counterintuitively, when you have a central thread dolling out work to many subroutines, the performance of that thread becomes more critical as opposed to less.