I find it interesting that "change" is equated with "maintenance".  I would say that maintenance is a very small subset of change.  It's true that you can change a program in a dynamically typed language more easily, in the same way that changes are easier to make if you don't use source control and everybody shares the same source folder.

Changes that improve things, however, are more tricky.  And as you say, a large multiple developer, dynamically typed project sounds like a disaster.

(Of course, I don't have to tell any of you this)

cheers,
Fraser.

On Tue, Mar 18, 2008 at 5:41 PM, Justin Bailey <jgbailey@gmail.com> wrote:
>From a recent interview[1] with the guy leading Ruby development on
.NET at Microsoft:

 "You spend less time writing software than you spend maintaining
software. Optimizing for writing software versus maintaining software
is probably the wrong thing to do. Static typing makes it harder to
maintain software because it's harder to change it."

Two years ago I would have agreed with that statement. Now - no way.
Make the compiler work for you. I've done a lot of Ruby development
and I would never use it for a project of more than 3 or 4 people.
It's an awesome language but I don't think it would scale to
programming "in the large." Any object can be modified at any time.
Determining where a particular method comes from can be an exercise in
Sherlockian deduction. Give an organization of 100 developers that
much freedom and I can only imagine chaos would result.

Justin

[1] http://www.regdeveloper.co.uk/2008/03/17/ironruby_work_schedule/
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe