Re: "stereotyping"

Clifford Heath wrote:
> Julian Fitzell wrote:
> 
>> Wow!  That's quite the troll! - I think I'll bite.
> 
> 
> Sorry, it probably was a bit OTT. Interesting though that most of the
> apps listed are either inhouse dev't or products sold to generate
> support (customisation) revenue - like large trading apps for example.

Well, I've never had a discussion about this that has changed the minds 
of either party, so I'm weary of carrying on much longer and I certainly 
stop short of trying to convince you - but I figure I might as well put 
the counterarguments out in the open for those who may be reading.

> My experience is with designing and extending large software products
> (>1MLOC) over dozens of upgrade cycles and six+ years, where you gather
> a large base of legacy code and entrenched design faults, with a need
> for backward compatibility and migration at every release, with teams
> of 10-30 engineers (not super-large, but enough that central review and
> control is quite hard), most of whom have been working on the product
> for less than half its life. I've done this three times now.

People often say that Smalltalk is never successfully used for "large" 
projects, but they usually mean "large" in the sense of code size as 
opposed to large in the sense of amount of functionality.  In my 
opinion, no language is ever used successfully for "large" projects when 
using the former definition.  In my experience, writing in Smalltalk 
produces code that has the same functionality as Java with a tenth of 
the volume of code.  Our project is an enterprise level application for 
a university community of 30,000 people; many of the large smalltalk 
applications out there are being used in similar environments and have 
been around for more than 6 years.

This doesn't in any way prove that static typing is evil or even worse, 
but the statement that "large" projects can't be done in a 
non-statically-typed language is pretty flawed, in my opinion.

> 9 months on a project doesn't really count. Problems arise over 9 years
> when you can't provide hands-on support for customer upgrades. I can't see
> how I'd do that with any fully dynamic language without even optional
> typing. Not Ruby, definitely not Smalltalk, though both are superlative in
> some fields. That doesn't mean I'm happy with the languages I *have* used
> however, I think the computer language field has a *long* way to go yet.
> Wish I had time to write Rite :-) Ruby's so good, and Rite is such a good
> opportunity for significant further improvement.

I really don't understand your statement that "I can't see how I'd do 
that with any fully dynamic language".  That statement seems to depend 
on the assumption that there is some problem with dynamic typing which 
is exactly the point being debated in this thread (though not, really, 
the point of my response, which was just to point out that Smalltalkers 
do in fact work in teams over extended periods of time).

>> If for some reason, it still wasn't clear, I could easily put in a 
>> comment explaining what was expected but I can't think of a time 
>> recently where that has been necessary.
> 
> 
> That is indeed the mark of a good language - it communicates by itself
> without the need for comments. However, the lack of method typing in
> both R&S limit the amount of information that can be included without
> adding comments, and that's a pity when so much else is right. Note that
> it's only partly about what the compiler can check, it's mainly about
> what the human can apprehend.

Again, I don't really see how it limits the amount of information that 
can be included.  Is "someMethod: fooString" really any less clear a 
declaration that "someMethod(String foo)" ?  The difference to the human 
reader seems pretty minimal.  In fact, to a human reader, why would it 
even matter if it had to be expressed in a comment instead of as a type?

The point of the compiler enforcement really is the crux of the matter 
in my opinion.  Some people like the basic security of static checking, 
but it gets in your way every time you want to change a type (you have 
to go change all the methods that take that as a parameter) even though 
the behaviour or interface is the same.  You need to spend a lot of time 
up front making sure your types and interfaces are correct so you don't 
have to go through making changes like that later.  You have to always 
worry about casting when you take objects out of an array (assuming 
we're talking about Java anyway) and you can have a runtime type error 
anyway if the object doesn't cast correctly.

To many of us, the increased plasticity allows us to more easily 
refactor and to make the code reflect what we mean as we develop rather 
than bending to the will of a compiler.  This, in my opinion, leads a 
cleaner system that is easier to understand, less likely to contain 
bugs, and easier to find bugs in when they do occur.  Others may 
disagree, but this is my experience.

And I will also say (though has little more merrit than you saying you 
don't know any Smalltalkers who work in teams on large projects) that 
the vast majority of people I have talked to who have used dynamic and 
static typing swear by dynamic typing.

Not the most compelling argument, but like I said, I'm not trying to 
tell anyone else they can't use static typing.  All I'm saying is:

a) I don't want to use it; and
b) I don't experience any of the problems, when using dynamic typing, 
that people who like static typing say I should be experiencing.

Julian