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 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

Justin Bailey 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."

It's interesting to say that, because not only is it completely untrue, but the opposite is in fact true. I would make the following statement: "Static typing makes it easier to maintain software because it's easier to change it". When you change the type of something in a program (be it statically dynamically typed) you have to change all uses of it. If your program is dynamically typed, you have to work very hard to make sure you catch all instances, perhaps by having an enormous test suite, perhaps by having a powerful IDE with semantically aware search and replace. A common source of bugs is making a partial change in this way, where a rarely-tested code path develops a semantic bug from a 'far-away change'. If your program is statically typed, the compiler tells you all the places you need to change. Job done. Therefore I find that generally speak change/refactoring is an order of magnitude easier in haskell than, say, ruby. Jules

Hello Justin, Tuesday, March 18, 2008, 7:41:15 PM, you wrote:

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.

f few weeks ago i made a post to main haskell list about static duck typing: type inference + flexible structure types created by use -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

At Tue, 18 Mar 2008 09:41:15 -0700, Justin Bailey 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.

I like to imagine it works like this: bad static type < dynamic typing < good static typing. Whenever someone says, dynamic typing is better than static typing -- just insert 'bad' in there and what they say actually makes a bit of sense ;) Since most programmers have never experienced a good static type system, it think it is fair to assume they are comparing dynamic typing to bad static typing -- unless they indicate otherwise. People also tend to mistake features commonly found in dynamically typed languages with things which could only be done in statically typed languages. For example, users of many popular dynamically typed languages like to be able to load code into an interpreter and run bits and pieces of it to test things out. This is obviously not a property of dynamically typed languages, since GHCi and hugs can do it as well. Many coverts to dynamic languages like to be able to just start coding with out having to first declare a bunch of stuff in .h files. But, of course, in Haskell you can just start writing code -- no type signatures or header files require. In this particular case, the ruby developer is attempting to attract attention and money to their project. The most likely converts are going to be Java, C++, and C# users. In that context, I suppose the claim that dynamic typing is better than (bad) static typing, could be true for some class of projects... j.

On Tue, Mar 18, 2008 at 09:41:15AM -0700, Justin Bailey wrote:

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.

It looks from the outside like Ruby is going through some growing pains as a result of the excerise of "too much freedom" at the moment. But I wouldn't write Ruby off on account of that: an interesting article I read recently made the comparision with Emacs lisp which offers a similar level of power to the programmer, in that pretty much any function can be redefined at any point, and yet it has a thriving culture of Emacs extensions, all written by disparate people who manage not to step on each other's toes. IOW, it's a cultural issue as well as a language issue. Ruby programmers will no doubt develop their own culture of what is and isn't "allowed" in publically available extensions just as Emacs lisp programmers have. Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt