[General] King of Lively part II : LIE and CHEAT

Short version:

IMO, the *Java* version of Lively is the fast route to a universal,
fast, tight platform. Such a platform  is a prerequisite for an active
community.

Where has the Java work got to?


Rambling version:  

Did I really say "Lively isn't ready for the prime time"?  I immediately
regretted pushing send. It is close and beautiful, and packs more power
into the browser than anything else  -but the prime time is unforgiving
and insists that if you are going to play the browser game, you have to
play it well. This means supporting four browsers on all the platforms
those browser run on. Lively could do it, (though it's thankless task
that never ends) but doesn't do four browsers now. And (yawn yawn) we
need more speed, and can't rely on Moore's Law.


So...

To me, the way forward is obvious: Focus on the Java implementation,
doing whatever it takes (meaning writing tactical Java) to make Lively
as slick, responsive and consistent as it will be when browsers get
their act together.

I'm NOT talking about switching to Java. I'm talking about building, in
Java, the kind of future-browser that Lively is anticipating. Lie and
cheat unabashedly. If Rhino isn't performing (and let's not forget Da
Vinci etc) then resort to Java. If (say) SVG doesn't offer a decent RGB
interface, add it. If SVG is too slow, revert to Java graphics. Lie and
cheat  -but be sure to have a browser implementation on hand lest you be
caught.

If Lively in the browser works, great  -but let users know that Java
will give them a better user experience today, especially for complex
worlds, and serious Lively hacking. The Internet Explorer problem goes
away(ish), and Sun research has a  (better than) ringside view of the
java-ajax gap.

[Aside: Silverlight would be an alternative to Java, but I'm assuming
that Sun/Oracle remain involved and people continue to fret about their
air supply. If Flash suddenly got a compliler on the client, it too
would make a nice Lively incubator. ]

More metaphors: I'm aware that the project worked with Java for a while
but encountered too much intrinsic complexity. I propose that Java be
considered *microcode*. The problem with the browser as computer, is
that you can't microcode it. When you hit a wall, there are no options.
Even Mozilla starts to feel like proprietary software.

My sense would be to implement HTML Canvas in "jmicrocode" (if a
implementation doesn't exist already). Canvas feels to me like a better
lively substrate than SVG, and doing Canvas in Java (oops -jmicrocode)
feels better to me than adapting to another graphics api (eg scene graph
etc) in Lively JS directly.

Tell me I'm wrong  (it's good for me).

Pete F
(gerbil)

IMO Javascript was a much better strategic choice than Java.

The people who need to be aware of Lively are the same people who made
jQuery succeed.

I love the way Google has documented their Javascript APIs. I think
this approach would help. Very few people will want to build entire
"sites" on Lively but parts of it should be widely adopted.

Did someone mention a debugger?

Keep up the good work :-)

Cheers,
Steve

On Tue, Nov 10, 2009@7:32 PM, Peter Fraser <[hidden email]> wrote:
> Short version:
>
> IMO, the *Java* version of Lively is the fast route to a universal,
> fast, tight platform. Such a platform ?is a prerequisite for an active
> community.

I'll admit to being a lurker/shirker.

Since "debugger" has come up a few times, thought I'd mention I've  
been working on WebKit's debugger, Web Inspector, for the last few  
months.  If there's something we can do to make debugging Lively  
better, I'd love to hear it.

I suspect the ability to host your own debugger isn't in the cards  
right now - perhaps something like that will be more feasible with  
Workers.  Living with the current debugger is the easiest route@the  
moment.

On Nov 11, 2009,@12:44 AM, Steve Wart wrote:

> ...
>
> Did someone mention a debugger?

Patrick Mueller - http://muellerware.org/

Peter Fraser <[hidden email]>  wrote...

>IMO, the *Java* version of Lively is the fast route to a universal,
>fast, tight platform. Such a platform  is a prerequisite for an active
>community.
>
>Where has the Java work got to?

Peter, and all -

This is great.  This is just the kind of thinking we need to do now.

Just to let you know, this is exactly where our thinking was a year
ago.  We got everything running on top of the JavaFX scene graph.
This allowed us to run all the regular LK demos, but in addition Java
(Swing) UI components in Lively windows (or not) and, hey, even a
midi player to hook up to the PianoKeyboard.  It ran@about the
same speed, though, because it was still all going through (our
JavaScript emulation of) the DOM.  But Krzysztof also did a small
experiment with direct calls on the graphics and demonstrated
something like a 4x speedup -- I think we ran over 100 bouncing
ellipses before slowing down to the normal speed for 25.  What a
great strategy - runs everywhere on the Open Web, and runs much
faster and ties into Enterprise libraries on the Sun platform.

