[General] A few thoughts on LK's future

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[General] A few thoughts on LK's future

Axel Rauschmayer
Lively Kernel (LK) is a really exciting project! I think the  
Javascript language is already very interesting and will be even more  
so in the future, so it is a good place to be.

Here are a few thoughts on LK's potential. Have any of these points  
been considered, yet?

- Ecmascript 4: This version feels like a "good-enough" mix of Lisp,  
Dylan, Smalltalk, Self, while it is bound to have the same amount of  
broad tool support that Java currently enjoys. It will also  
inevitably run on the JVM. Two consequences arise for LK: (1) If its  
language extensions mimick ES4, a transition will be easier later.  
(2) Soon LK will have the option of being a desktop environment (when  
hosted on the JVM).

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

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

Thanks for your time,

Axel Rauschmayer

--
http://hypergraphs.de/



Reply | Threaded
Open this post in threaded view
|

[General] A few thoughts on LK's future

Antero Taivalsaari
Axel Rauschmayer wrote:

> Lively Kernel (LK) is a really exciting project! I think the  
> Javascript language is already very interesting and will be even more  
> so in the future, so it is a good place to be.
>
> Here are a few thoughts on LK's potential. Have any of these points  
> been considered, yet?
>
> - Ecmascript 4: This version feels like a "good-enough" mix of Lisp,  
> Dylan, Smalltalk, Self, while it is bound to have the same amount of  
> broad tool support that Java currently enjoys. It will also  
> inevitably run on the JVM. Two consequences arise for LK: (1) If its  
> language extensions mimick ES4, a transition will be easier later.  
> (2) Soon LK will have the option of being a desktop environment (when  
> hosted on the JVM).

We have been following the development of JavaScript 2
(a.k.a. Ecmascript 4) with quite a bit of interest.

There is a good summary of Ecmascript 4 features
available@the Mozilla web site:

http://www.ecmascript.org/es4/spec/overview.pdf

See also:

http://www.ecmascript.org/es4/spec/evolutionary-programming-tutorial.pdf

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

It remains to be seen how quickly the industry will
actually adopt the new specification (the spec work
has taken several years already).  That said, JS2
will surely have a big impact in the industry as soon
as decent implementations become available in widely
used web browsers.  As soon as that happens, we will
start using JS2, too.

====

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.

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

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

It is certainly true that the look-and-feel of the
Lively Kernel is different from mainstream UIs today.
We've also noticed that@the API level, the Morphic
APIs require some adjustment from the developers when
they first start writing applications for the system.

As you may have noticed, the look-and-feel of the
Lively Kernel is intended to be customizable, so
that the developers can change the UI themes and
styles of individual UI elements@will.  However,
these features have not been documented well, so
the features probably aren't very obvious or easy
to use yet.

Perhaps Dan can comment more on these features
(and on this topic more generally) when he
comes back from vacation.

Best regards,

-- Antero Taivalsaari, Sun Labs Lively Kernel team

PS. Many of us in the LK team are away on vacation
either this week or next week.  So, responses to
messages sent to the alias may be delayed.