I guess the case I'd make for it is that your company should have been using MVC all along. While Rails is an MVC framework, there are multiple benefits to using Rails besides three letters. Substruct, Castle, and others have been available but none of your managers have been that interested in pushing it. This sounds, sadly, like an excuse to stay with the Microsoft developers because there are a lot of those around.
The problem with that is that if those developers aren't thinking about MVC already, they're not gonna benefit much from this now UNLESS MS pushes future development in ASP.Net to the MVC pattern. Ruby, and Rails, give you these features either completely or much easier. * Full stack open source. You are not reliant on a vendor to release a patch. If a security concern arises, everything from the views to the server itself can be patched. Easily. * Testing. It's easy to talk about writing tests, and I know for a fact that most places that write code for other people just don't do it in the .Net world. I cannot live that way and I vbet you can't either. N:Unit exists, but have you tried using it? In the Rails world, writing simple or complex tests are so easy to write you're foolish if you don't. * Experience: .Net has been around forever, but the MVC framework is new and if past products have been any indication (.net v1 and v2, silverlight 1 and 2, etc) are any indication, it's just *good enough* and surely not *good*. While you probably have a lot of .net developers, you probably don't have a lot who *know* the .Net MVC framework. With Rails, it's easy to find someone with 3 or 4 years of experience with the whole stack, including testing. Of course, this is exactly what you'd expect me to say, right CJ? On Fri, Apr 3, 2009 at 5:59 PM, Mark Turner <[email protected]> wrote: > > On Apr 3, 3:03 pm, Greg Donald <[email protected]> wrote: >> On Fri, Apr 3, 2009 at 4:18 PM, Mark Turner <[email protected]> wrote: >> > Rails is a mature framework >> >> No, it's not. > > This conversation will go way out of Chris's question's. Sorry Chris. > >> >> How can you say something like that after everything that's changed >> from 2.2 -> 2.3 ? Or knowing what's likely to change with 3.0 when >> more of Merb gets merged in? >> >> When I read things like "middleware layers being completely rewritten" >> it leads me to question why they were written so incorrectly to start >> with that they needed to be completely rewritten. When I read things >> like "memory sessions have been removed" I gotta wonder who thought >> they were a good idea to start with? Newsflash: some of use were >> using those. (Yes I'm aware of how to get them back using the plugin, >> that's not the point.) If you're gonna put something in there, have a >> good reason for putting it in there, have a reason so good that you >> won't later find an opposing reason strong enough to remove it. > > You're trying to tell me that backwards compatibly is the key to > determining maturity? > I disagree completely. Just like moving from gcc 3.2 to 3.4.. > regressions happen. Hence the reason for the developer to stay on top > of the changes in the frameworks, tools and languages they use for a > living. Hell look at Java 1.4 to the current 6.x (which if you follow > their previous versioning it would be 1.6)changes most of the user > exposed API's have been left alone but there are plenty of examples of > changes that would cause you to experience pain deploying your 1.4 app > on any 6.0 jre. > > This is one of the reasons testing has become so popular, not just in > our community but in most other development communities. > > And I calling rails mature in comparison to .net mvc seems pretty rock > solid to me. > >> The Rails API and docs change constantly and are often out of sync. >> Last month for example, api.rubyonrails.com was showing new 2.3 >> features before 2.3 was even released. How'd you like to be a new guy >> scratching his head over grouped_options_for_select being in the docs >> but not in the framework? I could much more easily accept the reverse >> case. > > Agreed. > >> And what about the gem servers that are constantly up and down? How >> can newcomers have any faith in Rail's maturity when you can't even >> install it sometimes? > > Rubyforge happens to be the standard gem repo right now, and > installing rails through gem is the de-facto standard method but > hardly the only way. > >> >> And what about the book situation? Rails is changing so much, so fast >> that a Rails book you buy today will be useless 6 months from now. I >> have 8 and 10 year old Perl books that I still use to this very day. > > Hmm and I seem to have an 8 year old ruby book that is still just as > valid as it is now, this is about Rails not Ruby. Try opening the > Catalyst book from packt and tell me things won't be different today. > This is an issue with computer books that's been around forever. > >> I love working in Rails, it's the fastest way I know of to build a >> website, but mature is the last thing I'd ever say about it. I have >> absolutely no faith in the API remaining the same from even a .1 to a >> .2 release, much less 2.x to 3.0. If you can't count on the >> user-level API being stable how can you even begin to say it's mature? > > I guess we have different views about maturity. Oh well. > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
