Slashdot Mirror
Python Converted To JavaScript, Executed In-Browser
lkcl writes "Two independent projects, Skulpt and Pyjamas, are working to bring Python to the web browser (and the JavaScript command-line) the hard way: as JavaScript. Skulpt already has a cool Python prompt demo on its homepage; Pyjamas has a gwtcanvas demo port and a GChart 2.6 demo port. Using the 64-bit version of Google v8 and PyV8, Pyjamas has just recently and successfully run its Python regression tests, converted to JavaScript, at the command-line. (Note: don't try any of the above SVG demos with FF2 or IE6; they will suck.)"
Because it's done like this:
<?php
die(Python);
?>
signature is pants
It's not entirely clear to me what Skulpt is exactly, but Pyjamas is apparently GWT ported to Python, which sounds like a really cool idea. Now if somebody did the same thing with Ruby and Scala, I'd be really happy.
Javascript is just way too stupid to program manually, but currently we're in the odd situation where we're writing server stuff in Ruby, and browser stuff in Java. That's just wrong.
What a waste of time and energy. The only thing worse than Python is, well, Javascript.
That is exactly the whole point that you're so obviously missing here: nobody sane should have to write Javascript, and yet it's the only thing that's supported by browsers. So converting code from other languages to Javascript is the only sensible solution at the moment. (For the longer term, it'd be nice if they replaced Javascript with something halfway sane.)
In most ways (no explicit integer type being an exception) Javascript is a remarkable and beautiful language. It has libraries available on a server near you through Dojo, among others. Javascript is one of the best things about browsers.
What browsers need is a workable CSS and DOM interface (although the DOM interface has improved in recent years). But these are not issues with Javascript per se. Cleaning up the browser programming environment is not about getting rid of Javascript.
From TFA: """
anyway, just thought there might be people who would be intrigued (or
horrified enough to care what's being done in the name of computer
science) by either of these projects.
"""
Not horrified, but I wonder if W3C politics is creating unforeseen consequences.
Verbum caro factum est
There is already a Ruby VM that runs in a browser: Hotruby : http://hotruby.yukoba.jp/
John Resig even blogged about it ages ago: http://ejohn.org/blog/ruby-vm-in-javascript/
Also, JS.class, while not a Ruby VM, is pretty cool and actually useful: http://blog.jcoglan.com/2009/06/08/jsclass-21-an-improved-pacakge-manager-proper-hashes-and-lots-of-ruby-19-goodness/ - http://ajaxian.com/archives/jsclass-21-released
{{.sig}}
I'd be interested to hear what you like better, and why? Personally I'm still sad that Java (not Javascript) didn't win on the Web - a cross-platform, general purpose language that is at least a reasonable choice for most anything. To make programming faster, you can always use higher-level libraries or code-building environments on top of it, or compile some other syntax to java bytecode.
Now instead the Web is a big mish-mash of fundamentally incompatible technologies. And if anybody does pull off the one-runtime-for-anything vision, it looks like it will be Microsoft.
Just when you thought things could not get any crazier, there's this story. Let's hope it's an early April Fool.
nope. it's not. and i didn't mention in the article that pyjamas-desktop can run the python as a desktop app, either. including the GWT Canvas ported code, under the MSHTML engine. after all, the IE/MSHTML gwtcanvas is just creating VML nodes, so perhaps it shouldn't come as a surprise that it works, but it's still pretty cool all the same.
There's no way one could simulate more than about 12% of Python's complex OO semantics in JavaScript.
wrong. sorry. javascript is a drastically underestimated language. dreadful to work with if you don't know what you're doing, but incredibly powerful at the same time.
a javascript implementation of "type" - not the 1-arg version but the full 3-arg version - was initially implemented in 85 lines of javascript (it's a bit more, now).
we use that functionality to dynamically create, classes, supporting multiple inheritance and more.
pyjamas has also implemented decorators _and_ properties; kees is currently working on "yield" after skulpt's developers started working on it. not "yield by cheating and using FF built-in support for yield", but "yield" as in doing it the hard way, by analysing the state of the function and adjusting / jumping to the correct point in the function on each loop.
you really should take a look at the regression tests
Python itself already has a hard and slow slog trying to perform all its tricks.
To add yet another layer of translation or simulation sounds like a lose-lose proposition. Slower and hopelessly inexact.
slower, yes - "hopelessly" inexact: no. for GUI purposes, _if_ you've designed the application correctly (i.e. along MVC / client-server lines), then the "-O" option which switches off all the python "strict" compatibility, is perfectly sufficient.
so, "letting things fall through" to javascript, and allowing int(width) + "px" to succeed, and [1,2,3] + [4] to fail, is "good enough for most purposes".
Not to mention many of the more useful Python modules have a considerable C component, making them completely unusable as JavaScript.
wrong again. sorry. two reasons. three.
1) pygtkweb showed that it is perfectly possible to make a seamless / transparent JSONRPC service that ships function call arguments over to a server, for execution server-side, starting from e.g. "import md5"
2) pyjamas' implementations of datetime, md5, urllib, time and a few others is growing as users contribute to them. thus, the pyjamas GUI library fits the *users* needs, on an ongoing basis.
3) if you _really_ can't do without the full semantics of python, but want the benefits of full HTML, CSS, NPAPI plugins etc., use one of the pyjamas-desktop ports. there's MSHTML, XULRunner and PyWebkitGTK to choose from.
As a high school computer science teacher, I can see a practical application of this. Currently, I think Python is one of the best languages to learn basic programming concepts with, in that it is relatively straightforward, powerful, and there's not much "voodoo" to prevent students from diving right into programming. It's possible to do some really cool things in Python with not much code.
However, one of the problems is that it can be difficult to give students a way to show off their code. Since it's an interpreted language, they can't just give an .exe or a .app file to someone else to show it off - they need to say, "Oh, go and install Python, and these libraries, etc." Yes, there are solutions such as py2exe and py2app, but getting these set up can be quite a task in itself. By running Python inside JavaScript, you basically open up the whole web-connected world as a potential audience to these budding programmers. It's much easier to say, "Hey, check out this link!" than "Hey, download Python (but get the right version) and this graphics library, then download my .py file, and open up a command prompt and type python blahblah.py!"
Announcing onelanguage dot com, an extension of Google Translate, ushering in an era where programmers need only learn one language and have it converted to another language of choice.
FAQ:
Q. How accurate is it?
A. Same as Google Translate. You have to learn the output language to know which parts of the language you already know result in garbage-out. We suggest you use our new Pidgin versions of Python, PHP, Java, and Ruby.
Her lips were softer than a duck's bill, but her quacks
I have an iPod touch running iPhone OS 3.1.1, so I tried these two projects out.
Skulpt works, but the console does not (I had to use the quick-links to test code). This is relatively easy to fix by using a textbox instead of using keyboard events. It would be very simple to write a simple webapp which evaluates Python code in the Safari browser. However, as I see it, Skulpt is still quite immature -- it doesn't implement much of the language (e.g. classes work, but can't be instantiated because Skulpt thinks you are trying to call the type object, instead of constructing it), and it doesn't do imports at all.
Pyjamas works extremely well, though it is compiled as pure JS and thus lacks (AFAIK) an "exec" method to run arbitrary Python code.
Given that Skulpt features a decent Python parser but lacks much of the core functionality, and Pyjamas implements a lot of functionality but lacks a parser built in JS, I think the projects would be mutually beneficial.
I prefer a javascript assembler
Pyjamas works extremely well, though it is compiled as pure JS and thus lacks (AFAIK) an "exec" method to run arbitrary Python code.
i'm working on it. last week i back-ported skulpt's parser and AST code from javascript to python, and regression-tested it; now it's a matter of improving the pyjamas compiler to be able to successfully compile that python into javascript, and we're bootstrapped.
...they used a Perl script to convert Python to Javascript.
Found something better: 6502 assembler!
I felt the same way until I watched Douglas Crockford's videos on javascript. If you hate javascript, you're doing it wrong. I now prefer it to the other languages being discussed here.
there are a ton of different ways, now: i've been maintaining a list on the python wiki, WebBrowserProgramming page. pypy used to have a -to-javascript back-end (now abandoned); there's titanium appcelerator (which supports IronRuby and IronPython); there's PyXPCOMExt and a few more besides.
Well, haXe is a Java-like language which compiles to Javascript among other languages. It's definitely general purpose enough to use in the client as well as the back-end, and it has nice libraries which make communication between them easy. It happens to compile to Flash, too. I'd imagine that any reasonably complex project could be built just about entirely in haXe.
This author takes full ownership and responsibility for the unpopular opinions outlined above.
That'd be damn hard. Python isn't made for sandboxing (google python and sandboxing, or restricted execution, and you'll see). If you did the script language=python implementation the "obvbious" way and just linked in the python interpreter into mozilla, you'd have a security hole big enough for a supertanker. There is Python support for extensions though - google PyXPCOM.
--The knowledge that you are an idiot, is what distinguishes you from one.
Python is quite a good language, but the implementations suck. This is holding back widespread use of Python. It's too slow, typically 10x to 30x slower than C. That's far worse than Java.
There have been several attempts at other implementations. But because Guido Rossum fights formal standardization of the language, treating his CPython implementation as a de-facto standard, everyone else has a moving target to hit.
Google (who hired Guido) likes Python, but they don't like the low performance. CPython is a "naive interpreter" (very little optimization). Worse, with the rather lame implementation the Global Interpreter Lock, not only can't it use a multi-core CPU effectively, multi-thread programs run slower on multi-core CPUs. (The threads fight over the lock in an embarrassingly inefficient way.)
Google is doing "Unladen Swallow", which is an attempt to bolt CPython to a just-in-time compiler to a virtual machine. It's not clear how well that will work out, but the end result will have more layers than seems to be indicated. The goal is 5x faster than CPython, which won't beat Java, let alone C/C++.
It's cute that Python to JavaScript translation is possible, but it's not going to help much on the performance front.
For a few years, the great hope of the Python community was PyPy, but that had too many goals, was being developed in "sprints", and after five years, the European Union pulled the plug on funding after it was slower than CPython.
Shed Skin, which is a Python to C++ hard-code compiler, is currently the lead in Python performance, but it doesn't yet implement the whole language. Still, with about two people working on it, Shed Skin is doing better than most of the bigger projects. Shed Skin does automatic type inference. Python doesn't have declarations, but with enough analysis, the compiler can figure out what types each variable can hold and generate hard types, which makes for much faster code.
Compiling Python to JavaScript running in a browser really is like putting lipstick on a dog.
Because it IS easier to use and hardware is always getting cheaper.
On the server side, 10x to 30x slower means building entire buildings full of servers. Or more expensive hardware in the cell phone. Or using another language.
Python is actually a good general-purpose programming language, not just a "scripting language". The big problem is slow execution.
The basic problem with CPython is that, being a naive interpreter, it has to check for the hard cases every time. "n = n + 1" ought to be a few machine instructions, maybe only one. But Python has to check for n being a float, n being a string, n being an object, etc., every time. Shed Skin, with a type inference systems, does analysis at compile time and determines that n is always an integer, then generates code for integer arithmetic only.
There are all sorts of dynamic things one can do to a Python program while it's running. You can add a function to an object. You can replace existing functions. You can load new modules on the fly. But most of the time, for most of the objects, you don't do that. An efficient implementation needs to separate out the cases where something unusual might occur, and the far more common cases when the program is doing routine stuff that needs to go fast. The common cases can then be handled with much simpler, and faster, code.