Wednesday, August 4, 2010

Java, Javascript, and the Installation Hurdle

For the past three years I've been teaching high school computer classes while using Java to teach the basics of programming in class. My usual routine is to teach HTML and CSS in the first semester, which provides the students with many of the basic skills of programming. Then in the second semester we start actually programming with Java.

The past two years I've taken advantage of the Greenfoot framework for Java. It eases the use of graphics and sound in Java programs, but more importantly it provides a visual representation of classes and objects. This greatly eases the burden of teaching what object oriented programming is all about, as well as demonstrating its advantages.

My reasons for using Java are several. Briefly, it's multi-platform. It's a "real" language, in that it is used outside the school and professionals are employed to use it. It incorporates the available facilities of the system, including graphics and sound, natively.

One of my hopes for my students is that after using Java in class, at least some of them will use it outside class as well. Unfortunately, for many of them the installation process has been a roadblock to doing this. Particularly in Windows, where an extra step has to be performed to add the Java SDK to the system's path. The students with Mac OS X at home are lucky, they don't have to install the SDK, it comes with the OS. The Linux users are usually capable of managing it for themselves. But about 80% of my students are under Windows outside of class. And the Java SDK install isn't what they're used to.

One potential solution to this would be moving to Javascript. There's no installation barrier there. One reason I've not used Javascript in class is that graphics subsystems like Canvas and SVG are not uniformly available. Even when IE9 comes out as a regular product next year, those students with Windows XP systems at home (about 75% of the Windows-only homes are running only XP, based on my surveys in class), this problem won't be entirely solved. The difference here is that the install of a second browser is a lot easier than a Java SDK install.

The installation barrier won't be the only thing my choice of language in class hinges on, but it's certainly a significant factor. Exactly why the Java SDK install has remained so hostile to Windows users is unclear to me. It smacks of elitism on the part of Sun/Oracle (if you can't hack the install process, we don't want you using it), but then the old saw about not ascribing evil intent where simple incompetence will suffice comes in. Maybe they just don't think it's a problem.

I expect to at least introduce Javascript this year as part of the HTML/CSS segment. Whether I do so and how deep we'll get into it will depend heavily on the character of the class--the chemistry of the students in any given class can make things vary a lot from class to class. Sometimes it's a struggle to get past <html><head><title><body>, other times I find them getting ahead of my lecture by several classes during one open work period.

Another factor in my willingness to consider using Javascript as the primary language in class is the advances the language has made recently. The ECMAScript Edition 5 specification is a big improvement on earlier specifications for the language. Likewise, the viewpoints of Douglas Crockford have influenced my impression of the language and its use.

If you're interested in Javascript, I highly recommend his book: JavaScript: The Good Parts.
There was an error in this gadget