Hacker News new | ask | show | jobs
by trebbble 1409 days ago
It's chiefly difficulty reading & navigating the code due to all the magic (made even worse by dynamic typing), plus reliance on extensive, comprehensive tests to maintain any amount of confidence it's doing what it's supposed to, or even to figure out what it's supposed to be doing. Not that tests aren't handy just about everywhere, but it's a matter of degree of reliance on them and how bad a time you'll have if the test suite's absent, or stale & neglected.
1 comments

I'm sorry you had a bad time with Rails but I don't find this to be a fair assessment. I've done Rails development for about 15 years and worked on over a dozen production codebases.

> "all the magic"

The "magic" factor in RoR is much less than, say, iOS development in XCode. And RoR has the benefit of being text-based, so whatever functionality you're looking for, you can be sure it's in a text file somewhere.

> made even worse by dynamic typing

This is a feature Ruby shares with the #1 and #2 most used programming languages.

> how bad a time you'll have if the test suite's absent, or stale & neglected

I agree that having no tests or bad tests guarantees a bad time, but I'd say it's pretty standard for even the bad codebases to be covered pretty consistently with unit tests. The Rails community has, by and large, accepted unit tests as part of our shared culture, so if your developers adhere to Rails convention, they will maintain decent test overage. That's a strength of RoR, not a weakness.

> The "magic" factor in RoR is much less than, say, iOS development in XCode. And RoR has the benefit of being text-based, so whatever functionality you're looking for, you can be sure it's in a text file somewhere.

Noooooo. A ton of things simply aren't defined until the program's running. "What even is this?" is frequently a question that's hard to answer without running the project (hope it's in a runnable state, then!)—even figuring out whether something's from Rails or from some other module (which one? Start googling or have fun poking at the Rails console against a running copy of the code until you figure it out) can be a pain. There's far less runtime metaprogramming magic in any other ecosystem I've worked in, which is lots and lots of them (including iOS). It's everywhere in Rails.

[EDIT] Also:

> The Rails community has, by and large, accepted unit tests as part of our shared culture, so if your developers adhere to Rails convention, they will maintain decent test overage. That's a strength of RoR, not a weakness.

Yes, tests are good! A culture of testing is good! But not every language/framework suffers so greatly from absent or bad tests as Rails does. Such heavy dependence on them is not a strength of Rails (though the culture of testing is).

> Start googling or have fun poking at the Rails console against a running copy of the code until you figure it out) can be a pain

Funny, none of those things sound bad to me, but just like part of the job :D Could be Stockholm Syndrome?

It's part of the job with Rails. In many other ecosystems your tools just tell you the answer immediately, or you can at least easily grep your way to an answer.