[General] King of Lively part II : LIE and CHEAT
Steve Wart
steve.wart at gmail.com
Thu Nov 12 19:30:53 CET 2009
Hi Peter
On Wed, Nov 11, 2009 at 1:06 PM, Peter Fraser <pfraser at spatialmedia.com>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 at 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.
> 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 ;-) )
>
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, at 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 at 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
More information about the lively-kernel
mailing list