| |||||||||||||
|
| |||||||||||||
Interview: Miguel de Icaza (DesktopLinux.com)Interview: Miguel de Icaza (DesktopLinux.com)Posted Oct 16, 2008 13:16 UTC (Thu) by massimiliano (subscriber, #3048)In reply to: Interview: Miguel de Icaza (DesktopLinux.com) by Janne Parent article: Interview: Miguel de Icaza (DesktopLinux.com)
AFAIK, the reason why Miguel liked (and likes) Silverlight is purely technical, and is related to Silverlight 2.0 and not 1.0.
The point is the following: HTML is nice to convey contents, but the HTML-JavaScript combination is terrible to develop applications. Since there is a great movement towards distributing applications directly into web browsers, people use it anyway, and also in sophisticated ways like with AJAX. But at the core there's always JavaScript, and not everybody likes it.
Flash is one alternative, but technically it only shifts the problem (you are forced to use ActionScript instead of JavaScript), and as Freedom goes it's the worst thing we have. With Silverlight 2 you have two advantages:
Do not understimate the second point: whether we like it or not, there's a strong push towards making richer and richer "web applications", and being constrained to a single programming language is not good to anybody. The more the complexity increases, the more there's a need for a sophisticated development environment (and-or framework), possibly providing static typing, clear modularization, and all the other things that good software engineering says that help in managing complexity. The "web standards" (XHTML, SVG, the new Canvas...) are totally ignoring this problem, providing JavaScript as the only programming language you can use. So the "strong point" of Silverlight 2 is the programming framework. Now, as all technical issues, this is debatable and there can be multiple solutions. But you can be sure that the interest Miguel had in Silverlight, just from the start, was due to this technical thing: having a strong (and Free Software!) programming framework for "rich internet applications". In principle there are other solutions (like Java applets, or the new Java FX), but they should all be evaluated on technical merits. Plus, it would be very silly to say "this technology deserves to have a Free Software implementation, and this other doesn't": this is exactly against Freedom.
In the Mono team we think that, as a programming framework, the design of the CLI specification is on average technically superior to the alternatives.
The "codec problem" is just an unfortunate side effect of the current patent legislation in some countries. Everybody that feels more comfortable using ffmpeg instead of the Microsoft-provided codec package can do so, this is Free Software, all your freedoms are preserved.
That said... have fun with the software you like most :-)
(Log in to post comments)
Interview: Miguel de Icaza (DesktopLinux.com) Posted Oct 19, 2008 17:27 UTC (Sun) by togga (subscriber, #53103) [Link]
Nice marketing.
>> "Actually, the simple fact that you are forced to use a specific programming language to do client side web programming is inherently bad."
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. It's a free world and you are just choosing to play the Microsoft ball-game.
>> "* The "data" is defined in a clean XML format (XAML), which is not SVG but is anyway better than 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.
None of your technical argument has any merit. 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.
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?
|
|
||||||||||||