Hacker News new | past | comments | ask | show | jobs | submit login
Ruby on Rails: the Duplo generation (railsontherun.com)
19 points by iamelgringo on March 17, 2008 | hide | past | favorite | 16 comments



Uh... if we're going to argue that way, we could say that Matz and Guido did the same thing by creating those easy to use languages that don't make real men out of their users like C did. Or that the C language took all the pain out of assembly that made users tough...


Not at all. He's saying people are using plugins but not writing pluging. When's the last time you saw a C programmer extend his compiler?

I've heard this complaint before, in fact:

"I complained at the last OOPSLA that - whereas at PARC we changed Smalltalk constantly, treating it always as a work in progress - when ST hit the larger world, it was pretty much taken as "something just to be learned", as though it were Pascal or Algol." --Alan Kay


This article is just more "My myopic Rails-constrained view of the coding universe forces me to conclude ..."


It's kind of silly to try and lump Python in with Ruby. Ruby's sold itself on how easy it makes web development and how you don't have to learn very much to be productive with the language. To use Python you need to know a fair bit about what's going on with the language. I'm not sure the same thing could be said for Ruby on Rails.


The other piece is that it takes a bit less time to learn a fair bit about Python.

Regardless of the merits of each language, Python has a lower barrier to entry. With Python, it only takes a half day to get used to the language. While I picked up enough to be comfortable in a subset of Ruby in a day, reading code isn't always as obvious to a newbie because of the numerous rubyisms that one encounters, especially with metaprogramming.

As such, it is going to take Rails developers longer to be able to meaningfully code plugins. The impedance mismatch leads to the Duplo syndrome here.


I like Rails a lot because it allows me to focus on concept and less on the actual code. If anything does pan out (which might happend 5% of the time if I go through enough concepts), then it's time to revisit whether or not Rails is the appropriate framework -- IF there are issues with it.

I get tons of ideas; Rails and Ruby together (I cannot begin to tell you how valuable Watir is) afford me enough speed so that I can prove if the concept is worthwhile while at the same time have something to build upon towards a production application. I could easily do the same in Java (what I use 40 hours/week), but I'd spend an equal amount of time on coding as I do on concept/design.

The fact that I don't have to worry much about coding components from scratch is useful specifically because I have a day job! Even if I didn't have a day job, I'd be cranking out more concepts using Rails than I would with Java.

So what if Rails lowers the barriers to entry for writing a web application?


Lowering barriers is good. However, if you didn't actually understand how Rails was making life easier for you, wouldn't that be a problem?


Not at all. If somebody is not skilled enough to build a quality application, what do I care? I only need to be worried about what I know, not with what others know. If somebody wants to take the initiative to write ANY application, then it is up to them to take the responsibility that they understand what they are getting themselves into -- this is THEIR responsibility, not mine, not DHH's, and probably not yours.

Furthermore, I do not need to be concerned with the underpinnings of ActiveRecord. I know I like it for what I need to do and more importantly I know how to use it properly (otherwise I would have no reason to jump into it). NOTE, knowing what to do is entirely different from the why of how it does what it does. An even better example is CookieStore: because I like to think I have a solid understanding of what constitutes a secure interaction using this default mechanism in Rails, I feel that I do not require a deeper understanding of how it performs its magic, unless of course there is something that is causing a systemic issue for my app; chances are somebody else is having the same issue and I'd rather let others spend time finding these flaws for me instead because I got other things to do (see a pattern emerging?). If all else fails, then I can spend time/energy in fixing it myself, at which point I become a contributor to Rails (yay!).

If somebody else is foolish enough to not know the general concepts of building an application responsibly (which does not translate into becoming a downright expert in whatever framework they are using) then this is a shortcoming in their approach/attitude towards success in the future and not an inherent issue with the framework they are using.


Completely agree. I've been saying to anyone who will listen that Rails is not for people who are new to web development, nor for people who were never willing to learn how certain things in web development work.

However, marketing of Rails was such as to invite the newbies in. These newbies will also complain the loudest when a certain plugin doesn't play well with their code or with other plugins. However, we cannot expect them to contribute, since they are not fully aware how Rails works anyway.


perhaps DHH is justified in saying "fuck you" to all those people who don't know better...

But I do agree with you - to a point. There are all sorts who liken Rails to the pixie dust of the year ("BUT IT'S BUILT IN RAILS SO IT MUST BE COOL!!"), but I just ignore them and go back to what I was working on.


All developers should start from scratch, create their own languages, compilers, operating systems and framework.

If they don't they don't deserve to get their right of passage and will never be mensa, spartan or ninjas

I havent used RoR, but what I always thought, was that even RoR is too hard, you still code from scratch, a better approach for RAD should make you start from a GUI/IDE and let you add code when needed something like VB6 only better!


Your first sentence was gold.


A plugin by the newbies this author is so down on would probably not be a plugin you'd want to use. It's cool that they're learning rails, why begrudge them the chance to learn on the framework or harangue them for not writing plugins? The natural learning curve of ruby/rails is nice in that mostly people can create plugins when they've climbed mount ruby on rails, but not sooner.

Everyone was a beginner once.


"The problem is that a generation of Rubyists has grown up being used to getting everything pre written for them. "

A generation?

Hyperbole much?


I think the ability to put things together from someone else's code is a good thing. Of course, I'm just getting old, lazy and cynical. But there's limited virtue, IMO, in creating something from scratch if Duplo-style development achieves results which are just as good.

Thoroughly take his point about whiny users though. Unfortunately, if you commit to an open source project that's just part of the scenery and you have to live with it.


"Regular" size Lego fits onto Duplo -- including Technics.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: