Ppooko says "Dammit, stop being overly prescriptive." (was: Re: [E-Lang] An Attempted Restatement of Hydro's Semantics)

[zooko@zooko.com]

 Tyler wrote:
>
> And hence the existence of Source#inspectWith()...
> 
> This particular example really isn't all that great since the data 
> should've been stored in a map. The general problem does exist though, so 
> that's why inspectWith is in the interface. You are still scuppered if you 
> want to do more than 2 at a time. I haven't ever needed to.
> 
> This probably isn't common enough to require syntax support.


I am feeling despair.  It seems that the E gurus (not just Tyler) are infected
by a desire to prescribe the behaviour of their programmers as much as
possible, rather than to do so as little as possible.  If this is true, then it
ineluctably points E down the path of a thousand beautiful failed languages
like Haskell, Sather, etc. etc. etc., instead of down the path of successful
languages like C, C++, Java, Perl and Python.

Ppooko, and 99% of the other C, C++, Java, Perl, Python programmers in this
world, sign off and go back to getting serious work done in non-prescriptive
languages, when you start saying things like "Why do programmers really *need*
to be able to index into arrays, anyway?".

Now Ppooko may well be wrong.  Maybe he doesn't *need* to be able to index into
arrays.  And maybe he doesn't need to have any side-effects at all, in which
case he should be using Haskell, or maybe he doesn't need to do anything which
isn't statically proven to be Design-by-Contract-compliant, in which case he
should be using Sather, etc. etc.

But the fact is, Ppooko and his myriad brethren are *not* going to stick around
to find out whether they really needed to index into arrays or not -- they are
going to go back to using one of the Big Five languages (or new challengers
like Ruby and C#), which allow them to do what they *think* they want to do.

(By the way, high-powered iteration with closures is apparently one of the
very shiniest arrows in Ruby's quiver, judging from the many pages devoted to
it in the Ruby book.  Nonetheless, nobody in Ruby land is blinkered enough to
think that they can get anywhere by offering a language without an array
indexing iterator.)



I regard the entire immutable-collections discussion with the same cynical eye.
Granted there is a legitimate security issue in there, but as far as I can tell
it applies to much more than just collections and so forcing everyone in the
world to use only immutable collections won't solve it anyway.  My suspicion
continues to wax: if one can't write secure code using mutable collections,
then the world is not going to see any secure code this decade, because
programmers are *not* going to switch to immutables-only on top of all the
other lumps they've already been asked to swallow (even including, if I may,
the trivial detail of "where's the DOT in method invocation??").



Time permitting, and assuming that my confidence in the whole E enterprise
doesn't continue to wane, I would like to discuss the security issues that have
been raised concerning mutability, adding authority when "subtyping", etc., but
I think we should start from the assumption that E v1.0 is going to ship with
array-indexing syntax, with mutable collections, and with anything else that
programmers think that they need, and it is going to ship soon, and the
discussion about security issues is aimed at minimizing the danger of these
required features or at making sure we don't preclude future improvements, not
at designing a language in which it is as hard as possible to write insecure
code.


Regards,

Ppooko and Zooko