[steveklabnik]

To add some quick answers in my experience:

1. It's a general attitude toward building interfaces; the reader of the code is put first. Yeah underneath things may be messy, but using those things should be nice. The onus is placed on the implementor, rather than the user. Ruby libraries will go to fairly extreme lengths to make things nice to use.

2. Matz has always said that he meant the path of least surprise to him, not to every programmer. I personally find this point the weakest.

3. Yes, stuff like rubocop can help teach you this, but you really pick it up from reading and writing others' code.

4. Ruby has had a test-focused bent for a long time; and so it has a lot of tools for testing. Back when I taught Ruby professionally, I even had an organization with a Perl webapp want me to teach their testers Ruby, to write test suites for the app in Ruby rather than Perl. Perl also has great testing, so I'm not sure I agreed with them in this case, but it is something many people feel.

5. I've seen many unmaintainable Ruby apps as well; I think this is something that should be aspired to overall, not necessarily something that's true today. Or rather, there's a period of development where people get enthused with a language, write tons of unmantainable code, step back, figure out why, and then the next iteration is better. Justin points out that node, being earlier in its life, might be in step 2, and that Ruby, being more mature, is on step 4 or 5 here.

[antod]

> 1. It's a general attitude toward building interfaces; the reader of the code is put first. Yeah underneath things may be messy, but using those things should be nice. The onus is placed on the implementor, rather than the user. Ruby libraries will go to fairly extreme lengths to make things nice to use.

I struggle with this a little as newish ruby coder (but not new to coding). The efforts to make a 'nice' interface can interfere with keeping underlying implementations elegant/simple.

Too much focus on the happiness of a dev cranking out new code at the expense of the happiness of developers coming along afterwards trying to understand it.

Ruby is fun to create stuff with, but I kinda prefer the Python culture that tries to drum into devs the importance of readability and explicitness for other developers. As a dev you do far more poring over others code than creating brand new stuff.

[christophilus]

Explicitness. << This is key. Ruby/Rails just feels really implicit and magical for someone who spent the first 15 years of his career in C++, C#, and JavaScript. (I've only been doing Rails professionally for a year, though, so maybe my opinion will change with more experience.)

[quesera]

That's mostly an effect of Rails. "Convention over configuration" was one of the early mantras, and usually it serves well for such a large API...but sometimes it's just magic.

Ruby itself is a fairly explicit and consistent language. Some of the syntax might seem surprising at first if you haven't bought into the "everything is an object (really)" perspective.

[matt_kantor]

Chef is pretty magical as well. I think it's easy to get carried away with syntax-sugary DSLs at the expense of of straightforwardness in Ruby if you aren't disciplined about simplicity.