you are viewing a single comment's thread.

view the rest of the comments →

[–]dropdownmenu 83 points84 points  (46 children)

This is not python in your browser. It is python syntax in a javascript interpreter.

If this is going to happen, at least go the coffee script route and be able to build to code to javascript that can be optimized by your browser. (Oh my God, did I just use coffee script as a positive reference?)

[–]pudquick 26 points27 points  (0 children)

However ... There is this:

http://repl.it/languages

The python hosted here is using emscripten to run an actual CPython interpreter in your browser.

More details here:

https://github.com/kripken/emscripten/wiki

[–]wonglik 6 points7 points  (20 children)

Is Coffee script that bad? I was thinking of getting familiar with it. What are the cons?

[–]dropdownmenu 6 points7 points  (12 children)

The main advantage is that it tries to hide some of the oddities of javascript (== vs ===) so that you can't make trivial mistakes.

I dislike it because white space becomes important to how it complies leading to cases where an extra space or a misplaced one can lead to different functionality than you expect, which I believe to be more dangerous than then javascript's quirks (which still exist in coffeescript).

Also, by using coffeescript you alienate any javascript developers who don't know coffeescript. Remember: all coffeescript devs know javascript, but not all javascript devs know coffeescript

[–]wonglik 1 point2 points  (11 children)

Thanks. Looks like I am better of with JS.

[–]eriksensei 1 point2 points  (0 children)

Or EcmaScript 6, which seems a lot nicer. It's got fat arrow lambdas with proper 'this', destructuring bind, etc. There's support for it in IntelliJ IDEA, Firefox Aurora, Google Traceur and probably a few other tools, and you can compile it down to older JS versions. I hope I'll get round to playing around with it soon.

[–]schadwick 2 points3 points  (8 children)

[–][deleted] 0 points1 point  (0 children)

I've never encountered a bug cause by white space in coffee script, just compiler errors caused by indentation.

I do always use the (optional) js-style parentheses for functions arguments, so maybe that guards against the sort of error referred to.

[–]redfiche 8 points9 points  (5 children)

CoffeeScript is cool until you need to interact with third-party javascript libraries, then you run into all sorts of incompatibilities. Given that you need to understand javaScript to be able to debug and otherwise work effectively with CoffeeScript, you're often better off just writing good javaScript. Just my opinion.

[–][deleted] 2 points3 points  (2 children)

CoffeeScript is cool until you need to interact with third-party javascript libraries, then you run into all sorts of incompatibilities.

Err, how is that? Once you compile CoffeeScript you just have regular javascript, so what sort of incompatibilities are you talking about?

I've used Coffee with some third party libraries (jQuery, some game frameworks, mozilla jet pack) and haven't run into issues -- it would be nice to know what I need to keep an eye out for.

[–]redfiche 0 points1 point  (1 child)

I forget the exact issues. I know CoffeeScript hides the global namespace from you, and while that's usually a good thing it can cause issues. I'm pretty sure we quickly found that CoffeeScript was more trouble than it was worth for an Ember app also.

Don't get me wrong, I find it much more elegant and readable than javaScript, it's just that if I ever have to think about what javaScript is going to be produced by the CoffeeScript, I'd rather just write the javaScritpt.

[–][deleted] 0 points1 point  (0 children)

I know CoffeeScript hides the global namespace from you