Alas, this strategy competed with another strategy and our project
got cancelled :-(

But it's 11 months later and people realize ours might have been good
after all ;-)

Now to your topics...

I agree about this.  There are actually two ways to pull this off right now.
One is to take what Krzysztof did for the ellipses demo, and carry it
through to the full Morphic graphics layer.  The nice thing is that
(with a couple days' work ;-) the result could be wrapped up
as a Java Applet, and thus run in any browser where Java is available.
This would cover just about everything, including our current big
handicap, Internet Explorer.  This is the strategy I mentioned above ;-).

The other is to use the 2D canvas in O3D.  This is a very attractive
bundle since it includes not only a directly accessible canvas
library, but also the V8 JavaScript engine and full 3D if you want to
play around.

Of course these are both plugin solutions, but I think the LK story
remains clean as long as there is a full Open Web version that
remains reasonably compatible.

Yes, yes, and yes.  I think we're on the same page.

>More metaphors: I'm aware that the project worked with Java for a while
>but encountered too much intrinsic complexity. I propose that Java be
>considered *microcode*. The problem with the browser as computer, is
>that you can't microcode it. When you hit a wall, there are no options.
>Even Mozilla starts to feel like proprietary software.

Actually, complexity was not the problem.  It's just that we felt an
Open Web solution would get us much more traction.

>My sense would be to implement HTML Canvas in "jmicrocode" (if a
>implementation doesn't exist already). Canvas feels to me like a better
>lively substrate than SVG, and doing Canvas in Java (oops -jmicrocode)
>feels better to me than adapting to another graphics api (eg scene graph
>etc) in Lively JS directly.
>
>Tell me I'm wrong  (it's good for me).

You and Krazy Kat, huh?  ;-)

Well, the Canvas port does exist - check it out in Safari, FireFox or Chrome at
        http://research.sun.com/projects/lively/expt.xhtml
You can tell it's the real thing by evaluating
        WorldMorph.current().showDamageRectangles = true
and you will see good old JavaScript busily computing and refreshing
every damaged rectangle on the canvas.  [Of course it runs slower doing this]

So, the step to a Java applet or O3D is not that all hard to contemplate ;-)

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

Hi Steve (and list  -apologies if this message turns up more than once  
-am suffering email problems today)

You probably didn't read the rambling part of my post  -I don't blame you.

**I'm not suggesting that LK abandon Javascript, or browsers**. LK runs
now (or has run, and nearly runs now) on the Java platform, using the
Rhino Javascript engine and the Batik SVG library. A few tweaks seem to
have been required to make it run (as for the various browsers), but
afaik it is regular LK (yes  -lively team?).

There is no LK Java code required (Batik comes with a sample viewer that
includes Rhino). I don't know how fast Batik is, but Rhino is almost
certainly slower than the respectable javascript runtimes   -however
there is an upside...

The key thing about the Rhino/Batik "browser" is that it *can be
modified*. Sure you could modify Firefox to make it more LK friendly,
but you would have to be able to push your changes back into Firefox to
be meaningful.

The lieing and cheating angle involves the lie: "it runs in any
browser"  and many cheats: (find the hot spots and optimise them in
java  -or fix problems like the svg color api rather than living with
them)   -whilst still preserving "don't get caught" by maintaining
support for pure javascript on a browser. Even if took lots of java code
it would absolutely be possible to deliver a fast, consistent Lively
Kernel on the JRE.

Keep in mind that there is no LK support yet for IE, and that is a
rather big hole which would be extremely hard to plug natively. If IE
Lively will require a plugin to work, it might as well be an already
widely deployed plugin that offers this magic cheat-ability.

Last I heard, someone on the Lively team (Krzysztof Palacz I think) was
working on the Java version, but intriguingly  -he was using the new
scene-graph libraries rather than Batik.  If this work has stalled, it
would be good to know so lurkers and shirkers might give it a go.

Ok, so you may have appreciated all this Steve and and still didn't
agree.  Fair enough :-)

You also mentioned:

 >>Very few people will want to build entire"sites" on Lively but parts
of it should be widely adopted.<<

