Posts

Some People Say Ruby Is Too Complex for Beginners…

Is Ruby the right programming language for beginners?

One of the biggest criticisms I hear lobbed against learning Ruby as a beginner language is that Ruby has so many different ways of doing things. People say that these different ways of doing the same thing makes it hard for beginners to learn.

To be specific, here’s one example of this argument that I read on reddit recently in response to my earlier post, Why Beginners Should Learn Ruby on Rails:

“Ruby almost always has 100 ways of doing any problem, and frequently the user-submitted examples on Stack Overflow are meant to dazzle rather than instruct.”

or

“So much shorthand and so many options that when I’m trying to learn one particular function, I get 100 different users telling me to do the problem 100 different ways, none of which helps me understand the thing I’m trying to learn.”

This is true.

Ruby in particular has lots of instances where there are multiple, equally good (and sometimes not equally good), ways of solving the same problem. But rather than that being a weakness of Ruby, I actually think the flexibility of the language is an incredible strength, especially for beginners.

But rather than that being a weakness of Ruby, I actually think the flexibility of the language is an incredible strength, especially for beginners.”

You see, there’s no one way that you learn something, and whichever way sticks is usually the best for a beginner.

Here’s an example.

In Ruby, there’s the select method (in Ruby, functions are called “methods”), which lets you take a list of things and pull out a sub-set of that list.

It looks like this:

list_of_numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
list_of_numbers.select { |number| number.even? }

Even if you’ve never coded in Ruby in your life, read that second line and take a guess at what you’re going to get. That’s right, you’re going to get the sub-set of even numbers: [2, 4, 6, 8, 10]

There’s a second way to do the same thing. It’s called the find_all method.

So instead, you could write:

list_of_numbers.find_all { |number| number.even? }

What do you think you’ll get here?

Right! It’s exactly the same result as the select method.

So why does Ruby have at least two ways of doing exactly the same thing?

It’s because the people who created Ruby were inspired by a few other programming languages — Perl, Smalltalk, and Lisp are a few — and they borrowed the different names for doing things from those languages. Also, it happens to be really easy to write a method once in Ruby and just point other methods to it. That’s not as easy to do in other languages.

So why is this an advantage?

Well, because you don’t have to remember both of these ways of doing things! You just have to remember the one that works for you. I almost always use select.

Doesn’t this get confusing? Maybe, if you’re looking at lots of different people’s code. But by that point you’ve already learned that select and find_all are the same, and it’s not so hard to figure out. Language is a lot like this. There are many ways to say the same thing in English:

Language is a lot like this. There are many ways to say the same thing in English, which enables creativity.

I’m happy, I’m cheerful, I’m pleased, I’m delighted, I’m jolly, I’m beatific, I’m glad, … do I needto keep going?

The flexibility actually opens up creativity, which I think is one of the coolest parts about a language like Ruby. Meanwhile, in most other languages when there’s only one way of doing something, if you don’t remember that way then you’re screwed.

Another clear example that people like to hate on all the time: parentheses.

In Ruby, parenthesis are optional in methods. So are brackets { } a lot of the times, and you can basically use either single quotes or double quotes interchangeably.

Take that same list from before:

list_of_numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

What if you wanted to see if it included a particular number?

You could use the include? method:

list_of_numbers.include?(2)

But you could also leave out the parentheses in this case (and lots of Rubyists do) because it’s prettier and easier to read:

list_of_numbers.include? 2

Sure, there’s a few rules about this. You have to put a space beforehand instead of parenthesis (otherwise Ruby would think you were trying to run a method called include?2 which doesn’t exist).

The point is, you can try many different ways of getting at the same issue, and get an answer to your question in many ways. Rather than get stuck on needing to know the exact way to write something, you can solve your problem in more than one way.

The same is true for software applications, like AutoCAD. As a user, you can type into the command line, navigate towards a button, or use drop-down menus. In addition, you can choose to draw a line with at least eight different tools (line edit, polyline, arc, points, etc). One way isn’t better than the other — they’re just all different tools for drawing. Having many different ways to get shit done makes it easier for people to remember the technique that works best for them.

Flexibility! It’s a beautiful thing.

I’ve never understood why people thought that having multiple ways of doing something was a bad thing. When you’re first learning, you have to grasp and understand whatever concepts you can, as a starting point.

Meanwhile, a language like JavaScript is a truly hard language for beginners to learn, because there are so many specifics that don’t come naturally to a beginner, and you have to do them that way. I’m not saying you can’t learn it, but the amount of times I’ve heard beginners so frustrated they were ready to give up because they’ve forgotten a “;” somewhere and have no idea where.

