Interview: Miguel de Icaza (DesktopLinux.com)

Posted Oct 21, 2008 15:13 UTC (Tue) by massimiliano (subscriber, #3048) [Link]

Well, mine was not marketing, I was presenting technical arguments (or at least this was the intention). So I keep the reply strictly on the technical side, hopefully the discussion will be constructive.

No-one is forcing you to a programming language, you can compile <random language> into Java or flash byte-code if you want with less amount of work than you've put in Mono.

You say I am free to choose the language I want client side, and give me two proposals to avoid Javascript: compiling to Java and compiling to Flash.

About Java: compiling an arbitrary language into Java bytecode is possible right now, and has been technically possible since maybe 1995. Then, to execute it client side in a "web application", you need to use a Java applet. Now, why didn't Java applets ever take off even if they technically could be a solution? My opinion is that they have several technical disadvantages over the alternatives. On paper they work, but in practice... they are simply impractical. One of the reasons is the class file format, which is hard to load without wasting lots of memory. Another one is the bytecode format, which lends itself well to interpretation (which is slow) but not to jitting (I know that modern JVMs do jitting, it's just that their job is harder than it should be). Maybe the new Java FX platform will make Java more attractive for this scenario, but so far, in a decade, it did not really work (while it works very well elsewhere).

The fact is, technically Flash beats Java badly for applications living in a browser...

Anyway, I don't consider "compile to Flash bytecode" a reasonable solution. First of all, its bytecode is not general enough, it has not been designed to be a "general purpose bytecode" (and this is a technical issue). Moreover Flash is not an open standard, only recently its specification has been somewhat opened, and we still have no Free implementation that works well and is encouraged, or maybe even acknowledged, by Adobe (I know, this is not a technical issue...).

So we are in the situation where a "technology" (Silverlight), even if it comes from Microsoft, is more open than the other mainstream alternative (Flash)...

My personal opinion is that this is a bad since XML is very bloated. OTOH, .NET is also very bloated so this goes hand-in-hand.

Please, show me where .NET is bloated. For once, the file format it uses for executables is really compact and loader-friendly, it is really fast to mmap it and move along. Compare that to the Java file format and you'll see what I mean. Also, a lot of thought has gone in correcting the mistakes gone in the Java bytecode design. Not to blame the original Java designers (they did a good job at the time), but .NET is truly a step ahead. And if by "bloat" you mean "the API is too large", well... Silverlight comes with a much restricted API exactly to solve that problem.

About using XML... it's a tradeoff. Even SVG is XML, and it does mostly the same thing. The whole WWW is built with a markup language! Maybe a compact binary format would be a bit more efficient, but in this case it would also be more inconvenient... as I said, it's a tradeoff. In this case in my opinion the choice makes sense, because it allows you to create contents without a specialized tool.

If you took all working-hours spent on Mono and made a open-source-platform with minimal overhead instead you could've made a difference.

There is already such a clean and minimalistic platform, it's called Squeak (it's Smalltalk based). Now, it's nice and all, but... is it making a huge difference?

Please, don't underestimate the "language neutrality" issue. It's really important, and in the Squeak case, the world is not willing to learn Smalltalk, and that's it. The problem is, designing a good language neutral platform is hard. Look at the new Parrot execution engine for Perl: it's taking ages to get right. So, Microsoft did the effort to design a good platform, and publish the specification as a standard: what's bad?