[e-lang] RANT: Taming considered harmful

[Kevin Reid]

On Apr 26, 2007, at 13:11, Constantine Plotnikov wrote:

> 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.

I partially disagree. As I explain below, I think that taming has its  
place, and that it is not absolutely bad for standard library design.  
However, we certainly should give thought to designing interfaces  
which are best for E, and taming does somewhat distract from that.

> ...
> 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.

E-on-Common-Lisp provides file access objects which behave like the  
objects E-on-Java provides (which are java.io.File after taming and  
sugaring).

The code in E-on-CL which provides file objects would need to exist  
regardless of what the chosen file-object protocol is -- whether its  
origin is derivation from Java or original thought.

Providing some service S via taming of language A does not mean that  
the implementor of S in language B necessarily has to do more work  
than if S were designed independently of A.

The result of the taming-and-sugaring process is a protocol which  
necessarily has the same conceptual internal state as the original  
Java objects; *if* that aspect is good enough, then there's no reason  
not to use a protocol just because its origin is in taming.

(It happens that I think the conceptual state that java.io.File  
provides *is* flawed in at least one way: if the operating system  
allows references to files which are stronger than pathnames, then  
they ought to be supplied to E programs. For example, a reference to  
a single file which has no effect after the user deletes that file.  
In the current world, granting a <file:///blah> gives permanent  
access to whatever lives under that pathname, and I think that is  
undesirable, as all practical grants must therefore be revocable or  
otherwise limited duration.)

> 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.

There is nothing about the current situation that prevents us from  
designing and implementing these APIs incrementally. If you want  
them, I suggest you propose them. As an E implementor, I'm interested  
in having good E-styled interfaces for primitive services, and I'll  
even implement them in E-on-CL experimentally.

> 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.

I don't think this is really related to taming; the bug was due to E  
implementation code /making use of/ mechanisms which I had thought  
were used only for Java compatibility. It was an implementation bug  
that happened to involve Java types, and not a consequence of  
exposing tamed objects to E.

> 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.

I have often used E-on-Java for working with with specific existing  
Java libraries. I get to use already-written libraries while using a  
sane language and concurrency system. I wouldn't want the existing  
taming mechanism to go away even if every 'standard library'  
component didn't use taming.

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>