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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide