1. 3
  1.  

  2. 2

    Language is a social decision, not a technical decision. Pft, madness, you say. Well, you could for instance say ‘the JVM is really slow.’ and decide not to use Java. Technical language decisions cannot reflect progress. So you are wrong when the JVM starts using dynamic information to gain speed over native C equivalents. You might say ‘Ruby is bad for multi-threading due to a naive garbage collector’ and then you’d be correct… until you are wrong.

    So, choose a language for social reasons. Maybe the community there is very much into the type of application domain you are interested in contributing. Less likely to change, and if it does, your stuff still works. If a language hinders you technically, work around it. You are picking a community which just happens to revolve around how-you-say-things-to-a-computer. Do I think, as the speaker suggests, that languages shape how you solve problems? No. I think very very much that the people around you shape not only how you solve problems, but which problems you solve.

    The caveat is when you have a very specific problem to solve that greatly benefits from existing work in a particular language. Obviously, you’d use that one. Arguably, that’s still a social reason!

    1. 1

      With all due respect, ruby is extremely inconsistent (eg. spat operator), wildly complex (eg. eigenclass, argument binding), and is an extremely immature platform (debugging/profiling/performance). If you spend the time to gain expertise, you can look past these things

      This feels like 7 languages in 7 weeks, where you spend enough time to have an idea what the language is about, but nowhere near enough time to really absorb the strengths/weaknesses, community, and ideas. For example, if you are not a lisp guy, and are doing this part time, you need at least a year on clojure to begin to get these things from it.

      1. 2

        With all due respect, could you elaborate on “eg. spat operator”? How is the eigenclass wildly complex? I find the Ruby object model and hierarchy pretty straightforward.

        I moved to Ruby after working qite a bit with perl and PHP. I was also doing Web development in Java (using an in-house framework that was very fast and very slick, so it was fun).

        I picked up Ruby quite quickly, and found that most of the time if I guessed at how to do something I was right. The language has assorted inconsistencies, but it never occur to me to call it extremely inconsistent or wildly complex; if that were the case I doubt I would have stuck with it.

        Over the years I’ve worked with Ruby I’ve determined that many things about the language are so poorly taught in books and articles that it’s wonder people learn anything advanced. Things are often made out to be more complicated than they really are.

        1. 1

          I was being a bit facetious. What I am saying is that there are things that dont make sense in ruby (much more then a lot of the language the speaker covered), but at the end of the day after a few months with the language it doesn’t matter. A lot of the speakers complaints with other languages will pretty much disappear once you gain a level of expertise with them. You are only a beginner for a little while, and the problems of a beginner aren’t the problems of an expert.

          Anyways, splat to gather params and splat to apply a list of args to a method are only related concepts on paper. When you are actually learning/teaching the language, it tends to be a pain point. And an invisible class in the lookup chain, plus multiple inheritance with modules makes “why something vs something else is called” much more complex then it is in pretty much any other language. On top of that, binding methods to the eigenclass of your class (which is an instance of Class) as the only way to have class level methods, is an extremely complex set of concepts that is in your face very early on. Ditto with method binding, making parens optional leads to some very non obvious corner cases that can actually lead to hard to see bugs.

          1. 1

            Anecdotally , what I’ve found with languages is that those that are rigorous in their core principles become hard to use in the course of common programming tasks. If special or exceptional behavior is added to make common scenarios easier they usually come at the expense of language simplicity. This certainly seems to be the case with Ruby. Syntax and behavior were added to fit the Principle of Least (to matz') Surprise, at the cost of making other (possibly less common) things harder to do or harder to understand. I find it, overall, a big win, but I can see that if someone comes at the language with different experience or expectations it might seem a mess.

            OTOH, languages like Ruby make it easy to jump in and start doing things without having to know jack shit about, say, eigenclasses.

            Whether Ruby is any worse than any other language, I can’t say, because as you’ve mentioned by the time I’ve used a language long enough to run into things that break my mental model of the language I’ve already become accustomed to a lot and tend to forget how weird some things may have been at first.

            This may be hard to judge objectively because that look simple (or not) on paper or abstractly may not play out that way for real people using to build real things. This is one reason I’m skeptical of any “7 languages in 7 weeks” deal because just knowing the syntax, without a good amount of practical experience, isn’t going to allow you to really assess a language. You have to live with it for a while to know what aspects are important and how well they work.