From: "Jörg W Mittag" Date: 2009-09-08T18:40:15+09:00 Subject: Re: Rubyscript instead of javascript David Masover wrote: > On Monday 07 September 2009 05:53:13 am Eleanor McHugh wrote: >> On 7 Sep 2009, at 02:49, David Masover wrote: >>> At the end of the day, I suppose it's a matter of taste, and we'd >>> probably all be much better off with a common VM in the browser >>> (something like Java or Flash, but more closely tied to the DOM, >>> and standard), so that no one is forced into one language or >>> another. We already have. It's called ECMAScript. The only thing missing to make it a great truly great VM is GOTO, but it actually *does* have GOTO, it's just spelled funny: E-X-C-E-P-T-I-O-N. Here is just a small excerpt of the languages that target ECMAScript: * CIL bytecode (meaning any CLI language, and that includes Ruby, Python, PHP, Perl, Scheme, Prolog(!), ... can run on ECMAScript), * JVM bytecode (meaning any JVM language, and that includes Ruby, Python, PHP, Scheme, ... can run on ECMAScript), * YARV bytecode (meaning any YARV language, and that *obviously* includes Ruby can run on ECMAScript), * any language implementation that uses PyPy (including Python, Smalltalk, Prolog), * Clojure, * C, * Flapjax, * Caja, * Objective-J, * Clamato, * haXe and * links. >> It seems that's part of Microsoft's thinking with Silverlight and the >> Mono project's Moonlight Linux/X11 implementation could make it a >> credible platform. > It looks interesting, but I have several concerns: > - Mono always seems to be several steps behind .NET. This not a problem if you explicitly target Mono. Also, while Mono does not implement the entirety of .NET, it *does* implement the entirety of ECMA-334 aka ISO/IEC 23270 (C#) and ECMA-335 aka ISO/IEC 23271 (CLI). It's also not entirely true: in several areas, .NET is several steps behind Mono: modularity (developing the CoreCLR for Silverlight was a major effort, while Mono was modular from day one), Compiler-as-a-Service (available in Mono for over a year, planned but not even announced yet for .NET 5 or 6), iPhone support (Mono runs on the iPhone just fine, .NET probably never will), static native compilation (Mono can compile a .NET application together with the Mono runtime into a single static native executable, .NET always needs the .NET runtime installed, even if you use NGen), 64 Bit array indices (explicitly allowed by the specification, but only implemented by Mono with no plans by Microsoft), SIMD support (some vague comments by Microsoft, but nothing even remotely concrete), Continuation support (no interest from Microsoft)- > - Microsoft has helped Mono and Moonlight, because they're fighting Flash. If > Flash dies, that support may simply be dropped. Microsoft already helped Mono before they did Silverlight. And even before Microsoft started helping them, Mono did just fine. Oh, and Silverlight has already failed. The next version of Office will be web-based, but it uses only HTML, CSS and ECMAScript. If you can build MS Office, Google Wave and Sun Research's Lively Kernel without any plugins, then what the heck *would* you need Silverlight for? > - Software patents? The ECMA specifications are covered by the Microsoft Specification Promise. Of course, that doesn't cover the parts not part of the ECMA specifications, which includes Silverlight. > What I've heard suggested instead is to take Adobe's Tamarin engine, merge it > into open browsers like Firefox, This was the original goal for replacing SpiderMonkey. However, as it turned out, Tamarin is heavily biased towards statically typed languages like ActionScript, which is why Mozilla and Adobe decided to drop Tamarin, only extract the tracing JIT and duct-tape that onto SpiderMonkey, producing the current Mozilla ECMAScript engine, TraceMonkey. Tamarin sounded like a good idea, when ECMAScript 4 was still the future, but that died, thank the heavens. > and let Adobe quietly push it into IE via > Flash. This has the advantage that everyone already has Flash, and Flash > generally stays up to date somehow or other, so it would be instant, > widespread adoption -- yet the Flash would be a hack for where the standard > itself isn't supported. Actually, Flash is also only supported on a tiny fraction of platforms. Indeed, I believe Mono is actually better in this regard. For example, Flash 9 was released in 2006, but in 2007, the most recent version of Flash for Linux was still Flash 7 (released 2003!), which did not support ActionScript 3 nor Flex. Also, to this day, Flash for Linux is only available for 32-Bit x86 processors (which is pretty much exactly 0% of computers sold in the last 2 years, with the exception of netbooks), and only for a small number of distributions and browsers (excluding, for example, Opera). > That's a powerful platform -- if that's the direction Adobe is going. I have > no idea -- a quick Google doesn't show whether any other languages target > Flash, or could reasonably target Flash. Here is just a small excerpt of the languages that target Flash: * YARV bytecode (meaning any YARV language, and that *obviously* includes Ruby), * C and * haXe. jwm