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
Technical factors include:
Political 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
- Platform requirements: The platform on which an application is to be
executed may have a limited choice of language implementations
- 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
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
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.
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: There does not now, nor will there ever, exist a
programming language in which it is the least bit hard to write bad
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
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''
Criteria for Comparing Programming Languages
We have previously discussed many criteria important to comparing or
evaluating general purpose programming languages. We will summarize
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.
- Simplicity of language constructs, which relates to ease of
- 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
Suggestions to Students Comparing Languages
Our suggestions to other students studying these questions would
Comparing the extremes (Assembly language vs.
- 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.
[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
[Zeigler] Zeigler, Stephen F. Comparing Development Costs of C and Ada,
March 30, 1995,
[Java] Gosling, James and Henry McGilton. The Java Language Environment,