Comparing Programming Languages
Group: Pradeep Bollineni, Patrick Hartling, Guy Helmer

How does one compare programming languages?

The fundamental goals of software development lie in the areas of expenditures necessary to develop and maintain software, which drive us to look at several important factors, many of which are subjective.

Technical factors include:

Political factors include:

Language vs Compiler for the Language

There are sometimes distinctions between a language and the compilers that implement the language. One compiler made by a given vendor may add extra features to the language they implement that another vendor may not include. An example of this is the concept of ``near'' and ``far'' pointers in DOS that UNIX compilers do not need.

The quality of a language's compilers can also influence the decision. If a language's existing compilers do not produce correctly executing or highly-optimized machine code, the language may not be a good choice for a development effort. We also need to consider what new language features the compiler supports. For example, in C++, the compiler should support the latest additions to the Standard Template Library.

Tool Support and Documentation

Tool support tends to be a critical factor in a language choice. Development tools that help organize a project, quickly locate on-line documentation and examples, and debug programs are extremely useful in the coding and debugging stages of programs. Also, tools that generate code from high-level specifications (such as user interface development or lexical analyzer tools) and tools that verify code or find common mistakes are useful, in our experience. Editors that can parse and format the language syntax are useful as well. Good tools and documentation seem to be driven by popularity, e.g. Visual C++ has good tool support and documentation.

Turing Tarpit

An explanation of the so-called ``Turing Tarpit'' is defined as follows:
``A place where anything is possible but nothing of interest is practical. Alan Turing helped lay the foundations of computer science by showing that all machines and languages capable of expressing a certain very primitive set of operations are logically equivalent in the kinds of computations they can carry out, and in principle have capabilities that differ only in speed from those of the most powerful and elegantly designed computers. However, no machine or language exactly matching Turing's primitive set has ever been built (other than possibly as a classroom exercise), because it would be horribly slow and far too painful to use. A `Turing tar-pit' is any computer language or other tool that shares this property. That is, it's theoretically universal -- but in practice, the harder you struggle to get any real work done, the deeper its inadequacies suck you in.'' [Tarpit]
Thus, at the most basic level, all languages are equivalent and can be used to implement the same tasks. However, the practical nature of this low-level equivalence detracts from the feasiblity of such an effort. It appears that, by these guidelines, we need sufficiently sophisticated constructs (e.g., looping, classes, etc.) to cleanly implement our designs. By comparing similar constructs in different languages, one can get an idea as to how easy/difficult a construct is (to understand and also use) in one language compared to the other.

A language needs sophisticated features while providing less-sophisticated features for occasional use where necessary. For example, Java provides high-level features which are used for nearly all programming, but also provides low-level features such as the Java Native Interface for access to things that a program can not do directly in Java.

In general, staying out of the tarpit seems to require that programmers be prevented from using one language (say Java) to implement an interperter for another language (say Pascal) that will run a program written in that other language. They must also avoid embedding code written in another language within the language that is intended to be used. This is key to avoiding the theory that all languages can be considered to implement any desired program as presented in the Church-Turing Thesis.

Flon's Axiom

Flon's Axiom: There does not now, nor will there ever, exist a programming language in which it is the least bit hard to write bad programs. [Flon75]

We agree with Flon's Axiom, based on experience of reading other people's programs, such as programs in the Obfuscated C and the Obfuscated Perl contests. Flon's Axiom seems to be of little use in choosing programming languages, because it states every language is equally liable to being used poorly.

We are not convinced that Flon's Axiom helps limit useless debate about features. The language debates continue, and language features continue to be painted ``bad'' because they can be used to write ``bad'' programs. However, the axiom can at least be used to point out that even though one language may have features that allow ``bad'' programs to be written, all other languages provide similar methods for writing ``bad'' programs.

Criteria for Comparing Programming Languages

We have previously discussed many criteria important to comparing or evaluating general purpose programming languages. We will summarize them here: The criteria are equally important because they affect the development cost and effort required over the lifetime of the program, and also affect the usefulness and quality of the developed program.

Our experience indicates that these criteria (or the subset which is applicable) also apply to other components that support program development, including object-oriented class libraries and designs for abstract data types. The use of appropriate, useful components external to the language, and the use of designs that result in higher quality, more generalized code improve readability, maintainability, and quality of the product while improving development speed.

Suggestions to Students Comparing Languages

Our suggestions to other students studying these questions would include: Comparing the extremes (Assembly language vs. Java)

References

[Flon75] Flon, Lawrence. ``On Research in Structured Programming'',
      SIGPLAN Notices, October 1975, Vol. 10 No. 10.
[Tarpit] The New Hacker's Dictionary, edited by Eric Raymond. (The MIT Press),
      http://www.netaxs.com/people/nerp/automata/chomsky7.html.
[Zeigler] Zeigler, Stephen F. Comparing Development Costs of C and Ada, March 30, 1995,
      http://www.sw-eng.falls-church.va.us/AdaIC/docs/reports/cada/cada_art.html.
[Java] Gosling, James and Henry McGilton. The Java Language Environment, May 1996,
      http://www.javasoft.com/docs/white/langenv/.