21–30 of 132 posts
It seems that the primary method of disagreement used by only-JavaScript-in-the-browser advocates is as follows: 1. Talk about the "open web"; 2. Tell you to compile to JavaScript. I really don't understand why this is considered a reasonable response to people who just want to build things with the language they prefer, without being treated as second-class citizens.
That's a ridiculous and off-putting way of wording your complaint.
As a user of Real Programming Languages (Common Lisp, Java, C) I'm indifferent to scripting languges, but if I had to choose ONE to see in the browser, it would be Lua. It has sane, symmetric minimal design that gets closures. It also looks like a programming language. I can type Lua into the Firebug repl and not worry about indentation.
Python is a full and mature programming language, lots of software you probably use every day is written in it, like dropbox, calibre, miro or websites like Reddit and YouTube for example.
You'll find a longer list here: http://en.wikipedia.org/wiki/List_of_Python_software
Sure you can use Python for scripting, but that doesn't mean it isn't a real programming language. It just makes it more versatile than other languages.
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 the correct types, and unittests testing if a class's/function's signature changed in an unexpected way.
What we need, in my opinion, is a dynamic language with powerful optional static typing (unlike Dart, where types are just comments), with sane object-orientedness, and support for immutable values. The core has to be really simple, but the language has to be powerful enough so that libraries can provide the missing functionality (math - rationals, matrices, ...; concurrency - channels, isolates, ...; GUI, IO (with formats, ...)).
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…
Lots of essential Python features are not part of the language, but belong to its standard library. The thing that makes JavaScript so portable is that it basically has no such thing (except maybe Date and Math). So to make convenient use of Python in the browser (or even to be able to run currently existing Python code), you wouldn't just have to embed the interpreter – you would have to ship this huge library. And…
Earlier quoted context omitted.
We do have that VM. It just happens that this VM's "bytecode" looks like JavaScript. Here is Python running in the browser: http://syntensity.com/static/python.html
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?
I think once browsers are able to debug in the originating languages people will stop complaining about this.
As a user of Real Programming Languages (Common Lisp, Java, C) I'm indifferent to scripting languges, but if I had to choose ONE to see in the browser, it would be Lua. It has sane, symmetric minimal design that gets closures. It also looks like a programming language. I can type Lua into the Firebug repl and not worry about indentation.
The notion that python isn't real, is just silly.
It seems that the primary method of disagreement used by only-JavaScript-in-the-browser advocates is as follows: 1. Talk about the "open web"; 2. Tell you to compile to JavaScript. I really don't understand why this is considered a reasonable response to people who just want to build things with the language they prefer, without being treated as second-class citizens.
Preference of language shouldn't really be a factor. The real question is that any change must be properly standardized and implemented by all browser vendors else you end up with "This webpage is written in python and is only supported by Chrome 39+ and Firefox 43+".
Does using your prefered language really outvalue that?
I think the bytecode argument is a more feasable one, as long as it could somehow be compiled to javascript and support older browser versions effortlessly.
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?
Browsers supporting JavaScript and some other bytecode format would bring web innovation to a crawl. I think once browsers are able to debug in the originating languages people will stop complaining about this.
Can the rpython translator support js as a target? Could you compile pypy to js that way, to provide a python environment in existing browsers? To be honest though, JS is a perfectly OK language for web browsers, and if you really want to reuse python code it probably makes more sense to translate it before it gets to the browser, using automated tools or otherwise. Supporting everybody's favourite language natively…
RPython -> LLVM -> Emscripten -> JavaScript
[1] http://www.mail-archive.com/pypy-dev@codespeak.net/msg03946....
[2] http://pyppet.blogspot.com/2011/04/rpython-to-javascript.htm...
Earlier quoted context omitted.
Lots of essential Python features are not part of the language, but belong to its standard library. The thing that makes JavaScript so portable is that it basically has no such thing (except maybe Date and Math). So to make convenient use of Python in the browser (or even to be able to run currently existing Python code), you wouldn't just have to embed the interpreter – you would have to ship this huge library. And…
You also would not be able to minify it properly because of whitespace identation constraints. Or am I off on this?