1. 38

Author suggests some actions that could be taken to alleviate pains of modern Ruby (and Rails) development which he thinks are mostly caused by idiomatic & implicit code and lots of DSLs instead of simple APIs.

While I agree with most of the points, I don’t think it will make it to mainstream. But we should try and consider different approaches.

  1.  

  2. 15

    This was true back when I was a Ruby programmer. It’s true now. I don’t know that exhortations to do better at software are going to change much for folks.

    1. 9

      Also sort of-not-quite-but-basically ex-Rubyist chiming in. Same. A bunch of us tried for a few years, you couldn’t go to a conference without hearing some talk on how your architecture was bad. Hasn’t seemed to change much…

      1. 3

        another mostly-ex-rubyist chiming in - the talks on how everyone’s architecture was bad were inspiring and all, but how many people started projects to do it right? say what you will about rails’s muddling of concerns, but there was a large community contributing code to it. there was (is?) essentially no leadership or community around the attempt to demonstrate a lot of one-thing-well libraries integrated nicely into a cohesive whole, even though the libraries themselves certainly existed.

        1. 13

          Well, there was an interesting bit of coevolution there.

          Rails’s quick time-to-market made it a really great fit for consultants, who appreciated that the integration was already done and weren’t really ever paid to care about how a codebase aged with time. So they started using it, and it began to sprout even more tightly-coupled features which made it amazing to get off the ground with but hampered its ability to remain tractable as the codebase aged and increased in size and complexity.

          I remember being at a RailsConf where the new feature everyone was excited about were the project generators, which would allow you to build project templates so you could pre-integrate all your favorite libraries and then just bang out a bunch of cookie-cutter projects for each gig you were working. At the time I was trying to figure out what to do with a three-year-old Rails codebase and hadn’t created a new Rails project in about three years. I realized I was surrounded with smart, focused people who had totally different jobs, and that I needed to find some tools which were better equipped to solve the problems I had.

          1. 3

            For as much as I agree with the comment above, it’s fascinating to me that the benevolent dictator* of Rails is a company supporting a single product with an 11 year old code base. My sense is just slightly more subtle: Rails has a great out of the box experience, and works well for Basecamp’s long-lived code base, but not as well for other people’s long-lived code bases.

            It would be interesting to know if this contributed to Basecamp’s decision to sell the rest of 37 Signals, though!

            * At least one member of the “Rails core team” didn’t know about Action Cable until David’s RailsConf keynote. So I think it’s fair to say David / Basecamp are driving, even though the “core team” is larger.

            1. 1

              Basecamp (né 37signals) shifted from being a web design/app consultancy to being more of a product company around the same time they open-sourced Rails. As far as Rails Core goes, 7 of them are currently working for consultancies (Koz, José, Santiago, Xavier, Rafael, Andrew, Godfrey), and 6 are working for product companies (DHH, Jeremy, Aaron, Guillermo, Carlos, Yves).

          2. 4

            Oh totally, agreed.

            1. 3

              I guess this is to @zem, @steveklabnik, and @codahale: could you point to examples of folks succeeding at leading/demonstrating how to improve the everyday practice of a language? I’m asking because I’m taking a run at this in Ruby (griping at my coworkers is just no longer enough) and it’d be nice to have folks to learn from.

              1. 3

                i’m a fan of what jane street has done in their “core” library (an alternative stdlib for ocaml). there has been a lot of thought put into consistency and coherence, complete with blog posts outlining some of their thinking and experiences. recently, they’ve been working on pulling out a minimal core_kernel that can be used in other runtimes like javascript where all of core is not available.

                even more inspiring is what the openmirage people are doing - indeed, that was the first project i thought about when reading the original post. they are pushing hard on the “everything is a library” model, and contributing to the general ocaml ecosystem in the process.

                another thing worth looking at is the elm mailing list - the language, while perfectly usable, is still in the going-through-changes stage, and the community is thinking hard about best practices, design patterns, where it makes sense to follow existing languages and where they should break with historical artefacts and go their own way, etc. it reminds me a bit of the early days of the ruby community, where things like finding a good name for something were considered of prime importance (because, after all, names are part of the public user interface of a language or library, and hard to change once they get established).

          3. 5

            I agree, exhortations won’t help.

            This article popped into my head as soon as I started reading. It feels to me like any language with prolific meta-programming falls into the same traps.. and Ruby is only the latest victim.

            1. [Comment removed by author]

              1. 3

                I’ll agree as far as finding the first far simpler and writing all of my tests in MiniTest. I have no idea why the RSpec DSL there is so prevalent despite being so hard to understand what’s going on.

                I mean, it reads like English, sure. But all of the methods for how to do things are completely different from standard Ruby. It’s like you have to memorize a whole different language to really understand the details and write new tests in it. What’s so wrong with a simple assert method?

                1. 2

                  My favorite by far is

                  10.hours
                  

                  This is monkey patching the core Number class just to match English measure word order. It’s like lighting a campfire through a careful application of a tank because you just so happened to already be driving one.

                  1. [Comment removed by author]

                    1. 1

                      Oh god, what library monkey patches forty_two in?

                        1. 1

                          I never even knew that was there. I’m at a loss for words.

                          Oh, and it was added to spite Reddit? That’s not even just poor design but straight childish.

                          It’s not even called forty_second?

                          1. 5

                            It was not added to spite Reddit, it was left in to spite reddit. Long ago, these accessors were there from everything from 1 - 100. A ton of people complained, so only one to five was kept in, and also, forty_two.

                              1. 1

                                Oh wow. Always strange when you find out that the way you imagined things was just … wrong. :(

                                Thanks for digging that up.

                                1. 1

                                  s/imagined/remembered/, sigh

                    2. 1

                      This could be implemented as a decorator pretty easily

                      1. 2

                        Or… a function. Static method on TimePeriod if you must.

                  2. 3

                    I’ve been using Common Lisp quite a bit lately, and I don’t really agree with the article you linked.

                    It could just be my experience, but from what I’ve seen, a lot of Lisp coders treat advanced macro programming like magic. It’s one of those things you “can” do, but rarely “should,” precisely because it’s so easy to misuse and potentially difficult to understand. There are some popular libraries (like Iterate) that use macros to do far out stuff, but most people write macros themselves pretty infrequently. Even Paul Graham, in “On Lisp” suggests writing macros, “when nothing else will do,” like when conditional evaluation is required.

                    On the other hand, my experience with Ruby was that everybody wanted to do meta-programming everywhere because it was the hot new thing and made Ruby like Lisp, and made you look smart and clever. The more a person could abuse meta-programming to twist the language, the better.

                    For example, here’s a Ruby tutorial explaining how to use method_missing to auto-generate methods that match a regular expression, and at the end: “we’ve created an extremely expressive and beautiful API that is DRY and easy to maintain.”

                    1. 4

                      Ruby seems like a faster / more extreme version of it maybe, but the pattern of meta-programming everywhere becoming harmful predates Ruby.

                      I have only worked on two major lisp projects. One become so impossible to reason about it was thrown away and rewritten in C. The second remained in lisp – but a strictly procedural version of it, all cleverness was banned and scanned for at the commit level with thousands of lines of Perl… which just made it sort of a “meh” language.

                      I have worked on two other meta-programming heavy projects, one built MOP/Groovy – which I just heard the rewrite to Go was completed in the last few months… and one written in Elixir which is still alive and well – but very young… so, my faith in “good” meta-programming based on personal experience is limited.

                      The failure always seem to follow the same pattern – initial team is awesome, everyone knows what to do, is reasonable and does amazing… they start to grow / ramp up / are successful! Now they need people, and they need to train and teach and document and they realize all the embedded undocumented knowledge using the system entails, how much of their personal preferences and how they think the language should work is baked in, and how horrible it is to bring new people on-board. This limps along for awhile until it is decided that just switching is easier than continuously paying the human integration cost.

                2. 11

                  This same message is also said in a very funny and powerful way by Rich Hickey - founder of Clojure - in his RailsConf keynote speech here: https://www.youtube.com/watch?v=rI8tNMsozo0

                  A great point is the distinction between simple, complex, easy, and hard. The Rails community, especially, is so focused on making things easy for the developer, but that’s often making the software very complex.

                  Best example:

                  gem install hairball

                  Brilliant talk. Very worth watching if you haven’t. Changed the way I think about all this.

                  1. [Comment removed by author]

                    1. 3

                      This is why it’s easier to simply leave altogether.

                    2. 6

                      This reflects my experience in much of the Ruby and Rails world. These days, the only Ruby work I take on is greenfield JRuby with minimal dependencies. It’s the only way I can keep things sane.

                      1. 3

                        Interesting. Could you share what kind of work is this? What’s the problem domain?

                        1. 1

                          Do you use Ruby gems at all or maybe you take advantage of Java interoperability with Ruby as a nicer Java?