From: David Masover Date: 2009-09-11T12:31:29+09:00 Subject: Re: Rubyscript instead of javascript On Tuesday 08 September 2009 04:40:15 am Jörg W Mittag wrote: > 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. > > 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), This can actually work reasonably well -- as I understand it, the IronRuby and IronPython compilers/interpreters live entirely inside the VM. > * JVM bytecode (meaning any JVM language, and that includes Ruby, > Python, PHP, Scheme, ... can run on ECMAScript), Same here. > * YARV bytecode (meaning any YARV language, and that *obviously* > includes Ruby can run on ECMAScript), This is problematic. MRI, at least, has tons of stuff written in C -- much of which really doesn't need to be. This includes the Ruby parser itself -- meaning anything involving 'eval' will be broken on YARV-on-ECMAScript. And then, it still raises the question of, is this the best we can do? I suppose it is nice, compatibility-wise, and if we adopt a standard, maybe browsers can accelerate it later... I know I always dream of the day when Browsers start shipping large parts of jQuery, re-implemented as native code, with the change transparent to authors. > > - Mono always seems to be several steps behind .NET. > > This not a problem if you explicitly target Mono. It is a problem if all the docs, tools, etc, are for .NET. > 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), That's not really visible to me as a developer. > iPhone support (Mono runs on > the iPhone just fine, .NET probably never will), That's pretty much like Mono on Linux. Mono definitely has them beaten in portability. > 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), I'm really not sure why this helps. If I'm targeting Windows, most recent Windows installations have .NET. If I'm targeting Linux, I can build a package that depends on Mono. I mean, it's cool to know it exists, but I'd be more interested in actual ahead-of-time compilation as a performance boost. > 64 Bit array > indices (explicitly allowed by the specification, but only implemented > by Mono with no plans by Microsoft), I honestly can't remember ever having a flat array with more than four billion elements. Cool, but it seems kind of like this: http://xkcd.com/619/ > SIMD support (some vague comments > by Microsoft, but nothing even remotely concrete), Continuation > support (no interest from Microsoft)- These look interesting. Of course, the major problem is that we've again got the market pretty much dominated by Microsoft. If I want to write a portable app, I have to target Mono, and then I have to remove these features and make it work on .NET. > 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? Developing said applications in a language other than ECMAScript (or JavaScript, for the non-pedantic), and having it perform better (not worse) than ECMAScript? Oh, and not having to deal with the DOM would be a plus. Those are the reasons it looks attractive to me, anyway. Of course, I entirely agree with you. The one web app I built that needed plugins, the choice was forced by management (and Facebook, and MySpace). I made a case for the audio tag, and lost. > > - 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. Right... I'm also going to want to go back and have a lawyer read that Promise. Maybe I'm being paranoid... > > 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. Interesting. I never knew that. It does make me wonder whether the two would merge at some point, though. And I still very much like the idea of piggybacking on Flash, rather than Silverlight, to support browsers that don't natively have some feature I want -- at least, to the extent that I can't hack it with JavaScript alone. > Actually, Flash is also only supported on a tiny fraction of > platforms. Indeed, I believe Mono is actually better in this regard. Citation needed, and it also misses the point. Flash IS INSTALLED on the platforms it supports. The exception might be Linux, at least until said Linux user wants to watch The Daily Show. > 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. That's flipped completely, in that: > Also, to this day, Flash for Linux is only available for 32-Bit x86 > processors Wrong. Flash in general has only been 32-bit. It's just that Linux is the only 64-bit capable OS on which the majority of the system is 64-bit out of the box, including the browser. And, there is currently an alpha Flash 10 64-bit for Linux -- before Flash has supported 64-bit on any other platform. Also wrong in that it has nothing to do with the processor itself, and everything to do with the OS. Nothing's stopping you from running a 32-bit Linux on 64-bit hardware. Most people run 32-bit Windows on that hardware, anyway. > only for a small > number of distributions I downloaded a file that looked pretty distribution-agnostic -- I think it was either a tarball or a binary. Indeed, once unpacked, the only critical file was one little .so to be put wherever your browser looks for plugins. > and browsers (excluding, for example, Opera). It uses the Netscape plugin API, which has been around forever, and which even Konqueror wraps. If Opera doesn't support it, I kind of feel like that's Opera's fault, or the fault of the community at large for not coming up with a better standard for plugins. > 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. And, if we include Adobe Air, ECMAScript. That was the other thing that got me excited -- since Air wraps a Webkit browser, and since Adobe has made Air installation so easy, wouldn't it be cool if I could deliver a shim for IE that simply loaded my shiny HTML5 app in Webkit in Flash? Unfortunately, Air seems to be mostly about downloadable apps (widgets?), not so much embedding in webpages.