[Sugar-devel] Activity bundle format (was Re: Long-term support for Sugar)

[Benjamin M. Schwartz]

Bernie Innocenti wrote:
> El Wed, 23-09-2009 a las 14:03 -0400, Benjamin M. Schwartz escribió:
>> Bernie Innocenti wrote:
>>> A fixed platform with infinite backwards compatibility is a dream even
>>> for an interpreted language.
>> Java.
> 
> Java is just a marketing lie ;-)
> 
> The official JVM did not even "run anywhere", but on 3 specific systems
> until very recently, when it was open sourced.  These days, there are
> plenty of "Windows only", "Linux only" and "Symbian Only" applications
> written in Java.
> 
> Besides, Java is not really an interpreted language: it can be
> statically compiled, and even the JIT can approximate the performance of
> C.  Python, which is 10-20 times slower, must depend on C libraries to
> perform all the computationally non-trivial work.
> 
> Moreover, we cannot control the evolution of Python.  If you look at its
> past history, you'll see that, unlike Java, it's a language that likes
> to break backwards compatibility from time to time for the sake of
> cleaning up its grammar and runtime libraries.

This is true.  When Python was selected as the language of Sugar, there
was a single vendor and a single hardware target, so "VM opacity" was not
considered an important quality.  Python certainly lacks it.  Java,
however, has excellent VM opacity, unless explicitly configured otherwise.

>> It depends what you mean.  I really do believe we _could_ implement a
>> highly usable system in which Activities are completely self-contained
>> portable bundles.  For example, see Android.  I don't believe that we
>> _have_ implemented such a system.  I do believe that we _should_, because
>> it maximizes the ability of users to predict how their system will behave,
>> and predictability is the core of usability and security.
> 
> This is a noble goal, but much, *much*, *MUCH* harder and much, *much*,
> *MUCH* more constraining than just adopting a real package system with
> full blown dependency checking.

It is certainly very constraining.  It's also the only way I can think of
to achieve the kind of universality that I desire.

> The motivation for offering a JVM on "smart" phones is definitely *not*
> vendor interoperability.  In fact, some of them are intentionally not
> interoperable.  I believe the design goal is creating a proprietary
> platform where only approved applications are allowed to run and perform
> only approved actions.  The overhead in terms of performance and
> flexibility is significant and the consumers pay the price.

We too are trying to create an environment in which applications' actions
must be approved ... by the user.  Also, Android is a nice example of a
smartphone environment in which users are free to run absolutely any "App"
that they choose.

> Because we're not in the business of creating a locked-down consumer
> platform, we don't have to castrate ourselves this way!

We are trying to do something much more challenging: to build an operating
environment that is usable, reliable, predictable, and educational,
despite running in the Worst Case Scenario of computing: poor children in
poor places.

>  We can have 3D
> fractal zooming activities for Sugar that would run decently fast even
> on the XO.

As you said yourself, Java is quite fast.  Even C would be an acceptable
language, if a compiler can be configured to provide an opaque environment.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20090923/7e97cf91/attachment-0001.pgp