[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why would anyone want opacity?

In-Reply-To: ozan s. yigit's message of Tue, 14 May 96 23:12:34 -0400

> > you seem have a habit of making arguments ad-hominem.  I will not
> > otherwise reply to this.
> so what is ad hominem in saying your argument seems to ultimately boil
> down to everything you have internalized and therefore prefer?

Some people use "ad hominem" in a fairly general sense, while
others restrict it to something like personal attacks.  Whether
that's what's behind your apparent disagreement about its application
in this case I don't know.  Anyway, the ad hominem element is that
you're directing our attention to GJR, rather than treating what
he said as independent.  To quote a handy net source:

   This fallacy can also be used as a means of rejecting a conclusion.
   For example:
     "Of course you would argue that positive discrimination is a bad
     thing. You're white."

However, you've raised an issue that it is legitimate to raise,
for surely our views of the relative merits of programming languages
are influenced by what we know and are used to.  For instance, some
people will point out that their view of ML changed greatly once
they started making serious use of it.  Another point that's 
sometimes made is that Lisp-like syntax should not be judged
by 1st impressions.

But one has to be careful here.  For instance, I've internalized an
awful lot of C and other languages over the years, yet I still prefer
Lisp; and this was so even when I had used the other languages more
than Lisp and knew them better.  Another example: I think it was
Richard O'Keefe who once replied to a claim that he was just giving a
personal preference about (Prolog) syntax by saying that couldn't be
so because he actually preferred a different syntax.

> i do not see
> what precious distinction you think you are drawing from the constraints of
> these two languages. perhaps i do not know enough about ML. it is strange
> that it gets everyone's goat so much so that gerald sussman mows down
> those "intellectual crutches" and you talk about educating "thinkers
> instead of idiot savants who cannot think" etc.

The earlier exchange went like this (with my remarks non-indented):

  (Standard) ML as _a language_ is defined with a particular static type
  discipline -- programs that violate it are illegal. 

  i unfortunately have not seen the language definition. do you remember
  offhand how it is specified exactly?

I just tried to look this up.  However, the idea that someone
might actually want to get _in_ to a library doesn't seem to have
caught on very well around here.

In any case, there are certainly a number of implementations that
won't run programs that fail to pass the type checks.  I doubt
that any language spec forbids implementations that run programs
that have something wrong with them.  But the ML definition
specifies type rules.  They are part of the language, and it
would be odd, at least, if programs that violated the type rules
were still considered valid ML.

                        The constraints
  are in the language, not in the tools/implementations.

  all languages are defined with constraints, and in able to express anything
  useful in them, you have to work with those constraints. so what is special
  about that? maybe you just mean "constraints different than the ones i know
  and love" and that is fine of course...

His point is that the type system isn't something specified by a
tool that you might or might not use (as it might be for current
Scheme).  Instead, it's part of the language.  And he's not objecting
to all constraints in languages, just to certain ones.

The difference between ML and Scheme here should be fairly clear.
If there were an ML-style type-checker for Scheme, available on
the net somewhere, Scheme programmers could completely ignore it;
and this is so even though there are still type rules, of a sort,
that _are_ in Scheme.  All conforming Scheme implementations will
run their programs, provided the programs follow the Scheme rules.
That they fail to follow some additional ML-style rules does not
change this.

ML programmers, on the other hand, need to follow the ML type
rules, or they'll have trouble running their programs in at
least some conforming ML implementations.

-- jd