Here's to the weird ones — The Art & Science of Ruby

Many years ago I remember seeing an interview with Linus Torvalds, where he said “… and that change is to keep the weird folks, like the rubyists, happy”.

I loved that.

The rest of the software development world thinks we’re odd. And not just because some key figures in the ruby world have taken a trip down nazi lane.

&&

I’ve been rewriting my “plumbing” gem. It was originally “unix pipes for ruby data structures” but it’s turned into more of a set of concurrency primitives and utilities for organising your application actors, observables, locators and operations.

As I started on the rewrite, I had a long conversation with one of my clankers and it did most of the work. I didn’t read the code it was generating - instead I kept an eye on the test suite and asked it to keep the documentation up to date. From the rspec and the docs, I could see the gem was taking the shape I wanted.

Then I came to actually use the code - and discovered there were whole areas of the API that I was not happy with.

Even without LLM code generation, this is normal. You can’t really tell whether an API is any good until you actually use it. And as I was using it, I discovered lots of points of friction, where the API didn’t quite work. This was my own fault - I had started from the wrong place; the implementation, instead of starting from the user.

So I refactored and reworked the clanker-written code.

&&

My intention was to update the public API so it was easier to use. But, as I read and adjusted the ruby code, I just kept on refactoring. And kept on refactoring.

Until I had reorganised the internal folder structure, replaced nearly all of the LLM-generated code and rewritten everything - but this time in my own style.

Why?

Did the LLM produce sub-standard code? No. It was decent code that did exactly what I had requested.

Was the test suite not comprehensive? It was. The clanker even covered edge cases and conditions I would have missed had I done it myself.

Did it fail to lint and format the files correctlyI like standardrb. It’s opinionated, meaning I don’t have decisions to make and rules to write. And I agree with the majority of its decisions? No. Technically it had done everything correctly.

But … the way the code sat in my editor was wrong .

Some of the internal implementation names and modules sounded odd. The split of how classes were organised into modules felt weird. Some of the methods looked ugly.

I just didn’t like it.

&&

As I said, Rubyists are weird. Most software developers think hard about what they want to do. They write the code, making sure the tests coverage is good and everything works as expected. They lint and format the source files so they meet their organisation’s coding standards.

And that is good enough.

But Rubyists want more.

Look back at how I described the LLM generated code (which was, remember, functionally correct).

The names sounded wrong.

The modules felt weird.

The methods looked ugly.

Rubyists care about the emotions of our code.

We agonise over whether to use a leading or trailing if - even though they are functionally equivalent

We worry about whether a parameter should be named or positional - even though that, too, is functionally equivalent

We stress over methods with block parameters - does the do keyword read correctly with the given method nameafter(10) do ... end vs wait(10) do ... end vs wait_for(10).then do ... end?

We refactor to ensure that the patterns of indentation stay aesthetically pleasing - does the code sway in and out from the left hand edge of the window correctly?

This stuff matters to us in a way that it doesn’t matter to other developers.

Rubyists are weird.

We’re emotional and we care about stuff no one else cares about.

It’s why I love ruby and I wouldn’t have it any other way.