I don't think the author really gets why people have a problem with what's going on with Rails, and the article strikes me as a "I like this why don't you?!" type deal vs making a reasoned argument for why the constant change in the Rails way of doing things is necessary.
> If you’re learning a new language, a strong community consensus about a right and a wrong way to tackle problems aids learning
-----------------
Right, but the problem is that there doesn't seem to be a 'right' way, That's the problem.
We were all prototype a few years ago, now it jquery ... we (well I) hadn't heard of coffeescript till a few months ago and now its a default option in rails, The way we were constructing ActiveRecord finders had been set all through Rails 2, now we've changed it, the way we dealt with gems was set all through rails 2 now its changed completely in Rails 3.
I like change, I like staying on the cutting edge of web technologies, but I don't want to learn something, only to discard it and re-do it completely to bring it up to date with a new way of doing things all the time.
> If, as coders, we aren’t constantly striving to improve the status quo, what’s the point?
---------------------------
The point is that you have to realize that Rails isn't just your personal plaything any more, people are invested in it just as much any one person or group of people.
I have 5 Rails 2 apps that I support at work and a couple more outside of that, they're all on rails 2 ... bringing them up to Rails 3 without disruption, isn't going to be trivial and I'd be nice if folks acted like they understood that and didn't dismiss similar concerns, or berate folks for having concerns.
To that end, my personal preference would be to see fewer but more substantial releases and a little bit more engagement with the community before making major decisions about the framework instead of the steady drumbeat of updates and (seemingly) unilateral decisions (that coffee script decision really irked me, can you tell?)
This is where "state of the art" is really an apt phrase. Rails 3 is effectively a community consensus on the best way to make most webapps today. Rails 2 was the community's best stab at that same goal a few years ago. The distance between the two is explained by a changing state of art, and some ferreting out of weaknesses in the framework.
I think rails developers blindly upgrade their apps, just because they want to be on the hottest new technology. I know I am drawn by the glitter of rails 3.1 beta. But everyone should really weigh the business decision of upgrading; what do you really truly gain by being on the latest rails for all your apps? Sometimes the technical debt you take on by maintaining an old framework is less than the effort you have to spend to upgrade, especially for sunsetting apps.
Please. I've been writing rails apps professionally since 1.2. My observations:
1. jQuery quickly replaced prototype for most projects via the jrails gem. This just reflects the underlying reality.
2. Coffeescript as the default was a bad idea. This would make more sense in say a year from now.
3. Rails 3 active record w/ ARel is HUGELY better. I used to have to pull out find_by_sql every so often, haven't needed it yet in rails 3.
4. Bundler solves a whole raft of annoying dependency issues in rails 2. I can't tell you how many hours I lost to dealing with weird issues with vendored gems.
Bringing rails2 apps to rails 3 is going to suck for you. I'd argue that one of the prices for the elegance of rails is that you need to spend more time constantly upgrading it.
However, the advantage of this price is that you have a framework that has been consistently lead of the pack in terms of productivity and simplicity.
Personally I have worked with probably a dozen web frameworks thus far, on top of various languages, including Perl.
I'm not going to say that Ruby on Rails is the most productive, as python's Django (my bread and butter) is not too shabby either, and most popular platforms have some web framework that gets close or that are better at various tasks (e.g. I chose PlayFramework for some project I had because of its async support and couldn't be happier about it).
But IMHO, Rails 3 has the best design of the bunch - ActiveModel, ARel, Bundler, Passenger, database migrations that don't suck, less boilerplate than anything else of the same size/scope, the best plugins system I've seen (yes, I think it is better than Django's, no matter what Zed Shaw has to say about it) and also has the advantage of popularity.
This doesn't come without sacrifice. I hate that they've forcefully added SCSS/CoffeeScript as a default. But the great refactoring of Rails 3 had to be done, as frankly, the Rails 2 codebase was an incomprehensible mess. And you can't be on the leading edge of web frameworks without breaking stuff.
That said, Coffeescript as a default? Geez, I'd really like to know what they are smoking.
I'm sorry yes, the preceding post represents my opinion, and my opinion only. It does not represent the opinions of my employer, bank, or family, nor is it an official verdict of the United States Supreme Court.
Furthermore, any likenesses to people real, living, or yet-born are purely coincidental, or have been properly sublicensed through those who own their copyright.
You may not make copies of my post without the express, written consent, of the National Football, Baseball and Basketball leagues.
> Right, but the problem is that there doesn't seem to be a 'right' way, That's the problem.
The problem is that the state of the art changes. The reason Rails is still relevant is because the core team is committed to improvement, even at the expense of API stability and legacy support. That's definitely a valid concern for someone supporting apps on a shoestring, but on the other hand it makes Rails more suitable for someone who wants to stay on the cutting edge. You simply can't have it both ways...
> We were all prototype a few years ago, now it jquery ...
You mean __7__ years ago when they chose it as the default? Rails was the first framework with Ajax support built-in, and it was done poorly because nobody understood how it should really work at the time.
> we (well I) hadn't heard of coffeescript till a few months ago and now its a default option in rails
It's easy to argue that CoffeeScript shouldn't be a default, but then it's even easier to just turn it off. Shouldn't be a point of major contention, but I can see how people don't like it.
> The way we were constructing ActiveRecord finders had been set all through Rails 2, now we've changed it
Yes, they replaced a hodge-podge of ad-hoc query construction with a relational algebra library that enables dramatically more flexible query construction and lazy loading. Who knows how many broken edge cases were fixed merely by the switch to a proper mathematical basis.
> the way we dealt with gems was set all through rails 2 now its changed completely in Rails 3.
Bundler solves dozens of thorny issues that were intractable in the Rails system. Now Rails is simpler because it doesn't have to have any gem activation code, it's handled by a separate library that can solve your gem management problems for your non-Rails projects as well. You may not have run into any of these issues, but I assure you there were real and Bundler is a big step in the right direction.
> the way we dealt with gems was set all through rails 2 now its changed completely in Rails 3.
Yeah but what are the implications of that? You want Microsoft-style legacy support from Apple? They ain't gonna give it to you, because that lack of legacy support is what enables them to move forward at the pace they do. This has definitely impacted the type of projects I feel comfortable delivering in Rails (ie. no low-budget small client sites), but for an actively developed app it makes Rails a more attractive place to be.
Neither the first post ("WTH is going on with Rails?") nor this one is talking about upgrading existing 2.x apps to 3.x. There's a lot of stuff to change, and it can take a not insignificant development effort to port them.
But that's not the question here -- the question is whether Rails is getting progressively easier or harder for a newbie to pick up and whether those changes are going to result in better or worse applications.
But that's not the question here -- the question is whether Rails is getting progressively easier or harder for a newbie to pick up and whether those changes are going to result in better or worse applications.
--------------------------------
If you read the article he makes other points as well, the author of this article just seized on this because it was probably easiest to shoot down.
In the original article the author says ...
"The speed of change in using and learning rails however is a real worry for anyone who wants to use it. It might completely change by the end of next month"
That's what I'm interested in discussing, and I suspect where the real problem lies.
The problem, or the solution depending on your point of view, is that Rails is not backward compatible between minor releases. Each minor version is work to upgrade to it. My recommendation has always been "start with the latest version of Rails even if it's RC status" since upgrading will be a pain. Hopefully the RC will be complete before you need to launch.
Then you have to make the decision for each app - "Do I upgrade or stay on the latest version"? I personally prefer that tradeoff - Rails can cleanly add new features even it breaks the past. Then I decide if I need those features more than I need the pain of upgrading.
I understand your frustration -- you may not think so, but I get it. That being said, the other points I made were in support of the answer I pose to the question: Rails is growing up. The changes we've seen aren't just change for change's sake. They're changes that continue Rails' evolution by identifying pain points and presenting a default solution to them, one that can be opted out of if desired. This is not new for Rails, but it seems like every time we turn around, people are acting surprised.
They're changes that continue Rails' evolution by identifying pain points and presenting a default solution to them, one that can be opted out of if desired
-------------------------
You're thinking "Why can't they just opt out of this and let us have our fun" and we're thinking "why are they forcing this on everybody".
Its kind of how you get a windows box and it has all this crap on it by default ... you can go uninstall or turn stuff off, but its fricking annoying as heck.
Some things should be the way things are done in rails, bundler, the new ActiveRecord queries. yes
Some of this other stuff, not so much ... you should have to explicitly turn it on not turn it off, and then if we're seeing wide adoption then we can make it part of the core.
What is wrong with that approach?
one that can be opted out of if desired. This is not new for Rails, but it seems like every time we turn around, people are acting surprised.
---------------
Don't make people opt out of stuff especially on things that might not be so core to rails ... Opting out is annoying ... its much better to go "Wow, I didn't know that was there" than "crap ... I have to turn this stuff off now". It gets on people's nerves, the fact that you're not seeing that despite confessing that people complain each time it happens suggests a certain amount of tone deafness.
I could be wrong, but I think its worth re-evaluating.
"I like change, I like staying on the cutting edge of web technologies, but I don't want to learn something, only to discard it and re-do it completely to bring it up to date with a new way of doing things all the time."
As long as something is backwards compatible, I don't see the problem. That is the natural progression of a rapidly evolving industry like tech, there is always something new. I don't see how introducing coffeescript as an option makes a problem for anyone. I agree there shouldnt be change for changes sake, but often through trial and error we discover a more efficient way of doing things. If rails doesn't evolve, it will be replaced by frameworks like Django, CakePHP that do.
The Rails core team does seem to treat the project as if it's a personal playground. But the improvements they make do seem to (usually) be good ones. Since it's almost always the case that you can eschew their choices, the complaints I hear are not compelling.
I think you're missing the perspective of someone who has a major body of apps to maintain. I easily upgraded a trivial app. Now I'm slogging through a month long Rails upgrade process on a very large app. Unless you've been stuck with a large upgrade like this, it is probably hard to understand the upgrade pain.
That said, I love the changes in Rails 3. Considering strings unsafe and escaping them by default is great, bundler rocks, arel is very nice, and the mailer api is nice.
The rapid change and code purity ideals in the Rails world leads to benefits, so I tolerate it in Rails in spite of its costs.
This idealism has unfortunately infected projects in the Rails ecosystem that are really just infrastructure (where change should occur slowly). As examples, both Rspec and RubyGems are willing to break compatibility and code that I rely on for benefits that are neglible, aesthetic, or invisible to me. The difference is, when Rails breaks something, 90% of the time it buys me something.
The Rails core team does seem to treat the project as if it's a personal playground
---------------------
And thats a dangerous attitude to have, because as smart as they are (and they are very smart guys, make no mistake), they can also make bad decisions, just like the rest of us ... the difference being that the impact on all of us could be huge.
The author says Rails is growing up, part of growing up is learning to be responsible too.
The difference is that Steve Coast, the post’s author, casts himself in the role of a crusader for the newbies.
I find this all a bit odd, since as a Rails newbie[1], I found Rails 3.0.x very easy to learn with a little help from Michael Hartl's tutorial and the Rails Guides. Perhaps this is an example of the "curse of knowledge?" In other words, that since Coast found Rails 2 easier, he assumed that newbies would as well?
[1] Front-end developer with little back-end experience.
Yup -- that's basically it. A true newbie should find Rails 3.x easier. It's the people who have to unlearn habits that may have it rough. I found Steve's advice to learn an early version of Rails first completely backwards, in that respect.
Wait till you have to keep up with the changes when 3.1 then 3.2 come out six months within each other, and start to change and deprecate things that you learned in 3.0.x
You don't have to keep up if you don't want to. Your apps will not stop working if you choose not to upgrade. I have apps still running on Rails 1.x and 2.x. They don't get huge traffic and they are meeting the customer's needs. There would be no business advantage for these particular customers if I had to charge them to upgrade.
Yes you do have to keep up. Because one day you'll go install your 2.3 app on a new server, and you'll have an incompatible version of some library because Rails 2.3 didn't specify version number dependencies.
Like what happened to Rails 3.0.7 and Rake 2 weeks ago.
That's why you use Bundler. In my experience Bundler solves this problem 100%. Lock your gems and get Ruby from RVM and the chances of nasty surprises are next to nil.
I wish the Rubygems guys would put down the crack pipe though. They're the one problem in this setup and, admittedly, they're a massive problem :(
It's not just security (and other) patches for Rails, it's maintenance for the assorted plugins one inevitably ends up using.
If you've a Rails 2.x app with plugin ActsLikeWhatever, and you run into some problem with that plugin, chances are the fix will only be in the newest, non-Rails2, release.
It took me five minutes of reading the changelog to figure out what I have to stop using in 3.1. There are additional features that can be integrated into a workflow at whatever pace is desired. People are making a bigger deal of this than they should, I think.
This is the typical "rails" response. Rails will make you a better programmer by teaching you the right design patterns, etc. Of course, it does indeed give you a proper structure to building a web service and can be quite educational. However, it can make life difficult once you start straying from "their way" even if you know exactly what you're doing for even simple things like mapping to a legacy DB with schema intact (not gonna happen). Conventions over configuration is nice but it requires some stability.
Part of the problem is the leadership. They take the stance, "you bastards are doing it wrong" if you want to do things a little different.
The community almost split when they managed to swallow Merb and keep Rails. It's toned down quite a bit but that negativity definitely carried over from the early days and infects the community (swearing in presentations and porn references, etc.).
But these thinking aids aren't exactly radical paradigm shifts that will expand your mind and make you a significantly better programmer for the rest of your days. Rails is one of the most influential frameworks and did a lot to advance the field but now there are other frameworks that are much easier to learn and get a functional web service started.
So saying dissenters are slow to learn, stubborn or haven't been writing tests really doesn't do anyone a service and doesn't make anything clearer, sorry.
>it can make life difficult once you start straying from "their way" even if you know exactly what you're doing for even simple things like mapping to a legacy DB with schema intact (not gonna happen)
Yikes, unfortunately this knocks rails off of my to-try list. I've got a non-web application with an unusual, but by no means bad, schema. I've found it makes a good measuring stick for frameworks/tools. I have nothing against doing things in the way of a particular framework, but I have existing code to bring to the party too, if something isn't going to play nice I ignore it. I can't live with building something that exists in isolation. Its either not going to work with what I have, or hold me back when I want to build on top of it with something else.
> However, it can make life difficult once you start straying from "their way" even if you know exactly what you're doing for even simple things like mapping to a legacy DB with schema intact (not gonna happen).
class Account < ActiveRecord::Base
set_table_name "tbl_accts"
has_many :posts, :class_name => "Post", :foreign_key => "postid"
end
class Post < ActiveRecord::Base
set_table_name "tbl_posts"
belongs_to :account, :class_name => "Account", :foreign_key => "postid"
end
#Account.first.posts.create(:title => "test", :body => "test")
that's almost like child's play(code is not tested, but it looks like that.. and i'm pretty sure it's sitting there quite a while)..
> Conventions over configuration is nice but it requires some stability.
if you were to compare this with an agnostic framework with drop-in, you have to set everything. with rails, you just gonna say "oh, this isn't default so i have to explicitly set this".. or "oh, this is no longer default so i have to set this".. it's just a convention.. if you want to use rails in an unconventional way, by all means do it, you just have to know more about its internals if you intend to do this -- this makes sense when you think about it(you don't want to be hacking hard on a piece of software you don't really understand, you're going to want to know what you're doing so that you have a good idea when some unexpected problem arises).
>Part of the problem is the leadership. They take the stance, "you bastards are doing it wrong" if you want to do things a little different.
if you did that and decided there's really nothing out there that can solve your problem, they you can just implement it however you want, rails is very configurable, but really, you're just limited to what ruby can do..
>So saying dissenters are slow to learn, stubborn or haven't been writing tests really doesn't do anyone a service and doesn't make anything clearer, sorry.
i'm sorry, did the article speak to you this way? are you a girl where you might be giving meaning to what's actually being said?
I think most of the arguments people have any time Rails does a major change can really be re-interpreted as:
"I have a moderately complex Rails app that I want to upgrade, but I don't have much confidence in my tests, I maybe don't have proper separation of concerns, and I just know that one hacky thing I did a while back is going to bite me in the ass."
It's just something that happens over time in any moderately complex app. I see Rails point release candidates as a good reminder to bust out rcov and spend a few days plugging up the gaps in test coverage before the stable release comes out.
If you've been procrastinating upgrading your Rails 2.3.x app to 3.0.x, you're really gonna have fun going straight from 2.3.x to 3.1. Sometimes you just gotta rip off the band-aid.
"I have a moderately complex Rails app that I want to upgrade, but I don't have much confidence in my tests, I maybe don't have proper separation of concerns, and I just know that one hacky thing I did a while back is going to bite me in the ass."
This says it all for me. Upgrading an app or parts of an app that have great test coverage is really pretty straightforward. It's only more difficult if you weren't following best practices all along.
> Upgrading an app or parts of an app that have great test coverage is really pretty straightforward. It's only more difficult if you weren't following best practices all along.
Like people working with Rails in the the real world with real, less-than-perfect programmers.
Yes, if I'm an ideologically pure, saint-like programmer with 100% test coverage and purely idiomatic ruby, then upgrades should be a breeze.
Except the plugin ecosystem problems still arise-- even the 'perfect' programmer has to be perpetually upgrading to the latest-and-greatest plugins since the last authentication/taggable/whatever plugin has been abandoned in favor of the flavor-of-the-week.
This happens with all languages and frameworks too. There are ASP.NET 1.1 apps at the last place I worked because when we did a test upgrade to 2.0 things started failing.... and there were no automated tests (yet a requirement of bugless releases :) so henceforth nobody wanted to invest in upgrading.
Its the nature of the software beast that upgrading a large and complex application to a new version of the language or framework is difficult and maybe prohibitively difficult. Once something is written and it works it often times stays as is... sometimes for decades.
Hard to take too seriously any OO fundamentalism from someone who cites the Gang of Four patterns as if they were sacred scripture. Actually, they're techniques for working around the limitations of languages like C++, and when evoked explicitly in Ruby tend to be a "code smell".
This comment has been a service provided by the small bot running in my brain programmed to respond to mentions of the GoF book with a link to Norvig's presentation on them:
I maintain a couple of non-trivial Rails 2 apps, have just shipped a couple of Rails 3 apps and am preparing to write a Rails 3.1 app. I had always been using Sass and Haml for my views from the Rails 2 days. I moved over from shoulda to rspec 2 for Rails 3. All my solutions run partly on MRI/1.9.2 and have certain parts in JRuby (document parsing, search, etc). I had always been minifying and combining my Javascript. Sass with Compass/Blueprint took care of minifying and compressing my CSS. The only change that I am not comfortable with as yet is CoffeeScript. But after playing with it for a couple of hours I understand that this is an excellent choice. I have been a Python programmer before and significant whitespace in CoffeeScript or Sass does not bother me.
I am extremely thankful to the people in the community who are putting their time and effort to build such great software and essentially giving it away for free. I am personally both awed and humbled by the excellent work put in by all the individuals who directly or indirectly contributed to Ruby and Rails across all the versions. If not for them I would not have quit my day job. If not for Rails, I am pretty sure that I would not be enjoying my life, as much as I am enjoying it today.
The point is that Rails has grown up to the point where makes it simple to write complex applications. For small projects, these choices may seem to be an overkill. But trust me, when you put it into production and start getting traction you will thank Rails. I have built applications with Sinatra and Rack and assembled my own Rails environment using tons of middleware and a lot of glue. I know how hard it is to do it the right way and appreciate the fact that Rails makes it a cakewalk for us. I sure learnt a lot of Ruby but I would choose Rails any day as I know that there has been a lot of thought put in by the community to make it awesome.
I've lost count of how many times I have tried to do something in Rails which was trivial in every other framework I have ever worked with; struggled; gone to #rubyonrails or a mailing list and asked for advice; and had people tell me that I was "fighting the framework". I understand the benefit of not having to make every single decision from the ground up when you're getting started on a project, but sometimes I worry that working with rails is actually warping my thought patterns to fit its myopic vision of how web apps "should" work.
To phrase it differently: I feel comfortable with a framework or community forcing me to change how I achieve some higher-level goal. But when that convention prevents me from doing something, period, I start to worry.
Rails is very opinionated about the things it handles and how it does them, but I've never had a problem rolling my own solutions and integrating them in. Not every model has to inherit from ActiveRecord, arbitrary code runs just fine in lib/ What's the problem?
Thats how Rails is ... I fought it at first, but you either come around or you don't. There isn't much middle ground with rails, you have to accept that and plan accordingly.
> In most cases — for mere humans, anyway — there really is a right way to do things. Ruby is an Object Oriented programming language. There are literally decades of prior research in the field of OO software design, and they’ve resulted in a lot of really well-documented and well-tested design patterns for building software.
... coming from the people who are known for relying heavily on monkey patching existing classes.
The rapid pace of Rails is a turn-off to me, and I do bounce between it and the more "sane" Django.
But I think that's more a reflection of myself (being an "old" guy who's "been there, done that" several times over and resistant to change and trends) and not the fault of Rails. So I try to keep up.
But Rails is good for the web. The web was pretty stagnant at one time, and it sucked, and didn't keep up with the needs of users and businesses.
And that's why I don't have a real problem with Rails' rapid pace. It keeps everyone on their toes, including their competitors.
I agree with a lot of what the article says but I do think the newbie coming to rails at the moment has to do a hell of a lot more to start swimming compared to the "good old days" of Rails 2.
Ruby 1.8 or 1.9? Use RVM? How does this Bundler thing work? What the hell are all these deprecation warning? Rake's broken? etc. etc. 3.1 brings asset pipelines where it seems you need to install a Javascript runtime on the server to deploy?!?
Even when you get your app up and running the load times in 1.9.x at the minute mean you'll be hanging around waiting for rails to generate files and your going to have to get Spork running to make any kind of rapid TDD/BDD.
Rails used to be the easy way into all this modern development goodness, now that "blog in 20 minutes" simplicity has gone along with the famous screencast.
It seems actually kind of obvious that "opinionated" software would have a higher rate of change than other kinds of software: opinions change faster than the other stuff.
I was thinking just the opposite. When it comes to frameworks, opinions are good things. But you kind of look like an undependable jackass if your opinion changes every 5 minutes.
Opinionated software should actually change slower. Why? Because if conventions/defaults change quickly you break constantly or even worse, you quietly break. And of course since your unit tests are often written in the same language, you now have double the problems.
With less opinionated software, changes actually rarely break you since it typically requires opt-in/code change to pick up the new capabilities.
All the frameworks "are growing up", this is nothing to be proud about. The real question is: is the framework becoming mature?
Because RoR has this tendency to reinvent itself every 18 months or so, the answer to the question is a resounding no. It's being used mostly to explore new ways to create web sites, but RoR is more and more becoming a framework you really want to avoid if you need to create a production site that you are planning to work on for years to come.
When one person drives the platform strategy, and it is opinion-driven, then conflict like this is inevitable. You either agree or you don't, and if DHH changes his mind, you might changes yours, too.
I don't think it is a statement on the platform at all - just a repercussion of one of its tenets.
At least you guys Rails have something new to look at, good or bad I don't judge. I've been using Zend framework for the last 3 years and it's latest version 1.10 has lived like "forever", until the day ZF 2.0 comes out, which has been "promised" a long time ago
I don't think this is a good thing. I built a few rails apps and currently we are doing our startup in rails and java and depressingly enough Java is actually nicer for me. He's talking about well documented gems; which ones? I haven't seen much of those; it's usually 'go read the source code'. And all those 'great OO practices' where suddenly some class is behaving totally different because you installed a plugin is GREAT when it works. When it doesn't you are debugging yourself silly through all that meta programming crap. And having (as in, stuff stops working) to change your code through minor versions? That's not growing up, that's just crazy behavior.
Rails will be retrofitted to make it easy to start with a “core” version of Rails (like Merb’s current core generator), that starts with all modules out, and makes it easy to select just the parts that are important for your app. Of course, Rails will still ship with the “stack” version as the default (just as Merb does since 1.0), but the goal is to make it easy to do with Rails what people do with Merb today.
"It's growing up" sounds like "it's turning into java"
Now I know it's not that bad but I can see a future where instead of just having the rails book, you have books for every new thing and option possible and the section looks like the Java section where Struts, Spring, and even Scala/Clojure all make the idea of switching to to rails seem far more daunting than it needs to be.
Right or wrong, I'm looking forward to whatever fills the spot that Rails left behind. It was a pleasure to work with a few years back and I miss that.
If you've seen something that fits the bill, please pass it on.
I liked being able to think of an idea, sketch out a schema and have it up in (admittedly ugly) webpages in a matter of minutes...and on almost any machine in just the time it took to download the package (no crazy dependencies, etc.).
The fact that you could then evolve this into something production-ready (arguably), well that was just icing on the cake!
Bxr is suggesting that you either move that conclusion to the end or eliminate it completely and define your argument so that the reader can figure out whether or not "he gets it". If I had to guess I'd say he would prefer the latter.
> If you’re learning a new language, a strong community consensus about a right and a wrong way to tackle problems aids learning
-----------------
Right, but the problem is that there doesn't seem to be a 'right' way, That's the problem.
We were all prototype a few years ago, now it jquery ... we (well I) hadn't heard of coffeescript till a few months ago and now its a default option in rails, The way we were constructing ActiveRecord finders had been set all through Rails 2, now we've changed it, the way we dealt with gems was set all through rails 2 now its changed completely in Rails 3.
I like change, I like staying on the cutting edge of web technologies, but I don't want to learn something, only to discard it and re-do it completely to bring it up to date with a new way of doing things all the time.
> If, as coders, we aren’t constantly striving to improve the status quo, what’s the point?
---------------------------
The point is that you have to realize that Rails isn't just your personal plaything any more, people are invested in it just as much any one person or group of people.
I have 5 Rails 2 apps that I support at work and a couple more outside of that, they're all on rails 2 ... bringing them up to Rails 3 without disruption, isn't going to be trivial and I'd be nice if folks acted like they understood that and didn't dismiss similar concerns, or berate folks for having concerns.
To that end, my personal preference would be to see fewer but more substantial releases and a little bit more engagement with the community before making major decisions about the framework instead of the steady drumbeat of updates and (seemingly) unilateral decisions (that coffee script decision really irked me, can you tell?)