Spotlight: Noel Rappin (Author)

A Ruby-Centric Chat
with Noel Rappin


Once you start noodling around with Ruby you quickly figure out, as Noel Rappin did, that it offers fantastic flexibility with dynamic typing, metaprogramming, and reflection, among other features. What’s more, it’s fun. Ruby’s clean syntax and conciseness allow you to focus on solving problems rather than thinking about language intricacies. When you are coming from Java, that’s a refreshing change.

We sat down with Noel to talk about his journey from learning Basic as a young person to programming in Java professionally, and finally his move to Ruby.


We’re giving away one of Noel’s books to one lucky winner! Simply post a comment or a question in his ask me anything (AMA) below, and the Devtalk bot will randomly pick a winner at a time of the author’s choosing . . . then automatically update this thread with the results!

INTERVIEW (abridged)

Introducing Noel

Noel Rappin has been a PragProg author for years and has recently taken on updating the pickaxe book: Programming Ruby, now in its fifth edition. He’s also our Ruby and Rails Series Editor, helping The Pragmatic Bookshelf to shape the future of books about programming in Ruby.

Raised in the Apple II generation, he was naturally curious about computers, and took after-school programming classes at the Kohl Computer Loft in Chicago—what is now the Kohl Children’s museum. Experimenting at home in Basic and Turbo Pascal, he says: “I wrote myself a flashcard program for Spanish language vocabulary—not that it helped me very much in Spanish—but it helped me in programming.”

On becoming a Java programmer . . .

Noel has both an undergraduate and graduate degree in computer science. He was exposed to C as an undergrad, but in grad school experimented with “a variety of dynamic, weird, and fringy languages.”

We’re talking HyperCard, Macintosh Common Lisp, Smalltalk, and “this really cool language called Prograph, which was a visual language where the code looked like a flow chart. You would actually drag and drop stuff and draw lines between things to have things done.”

While those languages were interesting, none were commercially viable, and Noel wound up programming professionally in Java, doing “boring enterprise-y kind of stuff” and not loving the environment or tools, so was continually playing with other languages.

On moving to Ruby . . .

“There’s an aesthetic to Java libraries where many Java libraries are built to make the thing that you do 1 percent of the time easy while making the thing you do 95 percent of the time more complicated.”

“Ruby libraries are the exact opposite. Most Ruby libraries are designed to make the thing you do 95 percent of the time really easy and the thing you do 1 percent of the time really hard. Sometimes meaning that the thing you do 1 percent of the time is not a thing you should be doing with that tool.”

Noel had been following extreme programming and Ruby from the early days via Internet mailing lists, and when the original Pickaxe book came out, Noel bought it as a birthday present for himself.

His next job was full-time Ruby, and he never looked back—that was over fifteen years ago.

On learning Ruby . . .

When you come to Ruby from a strictly typed language like Java, dynamic typing can be surprising. You have to change your mindset to a more dynamic way of looking at your code and how it behaves.

There’s a learning curve—working with those dynamics and getting used to an environment where everything is an object. Even things like numbers and strings, which have special syntax even in other object-oriented languages, behave the same way as every other object.

Ruby feels like a language designed to be a fancier Perl that was then colonized by SmallTalk programmers. Noel’s early Smalltalk experiences helped him learn Ruby because of their similarities. They’re both late-binding languages that don’t evaluate whether the object can receive the message being passed until it’s actually being evaluated.

“I love Smalltalk. For a long time, I would generally, at every new job, wind up giving a twenty-five-minute demo of how great Squeak Smalltalk or later Pharo Smalltalk were. Even just a couple of weeks ago, I was looking at Kent Beck’s Smalltalk Best Practice Patterns as a guide to how to do Ruby better, because even as a Smalltalk book it’s one of the best Ruby books around.”

On programmer happiness . . .

“Ruby has, from its very beginning, this sense of programmer-facing aesthetics being very important.” Take RSpec—it’s a testing library that allows you to write tests that read like native language.

Ruby’s standard library is at heart "batteries included.” String has two hundred plus methods for basic and not-basic string manipulation. Code you don’t have to write—and that philosophy extends to other libraries.

Similar tools in the Ruby community take seriously the idea of making the programmer interface easy. In fact, Yukihiro Matsumoto, Ruby’s creator, talks about Ruby being optimized for programmer happiness.

On correctness . . .

“The first Ruby community event I ever attended, Dave Thomas started off with a talk about Ruby metaprogramming, and he addressed this very issue and described it as more of a people problem than a technology problem.”

“There are technological solutions to this problem; one which Ruby developers use a lot is that they tend to be very aggressive about writing tests, because automated tests fill some of the purpose that static typing might have in another language.”

Ruby has some idiomatic style guidance that makes you aware of when you are doing something potentially dangerous and compels you to be mindful.

“I think that one of the things that the Programming Ruby book does historically very well, from Dave’s and Andy and Chad’s original text, is explain that a lot of the things that you think are going to go wrong when you leave behind a static typing language to come to Ruby just sort of don’t happen, because Ruby methods tend to be small, so it tends to be fairly easy to see the behavior of an individual object inside a method.”

Working with Ruby you come to realize the benefit of “not strictness,” and the cost of strictness.

People have built some pretty big programs using Ruby on Rails. Even without strong typing, these programs keep working. It’s a combination of tests, naming conventions, and structure that mean errors are difficult to make and even more difficult to persist. Often when you make an error, it’s very loud and you catch it very quickly. It’s not as scary as you might think coming from a strongly typed language to move to a dynamically typed language.

On programming features (friend or foe) . . .

We asked Noel to comment on some programming features and classify them as “friend or foe.”


“Hmmm. In between.”

