4 ms·
It was not built around any of that. It was built to facilitate compiler construction and add some introspection to that process. The problem is that building
by adestefan 3y ago
It was not built around any of that. It was built to facilitate compiler construction and add some introspection to that process. The problem is that building what is a compile and code generation library to cover multiple languages and multiple architectures is really hard. Abstractions start to get leaky. Next thing you know there are a bunch of assumptions and hacks that make you neat library a big ol’ mess.
I’m not faulting any of the llvm maintainers. Other people were hoping the IR and library bits would turn into more than a compiler toolkit. Unfortunately, reality sets in over time.
- Ericson2314 3y agoYeah the way things are is very naturally when one only compiles end-to-end --- there is little economic incentive to keep the internals modular when the productivity costs of entanglement only show up with a delay (and also programmers are not really compensated for productivity...). It's really good in this new LSP era good tooling is increasingly "mandatory", and language implementers have to deliver. (See also https://ollef.github.io/blog/posts/query-based-compilers.html https://ollef.github.io/blog/posts/query-based-compilers.htm... .) The higher standards of users (and aspirations of DARPA :)) are now providing the missing economic incentive.