The New Standard Model
The Standard Model is modern physics’ baseline explanation of How It All Works. It encompasses pretty much everything there is, except gravity. From subatomic physics to cosmology, everyone builds their theory in its image, hoping to create a new standard to supplant today’s.
For the developers of my generation, the Standard Model of programming took shape in the early 1980s. It consisted of:
- C (which has mutated  into C++);
- a character-oriented editor like Vi or Emacs;
- Make for automating the complexities of rebuilding code;
- the standard  Unix command-line tools like
- CVS for version control;
- character streams as a data exchange format; and
- "power tools" like Yacc and Awk for more complex tasks.
By the late 1980s, Microsoft had developed an alternative. It was also based on C, but presented developers with an IDE instead of a character-oriented editor, and gave users uncomposable GUIs instead of command-line filters. Visual Basic was the standard for scripting, and COM was how programmers glued components together.
Microsoft’s offerings were well engineered (more so than most Open Source advocates would like to admit). However, many programmers disliked the complexity of Microsoft’s offerings, and its business model—so much so that they were willing to adopt a new language instead. The result has been a New Standard Model—a morally respectable replacement for the venerable Unix toolset. As evidenced by a slew of recent books , this environment consists of:
- Eclipse and its many plugins
- Ant (for building) and JUnit (for testing);
- XML as a data exchange format;
- some form of scripting language ;
- reflection, and technologies built on top of it like JavaBeans, for managing components; and
- a web presence for everything (e.g. a project dashboard, a searchable mailing list archive, and so on ).
One of the most interesting things about the New Standard Model is how much of it is open source. Java itself is the glaring exception, but good implementations are freely available and (unusually for free software) very well documented. Most  North American universities have already switched to Java as a first teaching language.
However, most schools have not updated the rest of their curriculum. Few instructors, for example, require students to submit JUnit tests with exercise solutions in upper-year courses, or take XML and reflection as givens. CSC207, a new course at the University of Toronto, is an attempt to get the individual-oriented bits of this model into the curriculum.
The goal of the Helium project is to make it easy for instructors to teach the team-oriented bits of the New Standard Model. In order to do this, we are building a web application that is inspired by SourceForge, but tailored for the particular needs of classroom instruction. Using this, instructors will be able to create batches of team programming projects, while students will gain experience with version control, issue tracking, and so on.
This blog will record our progress as we figure out what Helium should do (most importantly, what it should do differently from industrial-strength systems like SourceForce), and as we discover how to build it. Comments and pointers are very welcome.
 I use the word in its science fiction “meddling with what ought not be meddled with” sense.
 By which I mean those defined in Kernighan and Pike’s The Unix Programming Environment, rather than those defined by some after-the-fact standards committee trying to produce a facade of unity by kitchen-sinking every feature any of them had ever shoe-horned into their clumsy, crippled implementations of—sorry, sorry, got carried away there.
 See Java Extreme Programming Cookbook, Professional Java Tools for Extreme Programming, Explorer’s Guide to Java Open Source Tools, and many others.
 As much as I like Python’s syntax, Jython and its ilk are crippled by the impedance mis-match between the semantics of their native data structures, and Java’s. For example, if you want to create a list in Jython, and pass it into some Java code, you must either translate Jython’s type to a Java List, or use a Java List in the first place—in which case, you lose much of the ease-of-use that makes scripting languages attractive in the first place. On the other hand, while Groovy uses native Java types, it doesn’t actually work at the moment…
 85%, according to one large textbook publisher; I’ve heard others quote 90% or more.