Ruby Video
RubyConf AU 2016
Burn Your Idiomatic Ruby
Arne Brasseur
@plexus
#code-quality
#ruby-community
#best-practices
#developer-experience
Summarized using AI

Burn Your Idiomatic Ruby

by Arne Brasseur

In this talk, titled "Burn Your Idiomatic Ruby" at RubyConf AU 2016, Arne Brasseur explores the concept of idioms in the Ruby programming language, focusing on their significance, evolution, and the potential pitfalls of adhering too rigidly to idiomatic practices.

Main Topic

The discussion revolves around idiomatic Ruby, which refers to the conventions and patterns that define how Ruby should be used by its community, emphasizing readability and elegance in code.

Key Points Discussed

  • Definitions of Idioms: The speaker distinguishes between two meanings of idioms:

    • The first meaning involves colloquial expressions that are unique to a language group.
    • The second meaning pertains to patterns and conventions specific to programming languages, particularly Ruby.

  • Examples of Ruby Idioms: Brasseur provides examples of Ruby idioms, highlighting how experienced Ruby developers recognize common patterns such as memoization and precondition checks.

  • Variability and Evolution of Idioms: The presentation discusses how idioms can vary across different Ruby communities (e.g., Ruby Core vs. Rails) and evolve over time, shaped by historical contexts and community practices.

  • Historical Context: Brasseur differentiates between early, middle, and modern Ruby periods, highlighting the influence of the Rails framework on popularizing certain idioms and encouraging code consistency.

  • Importance of Idiomatic Code: The speaker emphasizes that idiomatic code increases readability, reduces cognitive load, and promotes project coherence, thus making collaboration easier among developers.

  • Influence on Idiomatic Practices: He notes that while the Ruby Style Guide offers a set of common practices, there are influential figures in the community shaping idiomatic rules.

  • Challenges for Novice Developers: Brasseur warns that strict adherence to idiomatic rules may hinder innovation, particularly for new Rubyists who may interpret these as mandatory rather than stylistic guidelines.

  • Evolving Programming Landscape: The discussion touches upon new paradigms and the influence of languages like Go and Elixir on Ruby, suggesting that as programming evolves, so must the idioms of Ruby.

Conclusions and Takeaways

  • Idioms are not static; they are fluid and subject to change as the language and its community evolve.
  • Developers are encouraged to express their own coding style while being mindful of idiomatic conventions, understanding that "idiomatic" does not necessarily mean "quality."
  • Brasseur advocates for a balance between following idioms and embracing creativity in coding, allowing developers to find their unique voice within the Ruby language.

The presentation encourages Rubyists to remain open to innovation, urging them to evaluate code beyond its surface-level idiomatic appearance and to seek depth and value in their coding practices.

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.
Edit
Explore all talks recorded at RubyConf AU 2016
+11