Asp Forum - Re: "stereotyping"

Austin Ziegler

11/21/2003 2:22:00 PM

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

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

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

8 Answers

Ara.T.Howard

11/21/2003 3:11:00 PM

Sean O'Dell

11/21/2003 6:14:00 PM

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

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

Hal E. Fulton

11/21/2003 6:35:00 PM

Ara.T.Howard wrote:
> tcl is the worlds greatest language, but ousterhout is a very bright guy.

Umm, is there a "not" missing from this sentence? :)

Hal

Ara.T.Howard

11/21/2003 7:56:00 PM

gabriele renzi

11/21/2003 8:19:00 PM

il Fri, 21 Nov 2003 08:11:17 -0700, "Ara.T.Howard"
<ahoward@ngdc.noaa.gov> ha scritto::

>
>tcl is the worlds greatest language, but ousterhout is a very bright guy.
>

mh.. based on this we must hope that matz is really really stupid :)

matz

11/21/2003 11:19:00 PM

Hi,

In message "Re: "stereotyping""
on 03/11/22, gabriele renzi <surrender_it@rc1.vip.ukl.yahoo.com> writes:

|il Fri, 21 Nov 2003 08:11:17 -0700, "Ara.T.Howard"
|<ahoward@ngdc.noaa.gov> ha scritto::

|>tcl is the worlds greatest language, but ousterhout is a very bright guy.

|mh.. based on this we must hope that matz is really really stupid :)

Don't worry. I am.

By the way, where should I put "not" in the above statement, Ara?

matz.

dagbrown

11/21/2003 11:38:00 PM

In article <Pine.LNX.4.44.0311211255210.31321-100000@fattire.ngdc.noaa.gov>,
Ara.T.Howard <Ara.T.Howard@noaa.gov> wrote:
: On Sat, 22 Nov 2003, Hal Fulton wrote:
:
: > Date: Sat, 22 Nov 2003 03:35:09 +0900
: > From: Hal Fulton <hal9000@hypermetrics.com>
: > Newsgroups: comp.lang.ruby
: > Subject: Re: "stereotyping"
: >
: > Ara.T.Howard wrote:
: > > tcl is the worlds greatest language, but ousterhout is a very bright guy.
: >
: > Umm, is there a "not" missing from this sentence? :)
:
: oh man - _that_ is embarassing. definitely a missing 'not'!

Which part of the sentence is it missing from? :-)

--Dave

Ara.T.Howard

11/21/2003 11:58:00 PM

comp.lang.ruby

Re: "stereotyping"

Austin Ziegler

Ara.T.Howard

Sean O'Dell

Hal E. Fulton

Ara.T.Howard

gabriele renzi

matz

dagbrown

Ara.T.Howard

x Login to ForumsZone