[ilrwbwrkhv]

I went on a long email back and forth with the author because this was the one book that opened my eyes so much that I did't know why the Ruby community (of which I was a part of then, but am no longer) would break so many of the principles of the book.

Maybe the only book that has actual made me a better programmer that I can objectively measure.

[acjacobson]

Would you mind clarifying which one you found so helpful? The parent commenter mentioned two books

[ilrwbwrkhv]

You sort of have to marinate yourself in the ideas of the book. But the big one is that you should have a very limited API. And each API function should do a lot of things. So a very narrow set of deep APIs make for the best programs. The other thing was indirection. Try avoiding it as much as possible. Languages which allow easy access to functions or lambdas or blocks being pass around, usually end up with 4 - 5 levels of function calls to get anything done. That makes things really complected together and makes it hard to reason about later.

[loco5niner]

and which book are you talking about?

[RoyalSloth]

Deep APIs were mentioned in "A Philosophy of Software Design" (John Ousterhout)

[hiAndrewQuinn]

A Philosophy of Software Design - John Ousterhout

[thehappyfellow]

Can you say more about how the ruby community is breaking these principles? Was that part of the reason you left the community?

[ilrwbwrkhv]

So around the TDD phase of Rails and Ruby, there was this huge push to make methods 5 lines or really short and dependency inject everything. It would make changes incredible hard to make because which the open closed principle talks about how things like this should be easy to change, you end up with a lot of subtle bugs because your individual dependencies drift from each other. I think the Ruby community has gotten much better now with more experience but ya that time it was crazy. And Ruby allows you to really take the metaprogramming and block passing madness to the next level.

I didn't leave the community because of it. I left it because Ruby was slow as molasses, dynamic typing is a failed experiment (imo) and people would love magic and be proud of it. Which meant systems would break in production more times than I could take and I have done so many on call rotations because someone thought some magic was a fun way of doing it.

For personal projects I used Steel Bank Common Lisp because there the dynamic nature of the language actually has benefits such as programming through the REPL which is much more reliable than typing dynamic code in an editor to build programs.

Once I had to hire people I moved to Go but then again moved to Rust because I want to write programs which do not break, is fast as possible and doesn't take my users' memory and cpu for granted. Who am I to burn their electric bill or data plan while delivering broken buggy software to them. Plus I cannot stand null pointer exceptions and Go due to their ideological drive of remaining "simple" has null pointer exceptions in 2024.

Also the other meta thing I realized was because Rust is harder to get into, the discourse, libraries, tutorials, community is much higher quality compared to anything else I have seen so far so I really enjoy it. Plus Rust has some really cool things like high level maps and functional code while them compiling down to the same Assembly as for loops and other such zero cost abstractions that I like.

[thehappyfellow]

Funny, I spent the last decade working in a strongly typed natively compiled language (OCaml) and for fun I’m venturing into Ruby more and more, so kinda opposite of what you did :)

I’d agree that I wouldn’t like to support a large Ruby codebase commercially but in team of 1-4 devs and codebase not much larger than 10k lines it’s very productive (numbers pulled from thin air ofc).