2 July 2007
Blasphemy: The Case Against Ruby on Rails
In our last post I fawned over Ruby on Rails (RoR) like a schoolboy smitten by the new girl (let’s call her Ruby) at school. So, like the schoolboy’s heart wrenching realization that he mistook Ruby’s “hello, world” smile for a tender “will – you – be – my – boyfriend” countenance, I present a handful of potential RoR letdowns.
Skills Demand > Skills Supply …There appears to be considerably more demand for Rails programming than there are Rails programmers (irrespective of whether they are good programmers or mediocre ones). The theoretical speed of development and speed of enhancement (read: potential cost saving) as well as the trendiness (let’s face it) of Rails has inspired a legion of business visionaries to increase their demand for Rails programmers in order to get their own facebook-meets-amazon mind bender to market faster than the other guy.
Yes, [they’re] the great pretenders …The unfortunate reality of the RoR movement and market is that there are a number of below average soloists passing themselves off as solid developers due to the level of demand. This has consequently led to both able and mediocre sole practitioners and confederations of practitioners trying to fulfill the demand. We’ve seen a number of companies and entrepreneurs write, re-write, and re-re-write Rails applications primarily due to sub-standard code quality. Without real-world experience with Rails, companies and entrepreneurs are having an exceedingly difficult time vetting “single shingle” coders. Even though they are writing this software in a “highly desirable” framework, they’re commanding between $100 – $175/hour to write throw-away software due to their lack of sophistication and, ultimately, accountability. [Note: you should be paying for features and ROI not for hours]
The Visual Basic effect … A corollary to the fact that “pretenders” are besieging the market is that Ruby on Rails provides so much scaffolding, hand-holding, and out-of-the-box functionality for developers that inexperienced/unsophisticated developers are able to initially delight clients with early releases. Like Visual Basic in the mid/early 1990s, Rails allows non-computer scientists to put together seemingly impressive applications. However, as a project progresses or application matures the truth becomes clear: (1) Rails helps bad coders write unscalable, unmaintainable, unmentionable code faster, ergo (2) Rails helps organizations fail faster.
No Swiss Army Knife … Ruby on Rails was developed to do one thing and one thing well: help teams write web applications with user interfaces that perform basic operations on relational databases. Period. If you have complex processing needs such as message queuing, quantitative optimization, etc you’ll need to either (a) look somewhere else (b) write it into the framework (not likely as the shepherds of the framework are zealots and opinionated about protecting it from “unintended uses”) or (c) find a way to integrate with other technologies which support your business requirements.
No Throat to Choke and a Chasm to Cross … If what you want is an alpha, beta, or a version one application that you may re-write down the road, Rails may be right for you, but if you’ve got shareholders you must answer, teams you must attract, grow, & maintain, or business groups you must support with vendor options and a cadre of capable employees, Rails is an iffy choice. There are no/very few established vendors backing Rails at this point either from an implementation or education standpoint. This makes adoption of the technology and its ability to cross the technology chasm questionable. Rails is still early on the S-curve. It may make inroads into enterprise application environments the way Linux did through techie revolutionaries. However, for it to truly become a technology that is well understood, well-supported, and, consequently, well entrenched, it will need the backing of a behemoth or two. Perhaps RoR will gain the support of IBM or an equivalent, but the backing of a programming framework — at least on the surface — seems a heck of lot more pock-marked with landmines (variability in installations) than supporting and advancing the kernel of an operating system that has been in existence for decades.
The Java Defense … Perhaps the biggest reason not to choose Rails is, well, Java. The “old guard” Javaists are adapting. They may not be benefiting from the “hoola hoop” craze that is all things Ruby. However, they’re not taking the RoR attack lying down. In fact, in a very Zen-like fashion, they are borrowing from the “one thing well” manifesto of RoR to develop equivalents including Groovy on Grails, Trails, and the like (We’ll write about some quantitative benefits of these developments which we’ve seen first-hand in upcoming posts; suffice it to say, Groovy/Grails is proving itself to be a formidable challenger). In enterprise-friendly terms this means companies will be able to “maximize and enhance their existing Java technology investments.” And, with Java you get the Swiss army knife.
EDIT: For completeness and for the sake of those who did not have the time to navigate our blog, In a previous post, we examined the virtues of Ruby on Rails from a business perspective…and the potential economics of Rails in another post ….
Technorati Tags: crossing the chasm, Ruby on Rails, RoR, Rails productivity, technology adoption, Groovy, Grails, Trails, time to market,
Comments are locked.
R Mutt says:
sunjay says:
good catch, R Mutt (Matt) .. should be fixed now.
Adrian Madrid says:
Interesting read although it seems funny you mention Groovy/Grails and forget about JRuby. Your slant is anything but hidden nevertheless talking about Grails and skipping JRuby seems lacking.
AEM
KirinDave says:
How many times can we say “DOES NOT SCALE” in long-winded prose? Only the internet can tell us.
Joel Henderson says:
If you think Rails is just about relational databases, think again.
One customer of mine uses it for easy image processing via RMagick, another uses it for near-real-time logfile analysis, and another uses it to manage a large SFTP site for sharing media files. Ruby’s capabilities for Domain Specific Languages make this much easier than doing it in Java.
sunjay says:
Joel.. definitely don’t think RUBY is just for RDBMS (we’re working/exploring other things ourselves). RMagick as an interface between Ruby and ImageMagic libraries seems like neat glue code. However, just from a “spirit” standpoint DHH and crew have and continue to propound RAILS as best suited for web-based aplications.
Jon says:
I love Rails simply for what it has done for Java web dev. Hello Grails!
Rails is cute (Ruby is pretty sweet from a theoretical standpoint…practically it is just too slow), but Grails is powerful. Grails may never get into the web devs (or the people too “cool” to write enterprise applications, but instead write web sites and call them applications), but it will be used much more in enterprises and that makes it valuable.
As for Groovy vs JRuby vs Ruby. Well, I am quite partial to Groovy because it is cleaner and closer to its Java cousin. I like Ruby, again-in theory, but it is just too damned slow. JRuby? Why? Just use Groovy.
Mark Miller says:
Re: unskilled Rails developers
I’ve been hearing some about this. It surprised me, the idea that people would actually say they’re RoR developers when in fact they don’t know very much about the language, but just know how to manipulate the framework using the scripting tools, and maybe slap some code inside the models and views to get a site going.
Looking at RoR a bit from afar I’ve been concerned about the “VB factor” myself, not in the sense of working with inexperienced developers, but just running into the limitations of the framework, as you describe, or the language. I used to hear this about VB 6, though I didn’t completely understand it at the time. The complaint was you’d feel incredibly productive when you start out a project, but then you’d run into a wall where VB just couldn’t do something. Typically what would happen is the shop would either have a VC++ developer on hand to code some component that would do the job, or hire a developer to do this, and they’d link it into the VB app. The extensibility was its “saving grace”.
One example of this is continuations. I tried asking around about this recently since I was interested in the concept of using continuation servers with web apps. I’ve heard of Seaside and I’m interested in it. It turns out Ruby has continuations but they’re supported by a primitive (C code) and they only work one way. As they exist you can’t serialize them, so while you could use a continuation during a round trip, once it ends the continuation disappears. You can’t serialize continuations without modifying the Ruby core to support it. If I’m unwilling to do that, I can’t modify Rails to use them. I’m not a Java developer, but if I was, there are frameworks available you can use to essentially create a continuation server.
Justin says:
“but it is just too damned slow”
What are *you* doing wrong then? Maybe you are one of the VB Railers this blog post talks about?
I remember all the anti-Java stuff about how it was “just too damned slow”. Funny how that turned out.
Jason says:
Justin:
Java *was* too damned slow. Then the JIT got a lot better, and it got a lot faster. Ruby is too damned slow now; maybe it will get faster, but we’ve been hearing that the next version is right around the corner for some time now. Even when this magic new version comes out, there’s not a lot out there that suggesting that Ruby will be JVM speed for some time. Maybe JRuby.
Jon says:
So we are clear about my background:
C->Perl->Java for work work
C->ASM->Perl->Python,Lisp->Erlang for my side / fun work.
That being said: Ruby is too damned slow. Everyone knows it. Jason said it best about Java: Java *was* slow. JIT fixed that problem. When is Ruby going to fix this (among some other rather prominent problems).
Ruby just has to grow up, basically. And the people (the ones making sites and calling them applications) need to understand where Ruby fits. It sure isn’t in a hospital, or on wallstreet or in a bank. Ruby isn’t quite there yet. Lets be realistic.
Mark Smith says:
I don’t mean to be harsh but for me your credability went out the window when you recommended Grovy & Grails, which as independent language and framework have even less support than Ruby or Rails. It just makes no sense to me, maybe I just haven’t drunk enough of the Java-coolaid.
For the record: I’m a fan of most languages. Ruby has some nice qualities and some not so nice qualities. I’m not a web developer though so Rails is usless to me.
Other than that an interesting read, good work!
Mark Miller says:
Re: “Ruby is too slow” arguments
Being able to compile Ruby to bytecode and running that through a VM would be a start. I finally realized about a week ago that with RoR all the code that gets generated to create the ORM and the web interface has to be regenerated with each postback! I bet that’s where the performance hit is coming from. Having said this, when I tried out some simple stuff with RoR about a year ago it was snappy on my 1.4 Ghz machine. The point is it could run faster if it didn’t have the overhead of starting from square one with each page refresh.
I believe there’s an IronRuby implementation for .Net. I don’t know what its performance characteristics are, but if it’s anything like IronPython it could be an improvement over the original. I read that IronPython for .Net actually outperforms CPython.
Zachary Kim says:
This was a few posts down from this one on dzone:
http://www.anyware.co.uk/2005/2007/07/02/10-common-misconceptions-about-grails/
At the moment I don’t have much more than an academic interest in Grails, but I really admire a philosophy that puts a convention-over-configuration layer on top of existing, time-tested libs (Hibernate, Spring) instead of writing the functionality from scratch.
As Mark said, Ruby’s got some very nice features, and IMO is at least worth keeping an eye on.
Mark Murphy says:
This blog post…has issues, stemming from an underlying philosophy that the only businesses worth mentioning are “enterprises” (admittedly, that’s the focus of those behind the blog, but that might not be obvious to all readers). 99+% of the world’s businesses are not enterprises. Let’s look at the issues from a broader perspective:
– Skills Demand > Skills Supply: Only an issue if you routinely hire developers…like enterprises. Otherwise, you’re retraining your existing staff, and by your own implied admission, RoR is pretty easy to pick up. Or, you’re hiring a consultancy (though probably not a “boutique”), and your evaluation of their RoR ability is no different than your evaluation of their Java skills.
– Yes, [they’re] the great pretenders: Again, only an issue if you routinely hire developers…like enterprises. Otherwise, RoR has no impact on your existing staff (if they sucked before RoR, they’ll probably still suck after RoR), and it’s as easy to hire a “all hat, no cattle” consultancy based on misreading their Java expertise as it is for misreading their RoR expertise.
– The Visual Basic effect: the same issue as the preceding one, apparently repeated for emphasis.
– No Swiss Army Knife: this is definitely a real issue…but it is a real issue for most Web programming environments. With the exception of Java+your favorite MVC framework or ASP.NET, anything else (Perl, Python, PHP, Seaside, RoR, whatever) will likely need to use IPC or something to get work done that isn’t practical in the language the Web interface is using.
– No Throat to Choke and a Chasm to Cross: if you’re not in the Fortune 500, you lack the hand strength necessary to choke most vendors anyway, so you’re better off measuring your ability to get help based on ecosystem and community than necessarily relying on strangling vendors.
– The Java Defense: this isn’t really an issue with RoR, but more of a statement of an alternative, so it doesn’t logically belong with the preceding bullets.
And, since the commenters, er, “railed” upon it:
– Ruby is slow and Rails is a hog: I’ll agree with the latter, in that Rails seems awfully memory intensive, exacerbated by its need for caching (e.g., acts_as_cached) and the “pack of mongrels” approach for doing Web applications. But for the 99% of non-enterprises, Ruby itself is plenty fast for things in its domain, simply because you’re not going to have that many users in the first place. Could it be faster? You betcha. Is that going to matter for the mid-size business where there are only 10-20 users of the application at any one time? No.
If I were CIO of a Fortune 500 firm, using RoR outside of experimental apps might scare me. As IT manager of a mid-size civil engineering firm, it’s not a problem.
Daily links - 03.07.2007 : TrendPlex says:
[...] The Case against Ruby on Rails [...]
jens says:
If you’re looking for speed in Ruby, well, look here: rocaml – http://www.rubyinside.com/rocaml-write-ruby-extensions-in-ocaml-544.html
sunjay says:
Zachary, thanks for the link regarding misconceptions about Grails. Nice find.
Mark Murphy, regarding the “spirit” behind the post regarding Rails’ fit in the enterprise, you’re absolutely right (though we, infact, are champions of its use and do offer it in conversation regarding technology direction with our enterprise clients .. there certainliy is applicablity for Ruby/Rails in the enterprise) We’ve used Rails for our own purposes (http://planixonline.com) as well as for the types of smaller clients that you mention. It absolutely, is a great fit – especially if the goal is time-to-market and agility while being able to radically re-write, re-fine, ehance an application because of extreme uncertainty about the value/fit/desireability of the proposed appliction .. .but the flexibility provided by Ruby/Rails is no excuse for the pretenders’ code who we’ve personally had to re-write and who caused innovative, eager, leading edge entrepreneurs to sink their hard-won savings into code bases that were no more than towers of dung.
Perhaps I should have restructured/re-emphasized this excerpt and placed it in an appropriate “Enterprise” context—
” If what you want is an alpha, beta, or a version one application that you may re-write down the road, Rails may be right for you, but if you’ve got shareholders you must answer, teams you must attract, grow, & maintain, or business groups you must support with vendor options and a cadre of capable employees, Rails is an iffy choice.”
Calamitous says:
“So we are clear about my background:”
Clearly you’re quite impressed with yourself. I’m not sure why.
“That being said: Ruby is too damned slow. Everyone knows it.”
Too slow for *what,* exactly? It runs our 24/7 business, with 200 employees and 6,500 customers hitting a single server all day long. It’s not “too slow” for us.
“When is Ruby going to fix this (among some other rather prominent problems).”
You hint, in a rather FUDdy manner, that there are other “prominent” problems. I’ve been using Rails for over a year in production, and have failed to run into these “prominent” problems. Maybe I’m not doing something right, when someone who admits he’s got no extensive experience with the framework is stymied while I’m just getting things done.
“Ruby just has to grow up, basically.”
I smell irony.
“And the people (the ones making sites and calling them applications) need to understand where Ruby fits.”
Absolutely. Ruby (and Rails) have their place, just as other languages and frameworks have theirs. Ignoring or denigrating *any* language or framework from ignorance or fear is foolish.
“Lets be realistic.”
Yes, let’s.
M Rubinelli says:
Most issues raised here are about maturity. Yes, Rails is new, so there aren’t many developers, and it’s hard to evaluate them. Yes, you can’t find libraries and plugins for every need under the sun, and when you do find them and, again, it’s hard to evaluate their quality. Give it a couple more years and the situation is bound to change. Most Fortune 500 won’t dare touching it before that anyway, so you aren’t losing anyone there.
Now, point #3 is interesting. Is Rails raising another generation of bad coders? I don’t think so, for three reasons. First, other technologies, from PHP to ASP.NET, are equally easy to break into. In fact, you can write a full ASP.NET application without knowing what the tag is. Second, Rails may let you create a bare-bones application in minutes, but it also tries to teach good practices, like separating model, view and controller and generating unit tests. And third, since both pros and beginners are using the same language all the time, it is easier for the latter to see what good Ruby code looks like and follow suit.
In closing, a comment about using Groovy: don’t. You have two great options to embed dynamic languages in your Java framework, Rhino and JRuby. Groovy the project is nice, unhappily Groovy the language tries to find the sweet spot between Java and Ruby, and there simply isn’t a sweet spot there.
CG says:
However, they’re not taking the RoR attack lying down…
not likely as the shepherds of the framework are zealots and opinionated about protecting it from “unintended uses”
Who’s attacking who – the RoR developers I come into contact don’t really care what language the Java masses use – but imitation is indeed the most sincere form of flattery so I would think that Sun and Microsoft count as behemoths.
I pretty sure I can write bad code in any language you want to throw at me. Perhaps the goal should be to create a language that is so hard to learn and use that only self proclaimed geniuses can use it and burn the rest – kind of like in the middle ages. Actually assembly language comes pretty close to meeting this criteria – perhaps we should have stopped there – it certainly is a swiss army knife.
Before you ask – I have been using Java for over 4 years and have written thousands of lines of code in it and probably just as much XML to support it. Actually I had no choice because you are right about one thing many companies are zealots and opinionated about the languages that must be used.
cell says:
W-w-wait… I only got as far as “$100-$175 an hour”! If I can write “throw way” applications in any language for that money, I would happily do so! Take it from someone who writes throw away software, not because of the trendiness of the language he’s using, but the total inability of users to request and specify software requirements that last for more than 6 months, I’d rather be earning that sort of cash doing it!
lordes says:
lol @ cell .. funny … “you had me @$100-$175/hr” … I think that may have been the guy’s point .. happily sucking down cash for crappy applications .. dunno. interesting article.
Mark Miller says:
@CG:
Re: hard languages to learn
You could add to that list K&R C, Lisp, and Scheme.
Some have talked about using RoR for small business web apps., and that it works just fine. Paul Graham illustrates what can happen though with the “hard language” strategy: It works fine for the start-up, but once it gets bought by Some Big Corporation (Yahoo! bought ViaWeb), then they turn around and convert it to something that’s more common–like C++ and Perl. The reason Yahoo gave for this was they couldn’t find enough Lisp developers to maintain it.
On the one hand lesser skilled developers can hold you back, on the other, the lesser skilled developers are basically all you’ve got. If you can survive with a small development team, you’re fine. The problem is the pool of sufficiently skilled developers doesn’t scale. That’s unfortunate, but it’s the reality, and as best I can tell our programming schools aren’t helping one bit.
Carter Parks says:
This entire “Case Against Rails” is not only full of flaws but its just generally insulting to this great framework. First of all, I’m not sure what job supply vs. demand has to do with the framework. Clearly its heavily in demand. You also seem to have a problem with “poser” coders who think that they are worth $100/hr because they bought a copy of Agile Web Development with Rails. That’s fine, but once again it has nothing to do with the framework.
Rails never promised to be a Swiss Army Knife for web applications. It promised to deliver the tools that are commonly required for developing database driven web applications… and it does that beautifully. And your claims about it being a “Visual Basic” because of its scaffolding is ridiculous. Scaffolding isn’t exactly drag and drop coding like Visual Basic is and I think most developers will agree that they rarely use scaffolding (I do, however, use scaffold_resource, not for the views but for the REST API it builts for free).
You seem to say that Rails can only breed disposable, unmanageable, unscalable applications with no evidence at all. Sure, if you managed to hire a newbie coder in any language you’re going to get disposable code that’s worth nothing. But generally Rails encourages unit and integration testing which tends to breed very consistent, agile code that can easily be manipulated without breaking the app.
All in all, as a fulltime Rails freelancer for the past year and a half I was very disappointed to read this post. If you have a problem with the Rails job pool, that’s fine, write “The Case Against Ruby on Rails Programmers.” But do realize that there is also a wealth of great programmers out there who can deliver elegant, maintainable, scalable code in Rails. Ask anyone who has seriously been developing with Ruby on Rails if they’d rather be coding Java or PHP and they will say “hell no.”
The Case Against Rails at Regular Expression says:
[...] Man… In an article whose headline begins with the word “Blasphemy,” AlterThought’s Un.Rust blog dares to state the case against Ruby on Rails… and makes some excellent (though painful to read) observations. [...]
Sidu Ponnappa says:
About half of what you say is true. But for the rest:
No Throat to Choke and a Chasm to Cross: Ruby has the backing of Sun and ThoughtWorks
as a consequence
No Swiss Army Knife: For the enterprise, see RubyWorks – this will eventually evolve into a stack supporting stuff like messaging.
As for Grails, why bother with Groovy’s half-way syntax? There’s JRuby, again backed by both Sun and ThoughtWorks…
CG says:
“Yes, [they’re] the great pretenders… ”
This is just flat out insulting
“We continually strive to be thought leaders for emerging, mid-market, and Global 2000 companies.”
For AFTERThought’s sake it would probably be best that Ruby does not become more popular because I am pretty sure they have alienated most any one associated with Ruby (and a couple of other languages to boot) – if that was their goal kudos as this article did a great job. I’m sure no one will burden them with any RoR projects or consulting in the future.
sunjay says:
CG .. I’m sorry if you’ve felt insulted … there is value in re-reading that section a bit more dispassionately … Its just factual observation from our client/partner/colleague base … nothing more, nothing less.
“Yes, [they’re] the great pretenders… ”
“This has consequently led to *both* *able* and *mediocre* sole practitioners and confederations of practitioners trying to fulfill the demand. We’ve seen a number of companies and entrepreneurs write, re-write, and re-re-write Rails applications primarily due to sub-standard code quality”
Perhaps you may also gain a bit more color by reading a previous bost extolling the virtues of Rails …
http://alterlabs.com/ruby/ruby-on-rails-as-a-platform-of-choice-the-case-for-rails/
Jeremy Weiland says:
All in all, as a fulltime Rails freelancer for the past year and a half I was very disappointed to read this post.
I suspect that’s because (A) you took it far too personally, as if what Sunjay’s saying in general reflects on you specifically, and (B) you’re not part of his audience. It probably would have helped if Sunjay had mentioned the preface he included in the last post:
I write this post from the various perspectives of the “president,” “idea guy,” the sometimes “project manager,” and the “unresponsive stakeholder.”
He’s an executive, business-oriented decision maker talking to other executive, business-oriented decision makers. And what they care about is not necessarily the great potential of Rails (which is substantial – you won’t find a bigger advocate of Rails than I) but the particular cost-effective market opportunities for Rails in the enterprise, given the other choices (PHP / .NET / Java / etc.). That’s a totally different question than, “is Rails intrinsically good or bad”, as you seemed to interpret it.
I won’t say I agree with Sunjay on everything, because I don’t (fair warning – he’s my boss). But especially with regard to the talent pool available, a freelance coder can only imagine how crucial this aspect is to a business. Rails is just at a somewhat awkward time where, like Sunjay said, the demand for competent coders outstrips the supply. This means not only that it’s hard to find any Rails coder, but that there’s less ways to measure his or her competency, since the metrics haven’t been identified like they have for Java / .NET *from the perspective of the hirer* (in other words, no certifications).
That’s not a downside of the framework by any means, but Sunjay never said it was – it’s a downside for a business consumer who wants to consider RoR in their next project, given the real world situation that you need people to code. People who consider themselves “idea guys” need to know how much effort, money, etc. a particular method of realizing their vision will cost. RoR coders should be honest about the market at this time, rather than just waving our hands and talking about how we can do A, B, and C so much better.
On the Swiss Army Knife front, I think this is just a matter of time… look where PHP and Java were 3-4 years into their life. I’m always amazed by the new plugins, tools, and other goodies the RoR community rolls out. There’s no doubt in my mind that the expressiveness of Ruby contributes to the community’s quickly growing array of utilities, libraries, etc. Sunjay, not being a coder himself, may not realize this, but anybody who reads Peter Cooper’s Inside Ruby blog, for example, or has built his/her own plugin *would*. But for tech people like me in the enterprise services world who cherish Ruby, a big part of our responsibility is to communicate those facts in ways that make business sense to the guys who write our checks.
All in all, I think your critique is unfair, because as a freelancer you’re not part of the intended audience. That said, Sunjay could have been clearer about to whom he was speaking. Let’s everybody calm down and recognize that there are tons of opinions here (and that the Rails community seems to encourage, rather than discourage, copious opinionating for its own sake. Thanks a lot, DHH ;-) ). We need to foster a community where we can own up to our weaknesses and realistically represent our strengths, instead of trying to be the hip programming option for everybody and their moms, which Rails certainly is not (at least, not yet).
We’ll never get to the goal of having RoR be the premier choice for enterprise web development (is this a goal? I hope so) if we keep drinking our own kool-aid and engaging in breathless platitudes about how “Rails changes everything”. The best way to prove that is to DO IT.
Graeme Rocher says:
Some of the comments on here about Groovy/Grails reflect many of the common perceptions about what it is about and why you would choose it over Ruby/Rails.
I have expressed this in more detail at my blog:
http://graemerocher.blogspot.com/2007/07/5-more-misconceptions-about-grails.html
Cheers
Graeme
stefano c. says:
Mark Miller: “I finally realized about a week ago that with RoR all the code that gets generated to create the ORM and the web interface has to be regenerated with each postback! ”
I really hope it will take you less than a week to finally realize the difference between development and production mode…
ALTERthought Blogs » Go-Railers in the Midst … says:
[...] Dian Fossey would be proud. The comments and feedback I’ve received regarding my last post ranged from the contemplative: “excellent (though painful to read)…” to the vitriolic: “retarted.” Suffice it to say, I was impressed with the throng of Railers defending their beloved framework (and more importantly “movement”) like Sigourney Weaver defending African Mountain Gorillas from hell-bound Poachers and Rawandan fatcat beauracrats. Apparently, I’ve offended. I’ve re-read that post a few times; its an order of magnitude less than a glove-slap as I see it. The funny thing is that post was one piece in a set of three looking at The Technology (Capital T) from a business person’s (apparently an idiot business person’s) perspective. The others were: [...]
Atlantic Dominion Solutions » Blog Archive » Great quotes from blog postings 7.5.07 says:
[...] “… if they sucked before RoR, they’ll probably still suck after RoR…” – Mark Murphy (comment) “That’s the only way, IMO, that a developer will survive this decade and next–by embracing everything.” – Court (Flexible Rails Google Group) “Developers have different needs. Let a 1000 solutions bloom and let us have the wisdom to mix and match wisely…” – Stephyn (Flexible Rails Google Group) // [...]
Max Hodges says:
Huh? I don’t get it…
> Skills Demand > Skills Supply
Sure! it’s the fastest growing framework for the web. There was probably an equal deficit of PowerBuilder developers and Java developers when those technologies were emerging too right? But I see the fact of demand for a technology outstripping the supply of developers as only endorsing the techonology–from detracting from it.
By that logic the iPhone sucks because the demand outstripped the supply?
>>The unfortunate reality of the RoR movement and market is that there are a number of below average soloists passing themselves off as solid developers due to the level of demand.
I think you’ll find that with any technology that there are plenty of amatures around. Goes for web and flash designers, graphic designers and photographers as well. Again, not a symptom of any problems with the techonology.
>The VB effect
Ruby on Rails provides so much scaffolding, hand-holding, and out-of-the-box functionality for developers that inexperienced/unsophisticated developers are able to initially delight clients with early releases.
That’s not a bad thing. RoR prototypes are now “throw-away”. They are working rails applications that the programming team extends to make “production ready”. This is one of the primary reasons why RoR results in faster, more efficient work. He writes like it’s a bad thing.
> (1) Rails helps bad coders write unscalable, unmaintainable, unmentionable code faster, ergo (2) Rails helps organizations fail faster.
The sky is falling! Plenty of the millions of VB coders in the world are adding real business value. Once someone’s VB office automation solution has grown people their ability to scale it, that’s when you call it in the big guns to take it to the next level. Buinesses aren’t going to be dropped dead left and right because of ror.
> There are no/very few established vendors backing Rails at this point either from an implementation or education standpoint.
yeah, it’s new. new vendors are arriving on the scene all the time. RoR being deployed with Leopard/Leopard Server is certain to accelearate interest and growth.
> No Swiss Army Knife
Sure it doesn’t do everything. Could probably be extended to do more. Basecamp and Highrise and certainly proof that it is good for something.
> The Java Defense
the speed and agility of ror vs enterprise-java for a start-up? rolls eyes
Did I miss something? Seems like a bunch of sophistry/logical fallacies to me. I don’t see any real meat to this guy’s arguments.
Max Hodges says:
sorry, should be:
RoR prototypes are NOT “throw-away
rails blog » Blog Archive » [Rails] The Case Against Ruby on Rails says:
Mark Miller says:
@stefano c:
I really hope it will take you less than a week to finally realize the difference between development and production mode…
I had kind of neglected that distinction. I remember now that in production your view templates don’t have to be run through erb each time. What about the models, though? I saw no mention of them being optimized when I looked at RoR a year ago. I did a brief web search just now and found that models can be cached using the cache_model gem, which implies to me that models are not optimized by default in production.
Cory Perry says:
Hmm, interesting discussion, although I have to disagree with most all of it.
Rails is a framework that was created to build web apps, nothing more. Granted, it does not do everything in the world, but NO framework does. EVERY framework out there could stand to be extended further, be documented better, and have a better community of supporters. Such is life.
As for me, I am new to Rails and new to programming in general. I have a 6 year web design background and I wanted to learn something new so that I could extend my knowledge and build upon what I knew I could already do well.
Here is where I think Rails wins…..
As a new programmer, Rails teaches me some very good programming practices that I really need to know as a new programmer. I used PHP for a while, and then moved to Rails. Greatest move I ever made. PHP taught me how to write sloppy, unusable code very quickly. Not because it was that bad, it was because there were conventions in place to tell me otherwise. It “forced” me to do nothing.
At least with Rails, I am going to be a better ‘mediocre’ programmer than if I used some other language that has no thought behind it.
Interesting article though, but unfortunately most of it is rubbish that makes no sense at all, and holds very little merit.
jake says:
if they sucked before RoR, they’ll probably still suck after RoR
Mark Murphy
So True….
–jake
CG says:
>
Wrong on both accounts – I am not a freelance consultant, I have served at each role of his audience, and I did not personally feel insulted – but I find it hard to believe that some if not many RoR developers found this statement insulting.
>
I noticed no actual names were cited so is it true or is it FUD? If you go around throwing punches like that you should expect a response. If you don’t think this is insulting perhaps you should ask for other opinions – maybe I’m wrong. I even noticed that he felt the need to put quotes around “highly desirable” – what’s up with that?
I just grow weary that so many people seem to feel the need to lash out against RoR and the RoR community – why! Actually you had me at he’s my boss and is not a coder – but I do applaud you for having the courtesy to disclose that.
CG says:
Oops – the references got stripped out:
“I suspect that’s because (A) you took it far too personally, as if what Sunjay’s saying in general reflects on you specifically, and (B) you’re not part of his audience. It probably would have helped if Sunjay had mentioned the preface he included in the last post:”
—–
Wrong on both accounts – I am not a freelance consultant, I have served at each role of his audience, and I did not personally feel insulted – but I find it hard to believe that some if not many RoR developers did not find this statement insulting.
“Even though they are writing this software in a “highly desirable” framework, they’re commanding between $100 – $175/hour to write throw-away software due to their lack of sophistication and, ultimately, accountability.”
—–
I noticed no actual names were cited so is it true or is it FUD? If you go around throwing punches like that you should expect a response. If you don’t think this is insulting perhaps you should ask for other opinions – maybe I’m wrong. I even noticed that he felt the need to put quotes around “highly desirable” – what’s up with that?
I just grow weary that so many people seem to feel the need to lash out against RoR and the RoR community – why! And then we are asked or expected to read this passionately written stuff dispassionately – perhaps your right we should just treat it all as FUD and forget about it or just not read it at all. Actually you had me at he’s my boss and is not a coder – but I do applaud you for having the courtesy to disclose that.
anonymous says:
best way to be “recognize” is to post stupid review about a particular technology or platform.
Jim Van Fleet says:
I’m Jim, and I both work for Sunjay and founded the Central Virginia Ruby Enthusiasts’ Group.
CG, I have seen moderate underperformance in one instance and what I would call egregious misrepresentation of Rails background and execution in another. I’ve also heard some stories nearly as bad.
The first two cases aren’t FUD to me because I know they happened. Believe me, I’d love it if they hadn’t.
As Max Hodges points out, this isn’t something that effects only Rails specifically, but to assert, as Carter Parks does, that it has no effect on the framework is a claim I’m not sure is fully considered.
Expect more from me (aka the Coder) on this topic very soon!
rails blog » Blog Archive » [Rails] The Case Against Ruby on Rails says:
[...] > Some blockhead wrote this absurd critique of RoR. Thought some of you > might want to comment on his article. Just search that page for “max > hodges” to see the reply I posted: > > http://alterlabs.com/general/articles/blasphemy-the-case-against-ruby-on-rails/ [...]
CG says:
Actually I suspect the Sunjay is an intelligent and respected individual because of the loyalty shown by those who work for him. So I will leave this discussion at this point and hope we can all stick to the facts and hope we collaboratively try to evolve the state of software development. RoR is far from perfect (and so am I) but I find the RoR community *in general* quite accepting, giving, and nurturing – something that we can all benefit from.
I do take software engineering seriously – badly written software can actually result in people losing their life savings or even their lives. So I to am dismayed that their are individuals that have no business declaring themselves as software engineers. Is certification, a required degree, or internship a solution – I don’t know – but that topic in itself has caused such controversy and flames that it is almost fruitless to even try to address it. It’s like a black shadow over our entire discipline – I wish someone could find a way to resolve this.
Hopefully you future contributions will shed more light into these more important issues.
sunjay says:
CG, thanks for your passion and P-O-V. Regardless of your position, I respect your enthusiasm and perspective. Do stay tuned for more info on software engineering in general an Rails/Grails in specific. Cheers, Sunjay.
shayne says:
Hmm. Interesting post. I’m evaluating RoR, partly because holy shit is PHP’s inadequacys getting me down (v5’s object model is a world ahead of v4, but man…. its still a bit of a daft language at heart, and has an evil stench of perl that I’ve never been keen on rolling with).
But the inexperienced developers jibe is probably a bit unfair.
My language I’ve loved the most has long been python, precisely because of its conciseness and ‘less is more’ attitude. But we’ve often been accused of been innexperienced, lazy, and so on. The white spacing attacked for its unorthodoxy and so on.
And then things started to change. People realised that Python coders tended to be a rather clever bunch, and ‘pythonic’ was our code for ‘clear and readable’. Eventually the lightbulb went on over peoples heads.
Rubys on a similar trajectory. Sure RoR DOES seem a bit simplistic, and dangerously concise. But under the surface theres a lot of cleverness going on. I adore Rubys closures (hint guido-> Give us pythonistas real goddamn closures! Iterators are fun and all, but…) and its picked off some of the best features about Lisp that made me love Lisp back in the day.
Give it time. RoR’s hype is currently its worst enemy. When people stop being excited about it, thats when it’ll really shine.
Andrew says:
Pssst… I have a secret…. that Java developer sitting next to you programming at 4 times the rate that you are… yeah that guy…. he wrote it in ruby. JRuby, yep, ruby in a jar. But seriously the programmer who is writing the bad ruby / rails would write poor code in any language. A good programmer will do his best in any language. I love Ruby. Rails is a huge timesaver. And when I have a problem that isn’t solved in the Rails core, i write the solution. I have yet to hit a boundary. And yes I write web-based applications for small businesses. And I will continue writing code for them. They number in the millions. “Enterprise” companies number in the thousands; and you can keep them mister Java developer.
Anonymous Coward says:
It sounds like you are envious and just throwing out junk. All of the things that you bash Rails for are problems that people or businesses cause, not the framework. Guns enable people to kill other people, but it’s still a person pulling the trigger. Not everyone who owns or uses firearms are murderers.
Get a clue.
Weaksseef says:
hallo everybody visitors of site alterlabs.com I not so a long ago am in Seattle
and so, that I parted with valuable a man, Edward- Strangeron, and now try to find him, last that I know so it that he lives in citi, and often vi
sits the resources of type your alterlabs.com, in a network likes to utillize the nameApplekon
, if suddenly will see this nik write that this man knocked in my icq . I very much I strongly test a boredom without socializing with this man.To reason wanted to say thank you to the command your resource. So to hold boys. Only little request of,sdelayte so that alterlabs.com better embarked on dial-up connection
Roger Pack says:
I think RoR works great for small web sites, or things with small load. If you anticipate your website becoming ‘the next best thing’ then maybe go for grails or probably Django, I’d say. Otherwise it’s nice and efficient. Just my $0.02. Use the right tool. This happens to be a good one for some cool looking smaller web sites :)
-Roger
GSIY … Ruby-Rails Portal says:
[...] Dian Fossey would be proud. The comments and feedback I’ve received regarding my last post ranged from the contemplative: “excellent (though painful to read)…” to the vitriolic: “retarted.” Suffice it to say, I was impressed with the throng of Railers defending their (our) beloved framework (and more importantly “movement”) like Sigourney Weaver defending African Mountain Gorillas from hell-bound Poachers and Rawandan fatcat beauracrats. Apparently, I’ve offended. I’ve re-read that post a few times; its an order of magnitude less than a glove-slap as I see it. The funny thing is that post was one piece in a set of three attempting to ojectively analyze The Technology (Capital T – a compliment) from a business person’s (apparently an idiot business person’s) perspective. The others were: [...]
Groovy on Grails » Blog Archive » The Case Against Ruby on Rails (AlterThought) says:
[...] – ALTERthought [...]


S-curve link is broken. Otherwise, interesting article ;-)