[Sugar-devel] Activity bundle format (was Re: Long-term support for Sugar)
Bernie Innocenti wrote: A fixed platform with infinite backwards compatibility is a dream even for an interpreted language. Java. Right now, we're just closing our eyes pretending that we are immune from the dependency problems and that the .xo package format will suffice. Do you really believe this? 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. signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity bundle format (was Re: Long-term support for Sugar)
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. 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. 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. Because we're not in the business of creating a locked-down consumer platform, we don't have to castrate ourselves this way! We can have 3D fractal zooming activities for Sugar that would run decently fast even on the XO. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity bundle format (was Re: Long-term support for Sugar)
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. signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
