REFLECTIONSLanguage wars and false dichotomies

access to one. Therefore, make programming them more openly accessible! Some of my colleagues might recall the days when a personal computer presented only one choice, “program me”, in the form of the BASIC prompt “OK”. The so called “language wars” in our community center more around the formal introduction of computing where we have spent countless arguments going back and forth in self created dichotomies over the years: low-level vs. high-level, procedural vs. functional, compiled vs. interpreted, WITH OVER THREE BILLION COMPUTERS in use today (not counting smart phones and other programmable devices) it begs the question: How best to program them? Since FORTRAN in the 1950s, the computing community has offered over 2500 choices given that it has developed new programming languages at the rate of over one new language a week [1]. Several per week depending on what you may consider is (is not) a (new) programming language. This is obviously a conundrum for at least 2.9 billion or more computer users. Our colleagues in the computing industry might be quick to respond with C, C++, C#, Delphi, Java, Objective C, Perl, PHP, Python, and Visual Basic. For these, according to the TIOBE Index, make up the top ten most popular programming languages [4]. Though this is no indication of the number of lines of code or the percentage of software developed, the folks at TIOBE are quick to point out. Those passionate about their favorite language missing from the above might want to consult the next 20 or 50 languages on the TIOBE list. Some might even argue about how many of the 2.9 billion ever think about the need to program. For the computing education community wider access to programmable computing ought to be a priority. To make matters worse, increasingly, computing devices are being designed to shut out even those who can and want to program. Look up the SDK licensing for the Apple iPad, for example. static vs. dynamic, typeless vs. stronglytyped, threads vs. event-driven, nothing but object-oriented, and so on. Those in the programming language community tend to provide a slightly broader, more conceptual classifi cation of families of programming languages: imperative, objectoriented, functional, and declarative. Looking at the top ten listing above, it is clear that in the eyes of the computing industry, the latter two categories of programming languages do not play a signifi cant role. What is more, they seem to fail to recognize or properly situate at least half of the languages on TIOBE’s top ten list. In a 1998 paper, now considered seminal/landmark, John Ousterhout addresses this by making the case for a new family of programming languages: scripting or glue languages that will dominate the higher level programming landscape for the 21st century [3]. In Ousterhout’s Dichotomy (as it has come to be called), there are system programming languages (e.g., C, C++, Java) and then there are scripting languages (e.g., TCL, Perl, PHP, Python). System programming languages, Ousterhout explains, were designed to build data structures and algorithms from scratch, they tend to be strongly typed, are often complied, and evolved from the need to handle the same tasks as assembly languages, albeit at a “higher level”. “Higher level”, Ousterhout explains further, is relative to assembly level. A single line of code written in a system programming language roughly corresponds to a handful of equivalent assembly instructions (3 to 7) and the compiler handles the details of translation such as register allocation, procedure calls, and control structures. In terms of programmer productivity on any given task, system programming languages are at par with assembly languages since programming in assembly languages requires three to six times as many lines of code as the same program in a system programming language. Scripting languages, on the other hand, are designed to glue together applications rapidly using existing useful components that may be written in other (system) languages. They are not new per se (remember IBM’s JCL?) and have been in existence since the 1960s. They tend to be typeless (to encourage reuse), are interpreted (hence tend Language Wars and