Strings and Method Names

Ka-Ping Yee
Thu, 22 Oct 1998 12:01:58 -0700 (PDT)

On Thu, 22 Oct 1998, Bill Frantz wrote:
> I think there are at least 3 kinds of languages in the world.  They are:
> (1) Write only: HP calculator language for example.
> (2) Write and revise:  C, Algol and most such are examples.
> (3) Algorithm publication:  MIX?, C with buffer overruns?

> Where in this spectrum does E stand.

I think E stands (or most of us would like E to stand) near the
latter end.  I believe it was Mark that conveyed to me a famous
quote about how one should write programs primarily for other
humans to read, and only secondarily for computers to run.

I think Python is an excellent example of case 3.  It has been
described as "just like writing pseudocode... and having it *run*".
The dynamic typing, indentation awareness, and implicit line
continuation all come together to make Python look and feel very
similar to pseudocode.  I know of no other language that really
even comes close in this respect, so i consider it "*the* language
in which to communicate" among current object-oriented sequential
procedural languages.

It is therefore important that E have somewhat similar qualities
if we want it to play the analogous role of "*the* language in
which to talk about security" -- perhaps even more important for
E than for Python, since understanding code is especially crucial
to security.  And, of course, understanding security is crucual
to surviving Singularity.  I think we want people to explain
security concepts (just like the MintMaker) to each other by
typing in snippets of E in their e-mail messages... right, Mark?

> There is one case in the E runtime where we iterate over a changing
> collection.  Consider the connection building operation.

Sure.  Sorry -- i didn't mean to say that you should never iterate
over a changing collection.  I just meant that you should never
use "for" to iterate over a changing collection -- you can loop on
a particular condition of a changing collection with "while" if
you want.  A clear resolution of the issue about "for" allows us
to define very simple semantics for "for" and leave the details of
the behaviour when iterating over a changing collection to be
explicitly written out (i.e. explained) by the programmer.