DEV Community

Getting Cozy with Ruby

Ben Lovy on March 07, 2020

When I first approached Ruby, I basically looked at it like "dynamic C++", because that was the best analogue I had. Of course, that has required ...

Read full post

Scott Tadman • Mar 7 '20

That's a fun blitz tour of Ruby but you missed out on the big one, the "raison d'être" of Ruby, Enumerable.

One of the things that Ruby lends itself to quite naturally is transforming data from one form to another incrementally using little shifts, twists, and nudges. Like if you want to convert a string like "can_have_class" into "CanHaveClass", like the Rails String#camelcase method, you can do it with:

str.to_s.split(/_/).map do |s|
  s[0,1] = s[0,1].upcase
  s
end.join

Where that splits the string apart at the underscores, converts each of those bits with map into a capitalized version of itself, then combines them back into a single string with join.

While this doesn't seem all that complex, it avoids a lot of the mess you get in other languages where you'd need to explicitly declare an array, use a for loop over the correct range, and remember to return the array when you're done.

If you compare Ruby to other languages superficially it has a lot in common, but Enumerable is a very interesting and unique feature. JavaScript has things like Lodash which try to emulate it, but only cover a fraction of the functions Ruby has and the syntax is way more clunky and awkward due to language limitations.

The only reason I mention this is because when approaching Ruby for the first time that's the philosophy you need to understand first, and everything else can flow from there.

Ben Lovy • Mar 7 '20 • Edited

Very true, thanks so much for adding this! Blocks are indeed extremely natural and extremely common in all the code I read. It feels very much like using JavaScript or even a Lisp but wrapped up in a more class-based object-oriented structure. I think the strongest analogue I've used that's like that is ClojureScript - which is basically JS and lisp mashed together, so it stands to reason!

As side question, is this more or less what Scala feels like to use, just with types? Do some similar idioms arise via the functional<->OOP blending?

Scott Tadman • Mar 7 '20 • Edited

I haven't used Scala enough to comment on how it feels, but Ruby is able to straddle the intersection between procedural, object-oriented, and functional depending on how you use it.

This is increasingly true for a lot of languages, even Swift, Rust and Python, where functional approaches to problem solving have helped simplify things. Once you get lambdas it's inevitable that will happen. Maybe we'll even see more of that in C++.

Within Ruby there's a lot of push towards a more functional style as it's anticipated this will help resolve some of the major concurrency problems Ruby has. The Ruby core team seems to be opposed to threads as a general-purpose solution, instead steering towards approaches like Guilds, similar to how JavaScript has WebWorkers, but there's opportunities to parallelize things like map if you have clean, functional code to work with.

Here's hoping there's a concurrent version of things like map in future versions of Ruby!

rhymes • Mar 7 '20

This is increasingly true for a lot of languages, even Swift, Rust and Python, where functional approaches to problem solving have helped simplify things.

True that! My Python code is increasingly more functional and I think the natural namespace of file boundary in Python helps with that. Well, also having functions whereas Ruby has only methods. I don't use custom classes that much anymore in Python. Pass state between functions, inject dependencies, rinse, repeat.

It's also so much easier to test when you have side effects contained in a small amount of business logic.

Ben Lovy • Mar 7 '20

Rusts' Iterator trait definitely comes to mind, but I believe Ruby provides a greater set of methods, and I've definitely noticed a functional-forward trend in C++11 (and up).

I am not complaining :)

Scott Tadman • Mar 7 '20

If someone ported Enumerable to Rust and/or JavaScript in all of its glory that would be amazing.

Ben Halpern • Mar 7 '20

A big love or hate with Ruby are the methods that objects have like...

array = []
array.empty? # true

num = 1
num.zero? # false
num = 0
num.zero? # true

I find it funny when a linter wants me to use .zero? as its so highly specific and odd to me. .positive? seems a bit more natural to me along the same lines.

Rails provides .first, .second, etc. up to .fifth for arrays and collections. In a trolling fashion, it also has .forty_two, which returns the forty-second element.

(1..200).to_a.forty_two # 42

Scott Tadman • Mar 7 '20 • Edited

There used to be more of these whereupon there was debate, and ultimately a cull. #forty_two is an artifact of that, if you can call it, process.

Ben Lovy • Mar 7 '20

Hah! That really does come off like a "screw you yes we did this".

I'm a huge fan of the wide variety of messages you can pass, but it does seem like it will take a while to learn everything that's available. They seem to lead to very readable code.

drew • Mar 7 '20

Thanks for posting this. I recently started learning Ruby, been at it for about 3 weeks and loving it. I looked at the language before, kinda sorry I didn't try it sooner.

As a first language I'd probably recommend it because it just seems so easy. But then again, it might be better to try something harder like Java. That's what I wound up doing.

Scott Tadman • Mar 7 '20

Don’t confuse “easy to learn” with “not hard to use”. If you’re challenging yourself with hard problems the language, so long as it’s suited to the task, is rarely the hard part.

I’m doing some heavy Ruby Async work now and it is far from easy. It’s just nice that Ruby is pleasant to work with vs. battling the C++ compiler and undefined behaviour instead.