“A singleton is an object-oriented term for a class that only has one instance, one (usually) globally available instance. They are helpful in some cases where you work with a genuinely global state. They are problematic in other instances because weird global state can make things hard to replicate.”

“Ruby has an internal module that will let you convert any class into a singleton. It’s useful sometimes. In cases where you legitimately want only one of something in your system it can be overused. I don’t think it’s tremendously overused in a Ruby context.”



“Reflection internally is the programming language’s ability to understand its own structures. It’s best friend. It’s core to Ruby to be able to have a class be able to reflect on what methods it has and what methods it doesn’t have. Or what instance variables have already been declared for it or haven’t been. Anything like that, or what classes even exist or don’t exist.”

“Ruby has all kinds of very useful mechanisms that depend on its ability to reflect at runtime on the structure of the program.”


“I feel like I’m playing Jeopardy. A mix-in is a specific kind of module that is used to add functionality to an existing class. This is more also on the best friend line.”

“Mix-ins are a very core piece of Ruby implementation. It’s a way that Ruby sort of gets around not having multiple inheritance by allowing for an arbitrary number of mix-ins to be added into a class.”

“It is something that is a little bit more useful from libraries than it is in somebody’s application code, often. Ruby has a lot of third-party libraries that propagate themselves by providing mix-ins that you mix into your classes to get certain kinds of behavior.”

On the fifth edition of Programming Ruby . . .

“One of the goals of the original book that I’ve tried to keep up was to make it accessible to Ruby developers at a variety of different levels. If you are an entry-level developer Programming Ruby is great for you because it has a tutorial of how Ruby works and what the main constructs are and how they interact.”

“If you are an intermediate Ruby developer, you have all that plus a curated list of what the best API tools are. As you get more advanced, you’ll find a complete description of the language syntax.”

The pickaxe book covers new features in the language and in the library, but also addresses the population of new developers reading this book who have different reference points.

We take advantage of nine more years of Ruby experience, in terms of what people find hard or easy and what they use or don’t use. For example, developers are more likely to have JavaScript and Python experience than Perl or Java. “We wanted to use that a little bit to inform how we make some of the explanations in the book and how we compare certain Ruby features.”

We also added an appendix of symbols whose names are not obvious with what they’re often called. You get a quick definition and a word that goes along with them. For example, Ruby calls the equal sign followed by a greater than a “hash rocket,” or we talk about the “spaceship operator.”

Overall, there is something in the pickaxe book for every Ruby programmer.

The pickaxe book, named for the tool on the cover, is the definitive Ruby reference—a highly-regarded, fully object-oriented programming language. The fifth edition is a comprehensive reference on the language itself, with a tutorial on the most important features of Ruby—including pattern matching and Ractors—and describes the language through Ruby 3.3.

Now that you know his story, complete your collection of Noel’s PragProg titles today! Don’t forget to use coupon code to save 35 percent on one of Noel’s ebooks:

Follow Noel:




Linkedin, noelrappin


We’re now opening up the thread for your questions! Ask Noel anything! Please keep it clean and don’t forget by participating you automatically enter the competition to win one of Noel’s ebooks!


Hi, you mentioned “Yukihiro Matsumoto, Ruby’s creator, talks about Ruby being optimized for programmer happiness.” Where does he say that?

Have a nice day

1 Like

I’m not sure where Matsumoto’s original quote is, but this source also references that it was part of the origins of Ruby: Ruby on Rails — The Rails Doctrine

1 Like


What is the biggest challenge to upgrade the book Programming Ruby from Ruby version 2 to the latest one?

1 Like


What do you consider the most important changes in Ruby 3.3?

And a second question: What is on your wishlist for Ruby 4?


In the book “The Ruby Programming Language” in the introduction there is the following paragraph:

Matz’s guiding philosophy for the design of Ruby is summarized in an oft-quoted remark of his: Ruby is designed to make programmers happy.

Taking into consideration that that book is written by David Flanagan and Yukihiro Matsumoto himself we can consider that as a confirmation of Matz saying that quote.

1 Like


Do you think there is ever going to be a serious place at the table for Ruby in Machine Learning?

And second, do you have any plans to use Elixir in place of Ruby any time soon?

1 Like

@noelrappin Has your approach to testing evolved since Rails 5 Test Prescriptions?

1 Like

It’s surprisingly hard to find the original quote, but he mentions programmer happiness a lot, here’s one…

1 Like

The biggest challenges for me were not so much changes to the language itself, those are pretty well documented, but

  1. Changes in the ecosystem, making sure we added all the widely used tools (like Bundler) that have come about since the last version of the book.

  2. Handling the change in what other languages developers coming to Ruby might have seen before (JavaScript, for example)

1 Like

Long term, the most important change to Ruby 3.3 is likely to be the addition of Prism as an optional parser. Otherwise, there are very few front-facing changes in Ruby 3.3. The continued performance improvements in YJIT are quite welcome.

Ruby 4… I don’t really have a wishlist. I guess if I had a syntax wish list, it’d be the ability to specify an instance variable in the parameter list of a method: def initialize(@first_name, @last_name).


Machine Learning… it’s hard to say. There are people in the Ruby community that are working on these tools, but Python is very entrenched in that area (and in the science and data community in general), I think there’d have to be a really solid tool built.

I don’t have any plans to use Elixir right now, no.

1 Like

Yes and no?

My approach to testing in my own code hasn’t changed much (I just released a gem that I basically wrote test-first)

What has changed is how I see testing fitting into a larger ecosystem. I’ve become very aware of how fragile TDD is as an approach, and how tool choices can make it very hard, and also that fast tests are dependent on everybody on a team making good design choices, pretty much all the time and its hard to recover from bad choices. It has been frustrating to see the community as a whole move away from test-first, but at the same time, I don’t think that the testing community has really addressed how to make TDD as a practice more resilient.