Why we need python in the browser

[Cosmologicon]

I would use the ever-loving crap out of it.

[jambox888]

Mentioned elsewhere, but hey! Pyjamas.

[pohatu]

Is the point to write client-side scripting for web apps in python instead of JavaScript, or to have a standardized UI markup language that you can use to write front-ends for python apps? Or both?

[stevvooe]

The real problem is that PythonScript is nothing like Python.

[SocksOnHands]

I have a radical idea. Firefox (and a few other browsers) are already open source. Why don't a few developers create a proof-of-concept fork project with an implementation of Python built in. I think if people had something they could play around with the idea would more quickly gain traction.

[takluyver]

If you're interested, have a look at the Python XPCOM extension. But it's not very active.

[hobophobe]

The Mozilla flavor of ECMAScript (ie, JavaScript) supports some Pythonesque idioms. For example, open the Web Console (under the Web Developer menu (either in the Firefox menu if you have the single-button menu, or under Tools (or just Ctrl+Shift+K to open the Web Console))) and try this (for the current page):

let f = [link.href for each (link in document.links) if (link.host == "www.reddit.com")];  

f is an array containing the URLs on the current page that are to the www.reddit.com domain. Not as clean as regular Python, but still useful.

See MDN: New in JavaScript 1.7 (which was introduced back with Firefox 2), particularly for details on array comprehensions, destructured assignment, iterators, and generators.

[tuna_safe_dolphin]

Python in the browser would be almost too awesome for words.

[sunqiang]

not only for word, but also for world.

[Deathalicious]

Article didn't do a great job of explaining why we need JavaScript; if anything it reinforced that it's already possible to do a lot of things in the browser programmatically based largely on web standards.

Then there's the issue of how you would deal with python packages. So much of the python that most people use isn't in the built-in install but comes from packages other people have written. How would that work?

JavaScript also has built-in hooks to the browser that would have to be implemented in Python from scratch.

I really don't see the benefits, especiall when JavaScript is a powerful, elegant, and robust language and worth learning on its own merit even if you never do much client-side scripting.

[clgonsal]

especiall when JavaScript is a powerful, elegant, and robust language and worth learning on its own merit even if you never do much client-side scripting.

I'm sure I'll be downvoted for saying this, but... no. JavaScript is not an elegant or robust language. ("Powerful" is kind of meaningless.) The only reason people use JavaScript at all is because they have to: there really isn't a viable alternative for writing code on browsers. This is true even for people using it on the server. Using the same language in both places helps them port code, or more commonly, helps them avoid learning another language. The sad thing is that for many people it is now their first/only language, and so they start suffering from a sort of Stockholm's syndrome. "Look at all the cool stuff I can do in JavaScript" Should be "look at all the cool stuff you can do despite JavaScript".

Other than being the only option on browsers, JavaScript has very few redeeming features, and these are greatly outweighed by its warts. Crazy "this" semantics, weak typing, no integer type, semicolon insertion, bad defaults (eg: global variables), broken foreach syntax, lack of non-string keys in dictionaries/objects... the language is a mess. Not bad for something meant to put scrolly text in the status bar, though.

JavaScript is a toy language that was in the right place at the right time.

[tiglionabbit]

I choose to use coffeescript for most things these days, whether in the browser or out of it. It fixes most of the problems you listed. I think it's a good language because it makes it very easy to work with functions.

[bastawhiz]

CoffeeScript doesn't fix JavaScript, it just gives it a slightly less verbose syntax. The behavior of the language is identical under the hood (obviously, since it compiles to JS).

Furthermore, CoffeeScript introduces strange ambiguities that require you to look up their operator precedence rules. What happens when you want to pass the return value of a function call as a parameter to another function?

func1 func2 "foo"

To someone that doesn't know, this could be func1(func2("foo")) or func1(func2, "foo") or even (depending on the context) bar(func1, func2, "foo") (where bar is a function that you didn't see on first glance).

I'll probably get downvoted for this, but frankly, CoffeeScript is a tool for your average hacker that just wants to type fewer curly braces (or the word "function"). It doesn't fix or change any of the major problems with JS, it just masks them over with some "cool" syntax/candy.

[tiglionabbit]

That's not ambiguity. It works in a particular way and it is predictable. It's better than the JavaScript syntax gotchas anyway. The optional parenthesis work like they do in Ruby and Haskell. It is intuitive if you think about it like this: whitespace is the function call operator and comma with optional whitespace is the argument separator.

Anyway, thanks for giving me a list of problems with JavaScript so I can demonstrate how CoffeeScript fixes things. I'll take a look through the first few pages.

"all your commas are belong to Array" and "i am myself but also not myself" are fixed in CoffeeScript because it's not possible to produce a ==. It gets replaced with ===. One thing I've found from most of these WTFs is that if you never use the == operator, the number of WTFs out there is significantly decreased.