Personally, I can't see the value in using part of Lively. It's value is
as a complete self-contained solution. I don't really want to build
"sites" with Lively  -I want to make and share stuff on a simple little
"virtual computer in a web page" (like an XO  -except free, and able to
ship down a tcp/ip connection ;-)  )

regards
Pete

Hi Peter

On Wed, Nov 11, 2009@1:06 PM, Peter Fraser <[hidden email]>wrote:

> Hi Steve (and list  -apologies if this message turns up more than once  -am
> suffering email problems today)
>
> You probably didn't read the rambling part of my post  -I don't blame you.
>

Actually I did read it, but I have to confess I didn't really understand it.
Having looked@it again I realize that my problem is that I don't think of
Java as a client-side technology. JavaFX sounds nice, but it's in the same
league as Silverlight, and not likely to be available on the platforms I
want to support. JavaScript is already there, and that will be the case for
any new devices that ship in the foreseeable future.

I am impressed with the momentum and widespread adoption of Javascript, and
not quite sure how having an additional dependency on the Java runtime
helps, given the complexity web developers are already faced with (it seems
only to get worse). I don't mean this as a slight or to disrespect to the
work that's been done on Java. It's a great technology, I just don't see it
a necessary part of the browser application architecture.

[I've omitted commentary about Rhino and Batik because I'm not familiar with
those]


> Keep in mind that there is no LK support yet for IE, and that is a rather
> big hole which would be extremely hard to plug natively. If IE Lively will
> require a plugin to work, it might as well be an already widely deployed
> plugin that offers this magic cheat-ability.
>

In general it seems like the browser world is moving towards WebKit, with
the exception of Microsoft (not sure about Mozilla). I suppose some people
still need IE, especially in big companies. I gave up on Windows as a
professional about two years ago, and this is admittedly a blind spot for
me. In any case, it seems reasonable to assume that any holes in WebKit
could be plugged with JavaScript wrappers around Microsoft-specific APIs. I
agree Java could help here.


I used the scare quotes around "sites" because I was too lazy to be specific
about the types of developers I was referring to. It seems to me that a
solution needs to address a problem. I think the crux of the matter is to
identify the types of problems Lively is well-suited to solve.

I am personally interested in mobile development, and I would like to
emphasize Dan's comments about LK running unmodified on the iPhone. While I
would love to pick up Lively and do wonderful things with it, I am faced
with the unfortunate necessity of earning a living. That leaves two options:

1) someone pays me to extend Lively as a platform in itself - presumably
this is a possibility in certain educational or large corporate
environments, but for a freelance guy with kids to put through school, not
likely

2) I find an application of the technology to solve a particular business
problem. What I mean by "business" is that some revenue model needs to
exist, if not immediately,@some point in the not too distant future. For
me the essential technology components are a fast and reliable distributed
object model with built-in configuration management. Graphics are important,
but the reason people use computers is that they are a powerful
communications tool. It doesn't have to be something for corporate drones,
but a clever social networking application that "just works" would be nice.
People who don't want to configure or program their environments should just
be able to do something useful with a nicely designed system. How can I do
that?

As an old Smalltalk guy I found it quite easy to pick up Objective-C and
start doing iPhone development. I know that this is very likely a dead-end
as far as development technologies go, but it's been fun to indulge myself
with such a slick OO environment. I worked in .NET for 5 years and never
enjoyed it. I've tried many many times to pick up Java over the years and
continually found myself frustrated by a maze of interlocking standards that
never actually helped me get things done, but instead seemed to be punishing
me for my ignorance about the latest trends in the pursuit of the holy grail
of software engineering. Lively seems fun but I need to understand how I can
be productive with it.

In the past year I learned C++ and found it not to be anywhere near as bad
as I expected (although I still prefer the looser discipline of Obj-C), and
now I'm looking@GLSL shaders and entirely new ways of writing data
parallel code for web browsers and mobile devices. What is missing with
these Old New technologies is the stuff I took for granted for 15 years with
Smalltalk - interactive inspectors, incremental method compilation,
debuggers, easy code navigation. LK offers these things, which is exciting,
but most developers are willing to forego something that makes their lives
easier if it means they can have more control over the final result, whether
that means presentation quality, performance or deployment flexibility. I
don't have to worry so much about hard crashes as I used to but often I miss
tweaking a drawing method without rebuilding my entire app.

