1. 7

  2. 5

    The end of this post is what the author values in programming, to be “fun and happy”. And that’s fine. Things being easy will probably make someone fun and happy up to a point. At least most Ruby developers I’ve met feel productive. As someone who has been on the catcher side of a Ruby/Python pitcher, I find that operationally their complexity (which often is why they are easy) make them challenging to operate, debug, and modify. At around 1000 - 3000 lines of Python is my limit for being able to make a serious change without causing disaster.

    I can’t speak for Clojure as I have not used it and don’t know the community but I think many people believe simple and easy are a dichotomy, you can have one or the other but not both. I am a library author for the most part and the way I tend to build the library is in two pieces. The first is the simple components. The primitives, more or less, that will solve the problem with clear semantics. And I guess, maybe, that is where the Clojure community stops? But the next portion is I offer the primitives in pre-combined pieces based on how I expect users will want to use the system. They can always drop down to the primitives if they need to do something special but the 80% use-case is written for them. Where the tension comes in and I push hard against is when someone wants to modify the primitives to make the combined solution easier. In my world, that is greeted with a strict “no”. The combined solution is convenience, the primitives are the solution.

    I believe I have had great success in this. My solutions are rarely rejected and sometimes people even point out how they are good. Maintenance tends to be very little on the code I write and debugging tends to be not that complicated. As a specific datapoint, at a previous employer we had two teams with completely different world views. The team I was on worked as I’ve described here. Most of our libraries for that project didn’t go much past version 1.0. The other team really focused on easy and their software was very complected. In some cases they’d even poke fun at our system because we had so many distinct components. However, on average, our system malfunctioned less. When it did malfunction, determining the issue and fixing it was usually much faster (a day compared to half a week). We needed fewer developers on the project and it scaled better. I’ve seen similar results play out multiple times in my career. That shouldn’t convince anyone one way or the other, there are a lot of confounding factors, but for me the results are a strong indicator the system works if the goal is correct software.

    1. 1

      I’ll never understand why people fight over programming languages. Do carpenters fight over which type of hammer is best to hit a nail with? No, they just build the thing, using whatever tool is best for the job.

      1. 3

        The concept that your metaphor rests on is identity.

        Do carpenters fight over [types of hammers]?

        If we could find two carpenters who had come to identify with their hammers on some level, via some aspect of them (brand, material, shape), I’ll bet the answer is yes! They would have a spirited and ranging argument about whatever details mattered to them, and it would probably be really fascinating to watch for all of us who assume “a hammer is hammer”.

        Ultimately, I take your point, but the propensity to identify with a programming language is, for whatever reason, higher among programmers than hammer-identity is among carpenters.

        (Aside: I would be incredibly sad to see Clojure begin to decline in popularity earlier than Scala)

        1. 2

          Your analogy is broken. Programming languages are nothing like any tool a carpenter uses and they are orders of magnitude more complicated. When a carpenter builds something, the tools they use to build are are not embedded in the resulting artifact. But programs are extensions of the language they are implemented in. I often have to read stacktraces from “production” software I’ve installed, and to understand those stacktraces and what the issue is I need to understand the language. If I want to fix a bug in a program I need to understand how it was implemented and what it was implemented with. For the desk I own it doesn’t matter if the original creator used a nail gun or a hammer. The choices programmers make in how to implement a solution stick with it for its life.

          1. 1

            Oh, analogies! Fun!

            You could have made the desk in oak, or multiplex, or cheap pine wood. You could have made a solid desk with drawers and ink well, or just some boards, or one with just three legs. You could have asked a non-carpenter for your desk and have gotten something something perfectly usable from iron, or from glass, or poured from concrete. Seems like you’re also stick with those choices for its life.

            1. 1

              The comment I was responded to talked about tools such as hammers. When I buy a desk the material it’s made out of is actually often a requirement, whereas the language software is made with is often not an explicit requirement. Analogies suck but I don’t think your response really changes the discussion in any meaningful way.

          2. 1

            In a idea world, we could pick tools based off of the need of the job. Its not one though, most of the time Whether it be a library, framework, team decision, or relic of the past driving usage, the choice of programming language was made for you and is never within your control.

            1. 1

              People tend to use the tools they have, obtaining a new ones only if their current ones are grossly inadequate for the job.

              They use the best tool that they have for the job, not the best tool.

              The fight is over which tools other people have, because we benefit when others have the same tools as us.

              1. 1

                The fight is over which tools other people have, because we benefit when others have the same tools as us.

                I don’t like framing it as a “fight”. Instead, I would prefer framing it as collaboration, or simply sharing ideas. Ruby has certain ideas, Clojure has other ideas; we take good ideas when they are applicable to the problem domain. No need to fight over which is best. Just say “hey, that feature X is a good idea” and use it if it works for you. If it doesn’t work for your situation, that’s fine too.

                1. 1

                  And yet, you chose to describe it as a fight, and said you would never understand why they did.

                  Clearly, people are taking it beyond level-headed argument. I’ve proposed one explanation, which I think is enough on it’s own to explain the phenomenon.

                  1. 1

                    I’m not sure you’re understanding what I’m getting at. What I’m trying to say is what Linda Rising says in this video, though she says it better than I.