Live data from Hacker News

Why we need Python in the Browser

archlinux.me

121–130 of 132 posts

Re: Why we need Python in the Browser

#121
post #116

Earlier quoted context omitted.

It would just run on Chrome, and it would just run on x86 and x86_64 machines.

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.

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.

Re: Why we need Python in the Browser

#122
post #116

Earlier quoted context omitted.

It would just run on Chrome, and it would just run on x86 and x86_64 machines.

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.

Re: Why we need Python in the Browser

#123

Earlier quoted context omitted.

Python also has lambda syntax, therefore closures are quite easy to do. Example: items.select {|e| e.isFoo} It's arguably more terse and superior to javascript in that particular feature as well.

That's Ruby, if I'm not mistaken. In Python you'd do filter(lambda e: e.isFoo, items)

It's more Pythonic to write

    [e for e in items if e.isFoo]

Re: Why we need Python in the Browser

#124

Earlier quoted context omitted.

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 tha…

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.

Slower and integrate less well than javascript?

C'mon.

Re: Why we need Python in the Browser

#125
post #114

Earlier quoted context omitted.

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?

> 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 pr…

Source-level debugging please.

Re: Why we need Python in the Browser

#126
post #114

Earlier quoted context omitted.

> 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 pr…

Source-level debugging please.

Agreed it's important. I believe several major browsers are working on that.

Re: Why we need Python in the Browser

#127
post #7

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 JavaSc…

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.

Re: Why we need Python in the Browser

#128
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:

http://www.ezequielaceto.com.ar/techblog/?p=359

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.

I'd like to see someone try Python in NaCl.

Re: Why we need Python in the Browser

#129
post #103
post #3

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,…

"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 othe…

> 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.

Re: Why we need Python in the Browser

#130
post #101
post #23

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…

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 wid…

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.

Post reply on HN