The Next Browser Scripting Language Is — C? 375
mad.frog writes to tell us that in a recent talk by Adobe's Scott Petersen he demonstrated a new toolchain that he has been working on (and soon to be open-sourced) that allows C code to be run by the Tamarin virtual machine. "The toolchain includes lots of other details, such as a custom POSIX system call API and a C multimedia library that provides access to Flash. And there's some things that Petersen had to add to Tamarin, such as a native byte array that maps directly to RAM, thereby allowing the VM's "emulation" of memory to have only a minor overhead over the real thing. The end result is the ability to run a wide variety of existing C code in Flash at acceptable speeds. Petersen demonstrated a version of Quake running in a Flash app, as well as a C-based Nintendo emulator running Zelda; both were eminently playable, and included sound effects and music."
Internet-C reborn? (Score:4, Interesting)
There used to be a project, many years ago, which was I believe called itself something like "Internet-C". It used gcc with a pseudo-code backend to produce portable binaries which could then be ran from a plugin or through an emulator. Since gcc was tuned for register based archectures and 68k was already an existing backend, I think the pseudo-machine code he used was based at least loosely on the 68k one.
Perl is Interpreted C (Score:5, Interesting)
There's very little if any C code that can't be written basically the same for Perl to interpret it basically the same way. The exception is direct memory access, but there are ways. And besides, I'd rather access memory through an API that really manages it, like making it hard to unexpectedly overflow buffers or grant access to unauthorized other users.
I'd love a Perl interpreter embedded in my browser. I'd love to have a Perl API directly to the browser app and the browser documents' DOM. I'd love to have a "Perl commandline" that returns text like usual, or that works on remote data by URL, or that returns icons or other data displayable in the browser.
Javascript is a pain in the ass. I'd rather have a Perl engine, and all the Perl modules and scripts, to run against my browser the way I usually run against my terminal window.
Startup latency (Score:5, Interesting)
Being able to run Python or Quake inside a Flash VM sounds useful at first blush, but it seems you'd lose most of what makes webapps nice for both developers and users. In particular, C based apps are not designed to be streamed, whereas Flash or AJAX apps usually are (to some extent). Nobody wants to browse to a "web app" and then spend 5 minutes twiddling their thumbs whilst 20 megabyte of Python runtime or Quake is pulled down over the wire. Web apps just have a different DNA to desktop apps.
I can see this being used to accelerate computation-heavy subelements of a regular Flash app though. I wonder how much of this is being driven by a desire to run a Photoshop subset inside Flash?
Re:what? (Score:5, Interesting)
I'd use C for everything if its string handling weren't so utterly broken. It makes sense from a pure performance, near-the-hardware perspective to handle strings the way it does, but what is desperately needed is POSIX standardization of stracat/stracpy. That one change would make it trivial to eliminate 99% of all buffer overflows in typical apps (and, ideally, kernel code)....
Sure, I could write my own, and pretty much everybody on the planet has done it at least once in their lives, but it seems ridiculous that such obvious operations require hand holding. Outside of embedded platforms where malloc is expensive, dynamically allocating a new buffer for concatenations should be the norm. For situations where performance takes a big hit because you can't afford to copy the source string every time, you could also add this API:
Wherein strbuf is opaquely defined as:
struct strbuf_private { // null-terminated string
char *content;
size_t length;
void *private_history_data;
};
struct strbuf;
typedef struct strbuf *strbuf_t;
and the routines automatically realloc the internal char * buffer as needed to grow the size to hold incoming content and likely future content based on historical data about prior operations on the structure, the algorithm for which would be an implementation detail outside the scope of the standard. That said, for the rare cases where a simple copy hurts performance badly enough for most folks to care, chances are your application knows its own growth policy better than the OS could guess anyway, so you probably should just roll your own buffer management code. The important bits to add to the standard are those first two functions (stracpy and stracat).
Re:Internet-C reborn? (Score:4, Interesting)
Could it be Juice?
http://web.archive.org/web/20010408174718/caesar.ics.uci.edu/juice/intro.html [archive.org]
Crazy thoughts..... (Score:4, Interesting)
> You realise that all the OS layers, networking layers, web browsers,
> scripting languages are primarily to try to get away from C?
So? You are missing the bigger point. All of those layers and scripting languages you speak of are written in C. So C working in Flash means all of that other stuff can be brought over. Perl + Flash? Python + Flash? Ruby? The mind boggles at the possibilities.
Of course since nobody will want to stuff all of Perl + half of CPAN down the pipe every time an applet loads we will end up with predownloaded versions cached for use. Let the package war begin, will flash binary packages be maintained with .deb or .rpm... I can see Windows users fighting Package Kit or Synaptic to manage the cruft needed so that "web apps" can work. We could end up with an entire GNU/Flash[1] distribution lurking on every Windows PC.
[1] I object to the GNU/Linux misnaming abomination but this time it really will be a "GNU" distribution since Linux won't be involved. At least until we get a formal 'distribution' being shipped by Adobe.
Easier way... (Score:5, Interesting)
chrome://browser/content/browser.xul
Firefox inside Firefox inside Firefox...
Re:Internet-C reborn? (Score:4, Interesting)
The DotGNU project compiles C to the CLR, so that fits the bill.
Re:Browser-based OS (Score:3, Interesting)
Using a package management system does not make for "poof! problem solved." At work we have an entire team of packagers, plus ~1500 applications to maintain. Library conflicts and such are a nightmare, as are bad vendor packages.
Web apps honestly aren't much better... they usually tie you to a specific version of IE (activex) or Java (even worse in my opinion... i think we have 5 or 6 different slightly incompatible runtime packages out there now).
I put C on web pages at my last start-up (Score:3, Interesting)
At the now defunct start-up I last worked at, we had the usual LAMP stack driving our product. For amusement (and because I think there is an awful lot of bloat in LAMP), I did a simple front-end to our product based on an approximately 1000-line web server I wrote, and web pages with C embedded in comments. The makefile ran the web pages through a munger that transformed them into C, then built them and linked them into the server. If you didn't want the tiny web server, it could have just as easily built them as an apache module. The downside was that web developers using such a system would have had to "modify, compile, reload in browser" as opposed to their usual "modify, reload in browser" cycle. IMHO, this alone would have killed it since web devs like fast turnaround on changes. Nevermind that the web devs would have had to learn C, and that it wouldn't have been sandboxed or been able to run code client-side. I still like the idea though, and I'm glad to see others not only think in a similar way; but do so using a platform that would resolve some of the aforementioned issues.
My toy front-end was never put into production of course; but when I wanted to debug my code without pestering the web devs, and I needed something more than text, it was quite useful.