Hacker News Reader

Comment by kowdermeister | Hacker News Reader

Conventions is something I try to avoid at all costs. Conventions are usually things that are hard to find in documentation. Conventions are things that every experienced user says that "oh, this is common knowledge" and conventions are the reason why things seem to work magically.

Obviously if you follow a framework from day 0 you don't even notice it. For newcomers, it's a source of frustration.

View on HN

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.

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.

Frameworks should be designed for experts as well as newcomers. I was a Ruby-only developer and, after starting a full time Rails job, picked it up quickly enough.

Your complaint is more about implicit vs. explicit. Implicit behavior is bad when it's surprising. When it's what you would have done anyway, then making it explicit creates an unthinking, tedious ceremony that you repeat daily.

Some of my favorite Rails devs are former Python devs. They appreciate conventions and the freedom they give you.

Correct. I never tried Rails, I just know that conventions were always a major pain point for me. Most of the time it hurt me more than it aided me.

On the other hand conventions are great when reading a foreign code base.

And if conventions don't change :) If a team can follow conventions it's a good thing, but I personally favor explicit code that does nor les nor more than it says. I do use frameworks, but I always pick the minimalist ones where I can see the chance understanding what goes on under the hood.

Reply on news.ycombinator.com