There is an (IMHO quite underexplored) alternative of using HLL as a metalanguage for generating low-level code. Like Chisel/Spinal does for Verilog RTL, but with C or LLVM IR instead of RTL. I. e. terra-lang did this with Lua (afair didn't took off because of unfixably bad design choices from the start).
Why this matters: compile-time metaprogramming is the way to provide zero-cost abstractions. HLLs tends to avoid metaprogramming because it's hard, instead relying on rich runtime (i. e. late binding and dynamic dispatch). Sometimes (i. e. in game engine code) that's not really an option. And metaprogramming is best done is something lisp-like, rather than C-like or C++-templates like.
As to why this is underexplored, I think there are multiple reasons:
- The most important one: those who care about the language tends to spend so much time on the language that they never get to the actual product,
- We already have C++ templates which can do anything (they are also an unholy ureadable mess because they were invented for a completely different purpose) and C macros (which are also unholy unreadable mess because K&R hated macroprocessors passionately and curbed cpp to a bare unusable minimum). And people exposed to those conclude that any compile-time metaprogramming must necessarily be an unholy unreadable mess not worth exploring.
- Most library bindings are in C, so any such system should include a C parser. At which point you wonder why bother at all?
> using HLL as a metalanguage for generating low-level code
Unfortunately, this is very long known dead-end, because very few programs written evidence-based, but most just begin their life with first production release, and on some platforms (JVM), more than 90% of developer time spend to refactoring and maintenance of existing code, and many people don't know anything else.
So, templates are not enough to break through this wall, need infrastructure of libraries and debuggers, and may be macros, etc, designed specifically for fp and be at least on par with their imperative counterparts.
From what I see, looking promising, to discontinue UNIX systems (based on C, and yes, Windows is also favor of UNIX, as NT was made directly on foundations of VMS from Digital), and switch to something more high-level, like OpenStep (with high usage of SmallTalk), or at least BeOS (based on C++).
Sure, would be better to use Prolog based OS, when one will appear, or may somebody will create OS based on OcaML (Haskell, Rust).
What I see problem for gamedev, in many cases they need very high performance, and when nearly all target (current) OSs are just C-machines, it is very much like discover epic huge wall, when need to switch from OcaML level to C to get additional few FPS.
So most people choose easy way, they learn just primitive subset of C++ and work with it.
BTW I have an idea - for gamedev could be beneficial to make some VM engine (multiplatform), for example like BEAM, why not, but probably something much faster (like LLVM), but including rich library of structures and algorithms for structured data and optimized for GD, and with good debugging tools for high level structures.
This may become gamechanger, as it could be very fast, but high level abstraction, so people don't need to dive into machine level, and could work on high level.
From second view, looks like good way using ECMA-6 (for example) with Babel and some things added into browser debugger.
So, technically, high-level ECMA-6 language transpiled (more traditional word translated) to ordinary Javascript, and supplied file with structures, similar ideologically to C symbols tables, and within browser debugger (Chrome work) you could see not target JS but sources and debug on high level.
And when your code become mature, you just remove symbols tables and as usual, target optimized code become very much like obfuscated, and you could provide it as closed source.
So, as summary - must have all from list:
1. high-level language translator (may be into assembler, may be into some lover level language, as with ECMA-6 and JS)
2. some sort of debug support (as mentioned symbols tables)
3. good enough debugger, as much close to client platform as possible (Chrome is good example).
I worked with IBM PC clones and DOS for a long time. What I seen - just hexadecimal dumps, sometimes picture patterns and nearly nothing else.
Once one boy said me "this is Mac, on it things look different" and shown me just ordinary MS Office (for Mac) files in just standard utility. And I seen really other world - even on old MacOS (7..something), Office files was not just hexadecimal, but I easily see structure. Unfortunately, that's time I have not enough education in CS to understand how structures work, but some things was obvious. These was just some things partially implemented on ObjectiveC (too small objective part and too large C part), but any way it become significant shake of my world.
Unfortunately, in Linux I constantly see the same as in DOS - mostly just hexadecimal dumps, no structure, so developers don't have motivation to use structured data, as it will not help them on build and maintenance.
