From: Sean O'Dell <sean@...>
Date: 2003-11-22T03:13:47+09:00
Subject: Re: "stereotyping"

On Friday 21 November 2003 06:21 am, Austin Ziegler wrote:
> On Fri, 21 Nov 2003 17:13:36 +0900, Clifford Heath wrote:
> > Austin Ziegler wrote:
> >> Um. Sorry, but type signatures don't promise you that side
> >> effects are limited to compile-time.
> >
> > That's true, but they help by catching some cases.
>
> I don't find that they catch *useful* cases, but rather cases where
> work had to be done to accommodate the static typing system in the
> first place.
>
> > Said cases are more likely to occur in some programs and human
> > environments than others.
>
> I would agree, but I think that our definitions for such programs
> and environments are radically different. Mine would be the
> "absolutely must never fail" embedded code for heart monitors and
> such. Typical business apps are *not* those environments. There are
> good reasons for thinking this, too, that I'll describe below.

The humans writing the code usually determine points of failure, though.  
Humans circumvent ALL type checking; there is no perfect language.  All you 
can do is give them the suggestion, and if they want to swerve off the road, 
they're the ones taking that risk.

> > Whether Ruby should be used in environments where these errors are
> > common and avoidable seems to be the main bone of contention.
> > Optional typing (whether static, dynamic, or some combination)
> > would increase the range of purposes for which Ruby is suitable.
> > You might not want that, but I do.
>
> Frankly, Ruby is already suitable to those non-"absolutely must
> never fail" environments. What's not happening is that people aren't
> feeling comfortable with their own developers' capabilities -- and,
> I think, are underestimating them. Question: what is the purpose of
> software in a business environment? Answer: serving business
> purposes. Question: how much C++ or Java code actually *serves*
> business purposes? Answer: It depends...

I think people know how to evaluate their own developer's skills.  I've seen 
enough spaghetti code in my life to know that I personally do not suffer from 
chronic UNDER-estimation of developers I work with.

> He did this because in VB he was able to write closer to his
> business requirements without having to deal with the overhead (both
> mental and codewise) of C++. Joel's a bright man. I think that his
> lesson learned in this is *generally applicable* and is applicable
> to Ruby's situation as well.

These are good points, and it's exactly why Ruby should not force any sort of 
harsh typing restrictions on anyone.

> >> Which brings you right back to the advantages of dynamic
> >> languages as opposed to static type signatures.
> >
> > No it doesn't. It leaves you with no guarantee, but more
> > confidence.
>
> Often it's false confidence, Clifford. If static typing actually
> gave you anything of value, people wouldn't have to resort to tricks
> like (void *). As Bruce Eckels pointed out in the article I found
> earlier[1], when he tried some stuff in Python, he found that he no
> longer had to upcast. His class hierarchy was made simpler.

Confidence is confidence.  If a person moves forward and works, instead of 
fretting over what a method is going to do, they're working and moving 
forward.  If they're offered the opportunity to "give it a try" knowing 
they're likely to get a harmless error message for trying, they're working, 
thinking, moving forward.

> > But there are no guarentees anyhow - even if the software works as
> > designed, nothing says it meets the user's need.
>
> Again, I think that if we consider how much code is framework code
> in C, C++, and Java, all of the supposed advantages of statically
> typed languages disappear under the productivity killing crush.

That has nothing to do with whether or not they are statically typed, that's 
100% about the foundation the developers are given to work with when they 
begin development.  Typical C projects don't have any form of string handling 
and they make calls to memory management routines constantly.  That's a lot 
of overhead.  They basically lack a smart foundation to work with; there are 
many things missing you have to work around and that slows production down.

Java doesn't suffer from this nearly as much, so I think that's a bad example, 
but C++ definitely does have this problem.

However, I think that goes more to the implementations.  The people writing 
C/C++ compilers are compiler writers.  They typically stop when the compiler 
works, and think little about language usage.  Ruby and Python, though, are 
developed with both the parser and the language usage in mind; Matz didn't 
just write an interpreter, who wrote LIBRARIES.

It's all about this: how much time did the people who implemented my 
environment spend on giving me cool libraries to work with?

> > Nothing's certain in life, instead we must live within certain
> > confidence levels. Static typing can improve confidence levels. So
> > can thorough testing. Nothing about the absence of static typing
> > can yield these particular improvements - though individual
> > languages may have (mostly) unrelated other features which do,
> > including reduced verbosity.
>
> I'm not the only one who thinks that dynamically typed languages are
> at least as suitable as statically typed languages for business
> applications:
>
>   http://www.osteele.com/archives/2003/08/test_versus_type.html

Count me as one of them, too.  I believe in both dynamic and static languages.  
I'm glad Ruby is not becoming a statically typed language!

	Sean O'Dell