Slashdot Mirror

Wait, there's a Puhon plug-in for web browsers? Awesome! Where can I get it?

You can plug-in Python programs using IronPython and Silverlight. But there's no need for a plugin - there's surprisingly plenty of support for client-side Python: Brython, Skulpt, Pyjs et al.

when we gonna get python.js?

Now, apparently:

pyjs contains a Python-to-JavaScript compiler, an AJAX framework and a Widget Set API.

if you want a physics dynamics engine, you want ODE. if you want a small amount of code (a high bang-per-buck ratio for the students i.e. they get results fast), use python. ODE has python bindings, so you win both ways. there are plenty of example recipes for python-pyode with OpenGL and pygame, which you don't entirely have to "understand", just copy cut/paste just like any other programmer would, and it gets the job done.

now, if you're looking for web-based, i cannot recommend "pure javascript". it's too much like hell on earth: you'll be teaching the kids the wrong lessons (namely: stay the hell away from web development).

i _can_ however recommend pyjamas. we have 3 or 4 example games already done: one uses SVG Canvas, it's "asteroids". then there's minesweeper, hangman, lightout and i also wrote a sudoku game a year ago. not one single one of those examples is over 1,000 lines of code. i think the asteroids one is about 600. http://pyjs.org/examples

the nice thing about pyjamas is that you don't have to "mess about" setting up the libraries. you just go straight in. thus, the bang-per-buck ratio (lines of code required to achieve a particular goal) is very very much higher than average.

Meh. Pyjamas is better.

You mean like Sprixel? There are already a number of compilers for other languages, such as Java, Python, and Javascript, oddly enough. List of languages that compile to JS has many more.

It certainly does make things a little bit more bearable with larger projects. I work with pyjamas which is a python port (also trimmed down a little) of GWT and it really is an exceptionally powerful toolkit.

this "tug-of-war" between the "top" companies is why i created pyjamas-desktop, maintaining pyjs (the python-to-javascript compiler) and am giving thought to extending pyjs to output flash actionscript (it's very close to javascript).

pyjamas applications are written in python, and, across _five_ web browser types and now as of last week _six_ different web browser engine types, the applications themselves - python scripts - genuinely do not give a stuff about the underlying technology being used.

this is how *we* "win" - by making whoever "wins" the browser "wars" effectively irrelevant. MSHTML, webkit, xulrunner, it's all the same.

http://pyjs.org/ if you're interested in the concept - perhaps someone will eventually follow in the footsteps here and get RubyJS back up-and-running (it's on rubyforge), and perhaps create a port of GWT to the desktop as well, and maybe, god help us, even a perl version of pyjamas / GWT.

You might as well just compile python to javascript

Some people do.

http://pyjs.org/examples/asteroids/output/Space.html
using pyjamas http://pyjs.org/

http://pyjs.org/examples/asteroids/output/Space.html
using pyjamas http://pyjs.org/

ahh, the summary is wrong both from a W3C DOM standards perspective, because java is listed as the 2nd language supported by the W3C. the summary is wrong from a second perspective in that language bindings to HTML5-compliant web browser engines such as XulRunner and WebKit have been available for years. if Microsoft actually intend also to follow the HTML5 process properly, then it can be said that MSHTML, through its COM interface, also offers other language alternatives for decades rather than just years.

now it's a sad fact that nobody really *knows* that you can get at HTML5-compliant web browser engines and use DOM functions (3000+) and access DOM properties (20,000+) through XPCOM, or Glib/Gobject or COM, but it's perfectly possible. the best demonstration of this at its most extreme limit, taking advantage of absolutely all HTML5 W3C DOM features, is the http://pyjs.org/ pyjamas project, which abstracts the differences between these three major web browser engine types (XulRunner, Webkit and MSHTML aka Trident) and presents a single uniform API. on top this uniform API, normalising the discrepancies between the three engine types, an entire Desktop GUI Widget Set API has been created.

so the statement that there is "one HTML5 language: javascript" is just nonsense. for further examples of accessing HTML5 DOM using python, some of which will lead through to links to Ruby accessing HTML5 DOM such as AppCelerator, see http://wiki.python.org/moin/WebBrowserProgramming

Tried Pyjamas?

http://pyjs.org/

I'm sure something similar is feasible for Ruby too.

It certainly is.

And there's also a Python port of GWT, very aptly named pyjamas.

Why not just refuse to use non-standard features, browser sniffing, etc. Accommodating multiple broken browsers just perpetuates the "we don't need no stinking standards but our OWN!" mentality.

the existence of dynamic framework compilers such as Google Web Toolkit and Pyjamas makes it perfectly possible to accommodate "multiple broken browsers".

in the pyjamas case, the result of the compilation command is no less than FIVE completely separate applications: one for each (wildly incompatible) browser. user-agent string detection then redirects at run-time to the correct application.

this is just a "merging" trick that is applied at compile-time, by taking two ASTs (python abstract syntax trees), walking the top-level looking for classes and functions of the same name, and merging them. the resultant "munged" AST is then passed to the compiler, and used to spew forth javascript. the process is repeated for each of the five platforms.

this "trick" is actually something that even the developers can take advantage of. see browserdetect for the absolute most basic example (source code 2 levels below).

Why not just refuse to use non-standard features, browser sniffing, etc. Accommodating multiple broken browsers just perpetuates the "we don't need no stinking standards but our OWN!" mentality.

the existence of dynamic framework compilers such as Google Web Toolkit and Pyjamas makes it perfectly possible to accommodate "multiple broken browsers".

in the pyjamas case, the result of the compilation command is no less than FIVE completely separate applications: one for each (wildly incompatible) browser. user-agent string detection then redirects at run-time to the correct application.

this is just a "merging" trick that is applied at compile-time, by taking two ASTs (python abstract syntax trees), walking the top-level looking for classes and functions of the same name, and merging them. the resultant "munged" AST is then passed to the compiler, and used to spew forth javascript. the process is repeated for each of the five platforms.

this "trick" is actually something that even the developers can take advantage of. see browserdetect for the absolute most basic example (source code 2 levels below).

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.

And now you can do it in Python with Pyjamas.

The experimental combination of the Python-to-Javascript compiler, http://pyjs.org/ and the Python Bindings to Google's V8 Engine, http://code.google.com/p/pyv8 brings a ten times performance increase over standard python, already.

not - "10% now and 5x in the future" - that's a 1000% increase NOW.

When V8 supports the ECMAScript "Harmony" standard, which will include support for basic integer types, then there will be "correct" support in the PyJS + PyV8 combination for numerical types, and the word "experimental" can be dropped.

http://pyjsorg/ also includes an experiment showing the bindings of the PyJS compiler with the Python-Spidermonkey project. The spidermonkey JS engine has the advantage of running on generic platforms instead of just ARM and 32-bit x86 platforms, but has the disadvantage of being slightly slower.

Javascript is a _really_ interesting language that makes it in many ways highly suitable as an intermediate compiler language for compiling dynamic languages as Ruby and Python.

Currently what you find is that Javascript does not have a good interface to the system, without native javascript APIs for open, read, etc, and without a standard set of hooks into C programs. This is entirely because of javascript starting in the web browser, but what you'll see is people developing these and then ...

I should rest my case here.

But, jsut for nto being so dry, I will write on:

The Syntax: javascript doses use an archaic C syntax - which is nice when you have to closely follow the way the processor is behaving inside so you can have maximum effectiveness and even have a good idea of the machine code generated as you write it. The only good reason this syntax was choosen is that it...resembles C! Python syntax drops some punctuation so that the language resembles the way we do think our algorithms when we address our problems (at least in western Languages like English and Portuguese). As other peopl have noted in this thread: it resembles pseudo-code.

As an example, pick the integer dependent "for" statement - when you can have those in high level. (yes I know there is a "for each" in javascript. I tried to use it once, only to learn it would work only in some browers, so nobody actually uses it)

Finally: Python is there already, it is not "going" anywhere. One of the strrnghts in python is exactly the ease to open and manipulate files - to single method calls and you have the data in memory, ready for manipulation - and you just admited javascript can't read files at all. And if current javascript engines are faster than the standard python implementation's engine, no problem in there as well: python with it is nicer, higher level syntax can be seamlessly translated to javascript and run on javascript backends for at least two different projects (Pypy and pyjamas).

No trolling here: just try a bit of Python - it is much better to write (and read) than the C legacy syntax of Javascript.
And there are a few goodies in the language that javascript don't do, for example: namespaces, and trying to access an as of yet unattributed variable yields an error - it may sound simple, but saves hours on debugging complex incorrect behaviors derived form small typos in variable names.

That said, I agree with you that the javascript VMs are evolving at huge steps with Apple, Google and Mozilla each trying to deliver a faster engine. And I will be running Python (auto-translated to javascript if needed) on those - on client side web pages. Up to there, I will just use native python to do desktop GUI programing, web server apps, network and server management tasks, videogames, scientfic computing, and so on.

With compilers like GWT, Pyjamas, and HotRuby, I sometimes wonder if JavaScript is starting to emerge as a "portable assembly language" for dynamic languages, the way C is often used by higher-level language compilers. I mean, when it comes down to it JS is basically just hash tables and closures, some of the basic elements required for dynamic language execution.

Given a fast-as-C javascript engine, you could have a pretty decent VM to share between several dynamic languages, and due to JS's dynamic nature compiling these languages to JS is fairly trivial.

I mentioned this once on reddit and someone called it a 'braindead' approach. That may be true. I'm not sure. He also pointed out that many things you'd have to do to get languages like Ruby running in JS would require passing the context as a function argument, which he claimed would probably bypass any potential optimization by the JS compiler. Not sure about that either.

But I find it really interesting (and cool!) that JS's heavy web presence is giving it such attention in both the "compiler backend" and optimization departments simultaneously. Whether it's a braindead approach or not, it sure seems to be drawing a lot of interest lately.

Stick a full VM into the browser. Problem solved. Except of course for the huge resources needed to view even the simplest of pages.

The entire push over the last few years to transferring processing load back onto the client is the wrong direction in my opinion, and the browser should remain a THIN client like the original intent. Keeping it a thin client by nature would be secure.

noooo, nonono can do - yes it would be secure, but times have changed _drastically_. what's happened is that as the desktop wars got ridiculous (and i don't just mean between different OSes, i also mean between win95, xp and up), people simply moved to the browser itself to provide access to applications. all the talk of "ubiquitous computing" has actually _happened_.

