Start here

JavaScript as a first programming language? Some pros and cons

Recently I was working with a group of JavaScript developers in Australia. One of them observed (from maintaining code written by other developers) that he felt people coded in JavaScript in various styles, depending on their programming background, and that this stylistic mashup was perhaps a consequence of the fact that no-one used JavaScript as their first programming language, so they brought their stylistic baggage with them from a range of other ‘first’ languages.

Now I don’t know if there is actually no-one out there who first learned to program with JavaScript, but I suspect there would be very few, for good reason. Historically, JavaScript has been hard to write (no decent development environments), hard to debug, hard to test, and the browser runtimes were slow and flaky. That is no longer the case. IDEs like WebStorm make it easy to develop code, and when it is used with the plugin for Chrome, it also provides a full debugging environment. There are now a range of test tools available, including QUnit, and the quality of JavaScript engines in browsers has increased hugely.

So, would JavaScript be a good first programming language? It has some nice features that would make it seem attractive. It supports higher order functions that can be passed around using variables, it supports variadic functions for variable length parameter lists, and supports closures. You could teach people to use functions without the object oriented baggage of something like Java. Once you do want to use objects, its type system does not support all the features of a classical inheritance based language, but on the other hand it is dynamic, so complex data types can be reconstructed at run time, a really cool feature.

What about the down sides? Well there are still a few. The loose type system is a trap for the unwary, as is the lack of block scoping in favour of function scoping (though the ‘let’ keyword will address this once the major browsers all support it), and another danger is the ease with which global variables can be created (either deliberately or accidentally.) Whacky features like hoisting (where you can use a variable before you declare it) might also confuse the beginner, and running your code in a browser might get in the way of focusing on the basics of the language at the expense of being distracted by the UI.

Some of these issues might be addressed with tools like Microsoft’s TypeScript language, which brings type checking to JavaScript, and tedious browser document navigation and UI issues are simplified by libraries such as jQuery.

So, would I want to try teaching JavaScript as a first language? It probably depends on the type of class. For students at the ‘softer’/applied end of computing, learning the pre-eminent language of the Web, with quick and easy routes to seeing something useful happening in a browser, might not be such a bad place to start.

Recently we had an issue with one of our postgraduate students who was disappointed with the grade he received for his research report. He had been under the impression from his supervisor that his work was of a high standard, but it was assessed as being very poor. It struck me that this unfortunate circumstance may well have been a simple matter of miscommunication rather than anything  else. It reminded me of a document, of uncertain provenance, that claims to be an ‘Anglo-EU translation guide’ and appears on many sites across the web. It consists of a table with the following columns: ‘what the British say’,  ‘what the British mean’ and ‘what others understand’. With acknowledgements to the originators, I have put together my own version, which attempts to  provide a ‘supervisor- research student translation guide’.

What the research supervisor says What the research supervisor means What the research student thinks has been said
You have chosen an interesting topic The project is both boring and impossible I am a genius
You may have missed one or two references You have not read or understood anything My literature review is almost complete
You may need to sharpen the focus of your conclusions Your work has made no contribution whatsoever My conclusions are important
I hear what you say I disagree entirely and do not expect to see this in the thesis I must put this in the thesis
With the greatest respect… I think you are an idiot They are listening to me
That’s not bad That’s good That’s poor
That is a very brave proposal You are insane They think I have courage
Quite good A bit disappointing Quite good
I would suggest… Do it or you will fail Think about the idea, but do what you like
Oh, incidentally/ by the way The primary purpose of our discussion is… That is not very important
I was a bit disappointed that I am annoyed that It really doesn’t matter
Very interesting That is clearly nonsense They are impressed
I’ll bear it in mind I’ve forgotten it already They will probably do it
I may have misunderstood, but… You have completely missed the point They have misunderstood
Perhaps you should write this up as a paper If you won’t listen to me, perhaps a rejection will wake you up They think my work is publishable
I almost agree I don’t agree at all They agree
I only have a few minor comments Please re-write completely They have found a few typos
Could we consider some other options? I don’t like your idea They have not yet decided
Correct me if I’m wrong I’m right, don’t contradict me They are wrong and need correcting
Up to a point Not in the slightest Partially
It’s time to start nominating your examiners Damn, we’re running out of time I am nearly finished
The examiners have suggested a few changes You deserved to fail but they have generously given you six months to try to salvage the thesis I have a doctorate, I will start applying for jobs

Faking your location – how and why

One of the many interesting types of app you can download on your phone is one that will fake your GPS location. There are quite a few of these on the app stores, but they all work in much the same way. If you turn off the network based location services on your phone, but leave the GPS service on, these apps can fool any other app that uses your GPS location into thinking you are somewhere else (and there are plenty of these – think of all those permissions you say ‘yes’ to without reading them every time you install a new app.) When you run a fake GPS app, all you have to do is click on a map of where you want to pretend to be and hey presto, your boss thinks you’re at a client, your partner thinks you’re working late, your accounts department thinks you’re staying in a cheap hotel and your friends think you’re on holiday in the Cayman Islands.

