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

How does one compare programming languages?

Technical factors include:

• Application requirements: Languages tend to be suited to particular applications. For example, C is widely used for operating system development (UNIX, Linux, and Windows, to name a few), while Perl is useful for text processing, HTTP server CGI programs, and system administration work.
• Platform requirements: The platform on which an application is to be executed may have a limited choice of language implementations available.
• Development time: How quickly could the application be developed in a particular language? (The technical side of this question depends on how understandable the language is, and how easily an application's design can be coded in it; the political side of this question depends on the knowledge of programming staff, training available, or whether programmers with experience in the language can be hired.)
• Portability: Execution platforms for programs tend to change over time (e.g., from DOS to Windows to Windows NT, just to trace the ``Wintel'' lineage). Is the language closely tied to a particular machine (e.g., the use of ``far'' and ``near'' pointers in C on DOS and Windows), or is the language clearly portable (e.g., Java's clear independence of any particular machine's quirks or implementation)?

• Popularity of the language: Popularity, in terms of the size of the marketplace and number of programmers using a language, clearly affects the choice of a language. The choice of a well-known, popular language, such as C, or a lesser-used language, such as Ada, will influence hiring and/or training requirements. [Zeigler]
• Economic: Which language tends to be cheapest or most cost effective in previous, similar development efforts? Is the language well-supported by commercial organizations or freeware development communities (i.e., will the language's compilers and development environment be available for the foreseeable future)? [Zeigler]

Language vs Compiler for the Language

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

Turing Tarpit

``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]

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

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

• Simplicity of language constructs, which relates to ease of programming
• Readability, which relates to maintainability, an important factor as many programs greatly outlive their expected lifetimes (witness the Y2K software crisis)
• How tuned a language's features are for a particular application (e.g., Perl relates well to text processing)
• Compilation speed
• Runtime efficiency, in terms of speed and machine resources
• Library support
• Debugging help
• Language safety
• Longevity of language and compiler tools
• Portability across platforms and machine architectures

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

• A variety of experiences in languages and an understanding of programming languages in general is important.
  • Studying and comparing the basic constructs common to most or all programming languages can provide a better understanding of benefits and drawbacks.
  • Studying the process behind syntax design (i.e., what is the deciding factor behind choosing one syntactical construct over another) aids in determining the readability of the code.
  • Comparing the level of abstraction of several languages to decide where the best medium between too high and too low lies can provide insight into how much time is needed for development, into what level of efficiency will be present at runtime, and into how readable the actual code will be.
  • Determining what makes a language ``safe'' provides a better understanding of how one language may be better than another.
• Experimentation with languages gives a good understanding of what can be done easily in one language as well as what cannot be done easily in that language.
• Investigation into new paradigms (e.g., concurrent languages, component programming, object-orientation models, etc.) furhter increases comparison capabilities.
• Much more effort could be expended in discussing these issues than we have been able to do in this short amount of time.

References