Comments on: Rumor: Mac Java’s Demise is Real, and Why That Could Be Good News for Multimedia

By: Harland

Harland — Sat, 09 Feb 2008 09:41:21 +0000

Having SUN do the MAC OS X Java Vm makes a lot of sense now that Leopard is a Certified UNIX. This should make it easier for SUN to use the Solaris VM on Mac OS X. Visit here for more info ...

By: Nat

Nat — Thu, 01 Nov 2007 19:07:26 +0000

busoni: probably, but that was not my call ;)

By: busoni

busoni — Thu, 01 Nov 2007 19:01:12 +0000

“So basically if you ask me, was using an interpreted language to create full GUI apps a good idea 10 years ago ? No. Is it now, totally.”

performance-wise, the OLPC is much like a 10 years old PC. is it a good idea to use an interpreted language to create apps for it? is it the right place for transparency and a lot of custom drawings? couldn’t fresh ideas for educative and entertaining programs be implemented with the basic GUI type that can be found in most mobile and PDA apps?

By: Peter Kirn

Peter Kirn — Thu, 01 Nov 2007 16:36:06 +0000

@jah: JavaSound was substantially recoded by Florian Bomers, possibly *after* you worked with JavaSound.

There’s really quite a lot more work to be done, but I also think it’s a) possible to do some very interesting stuff now and b) already some concrete progress on getting it further and c) Java is further along than some of the alternatives that aren’t C/C++. ;)

For synthesis alone, Java is a long way from making sense. But as one platform for integrating other features, like 3D, networking, etc., it gets more interesting. There’s never going to be one tool for everything, anyway. That’d *be* C++, except that it can be really painful for certain kinds of development, especially with individuals / hobbyists / students, who I think are important, if often-overlooked.

By: Peter Kirn

Peter Kirn — Thu, 01 Nov 2007 16:26:18 +0000

Hmmm… my sense is, for what it’s worth, it is possible to get around some of those performance bottlenecks with Java. It’s not hard to imagine full-blown Java apps running on mobile devices in the near future. But I haven’t played enough with Tam Tam / Python to know for sure. And I know Python works a little differently from Java in terms of compiling… I think the gulf between real-world and theoretical Java performance is interesting, because it demonstrates just how much you can screw up performance in the real world, not as a language issue (Java apps do run nearly native, if on a virtual machine) as an issue of all this other gunk we layer on top and the way it’s implemented.

By: Nat

Nat — Thu, 01 Nov 2007 16:05:27 +0000

Just to clarify things, Python does not run “Native” Meaning it doesn’t run at the same speed as C for sure. The PYC files are compiled, but only in order to make the interpreter parse the file faster. The C functions that python calls run native, obviously.
Regarding the OLPC vs normal PC speed issue, to give an idea, TamTam takes 2-3 seconds to load on my MacBook (under Parallels) but takes 30-45 seconds to load on the XO. What needs to be taken into account is that TamTam is a very rich applications in terms of the GUI. We use raster images with transparency and do a lot of custom drawings. I doubt that the GUI of Pocket PC applications are as complex (I have one myself and the GUI is very basic in general).

So basically if you ask me, was using an interpreted language to create full GUI apps a good idea 10 years ago ? No. Is it now, totally.

By: Peter Kirn

Peter Kirn — Thu, 01 Nov 2007 15:49:07 +0000

Yeah, JUCE is cool … see also OpenFrameworks for C++, not necessarily for full-blown apps but as something for artists. It is interesting to me that these were both inspired by Java projects, which says the ideas in Java have been right and something’s lacking in execution.

By: Fintain

Fintain — Thu, 01 Nov 2007 15:46:04 +0000

Is anyone aware of JUCE, the C++ framework for developing cross platform audio applications?

By: Peter Kirn

Peter Kirn — Thu, 01 Nov 2007 15:04:26 +0000

Right, but again — Java, Python run native. So it’s not the lack of bytecode that’s making things slow. And launch time may be a different issue altogether.

By: busoni

busoni — Thu, 01 Nov 2007 15:01:45 +0000

i didn’t intend to say “python is slow”, i just saw that the OLPC prototype i tried was terribly slow.
wether interpreted or not, there seems to be a lot of overhead in the current implementation, resulting in a hardly usable system. i understand that it’s maybe just too complicated to write everything in native/lowlevel code and that the whole design is much better understandable and easier to extend with python. but again, it’s just not fun to work with a system where closing a program and starting another one takes one minute.