Funny, I've mentioned "ease of use" and "rails" to a few rails friends, and most have said something along the lines of "Rails was never pitched as easy to use - I've no idea where people get the idea that Rails was intended to be easy to use!". It may be just them, but I've heard it from more than a few Rails people (though not universally).

Personally, it feels a bit revisionist, because I distinctly remember the Rails fans in 2006/2007 talking about how easy Rails made web development. But... perhaps my mind is playing tricks on me as I get older.

Rails was easy to use/learn in 2006/2007, and, coming from a background of 5 years of writing Java web apps, it was vastly easier than doing that mess.

I'm not saying it was or wasn't easy to use or learn, but I've had a few people tell me that it was never promoted as such by Rails proponents, only that it was a "better" way.

Again, my memory tells me that supporters at the time promoted it as easy as well, but I'm not finding much particular support material from 2006 on Rails (perhaps my google/archive-fu needs work).

Easy to use and easy to learn are too very distinct things.

And it was both...

I heard neuroscientists said our memories are actually unreliable and is more likely to become more fictionalized as time passes.

you sure that's what they said?

I feel like a lot of complaints about Rails 3 being harder to use are coming from Rails 2 developers who don't know it as well.

I've only played around with Rails 3 (I'm following Michael Hartl's tutorial) and have never used Rails 2, but I don't see how new Rails features like `has_secure_password` or the asset pipeline (which is super dead simple) make Rails 3 any harder. It seems like the opposite — perhaps someone who has developed on both major versions can enlighten me?

Thanks for the tl/dr, that post certainly needed one.

You missed the most important part:

And as for overly ceremonial code, let me tell you about my balls. I actually have a rake task to scratch my balls. Somebody told me a good entrepreneurial programmer writes code to scratch their own itch, and I took them literally. The code uses a serial port to power an Arduino board. The Arduino's got a servo with a backscratcher attached. I keep it on a shelf at scrotum height underneath my desk. I literally need to type bundle exec every single time I want to scratch my balls. I don't like having to type bundle exec every single time I scratch my balls. I named the task balls, so I can type rake balls, because it rakes my balls, and Bundler pisses all over my tidy syntax, but am I going to complain? Am I going to point out that asking me to type bundle exec every time I want to scratch my own balls shows incredible contempt for me as a user, particularly considering that the whole reason I'm a user of this particular thing is because I work in a language which was designed to optimize for programmer happiness? Of course not. It's not productive or helpful to say that, so I simply type bundle exec rake balls and scratch my balls in sullen silence. Typing bundle exec every single time I want to scratch my balls is the epitome of the overly ceremonial code which Rails defined itself against from 2005 to 2007.

The problem with tl/dr is that it misses out on the funny. :-(

Nope, the tl;dr didn't miss a thing.

OK it's mad funny, but what's so hard about `alias bx 'bundle exec'` in your .(bash|zsh)rc file?

I have that exact alias. But it still adds 3 seconds to the startup time of any command run under it

Maybe my laptop is underpowered, but three seconds to do essentially nothing is still a long time

I solved this by having isolated gemset for every project. This way I can use rake without fear of having multiple conflicting gem versions.

Bundler and rvm? "now you have two problems" :-)

Just to satisfy my curiosity, have you upgraded to 1.9.3 yet?

You shouldn't need an alias in the first place. "Convention over configuration."

Correct. The problem isn't the difficulty, it's the education.

In my own project (SproutCore), we've used Ruby-based buildtools since 2007, and there is unanimous support to move to Node, precisely because running a modern Ruby stack requires so much education.

We want to spend time in our IRC channel on SproutCore itself, not Ruby and it's myriad problems (all of which have "fixes" that "aren't so hard").

We're also moving to Node because the performance of the Ruby tools sucks, despite three rewrites (one by a member of the Rails core team, so not Ruby n00bs).

The Node tooling? It's so fast that we can literally rebuild the entire project from scratch every time we reload the app and still load everything into the browser in under a second. Oh, and it took about a day to write. :/

That, to me, is why Node is taking off. The "I can get shit done quickly" factor is very high, the resulting code runs very fast, and the community is large, energetic, and helpful. Plus, pretty much everyone has to use JavaScript today.

> precisely because running a modern Ruby stack requires so much education

Education about what? Can you give some specifics here? I'm genuinely curious as my day-to-day ruby development is pretty smooth and I haven't been doing it very long.

or if that's too much use --binstubs to use "bin/rake balls" or if you are really, utterly crazy, use --binstubs AND set $PATH to contain './bin' and then use "rake balls".

You can also use rvm with gemsets and just not use bundle exec at all. I'm amazed how quickly people forget about the things that bundler tries to fix. If you don't have any conflicts across your gems, you can basically use bundler as "just install my gems".

This broke for me with Rails 3.1 last I tried it. I had to use bundle exec to get it to work.

I use rbenv with rbenv-bundler which runs the bundled binstub from my current directory when I run the command.

whats the fuzz about bundle exec? that annoyed me for some time but it's sure gone for some time that I don't even remember it anymore..