Hacker News new | comments | show | ask | jobs | submit login

It actually translates Python into Javascript! I'm thoroughly impressed.

Another approach that may work in Chrome is to use Chrome Native Client to embed a 'proper' Python runtime.

I've often lamented that we have Javascript and not Python :( http://williamedwardscoder.tumblr.com/post/20771096806/why-d...

Completely agree that Python ought to be the default browser scripting language. Far, far better than JS. I've always been excited about the prospect of NaCl because it may be able to help us make that a reality in some limited contexts.

Python noob here, I am very interested in what you think makes Python a better browser scripting language than JS (which I use a lot on client and server side and like very much).

It is surely subjective. Not the person you reply to but I'll chip in anyway.

I write lots of Javascript; mostly 'raw' Javascript in the webGL space. Here's just of the top of my head what's wrong with Javascript:

* looping over elements has too much boilerplate

* the mindfulnesss of 'this' is distracting

* the duality of dictionaries and lists and how that's an easy lie to fall for is fustrating

* that there are multiple frameworks trying to use $

On the other hand, their anonymous functions are very nice. And, I rather like prototypes vs classes. A bit. Sometimes

With Python, I like significant whitespace (so sue me) and especially the syntax for collections and packing/unpacking them.

I've blogged along these lines a lot in the past e.g. http://williamedwardscoder.tumblr.com/post/18319031919/progr...

With that particular list of features and complaints, you may want to take a quick look at CoffeeScript. It addresses everything on the list except for the "multiple frameworks trying to use $" bit.

I think the $ point is a bit soft anyway. With jQuery, it's easy enough to just use non-conflict mode.

It's not often you want to use two libraries that both use $ anyway (e.g. you'd use jQuery OR prototype, Zepto OR MooTools - not usually both).

Funnily enough, it was trying to use a box2d port that used prototype in an app that already used jquery that raised my hackles most recently...

Both languages are very good. JavaScript has its kinks, but they are not hard to work around with library support or syntax translations (such as CoffeeScript). However, JavaScript's execution model is simple and doesn't provide as much value as the one in Python does, and this is something that is not easily addressed with libraries or (simple) translations.

By this I refer to that in Python, most syntactic constructs map to more primitive operations that are accessible (and overridable) in the language itself. For example, anything can be made callable, indexable, sliceable, iterable, etc., by providing the right interface. It is like operator overloading on steroids. Even attribute access (the dot operator) can be overridden in extremely powerful ways. This is great for library writers, who can use it to provide the simplest possible API to their users.

I also like very much Python's data model. Things consistently behave as references (even primitive values which all behave as immutable singletons, although of course they are not implemented as such). It just somehow fits and makes sense once you have the model in your mind. JavaScript is slightly less intuitive in this way, and while it makes sense once you understand it, there are a few caveats you need to keep in mind (variable hoisting, scoping, anticipating different context objects). Prototype inheritance works fine but requires a special mind-set, and to me it seems JS fits better for functional programming than object-oriented Java-style.

Python's shortcomings are mainly syntactical (not counting the shortcomings of CPython's implementation specifically), such as not having an easy syntax for function expressions. This is the main reason functional programming can get slightly awkward in Python.

ES6 will allow for low-level extensibility with Proxies (http://wiki.ecmascript.org/doku.php?id=harmony:proxies).

That's true, and definitely worth pointing out. I've used them a fair bit, and while they provide exellent power, they are slightly cumbersome to use compared to Python's pervasive "overloadability" (for the lack of a better word). But I would give them a chance to grow on me before passing any further judgement.

I just really, really prefer Python and think it would greatly simplify the whole process, make scripts much, much easier to read, write and modify, etc. It's basically an argument that JavaScript is bad. Not sure what the deal is with the cult of JavaScript that's been arising in the last few years but in my mind it's still Brendan Eich's quick "seven days to save the company" hack, and for that it's impressive, but it should have been deprecated a long, long time ago.

To be honest I'm not intimate enough with JS to give a big list of my biggest language-level annoyances off the top of my head. It's just a general distaste/annoyance that occurs every time I get involved in JavaScript code, either the reading or the writing of it. Python, on the other hand, is nearly readable by non-programmers, and is otherwise super cool. I recognize that others may have a different opinion on this than I have and while they're not necessarily wrong for themselves, I believe Python is more accessible in general.

I think the facts that a) almost no one writes bare in-browser JavaScript anymore, it's all through jQuery and b) CoffeeScript and other persistent "rewrite/simplify/improve JS" movements exist and keep coming up are ample evidence that the basic tools provided by the browser and the JS language are insufficient.

This more or less sums up what I despise about JS: http://bonsaiden.github.com/JavaScript-Garden/#intro. Python has way better language design. CoffeeScript may be better suited than Python though, because the callback-heavy nature of web programming is easier to tolerate when you have inline function literals and stuff, in my opinion.

I get the impression from the above that Python is easier to learn and read, which I agree with. How well it'd work beyond that by comparison, I'm not sure.

I love python but I'm not convinced that a language with significant whitespace is ideal for the web where formatting is too easily lost.

How is formatting "easily lost" merely by virtue of being used as a web scripting language? There's nothing that mangles whitespace of anything delivered over HTTP. Yes, if you include it directly in HTML for display without any kind of escaping, the whitespace will be collapsed. But if you'll notice, JavaScript is the current web scripting language, and it has significant whitespace (line endings). So it's not like having significant whitespace makes it unsuitable for the web.

Javascript is frequently stripped of all whitespace as part of the minification process. This includes removing all newlines and indentation. This would a good bit harder with Python.

Yes, they'd have to come up with something else to get equivalent results from minification, like a special minified dialect where whitespace characters are replaced with another unused symbol (perhaps a canary-type header like the coding: thing). If this is determined infeasible they'd probably just have to accept that the whitespace needs to be transferred, which honestly I wouldn't really consider a bad thing.

Minification should not be considered as a major reason to forgo the benefits of alternate scripting languages.

The answer lies in between, ES6 borrows from python (as many other languages). I personally would love a coffeescript~ to be the one.

NaCl is not needed for that. Embedding CPython into the browser has been done for some time now with Emscripten. Here's a demo: http://syntensity.com/static/python.html

This has the advantage over NaCl that it works in all browsers, not just Chrome. It's also portable.

The point of a NaCL VM would be its speed. It could actually be PyPy or something, for real. Embedded just like the Flash or Java Applet runtime (in the NaCL container, which we have rather better security salts [pun] about.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact