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 about 5 years ago; latest suggestion about 5 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.
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!
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?
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?
All good points, and I appreciate the clarification in the proposal. I now have a better idea of what this talk will be about. :-)
What if the language itself made a distinction between functions on immutable values and methods on mutable objects?
What if all methods returned
selfby default (Smalltalk)? What if there were a
voidreturn 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". ;)
I’ve imagined a bit harder and guessed that it might be to do with “tell, don’t ask” — perhaps if all methods returned
nilby 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!)
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!