Live data from Hacker News

Why we need Python in the Browser

archlinux.me

91–100 of 132 posts

Re: Why we need Python in the Browser

#91

We don't need Python in the Browser. We need a VM SPEC for the browser, so we can have whatever language we damned well please in the browser. Why Google decided to go with Dart rather than publish a VM spec is beyond me.

Brendan Eich has talked about why bytecode + VM is a bad idea for a browser: http://www.aminutewithbrendan.com/pages/20101122 If you really want a VM, it already exists. It's called JavaScript, assembly language of the web. I would hate for sites to start saying, "Requires the PyJSVM v0.8 or better to function, download it now!" EDIT: in hindsight, this post was careless. I was wrong about the "PyJSVM" point, and I p…

You wouldn't, you would do server side compilation, if we could require users to install a plugin we would already do it today and not bother with JS.

Re: Why we need Python in the Browser

#92

We don't need Python in the Browser. We need a VM SPEC for the browser, so we can have whatever language we damned well please in the browser. Why Google decided to go with Dart rather than publish a VM spec is beyond me.

Brendan Eich has talked about why bytecode + VM is a bad idea for a browser: http://www.aminutewithbrendan.com/pages/20101122 If you really want a VM, it already exists. It's called JavaScript, assembly language of the web. I would hate for sites to start saying, "Requires the PyJSVM v0.8 or better to function, download it now!" EDIT: in hindsight, this post was careless. I was wrong about the "PyJSVM" point, and I p…

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 than a language does, although it can imply semantics.

And then, at the end, he basically advocates a JS-specific bytecode. Hah. Oh, but they aren't working on it in committee. That says about all you need to know.

There is nothing about a bytecode spec that harder than a language and language spec.

Basically, he doesn't want any competition for Javascript. That was an incredibly weak podcast and he should have been shredded for it. People cut this guy way too much slack.

Re: Why we need Python in the Browser

#93

We don't need Python in the Browser. We need a VM SPEC for the browser, so we can have whatever language we damned well please in the browser. Why Google decided to go with Dart rather than publish a VM spec is beyond me.

Brendan Eich has talked about why bytecode + VM is a bad idea for a browser: http://www.aminutewithbrendan.com/pages/20101122 If you really want a VM, it already exists. It's called JavaScript, assembly language of the web. I would hate for sites to start saying, "Requires the PyJSVM v0.8 or better to function, download it now!" EDIT: in hindsight, this post was careless. I was wrong about the "PyJSVM" point, and I p…

"Requires the PyJSVM v0.8 or better to function, download it now!"

WTF is that? The whole point is that you'd target the bytecode standard. This would be just like targeting javascript today, but it wouldn't require hacks to deal with the broken aspects of javascript and maybe tools like cliend-side debugging would be useful.

It doesn't have anything to do with individual VMs per language.

Re: Why we need Python in the Browser

#94
post #14
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…

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

That bytecode is not good enough. It doesn't even have ints for christ sake.

Re: Why we need Python in the Browser

#95
post #50

Earlier quoted context omitted.

I like how you capitalized the Real Programming Languages, as if it is some official definition. The notion that python isn't real, is just silly.

(with-devils-advocacy A Real Programming Language is one that can be used (and has been used) to implement its own compiler or interpreter ) That said, by this definition Python qualifies.

Even that isn't a great definition as there have been interpreters for Brainfuck, why probably shouldn't be regarded as a "Real Language", written in Brainfuck:

http://esolangs.org/wiki/Brainfuck#Self-interpreters

Re: Why we need Python in the Browser

#96
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…

> 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. Sorry to be blunt, but if every one of your Python functions and methods begins with isinstance() checks for every parameter, you just missed the point of the entire language. Python was built on a foundation of ducktyping, with the mantra that…

The Python approach means that when an exception is thrown, it's unclear whose fault it is. Is it a bug in the called function, or in the caller for passing a bad parameter? The larger the program the more of a problem this becomes.

It also means that when you change a function signature, the compiler can't tell you all the call sites you need to fix. You have to find them through testing. This is a large barrier to aggressive refactoring.

Even the Python C API provides facilities for checking that arguments have a specific type and raising TypeError if not, so it can't be that completely counter to the intention of the language: http://docs.python.org/c-api/arg.html (see O!)

Re: Why we need Python in the Browser

#97
post #11
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…

I'm sure we could have some sort of JSVM, we could even have some sort of bytecode for the HTML, but it would destroy part of what makes the web so great: it's openness. The ability to view the source of any webpage, and even make chances and enhance it locally. There is also the fact that certain optimization can only be done by the browser if it has the actual source code rather than the compiled bytecode.

You have already lost that. Go look at the source code for cuttherope.ie and tell me that you learned anything. It might as well have been binary.

Re: Why we need Python in the Browser

#98
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…

Parrot in the browser! Don't really know a lot about it, to be honet, but it could work :)

"Parrot is a virtual machine designed to efficiently compile and execute bytecode for dynamic languages. Parrot currently hosts a variety of language implementations in various stages of completion, including Tcl, Javascript, Ruby, Lua, Scheme, PHP, Python, Perl 6, APL, and a .NET bytecode translator. Parrot is not about parrots, though we are rather fond of them for obvious reasons."

http://www.parrot.org/ http://duckduckgo.com/Parrot_virtual_machine

Re: Why we need Python in the Browser

#99
post #27

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.

Maybe because people are afraid to end up with a fragmented web all over again. 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 byt…

Actually it would be great if it broke the old webbrowsers -- that way we might finally get people to something modern.

But failing that I would be okay with it compilling down to javascript.

Re: Why we need Python in the Browser

#100

Earlier quoted context omitted.

Brendan Eich has talked about why bytecode + VM is a bad idea for a browser: http://www.aminutewithbrendan.com/pages/20101122 If you really want a VM, it already exists. It's called JavaScript, assembly language of the web. I would hate for sites to start saying, "Requires the PyJSVM v0.8 or better to function, download it now!" EDIT: in hindsight, this post was careless. I was wrong about the "PyJSVM" point, and I p…

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.
Post reply on HN