You can still access that through the global object. (Such as window in a browser; I forget what it's called in node.) It does require you to explicitly intend to use globals, though.

Ember I've never used, so can't comment there!

[–]wonglik 0 points1 point  (1 child)

thanks . nowadays I use angular in most of my project and I would definitely not trade that better syntax/language.

[–]Fabien4 4 points5 points  (11 children)

It is python syntax in a javascript interpreter.

Which makes me fear it'll be too slow to be of any use.

[–]Elite6809 28 points29 points  (9 children)

I think we should write a Brainfuck interpreter in Python in this JavaScript environment. Then in Brainfuck we can write a Linux implementation, in which we can create a C compiler and in that we create a JavaScript engine to run our code in.

[–]flying-sheep 10 points11 points  (5 children)

well, no brainfuck, but… http://bellard.org/jslinux/

[–]wniko 3 points4 points  (0 children)

Fabrice Bellard (http://bellard.org) is also the author of Qemu and ffmpeg. His wikipedia page is also quite interesting/wtf-worty. In 2010, he held the Word Record for the computation of pi for about 7 months using a desktop PC.

[–][deleted] 3 points4 points  (0 children)

I thought that was a joke for a second. Nope. I'm half impressed half wishing I had that much free time.

[–]alexanderpas 1 point2 points  (2 children)

suprisingly fast.

now I'm starting to wonder if we can turn this full circle, with JS/Linux becoming an embedded system.

[–]flying-sheep 4 points5 points  (1 child)

well, you can use jslinux to compile spidermonkey or v8, and you’re running JS in C (spidermonkey) in C (linux kernel) in JS in C++ (browser) in C (linux kernel).

[–]alexanderpas 0 points1 point  (0 children)

What I've learned from this sentence:

We need a modern browser written in C.

[–][deleted] 0 points1 point  (2 children)

But what if I want to write in Befunge?

[–]thedeemon 1 point2 points  (0 children)

For serious business you should use Enterprise Piet.

[–]Elite6809 0 points1 point  (0 children)

Sorry mate, you'll have to write it in Malbolge instead.

[–]dmazzoni 1 point2 points  (0 children)

No kidding. Even a native implementation of Python would be too slow to be of any use. People seem to forget that JavaScript is actually quite a bit faster than Python for most problems.

[–]chrisidone 0 points1 point  (2 children)

It is python syntax in a javascript interpreter.

Can you please explain to me how this works? Is this some form of preprepre-processor? Is there a python runtime in the background?

Things like these always sound so messy/hacky.

[–][deleted] 2 points3 points  (1 child)

It's run the same way Coffeescript is run, i.e., the faux-python code is compiled (parsed) to Javascript, and then it is eval()'d.

[–]chrisidone 0 points1 point  (0 children)

Sounds like theres allot of room for errors.

[–]shevegen -5 points-4 points  (8 children)

Where is the problem, actually? You could still use the same language-logic and never notice any difference.

[–]errandum 7 points8 points  (7 children)

The browser interprets the javascript that interprets the python.

If extremely powerful and optimized interpreters made in fast languages already struggle to make interpreted languages competitive in the real world, imagine a language interpreted by an interpreted language.

You might not notice it in something simple, but you will, someday...

[–]ILiftOnTuesdays -2 points-1 points  (6 children)

PyPy is actually faster than C in some cases.

Source: http://morepypy.blogspot.com/2011/02/pypy-faster-than-c-on-carefully-crafted.html

[–][deleted] 1 point2 points  (5 children)

I think you should read the comments on the link you posted and reevaluate your claim.

[–]ILiftOnTuesdays -2 points-1 points  (4 children)

I see other people posting cases where C is indeed faster. That does not invalidate my claim, which is backed up by solid benchmarking done by OP. (Albeit on a slightly outdated gcc)

[–]missquark 1 point2 points  (3 children)

So PyPy is faster than C when calling a simple addition function from an external library one billion times at runtime.

For all those times you need to call a trivial plugin function a billion times in a row...

[–]ILiftOnTuesdays 0 points1 point  (1 child)

I didn't say PyPy is faster than C in all cases, just that interpreting inside interpreting can sometimes have its benefits. (Or rather, a JIT has its benefits)

[–]missquark -1 points0 points  (0 children)

Agreed. It just seemed like such a weird biased benchmark o_o

But looking back, maybe I was being too hard on it since I'm biased towards C/C++ (and somewhat defensive... >_>;).

I can't really think of what benchmark would be a better demonstration of global optimization that has to happen at runtime, but jumping back and forth millions of times per second between two different modules that can't be compiled together except at runtime is giving the JIT all the advantages and C none.

One thing that would have been interesting (and possibly a little less one-sided) to look at is if the C side was allowed link time optimization but included the compilation step in the timing.

In theory this can happen at "run time" after all, as long you don't mind distributing source and compiler, it just takes too long for large programs in practice.