Re: Idle musings on doing E over again

The ideas represented by E would have a bigger impact if they were 
embedded into a popular language, especially if that happens before 
major adoption of the host language occurs.  People probably know the 
counterfactual story about how capabilities almost got into Java (MarkM 
and Agorics associates were contracting to Sun Labs when Live Oak was 
turning into Java).  In the interest of time, Java was instead rushed 
out with the unwieldy security ACL security.properties (it was a 
milestone for security in a widely used language, but it left much to be 
desired.)

Scala is really taking off now; it is transitioning from pioneer to 
early adopter stage, as evidenced by use in multiple open source 
projects (Spark, Scalding), frequent mentions on blogs, an online course 
(coursera.org has a free undergrad level class taught by Odersky which I 
am taking now), and 5 recent books (sample chapters available at 
manning.com).  Any primary security mechanism introduced for Scala at 
this point has a good chance at becoming a de facto standard as the 
adoption grows.

Trend:
http://www.google.com/trends/explore#q=scala%20sbt&cmpt=q

Scala is a shoe-in for server-side Java programmers who prefer static 
typing (who wants to write unit tests specifically to fill-in for lack 
of static typing?), and want something more expressive with less 
boilerplate, but it also has nice interactive REPLoop, functional 
composition features with early and late parameter eval (reminds me of 
Scheme), first-class functions, type inference, operators, traits, a 
very rich collections library, and some language features inspired by 
Haskell.


Paul


On 20121001 7:44 , Kevin Reid wrote:
> On Oct 1, 2012, at 5:42, Thomas Leonard wrote:
>
>> Hi Kevin,
>>
>> If you want feedback from users, these were the main problems for us:
>>
>> 1. VatTP not using standard TLS libraries -> security risk due to lack of
>> updates.
> As far as I know, The Plan Always Has Been to move to standard SSL/TLS/whichever-it-is-HTTPS-uses plus key checking; it's just that nobody has gotten around to implementing this in all these years. Certainly a new from-scratch implementation would take advantage of the latest libraries.
>
>> 2. CapTP "ping-of-death" vulnerabilities due to pipelining: e.g.
>> server<-getVersion()<-pow(2147483647).
> E has always intended to support mobile code, which by definition may hang the target vat. However, I have considered the possibility of locking down unserialization by defining a subset of all messages, which is those which are processed in time linear in the input size. Such a subset, plus application-specific messages, might well solve this problem, but I have not yet tried to actually implement it.
>
> (Tricky part of defining such a condition coherently is reference cycles in the input.)
>
>> 3. Lack of a framework for persisting and reviving database resources
>> (timeMachine not useful; had to build our own).
> This strikes me as the sort of thing which would necessarily be application-specific. Can you describe what you think would be generalizable?
>
>> 4. Lack of static type-checking (Java developers are used to the compiler
>> checking things for them).
> I would hope to have a compiler smart enough to do inlining and allocation-elimination optimizations. There'll probably be enough information to issue "this will necessarily crash at runtime" warnings -- but this is an implementation feature, not a language feature, and I'm currently largely thinking about language features.
>
> What type of static type system do you have in mind?
>
>> Lack of a proper record type is related.
> Ah, I am very much in favor of including a record type. However, I'd just like to check — what is a “record type” to you?
>
> This are the features I am thinking of for the “record type”:
> • like a Map, but exposes its keys as methods/accessors, not subscripts
> • optimized for many records of the same shape (key set) with few entries
> • can express a subtype which is “records with exactly these keys”
> • can be pattern-matched
> • automatically provides mutable and immutable variants, 'with' copy-and-mutator operations, and zippers
>
> These are the use cases I want it to serve:
> • algebraic data types
> • named parameters
> • multiple return values
> • possibly syntax trees
>
>> 5. Performance (especially start-up time). Static type checking would help a
>> lot here, I think.
> Startup time is certainly something I intend to keep in mind. It is relevant to two use cases I am particularly interested in supporting better than current E does:
> • code in web pages (the common form of distributed computing)
> • command-line utilities and other programs following the launch, do something, exit pattern.
>
> I believe most of the startup time in current E implementations is in loading code (improvable by precompilation, if you have a place to stash the compile output) and in creating the objects in a vat (improvable by keeping the core code smaller and improving execution speed).
>
> Could you explain how you expect static type checking to help startup time?
>
>> People complained a bit about the syntax, but I don't think anything else
>> would have been better. If it had been pure Java, they'd have had to learn
>> the same concepts. Personally, I think it's very good.
> I'll keep that in mind. For what it's worth, most of my wilder syntactic ideas have so far produced terrible results when I try to write down a program in them :-)
>
>> Integration with Java was very easy and useful, though very hard to explain to managers.
>
> I do not see Java as the right target for the primary implementation, but certainly host-platform integration should be a priority, whatever the host is.
>