I would like to see documentation to help me understand that Lively isn't a
large complex system with ill-defined internal dependencies. It needs to be
easy to use the parts I need without pulling in other components that are
still only partially developed, or worse, pulling in bits of framework that
are partially developed and half-forgotten. I have seen this too many times
and I worry that it's a natural consequence of "complete self-contained
solutions" that don't consider how they fit in with other components that
are also part of an even larger complex system.

Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://livelykernel.sunlabs.com/pipermail/general/attachments/20091112/602b6cfa/attachment-0001.html 

This is not specific, but fairly general.  A strategy.

I believe LK should join the rapid JS revolution: server side, client  
side, and communication between the two.

Server Side: From the day of Steve Yegge's Rhino On Rails post, a  
flood of server side JS stunts have been flourishing.
   http://steve-yegge.blogspot.com/2007/06/rhino-on-rails.html
Aptana's Jaxer, with a DOM on the server side, and now Google App  
Engine supporting Rhino.  Why is this happening?  History.  Us old-
timers are used to desktop programming.  But the *average* programmer  
is young and web centric.  Proof?  Look@Adobe's AIR which uses JS,  
CSS/HTML, DOM to create desktop apps!  Yup .. migration of web tech to  
desk tech.  And its pretty impressive.

Client Side: Yes, script kiddies have used snippets to make pages  
horrid for years.  But since the rise of brilliant JS practitioners  
(John Resig, Douglas Crockford, and more) .. including LK .. people  
recognize JS's power, simplicity, and sophistication.  The Browser has  
made JS the dominant language, period.  Its everywhere.  With Doug's  
"JS the good parts" book, snobs like me have been converted.  And  
Rhino being built into the Java release has made JS outside the  
browser popular.  Flash is JS++.  And more systems are becoming JS  
based daily. And with Chrome and other really fast JS implementations,  
performance is less and less an issue daily.

Communication: This is the sleeper: JSON.  XML was the ugly duckling  
for quite a while for client-server communication .. the X in AJAX.  
But now savvy programmers are sending JSON back & forth, needing no  
parsing .. eval the payload and you get a native JS data structure!

Libraries: I might as well include these too.  What is a JS library?  
A URL.  You simply can't have easier deployment.  And a HUGE number of  
libraries are being converted to JS.  Processing, for example now has  
a ProcessingJS (Resig).

So gone is PHP-XML-JS-Classpath and always forgetting which language  
you are using.  JS has unified the whole client-server-communication  
life cycle.  And it has turned deployment into HTTP.  This is almost  
impossible to believe!  I study Complex Adaptive Systems and this  
emergent phenomenon is hard even for me to believe!  Prisoner's  
Dilemma heck, look@the JS ecology.

This unification is important.  I built an early GAE web app, using  
Google Maps, their Big Tables, Django for the server, JS for the  
client, a bloody blend of XML and JSON, and so on.  Painful!

So what does that have to do with LK?  Strategy.  I don't know how to  
do it, but building a part of the JS ecology/revolution above would be  
absfab.  Downside: you'll now have to fit in with the rest of the  
crowd.  That is often difficult, architecturally.  How to avoid  
conflicts.  How to factor LK so that it can be used with or without  
the DOM.