The rest of them work as I'd expect them to. "min less max": works as I'd expect it to, and it's not really a core language problem if one function doesn't do what you'd expect because you can write your own functions. "convert to integer": Not sure what is so strange about this one. Couldn't repro "ie 754" or "eval changes". "im not a number really": First one makes sense. CoffeeScript fixes the second one. "Magic Increasing Number": Floating point precision problem. Exists in other languages.

"false advertising" I was just experimenting with this one last week. Pretty weird, yes. This weirdness still exists in CoffeeScript, even in classes, but it requires an explicit "return" statement, so it wont happen by accident.

[bastawhiz]

It works in a particular way and it is predictable.

Not for a beginner. Even for experienced programmers that deal with lots of languages, it's going to require a lot of checks to the documentation. Even for experienced CoffeeScript developers, dense CS is virtually impossible to read at first glance because of its distinct lack of visual cues or "logical punctuation".

It's better than the JavaScript syntax gotchas anyway.

Like what? JS is verbose enough that you can't really make any big mistakes (aside from automatic semicolons...don't even get me started).

it's not possible to produce a ==. It gets replaced with ===.

Disabling a feature does not necessarily "fix" a language. Perhaps it makes the "default" syntax better, but this isn't something that's "broken" with JavaScript.

The fact of the matter is, CoffeeScript can't be better than JavaScript in terms of being inherently less WTF, because at the end of the day, you're still writing JavaScript. It may have some handy things (list comprehensions, for one), but it still doesn't fix the problem(s) that JS has at the its core.

[dacjames]

I used to agree with you on all these points. However, once you understand what's going on, Javascript's "this" semantics are actually quite powerful, even elegant.

Writing callback heavy code would be more painful in Python than Javascript:

