Noel Rappin Writes Here

So, after writing two articles basically assuming what Ruby’s influence are, it occurred to me to check the About Ruby page on the official Ruby site. It says this: Ruby is a language of careful balance. Its creator, Yukihiro “Matz” Matsumoto, blended parts of his favorite languages (Perl, Smalltalk, Eiffel, Ada, and Lisp) to form a new language that balanced functional programming with imperative programming. We’ve already talked about Perl and Smalltalk.

Last time, we talked about Perl as an influence on Ruby, this time, we’ll talk about the other major influence on Ruby: Smalltalk. Smalltalk had a different kind of influence, since almost nothing of Smalltalk’s syntax made into Ruby. But many of the details of how objects work are directly inspired by Smalltalk, including the idea that every piece of data is part of the object system. Also unlike Perl, I spent a good couple of years working in Smalltalk, and it is one of my favorite languages that I’ll never likely use in anger again.

Ruby takes a large part of its inspiration from two older languages: Perl for general syntax and design philosophy Smalltalk for Object-Oriented structure I’ve been in kind of a writers block, for all kinds of reasons, personal and professional. I started to think about an article that I could write that would get my fingers typing, and drifted into what I could do for another “Better Know A Ruby Thing”, started thinking about String literals, wondered how I would answer the question of why Ruby has so many ways to write String literals.

As developers, we tend to think that our best practices are universal laws that we’ve discovered and which get refined over time. That’s true to an extent, but I think we underrate the ways our environment and technology shape what a best practice even is or what the best way to use a developers time might be. Looking at the past can help us calibrate what is and is not part of our environment.

Every time I think the AI frenzy has peaked, it peaks again. Writing about coding these days feels like Jimmy Stewart dancing on the edge of a floor that’s rapidly receding under him. I had a draft of this that started with five or six capsule stories of interactions with LLMs for coding purposes, some saving incremental time, some being wrong, some even being right. Then I realized that I probably shouldn’t be that detailed about work stuff, but more importantly, you likely have all these stories too.

So, this is wildly late. So late that it mocks the very concept of an end-of-year recap. And honestly, if I didn’t like going back to these things and re-reading them, I probably wouldn’t have finished it. Couple of quick notes before getting to it: The new thing this year is that I used The StoryGraph to rate all the books right after I finished them. You’d think that’d make it easier to get this list out, but apparently not.

Notes and Corrections Before we get fully started here, a couple of notes on Better Know Singleton Classes, which, among other things, got mentioned on Hacker News, giving me comments there for the first time in years, maybe for the first time ever. One Hacker News comment suggested that “Eigenclass” was coined by _why the lucky stiff as a joke and was then adopted by the community. I looked this up and that doesn’t seem to be the case… _why’s Poignant Guide To Ruby uses “metaclass” when it discusses this feature (at least the version I have does…).

It is time to Better Know what is perhaps the Ruby-iest of Ruby things, a feature that didn’t even have an official name for several years, despite being critical to Ruby’s Object-Oriented semantics. (It only just now occurs to me that there was no official name in English, I wonder what the Japanese name for it was…). Yes, it’s the singleton class. Which isn’t really a singleton. Or really a class.

Last time, I talked about ways to use dynamic typing to manage objects and business logic in your code. Doing so involves leaning into the object system, going beyond just “one class for each noun” and creating objects to model different states within the business logic directly. In a basic Object-Oriented design, you might have an object called User. This object, by itself, represents the entire concept of a user within the system.

How To Not Use Static Typing In Ruby Last time, I took a short example and examined in some detail what you would gain by adding static typing to it and what it would cost to use static typing. What I didn’t do was explain how I might handle the problem without static typing. For reference, Here’s the example again. Consider this to be part of a larger system and don’t worry too much about the rest of the world: