> And wouldn't one solution be to use an alternate front-end with less clunky and error-prone syntax (say, python) that has doc strings so you can hover over an

> And wouldn't one solution be to use an alternate front-end with less clunky and error-prone syntax (say, python) that has doc strings so you can hover over an API in your IDE and read what it does, get auto-complete, etc.? You're right of course that there are great advantages to using existing languages with familiar syntax and good existing tools. I agree that CMake should have gone with an existing language rather than inventing a bad one of their own. Same applies more generally to projects that roll their own language for no clear reason, such as FlightGear. [0] For me the question is how much work it would be. If they could introduce a decent Python frontend, in addition to supporting their existing language, I agree it could improve things greatly. > The benefits of allowing arbitrary language bindings are immense. Arbitrary languages? If that's the end-goal, presumably they'd really just be exposing a C API (the way LLVM does), or a machine-friendly text interface (LLVM supports this approach too with its own assembly language). I don't think that would be the way to go, but I can see the case for supporting one language well. Python3 would be a fine choice. [0] http://wiki.flightgear.org/Nasal_scripting_language http://wiki.flightgear.org/Nasal_scripting_language