Well, those seem to be the kind of use cases that people suggest on the Web. I had a rather more humdrum requirement. I was updating a mobile learning game that we have been developing for a long time, and converting it to use the most recent version of the Google Maps API. Unfortunately this renders it impossible to test map based apps in desktop device emulators without some rather nasty hacks, which are technically illegal. The only sensible option is to test your apps on a device, but how do I test a location based app when I’m sitting in the office with the phone connected to the laptop through a cable?

The answer is. of course, to fake your GPS location with one of the aforementioned apps. I used ‘Fake GPS Fake Location’ by Andev, but there are plenty of others (with very similar names). First, I ran the app, then just moved the red dot to where I wanted to pretend to be. In this case, I wanted to generate some screen captures of the game being used at Hanyang University in Seoul, Korea, where we had been testing the game, so I positioned the dot there. Here’s what the screen looks like in the Fake Location app.


Next, I ran my own app, and it was fooled into thinking I was in Seoul. Here’s my app, running on the device in Auckland, reading the GPS as normal, but getting fooled.


Faking your GPS location may have all kinds of strange and sneaky uses, but from the perspective of testing location based mobile apps it’s a great tool.


Validating Hofstede? Some reflections on cultural differences

This semester, for the second year running, I tried out a small experiment with one of my classes to see if the students cultural profile matched Hofstede’s results for New Zealand:

I asked the students to fill in the VSM94 questionnaire, then put their results (anonymously) into a shared Google doc that calculated the results according to the algorithms outlined in the VSM94 manual. The sample size was only 30, so take the results with a pinch of salt, but the outcome was very interesting, and replicated the results from last year. Despite the fact that the majority of my students were not born in New Zealand, the results of our survey correlated quite closely with Hofstede’s figures, apart from masculinity:

Cultural Measure Hofstede Result Student Result
Power Distance 22 20
Individualism 79 72
Masculinity 58 33
Uncertainty Avoidance 49 58

Certainly wider New Zealand society has masculine traits with a strong emphasis on competing in sport, aggressive outdoor activities and terrible driving, but perhaps students have a different subculture? However it is the similarities that interest me more than the differences, suggesting that we absorb the culture around us  quite quickly, given the short time that some of my students have been in New Zealand.

Ignatia Webs blog post – the future of mobile learning

Ignatia Webs blog post – the future of mobile learning

I was very pleased to see this positive blog post review of a chapter I recently published in an open access book on mobile learning, which the blogger, Inge De Ward, also tweeted. Inge’s blog and Twitter feed must be quite popular, judging by the large number re-tweets that ensued. Please take a look at the blog post, and also the article (the blog contains a link to it)

Strong passwords, stronger extortionists

I’ve posted before about passwords, specifically about the large number of extremely weak passwords revealed by the Adobe hackers. I recently saw a story on the BBC web site about a password that the security forces couldn’t crack. Here’s the article:

Man jailed for refusing to give police USB stick password

The password was $ur4ht4ub4h8, apparently a play on words relating to a chapter of the Koran. Next time some piece of software insists your password must include a mix of upper and lower case letters you can tell it to go take a hike.

If the password was so uncrackable, you may wonder, how come it’s in the article? Well as usual the security of your password is only part of the story, the authorities have many ways of extorting your passwords out of you, as this article describes:

David Miranda feels ‘invaded’ after password disclosure

The moral of the story, if there is one, might be that however secure your data is, you yourself are more easily hacked.

Testing, Testing…

I’ve recently been interested to see a couple of examples where the concepts of test driven development and regression testing were clearly not applied, or at least not applied as they should have been.

The first example was FaceTime on my old iPod Touch. Having worked perfectly happily for years, communicating with an identical device in the UK, it suddenly started failing, and for a while I was reduced to using the much flakier Skype. As you do, I stared surfing the web for answers to the problem. I soon found a growing number of people interacting on various on-line forums complaining about a similar issue. Clearly, the common denominator seemed to be a regression caused by a recent upgrade to the iOS operating system on iPod Touch 4th generation. Interestingly, the response from Apple, if the experiences of those on the forums were anything to go by, seemed to be one of total disinterest. However, a few weeks later, Apple quietly released the following fix for a problem that had affected ‘some users’ (i.e. many):

Now I know, from painful experience, how hard it is to test for this type of fault, but Apple should have had regression tests in place for changes that might affect popular standard apps like FaceTime.

The other interesting example was this one, about LG televisions sending personal data back to the company, even when a privacy setting had been turned on:

Now you would expect, if this software had been test driven, that a test would have been written that ensured that activating the privacy setting meant that data could not be sent. Instead, data was still sent, along with an indication that the privacy setting was turned on. Either that wasn’t tested at all, or it was driven by a stupid test. The alternative interpretation, that LG wants your data whether you like it or not is, I’m sure, not the case.

These two examples are instructive because they emphasize how important it is to (a) drive your designs with unit tests and (b) avoid the entropy of your software with regression tests.




Get every new post delivered to your Inbox.