For some time now I've been wondering why the primary scripting format consumed by browsers is JavaScript (a language intended for humans) and not some sort of standard bytecode that would be executed in a browser's virtual machine.
What we need is the JSVM! In other words, something like the JVM but adapted for the browser. That probably means it would have a more dynamic typing focus since it makes sense for JavaScript to be the primary language targeted by the system (though there's no reason this couldn't evolve over time just like the JVM has).
All of a sudden you don't need to build in Python support, or Ruby support or LISP support or whatever else you fancy into the browser. The browser no longer cares what you compiled the script from, it just gets the standard bytecode and everyone's happy.
All of a sudden you don't need to build in Python support, or Ruby support or LISP support or whatever else you fancy into the browser. The browser no longer cares what you compiled the script from, it just gets the standard bytecode and everyone's happy.
Yes please. Just define a straightforward VM in the browser and be done with it. Let the coders handle the rest, and compile any of their favorite languages to it (they will!). Java was on the right track, too bad the implementation (and APIs) were so clunky instead of nicely integrated, otherwise we'd never have needed the JS, Flash, Silverlight, Java applets, HTML5 mess that we're in now.
Anyway, hindsight is 20/20, now we can just settle on JS as a target VM. Too bad it's implemented slightly different in every browser, making it inconvenient as intermediate format. Also, going through a dynamic language is an inefficient level of indirection if you want to program in a static language. You throw away information that could have been used to optimize.
Lots of essential Python features are not part of the language, but belong to its standard library. The thing that makes JavaScript so portable is that it basically has no such thing (except maybe Date and Math).
So to make convenient use of Python in the browser (or even to be able to run currently existing Python code), you wouldn't just have to embed the interpreter – you would have to ship this huge library. And you would have to do that for each language you want to support.
> So to make convenient use of Python in the browser (or even to be able to run currently existing Python code), you wouldn't just have to embed the interpreter – you would have to ship this huge library.
You would ship it once. Websites already do not download jquery etc. more than once. In fact websites can use those libraries from standard locations on the web so that multiple websites don't need multiple downloads of large libraries.
I'm sure we could have some sort of JSVM, we could even have some sort of bytecode for the HTML, but it would destroy part of what makes the web so great: it's openness. The ability to view the source of any webpage, and even make chances and enhance it locally.
There is also the fact that certain optimization can only be done by the browser if it has the actual source code rather than the compiled bytecode.
In both .net and java there exists excellent decompilation tools where you can easily decompile the bytecode back into java or C# or anyother language. It's not necessarily going to give you the original source code (especially missing comments) but it works incredibly well nonetheless. You could easily debug in it and edit it dynamically in browser tools as well. This is pretty much a solved problem. I wouldn't consider this a limitation worth talking about again.
Not really. HTML would remain HTML. We're talking about JavaScript, and that is already minified (and sometimes obfuscated) beyond recognisability for a human.
I'd be curious to hear what kind of optimisations become unavailable.
I think you're arguing a bit of a strawman when you mention viewing page sources: the discussion is about replacing JavaScript, not HTML. In any case, the fact that (non-web) applications are compiled into binaries hasn't stopped open source from flourishing.
Sorry, but this is not good enough. This argument is made all the time, but all you're really saying is that every other language should be a second-class citizen to JavaScript. Emscripten is a cool technical hack, but why the fuck is it 2012 and we have to compile C++ to JavaScript?
It's not good enough now, probably because JavaScript was designed as a lightweight scripting language to make web pages a little more interactive and not as a general "bytecode for the web".
However, it always amazes me when people in discussions like this take JavaScript as a done deal or a static target...this is a fatal flaw in this discussion.
JavaScript as a language and community has evolved a lot, and it continues to evolve. We've already seen improvements that make it a better target for compilation, and we'll be seeing more in the future...now that it's clear that that is what the web wants/needs and not just a little scripting language for forms.
My bet is it will be much easier/quicker to work JavaScript into a good target for compiling other languages to than to develop a general VM and convince all the browser vendors to adopt it.
That's not even taking into account which would be better overall, which I think is an interesting question without an entirely clear answer....but I'm a pragmatist and so I think it's not worth worrying about except intellectually.
> all you're really saying is that every other language should be a second-class citizen to JavaScript.
Every platform has a "native" form. On your x86 desktop, it's x86 assembly, which everything is a second-class citizen to in the sense it needs to be compiled into it. On the web, the native form is JavaScript.
It has to be something fairly high-level because the web is CPU and OS-agnostic, which JS is.
The only practical concern that can be here, is whether JS is good enough for this task - if languages compiled into it run efficiently enough. It can be, if browsers continue to improve JS and if we all improve compilers into JS. So far little work has been done on both of those, but there is starting to be effort there.
> Emscripten is a cool technical hack, but why the fuck is it 2012 and we have to compile C++ to JavaScript?
We need to compile into something platform-independent, memory-safe and standardized. There isn't currently a better option than JavaScript, because each other option has major downsides. So does JS, to be sure, but overall it's a wash, and JS is already there so it wins.
Come on now, that's a bit harsh. There are really smart people who have been trying this exact thing for years without success. Microsoft tried harder than anyone to make "JScript" part of .NET but finally gave up and Windows 8 has 2 first-class VMs.
Without success because people like you have been fighting them every step of the way trying to hold back progress. It's hard to overcome inertia, and it's almost impossible when there is an organized resistance. It becomes absolutely insanity-inducing when said resistance uses its own success in warding off progress as ammunition for holding back progress.
I'd say I was exceedingly un-harsh, even downright polite, considering the long-term damage that has been inflicted.
For some time now I've been wondering why the primary scripting format consumed by browsers is JavaScript (a language intended for humans) and not some sort of standard bytecode that would be executed in a browser's virtual machine.
Because that's how it was initially. And initially - before github and minifiers - that was very important as a way of helping people learn by being able to study the code of other websites.
Parrot in the browser! Don't really know a lot about it, to be honet, but it could work :)
"Parrot is a virtual machine designed to efficiently compile and execute bytecode for dynamic languages. Parrot currently hosts a variety of language implementations in various stages of completion, including Tcl, Javascript, Ruby, Lua, Scheme, PHP, Python, Perl 6, APL, and a .NET bytecode translator. Parrot is not about parrots, though we are rather fond of them for obvious reasons."
This is called NACL. And as great as it is, what we really need are on-the-fly compilers/interpreters.
The web needs to be open. As much as this would appease those who want privacy/drm for their code, we all know what road this leads to. Eventually we will be forced to execute certain binaries to browse certain portions of the web. The Urchin.exe forced to execute while we divulge our lives in our browsing habits.
Google/Facebook will track us, we'll know it, and we won't be able to function without it.
We do need a vm. But more than that, we need transparency in the future choices of web standards. Their are powers-that-be that are simply salivating at how quickly developers will evangelize this technology.
All I'm trying to say is the battle seems quite planned and half-done already, and I'm not sure anyone understands the long-term consequences. I sure don't.
Python in the browser would ultimately lead to all the same problems as Javascript in the browser. In a few years, we'll be hearing: Clojure in the browser, Scala in the browser, Haskell in the browser.
I've been programming in Python full-time for the past 6 months, and it's main deficiency are the same as JavaScript's: no (optional) static typing - I'm really sick of writing checks whether my function got values of the correct types, and unittests testing if a class's/function's signature changed in an unexpected way.
What we need, in my opinion, is a dynamic language with powerful optional static typing (unlike Dart, where types are just comments), with sane object-orientedness, and support for immutable values. The core has to be really simple, but the language has to be powerful enough so that libraries can provide the missing functionality (math - rationals, matrices, ...; concurrency - channels, isolates, ...; GUI, IO (with formats, ...)).
> I'm really sick of writing checks whether my function got values of the correct types, and unittests testing if a class's/function's signature changed in an unexpected way.
Sorry to be blunt, but if every one of your Python functions and methods begins with isinstance() checks for every parameter, you just missed the point of the entire language. Python was built on a foundation of ducktyping, with the mantra that "it's easier to ask forgiveness than permission" (EAFP).
Just use your parameters in whatever way you expect them to be, and either catch the rare Exception there or allow them to bubble up. Here's some suggested reading on the subject:
The Python approach means that when an exception is thrown, it's unclear whose fault it is. Is it a bug in the called function, or in the caller for passing a bad parameter? The larger the program the more of a problem this becomes.
It also means that when you change a function signature, the compiler can't tell you all the call sites you need to fix. You have to find them through testing. This is a large barrier to aggressive refactoring.
Even the Python C API provides facilities for checking that arguments have a specific type and raising TypeError if not, so it can't be that completely counter to the intention of the language: http://docs.python.org/c-api/arg.html (see O!)
> It also means that when you change a function signature, the compiler can't tell you all the call sites you need to fix. You have to find them through testing. This is a large barrier to aggressive refactoring.
This is a problem inherit to every dynamic language. You sacrifice brain-dead refactoring for improvements and tradeoffs elsewhere. Not to mention that modern IDEs and tools like Rope [1] can definitely help.
Not every function, but often enough that it gets annoying.
It mostly happens when dealing with very tight systems, e.g. a RabbitMQ queue consumer fetching messages from an external system and writing stuff to MySQL & Cassandra.
The general issue is that there are some kinds of data types (integer, string, datetime) that cannot really be duck-typed, i.e. replaced by different objects. In my experience, it is better to catch such type errors sooner rather than later, therefore isinstance() checks.
> I'm really sick of writing checks whether my function got values of the correct types
That doesn't sound like a problem that you should be having. The "Pythonic" way to do things is just roll with the values you get and handle any errors that result.
Once you master GWT you can really be very productive in it, while allowing you to:
-Write statically-typed code
-Maintain large projects using packages and OOP
-Use unit testing, code generation, and refactoring tools
-Use many Java libraries out-of-the-box or with minor modifications (this part I often find mind-boggling)
-Write code that works on server and client (also mind-boggling)
-Ignore the DOM, just use widgets
-Ignore the vast majority of cross-browser issues
-Get great IDE support
-Readily deploy apps in servlet containers like GAE or Elastic Beanstalk
-Get very performant, minimized production code
-Get help implementing best practices such as safehtml
-Interleave with JavaScript
Main drawbacks are that there are few well-maintained widget libraries, compiler takes forever, Google has been a bit reluctant to expand JRE emulation, and the script format is a bit annoying. Java is also not a great asynchronous language since it lacks anonymous functions. However, if slightly uglier looking code really concerns you, you probably don't have your priorities straight.
I don't really know what the point of Dart is. I suspect it is being promoted more out of legal concerns over Oracle than out of technical merit.
I'm constantly on code reviews for and occasionally writing GWT code, and the gymnastics and ceremony it requires on top of the slow compilation are painful enough, and the resulting JavaScript/html unpredictable enough, that I would refuse to work on any new project that used it.
It's just a tool that makes your existing HTML/CSS/js knowledge useless, a crutch for java blubs.
Python in the browser would ultimately lead to all the same problems as Javascript in the browser. In a few years, we'll be hearing: Clojure in the browser, Scala in the browser, Haskell in the browser.
Did you miss this bit of the article: "Web browsers can be viewed as a zero install interface, a virtual machine for these applications. Such a VM has no reason to be language dependent."
I don't think the article is really about Python, just thats used as an example because that's the language the author uses. I think its really about wanting a VM in the browser that any language can compile to (without having to compile to a high level language like javascript).
If you want to give your javascript some type-checking, try running it through the closure compiler. This is what we do, and we annotate our methods with type signatures like this
/**
* Queries a Baz for items.
* @param {number} groupNum Subgroup id to query.
* @param {string|number|null} term An itemName,
* or itemId, or null to search everything.
*/
goog.Baz.prototype.query = function(groupNum, term) {
...
};
And then the Closure Compiler tells us if we've broken some type contracts.
tldr: capabilities you want already exist in languages. Non-mainstream stuff to check out for the curious.
What we need, in my opinion, is a dynamic language with powerful optional static typing...with sane object-orientedness, and support for immutable values. The core has to be really simple, but the language has to be powerful enough so that libraries can provide the missing functionality
Check out Strongtalk. I know it already has almost everything you just mentioned above:
http://www.strongtalk.org/
* optional static typing - Check!
* sane object-orientedness - Check! - superlative, actually
* the core...really simple - Check!
* language has to be powerful...libraries
can provide the missing functionality - Check!
I'm not sure if it has immutables, but VisualWorks Smalltalk has it, so it is feasible to add it. (Especially since the engineer who added it for the private vendor is now working on Cog, which is an open source VM.) In addition, Squeak/Pharo run with a >bit-identical model< on something like 50 platforms. (Including different ISA, not just OS.) That's an ideal capability for a browser language.
I'm not saying that we need to use a derivative of Smalltalk in the browser. Smalltalk doesn't have operator precedence, so it comes across as strange to lots of technical people. In fact, lots of things are elegantly different in a lateral-thinking weird way. Alan Kay said it best: the computer revolution hasn't happened yet -- it is in progress. It takes decades for the full impact of what comes out of research labs to really reach the mainstream. It's time for some far-sighted people to take stock of capabilities we're not aware of yet, but which are there to be used.
I also prefer typed languages. I also don't like, the way classes are implemented in Python (the whole self thing). But I think Python has enough good stuff to make up for it. To a degree this is psychological, if you only focus on the bad stuff, you will end up hating every programming language you work with.
The self thing is one of my favourite feature in python, it is then shoo easy to refactor a method in a function, it makes very clear where things come from, etc.
I sometimes see C++ code where all the member variables start with "m_". I'd much rather have it enforced by the language than in a coding convention. (I personally find Ruby's explicit "@" prefix for member variables prettier than Python's explicit "self.", but that's minor.)
I do agree that we need a language with static typing so that one can have some level of confidence before releasing the code to production. Having said that python definitely is much better than javascript.
Doesn't dart actually do type checking? It's been a month or 2 since I played with it, but I could swear that it did type checking and reported errors when the type was wrong.
It has a "checked mode" and an unchecked mode, but they recommend the checks be disabled in production. The unchecked mode is actually called "production mode" in a lot of their documentation, including the language spec. (See the section on "types".)
We don't need Python in the browser. We need x in the browser, where x is every language and runtime.
Javascript isn't some sort of global optimum that's perfect for every possible application. The subset of Javascript that's supported by a wide range of current browsers certainly isn't. And the result is that people aiming for the web environment are limited by what Javascript can do - even though there are languages that are arguably more expressive than it.
The problem is right now, only browser makers get to decide what languages run in the browser. Browser makers have their own concerns, and supporting new languages hasn't been historically among them.
What would be nice to aim for is a model where browsers can support multiple language runtimes. Instead of the browser makers being the ones to support a language, that language's advocates would be responsible for the port - and I suspect the competition and cooperation would make them stronger.
Ideally, the language runtimes would be installed transparently. That's the big potential of a project like Native Client - if it lives up to its billing, it makes downloading the latest version of a language runtime to a browser safe, while giving near-native speed and abstract machine.
This would let Python, Ruby, Haskell, Scala, Closure, Java, non-legacy Javascript, and more exist in the same browser, giving the web platform the same diversity of languages as is available on the desktop.
(Mobile platforms seem to also have this problem. The recent move from general-purpose to language-specific platforms is sub-optimal.)
> Ideally, the language runtimes would be installed transparently. That's the big potential of a project like Native Client - if it lives up to its billing, it makes downloading the latest version of a language runtime to a browser safe, while giving near-native speed and abstract machine.
Native Client works behind a plugin API. That means all the languages you implement in it don't integrate as well with the web as JS does. For example, holding references to DOM notes, cycles etc. would work differently.
So I'm a little ignorant, but I think I'll benefit from answers more informed people give:
My question is, why aren't people out there (who are more experienced at programming/developing than I am) developing support for X language(s) in open source web browsers like Firefox. I'm sure I don't fully understand how this works yet, but can't anyone who wants to be developing this capability independently instead of waiting for browser makers to do it?
That's a good point; does that imply that it can't be incorporated after the fact? That if a number of dedicated users applied it to the product themselves, the browser makers wouldn't come around to incorporating it?
If you really want a VM, it already exists. It's called JavaScript, assembly language of the web.
I would hate for sites to start saying, "Requires the PyJSVM v0.8 or better to function, download it now!"
EDIT: in hindsight, this post was careless. I was wrong about the "PyJSVM" point, and I posted the minutewithbrendan link to provide commentary, not "Eich said it, so it must be true."
What I should have said:
JavaScript is so widely used today, that anything that comes along purporting to be better (such as bytecode, Dart, whatever) must be so much better as to provide a clear reason for developers and users. If it's just "better", then JS will remain dominant because it's good enough. Therefore, it makes sense to target JS from other langs. It's definitely not getting slower, and we're on the cusp of some great APIs!
Surprise, surprise. Mr. Javascript thinks a VM for the browser would be a bad idea. Let's address his points:
Viewing source is a non-sequitor: the source code could be streamed down with the bytecode.
Standardizing a bytecode is no harder than standardizing a language and DOM, in fact, should be easier.
Versioning bytecode is no harder than versioning languages.
Bytecode does not imply an implementation any more than a language does, although it can imply semantics.
And then, at the end, he basically advocates a JS-specific bytecode. Hah. Oh, but they aren't working on it in committee. That says about all you need to know.
There is nothing about a bytecode spec that harder than a language and language spec.
Basically, he doesn't want any competition for Javascript. That was an incredibly weak podcast and he should have been shredded for it. People cut this guy way too much slack.
The semantics are the hard part. Just making a bytecode for some language isn't hard. The problem is coming up with some semantics that allow all languages to be implemented efficiently on top of it. Turns out that's extremely difficult. The JVM and .NET certainly didn't achieve that; the Java-fied and .NET-ified versions of languages are typically slower and don't integrate well with their host languages.
The view source is not a non-sequitor. What would prevent a server from refusing to stream the source? It would have to be part of the VM spec that the source must be made available, and that seems unlikely.
I look at Flash, which I used to develop in (this is not meant to be a comment on Flash itself). There are amazing people out there doing amazing things, but because the source isn't right there, a blog post with code snippets is mandatory. Whereas with JS you can typically learn something even if it's obfuscated (to an extent).
"Requires the PyJSVM v0.8 or better to function, download it now!"
WTF is that? The whole point is that you'd target the bytecode standard. This would be just like targeting javascript today, but it wouldn't require hacks to deal with the broken aspects of javascript and maybe tools like cliend-side debugging would be useful.
It doesn't have anything to do with individual VMs per language.
Yes, you're right. Sorry, I was mistaken, confusing how Dart has its own VM, and how the browser has to have explicit support for said VM. (And yes, I know Dart can also compile to JS, that's not my point).
With that installed, you can write extensions in Python and even include Python code in your HTML files if you want to: https://developer.mozilla.org/en/PyDOM
Can the rpython translator support js as a target? Could you compile pypy to js that way, to provide a python environment in existing browsers?
To be honest though, JS is a perfectly OK language for web browsers, and if you really want to reuse python code it probably makes more sense to translate it before it gets to the browser, using automated tools or otherwise. Supporting everybody's favourite language natively in every browser would be horrible.
Yes, you can compile PyPy to JavaScript. There even used to be a JS backend as part of the RPython translation toolchain, but it got dumped since no-one was interested in working on it [1]. There've been more successful attempts like RPythonic [2] in translating from RPython to JavaScript by going via Emscripten [3], i.e.
RPython -> LLVM -> Emscripten -> JavaScript
And, then, there have been efforts like my own which have focused on building a WebKit bridge [4] to PyPy.
Actually, Javascript was originally a target for PyPy, and there was a working implementation before it was dropped since the developers thought that PyPy was being spread too thin; at that time PyPy was already was targeting the JVM, .net, llvm, and C.
Note that there is also a working implementation of Javascript that runs on PyPy. This project was actually an implementation of Python that compiled to Javascript as a target.
Source mapping (part of ES6) gives proper error messages for other languages compiled into JS, I believe this would include Pyjamas etc.
But do Python programmers who haven't programmed for the browser before realize how important async is?
Tornado and Twisted users are used to passing around functions, but they're very small subsets of the Python community, who, if asked to fetch something and do something with it, would generally wait until it's fetched.
"But do Python programmers who haven't programmed for the browser before realize how important async is?"
Not a very useful question. Anyone who has ever programmed on a GUI of any sort will know how important that is, anybody else will rapidly learn. The vague-but-pervasive idea that web developers invented async about two years ago and thus "async experience" can be presumed to have not penetrated out to those other less enlightened communities who still haven't discovered its Mighty Powers is... not exactly historically accurate, let us say. GUIs have always had to deal with async issues, going all the way back to the dawn of GUIs. It's not a new idea. It's probably older than you are. (It is older than I am.)
> Anyone who has ever programmed on a GUI of any sort
Most Python folks are backend folks. As mentioned, I frequently see Python folk (including myself a few years ago) confusing async code for JS being a complex language.
> anybody else will rapidly learn.
Why?
Delphi and the other desktop app RAD tools took care of callback integration - the entry point for the code was generally not shown, it was just visually attached to the button.
The subsets of people that do UI work right (Qt, Gtk, etc.) and people that do networking right (Twisted) are relatively large. I wouldn't worry about it too much.
I like Python, but JavaScript is sort of good at what it does: evented programming. In javascript it's really easy write a closure. I have not worked with asynchronous frameworks like twisted, but I'd image it's a little more awkward. Am I wrong?
Personally, to me Javascript is horrendously broken at what it does. In addition to being fatally underspecified as a language, the asynchronous model as implemented in JS results in callback spaghetti (or black magic with Streamline or something). Most JS evented code has extremely poor readability, since logic flow is continuously interrupted.
The best asynchronous event programming idioms I've seen in Python use decorators and yield.
But... Uhhhh... that was Ruby you just showed there. And Python's anonymous functions are deliberately crippled because the Grand BDFL dislikes functional programming (often tried to be sneaked around by those dastardly Schemers, curse them!).
Yup, you're all right, I copied the wrong snippet it seems. I don't know how that happened. And it's also true that that lambda doesn't have a closure (double fail) but in my experience a lambda usually implies the possibility of a closure. Is that a bad assumption? Thanks for the corrections.
The language in the browser is not the problem to me. If I could use python it wouldn't change the fact that you still need to deal with the DOM, CSS and browser differences.
It seems that the primary method of disagreement used by only-JavaScript-in-the-browser advocates is as follows:
1. Talk about the "open web";
2. Tell you to compile to JavaScript.
I really don't understand why this is considered a reasonable response to people who just want to build things with the language they prefer, without being treated as second-class citizens.
Maybe because people are afraid to end up with a fragmented web all over again.
Preference of language shouldn't really be a factor. The real question is that any change must be properly standardized and implemented by all browser vendors else you end up with "This webpage is written in python and is only supported by Chrome 39+ and Firefox 43+".
Does using your prefered language really outvalue that?
I think the bytecode argument is a more feasable one, as long as it could somehow be compiled to javascript and support older browser versions effortlessly.
Version fragmentation is nearly a non-issue if browser updates are automatic by default and non-intrusive. Firefox is slowly catching up, and Chrome is very good at this. IE would obviously need to substantially change its release cycle if it lost enough market share, though I imagine that won't happen for quite some time.
This is ridiculous. I love python, but it has no language support for an event loop, and if you put it in a browser, everything would have to be done in an event loop. It'd be ugly.
Javascript excels at evented programming. Use the right tool for the job.
I was just going to comment that at least Python has yield (generators) which helps to avoid callback spaghetti¹, but Javascript seems to have got it too in 1.7².
If your python eventually compiles down to JavaScript it's worth doing. That way you can get the developers to hop on because it's easier to program. Browsers could then implement functions to directly process the python source and not the JS which would have speed benefits.
But I really feel there is no need for python in the browser. JS is good enough. If you want an easier way to write it use CoffeeScript.
With a tool like Enyo you can write all the code in a sort of JavaScript, and it is converted to HTML + JavaScript. Google also has a tool to convert Java to JavaScript. Why not a similar tool for Python (or other language)? No practical need to have a lot of languages in the browser itself IMHO even if it would be nice to program web pages with his favorite language.
We don't need another language in the browser. We need a VM in the browser. As in byte codes. That way ANY language can be used. JS gets compiled down to a VM and then that is run in most implementations of JS. Why can't we just target that VM directly and use our own tools and compilers instead of being forced to compile it to javascript?
An ideal situation would be installable interpreters that still allowed you to use a system-wide rendering engine. I actually think Windows had something similar with ActiveScripting.
I assume something like QT allows you to script the webview with whatever language you have bindings for? Unfortunately QT+bindings is a pretty long way from 'zero install'
Sounds more like plugin hell to me. I think it's becoming increasingly harder to convince users to install browser plugins (for good reasons), and it's not even possible on most mobile browsers.
As with the original article I'm talking about desktop apps which would already require an installer. It's just about reducing the pain of that install.
JavaScript is the bytecode that you can compile your python or whatever code too. Just make the standards committee implement some nice features that are useful for bytecodes and you are all set.
That's true but for the first part, it's mostly due to a lack of interest by other vendors. For the second part, isn't the nacl team working on a protable version of nacl?
It's at least one way to get python in the browser today.
> That's true but for the first part, it's mostly due to a lack of interest by other vendors.
The lack of interest by other vendors is because NaCl isn't an appropriate technology for the open web, not just random lack of interest. (First and foremost, because it is CPU-specific, while the web is supposed to run everywhere.)
> For the second part, isn't the nacl team working on a protable version of nacl?
A research project called PNaCl, yes. But it is a different technology than NaCl despite the similar name. One is based on gcc, the other llvm, one ships CPU-specific machine code, the other bitcode, etc. So it is at this point too early to tell if PNaCl will achieve good portability+speed, NaCl's speed doesn't mean PNaCl will be fast too. Adopting NaCl because of the promise of PNaCl doesn't make much sense.
Yes I believe they're using a subset of LLVM for PNaCl. The whole idea is to define the semantics of how LLVM should be targeted there for it, since it normally does include some system specific things (how structs and things end up aligned when compiling C and the like). I think they're working on some "sane" defaults for all of those kinds of things so that they can target that subset with their compilers and then in theory run anywhere supported by LLVM. It's a very very interesting idea and if it does actually get anywhere it'll mean that there's a subset of LLVM that could be targeted by "native" applications for a similar effect, e.g. no need for a fat binary, just use the portable subset of llvm bytecode.
Would creating a Python interpreter that runs on Chrome's Native Client be enough? In NaCl you have an environment that lets you take C/C++ code and deploy programs written in that code to the browser. The Python interpreter (and the ones for several widespread languages) is written in C. Why not put the two together?
I've seen a proof-of-concept of this on webOS, which is essentially a browser since JavaScript programs can run natively. In webOS 1.4.5 and above, there is the PDK, which is a library that lets you make C/C++ programs compatible with webOS and run them on-device. Part of the PDK is the plugin interface, which allows JavaScript code to call C-compiled functions, which the C-compiled program exposes to JavaScript with special PDK functions.
Since the Python interpreter is in C, it can be adapted with the PDK to allow Python programs to run natively. Here is a post demonstrating it:
In Chrome, NaCl is analogous to the PDK, so why not have Python as an NaCl plugin and use it to run Python in the browser? You have to imagine that if NaCl gets widespread use, similar and compatible technology will pop up in competing browsers, so sooner or later your Python will be cross-browser.
Sure, Silverlight can run Python, but Microsoft has stepped away from plugins in IE10, and SL/ML run poorly or not at all in most other desktops and tablets.
As a user of Real Programming Languages (Common Lisp, Java, C) I'm indifferent to scripting languges, but if I had to choose ONE to see in the browser, it would be Lua.
It has sane, symmetric minimal design that gets closures. It also looks like a programming language. I can type Lua into the Firebug repl and not worry about indentation.
Of course Python is a Real Language, it exists, etc, yes. But it's not a Real Programming Language.
You see, everyone using python, ruby, perl, php, and other similar platforms - we're not programming, we're just scripting. The difference is so extreme, that, well... if you don't understand, I'm not going to bother explaining.
Sorry too - I should have added a sarcasm tag (or, more appropriately, a sarchasm tag).
I've been doing PHP for 16 years (among other things), and have grown tired of the "scripting vs whatever" debates/comments/remarks/jibes/etc over the years. That didn't come across enough in my original post - sorry. :/
(with-devils-advocacy
A Real Programming Language is one that can be used (and has been used) to implement its own compiler or interpreter
)
That said, by this definition Python qualifies.
Even that isn't a great definition as there have been interpreters for Brainfuck, why probably shouldn't be regarded as a "Real Language", written in Brainfuck:
So Python is a scripting language and not a "real programming language"? - What a stupid comment.
Python is a full and mature programming language, lots of software you probably use every day is written in it, like dropbox, calibre, miro or websites like Reddit and YouTube for example.
Sure you can use Python for scripting, but that doesn't mean it isn't a real programming language. It just makes it more versatile than other languages.
What we need is the JSVM! In other words, something like the JVM but adapted for the browser. That probably means it would have a more dynamic typing focus since it makes sense for JavaScript to be the primary language targeted by the system (though there's no reason this couldn't evolve over time just like the JVM has).
All of a sudden you don't need to build in Python support, or Ruby support or LISP support or whatever else you fancy into the browser. The browser no longer cares what you compiled the script from, it just gets the standard bytecode and everyone's happy.