and, as the expectations of web infrastructure got ever greater, that origial "thin client" architecture began to look... well... thin! so along came flash, and javascript, and god help us java, and then AJAX, and then GWT and Pyjamas which _really_ make it clear that the browser really _is_ just another "widget set" like Python-QT4, Python-GTK2 or Java Swing, and somewhere rather unfortunately along the line silverlight got added to the mix.

and once you're down this road, there really is no turning back. you're now running complex comprehensive applications such as gmail.com, google apps and WebOS and i do _mean_ applications side-by-side in the same "space" and it's just getting too much for the poor little browsers, which were never designed to act as "operating systems".

so i think what we're seeing here is the recognition of the fact that browsers have to become what OSes were designed to do, because browsers are now taking over from what OSes were _supposed_ to be doing, because everyone's moving inexorably to online interaction, now, instead of "isolated desktop".

so is anyone _really_ surprised that the solutions proposed are to use tried-and-tested proven technology, just moving it to where the focus has gone? current browser technology can be compared to OS technology of the Windows 1.0, GEM/DOS and early Mac era!

i've done event-driven vehicle simulators; i've clean-room network-reverse-engineered MSRPC and NT domains protocols; i've ported freedce to win32; i've added glib bindings to webkit and on top of that, ported a port of GWT to python even _more_ into python by adding DOM manipulation to pywebkitgtk.

in amongst all that mindless drivel of alphabet soup you should be getting a pretty clear picture that i'm not a stranger to complexity.

i've learned that if someone says "surely it doesn't have to be as complicated as all that", it's time to run like stink as fast as possible, out of the conversation and the room, and never look back.

browsers are effectively desktop technology within a desktop (and damn good at displaying widgets), except you're letting the web site dictate what "programs" are allowed to be "run" on your desktop^H^H^H^H^H^H^Hbrowser.