If you’re interested in reading more about why Ruby is a great language for beginners, check out Why’s (Poignant) Guide to Ruby. It’s one of the most beautifully and interestingly written pieces about programming, and is one of the biggest reasons I fell in love with Ruby in the first place.

And then, if you want to learn more about Rails, watch our free one-minute video or check out our Rails course to go build your first app.

The Perfect Follow Up To One Month Rails

Why should someone who already took One Month Rails take One Month Ruby?

Well, for one, you know very little about Ruby so far. Sure, we did some basic stuff like if… then. And we created a few variables. But Ruby is a wonderful language, and your ability to get stuff done in Rails is only like 20% of what it could be. There’s so much more still that you could do that you don’t even know about!

Have you wanted to expand the functionality of your Rails app? Take the Ruby course. If you want to be able to get a job as a developer, you HAVE to get a better understanding of Ruby.

When I was first learning how to code, I built my first Rails app and then I hunkered down and learned as much Ruby as possible.

I went through Codecademy’s Ruby tutorial. I went through other resources like Ruby Koans and Ruby Warrior. My favorite were two books: one called Practical Object Oriented Design with Ruby by Sandi Metz and one called Why’s (Poignant) Guide to Ruby.

That was when I first fell in love with Ruby. It’s an incredible language. It’s really powerful, so much fun to use, and it’s got an amazing community.

If you enjoyed One Month Rails, you really should take One Month Ruby.

For years Rails students have been asking me to create a Ruby course because they feel like they wanted a deeper understanding of the language that Rails is based on. So that’s what I’ve done.

Why else should Rails developers learn Ruby? Well, obviously Rails is built in Ruby. If you took Rails, then you can do it. But, if you want to understand it, you had better learn Ruby.

That’s probably the biggest most obvious reason.

There are things you can do in Rails that you can only do if you know Ruby. For example, writing web scrapers and interacting with APIs. All of that is outside the bounds of what Rails is meant to cover, so you’ll have to know it if you want to do anything more advanced. If you want to automate stuff. If you want to be a better coder. This is the next step.

Ruby Tutorial: Map vs. Each

I like to think of programming as the process of taking a chunk of information, manipulating it and then returning a new version of that info. Let’s take Facebook for example. To create a profile page you enter in your information, Facebook then manipulates it by creating your profile, then returns a nicely formatted webpage that you can share with the world.

Today we are going to apply this concept to a smaller section of programming called iteration. Iteration for all purposes is the process of doing something over and over. In Ruby, iteration often occurs in the Array and Hash classes by looping through a list of items, manipulating them and then returning a new version of each item.

Luckily for us, Ruby does a lot of the heavy lifting by providing us with an each method and an Enumerable mixin.

The Ruby Docs tell us that “the Enumerable mixin provides collection classes with several traversal and searching methods, and with the ability to sort. The class must provide a method each, which yields successive members of the collection.”

So what does this mean exactly? Basically, if the class you want to iterate over provides an each method, you can mixin the Enumerable module giving you access to additional methods.

For our examples we will be using Ruby’s Array class. We will be building a pizza method that takes an array of toppings as an argument.

What we want our methods to do

  • Take in an array of pizza toppings.
  • Iterate through each topping, one at a time.
  • Manipulate that data (do something to it).
  • Return the manipulated data.

Each

The most important thing to remember about each is that it does not change the return value. It implicitly returns the original array.

This method will print:

But the return value is still:

If we want to change the return value, we have to explicitly tell it to do so.

In this version of our pizza method we set an empty array called my_statements, which we will then explicitly return after we finish our loop. Inside our each statement loop, we manipulate each topping by interpolating it inside a string. We then push that string into our my_statements array. After we iterate over each topping in our array, we return the new my_statements array.

Our new return value:

However, if we do want to change the return value, there is a handy method called map, also known as collect. These two methods are synonyms for each other and they implicitly return a new return value every time. Map and Collect are abstractions of our each method. An abstraction is the process of taking away or removing characteristics from something in order to reduce it to a set of essential characteristics. Let’s take a look at a few examples.

Map & Collect

This method will print:

This method will return:

Why nil?

If you look inside our map loop, you will see that we are using puts, which always has a nil return value. What this is telling us is that our return value is indeed being changed by map. Let’s look at another example.

Here we are no longer using puts, but instead implicitly returning what is inside our block. Again showing that map will give us a new return value based on the logic inside our block.

Our new return value:

Takeaway:

• If you want to change the return value use map.

• If you want to return the original return value use each.

It’s common to reach for each when dealing with arrays and hashes, but now that you have an understanding of map, you have another tool in your bag! Remember to be mindful of your return value. Knowing what you want to return will help you determine which method to use.