Hacker News Reader

Comment by lobster_johnson | Hacker News Reader

That's not really what convention refers to here. Rails' motto "convention over configuration" simply means that boilerplate should be avoided, and that code should use sensible defaults whenever there isn't information.

For example, ActiveRecord class names map to table names through a simple pluralizer (UserProfile -> user_profiles). That's a convention, no configuration needed. Just write a class and off you go. You can override this behaviour, but you can also write huge apps that just follow the convention. Other frameworks would typically make this mapping explicit.

You do need to read the documentation to see what the conventional behaviour is, but it's not very deep knowledge. It's not much worse than other frameworks, where you need to find how things are configured.

View on HN

My experience is that programmers migrating to Rails are thoroughly confused by these conventions like "UserProfile -> user_profiles". Although it's only the second-biggest source of confusion after ActiveSupport, e.g. "10.hours.ago" even though the integer class does not have an hours method according to the Ruby documentation.

Integers have methods? ಠ_ಠ

Yes, why not?

    42.times { puts "foo" }

    1.upto(9) { |n| puts n }

    puts 1.year + 7.months - 1.day

one of the issues I see with rails precisely is that most people won't ever know that 1.year is not a plain ruby method

Is there a problem? If they don't know, there's not much harm. But surely this is part of the learning process. Understanding leads to enlightenment. There's certainly evidence that tons of developers using JavaScript don't know how classes work.

I can call methods on objects in most frameworks/libraries. The fact that I don't know if .trim() is a core Javascript function or part of jQuery isn't a weakness of jQuery. If a "developer" can't be bothered to consult documentation when they work on a slightly different project than they're used to, then they're in the wrong industry.

It's definitely a issue, but I think it's far from the biggest issue. If you're going to use ruby, you're going to have to come grips with the culture, which for better or worse involves more "magic" and meta-programming than, say, Python where the same power exists but is avoided on principle.

It takes a little getting used to, but once you are, then the tooling is there to help you make sense of these things:

1.method(:year).source_location

The bigger issues with Rails I see are the monoculture issue raised in the article, plus the intractable issues with ruby around performance, memory bloat, concurrency, and last but not least, the multi-paradigm nature giving you functional features, but without any of the usual immutability guarantees (unless you follow a constrained and unconventional coding style which no one does in the ruby community).

It's a fairly simple remedy, if you're OK with pulling in Activesupport

Yes 1.+(5), 5.-(1), 1.*(2). Ruby is probably the most object oriented language out there, besides Scala(which borrows from Ruby. Which borrowed form Smalltalk). Keeps syntax rules to a minimum. Where is something like Java 1 + 1 is a special syntax case on primitive types(primitive types in hindsight were a terrible decision). In Ruby methods can be called with spaces and without parenthesis. So 1.+(5) is the same as 1 + 5.

But is that any different from any other system, where you have to learn how things are put together? For example, Java projects frequently use Maven. You need to download and learn Maven to understand how it's put together.

You can explain those two things you mention in a few seconds ("Ruby allows adding new methods to anything; the 'hours' method is defined by ActiveSupport"), and then the confusion has been eliminated. That leads to an increased understanding of Ruby.

FWIW, I've had a whole bunch of junior colleages learn Ruby, and those things were never a point of confusion. If anything, I have the opposite experience; Ruby and Rails are superb for newbies because of all the sane (convention over config) defaults.

Unfortunately, one segment of the Rails developer culture has perpetrated a lot of ugly overdesign (mini-frameworks such as Devise, ActiveMerchant, etc. that inject themselves into Rails in brittle ways) that certainly will confuse newbies. But that's not Rails' fault.

Explicit configuration may teach a new developer about a codebase, but it also means that there's more upfront work when developing. If the conventions are already there, in the form of good developer habits and good workflow, it's more pragmatic to encode them as explicit conventions, rather than introduce lots of un-DRY boilerplate.

Reply on news.ycombinator.com