I can’t think of any for Haskell, Objective-C or Swift, at the moment, but I’m sure they are there.
Thunks are Haskell’s dark corner. Laziness is great until it isn’t! Reading Performance/Strictness in the wiki is helpful.
Generics are actually pretty weird / ugly in Java, but it’s rarely an issue in practice. You will butt against the limitations of the system before finding the quirks.
One thing that I think developers learn over time is to avoid code which relies on these more complex, more obscure details. There be dragons and unless you have a firm mental model of it, it’ll eventually lead to a nightmare debugging session.
I have this growing concern about how difficult it is to enter some software ecosystems versus others. About how hard it is to jump onto the metaphorical moving train.
When I got to the section that discusses refinements, I had a knee-jerk reaction so strong that I verbally exclaimed “No, just don’t! Nobody uses refinements!” in a quiet room. But we only have the “nobody uses” knowledge because we happen to be in the ecosystem as it grew and changed. If someone asked me how to get up to speed in Ruby at this point, I would struggle to be of any help because their newbie experience would be so different than mine was.
Across these articles, a surprising number of details elicited that same thought:
“But I would never use [feature] for that”
“That’s almost never a problem, because [reason]”.
So now I’m reflecting on the extent to which writing “good” Ruby code comes from a shared (social?) awareness of what not to do, how not to structure projects, how not to build module hierarchies or share constants, and so on–rather than an awareness of what the language can do.
Sure, the article shows the contrived because I wanted to have the full precise ruleset. Twisted examples are the most enlightening in that regard. This is not a guide of best practices :)
Regarding refinements, the motivation for them is solid, and if I were writing libraries in Ruby I still would use them in preference to monkey patching. The implementation might be lacking, but it’s still better than polluting the user’s environment.
Definitely. Still, some things do come up: linearization issues from time to time, constant lookup, weird argument-parameter behavior.
Actually, I think that because Ruby has so many corner cases, the rules are under-publicized, and some situations that would otherwise not be that problematic can become really puzzling because it’s almost impossible to find some of these rules.
ruby is a dark corner.