browsers are no longer "just HTML displayers", they are actually executing applications - _real_ applications - that in many instances happen to be written in javascript. GWT, Pyjamas and RubyJS should all hammer that point home.

with that in mind, why is it so hard to then imagine that, given that the "browser" is doing everything that you can also do with desktop widget UI toolkits, why is it so hard to appreciate that you need the full range of OS technology to support that desktop^H^H^H^H^H^H^H^Hbrowser technology?

The problem is that I have yet to see an implementation through a browser that can challenge a native GUI implementation and yes this includes Sales Force, Google Mail, Google Docs and all the rest of them.

that's why i ported pyjamas to the desktop:

    http://pyjs.org/

pyjamas-desktop basically rips out all of the javascript, and replaces every single javascript-based function with exact same corresponding functionality that manipulates the DOM model of the underlying technology.

and i chose http://webkit.org/ as the DOM-manipulating technology.

i _could_ have chosen XUL / Gecko, but it took so damn long to find Hulahop - http://wiki.laptop.org/go/HulaHop - that i had to go for webkit.

i could have chosen PyKDE / KHTMLPart but it has very subtle bugs that require the entire KDE library to be compiled with c++ RTTI switched on. if it's switched off, the whole thing falls over.

by porting pyjamas to the desktop, it's possible to make the same application run as EITHER a desktop application (and i don't mean "running as javascript under Adobe AIR") OR a web application.

same source code. unmodified.

it's very cool.

web programming itself is completely misunderstood. HTML is a "display" mechanism, and people believe it to be "programmable".

then along comes javascript, one of the most fundamentally powerful yet utterly obtuse programming languages, and it gets "thrown in" amongst the "display" mechanism.

we've known for years that mixing HTML into a programming language and vice-versa is a bad idea: you only have to look at how people get themselves into an awful mess with PHP to appreciate that. in that respect, javascript is no different.

my take on this is that it's far better to do web client programming in a higher-level-language such as python or java. fortunately, javascript is an extremely good fit with python, and java has a limited subset of the dynamic capabilities of javascript, so is also a good (one-way) fit.

by programming in python, java or ruby and having it translated into javascript automatically, the fear that people have of getting into an awful AJAX mess goes away.

http://pyjs.org/
http://code.google.com/gwt

Javascript is an awful language to develop in, yet it is also incredibly powerful.

That makes it a better target as an "intermediate" language - as human-readable assembler, if you will.

There are two projects that allow web browsers to be programmed in much more understandable languages:

1) GWT http://code.google.com/gwt which is a java-to-javascript compiler and AJAX library

2) Pyjamas http://pyjs.org/ which is a python-to-javascript compiler and AJAX library

by using this kind of technology, not only do you get to write your code in a decent high-level language, subdividing it into modules, classes and functions, but also the technology takes care of all the browser incompatibilities - again, by putting them behind well-written modules and classes with a common API.

until AJAX was properly discovered, browsers were being treated as no more than "thin clients", where the HTML was generated by the server. AJAX has turned that on its head, as code is now being executed client-side (browser-side).

it's becoming increasingly clear that javascript is a wildly inappropriate language to do web development in, yet it's also not going to go away and, because it is so powerful, it shouldn't HAVE to go away.

and, if you have a compiler which turns decent high-level languages into javascript, automatically, javascript DOESN'T have to go away.

see http://advogato.org/article/985.html comment "a question and an open request" for more information on javascript compilers such as rb2js.

no don't laugh, it works very well! there are a number of very good reasons for this.

1) javascript is actually an incredibly powerful language, in particular due to the concept of "prototype"ing.

2) javascript, thanks to web browsers, has an unbelievably large amount of attention spent on it, to optimise the stuffing out of it. as a result, the latest incarnation to hit the streets - the V8 engine - actually compiles to i386 or ARM assembler.

3) the number of "-to-javascript" compilers is really quite staggering. see the comments from pyv8 article for an incomplete list.

GWT has a java-to-javascript compiler; Pyjamas has a python-to-javascript compiler. There's a ruby-to-javascript compiler - the list just goes on.

then there's the pypy compiler collection, which has javascript as a back-end. (and, for completeness, it's worth mentioning that it also has a CLR backend, LLVM.org backend, and a java backend).