From: Devin Mullins Date: 2006-09-06T12:08:31+09:00 Subject: Re: Joel Spolsky on languages for web programming Long post! Ack! > The fact that one solution may take 50-100% longer to implement > isn't necessarily a big risk. But when a library or technology that > is critical to your infrastructure exposes its project-breaking flaw > you are in serious sh1t, as unless there is a feature equivalent > non-broken alternative, or you can write your own conveniently, your > project schedule is out the window. Your initial schedule is nothing > compared to the time overruns these kinds of showstoppers > introduce. So... the 50-100% extra time is okay, as long as it's known up front? Why not just pad the extra 50-100% for the Ruby estimate, and just spend the last few weeks partying when you finish early? :P >> 2. What such case studies have you read about the other options you're >> considering? > > I have read this negative one: > http://rationalist-manifesto.blogspot.com/2006/07/web-applications-vs-web-sites-ruby-on.html My question had an agenda. I meant: leading up to the moment you picked [Java, I presume], what case studies had you read about its use? Just trying to scope out for any double-edged swords. Sorry; I was cranky yesterday. > Mostly what I am concerned about are War stories > - case studies of Rails adoption, even from companies that were not strong > in web development Well, at RailsConf, I talked to a guy who'd never programmed in his life before Rails, and he said that within 2 months of picking it up, he'd deployed an app to a customer. *shudder* > I have seen reports on this list that Rails churns its plugins, that > correct plugin operation is not guaranteed as it matures. Hrm. The only thing I really recall breaking a whole bunch is Engines. That said, through experience developing some of these apps, I've become much more conservative of what plugins I use. I wrote my own tagging code; were I to do it again, I'd write my own user/password code; etc. Not so much because of Rails upgrades causing breakage, but because the plugin implementations turned out to be flawed/buggy (read: poorly tested). > to. People with an eye for risk take that pretty seriously - they > expect security issues, but not rock-and-hard-place conflicts like > that. That's true, and that's one of the ways in which Rails needs somewhat guru coders -- ones who test their app thoroughly, and are able to patch the broken spots when they come up. >> Ruby/Rails libraries/plugins/tools are all over the map > i.e. all over the place - that makes it risky Same could be said about any language, no? > I don't see enough libraries > that I am likely to depend on, at a mature enough version to warrant doing > anything mission critical with them. Theres a lot of libraries that require > binary installations that are unavailable on all platforms. Ah, yeah, can't help you there -- I haven't needed much in the way of libraries -- XML parser, HTML parser, etc.. I might be able to help you with the second part in a few days -- I'm finally getting around to profiling, and hence need to compile Shugo's or ZenProfiler for win32. > write your own equivalents (which will wipe > out your rails productivity boost). Well, not according to the Relevance folks, but I admit, they seem pretty adept. >> Never had to do SNMP processing, sorry. > Well lots of people do, and the question still stands as to what happens > to the boost if you have to do any significant Ruby code processing in > Rails (non-SNMP). I'm confused... are you asking if the Ruby language is as quick to program in as the Rails framework, or if the framework is fast despite the language? Or are you talking about writing a Ruby extension? In any case, I don't know if you are going to get metrics much more specific than the Relevance posts. People seem pretty guarded about their own professional productivity. Probably a little productivity abritage going on. > I am not talking of the classic situation of where you own the server or > can directly install on in customer equipment. I am talking of scenarios > where you have to produce a windows/Mac OS/Linux installer/packager, > that will extract out a working Rails Apps with dependencies and > minimal interaction from the user. Interesting. Well, Rubyscript2Exe is supposed to do just that. Never used it, but seen an example package being run. A little slow to start up. > I don't have a problem with working on Rails myself, I always figured > that if > I could get a functional prototype of what our main app is doing, > working in > Rails, it would be a good start. But its all these edge conditions that > would > kill Rails adoption - and I don't have the time to both address/investigate > the concerns Ah. Well, I might, were I working for you. But I'm not. :D Devin You made it! You win a prize!