JavaScript for Pythonistas

My first extreme talk, and Ian Bicking is always worth a listen. Because it's extreme, no intro to JavaScript. "It's a small, simple language with some weird things that are totally understandable." Ian wants to focus on what the language does rather than why it does it.

JavaScript is easily accessible to Python programmers, but the data structures can be tricky. Arrays are like Python lists, objects are like Python dicts. Objects can be fairly lightweight, and can be passed around. Keys are always strings, -- subscripted notation and attribute notation are equivalent. Exceptrions work very similarly to Python, but JavaScript programmers don't use them anywhere near as extensively.

Function declarations are fairly intuitive, but unlike in Python an undeclared variable is assumed to be located in some "containing" scope, and the var keyword causes them to be bound locally. Function arguments are always optional, and parameters for which there is no corresponding actual argument will be undefined. Undefined is "falsish", and we have to use typeof(name) == "undefined" to test for this.

Object classes are created by prototype, which is more like Self, or perhaps Ruby, than Python. The new operator is the only way to effectively create new instances. A function call implicitly binds to the variable this, but without new the binding will be to some global object (in a browser typically the document or the window). The inheritance hierarchy is handled similarly to Python except that instance creation calls the prototype function using new. It's not, therefore, as simple to use factory functions and classes interchangeably - though it can be done if you work.

The this object is almost comparable to Python's self, but the way JavaScript figures out what value it takes is, Ian submits, insane. With no equivalent to Python's bound methods, and method calls are determined syntactically. Consequently assigning an object's method to a local variable will cause this to be computed completely differently depending on whether the method is called directly or through the local variable. This is also problematic when closures are used to create private data stores. You can sometimes overcome it my saving this for later use (Ian chose the name self for the local variable he used to do this).

Functions have .call() and .apply() methods, whihc you can use to call them in specific ways.

Monkey patching should be avoided.

Types are one of the aspects of JavaScript makes least sense to people. It has numbers, strings and Booleans. The language also has the same kind of distinction between primitive and boxed values that Java does. There should really be no need to use the classes that wrap the primitive types. This gives rise to strange non-intuitive rules that are applied during comparisons. The "===" operator is similar to Python's is.

Arrays are disappointing to Python users, being a pale shadow of the Python list. There is not iteration protocol, and no test for containment of a value within a list.

Much of JavaScript's applications work on the browser Document Object Model (DOM). C++ is responsible for the DOM's complexity. The language is improving, but the new features are only slowly working their way into implementations. Many newer features have been inspired by, among other languages, Python.

If you like Python, you might want to try using CoffeeScript. It is more whitespace sensitive than Python, and handles arrays better than JavaScript.

Alas, time for only a few questions:

Q: What do you recommend as the closest equivalent in JavaScript to Python's interactive console. A: Firebug and the like.

Q: What does inheritance look like with prototypes?
A: If a prototype has a prototype that is essentially subclassing.

Preparedness, Privilege and Discrimination

Coming very late to the party I noticed a blog entry from June about the JavaScript community's response to Google's financial support to allow more women to attend JSConf Europe. It sounds like it was indeed the usual real can of worms, and many of the comments show the usual lack of appreciation of the problems from the privileged side of the issue (in this case men, since it is a gender issue and women appear to be about as well represented in the JavaScript community as they are in the Python world, which is to say hardly at all).

The reason I found it interesting was that this year, for the first time, PyCon also used Google's support to fund the attendance for more women, who came from as far afield as Roumania and India. I was gratified to be told by several of those who would otherwise not have been at the conference how happy they were to have had the chance to attend. (In truth I had little to do with it: Google should get the credit for the funding, and the actual hard work was done by Peter Kropf and Gloria Willedsen). In the Python community's case there was one short period of adverse comment on the #python IRC channel, which resulted in my exchanging emails with one person to explain why I thought it was a good idea to encourage more women to be at PyCon. End of story, except that in 2010 women represented 11% of PyCon attendance, up from 2% the previous year. I count that as one of the better results of my time as chairman.

Now I am not saying this to be smug, but because I believe there was a reason for the difference in the reactions. Last year the PSF, at Guido van Rossum's urging, started a diversity mailing list which discussed the questions of race, gender and other discrimination extensively and sometimes acrimoniously. Eventually this led to a proposal for a "diversity statement", which was referred to the membership where it triggered another round of extensive and sometimes acrimonious discussions, leading to a referral back to the diversity list and a further proposal which was finally accepted by the membership more or less unchanged and adopted by the Board:

The Python Software Foundation and the global Python community welcome and encourage participation by everyone. Our community is based on mutual respect, tolerance, and encouragement, and we are working to help each other live up to these principles. We want our community to be more diverse: whoever you are, and whatever your background, we welcome you.

This may not be the best statement ever, but if anyone bothers to look it does make it clear that these issues have been addressed. Thus anyone who feels discriminated against can decide that at least they would have a chance of a fair hearing should they choose to complain (which, sadly, I imagine most don't, instead choosing to vote with their feet). Similarly, anyone about to indulge in discriminatory behavior might think twice before doing so.

The hidden benefit of this long-drawn-out process was the creation, on the diversity list, of a corpus of varied individuals who had discussed these  issues and hammered out a shared approach to the problems that included a refusal to punish individuals for things done out of ignorance. It also meant that when one speaker used a slightly ill-advised graphic in a presentation the issue was dealt with then and there in a very direct manner without any recriminations, and I didn't even get to hear about it until  much later that day. The speaker was advised that the material was inappropriate and that therefore the slides and the video of the talk wouldn't be published, and hopefully left without feeling that they weren't welcome at next year's conference.

I hope that the JavaScript community manages to develop its own understanding of diversity issues and its own process for dealing with them. I know it took up a lot of my time as PSF chairman and gave me some uncomfortable moments (and does not exempt me from the results of my own stupidity in the future), but I am glad it led to a tolerant community process that nevertheless has made it clear that discrimination is not acceptable.