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.

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

The situation is somewhat better now in C++ than it used to be (with
the STL), but I know that significant portions of the production-
level C++ code that I've worked with and on that deal with memory
management and other overhead details. In some cases, as much as
*half* of the code was needed for wrangling with the language. In
Java, it's even worse, especially if you're using J2EE. There's a
book that advocates using Ruby for those environments where
management has been convinced to use J2EE or .NET that covers this
50 - 75% overhead code: _Code Generation in Action_.

What if your developers could write directly to the business
requirements without having to worry about language overhead? With
Ruby -- and other strongly-typed dynamic languages -- they can. Joel
Spolsky (www.joelonsoftware.com) wrote CityDesk, a desktop-based
content management system, in Visual Basic with Visual C++
performing necessary performance improvements or other things that
can't be done in VB. It's easily one of the best -- and most
responsive -- programs I've ever used on Windows.

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.

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

Note that strongly and explicitly typed languages like Ada aren't
actually as frustrating as C++, because they make you think about
how your types are used, rather than sometimes doing things
implicittly.

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

> 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

As Oliver Steele points out, the productivity boost *has been shown
in research*! 

-austin
[1] http://www.mindview.net/WebLog/log-0025
--
austin ziegler    * austin / halostatue.ca * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.11.21
                                         * 09.21.33