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 <[EMAIL PROTECTED]> 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 >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe