00:00:00.160
Good, although Australia... Um, how are you all doing? Did any of you get on the terps yesterday? So, uh, yeah, I'd say I'll drop the idioms, but there will be more.
00:00:10.880
This is my first time down here; I'm really, really happy about it. I'm really excited. I have actually, for years, been a massive fan of both Vegemite and Lucas' Papaw Ointment, so I think I can basically apply for citizenship now.
00:00:36.239
Okay, so this talk is about idioms and idiomatic Ruby. The protagonist of this story is the idiom. In English, when we're talking about natural language, "idiom" can mean two things: the smaller meaning and the bigger meaning. The first, smaller meaning, is a peculiar expression that is commonly understood; it's sort of a colloquial metaphor. The second meaning of "idiom" refers to the way of speaking or using language that is particular to a specific group of people.
00:01:10.000
I will talk a bit about the first meaning and give you some examples, but we're mostly going to focus on the second. An idiom in the first sense includes phrases like "spit the dummy" or "flat out like a lizard drinking." These are phrases that, even if you know every single word of them, may still not make sense. If you translate them literally to another language, they probably also won't make sense. However, people within that group will immediately understand you; that's an idiom.
00:01:31.200
Both of these meanings can also transfer to programming languages. In Ruby, when we refer to an idiom in this first sense, you can think of it as the tiniest form of design pattern. For example, a Ruby idiom could be a method that memoizes—implementing memoization. You could do this in various ways, but this is the most common idiomatic way: having a method that conditionally assigns to an instance variable with the same name. An experienced Rubyist at a glance knows that they don't need to go into the details; they can just see this and recognize it as memoization.
00:02:20.000
Similarly, if your method starts with "raise" followed by conditional checks, you immediately recognize them as precondition checks, which are not part of the core functionality of the method. They are little patterns that you recognize.
00:02:48.480
An idiom in the second sense is how a specific language is used by a specific group of people. For example, if you go to Brussels, the area of the European institutions, you might find that people speak a lot of English, but it’s very strange English. They use complicated words where easier ones would suffice, alongside words that you rarely hear in English or words that carry different meanings based on Romance languages.
00:03:03.920
This illustrates the variety of English that has developed within the European Parliament and institutions. Similarly, high school language among kids around the world can differ significantly from how the language is used by teachers or parents. This idiom can vary and change across different groups; for example, Aussie English differs from American English. It also changes over time—look at early English, Middle English, Modern English, and the same applies to Ruby.
00:04:13.680
In the Ruby community, we have different groups with their own idioms. Ruby Core has its own style of using the language compared to Rails. Rails Ruby has its own idioms that differ from those in the Seattle RB projects like MiniTest, Flog, and Flay, which are known for having a particular way of doing things.
00:04:51.200
Interestingly, there's a recent phenomenon with DataMapper and later, Ruby Object Mapper, which attracted people doing things in their own way—building their own tooling, developing their own metrics on code, and forming their own unique style.
00:05:08.240
Here's a quick example of how idioms vary: look at line one where you see no parentheses; arguments are implicitly understood. On line two and line four, there’s an explicit "then" that could have been omitted. If you look at this code, it's consistently written, possibly from Flog or Flay.
00:05:52.640
That's the first dimension of how idioms change, but they also evolve over time. I researched various Ruby code samples and found some interesting examples from around 2004 taken from the standard library. The first thing that pops out is the use of an actual "for" loop; some people might not even know Ruby has that. In modern Ruby, you could write that using `tap`. In older Rails Ruby, you might encounter explicitly returning `object.new { ... }`.
00:06:35.520
Moreover, looking at the example, you see it using a match operator on rejects rather than the matching operator on strings. On line six, it’s relevant to note that it uses the scoping operator to call a class method. We don’t commonly see that this way anymore. Thus, we could delineate Ruby into early, middle, and modern periods, with early Ruby from 1995 to 2005 being like primordial ooze. Ruby, as a new and niche language, had early adopters coming from various backgrounds, leading to a diversity of styles lacking a substantial body of work for guidance.
00:07:43.760
Come 2004-2005, Rails emerged, causing a boom in Ruby adoption. By 2005-2006, the majority of Rubyists were newbies, often relying on the Rails codebase. This led to a crystallization of common idioms around it. People were drawn to Ruby for its reputation as a programmer-friendly language, emphasizing happiness and flexibility. Fast forward five years, and these Rails apps became older and more mature; developers began seeking standardization and best practices.
00:09:03.680
During this time, a common style emerged, bolstered by projects like the Ruby Style Guide and the advent of RuboCop, which concretized this newfound idiomatic approach. In this modern era, while there's a substantial focus on standardization, there's also a faction interested in exploring Ruby beyond Rails, adopting novel approaches and developing their own idioms.
00:10:04.480
We've delved into idioms and their evolution, but why does it really matter? We prefer code to be idiomatic because it ensures that it conforms to a common standard, facilitating ease of understanding, minimizing cognitive load, and enhancing readability.
00:10:47.840
Idiomatic code leverages the features of the language, making it concise, performant, and clean. The consequence of this is greater consistency within a project. If all code reads as though written by a single person, it becomes manageable for others to navigate. In maintaining idiomatic code, we reduce cognitive overhead, which is critical for project coherence.
00:11:54.560
The question arises: who dictates these idiomatic rules? The Ruby Style Guide may reflect common practice, but there are well-known influencers whose styles have affected the conventions. When reviewing Ruby code from 2004-2005, you find remnants of outdated styles contrasting sharply with the Rails codebase, which remains modern and relevant.
00:12:24.560
Fascinatingly, the Ruby community is vocal about idiomatic practices. An analysis I conducted on GitHub revealed Ruby references idiomatic writing roughly twice as much as JavaScript and three times as much as Java, indicating our collective commitment to maintaining idiomatic integrity. However, a caveat exists.
00:13:37.920
This strict adherence to idioms presents challenges for newcomers. Many aspiring Rubyists struggle with codifying rules that are merely stylistic. As they learn, it’s essential not to overload them with these expectations, which could obscure the actual learning process.
00:14:27.600
In fact, when I checked the current repository on RuboCop, it contains 335 rules that encapsulate this rigor. Rigid adherence to idioms can stifle innovation as our language evolves. The programming landscape is shifting towards new paradigms, and as new languages with different approaches emerge, Ruby must adapt.
00:14:57.920
In recent years, ideas from distributed systems and concurrency models, particularly from languages like Go and Elixir, have begun to influence Ruby. Concepts like monads, functional composition, and transducers, which only a few years back seemed alien to the Ruby ecosystem, are now experimental territories for many Ruby developers.
00:15:42.080
In conclusion, idiom is fluid; it changes and will always evolve. Treat idiom as a flexible concept. Programming isn’t merely about machines—it’s a language and a form of expression. Like any art form, find your own voice and how you want to express yourself. If any of the RuboCop rules feel unnatural, feel free to disable them temporarily until you find what resonates with you. Just remember: idiomatic does not equate to quality. Just because code looks familiar doesn’t mean it’s good; conversely, unfamiliar code isn't inherently bad. Always consider what's happening beneath the surface of the code; seek where the value truly lies. Thank you very much.
