[General] A few thoughts on LK's future
axel at rauschma.de
Fri Feb 22 22:33:11 CET 2008
> Personally, I still have mixed feelings about Ecmascript 4.
> committee -- so many features have been added that the
> language feels rather different from those versions of
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
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
> 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 at this problem.
Sun's Phobos comes to mind, as well as Aptana's Jaxer . I see two
(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.
>> - Look and feel: What still puts me slightly off Morphic is that
>> it is non-standard. This does not mean that I particularly like
>> how the Mac OS or Windows do their thing, but it is still
>> standardized enough that you can easily switch between them (or
>> even between them and Gnome or KDE for that matter). I think it
>> would be both a practical and a marketing advantage to emulate
>> these operating systems as much as is reasonable.
> Perhaps Dan can comment more on these features
> (and on this topic more generally) when he
> comes back from vacation.
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).
Axel.Rauschmayer at ifi.lmu.de
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lively-kernel