This version of Vestibule is read only. It represents an archive of the community effort to produce content for Ruby Manor 4.

Mistakes at the heart of Ruby

This proposal by <a href="/users/mortice">Tom Stuart</a> has been chosen by the community to be given at Ruby Manor 4.

updated over 4 years ago; latest suggestion over 4 years ago

This talk centres on three aspects of Ruby-the-language (as opposed to Ruby the programming culture) which I dislike, and which I think often set developers on a path to code which is more difficult to reason about and work with than it needs to be. These three aspects are:

  • Methods return the value of their last expression by default
  • Require runs stuff and mutates global state
  • Mutation of value types is baked into the language's philosophy

I'll explore the characteristics of these mistakes, comparing them to other languages such as Smalltalk, Clojure, Python and Java, and attempt to show that they establish patterns of thinking in developers which ultimately lead to Rails and other disasters.

I'll also present the counter argument: that none of these characteristics is actually the source of our problems, and that in fact we are in a mess for cultural reasons.

I won't attempt to argue that we're not in a mess.

Suggestions

  • C004d67820a114e24ccf6f2ddaf5b236 Richard Livsey suggests over 4 years ago

    Sounds great, I miss implicit return in other languages so I'd certainly be interested in the argument against.

    One of the downsides of implicit return is lazy API design, especially in predicate methods where a method returns an object which is truthy instead of an actual Bool as a side effect of the last expression. Ruby core is guilty of this quite a bit.

    A void return type would be handy, but I'd quite like optional typing throughout Ruby too!

  • Acd62030df551952268e84c8fff26a5b James Adam suggests over 4 years ago

    This is a really intriguing proposal. Please keep developing it!

    You say that these "mistakes" establish patterns of thinking that lead to bad software. Are you able to present the converse argument as well, i.e. to show how omitting these mistakes enable other languages to encourage better software?

  • E257c5fb15b33c01a4c9373ccb549c87 Tim Ruffles suggests over 4 years ago

    Sounds an interesting talk. Three questions:

    • is it going to be problem or solution oriented?
    • will you discuss concrete examples - eg how solutions to this would improve/avoid a specific part of "Rails and other disasters"?
    • could you explain how the first two are high level enough to be relevant to the parts of Rail's design I've heard criticised?
  • Be3698f145a80c1230fd667c87d0f0c8 Tom Stuart suggests over 4 years ago

    All good points, and I appreciate the clarification in the proposal. I now have a better idea of what this talk will be about. :-)

  • The proposal author responds over 4 years ago

    What if the language itself made a distinction between functions on immutable values and methods on mutable objects?

  • The proposal author responds over 4 years ago

    What if all methods returned self by default (Smalltalk)? What if there were a void return type (Java &c.)? Are these good ideas?

    I've updated the last 'mistake' (which is a ridiculously provocative label, of course) to read: "mutation of value types". ;)

  • Be3698f145a80c1230fd667c87d0f0c8 Tom Stuart suggests over 4 years ago

    I’ve imagined a bit harder and guessed that it might be to do with “tell, don’t ask” — perhaps if all methods returned nil by default, people would be less tempted to grab the (often incidental) return values and do stuff with them.

    But TDA is in tension with the functional approach: if you’re not getting a value back, you’re relying on a side effect. And fine, encapsulation of mutable state is the selling point of OO, but how do you reconcile that with the complaint that “mutation is baked into the language’s philosophy”?

    (None of this is intended as a complaint, of course. I am interested in hearing this talk!)

  • Be3698f145a80c1230fd667c87d0f0c8 Tom Stuart suggests over 4 years ago

    I can’t imagine how being expression-oriented could be considered a mistake rather than a massive simplifying advantage, but I guess I’m curious to hear the argument!