From: avi@...4.com (Avi Bryant)
Date: 2002-04-30T10:24:48+09:00
Subject: Re: RubyConf.new(2002) - ideas for agenda

james@rubyxml.com wrote: 

<being able to push code updates to a live application>

> Maybe this is getting too far a field, but I'm curious why this is
> essential for web development.  Most languages do not have this feature,
> yet they are used daily for web development.   Is this mostly a matter of
> deployment, where one would prefer not to have to stop and restart an
> application to change the in-memory code image?

Ok, so "essential" was a little too strong.  Make it "extremely nice".

Deployment is definitely a big part of it - I don't generally work on
large scale, publically accessible web apps a-la Slashdot, but rather
on specialized in-house applications or services with small numbers of
clients.  If someone runs into a problem, they'll call me, and it's a
world of difference to be able to write, test, and deploy a fix with
the client still on the phone, than to have to take down the app or
ask them to restart what they're doing.  There are examples in the
Smalltalk world of web applications with uptimes of over a year, with
development progressing all the while (to make myself perfectly clear:
a single process, running for a year, with code updates being
continually fed into it); in the Lisp world, Paul Graham talks about
doing very similar things for ViaWeb.

But for me, the gains during development are nearly as important. 
Bear in mind that this ability is something that most web developers
are actually quite used to, in that with the typical stateless CGI or
script approach, you can modify a script partway through testing an
application and keep going from that point - when you're between
pages, there's no actual running process to worry about.  Stateful
approaches like FastCGI or Servlets, although offering big gains,
generally take a step backwards in that respect.  A big part of the
reason I chose Ruby for IOWA in the first place was that, being
interpreted, it lent itself decently to the edit-reload cycle I was
used to with web scripting, even while doing complicated stateful
applications.  Ruby actually works more or less well enough in this
respect for development - during my RubyConf presentation, I got a
number of surprised comments on my continual debugging without ever
restarting the application - but there are enough gotchas to make it
annoying, and there's no chance I would risk a live reload on a
deployed app.

Cheers,
Avi