3 ms·

IMHO, in retrospect, runtime access to annotations was a mistake. Possibly the level of reflection it offers, too. These two make all that code possible that ca

by moring 4y ago

IMHO, in retrospect, runtime access to annotations was a mistake. Possibly the level of reflection it offers, too. These two make all that code possible that cannot be understood statically. And yes, lambdas and macros would probably have been a good replacement for that those two were originally meant to achieve.

jcelerier 4y ago
It made a ton of software possible that wouldn't even exist otherwise. We don't have runtime access to annotations in c++ and it's a constant PITA as soon as someone wants to make something as basic as generating a GUI automatically from a data model, which is maybe 50% of what programmers do all day in the world
- 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

It made a ton of software possible that wouldn't even exist otherwise. We don't have runtime access to annotations in c++ and it's a constant PITA as soon as someone wants to make something as basic as generating a GUI automatically from a data model, which is maybe 50% of what programmers do all day in the world

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.