From: Chad Perrin Date: 2006-09-06T06:06:17+09:00 Subject: Re: Joel Spolsky on languages for web programming On Wed, Sep 06, 2006 at 02:36:02AM +0900, Richard Conroy wrote: > > Libraries is life. And the greatest source of risk generally, developers > like > libraries that they can trust. If you can't trust them you have to > limit yourself > to problems that do without, or write your own equivalents (which will wipe > out your rails productivity boost). . . . once. Imagine you have choice A and choice B. With choice B, you have all the libraries already. With choice A, you're missing some. On the other hand, with choice A you have a productivity boost that provides extra time roughly equivalent to the time it takes to write the libraries that are missing. Now imagine you're doing the same thing again, a few years later. Would you rather have chosen option B the first time, and be faced again by the same trade-off between core task productivity and available libraries, or have chosen option A the first time, have written the libraries you needed, and now have only to choose between two options with the same library availability for the task at hand with wildly different productivity characteristics? Productivity doesn't go away just because you're spending the same amount of time completing the overall goal. It just gets used more. Rather than producing only a web app, you are in the same time producing a web app and the libraries necessary to support it. Now, if producing those libraries the first time ends up taking three times as long as the app itself with choice B would have, that's another story -- but if I take your "wipe out your rails productivity boost" comment at face value, I'm still choosing Rails. > > 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 have got some sloppy partial code around that > builds up a DIV graph and there is a perceptible delay in the drawing > of the page that uses it. Admittedly its under worst case scenarios, but > it does strike me that you really don't want to be doing anything funky > in your controllers at all. It strikes me as a bad idea in general to pursue edge cases in frameworks. Frameworks are for general-case development. Their benefit is that they do the common things for you. If your application is 98% uncommon things, you aren't going to get much use out of frameworks. SNMP, I realize, is not an uncommon case, but it's uncommon enough for web app development that expecting a web development framework to do the heavy lifting for you is a somewhat odd demand, I think. > > 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. > > I would kill to read a step by step example of this - from source control > to OS-specific-user-friendly installers. I have been looking a bit at > Capistrano, I haven't delved deeply enough, but it doesn't seem to > go the full distance that I am talking about. And if I am not mistaken, > the author has stated that its not a path he will pursue I'm entirely with you on this: web application framework advocates, for any framework in any language, seem to believe that the developer will always be the one deploying and that deployment will be accomplished at a server where the developer has complete access and control. There isn't nearly enough attention on the problem of removing control characteristics and direct access capabilities, or even passing on deployment to someone else entirely who wasn't part of the original picture at all. -- CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ] "There comes a time in the history of any project when it becomes necessary to shoot the engineers and begin production." - MacUser, November 1990