But its the direction I would take.  I'd get Resig and Crockford on  
the phone and chat strategy.  I left Data Base out of the above but if  
you need to spin it for the New Sun (how's it going, btw), JS+JSON+DB  
is a great story.  It certainly not hard to convince folks XML is  
diabolic!

Best wishes,

    -- Owen

Great post, Owen!
Comments interleaved...

>This is not specific, but fairly general.  A strategy.
>
>I believe LK should join the rapid JS revolution: server side, client
>side, and communication between the two.

Yes, I agree.
But there is another revolution around collaboration, by which I mean
multiple users in the same space, that may be a closer match to LK's
strengths.  We should definitely encourage both for now.

>Server Side: From the day of Steve Yegge's Rhino On Rails post, a
>flood of server side JS stunts have been flourishing.
>   http://steve-yegge.blogspot.com/2007/06/rhino-on-rails.html
>Aptana's Jaxer, with a DOM on the server side, and now Google App
>Engine supporting Rhino.  Why is this happening?  History.  Us old-
>timers are used to desktop programming.  But the *average* programmer
>is young and web centric.  Proof?  Look@Adobe's AIR which uses JS,
>CSS/HTML, DOM to create desktop apps!  Yup .. migration of web tech to
>desk tech.  And its pretty impressive.

Agreed.
Necessity is the mother of invention.  By which I mean that the way for
us to make progress on the server side is to have a need for the server
side.  Or, equally effective, a passion to pull of a cool demo on the
server side.

By the way, with regard to the DOM, Krzysztof's cool 1-week port of
LK to JavaFX was done by way of a JavaScript emulation of the DOM
that was originally done by Dan Amelang as a way to couple some
experimental graphics to LK.  The code is in EmuDom.js.

Yup.  Indeed, the faster JS engines are making real the characterization
of JS as the assembly language of the Internet.  It is just good enough,
and now just fast enough, to make it reasonable to compile lots of
our favorite languages to JS.

>Communication: This is the sleeper: JSON.  XML was the ugly duckling
>for quite a while for client-server communication .. the X in AJAX.  
>But now savvy programmers are sending JSON back & forth, needing no
>parsing .. eval the payload and you get a native JS data structure!

Absolutely.  I have wanted to make this shift almost since we started.
I always thought the Smalltalk approach to serialization is nice, and
JSON is an even cleaner and more consistent job.

>Libraries: I might as well include these too.  What is a JS library?  
>A URL.  You simply can't have easier deployment.  And a HUGE number of
>libraries are being converted to JS.  Processing, for example now has
>a ProcessingJS (Resig).

Yes.  And this is something we need to press on.  It would be so
easy to just go through our files and separate the kernel from the rest
and then crunch it into one or two simple files.

>So gone is PHP-XML-JS-Classpath and always forgetting which language
>you are using.  JS has unified the whole client-server-communication
>life cycle.  And it has turned deployment into HTTP.  This is almost
>impossible to believe!  I study Complex Adaptive Systems and this
>emergent phenomenon is hard even for me to believe!  Prisoner's
>Dilemma heck, look@the JS ecology.

Well, it's not so amazing to me because we have a lot of pressure
going from smart people who know that it *can* be simple, and it
*can* be general, and they're all trying to figure out how to evolve
into a better world.  And guess what?  Enough smart people
with enough motivation will finally figure out how to, as you put it,
turn deployment into HTTP ;-).

>This unification is important.  I built an early GAE web app, using
>Google Maps, their Big Tables, Django for the server, JS for the
>client, a bloody blend of XML and JSON, and so on.  Painful!

This is just what I have been doing recently:  using LK in the role of
Dojo to implement a couple of views in conventional HTML.
It was Steve Uhler who pushed for this, and Robert Krahn who
built the first demo -- check out...

        http://research.sun.com/projects/lively/divChallenge.html

It's just a sketch, but it shows three Lively Kernel worlds embedded
in HTML, and inter-operating so, eg, an HTML input can control
the time zone of a clock or the number of cylinders on the engine.

>So what does that have to do with LK?  Strategy.  I don't know how to
>do it, but building a part of the JS ecology/revolution above would be
>absfab.  Downside: you'll now have to fit in with the rest of the
>crowd.  That is often difficult, architecturally.  How to avoid
>conflicts.  How to factor LK so that it can be used with or without
>the DOM.

So, as you see above, much of the work has been done already,
although, as with LK in general, only through proof of concept.
I agree with your strategy, plus I still want to include a couple of
other synergies (Caja and collaboration@least, plus some
high performance solution).

I've been feeling it's time to take it all apart and start over, but maybe
it's also time to put together a set of demos using what we have
to map out and demonstrate our place in the new world.
One demo I've been wanting to do (mentioned earlier) is a
truly performant port to O3D or JavaFX that can run in any
browser including (sigh) IE.

>But its the direction I would take.  I'd get Resig and Crockford on
>the phone and chat strategy.  I left Data Base out of the above but if
>you need to spin it for the New Sun (how's it going, btw), JS+JSON+DB
>is a great story.  It certainly not hard to convince folks XML is
>diabolic!

I think that including databases is relatively easy@this point.
Steve Uhler has been playing around with this, and you're absolutely
right that that's a big market, and one that I think is starved for
*lively* views.

And with regard to your "how's it going", you can read the news
as well as I regarding the high order bit.  For the LK project, it has
been rough, as I'm the only person remaining, though Robert,
Krzysztof and Steve will always lend a hand if I ask.  That's what led
me to call for workers, and it has been great just to hear voices out
there.  I think something big is coming, and I still want to play.
I agree absolutely about alignment with Crockford, Resig and,
looking forward, Mark Miller's work.

Again thanks for your strategic thoughts and your enthusiasm in general.

        - Dan