Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!gatech!news.jsums.edu!news2.cais.net!news.cais.net!news.ac.net!imci4!newsfeed.internetmci.com!howland.reston.ans.net!nntp.coast.net!col.hp.com!news.dtc.hp.com!hplntx!hplntx.hpl.hp.com!gjr
From: gjr@hplgr2.hpl.hp.com (Guillermo (Bill) J. Rozas)
Subject: Re: R5RS?
Sender: news@hpl.hp.com (HPLabs Usenet Login)
Message-ID: <GJR.96Mar4102338@hplgr2.hpl.hp.com>
In-Reply-To: blume@zayin.cs.princeton.edu's message of 29 Feb 1996 15:55:52 GMT
Date: Mon, 4 Mar 1996 18:23:38 GMT
Reply-To: gjr@hpl.hp.com
References: <4gc83r$617@news.simplex.nl> <4gfrfi$m7u@camelot.ccs.neu.edu>
	<leavens.824995212@larch> <4gi3p0$kvh@agate.berkeley.edu>
	<leavens.825012724@larch> <GJR.96Feb22191305@hplgr2.hpl.hp.com>
	<BLUME.96Feb27152646@zayin.cs.princeton.edu>
	<GJR.96Feb28133746@hplgr2.hpl.hp.com>
	<BLUME.96Feb29105552@zayin.cs.princeton.edu>
Nntp-Posting-Host: hplgr2.hpl.hp.com
Organization: Hewlett-Packard Laboratories, Palo Alto, CA
Lines: 171

In article <BLUME.96Feb29105552@zayin.cs.princeton.edu> blume@zayin.cs.princeton.edu (Matthias Blume) writes:

