Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!gatech!news.mathworks.com!news.kei.com!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.96Mar4191050@hplgr2.hpl.hp.com>
In-Reply-To: blume@zayin.cs.princeton.edu's message of 04 Mar 1996 21:02:07 GMT
Date: Tue, 5 Mar 1996 03:10:50 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>
	<GJR.96Mar4102338@hplgr2.hpl.hp.com>
	<BLUME.96Mar4160207@zayin.cs.princeton.edu>
Nntp-Posting-Host: hplgr2.hpl.hp.com
Organization: Hewlett-Packard Laboratories, Palo Alto, CA
Lines: 209

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

|      On the other hand, most of
|      the fun (for me) comes from learning something after finding a really
|      deeply interconnected bug.
|
|   Yeah, let's make a hard problem even harder so we feel even better
|   when we solve it!

It is not a matter of feeling better.  It is a matter of learning.  As
I have said, I don't find type errors common or difficult to deal
with.  No more so than typos, and no more important.  Would you
seriously restrict the semantics of your language in order to avoid
typos?  I would not, and I view the tradeoff of restricting the
semantics to avoid simple type errors in the same vein.

The question is always, what are you trading for what?  For you the
tradeoff is worth it.  I will even grant you that to many or most
people it is.  However, for some of us it is definitely not.  We have
found refuge in languages such as Lisp and Scheme.  Now you are trying
to take away our bone... 

|   Well, you will be very hard pressed to convince me with words.  I
|   *have* tried both styles, yes, I've even been an advocate of the other
|   style myself.  But yet, I have changed my mind, because evidence is
|   mounting.

To you.  Again, it is a matter of taste, and I doubt that _technical_
evidence is mounting.  Perhaps statistics evidence, but since I am not
the average person/programmer/etc., I don't really care about
statistical evidence.  BTW, what makes you believe that I haven't
tried both?

|   Just on the side, being a German I would like to say that the usage of
|   the word "fascist" in this context is ridiculous.  There is nothing
|   fascist in ML's type system.  Abstractions (i.e., opaque types) are an
|   option, you don't have to use them if you don't want to.  And what's
|   "fascist" about ML's modules escapes me entirely.

You are viewing it backwards.  The programmer/provider always has many
options.  The consumer/customer does not if the programmer/provider
does not give them to him/her.  The ML opaque types and module system
leave all such choices in the hands of the provider/state, not in the
hands of the consumer/individual.  That is why it is fascist, because
the provider/state has all the options and it is only by his/its
condescension that the consumer/individual has any.  I believe in
consumer/human rights which the state/provider should not be able to
take away.  I think the term "fascist" is perfectly well applied here.

As an aside, even though you are German, I don't know whether you are
old enough.  I am Spanish and _have_ lived under a fascist regime,
although in its waning years.

|   In ML you have the freedom to choose between stronger and weaker forms
|   of protecting yourself.  In Scheme you CANNOT use adequate protection,
|   even if you want to, because those liberal gods of Scheme won't let
|   you...

Again, you view the choice as being in the producer, not the consumer.
I view it the other way and I would not want it any other way.

|
|      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.
|
|   Of course, go ahead.  But it must be allowed to express one's opinion.
|   Or who is being "fascist" here?

I'm not asking you to stop talking.  However, I don't understand your
zeal especially when you are already satisfied.  I'm not trying to
convert you nor trying to change ML (I'm not even on its list).  I
just want to make sure that the Scheme philosophy is presented again
and again every time it is under the barrage from the zealots on the
other side. :)

|   Aha, but you are saying you can patch it if it was written in Scheme.
|   I think, if this actually succeeds, then only by *incredible* luck.

Try me :-).  Even if you consider it unlikely it is certainly more likely
in a system that lets you than in one that does not.

|      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.
|
|   I wasn't talking about C.  Indeed, I think C is a worse choice than
|   Scheme.

