1. 10

  2. 3

    It’s always interesting to see what the dark corners of a language are. They seem near unescapeable. For C#, I can think of the various rules and boilerplates around equality. For Python (the so-called easiest language to use), they exist around what really happens with __add and friends thanks to things that have been done to help performance. For C and C++, undefined behavior is the well known bogeyman. C++ also has heavy template metaprogramming. The only thing that comes to mind for Java is GC tuning. JavaScript has this, new and prototype chains.

    I can’t think of any for Haskell, Objective-C or Swift, at the moment, but I’m sure they are there.

    1. 6

      Thunks are Haskell’s dark corner. Laziness is great until it isn’t! Reading Performance/Strictness in the wiki is helpful.

      1. 3

        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.

      2. 3

        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.

        1. 3

          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.

          And it also brings to mind this article from yesterday about ES2015 classes. As much as I might struggle to help someone learn Ruby these days, I could at least try. With JavaScript, I wouldn’t even know where to begin.

          1. 2

            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.

            I haven’t kept up with Javascript, but the last time I looked (and I looked pretty deep) it was way simpler than Ruby.

          2. 1

            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.

          3. -4

            ruby is a dark corner.