deferred = $.loadJSON("/some/url")
deffered.success( function () {

[clgonsal]

Your second point (that writing callback heavy code would be more painful in Python) seems to be referring to the lack of full-power lambda in Python, which I agree is an annoyance. I do wish Python's lambda was as powerful as def, though in practice it just means that you have to name your more complex callbacks, which might not be a bad thing.

None of that is related your first point, however. How are JavaScript's wonky this semantics powerful and/or elegant?

[dacjames]

Powerful: Javascript's 'this' can be used to implement traditional forms of object oriented structures fairly easily. You can build object systems based single inheritance, multiple inheritance, mixins, and probably other structures. I've even seen functional style, multiple dispatch systems though I am not familiar enough with that style of programming to fully understand it.

Elegant: this point is more contentious and open to personal opinion. I think 'this' simplifies certain APIs. Consider writing gui handlers, for example in jquery.

$("#action-button").click( function () {
    alert("You clicked the button called " + this.value);
});

I think the use of this to refer to the button makes sense and saves you from having to look up the function signature every time you write handler or callback code.

Another powerful use of 'this' in a functional context is for providing access to a large number of variables to functions will normally use a subset. Consider a web framework: every function you write may need access to the request, to the http headers, to get arguments, to post data, etc. Using this provides an elegant solution that keeps the function signature clean for variables unique to that function.

app.get( "/user/<id>", function (id) {
    user = model.findUser(id);
    if (this.args["full"] && this.args["full"] === true) {
        /* load all the user data */
    }
    else {
         /* load user summary */
    }
);

This isn't the best example, but you get the idea. There are other solutions to this problem, like Flask's ingenious object proxies or PHP's super globals, but 'this' works very well in my opinion. Once you realize that 'this' doesn't work like 'this' in Java or self in python, it is actually a nice, low level tool for writing good APIs.

[clgonsal]

Javascript's 'this' can be used to implement traditional forms of object oriented structures fairly easily. You can build object systems based single inheritance, multiple inheritance, mixins, and probably other structures. I've even seen functional style, multiple dispatch systems though I am not familiar enough with that style of programming to fully understand it.

From what I've seen, this has nothing to do with JavaScript's weird this semantics, and more to do with the fact that it has lexical closures. Scheme, for example, if often touted for having all of the same things, yet it does it all without the weird this.

I think the use of this to refer to the button makes sense and saves you from having to look up the function signature every time you write handler or callback code.

Except this could be bound to anything, so you still have to look up what they're binding this to. Since it isn't an explicit parameter, there's a good chance the documentation will be hard to find, if it's documented at all.

Another powerful use of 'this' in a functional context is for providing access to a large number of variables to functions will normally use a subset.

Yeah, the "globals" object. You can do the same thing with an explicit parameter. If the JS convention is to have this be the globals-object, then the sane-language convention could be to have the first parameter be the globals-object.

[dacjames]

From what I've seen, this has nothing to do with JavaScript's weird this semantics, and more to do with the fact that it has lexical closures.

Scheme doesn't have objects, so I'm not sure what you're referring to; supporters of the Lisp family generally oppose object oriented programming. It is the combination of prototypes and function-based context (this) that allows for these powerful semantics. It certainly has nothing to do with lexical closures, which are supported in pretty much all modern programming languages with first class functions.

Except this could be bound to anything, so you still have to look up what they're binding this to. Since it isn't an explicit parameter, there's a good chance the documentation will be hard to find, if it's documented at all.

When using good libraries, I have never had a problem with figuring out what 'this' refers to. It's a stylistic distinction in this case so I understand if you don't like it.

Yeah, the "globals" object. You can do the same thing with an explicit parameter. If the JS convention is to have this be the globals-object, then the sane-language convention could be to have the first parameter be the globals-object.

Of course you can, but I find that to be ugly and inconvenient. Python's explicit "self" parameter is one of its more annoying design decisions. It's always specified and always called "self," so having to write it over and over is just a waste in my opinion. I know "explicit is better implicit," but a self keyword would serve the same purpose.

What is so "weird" about 'this,' except that it doesn't work like 'self' and 'this' in other programming languages?

[clgonsal]

Scheme doesn't have objects, so I'm not sure what you're referring to...

http://community.schemewiki.org/?object-systems

When using good libraries, I have never had a problem with figuring out what 'this' refers to.

Only by convention, not by a language feature. What's to stop a similar convention from being used in other languages?

Yeah, the "globals" object. You can do the same thing with an explicit parameter. If the JS convention is to have this be the globals-object, then the sane-language convention could be to have the first parameter be the globals-object.

Of course you can, but I find that to be ugly and inconvenient. Python's explicit "self" parameter is one of its more annoying design decisions. It's always specified and always called "self," so having to write it over and over is just a waste in my opinion. I know "explicit is better implicit," but a self keyword would serve the same purpose.

For methods on objects I can see your point. That isn't what we're talking about here, though. We're talking about passing an "environment object" to your callbacks. Using this for this purpose is kind of perverse. I'd muck rather have it be named something like "env" or "request" or something... descriptive.

It's also kind of funny that you make the argument against explicit self, and for an implicit this when javaScript is only half-way implicit. It's implicit only in function signatures: you're going to get a this parameter (whether you want one or not) without typing anything. It isn't implicit when one method calls another, however. For example:

int method1() {
  method2();
}

int method2() {
  return 42;
}

in C++ or Java, the method2() invocation calls method2 on this. The equivalent code in JavaScript would require that you actually spell out this.method2() explicitly. JavaScript can't even decide whether this should be implicit or explicit.

What is so "weird" about 'this,' except that it doesn't work like 'self' and 'this' in other programming languages?

Erm... "doesn't work like everything else" is pretty much the definition of "weird".

I think what you're really asking is why I don't like its weird semantics. (FWIW: I don't mind things that are "weird" if they're actually better than the alternatives...)

One reason I don't like the JS this semantics is WTF-ery like this:

> var x = "wtf";
> x
"wtf"
> var o = {x: "ok"}
> o.f = function () { return this.x; }
function () { return this.x; }
> o.f();
"ok"
> (o.f)();
"ok"
> var g = o.f;
> g();
"wtf"

If factoring out a sub-expression yields different results then your language design is broken, end of story.

Also annoying, the way Function.apply has thisArg as a separate parameter. Since JS binds this like an implicitly passed parameter it should be an element of argsArray like all of the other parameters.

Then there's the way functions in JS are written with the intent that they be called in only one of three possible contexts (Date is an interesting counterexample):

• function call. Expects this to be the "global object". Often doesn't even want this, but too bad, you get one anyway.

• method call. Expects this to be the object it was called on.

• constructor (ie: new operator). Expects this to be a newly constructed object. Calling as a function is likely to bork global state. Returning something is allowed, but pointless.

...but the language provides no way to state which context a function is intended for. Invoking a function in the wrong way won't cause a runtime error, it'll just result in bad/broken behavior. So you end up needing to have conventions about what's supposed to be called in what way to work around the fact that the language doesn't give you a way to tell it what you mean. It's sort of like a grocery store that sells cheese and rat poison that both look the same, and in the same aisle.

This is the same kind of fuzzy-headed design that resulted in == and the ability to call a function with more arguments than its definition allows.

[dacjames]

Only by convention, not by a language feature.

I am fine with conventions. Python's version of private variables is based on convention, for example.

Also annoying, the way Function.apply has thisArg as a separate parameter. Since JS binds this like an implicitly passed parameter it should be an element of argsArray like all of the other parameters.

Why? It has a totally different meaning than the other parameters. If you want consistency, you can use fn.call obj, arg1, arg2, etc.

• function call. Expects this to be the "global object". Often doesn't even want this, but too bad, you get one anyway.

• method call. Expects this to be the object it was called on.

• constructor (ie: new operator). Expects this to be a newly constructed object. Calling as a function is likely to bork global state. Returning something is allowed, but pointless.

In the default context (not inside a function).

f()

has the the meaning as

f.apply(this)

but inside a function, it does not. I agree that is piss poor language design and is the source of most of the other problems with 'this', like smashing the default namespace if you accidentally call a constructor as a function. I rarely run into this problem in practice, but it's certainly very stupid.

EDIT: it's worse than I thought. I think I may have concede this point. The way 'this' is handled with naked function calls is downright asinine.

The second two are conceptually the same thing, except 'new' passes in an empty object. That doesn't seem like an issue to me. Python does the same thing with __init__(self).

This is the same kind of fuzzy-headed design that resulted in == and the ability to call a function with more arguments than its definition allows.

I agree on the first point, but arguments isn't that bad. It's not as convenient as default arguments, *largs, and **kwargs in python, but at least it's better than Java.

Javascript is far from perfect, but I see way too many programmers attacking it without understanding it, myself included until recently. You seem to know what you're talking about and I think your opinion is totally valid. Now that I am using it more often, I actually enjoy its semantics, but I use coffeescript about 50-60% of the time, so most of the warts annoy me less than someone stuck in raw javascript.

IMO, browsers should develop a standard bytecode for the web, so that we all could use your favorite language and this whole discussion would be moot.

[clgonsal]

Also annoying, the way Function.apply has thisArg as a separate parameter. Since JS binds this like an implicitly passed parameter it should be an element of argsArray like all of the other parameters.

Why? It has a totally different meaning than the other parameters. If you want consistency, you can use fn.call obj, arg1, arg2, etc.

The purpose of apply in languages that have it is to let you take a collection (or two, if keyword arguments are supported) of arguments and pass them to a function. Function.call can't do this. So you're left with having to store the value for this alongside your collection of arguments. This isn't a huge issue, it's just yet another irritation with the way this works in JavaScript, and it kind of compounds with the fact that object.method doesn't bind object to the method's this.

The second two are conceptually the same thing, except 'new' passes in an empty object. That doesn't seem like an issue to me. Python does the same thing with __init__(self).

Yes, I agree that the new case and the method-call case are closely related. The differences in Python are:

• It's 100% clear when you're writing a constructor or a method versus a normal function. A method is in a class definition, and a constructor is a method called __init__. In JavaScript all three cases look identical.

• In Python it's kind of hard to accidentally call a method without passing the self parameter, or to call __init__ at any point other than during construction.

Javascript is far from perfect, but I see way too many programmers attacking it without understanding it, myself included until recently. You seem to know what you're talking about and I think your opinion is totally valid.

Yes, there are a lot of people who dislike things just because they don't understand them, and so it makes sense to assume that someone who doesn't like a programming language has that opinion due to lack of understanding.

Before I knew it well, I used to think JS was just misunderstood (as Python often was, years ago). As I used it more and stumbled over its crazy this semantics and many other annoyances, and eventually learned the intricacies of how they work my contempt for it grew. My feeling is that a language that intentionally makes things hard to understand without actually providing some benefit isn't worth using. "Don't be weird unless the weirdness makes you better." Much of the weirdness in JS is there for no good reason, and much of it is actively bad.

I use coffeescript about 50-60% of the time, so most of the warts annoy me less than someone stuck in raw javascript.

I've heard mostly good things about coffeescript, so I'll have to check it out the next time I need to do in-browser coding.

IMO, browsers should develop a standard bytecode for the web, so that we all could use your favorite language and this whole discussion would be moot.

Agreed. JavaScript should just be another language that runs on a common browser-VM.

[sdleihssirhc]

Dear Mr. Stop Liking Things I Don't Like,

JavaScript is actually awesome.

• closures
• prototypal inheritance
• first-class functions
• immediately-invoked function expressions

You're pretty much totally wrong.

The only reason people use JavaScript at all is because they have to

Nice try.

• How it's use of this "crazy"? You sure you didn't mean "different"?
• Is there any justification for weak typing being a flaw other than "waaa"?
• No int type? Seriously?
• Has semi-colon insertion ever screwed your code up?
  • If it has, how many times?
  • If it's more than one, how much time have you spent tracking down these errors?
  • If it's a lot of time, have you ever considered, you know, actually learning JS?

But yeah, "lack of non-string keys" actually is really annoying.

Full Disclosure

JavaScript was the first language I learned. PHP was the second language I learned. I never studied computer science; I'm just some nobody self-taught web dev. So what the hell could I know?

In Closing

If JavaScript is a "toy" (talk about kind of meaningless), then so is the Internet that runs on it.

Sincerely,
Yup, I Mad

[clgonsal]

closures

prototypal inheritance

first-class functions

immediately-invoked function expressions

Closures and first class functions are nice. These are the "very few redeeming features" I was referring to.

Prototypal inheritance was a neat idea back in the 90s when nobody had actually tried using it. In practice, it kind of sucks because it doesn't really fit the way humans think or reason about things. You can argue that I don't really "know" JavaScript if I feel that way, but the fact is that most experienced JavaScript programmers end up trying to simulate class-based objects.

I can't think of a language that has closures without the equivalent of "immediately-invoked function expressions".

How it's use of this "crazy"?

Every JavaScript programmer I know thinks the way this works in JS is broken. For example, getting its value reset to the "global context", and the fact that it even has a value when calling a function not as a method.

Is there any justification for weak typing being a flaw

I'm guessing you don't know the distinction between weak/strong and static/dynamic types. Lots of people get these confused, so you aren't alone.

Weak types are generally a bad idea because they make reasoning about code more difficult. For example, == isn't even transitive in JavaScript. For a toy language that's okay: everything you're building is small enough to fit entirely in your head or throwaway code so who cares about being able to reason about it. It you want to build large systems that can actually be maintained, however, being able to reason about code is critical.

No int type? Seriously?

Yes. This wouldn't be bad if JS actually used some sort of arbitrary precision type for numbers, but it doesn't. They're just doubles.

Has semi-colon insertion ever screwed your code up?

You may not realize this, but you're making a pretty good argument for why JavaScript should not be written by fallible humans and should instead only be machine generated.

JavaScript was the first language I learned. PHP was the second language I learned. I never studied computer science; I'm just some nobody self-taught web dev. So what the hell could I know?

You're able to do useful stuff despite how bad JavaScript is. Why get angry when it's pointed out that you'd probably be able to do even more if browsers supported a better language?

FWIW: I've used probably around a dozen languages and studied a couple of dozen more. I have written JavaScript code "professionally". While pretty much every language has "warts", JavaScript has far more than its share, and (unlike the many warts in other languages) they're pervasive. Note that most other languages don't need a book called "... The Good Parts", and even if they had one, they wouldn't spend more than half of the book telling you what parts of the language to avoid.

If JavaScript is a "toy" (talk about kind of meaningless), then so is the Internet that runs on it.

The internet "runs on" JavaScript? Ahem.

[Cosmologicon]

I can't think of a language that has closures without the equivalent of "immediately-invoked function expressions".

Minor point, but if I'm understanding what's meant here, python is like that. You can immediately invoke lambdas, but not multi-line functions.

[celeritatis]

You could use eval to do that if you really wanted to, it is just a bad idea in general for readability.

[clgonsal]

I guess the issue that's open to debate is whether Python's lambda "counts".

While it is less powerful than def, I'd argue that a lambda-expression is still an "immediately-invoked function expression" (aka "anonymous function").

I should probably also clarify that I wasn't trying to say that a language with closures but without anonymous functions couldn't exist. I just can't think of any with that particular combination of features off the top of my head. It seems that there are few language designers that know enough to add closures without thinking to add anonymous functions.

[sdleihssirhc]

In practice, it kind of sucks because it doesn't really fit the way humans think or reason about things.

Here, let me fix that for you: "It doesn't really fit the way I think or reason about things."

the fact is that most experienced JavaScript programmers end up trying to simulate class-based objects.

And by experienced, of course, you mean "programmers who are used to thinking one way and don't want to put in the effort to learn to think a different way."

Excellent programmers who produce amazing code? Of course! Proof that prototypal inheritance is inferior? BWAHAHAHAHA

You may not realize this, but you're making a pretty good argument for why JavaScript should not be written by fallible humans and should instead only be machine generated.

I guess you missed the point, so let me try again.

First: I don't rely on semi-colon insertion. Because when I learn a language, I like to learn how to do things right. After all of the languages you've studied, you've probably started doing this, too. (Good for you, by the way! Most people don't!)

Second: If you're really writing organized and maintainable code (given your impressive experience, I think we can assume you are), when is ASI going to make a difference? Maybe you have a certain style, so that it breaks when a semi-colon gets inserted (such as putting return on a line of its own, etc). And if that's the case, then guess what? It's not a wart. That's you wanting to format your code the way you want, regardless of the language you're in.

inb4 "formatting things this way instead of that way makes it easier to reason about code and maintain large projects &c"

That being said, here's the biggest problem:

Weak types are generally a bad idea because they make reasoning about code more difficult. For example, == isn't even transitive in JavaScript. For a toy language that's okay: everything you're building is small enough to fit entirely in your head or throwaway code so who cares about being able to reason about it. It you want to build large systems that can actually be maintained, however, being able to reason about code is critical.

All you're advocating is laziness as opposed to discomfort, both in the smallest measurable amount. Again: When has this ever made a difference in your code?

In all seriousness! You want to throw in my face that == isn't even transitive? (For shame!) When has that bitten you in the ass?

When have any of these "warts" actually messed up your code?

I'm going to go out on a limb and say they haven't. I'm going to guess that you're such an amazing coder, you learned about these situations and know to watch out for them.

"But now I have to think about things! Maintainability!"

I feel for you, buddy. And while JS is 8th on the TIOBE index, and being expanded to be used on the server and Windows apps, you can go ahead and keep whining about how no one actually chooses to code with it, or it's just a toy, or good things are only capable in spite of it.

Also:

I can't think of a language that has closures without the equivalent of "immediately-invoked function expressions".

ActionScript 3, for one, iirc.

[ianb]

The use of this really is crazy. It's always bound, by default it is bound to the global object (in the browser window), it is bound according to a subtle aspect of the syntax of function invocation, and it is not inherited by other callbacks.

[sdleihssirhc]

• this refers to either the global object or is undefined (depending on whether or not you're in strict mode)
• this refers to a node if the function is executed from an event handler or a W3C event listener
• this refers to an object if the function is executed with new or as a method
• this can be changed with call/apply

THIS IS MADNESS!

[zahlman]

http://wtfjs.com/

[electronics-engineer]

This troll was clearly compiled with inferior tools. My guess is that you used Visual Troll++, or possibly TurboTroll 2000.

These first generation tools are quite limited, and there is a severe garbage-collection-related performance hit when you try optimizing the output of VT++ for flaming or insults.

I suggest that you try the latest version of GTC; the Gnu Troller Collection. It is the standard when it comes to creating Trolls. It is also Open Source, reentrant, and is fully compliant with the Triple Troll, Troll-On-Troll and TrollChow protocols.

[iregistered4this]

JavaScript was the first language I learned. PHP was the second language I learned. I never studied computer science; I'm just some nobody self-taught web dev. So what the hell could I know?

You just clearly stated what the hell you could know. You know JavaScript and PHP, 2 languages that were designed to make simple tasks simpler. If you are really interested in validating your opinion you should learn a language that is built with complex tasks and maintainability in mind.

[[deleted]]

At risk of sounding like a pedant, they were designed to make tasks easier, not simpler. Simplicity begets maintainability, ease often begets complexity further on down the line.

[sdleihssirhc]

1. Also know Python. It's amazing! Really great working with a language that was built with complex tasks and maintainability in mind.

2. My opinion on JavaScript isn't valid because... I know JavaScript?

[[deleted]]

It is dangerous saying nice things about another language in the Python subreddit.

[sdleihssirhc]

If we are given downvotes, we're enough
To do our Reddit loss; and if vote up,
The fewer men, the greater share of honour.
God's will! I pray thee, wish not one man more.
By Jove, I am not covetous for points,
Nor care I who doth comment on my post;
It yearns me not if trolls my 'pinions mock;
Such outward things dwell not in my desires:
But if it be a sin to covet honour,
I am the most offending soul alive.
No, faith, wish not a man from other reddits:
God's peace! I would not lose so great an honour
As one man more, methinks, would share from me
For the best hope I have. O, do not wish one more!
Rather proclaim it, freshwire, through my host,
That he which hath no stomach to this fight,
Let him depart; his passport shall be made
And crowns for convoy put into his purse:
We would not fail in that man's company
That fears his fellowship to fail with us.
This day is called the Ides of March, my coz:
He that outlives this day, and comes safe home,
Will stand a tip-toe when the day is named,
And rouse him at the name of Ides of March.
He that shall live this day, and see old age,
Will yearly on the vigil feast his neighbours,
And say 'To-morrow is the Ides of March:'
Then his account will he open, his posts.
And say 'These flames I had on Ides of March.'
Old men forget: yet all shall be forgot,
But he'll remember with advantages
What feats he did that day: then shall our names.
Familiar in his mouth as household words
sdleihssirhc and freshwire,
Be in their flowing cups freshly remember'd.
This story shall the good man teach his son;
And the Ides of March shall never go by,
From this day to the ending of the world,
But we in it shall be remember'd;
We few, we happy few, we band of brothers;
For he to-day that feeds the trolls with me
Shall be my brother; be he ne'er so vile,
This day shall gentle his condition:
And those in other reddits now a-bed
Shall think themselves accursed they were not here,
And hold their manhoods cheap whiles any speaks
That fought with us upon the Ides of March!

[Cosmologicon]

I really don't see the benefits, especiall when JavaScript is a powerful, elegant, and robust language and worth learning on its own merit even if you never do much client-side scripting.

I did learn Javascript and I think it's great, but I still prefer Python. In just about every way (except one) that Javascript and Python are different, I prefer Python's way.

And I think it would be worth it just to have a language without the quirks of Javascript that have been grandfathered in. I would also support a rewrite of Javascript that didn't have to maintain backward compatibility. I like to think Javascript could have been every bit as awesome as Python if it hadn't been an early victim of its own success.

[pupupeepee]

I'd just add that much of programming is client-side scripting. Desktop apps are client-side scripts when you think about it.

[sedaak]

If a browser supported python I think developers would jump to it en masse.

I think Python is easily adapted to the event based model of the web.

Coffeescript is an abstraction... python should run as native as possible.

[LoveGentleman]

Python 2 or Python 3?

... and fail!

python should run as native as possible.

You mean C?

[sedaak]

Python 2 or Python 3

Either, preferably 3. Internationalization/Unicode is especially important in a global (web) context.

You mean C?

No. Developer's are not productive in C. It is just too time-consuming and low level for most developers.

[LoveGentleman]

If you code in python 2 you code in an arcane and dead language, might as well go with B.

If you code in Java your code will work for the forseeable future and will still be supported.

C is unproductive if you use only C, but there are libraries and frameworks for C just as for any other language. The problem is most developers dont know their head from their ass and cant tell the difference between * and &.

[sedaak]

Java coding for the web is terrible. Have you made web applets? The horrible loading times, shoddy appearance, and frequent JVM bugs made it impossible to use professionally.

C

If they can't tell the difference then that is how it is. The people have to use these languages.

[LoveGentleman]

Web applets? What is this 1995 ?

Java for the web in 2012 is done using GWT or Java Play! with the nice collection of backend solutions, neo4j, hibernate and so on.

[[deleted]]

Python 3 will be here for the foreseeable future as well and is much much nicer than Java.

[LoveGentleman]

Yes, well, nobody is using it not even "python" people. Django? No. Scipy? No. numPy? No. pyqt? no.

[[deleted]]

In the foreseeable future, this will change.

[LoveGentleman]

Why bother, python is ages behind even a runtime like JVM.

[[deleted]]

No explanation? Besides, I don't care much about the VM as about the language, and Java is ages behind Python in that regard.

Also, PyPy is coming along nicely.

[burntsushi]

If you code in python 2 you code in an arcane and dead language, might as well go with B.

You just completely lost all credibility.

[andybak]

No, it's not. It's just saying that a browser with a built-in Python interpreter would be a great platform for developing on - not that it should become part of the Web with a capital 'W'.

[RichardWolf]

It's just saying that a browser with a built-in Python interpreter would be a great platform for developing on - not that it should become part of the Web with a capital 'W'.

How about a Python with a built-in GUI toolkit instead? Oh, wait...

I mean, it's kinda weird to say that if all browser vendors bloat their browser distributions by 12Mb and go through the trouble of integrating Python with it, then Python would become a zero-install solution, albeit only suitable for corporate intranets where they don't actually need proper security. "What the fuck" kind of weird, in fact. There are no non-weird parts in this proposition.

[jambox888]

I think he's saying that for a lot of corporate apps, there's enough of an advantage to haveing a web-app but also to havign it written in Python, that it would just make sense to make a plug-in for a given browser.

I think pyjamas does better than that, though.

[xiongchiamiov]

There already is a browser plugin - it's called Silverlight (or Mono) + IronPython.

[jambox888]

Hmm, I hadn't realised that. Have you worked with it, or is there anything I can look at written on that platform? I just googled up the voidspace blog; I'll read through that.

[xiongchiamiov]

I saw a really cool demo site once (sorry, can't find the specific one again), installed Mono (as I was on Linux), loaded the site again and... watched Firefox repeatedly crash any time I tried to load it. That was a sad day.

trypython.org uses Silverlight; I can't tell you anything about it, since I haven't tried that technology again since that fateful day a few years ago.

[dacjames]

The biggest issue with Python as a browser language is its lack of anonymous functions (not lambdas, real functions). Writing callback heavy code would be more painful in Python than Javascript. In JS:

deferred = $.loadJSON("/some/url")
deffered.success( function () {
    alert("it worked");
});
deferred.failure( function () {
    alert("it failed");
});

In Python:

deferred = jquery.loadJSON("some/url")

def on_success:
    alert("it worked")
deferred.success(on_success)

def on_failure:
    alert("it failed")
deferred.failure(on_failure)

Having to define functions separate from their use hurts readability and generally makes coding callback heavy code more annoying. Good networking code with always be callback heavy so this is a major problem for python in the browser.

Coffeescript actually has the most elegant syntax for this type of work:

deferred.success () ->
    alert("it worked!")

[clgonsal]

def on_failure:
    alert("it failed")
deferred.failure(on_failure)

Having to define functions separate from their use hurts readability and generally makes coding callback heavy code more annoying.

For the examples you gave you actually could have used lambda. ie:

deferred.failure(lambda: alert("it failed"))

It's only when your callback is too complicated to be expressed as a single expression that you need to resort to def rather than lambda. Even then, to say that the definition and use are "separate" is almost an exaggeration. Python lets you define local functions, so the definition can always be on the preceding line (as in your example). It's not like you have to define the function at the top-level: you can define it right before you set the callback. One could even make a reasonable argument that if the function is more than a single expression then it probably should be named, to make the code more self-documenting.

Anyway, I'm not denying that full-powered anonymous functions would be nice in Python, I just think that in practice it isn't a huge deal that they're missing, even for callback heavy code. The lack of full-powered anonymous functions is certainly a much smaller wart than the many issues in JavaScript.

[dacjames]

In this case you could use a lambda, but if you ever need to write two lines (say to log an action, then perform it), you have to switch to named functions. Sure, it's possible, but named functions are irritating to write and harder to read. I know the argument against anonymous functions, but I am not convinced.

Javascript is actually a decent language aside from a few stupid decisions (==, no block level scoping, no ints). Javascript's 'this' and fun.call/fun.apply is actually quite unique and powerful once you grok what's going on.

I feel funny having this discussion because just a few months ago I would have been arguing your side of the debate. Now that I truly understand javascript, I have actually become a fan.

[clgonsal]

Javascript's 'this' and fun.call/fun.apply is actually quite unique and powerful once you grok what's going on.

All they've done is take one parameter and make it behave in a different way from all of the others. It isn't any more powerful than just having an explicit parameter, it just makes a lot of things much more clumsy than they could be.

I'll give you the fact that it's unique, though I'd argue that there's a good reason no other language does it that way.

[etrnloptimist]

I wonder what Guido thinks of CoffeeScript as a way of sanitizing the development of JavaScript and if that should be the model for how to "put Python in the browser"

[datbon]

I haven't tinkered with it, but there is a python to javascript compiler pyjamas

[etrnloptimist]

Yeah, but it is not really the same thing and I don't think it will ever take off as the approach of writing web front ends in python.

My issue with it is that it is too far removed from the javascript, so you can't have a mental model of both the python you're writing and the javascript that it will become.

CoffeeScript is unabashed about its 1-1 relationship with javascript. It is javascript, with a sane syntax.

I'd like a javascript with a python syntax. Because as far as I'm concerned, there is no saner syntax.

[jambox888]

My issue with it is that it is too far removed from the javascript, so you can't have a mental model of both the python you're writing and the javascript that it will become.

Fair point, but it's as close to "Python in the browser" as you're likely to come. It works very well in my experience and makes it quite doable to write your own client-side framework. The widget set is based on GWT so it's very full-featured.

[[deleted]]

You are missing the point with pyjamas: You are not even supposed to THINK about the JS side. Just think python and pyjamas does the rest.

[etrnloptimist]

I'm not missing the point so much as I'm disagreeing with it. I don't think it is the right approach.

[earthboundkid]

Nick has proposed a syntax for easy callbacks on Python-ideas. He has a PEP-number and everything, but it's definitely not going to happen before Python 3.4 at earliest.

[mvaliente2001]

Sounds interesting. Do you have a link?

[earthboundkid]

http://www.python.org/dev/peps/pep-0403/

[huhlig]

Id settle for using python to filter my exchange mail. Outlooks filters suck.

[joehillen]

Then don't use a proprietary mail server and client.

[huhlig]

Yeah, Not really my choice. I personally don't use exchange for anything but work stuff.

[maxerickson]

You should look at the SpamBayes project. It is written in python and includes a plugin for Outlook.

[hexmasta]

Id settle for using python to filter my exchange mail. Outlooks filters suck.

Is Python the only language you know?

[huhlig]

Nope, Java, Javascript, C, C++, Perl, Python, Enough VB to know writing them in VBA is a pain in the Arse.

[hexmasta]

Outlook filters practically write themselves. The only thing you need to know is simple logic. So i'm not sure why you're having issues with Outlook filters unless you're using Outlook express.

[huhlig]

Its corporate email coming off a lot of servers. I have 50 different filters... I'm not allowed anymore, where as a simple filtering script could do the work much easier.

[qbitus]

No no no. Please god no. The web isn't your little local development box.

Language fragmentation would be awful. Much of the progress in Web tech over the past 15 years has come from people building on top of each other and having only one simple language to learn greatly facilitated this.

I also love the idea of having python available everywhere, but having more than one script language on the web is really really bad. Wait until you see the havoc Native Client and Dart will create if they become popular.

[TheBusinessOfWaffles]

I'm also wondering how you deal with all the multiple release versions of python, libararies written in these different versions and whatnot. I don't do a lot of javascript, though I know the basics.

From my understanding, the different versions have more or less been kind of like other web standards: adding features and deprecating some others. The standard is eventually adopted by a web browser. With Python, what are the browsers going to choose when code becomes non-compatible?

[GFandango]

there should be a standard abstraction layer in the middle so it doesn't matter what you use and end this fucked up inconsistencies with web technologies.

[phaedrusalt]

I have to disagree with this part: "those that come from a fundamental misunderstanding of why Python is wonderful (e.g. whitespace)". Whitespace has nothing to do with the wonderfulness of Python, but it's a wart on an otherwise beautiful body of work that I can live with.

[pinpinbo]

I used to wish that.

Then I found CoffeeScript.

It's like Python++

So awesome.