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.)"
Fortran is better. You're doing it wrong.
You can't legislate goodness. Let each to his own destiny, by will of his freely made choices.
Because it's done like this:
<?php
die(Python);
?>
signature is pants
Using python to GENERATE JavaScript, not python converted
To paraphrase Fyodor Mikhailovich Dostoevsky: "Why should such a troll live?"
Oh whatever.
Seems pretty pointless. Either learn a language or drop it.
I'd prefer native Ruby in browser though.
Quick way to get 30% Funny 70% Troll: defend Opera browser on
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.)
I write python webapps and sometimes there are things I'd love to do in the browser but can't. For example using pypdf or reportlab browser-side would be really useful .
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
Specially given it's Python, I'm really sympathetic towards Python. OTOH, all that "rich" content for webpages fetish bothers me a little. I tend to think of webpages as magazines or newspapers, I prefer text and static images only.
Just when you thought things could not get any crazier, there's this story. Let's hope it's an early April Fool.
There's no way one could simulate more than about 12% of Python's complex OO semantics in JavaScript.
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.
Not to mention many of the more useful Python modules have a considerable C component, making them completely unusable as JavaScript.
( Yes, I know, in theory JavaScript is Turing-complete, so you can do anything in it, given a universe full of CPU's ).
the initial experiment some months ago, with pyjamas 0.5, produced a python ACcellerator with a 10x performance increase; the latest 0.6~svn pyjamas compiler results in a python DEcellerator with a [finger-in-the-air] 10x performance DEcrease, thanks to the addition of several python strictness features
Of course, this is a 'just to do it' project', so I suppose performance is probably more of a secondary goal. :-)
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.
var mydingaling = document.createElement('select');
mydingaling.setAttribute('multple','multiple');
mydingaling.options.add( document.createElement('option').text = 'i want to play with my dingaling';
Doesn't javascript allow you to the majority of what was set forth as canonical in Lisp?
I wonder whether this would function correctly on the iPhone, because apple cannot restrict this, it is only JavaScript after all.
Ahaha you're so funny.
Now, GOTO \your_namespace because $this->is_off_topic(TRUE == "FALSE");
{{.sig}}
AAAHHHHHHH! It burns!
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 prefer a javascript assembler
...they used a Perl script to convert Python to Javascript.
Pfft! Python makes it easy:
import suicide-python
Silly rabbit
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.
I can finally make my browser fly!
Which, according to the "great" auto-conversion of PHP would print the string "Python" before exiting, because it converts unknown constant names to strings. If you put a "define("Python",0xFA1);" in above the die(), it will print the integer "4001" and return it as an errorlevel. If you instead use "define("Python",0xFA1.L);", it will just print "4001L" and not return it as an errorlevel.
That is, why "easier" is not always easier, but sometimes actually harder. The reason why we can't stand Clippy. The reason some can't stand many Microsoft or Apple products at all. (And many other "so easy an idiot could do it (but actually only an idiot still can do it!)" products. It'shalf the reason people have problems with computers nowadays.
And why the resulting idiocy of auto-typecasting is one of the biggest failures in programming language design ever. ^^
P.S.: Haskell FTW! ;)
Any sufficiently advanced intelligence is indistinguishable from stupidity.
[script type="text/python"][/script]. Let one of the major browsers implement it, and see if the others follow... there's probably already DOM-access libraries in Python, yes?
Seems to make a hell of a lot more sense than this translation stuff.
Comment of the year
Seriously guys. What the hell. We've reached some bizarro meta level of abstraction now. With things like this and GWT, we're just making things worse. I used to absolutely loathe javascript. Then, I took the time to sit down and actually _learn_ the language and it quickly became one of my favorites. It really can be a lot of fun.
Go watch Doug Crockford's presentations on javascript. He makes some excellent points about just how misunderstood the language is. Yes, it has some nastiness in it, but you don't have to and shouldn't use those parts. The vast majority of javascript books, tutorials, and web resources are just terrible. There's a lot of chaff out there to winnow before you find the wheat.
Download some of the better javascript libraries. Use them. Take them apart. Learn how they did things. Just start playing... seriously, it's fun.
I highly recommend MooTools, jQuery, Prototype, and their ilk. Rip those suckers apart and bend the browser to your will. Muhahah!
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.
Jesus Christ, man. It was a joke!
@import sense_of_humor;
And Microsoft removed Clippy like a fucking DECADE ago, get over it already.
Comment of the year
Who can string together the largest number of platform layers over each other, and still have it running.
The first league will start in the 2 GB core memory and 2* 2 GHz (dual-core) CPU range with no other processor (like GPU) or storage (like HDD) usage.
Every type of platform is only allowed once.
Here is a list of platforms, to get you started:
- Emacs
- the CPU itself
- Virtual machine (e.g. VirtualBox/VMware)
- Browser(s)
- C/C++
- JavaScript
- interpreted Piet
- Python
- LOLCode
- Malbolge
Bonus points for achieving a circle jer^H^H^Hof platforms, so that no actual real program is ever executed.
Any sufficiently advanced intelligence is indistinguishable from stupidity.
I know everyone hates Microsoft and its eeevil proprietary technologies but still, it can achieve nice things. A javascript library which parses python script-tags via Silverlight. Check it out: http://visitmix.com/labs/gestalt/
...is to be buried deep down under ground and never see the face of the Earth again.
What I mean is that we don't need browsers, we need a code/data distribution system that lazily downloads application components/data.
It has been first converted to Javascript, then executed.
Cruel and unusual perhaps, but it is certainly dead now.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
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.
Coincidentally, that's exactly why Microsoft has the least secure operating system on the planet.
Are there any open source web browsers written in Python? If so, I would like to run it in these JavaScript python interpreters so I can browse the web.
Python was created based on the philosophy:
"Well, the only reason people don't like Lisp is because of all the parenthesis"
and, for good measure:
"And Lisp-people don't like curly-braces, so let's not use them, either"
Compiling Python to JavaScript running in a browser really is like putting lipstick on a dog.
Nice.
The CB App. What's your 20?
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.
That's pretty cool actually :-D
What this tells us is that we didn't need a standard web-language. We needed a standard web virtual machine. I guess, the JRE and Flash really are those things. Javascript really isn't.
There are also a few implementations of Smalltalk using Javascript:
http://gwt-smalltalk.appspot.com/
http://clamato.net/
http://tinlizzie.org/ometa/ometa-js-old/
We heard you like converting, so...
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
I saw this... elsewhere.
This seems outdated: map is a method as of 2.6, and you wouldn't use map anyway since comprehensions are preferred.
The last complaint could be mitigated by writing a regular function, too.
This seems outdated: map is a method as of 2.6, and you wouldn't use map anyway since comprehensions are preferred.
No, it's not "outdated". Using the keyword is the "officially" recommended way of using map.
http://docs.python.org/tutorial/datastructures.html#functional-programming-tools
As nice as list comprehensions are, they're a bad method of chaining functions, because it is achieved by nesting, at the syntactic level. Something like:
[ (lambda x: x) for x in [ (lambda y: y) for y in list] ]
If I want to apply another function, I get to move that whole list construct into a new one. Or rewrite, but that defeats the purpose of using powerful and expressive tools. We already saw what that would look like if Python was awesome:
list.map(lambda x: x).map(lambda y: y)
Functor composition is expressed by simple concatenation. That's much easier to read, write, and maintain.
The last complaint could be mitigated by writing a regular function, too.
Brilliant. Let's break encapsulation for every single utility function a model might use.
Get your facts straight, Microsoft didn't remove Clippy, they promoted him to behind-the-scenes CTO.
I know it is very capable, flexible, and many frameworks exist to shortcut many common sequences of javascript used in sophisticated application development. I can respect a Javascript developer and not doubt for a minute they can code up fully capable stuff (particularly in conjution with HTML5 features including canvas). I won't claim that Javascript doesn't have a decent debugging strategy (i.e. firebug). I even appreciate the fact that sometimes, the community is better of just picking *something* and sticking with it in the name of standardization even if something universally more popular yet not much more featureful comes along.
However, while I recognize that what I can do isn't so different from what I can do in other languages, it is how I have to do it. I find the syntax to share too many of the characteristics I find distasteful about Java, namely typically tedious steps to do most of what I want. Some of it is the language itself, some of it is the relative complexity of manipulating HTML DOM elements and CSS compared to most modern desktop APIs, and some more of it is the network access model being a bit more limited than arbitrary sockets for certain tasks. Writing a Perl GTK program or a WxWidgets in Python (though I'm less fond of Wx) is, to me, just a lot easier than Javascript/HTML/CSS environments.
XML is like violence. If it doesn't solve the problem, use more.
I thought he was store manager at the first Microsoft store that opened.
signature is pants
Awesome.
I think the problem here is that you don't know anything about python.
No, it's not "outdated". Using the keyword...
It's not outdated, because it's completely incorrect. map isn't a keyword, and never has been; it's a function.
As nice as list comprehensions are, they're a bad method of chaining functions, because it is achieved by nesting, at the syntactic level. Something like:
[ (lambda x: x) for x in [ (lambda y: y) for y in list] ]
If I want to apply another function, I get to move that whole list construct into a new one.
No, a comprehension looks like:
[f(x) for x in l]
So if you want to apply another function, you write:
[g(f(x)) for x in l]
The function composition occurs the same way it does anywhere else - by applying one function to the result of another.
The last complaint could be mitigated by writing a regular function, too.
Brilliant. Let's break encapsulation for every single utility function a model might use.
I have no idea what this means. Functions created using lambda and functions created using def are exactly the same. What kind of "encapsulation" is "broken" by using a regular function, but somehow isn't broken by using a lambda?
How about Google Web Toolkit?
Robert Oschler - RobotsRule.com
If you hate javascript, you're doing it wrong.
Prototype-based OO by itself is a pretty neat idea, and it has many strength, but JavaScript isn't a particularly good implementation of it - it's burdened by ugly "Java-like" curly braces syntax, and legacy quirks like brain-dead local variable scoping. There really isn't much to love in there - the same ideas have been implemented much better elsewhere.
(Note: don't try any of the above SVG demos with FF2 or IE6; they will suck.)
IE6 sucks now. It will continue to suck tomorrow. It sucked yesterday. There was no day when ie6 did not suck.
"; ".join(["%s, %s" % (a.surname, a.given_name) for a in self.author.order_by('surname')])
It's not outdated, because it's completely incorrect. map isn't a keyword, and never has been; it's a function.
So is it a reserved word, or not? Does your "point" mitigate my observation that map is essentially a reserved word? Does it change the point that it, and join are poorly designed and actively get in the way of maintainable programming?
No, a comprehension looks like:
[f(x) for x in l]
Which is exactly what I wrote, only I did nesting.
So if you want to apply another function, you write:
Wow, thanks for nothing. And if you want to filter the results of an operation, and then apply an expensive operation to those results, what do you do? What if you want to filter those results?
From the documentation, the first operation would be something like
[ expensive_operation x for x in list if (satisfies_first_predicate x) ]
Which means that if you want to filter these results, using a list comprehension, you need to
[ x for x in [ expensive_operation x for x in list if (satisfies_first_predicate x) ] if (satisfies_second_predicate x) ]
(I didn't see that one coming, when I said nesting is necessary...) What's more readable? That? Or...
...?
list.filter(satisfies_first_predicate).map(expensive_operation).filter(satisfies_second_predicate)
Be honest. Which is easier to maintain?
The fundamental insight is that map, filter (and a few others) are all "functors" on lists.
Haskell has a notion of "monad comprehensions", which let you "pull" elements from arbitrary monads. So a monad comprehension is a generalization of a list comprehension. And they are more useful, since you can use the same programming paradigm on lots of similar data structures (that do not need to be lists, or even collections...)
People typically don't use monad comprehensions very much, despite being far more useful, because they introduce multiple syntactic forms for functor application. If you have a list, you want to do "something" with it. And it is much easier on you when all those "somethings" take on the same syntactic form.
I have no idea what this means. Functions created using lambda and functions created using def are exactly the same.
For one thing, functions are named. Lambdas are not. So they're not "exactly the same". The difference is an important one.
I take it you haven't been doing much professional programming, and probably have trouble with reading comprehension. The rant was pretty clear about why that circumstance was utterly stupid. Using a lambda is fine, when it is clear. Map and join notation make it unclear. Ergo, you must moved to named functions. But named functions live in namespaces or classes. Here is the appropriate part of the rant:
That's okay and all, but list comprehensions can require nesting. That's not good for maintainability. In fact, it is very bad. The sorts of things that ought to be thoughtless exercises (adding a hook to filter a list, so that you can pass the hook a function) become non-trivial exercises in themselves.
Consider the idea of taking a list, filtering by some predicate A, applying an expensive operation on the filtered list, and filtering the new list on some predicate B. Using list comprehensions, the "inner" list is:
[ expensive_operation x for x in list if A x ]
If you want to filter, and continue to use the same syntactic form, you have to do
[ x for x in [ expensive operation x for x in list if A x ] if B x ]
The fact that my eye has to go left and right and left and right, to find governing filters, braces, and so on, make it much harder to read to the equivalent (if Python was awesome)
list.filter(A).map(expensive_operation).filter(B)
I can keep that construct up for a few dozen method calls, and it will still be clear. Try nesting even four or five list comprehensions.
And I still think "; ".join is disgusting. I don't mean to be condescending, but do you know what a "join" is? http://en.wikipedia.org/wiki/Join_(mathematics)
After all, I am strangely colored.
I think the problem here is that you don't know anything about python.
I know enough about python to know that your attitude is typical among Python users.
So why is a list comprehension better than something like
list.filter(A).map(function).filter(B).map(C).filter(D)?
How would you even express something like that? Nasty nesting, I'm sure. Even if you use "map" and "filter", you're screwed. You have to nest, because of Python's idiotic definitions of map and join.
And I'm sure you're not experienced enough to know why my version is significantly better. In effect, it's better because the important parts of every step are ALL RIGHT OF the textual representation of the last operation. So you DON'T need to move your eyes back and forth to keep track of scoping. So if you want to add a step to the computation on a list, you just add it at the end. If you want to add an intermediate step, you find where it goes, and insert it.
After all, I am strangely colored.
... the hard way ...
I might be daft, but I don't think there is an easier way to run python in a browser. Please enlighten me.
Show a man some news, distract him for an hour. Show a man some mod points, distract him for the rest of his life.
It doesn't matter what a mathematical join is, python is using join in the sense of attaching multiple things together, the regular English meaning of the word.
You don't need to nest the comprehensions, simply use multiple lines:
result = (item for item in list if predicate(item))
result = (item for item in result if predicate2(item))
result = [expensive(item) for item in result]
Maybe it's not as nice as the method based filter/map, but it shows you don't have to horribly nest comprehensions like that.
In other news, if you do something completely stupid with a programming language, the language will respond in kind.
The land shall stone them with the bread of his son.