Algol vs Java

[bren@xxxxxxxxxxxxxxxx (Brendan Macmillan)]

Hi Bob,


You're absolutely right - I meant Algo 68.
> You sure this isn't Algol 68?  It had the operator creation stuff.  I know
> that I am showing my age, but I have used (some years back) Algol 60, Algol
> W, and Algol 68 -- but I just can't remember or find Algol 66.
 
Sounds like Algol 68 was deposed for having too much unrestrained power.
Forgive my indulgence, but an example of such unrestrained power is the
apparently humble "goto" statement.  There's nothing wrong with it, when used 
appropriately, as in loops and conditional statements. But it can cause
a lot of trouble!  But I remember being surprised that everyone else also
used "loop" and "skip" labels in assembly language...  It was very sensible
to encapulate and restrain these within the "for" and "if" statement
families.  A personal fascination for me is that I also found "break" and
"continue" to be inadequate for nested loops - the only point at which a
goto was better, I thought.  And then along comes the named break and
continue, to capture the very last bastion of goto[*].

Another example is pointer arithmetic. It has been structured as references
in Java, and also in arrays, unions, and the struct of C (et al).

> Algol 68 was horrible.  It was like a language construction framework, and
> you got to build your own language.  It was like working with someone that
> used operator overloading in C++ and lots of macros, so that you could never
> figure out what the code was doing.  But Algol 68 was even worse since you
> were really encouraged to extend the language.  Everyone I knew that used it
> hated it, and it went away.
> 
> Certainly there are many features in the Algols that are in Java.  In fact,
> knowing BCPL (the parent of C -- C is just a variant), C++, Mesa, Cedar, and
> Modula, there is nothing I can think of in Java that is new (except the
> syntax and tweaking some features).  Mostly Java is the selection of the
> stuff that was out there and putting it together in a coherent package.  
What about the higher level stuff of "design patterns"?  Factories, etc.

> Now, don't think that I am saying that this is easy.  Java is my favorite
> language, by far, because I like the selection that was made.
Emphatic agreement  :-)  Matching the choices available to the choices
desired avoids irrelevant work and guides you toward the important decisions.

I wonder what the next language will be like?  Restrained power, familiarity
and efficiency are all important.  Certainly, it will retain the basic
expression syntax of C/Java/Perl; and structured statements such as "for"
and "if" to restrain power and concentrate choice; and the modularity
of classes and packages.  My wish is for efficiency: implementations that
allow direct access to the underlying machine, appropriately restrained.
An example is the pointer arithmetic of array offsets to avoid the repeated
recalculation of indices from a base[**].  Forgive me, but Perl is evolving
so fast and with such intelligent input from many sources, that from it
will probably emerge the next language; though I suspect it will not gain
wide acceptance until enshrined in an entirely new language, because Perl is
just too mad.  Gentlemen prefer Java.


Is efficiency too much to ask for, in the next thousand years?  ;-)
Brendan
--
bren@xxxxxxxxxxxxxxxxxx    +61 (3)  9587 2117     tel:  +61 (3)  9905 5194
Email is checked daily         voice mail         Phone is rarely attended
A giant puppy cannot imagine hardship.


[*].  But I don't like Java's syntax for named breaks - when breaking out of
an enclosing statement, I'd rather not name it at the top, but at the bottom.

[**].  Such restraints exist for special cases in the form of multidimensional
arrays, and arrays of classes, where there is no overlap between the data
structures.  But sometimes overlap is convenient, as when processing an array
from the first element, then again from the second element, and so on.
A union of arrays (of the same type) could do this, but it would
be even nicer to be able to specify the offset as needed.  Maybe this
is in the newish Arrays class (from the "Collections" update)?

---
To unsubscribe, mail advanced-java-unsubscribe@xxxxxxxxxxxxxxxx
To get help, mail advanced-java-help@xxxxxxxxxxxxxxxx