Resolved: NOT. --WAS: Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming:OOP and memory management)

From: cstb (jas_at_cruzio.com)
Date: 08/21/04 

Date: Fri, 20 Aug 2004 20:40:35 -0700
To: khall@acm.org

Kelly Hall wrote:
>
> Jeff Brooks wrote:
>
> > So you assume that most people make type errors? I think you actually
> > mean "i strongly advocate beefier static checking".
>
> No, I don't mean that except as a side effect of having more robust type
> systems. I certainly want more errors detected at compile time, and I
> advocate reaching that goal through beefier type systems.

Two problems with this:

#1) Where's the beef?
#2) Mad cow disease.

> I think people make a lot of errors. I think if type systems were more
> expressive, programmers could define and use types that capture more
> details of correctness than the current type systems. If programs with
> these rich types were then type checked statically, more errors would be
> caught at compile time.

I agree with the first two sentences, but the last
is a tautology, and a fine example of (#2), no offense.

Catching errors at a specific point in time is not
a very good criterion -- the conditional is overly
strict -- it is necessary that errors are caught
prior to customer delivery, and sufficient that
errors are caught prior to any unacceptable
increase in the net cost of getting them fixed.

If there is more than one such approach available,
and some approaches get excluded by an overly strict
conditional, then one is forced to conclude
that one is either:
  a) using the best approach by shear luck
or
  b) flushing potentially useful power
     right down the drain by shear neglect.

So, it is ok if errors are caught at compile time,
as long as the cost of doing so is acceptable.

Many times, and this is one of them, the cost
  {which is extraordinarily high - more on that below}
is only acceptable if there is no alternative,
  {there is at least one}
and if the "errors" are legitimate (i.e. fully constrained)
  {which they are not}.

  
>
> As an example, why can't I define a subtype of positive integers that
> are even? Or that are odd? Or that are prime? Or that are relatively
> prime to two other integers? I can't because most type systems are
> pretty weak. Mostly because type checking algorithms are extremely stupid.

Technically, you can't because "positive even integers", etc.
are not proper subtypes of anything you would otherwise have
a use for. Most of the time. That I can think of.

If you dump the "subType" constraint, and just want
to define the type "PositiveEvenInteger", you certainly can.
But I can't think of a use for such a thing where compile-time
checking would have an appreciable value. The closest thing
I can think of that compile-time checking of this sort of thing
might produce wins for would be a continuous subrange of positive
integers, so that MS could use it to do bounds checking against
buffer overflows.

But even that need is a carry over from the procedural point of view,
in which you were "speaking" to raw memory addresses and needed
to markup all your accesses with "intentionRevealingTypeDefs"
so the poor disembodied code could be kept 'in bounds'.

As soon as you adopt an OO point of view, the entire
problem de-materializes, because you *cannot* speak
to raw-dumb-do-with-me-as-you-please memory addresses
anymore. The object knows how big it is, and what operations
are defined on it, and how to do them correctly, and whether
or not it is itself still in scope, etc.

[ Note: that was an OO, not just an OB point of view].

>
> > Most warnings are not related to type checking.
>
> Maybe when you write code. When add 'use strict;' to my Perl programs,
> I get a fair amount of warnings that almost all relate to misusing a
> list or a scalar where the other is expected. I call that a type error.

Right - it is a type error.
It occurs when the programmer is using a procedural POV
in a procedural language, or in an object based language.
Perl, depending on which version and how it is being used,
is either procedural, or {I'm stretching here} object based.
It is definitely NOT OO.

> Given a richer type system, I hope to get more errors detected as
> type errors and less detected at runtime.

There you go again - mixing up the constraints.
Yes, a richer type system can detect more errors as type errors,
rather than as "the code began operating on a memory address in
some inappropriate way that is impossible to recover from. Abort."
errors. Definitely a good thing.

Whether this happens by some external, alien force
sending scanning beams from afar while time is stopped,
and everyone sits frozen in suspended animation until
the scan completes and the entire system is certified
"type safe", or happens with the aid (and full power)
of local and/or non-local but always internal processing
isn't really important, unless they produce different
results. If they did, you'd have to weigh in on the
desirability of each aspect that differed.

OOPS - they produce different results. Now what?
Better list the differences, and weigh in on each.
Let's see,
  Classical mechanics - relatively simple, pretty accurate,
                           but impossible to get transaction
                           semantics to work, and no polymorphism.
  Relativistic mechanics - solves the transaction thing, not as simple.
                           gravity gets really complicated. good
results.
  Quantum mechanics - enables polymorphism. useable, but impossible
                           to actually understand what's going on.
                           gives excellent match to experiments.
  I'd have to pick Quantum mechanics.
  How bout you?
Oh yeah - this is supposed to be languages.
Well, same idea. List the differences, weigh in.

But - before doing that - let's take a big ol' SWAG
as to whether static analysis over the artificially
constructed language of typesAsShorthand is more
likely or less likely than dynamic analysis with
fully reflective access to direct execution,
accumulation of executional state, and the entire
operational grammar of the language under analysis
to be the one which produces the richer, more
powerful set of outcomes?

[ Hint #1: The *best* you can do with static analysis
           over a reduced grammar is to get the
           same answer, but with less computation
]

[ Hint #2: We've already agreed that the answers
           produced by the two approaches is different
]

 

>
> > You still have to test the logic. If you test the logic you also test
> > the majority of the type usage in a dynamic language.
>
> As I've said, I'd prefer to express more of the correctness of the
> program in the type system, and let the compiler/prooftool prove that
> the code is type safe. Given a sufficiently rich type system and formal
> specification language, I can eliminate most of the testing.

Absolutely. Well, that may be a bit too strong.
One can certainly eliminate *much* of the testing.

How much?

Well, in theory, one could do even better than, say, Smalltalk.
If one were to add the ability to (optionally) annotate formal
parameters according to the [first class] protocol they are expected
to support, you could do some pretty interesting things in the area
of proof tools. Such ideas have been touched on (see e.g. Strongtalk),
but haven't made it to mainstream usage and further exploration.

Unfortunately, too many people are stuck in a world of goofy notions
like "C++ and Java are OO languages" and so consequently miss
the entire point. Which would be ok, to each his own, and all that,
but it drains SO MUCH RESOURCE from the world that there are very few
resources left to spend on making actual progress.

Sigh.

Maybe someday, some more people like you, who care
about correctness proofs and other "high minded" notions,
will learn enough about OO to start demanding that they
use it, get to use it, spend money on using it, and something
more than just sustainable persistence funding will shift toward
something that matters, like "better tools" that are actually
"better than the previously best available", instead of just
"better than the horrid bs we had to use yesterday, because
we didn't, and still don't, know any better".

> Catching programming errors when the code is running on your desktop may
> be fun and interactive. But I develop embedded systems, and I have no
> desire for my end users to catch runtime errors.

Non-sequiter. The two are not related by any
mechanism known to man. Modern man. Ok, some people
think of themselves as modern, and they have mechanisms
by which these phenomenon get inextricably linked.
But that goes back to your earlier statement
about how often people make errors. ;-)

