[e-lang] RANT: Taming considered harmful

[Constantine Plotnikov]

I guess it is the time to write my own "considered harmful" essay :).
I'm going to target taming as a language design pattern. The more I
think about taming idea the less I like it. I think that taming is
harmful to E development and possibly to Joe-E development (I know
much less about Joe-E). If the situation does not change, these
languages will have no legs to stay on their own. They try to stay on
Java-branded crutches, so their own legs suffer from atrophy.

The core idea of taming that every E program including mobile code has
to underlying platform and we can somehow filter out safe from unsafe.
It saved E language developers from pain of creating a rich class
library for E. That is a good thing.

However this is a bad thing as well. E does not have a stimulus to
develop own class library and own API that is based on capability
security and message-passing models. If some functionality is needed,
we can just tame one more class in a declarative way. However E is a
language that is different from Java. So API that is good for Java, is
not necessary good for E. For example E has a very nice asynchronous
message-passing model. Java is not aware of this model. It actually
does not have a unified asynchronous model at all (as exercise, one
could try finding a common API theme among java.util.concurrent, AWT,
and NIO).

Also for some weird reason, Java API is missing on Common Lisp
platform (at least on dialects that I have checked). Therefore E
program that depends on java.io.File will not work on Common Lisp E.
The Native-E situation is not much different either.

I suggest treating Java platform as completely unsafe thing. It is not
under of control of E runtime. Even features that were safe yesterday
might stop to be safe tomorrow.

I think that E deserves own rich class library that supports IO
operations, user interface toolkit, and other nice to have API. These
libraries will require a time to design to make sure that API provides
safe to use abstractions. Implementing these abstractions safely using
Java, common lisp, C or other unsafe library would be another
challenge. But I do not see a way around it.

Normal E programs should not be aware of the fact that Java is
underlying platform. If standard language library miss some feature,
the program will have to create a wrapper API that is platform
dependent. This platform dependent wrapper might be re-implemented on
some platform provided that it supports required operations. The
situation will be similar situation with Java and JNI or C# and unsafe
code.

Recent swtGrid discussion is a symptom of this atrophy, why on the
earth a developer that use E programming language has to deal Java
data type coercion. And why he has to work with SWT rather than with
something E Widget Toolkit.

Using E as scripting language for Java is a somewhat strange thing
anyway. Developers get neither full power of Java platform since some
API are not accessible, nor they get a safety and clarity of E since E
allows for more elegant and safer API then offered by Java.

Constantine