[General] A few thoughts on LK's future

> Personally, I still have mixed feelings about Ecmascript 4.
> While JavaScript 1.* was a relatively simple language,
> JavaScript 2 seems like a "kitchen sink" designed by a
> committee -- so many features have been added that the
> language feels rather different from those versions of
> JavaScript that are widely used today (1.5 - 1.7).


I agree, the relatively radical departure from JS 1.x is a bit weird.  
On the other hand, they are using Python as a role model from which  
they borrowed most of their features (I like Python...). I've been  
waiting for years for a decent language such as Lisp or Smalltalk to  
make it into the true mainstream. JS2 is not as good, but seems  
bearable. Furthermore, compared to Python, we get optional static  
typing, compared to Smalltalk we get some interesting modularity  
constructs.

I wonder whether modularity constructs will change the style of LK  
programming, as they partially run counter to direct manipulation  
(you have to encapsulate changes to the system in a module instead of  
applying them directly).

Maybe you guys should work together with the JS group, because you  
are giving Javascript something that it does not have yet: a proper  
development environment.

> About running the Lively Kernel on a JVM: we did have
> an earlier version of the system running as an applet
> on top of a JVM, Rhino, and the Java 2D graphics API
> instead of SVG.  For various reasons, the Java version
> wasn't made available as part of the open source release,
> but we might still release it later.


Interesting (threads, PDF rendering, etc.).

>> - Client/server programming: My guess is that LK could be the  
>> ideal  distributed environment. You would implement your  
>> application in LK  and then decide which parts stay on the server  
>> (JVM-hosted?) and  which parts stay on the client.


> Yes.  In fact, we currently have a grad student
> in the project looking@this problem.


Sun's Phobos comes to mind, as well as Aptana's Jaxer [1]. I see two  
possible models:

(1) Fat server, thin client: The server manages the data, the client  
is mainly a user interface layer that keeps a little data locally,  
but mainly sends the changes directly to the server. Advantage:  
Relatively close to traditional web architectures, small browser  
memory footprint. Disadvantage: Webapp cannot be used offline.

(2) Thin server, fat client: Then the server is more like a version  
control system and used to synchronize between complete copies of the  
data that are kept in the browser. Advantage: Editing is faster (no  
need to communicate with the server) and works offline. Disadvantage:  
Takes up a lot of memory/processing time in the browser.

If you will, keep us posted on the progress.


OK. I still think that Swing found a very good compromise between  
doing everything itself and completely relying on the host operating  
system. I'm not sure how this translates to a browser environment,  
but it always made Swing applications usable by "normal" people. On  
the other hand, even though I wanted to like Squeak (which is an  
amazing achievement), I could not get myself to use it, mainly due to  
its UI (even just for myself I was hesitant, for non-technical people  
it's just too quirky).

[1] http://www.aptana.com/jaxer

Greetings,

Axel

--
[hidden email]
http://www.pst.ifi.lmu.de/~rauschma/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://livelykernel.sunlabs.com/pipermail/general/attachments/20080222/b9ef1617/attachment.html