No, but Emacs, which is what we were talking about, has a core written
in C that prevents me from rebuilding it from scratch.  That is why I
need it to be flexible and patchable.  I agree that Scheme is superior
to C.  I would not be so sure about ML.  At least in C I can ignore
the type system.

|   Yes, because I make sure that some signature or some type changes in
|   the course of a substancial modification.

Interesting, so then you have to change all the users of your new
module because the interface has changed.  I thought the advantage of
the opaque types that you like so much was that they hid all such
implementation details from the consumers.  No I find that you
explicitly void uses of the code.  This sounds really strange.  Can
you explain this a little further?

|     Being no theoretician, I may be wrong,
|      but I think you are attributing omniscience to your type checker.
|
|   No, I'm not.  I wasn't talking about proving my program correct.  I
|   was talking about finding all the places that rely on one particular
|   previous design in the case that I change that design.

Not really.  I view what you are doing as no more complicated than
doing a search when I change the spelling of something.  How do you
handle true differences in invariants that are not reflected in the
type system?  If you tell me that all invariances are reflected in the
type system I will have to laugh.  How do you guarantee that the input
is really a prime number?  Having a prime type is useless.  How do you
guarantee that Fermat's "last theorem" is true (assuming that the
proof has not been finished) if your code depends on it?
Shallow-semantic type systems such as those in ML don't help you with
anything really hard.

I really believe that what you get out of such type systems is no more
useful (as useful as it may be) as a spelling checker.  However, a
spelling checker does not limit my expressive power.

|   Oh, now you are asking for omnipotence of the type system!
|
|   An error pointed out during development is millions of times better
|   than a runtime bug that occurs during normal operation, because in the
|   latter case it can be too late and in extreme cases people could die.

That is an exaggeration and you know it.  I would no more trust a
controller because it was written in ML than if it was written in
assembly language, and I doubt you would too.  Rigorous, comprehensive
testing is the key, and I doubt very much that any trivial type error
will not be found that way.  The other errors, the hard ones, you will
not find without such testing (and perhaps not even then).  Those are
the ones that are likely to cost you a lot to fix.

|   True.  The only problem with this is that it is undecidable whether
|   this kind of deeper understanding will be achieved before your program
|   is delivered to the customer.  Of course, static type systems *are*
|   less expressive than dynamic ones, nobody is arguing otherwise.  But
|   still, I claim the static type system is actually more useful, because
|   you will get your error message at a time when you still can do
|   something about it.

Assuming that you can comprehend a humongous program statically in
your mind.  I venture to say that a 200+ page program cannot be
comprehended by many people, hence a mere flag of a logical
inconsistency (even if not merely an artifact of the type system)
is not helpful.   Everything interesting is undecidable, and that is
my point.  Your type system cannot solve anything interesting by
definition.

|      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.
|
|   Ah, the ostrich approach -- if you don't see a type error you don't
|   worry about it...

No, it is because I'm trying to generate an example because after
_thinking about it_ I still do not understand what the problem is.

I am an engineer, a tinkerer.  I try to insert probes and look at
things before I make a determination.  Even when doing mathematics I
gain far more insight by carefully examining examples than by thinking
abstractly.  All the best programmers that I know operate the same
way.  The problem with static type systems (and the richer the harder
the problem becomes) is that they require me to fix the problem in the
absence of _any_ examples, in the presence merely of an arbitrarily
complicated logical inference.  I'd much rather have the
counterexample to my reasoning.

Yes, I'm not guaranteed to find it before shipment, but neither are
you for any non-trivial bug.  That's why thorough testing is
important.  However, static type systems attempt to force me into what
I consider an artificial and bad methodology, namely to examine such
logical errors in the absence of examples.

|      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).
|
|   True, you just used the Scheme solution explicitely.

Right, which is rather silly, isn't it?  I claim that for any
moderately complicated program half of the code would be of the sort
that you find above.

|      Dynamic type systems do this for me automatically.
|
|   Sure, but I don't believe this is a good thing.

But I do -- it saves me lots of typing and from fruitless difficult
thinking.
