Programming Languages Reviewer

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 3

Evaluating Programming Languages

How do we evaluate a given programming language?

External Evaluation Criteria

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.

Internal Evaluation Criteria

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

 A binding is an association between a name and the thing that is named


 Binding time is the time at which an implementation decision is made to create a binding
1. Language design time: the design of specific program constructs (syntax), primitive types, and
meaning (semantics)
2. Language implementation time: fixation of implementation constants such as numeric precision,
run-time memory sizes, max identifier name length, number and types of built-in exceptions, etc.
3. Program writing time: the programmer's choice of algorithms and data structures
4. Compile time: the time of translation of high-level constructs to machine code and choice of
memory layout for objects
5. Link time: the time at which multiple object codes (machine code files) and libraries are
combined into one executable
6. Load time: the time at which the operating system loads the executable in memory
7. Run time: the time during which a program executes (runs)

The Effect of 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

Static and 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

 As binding time gets earlier:


o efficiency goes up
o safety goes up
o flexibility goes down

You might also like