Side-effect free containers for E

Marc Stiegler marcs@skyhunter.com
Thu, 10 Aug 2000 10:38:10 -0700


> > As long as E
> > supports styles of
> > programming that enable security for applications that need
> > it, I believe it
> > is okay for E to support styles of programming that don't
> > prohibit insecure
> > styles for applications that don't.
>
> I think Javasoft would say the same about Java. Why are we making E?

Well, we are telling the truth when we make this claim, JavaSoft isn't :-)

>
> >From my perspective, the whole point of E is to facilitate, and
> encourage, writing secure code.

I have also found E great for facilitating the development of deadlock free,
high-performance (optimistically computing) distributed apps wherein there
are no security considerations. This is off-topic but is worth remembering.

> The main difference that we're talking about is that instead of:
>
> container add(new_element);
>
> you have to write:
>
> container := container with(new_element);

This sounds promisingly close to falling off a log, though I find the
syntaxes markm has proposed in later emails unacceptable. If we can find the
right syntax, I guess I can probably agree with your proposal...though the
banishment of the traditional "a[1] := 2" syntax just has to be a nasty
shock for conventional programmers. At the end of the day, I still would
prefer that E allow this syntax as well as allowing other more sensible
things.

I realize upon writing the above paragraph that this means I would like to
see E support a more robust set of immutable containers (Tyler, another
thing you were right about, it is a pain switching back and forth between
mutable and immutable containers as I toss data over the line in a
distributed application). And I further realize that the mutable containers
could be downgraded to the point of only supporting array-like containers
and still get the full comfort effect. I believe this may be the place where
E should land, sort of halfway between my original stance and your stance:
stronger immutables and weaker (but allowed) mutables.

I observe philosophically, Tyler, that thee and me seem destined to take
opposite sides in a general case,  the case in which there is a language
feature that we consider "bad" (mutable containers in this case, inheritance
the last time) but which are things that conventional programmers expect to
see in their languages. You come down strongly on the side of "forbid it", I
come down strongly on the side of "allow it, but do not make it the only
possible way to solve a problem, go to great lengths to make E look and feel
comfortable, we have enough shock value in E already".

Taking one of your lines out of context from the last email (but not, I hope
and believe, so much out of context as to be a misrepresentation),

> I think that such surprise would be a good thing.

This is the fundamental place where we disagree. If we want to surprise
people, we can give them Joule. Unfortunately, they will throw it back at us
(sorry, dean).

Both inheritance and mutable containers can be dealt with in programming
shops that need to worry about it by using policy rather than language
enforcement--as long as we supply good alternatives. Using policy in the
case of mutable containers and security, this is going to be one of the
easiest parts to follow of the security policies they will need to write
secure code anyway.

Taking yet another tack on explaining my philosophy, I have long argued the
following concept:

"If you want to get people to do something the right way, you have to make
the right way the easy way."

It seems at first glance there are 2 ways of making the right way the easy
way: forbid the wrong way, and simplify the right way. History demonstrates
that forbidding the wrong way doesn't work half as well as you might expect:
people will find a way around the constraint you impose (in this case, by
using Java instead of E).

Simplifying the right way works vastly better. And if you do a good enough
job simplifying the right way, the fact that the wrong way is still allowed
doesn't make any difference: they'll use the easy way which happens to be
right. This is how, in the end, the programming world stamped out the GOTO
statement, by making other things that were easier even though GOTO was
still allowed in the languages.

I have already seen this strategy work in E, as it happens. E does indeed
allow inheritance, there is syntactic sugar for it. But despite this, though
I have now written thousands of lines of E, I have never used inheritance
once. Furthermore, this is not because of a personal policy to never use it
(I don't object to inheritance even a tenth as much as others on this list).
Rather, I haven't used inheritance because delegation is so easy. Even more
strongly: I have never even thought about using inheritance because
delegation is so easy; delegation meets the criterion, "like falling off a
log". I remember waking up one day after completing the Edesk app and being
surprised and amused that I'd never even thought about inheritance. I had
consistently chosen the easy way, which happened to be the right way.


--marcs