5 ms·

Doesn't reflection make lots of things harder to debug and understand? Why should one need to take on the ugly patterns of other ecosystems? It also kills many

by bjz_ 11y ago

Doesn't reflection make lots of things harder to debug and understand? Why should one need to take on the ugly patterns of other ecosystems? It also kills many of the good points of statically typed languages - ie. type safety, ease of optimization, and performance.

joslin01 11y ago
Calling "reflection" an ugly pattern is like calling onions a bad recipe. It's up to you how you intend to use it, but please, let's not be ridiculous and call it an "ugly pattern of other ecosystems." Reflection doesn't get in the way of type safety (in fact, it's generally supported by it) and "ease of optimization" and "performance" is just BS. Ya, sure, sometimes reflection slows things down but web devs who use ruby for 90% of projects don't care about that. I'd love to hear you try and explain how reflection tarnishes "ease of optimization" and why it's so "ugly"
- netheril96 11y ago
  > Web devs who use ruby ... Ruby is not a statically typed language and has nothing to do with type safety or ease of optimization. Reflection for a dynamic language is hardly the same as reflection for static language.
  - joslin01 11y ago
    Good way to take a few words completely out of context. I said "web devs who use ruby for 90% of projects" as in "they obviously don't care much about performance in the first place" If you had anything you wanted to offer, I'm all ears but you telling me dynamic vs static reflection have different implementation details (and necessarily different implications) is pretty obvious, wouldn't you agree?
    - netheril96 11y ago
      I was wondering if you had more experience with Ruby than with a statically typed language like Java, and thus did not see the problem with reflection. Now, to answer your previous question, about how reflection is bad: * Reflection allows one to dynamically add, remove and modify properties and methods, and that breaks type safety. Compilers are no longer able to prove deterministically that a certain object has certain properties or certain methods, or that certain methods have certain signatures because all those may change at runtime. * That which can be dynamically changed must be dynamically resolved. And dynamic resolution is slower. * It breaks encapsulation. It exposes private APIs and allows immutable objects to be modified. That is why its usage is ugly. A dynamically typed language has much less problems with reflection, since in these languages, dynamic resolution is the norm, and they are not amenable to static analysis anyway.
  - fleitz 11y ago
    It may not be statically typed, but it is strongly typed which is usually more useful than static typing. For instance the type system in C is static but weak, creating entire classes of issues that are hard to debug that don't exist in ruby.
    - netheril96 11y ago
      > but it is strongly typed which is usually more useful than static typing. Strong typing is orthogonal to static typing and I do not believe one is more useful to another. The benefit of static typing is that you can catch many mistakes at compile time. Static typing also makes analysis and navigation of the code base easier.
- bjz_ 11y ago
  > Reflection doesn't get in the way of type safety (in fact, it's generally supported by it) Perhaps my terminology was incorrect there. It's more that it gets in the way of static verification, and makes it much harder to refactor code with confidence. For example, I am working on a Java project at the moment, for which many constructors and methods are apparently (to the IDE's static analysis) unused. I could quite merrily delete them or change their signatures, only to have the program it break unexpectedly at runtime due to reflection expecting them to exist at the opposite end of the codebase. That is the power of static types - and reflection breaks those guarantees.
fleitz 11y ago
Not really, you're just operating on a higher dimension. It's like saying multiplication makes things hard to understand... You could write things 15 x 3 or 15 + 15 + 15, I dislike having programmers who like to do the latter on my team, or languages that make you do things like: Integer(15).multiply(Integer(3)) I'm sure that using reflection or higher order programming does cut out some people that you probably don't want anyway.
- sscarduzio 11y ago
  It's a higher dimension of RUNTIME fuck ups. Leveraging the type system for COMPILE TIME dynamic programming is not only safer, but more runtime-efficient. Wanna be clever? Here you go, be type-safely clever: https://vimeo.com/channels/flatmap2015/128466887 https://vimeo.com/channels/flatmap2015/128466887 http://www.haskellforall.com/2012/06/you-could-have-invented-free-monads.html http://www.haskellforall.com/2012/06/you-could-have-invented... With a good type system, you won't need reflection. If it compiles, it will work. And give me a break on the "cut out the dumb people" part, I heard it many times from people right before they shoot themselves on a foot. Repeatedly. As engineers, it's our job to solve problem and reduce complexity. Fail at either of the two, you have been a shit engineer.

