I've never liked this paper.<p>First, I quibble that the metrics are off: the "code ratio" ignores intrinsic factors that alter the numbers, such as the overhead in a "scripting" language for driving the interpreter and managing its resources.<p>Second, and more importantly, it posits that the role of a scripting language is to automate and glue together systems code. History hasn't borne that argument out. You can assert that every Python or Ruby extension is an example of systems code offered by the interpreter for glueing, but architecturally I can make the same claim about every kernel interface, device driver, and chipset feature. The fact is that in 2009 high-level languages are the principal programming environment; lots of apps get built without even considering a "systems programming" environment.<p>Finally, what makes Osterhout's argument even more incoherent is the fact that there's no real line of division between systems programming languages and scripting languages. Feature for feature, Common Lisp and Python are both "scripting" languages in Osterhout's definition. But Common Lisp is a fine systems programming language (people build operating systems in it). He really just seems to be building walls around the immaturity of specific interpreters --- Tcl, in particular, which has always had one of the most primitive execution environments.<p>There's no such thing as a "scripting language". They're all just programming languages.