As an aside: Do people actually believe that
             these are the alternative outcomes
             being debated? I.e. Do people
             actually believe that the OO crowd
             is simply ignorant of the potential
             benefit of static analysis?
             Or that we're just those slugs who
             still deliver crap software that
             blue-screens on our un-sophisticated
             customers silly enough to buy the ol'
             "can't help it - software is hard"
             routine?

> The more errors found by the compiler, the better IMHO.

Sure. As long as it doesn't cost too much.

If you're willing to use ancient artifacts
like non-OO languages, you're probably stuck
with that anyway. But if you ever get the
choice, I recommend trying an OO language,
just for grins, and actually comparing the
results. I have yet to meet anyone who has,
and who wasn't afterwards completely and
thoroughly **stunned** by the actual magnitude
of the difference between what he thought,
and what he is now beginning to realize how,
he understood.

Sorry about the rant.
It's just difficult to even begin to comment
on an argument as absurd as this thread becomes,
every time it resurfaces. But some of it may
be helpful to some people, so occasional attempts
to contribute seem warranted.

Maybe some numbers are useful:

I did a three year study (early 80's) on the benefits
of static type checking, during the development of an OS.
I recorded actual errors caught vs. "pretend errors".
The compiler allowed one to switch off all type errors,
flag them as warnings instead, and continue with code
generation. All execution errors were recorded, and
tracked against static type check errors, noting whether
any type check anywhere in the system would have prevented
the occurrence of the eventual error.

End result:

500K lines of code.
534 "warnings" (type check errors).
1 "actual error" in execution.

The actual error was a single occurrence of passing
an "incorrect" type AND getting incorrect code generation
as the result. In other words, exactly one runtime error
was tracked to a type-check warning which would, if the
warning had been heeded, have prevented the execution
error. (The error in question was caught in testing,
not by customers. It *was* difficult to find. Had it
been written in Smalltalk, the error would have triggered
a runtime exception, approximately 7 seconds after the
code which contained it was written. Instead, it took
half a day to debug). Over the life of the project,
all of the remaining errors were logic errors - the code
would work as "expected", it was just wrong. All such
logic errors were caught in testing. Zero errors were
detected in the field (i.e. by customers).

Granted, I get *far* more DNUs these days than one in
three years - but that is primarily due to the fact that
I experiment more, and spend more time developing with
a technique which causes DNUs on purpose. In any case,
they each result in a lag of ~7 seconds between the
code being written and the runtime error which results.
[ It could be gotten down to ~2 seconds, but on average,
  I drink a little coffee after writing and before testing.
]

Ok - there's my empirical evidence.
Let's see some other numbers...

Regards,

-cstb

Relevant Pages

  • Re: GMP vs. straight C arithmetic
    ... ordinary data structures that don't impose an additonal performance ... Side-effects are another crucial part of the language. ... > Take the tree structure example I gave earlier. ... determined at compile time, is this a compile time error? ...
    (comp.programming)
  • Re: Teach myself C++.
    ... That seems to be an objection to the quality of implementation of ... The language IS the compilers. ... should be possible to compile some code more than once, ... I'd say that string handling is something most other languages get ...
    (sci.crypt)
  • Re: censored by comp.compilers [was please suggest an OS and language a text]
    ... It's only when I speak to people who think UNIX and Windows ... or year or a whole career accomplishing nothing but mediocrity. ... the language design is arguably less elegant, but partly because the language wasn't aiming to be "simple" or "elegant", but rather to try to look and act more like traditional "industrial strength" languages. ... this is mostly related to the hassle of having to compile the C frontend's ASTs into the current bytecode, and deal somehow with the issue of "the mountain of crud pulled in from the headers", which given the current VM design would be a bit problematic. ...
    (comp.lang.misc)
  • Re: Original Macbook OS died. now no space on HD but also no way to rebuild?
    ... It is very easy to learn to write a program using .net or java. ... learning any language takes longer than a paragraph. ... programming environment is much easier to learn compared to modern ... could compile Java at all. ...
    (uk.comp.sys.mac)
  • Re: dynamic vs. static: the age-old debate
    ... necessary to compile a program, ... inseparably related to either dynamic or static typing, ... otherwise static language, and with similar effort, can write a largely ... I have the feeling you are not separating semantics and implementation; ...
    (comp.lang.misc)