Re: The revolution will not be standardized

[Robert A Duff <bobduff@world.std.com>]

Robert Dewar <robert_dewar@my-deja.com> writes:

> It is well known that complete portability can be achieved
> with high level languages, the kind that people usually regard
> as interpretive languages, e.g. SNOBOL-4. [side note, the work
> on SPITBOL shows that it is possible in fact to compile such
> languages successfully].

"Complete portability" is impossible.  Different machines run at
different speeds, and have different amounts of memory.  Clearly the
speed at which a program runs, and whether or not it runs out of memory,
are user-visible properties.  But it is clearly impossible to define
them portably in a language standard, so of course no standard tries.

Of course, I know what you mean -- you mean *assuming* we don't run out
of resources, we can achieve complete portability, at the expense of
efficiency.  Fine.

Also, I think it is impossible, or at least infeasible, to achieve
portability with respect to interactions with the outside world that
depend on timing.  Any program that has a delay statement in it is
potentially non-portable, as is any program that uses true parallelism.
Any program that depends on the timing of mouse clicks or keystrokes is
potentially non-portable.  SNOBOL-4 isn't a multi-threaded language, if
I remember correctly.

Most of the computer science theory I learned in school imagined a
computer program as taking some input, grinding upon it, and then
printing out the answer -- a Turing machine or equivalent.  But real
programs nowadays interact with the outside world over a period of time,
which is a different thing.

> My feeling about Java is that it falls between two desirable
> points, and thus is a bit of a failure in this regard.

Yeah.  For example, it's strange to force almost everything into the
heap, and require garbage collection, and require growable arrays, but
then not have growable (arbitrary-range) integers.

But I actually don't think a language design *has* to choose a point on
that spectrum.  It can support many points on that spectrum.  Kind of
like Ada has chapter-13-ish kinds of stuff, but also allows you to
program at a much higher level when you so desire.

> If you want to take the hit for 100% portability, then do it
> properly, and produce a proper high level language (something
> with the flavors of SNOBOL4, SETL, APL, PROLOG, ABC, Python).

Well, I don't really want 100% portability, even in the sense of
ignoring timing and memory use and so forth.

The trade-off between efficiency and portability is an engineering
decision.  What I would like is to allow the programmer (rather than the
language designer) to make that decision, and to make it differently in
different parts of the same program.  In other words, I don't like (say)
Ada because it forces me to use efficient, machine-oriented,
error-prone, non-portable integers all the time, but I don't like (say)
Smalltalk either, because it forces me to use inefficient, portable,
safe integers all the time.  What I want is a language that gives me the
choice.  And I don't want to bias that choice against portability.  Of
course you *can* do arbitrary-range arithmetic in Ada -- it's just a
huge pain for various reasons.

> Don't end up with a low level machine oriented language which
> still has 32-bit wrap around integers :-)

I agree completely about integers.

But I was thinking of things like order-of-evaluation of actual
parameters.  In that case, Ada allows bugs to lurk where Java eliminates
them.  And I'm not convinced it *needs* to cause inefficiency.

- Bob

P.S. What would happen if this thread were cross-posted to
comp.lang.java, or comp.java.advocacy or whatever it's called?  ;-)