6 ms·

It's not hiding anything, other than the conventions. Django's spammy boilerplate is just default behavior.

• kowdermeister 10y ago
  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.
  • nitrogen 10y ago
    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.
  • lobster_johnson 10y ago
    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.
    • majewsky 10y ago
      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.
      • kowdermeister 10y ago
        Integers have methods? ಠ_ಠ
        • lobster_johnson 10y ago
          Yes, why not? 42.times { puts "foo" } 1.upto(9) { |n| puts n } puts 1.year + 7.months - 1.day
          • dedsm 10y ago
            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
            • lobster_johnson 10y ago
              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.
            • bdcravens 10y ago
              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.
            • dasil003 10y ago
              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).
  • viseztrance 10y ago
    On the other hand conventions are great when reading a foreign code base.
    • kowdermeister 10y ago
      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.
  • gonyea 10y ago
    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.
    • kowdermeister 10y ago
      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.
• collyw 10y ago
  What do you see as Django's spammy boilerplate?