3 ms·

I first wanted to write: Generating a GUI can happen as a fully automated build stepü, without runtime reflection. But then I realized that such build steps re

by moring 4y ago

I first wanted to write: Generating a GUI can happen as a fully automated build stepü, without runtime reflection. But then I realized that such build steps re-introduce the same problems as runtime reflection does: You cannot understand the code statically. So, yeah, maybe reflection and annotations are simply an overused hammer that makes everything look like nails... It feels like every library goes out of its way to use annotations for everything, completely defeating type-safety and static analysis. When it should actually be like, "is there really no way we can solve this without annotations and reflection".

jcelerier 4y ago
Note that what I'm talking about is perfectly doable without any runtime reflection at all, only through static compile-time reflection. E.g. attributes in c++ are a purely compile-time thing - if there was an API to do stuff with them it would also be a compile-time one. The code isn't meaningfully different though. But yeah, "fully automated build step" generally looks like "let's parse enough of the language so that we can implement our own custom reflection system" which leads to every project having an incompatible one and in practice much more pain (and macros) for the developers than if it was a standard one, e.g. Qt, Unreal Engine and so many others have their custom homegrown reflection scheme and there are a thousand libs on GitHub trying to reimplement it: https://github.com/topics/reflection?l=c%2B%2B https://github.com/topics/reflection?l=c%2B%2B It's exactly like type systems being Turing complete : if yours isn't, someone somewhere will be making a language that compiles down to yours with one because of how useful of a property it can be in some cases. All of this is not accidental complexity, the alternative to not having them is much, much, much less productive in practice. My personal experience writing code with reflection is that at the cost of one complicated base library, the app code is literally 10x faster and simpler to write, and the huge majority of the time is spent in app code, not library one.

by moring 4y ago

jcelerier 4y ago

Note that what I'm talking about is perfectly doable without any runtime reflection at all, only through static compile-time reflection. E.g. attributes in c++ are a purely compile-time thing - if there was an API to do stuff with them it would also be a compile-time one. The code isn't meaningfully different though. But yeah, "fully automated build step" generally looks like "let's parse enough of the language so that we can implement our own custom reflection system" which leads to every project having an incompatible one and in practice much more pain (and macros) for the developers than if it was a standard one, e.g. Qt, Unreal Engine and so many others have their custom homegrown reflection scheme and there are a thousand libs on GitHub trying to reimplement it: https://github.com/topics/reflection?l=c%2B%2B https://github.com/topics/reflection?l=c%2B%2B It's exactly like type systems being Turing complete : if yours isn't, someone somewhere will be making a language that compiles down to yours with one because of how useful of a property it can be in some cases. All of this is not accidental complexity, the alternative to not having them is much, much, much less productive in practice. My personal experience writing code with reflection is that at the cost of one complicated base library, the app code is literally 10x faster and simpler to write, and the huge majority of the time is spent in app code, not library one.