Readers' Choice Awards 2008
Programming Languages and Scripting Languages
We received a lot of feedback about our on-line survey of favorite languages. A particular point from this feedback has been why some languages were called scripting languages, and others not. A criterion was used to decide this, as will be explained. A plethora of issues was raised in the responses we received, so highlighting some of the issues will contextualize how the criteria emerged for this survey.
One simple way of distinguishing computer programming languages is whether they are compiled or interpreted, which several Linux Journal readers pointed out. However, even that is an issue. Java is considered as a general-purpose programming language, but nominally the runtime environment is a Java Virtual Machine. This is very similar to a variety of scripting languages actually, including Emacs Lisp. However, Java also can be compiled to native machine code. So, for the interpreted versus compiled issue, one might ask, “What kind of compiled?”
A scripting language could generally be a language that is hosted by another environment. In other words, it's “running on top of something”, whether that be a byte-code interpreter or, in the case of embedded application use, as an adjunct to another software application. One also might ask whether the breadth and representative power are obtained by libraries, or because of built-ins to the language?
Scripting languages also can have object features and work at a higher level, or work more like a dynamic language, such as Lisp, which does manifest typing. AWK and Python or Perl are arguably scripting languages, but they are quite different in their utility. One might think of AWK as slightly easier to use than bash, with the particularly nice facet of associative arrays. But, Python or Perl (via strong libraries) are much more powerful, and they are glued to numerous layers in the complete FLOSS stack. So, the “grain size” of a scripting language tends to matter as to its utility.
One of the scripting languages that was omitted in the original survey was Tcl, and this was a mistake. Tcl is very popular, especially in certain application domains, such as CAD tools, where it is a de facto scripting language. Similarly, upon further reflection, it might be argued that the general-purpose programming language BASIC that is most in use today is not really a later variant of Kemeney and Kurtz' 1964 original, but rather Visual BASIC, arguably a scripting language. However, that language generally does not run well on Linux, and efforts to bring this particular language to Linux have provoked some controversy.
Based on comparative technical criteria, one could make the case that Java is a scripting language. Its runtime implementation is strikingly similar to Python, though there are clearly very divergent language syntax and semantics in both: Python is much less strongly typed. The problem is that Java users really don't use it as a scripting language, and its promoters don't promote it that way either. It's much more ubiquitous in any of its roles, such as middle-ware, for complete applications, or as a standalone embedded platform. So, a leading clue is that what defines a “scripting language” is not necessarily decided along strictly technical lines.
Perhaps the motivating factor behind what determines whether a language is a scripting language or programming language is ultimately how a critical mass of users tend to use it. Other factors include how it's promoted, whether it's standardized, how the user community is responded to with emergent problems or technical issues, and how the primary maintainers allow the language to “evolve” where necessary. A really good way to see this is to compare the number of technical book titles on computer languages and associated libraries or environments in a modest bookstore.
Finally, it was this “tendency of use” that was the primary litmus test to assert which language was selected as a programming language versus as a scripting language. Some respondents have rightly pointed out that this was relatively “arbitrary”, and that there were numerous dissonances along the axis of “compiled” versus “interpreted”. They are right. This arbitrariness is borne out, in fact, by the usage patterns seen; the mass of users themselves really have decided the use models. Practical and reasonable programmers, in fact, do disagree on such distinctions.
Such divides cut across much more than compiled or not. A larger divide would appear to be strongly typed versus dynamic languages. Another would be functional versus imperative. One divide that seems to be waning is whether object-oriented is good; we generally seem to believe that it is. Despite this general consensus, C is not going away any time soon. C is viewed as the most portable high-level “assembly language” there is.
I think a conundrum about languages is benign, and actually good news, because it reflects the diversity of choice and utility. If the absolute ultimate runtime performance is not relevant to a programming problem, modern scripting languages are a strong play. One can get more done with fewer lines of code, if compared with starting a program in the C language. Most are easier to learn and use than, say, C++. This may well be a legacy of highly evolved computer technology. If you believe that “premature optimization is the root of all evil”, perhaps using a “standard” programming language is one kind of premature optimization. A lot of careful thinking has gone into certain scripting languages, and very strong compilation software is available to host these languages. But, these advances in computer science also derive benefit from late-modern hardware technology. Machines today are so fast that it really is possible to use scripting languages as general-purpose programming languages for nearly any purpose on a wide variety of applications.
—Michael Baxter, Technical Editor, Linux Journal
James Gray is Products Editor for Linux Journal
Special Reports: DevOps
Have projects in development that need help? Have a great development operation in place that can ALWAYS be better? Regardless of where you are in your DevOps process, Linux Journal can help!
With deep focus on Collaborative Development, Continuous Testing and Release & Deployment, we offer here the DEFINITIVE DevOps for Dummies, a mobile Application Development Primer, advice & help from the experts, plus a host of other books, videos, podcasts and more. All free with a quick, one-time registration. Start browsing now...
- Hash Tables—Theory and Practice
- The Ubuntu Conspiracy
- A First Look at IBM's New Linux Servers
- Vigilante Malware
- Vagrant Simplified
- Disney's Linux Light Bulbs (Not a "Luxo Jr." Reboot)
- Science on Android
- System Status as SMS Text Messages
- Bluetooth Hacks
- Making a PHP Site on Linux Work with a Microsoft SQL Server Database