Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why we need Python in the Browser

archlinux.me

Post reply on HN
Print view View original

111–120 of 132 posts

Re: Why we need Python in the Browser

#111

Post by TylerE »

skizzikskizziks wrote: post #58
trothamel wrote: post #42

We don't need Python in the browser. We need x in the browser, where x is every language and runtime. Javascript isn't some sort of global optimum that's perfect for every possible application. The subset of Javascript that's supported by a wide range of current browsers certainly isn't. And the result is that people aiming for the web environment are limited by what Javascript can do - even though there are language…

So I'm a little ignorant, but I think I'll benefit from answers more informed people give: My question is, why aren't people out there (who are more experienced at programming/developing than I am) developing support for X language(s) in open source web browsers like Firefox. I'm sure I don't fully understand how this works yet, but can't anyone who wants to be developing this capability independently instead of wait…

Because unless the major browser makers ship it in their mainline product, it's worthless.

Re: Why we need Python in the Browser

#112

Post by stcredzero »

tomp wrote: 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…

tldr: capabilities you want already exist in languages. Non-mainstream stuff to check out for the curious.

What we need, in my opinion, is a dynamic language with powerful optional static typing...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

Check out Strongtalk. I know it already has almost everything you just mentioned above: http://www.strongtalk.org/

    * optional static typing - Check!
    * sane object-orientedness -  Check! - superlative, actually
    * the core...really simple - Check!
    * language has to be powerful...libraries 
      can provide the missing functionality - Check!
I'm not sure if it has immutables, but VisualWorks Smalltalk has it, so it is feasible to add it. (Especially since the engineer who added it for the private vendor is now working on Cog, which is an open source VM.) In addition, Squeak/Pharo run with a >bit-identical modelI'm not saying that we need to use a derivative of Smalltalk in the browser. Smalltalk doesn't have operator precedence, so it comes across as strange to lots of technical people. In fact, lots of things are elegantly different in a lateral-thinking weird way. Alan Kay said it best: the computer revolution hasn't happened yet -- it is in progress. It takes decades for the full impact of what comes out of research labs to really reach the mainstream. It's time for some far-sighted people to take stock of capabilities we're not aware of yet, but which are there to be used.

Re: Why we need Python in the Browser

#114

Post by azakai »

dhconnelly wrote: post #18
pornel wrote: post #14

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?

> 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 practical concern that can be here, is whether JS is good enough for this task - if languages compiled into it run efficiently enough. It can be, if browsers continue to improve JS and if we all improve compilers into JS. So far little work has been done on both of those, but there is starting to be effort there.

> Emscripten is a cool technical hack, but why the fuck is it 2012 and we have to compile C++ to JavaScript?

We need to compile into something platform-independent, memory-safe and standardized. There isn't currently a better option than JavaScript, because each other option has major downsides. So does JS, to be sure, but overall it's a wash, and JS is already there so it wins.

Re: Why we need Python in the Browser

#115

Post by azakai »

hannes2000 wrote: post #12
hetman wrote: 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…

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…

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

You would ship it once. Websites already do not download jquery etc. more than once. In fact websites can use those libraries from standard locations on the web so that multiple websites don't need multiple downloads of large libraries.

Re: Why we need Python in the Browser

#117

Post by azakai »

trothamel wrote: post #42

We don't need Python in the browser. We need x in the browser, where x is every language and runtime. Javascript isn't some sort of global optimum that's perfect for every possible application. The subset of Javascript that's supported by a wide range of current browsers certainly isn't. And the result is that people aiming for the web environment are limited by what Javascript can do - even though there are language…

> Ideally, the language runtimes would be installed transparently. That's the big potential of a project like Native Client - if it lives up to its billing, it makes downloading the latest version of a language runtime to a browser safe, while giving near-native speed and abstract machine.

Native Client works behind a plugin API. That means all the languages you implement in it don't integrate as well with the web as JS does. For example, holding references to DOM notes, cycles etc. would work differently.

Re: Why we need Python in the Browser

#118

Post by Pewpewarrows »

haberman wrote: post #96
Pewpewarrows wrote: post #65

Earlier quoted context omitted.

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

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

This is a problem inherit to every dynamic language. You sacrifice brain-dead refactoring for improvements and tradeoffs elsewhere. Not to mention that modern IDEs and tools like Rope [1] can definitely help.

[1] http://rope.sourceforge.net/

Re: Why we need Python in the Browser

#119

Post by nkassis »

azakai wrote: post #116
nkassis wrote: post #113

What about using Native Client (nacl) to compile an implementation of python (without the batteries)?

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.

Re: Why we need Python in the Browser

#120

Post by skizzikskizziks »

TylerE wrote: post #111
skizzikskizziks wrote: post #58

Earlier quoted context omitted.

So I'm a little ignorant, but I think I'll benefit from answers more informed people give: My question is, why aren't people out there (who are more experienced at programming/developing than I am) developing support for X language(s) in open source web browsers like Firefox. I'm sure I don't fully understand how this works yet, but can't anyone who wants to be developing this capability independently instead of wait…

Because unless the major browser makers ship it in their mainline product, it's worthless.

That's a good point; does that imply that it can't be incorporated after the fact? That if a number of dedicated users applied it to the product themselves, the browser makers wouldn't come around to incorporating it?
Post reply on HN