by bjz_ 11y ago

joslin01 11y ago

Calling "reflection" an ugly pattern is like calling onions a bad recipe. It's up to you how you intend to use it, but please, let's not be ridiculous and call it an "ugly pattern of other ecosystems." Reflection doesn't get in the way of type safety (in fact, it's generally supported by it) and "ease of optimization" and "performance" is just BS. Ya, sure, sometimes reflection slows things down but web devs who use ruby for 90% of projects don't care about that. I'd love to hear you try and explain how reflection tarnishes "ease of optimization" and why it's so "ugly"

netheril96 11y ago
> Web devs who use ruby ... Ruby is not a statically typed language and has nothing to do with type safety or ease of optimization. Reflection for a dynamic language is hardly the same as reflection for static language.
- joslin01 11y ago
  Good way to take a few words completely out of context. I said "web devs who use ruby for 90% of projects" as in "they obviously don't care much about performance in the first place" If you had anything you wanted to offer, I'm all ears but you telling me dynamic vs static reflection have different implementation details (and necessarily different implications) is pretty obvious, wouldn't you agree?
  - netheril96 11y ago
    I was wondering if you had more experience with Ruby than with a statically typed language like Java, and thus did not see the problem with reflection. Now, to answer your previous question, about how reflection is bad: * Reflection allows one to dynamically add, remove and modify properties and methods, and that breaks type safety. Compilers are no longer able to prove deterministically that a certain object has certain properties or certain methods, or that certain methods have certain signatures because all those may change at runtime. * That which can be dynamically changed must be dynamically resolved. And dynamic resolution is slower. * It breaks encapsulation. It exposes private APIs and allows immutable objects to be modified. That is why its usage is ugly. A dynamically typed language has much less problems with reflection, since in these languages, dynamic resolution is the norm, and they are not amenable to static analysis anyway.
- fleitz 11y ago
  It may not be statically typed, but it is strongly typed which is usually more useful than static typing. For instance the type system in C is static but weak, creating entire classes of issues that are hard to debug that don't exist in ruby.
  - netheril96 11y ago
    > but it is strongly typed which is usually more useful than static typing. Strong typing is orthogonal to static typing and I do not believe one is more useful to another. The benefit of static typing is that you can catch many mistakes at compile time. Static typing also makes analysis and navigation of the code base easier.
bjz_ 11y ago
> Reflection doesn't get in the way of type safety (in fact, it's generally supported by it) Perhaps my terminology was incorrect there. It's more that it gets in the way of static verification, and makes it much harder to refactor code with confidence. For example, I am working on a Java project at the moment, for which many constructors and methods are apparently (to the IDE's static analysis) unused. I could quite merrily delete them or change their signatures, only to have the program it break unexpectedly at runtime due to reflection expecting them to exist at the opposite end of the codebase. That is the power of static types - and reflection breaks those guarantees.

fleitz 11y ago

Not really, you're just operating on a higher dimension. It's like saying multiplication makes things hard to understand... You could write things 15 x 3 or 15 + 15 + 15, I dislike having programmers who like to do the latter on my team, or languages that make you do things like: Integer(15).multiply(Integer(3)) I'm sure that using reflection or higher order programming does cut out some people that you probably don't want anyway.

sscarduzio 11y ago
It's a higher dimension of RUNTIME fuck ups. Leveraging the type system for COMPILE TIME dynamic programming is not only safer, but more runtime-efficient. Wanna be clever? Here you go, be type-safely clever: https://vimeo.com/channels/flatmap2015/128466887 https://vimeo.com/channels/flatmap2015/128466887 http://www.haskellforall.com/2012/06/you-could-have-invented-free-monads.html http://www.haskellforall.com/2012/06/you-could-have-invented... With a good type system, you won't need reflection. If it compiles, it will work. And give me a break on the "cut out the dumb people" part, I heard it many times from people right before they shoot themselves on a foot. Repeatedly. As engineers, it's our job to solve problem and reduce complexity. Fail at either of the two, you have been a shit engineer.