Good question. In a nutshell, the point is to distinguish between the public interface of a class (or module or whatever this code lives in) and its inner workings.

The purpose of this isn't really apparent when it's just in a kata, but imagine that this code was part of a larger application. When you make a method public, you're allowing other parts of the application to use it. Once they do, those other bits of code become dependent on this method still existing and working exactly the way it does. If you change the way it works, you might have to change any code that uses it as well. If this was part of a gem or a library that other people use, their code might be relying on it too, so you'd have to warn them that this method has changed.

By making the helper method private, you're saying that it's internal to this class, and other code shouldn't be using it directly. This means you can safely change it as much as you like (or even remove it), without breaking anything outside this class - as long as the public interface, decodeMorse, still does the same thing. Does that make sense?

I agree that, especially in a professional setting, cramming everything into one line isn't necessarily the most practical approach if many people will have to write code. Glad you brought this up!

An additional question for you: I'm new to Ruby-- what's the point of making your helper method decodeWord private? Thanks!

We obviously think alike because I literally came up with the exact same solution. I would consider this more elegant than a one-line solution for the sake of both readability and future maintainability.

This will work without the .join - we might as well compare two arrays as two strings. Or is it more conceptually pure/better practice to return a string?