Programming Languages Reviewer
Programming Languages Reviewer
Programming Languages Reviewer
The actual users of languages (businesses, engineers, scientists, students, managers, secretaries, etc.) have
certain demands on the languages they use. One legitimate way to evaluate languages is to ask whether a given
language meets the needs of a given user community.
Rapid development
Programmers are more expensive than machines, so they'd better be able to make fast progress. (We
should consider both the language and its environment in making this evaluation.)
Easy maintenance
Maintenance is expensive.
Reliability and safety
When computers go down, planes crash, phone systems break, nuclear reactors melt down, cash
machines close. We'd like to avoid this.
Portability
I'd like my program to run on many different platforms, with minimal rewriting.
Efficiency
The compiler should be fast. The code itself should be fast.
Low training time (learnability)
The language should be easy to learn. Training is expensive.
Reusability
Writing software components once is cheaper than writing them twice.
Pedagogical value
The language should support and enforce the concepts you want to teach.
Although the above demands are all important, we should still ask what makes a good language, independent of
the demands of its users. This is a little like the question "What makes a good artwork?" as opposed to "What
makes a good Hollywood movie?" Here are some qualities of a good language.
Readability
Understand what you, or someone else has written.
Writeability
Say what you mean, without excessive verbiage.
Simplicity
The language should have a minimal number of primitive concepts/features.
Orthogonality
The language should support the combination of its concepts/features in a meaningful way.
Consistency
The language should not include needless inconsistencies. (But remember Ralph Waldo Emerson: "A
foolish consistency is the hobgoblin of small minds.")
Expressiveness
The programmer should be able to express their algorithm naturally.
Abstraction
The language should support a high level of data and control abstraction.
We will generally make use of these and other internal evaluation criteria when comparing languages.
Binding Time Examples
Binding Time
Early binding times (before run time) are associated with greater efficiency
o Compilers try to fix decisions that can be taken at compile time to avoid to generate code that
makes a decision at run time
o Syntax and static semantics checking is performed only once at compile time and does not
impose any run-time overheads
Late binding times (at run time) are associated with greater flexibility
o Interpreters allow programs to be extended at run time
o Languages such as Smalltalk-80 with polymorphic types allow variable names to refer to objects
of multiple types at run time
o Method binding in object-oriented languages must be late to support dynamic binding
A binding is static if it occurs before run time and remains unchanged throughout program execution
A binding is dynamic if it occurs during execution or can change during execution of the program
In many ways, binding times for various attributes determine the flavor of a language