|   Because many people don't give a **** about conventions.  A comment of
|   the form
|
|	   ... ;; don't touch this
|
|   serves as an invitation to them to mess around with it.  It is one of
|   those folk myths that people `usually respect abstractions'.  And even
|   if it were indeed rare -- that only makes it even harder to find the
|   few places in a large body of code that rely on details they are not
|   supposed to rely on.

So instead you, who knows better than they do, will prevent them from
getting burnt.  Paternalism is nice for kids, but not for adults.
Yes, occasionally adults will get burnt, but it also allows them to do
things that we don't let children do.

I, and most people that I have worked with and know, place high value
on conventions.  Perhaps I have been pampered, but I'd rather spend my
time teaching people to design and observe good conventions than ways
to circumvent straight-jackets.

|   I never understood what's so beautiful about that.  I hardly ever
|   patched my programs while they were running -- even in Scheme.  Part
|   of the reason for this is that Scheme doesn't really let you do it
|   reliably either.  On the other hand I never felt the need for working
|   that way in the first place.

Well, perhaps you are much smarter than I am, but I have had programs
running for several weeks that I could not really afford to restart by
the time they got to the point where my shortsightedness/lack of
understanding became apparent.  Now you might say that a strongly
typed language might have pointed out my mistakes earlier to me, but I
rather doubt it.  I tend to spend about as much thought and effort on
type errors as on typos.  Things like off-by-one errors, inconsistent
shared data structures, non-terminating computations, race conditions,
etc. are far more devastating and I know of no simple tool that even
helps with them (not even worrying here about decidability).

|   Strong type checking can give you instant feedback about silly errors.
|   This eliminates many of the occasions where you might feel the need to
|   patch up your program later -- once it passes the compiler it works
|   and doesn't require further patchwork.

Oh, how I wish programming were so simple.  On the other hand, most of
the fun (for me) comes from learning something after finding a really
deeply interconnected bug.  I guess I don't really want
programming/debugging to become rote/mechanical, but I am quite
certain that type errors are an insignificant part of my work or fun.

|
|   People say strong typing gets in their way.  I though this to be true
|   myself for a long time.  But polymorphic type systems with type
|   inference turn out to be almost as "convenient" to use as non-existent
|   type systems.  In many cases, when I found myself struggling with ML's
|   type checker, I finally realized that my design was flawed.  Once the
|   types worked the design was basically right.
|
|   I know that I could go on like this forever without convincing anyone.
|   The same thing happened to me -- my office mate Zhong Shao was trying
|   to tell me the same things, my advisor was talking about it, and I
|   simply refused to accept it.  But then, after writing a large body of
|   code I began to appreciate the differences.  To show you how far I've
|   come around: Last year I decided to use SML as the implementation
|   language of a prototype for my "module-and-macros: variant of *Scheme*
|   (!), because I realized that building that prototype in SML would in
|   fact be much easier.

Great.  I am so happy that you have found a tool that satisfies you.
I think we are largely arguing about matters of taste, and hence it is
hard to convince each other.

My main concern is that there are mighty few languages (actually I
should really say a few mighty languages) that give me what _I_ want.
You already have ML that keeps you happy.  I don't think that Scheme
would ever make you happy again because of the other features you
would find missing even if opaque types and "fascist" modules were
added.  Hence, since (I believe) there is no way to make an apostate
like you a convert, please let the rest of us have it the way we like
it.

|      Hence I want to have ways to go beyond
|      their advertised interface, even at the risk that I will void the
|      warranty of proper operation.
|
|   The passengers of the airplane that is controlled by your software
|   might object to that attitude.

This is more of a bugaboo than anything else.

But, in the same vein, 3 months out from Earth on a Mars mission (1
year turnaround) you might feel very different if you had to rely on
the system getting back to the same state after rebooting because you
could not patch it as it was running.  That even assuming that you
could rebuild from scratch with the poor bandwidth to where your code
base resides.

|
|      I think GNU Emacs, just to give an example, is far more customizable
|      precisely because it allows arbitrary mucking around with internal
|      stuff.
|
|   Yes, and half of the stuff breaks every once in a while.  Emacs is in
|   fact really horrible.  (Mind you, I still use it all the time, because
|   I don't know of a better alternative.)

Right.  There is no better alternative because the other languages do
not lend themselves to that sort of thing at all.  Evolution does not
lead to pretty designs, but to _working_ designs.  Many are dropped by
the wayside, but the ones that succeed are pretty darn stable.
It is very humorous to me how you do not see the connection between
your desire in languages and the lack of things like Emacs written in them.

|   Also, your example doesn't hold water even if emacs were to be a fine
|   example of good software engineering.  If emacs were written in a
|   strongly typed language it could still be hacked arbitrarily, because
|   it comes with all the source code.  Strong typing would actually help
|   hacking it, because the type-checker will tell you when you do
|   something that is inconsistent with the intentions of other authors.

That would assume that I had the ability, patience, etc. to rebuild
from scratch all the time.  You might say that everyone does, but
remember, PCs and workstations do not come with C compilers, and they
are pretty costly.  I'd much rather have a system that I can patch on
the fly than have to spend $1K just to change one line of code.

|   SML/NJ is a huge program that many people have hacked.  It is not as
|   popular as emacs, because it isn't a text editor but a compiler.
|   Nevertheless, I feel much more confident changing almost arbitrary
|   internals of SML/NJ.  Whenever I change something substantial, then
|   the compiler will tell me about ALL the place affected by that change.

Really?  I'm very surprised.  Being no theoretician, I may be wrong,
but I think you are attributing omniscience to your type checker.
Last I heard the problem of determining whether a program has a bug
was undecidable, and again, your bugs may differ from mine, but mine
are hardly ever of the typo/type-mistake variety.

Finally, one argument that I hardly ever see raised is the
following:

Even when I have a type error, the type error is almost always a
manifestation of a deeper bug.  In most of these cases just pointing
out the type error does nothing because it does not point out the real
root of the problem, nor, even more importantly, give me an example
instance where my reasoning breaks.

One of the incredibly wonderful things about so-called dynamic type
checking systems is that when a non-trivial type error is met, the
system hands me on a platter a counter-example to my reasoning, from
which induction/generalization is usually much easier than from a dry
logical inconsistency.  This leads (me) to deeper understanding of the
bug, and a real fix, and not just something that satisfies the type
checker.

In fact, in statically type-checked systems I often end up fixing
static type errors with code like

if (test)			; type-case, tag-case, whatever
  do-the-work
else
  signal-error

because I haven't a clue about what to do when the condition is not
met.  Hence I've fixed the type error as far as the compiler is
concerned, but I haven't fixed the real error (if any -- sometimes it
is just that the proof is more complicated than what I can do in the
absence of examples).

Dynamic type systems do this for me automatically.
