Topic 1
Topic 1
Ruby source files are converted directly from the English source tree.
Overview
I begin the course with a very small shift that turns out to matter a great deal: Ruby code is often built from expressions rather than ceremony. A method can say what it means directly, and a test can describe behavior before the implementation exists.
That may sound minor, but it changes how the code feels. If you are coming from Java, you are used to more visible scaffolding around even simple behavior. In Ruby, I want you to see how some of that scaffolding can disappear without the thinking becoming weaker.
What I Want You To Learn Here
By the end of this topic, I want you to be able to:
What You Need Before Starting
You only need a few basics:
If you do not come from Java, that is fine. The comparisons will still help, and the exercises are small enough to learn from directly.
What I Want You To Notice
The arithmetic in this topic is not the real point. I am using simple arithmetic because I do not want the domain to distract you from the design.
What I really want you to notice is this:
If the Ruby version ends up shorter than a Java version, that is useful. If it ends up shorter and clearer, that is the real win.
Short Note
One of the first things I want you to feel in Ruby is that methods return the last evaluated expression. That sounds like a small rule, but it changes the texture of the code.
In Java, even simple methods often carry visible scaffolding: type declarations, explicit returns, and a little extra structure around the real idea. Ruby lets a small method say the idea more directly.
def double ( n ) n * 2 end shortnote.md ruby I am not showing you that method because it is clever. I am showing it because it is direct. Ruby often reads best when the parts that are only ceremony fall away and the parts carrying meaning remain visible.
This topic is not really about arithmetic. I am using arithmetic to teach design discipline at a very small scale:
Ruby's strength in a topic like this is that a class can express one idea with very little boilerplate. The caution matters just as much: short code is not automatically good code. If the names are weak, Ruby's concision can hide confusion instead of removing it.
As you work through the exercises, keep one question in mind: what became clearer in the Ruby version, and what only became shorter?