Programming Language Evaluation Criteria Part 2: Writability, Reliability, Cost
In this article, I continue to talk about criteria for evaluating programming languages, concluding what’s started in“Programming Language Evaluation Criteria Part 1: Readability”. If you haven’t read it yet, go check it out
Writability
Think of writability as the ease of writing a program, given the problem it must solve. Consider readability and writability as two different aspects of a language, with common causes.
In fact, the writer often has to re-read what he wrote.
Also in this case, consider writability with respect to the context for which a language has been thought. You can express yourself well and easily with a language if you use it in context and for problems for which it was thought; otherwise, it becomes complex to use.
Orthogonality and simplicity
For orthogonality and simplicity, the same considerations made for readability have to be done.
Too many constructs and too many ways of combining the constructs of a language, can lead to writing errors, ignored by both the programmer and the compiler. Furthermore, too much freedom of use, especially with complex constructs, can lead to difficulties in use. This often support poor elegantness and difficulties to modify implemented solutions.
Expression
By expressiveness, I mean the possibility of expressing a certain computation in a convenient manner.
For example:
C language:
count = count + 1;is less easily written than:
count ++;
Reliability
In general, think of it as the ability of a program to comply with its specifications, under all conditions.
There are various aspects that contribute to reliability.
Type Checking
It is a type error check, done by the compiler or, during execution, by the interpreter.
A fairly simple example is the assignment to an integer variable of the result of a division, which produces a decimal value.
As a rule, type checking done at compile time is desirable; this both for computational costs reasons and because you want to find errors as soon as possible.
Exception handling
A certain language can allow better exception handling than others.
Good and easy management is certainly an aid to reliability. It is implied that this ease of management should not impact running process.
Aliasing
If you do not know what this is, you can imagine aliasing as the possibility of referring to the same (virtual) memory cell with different names. As if the memory cell has a name and a nickname.
Most of modern languages allow the use of aliasing, in different quantities. Aliasing can be a danger in development, although its usefullness, because, as reader or writer, you have to remember what you have done. The responsibility for managing aliasing lies in the programmer and this is always a problem for reliability.
Readability and writability
I put it simple: if it’s easy to write and read a language, then there are good chances that the program written in that language will be correct.
Cost
The cost of a language depends on many factors. Let’s see a short list.
First of all, to instruct programmers to use a certain language. This cost is a function of simplicity and orthogonality. Generally, the more powerful a language is, the more complex it is.
Secondly, there is a cost linked both to the difficulty of writing in a certain language and to the preparation and use of the right development environment.
Historically speaking, these costs have led to the birth of very high level languages and functional languages.
Linked to the cost of the development environment, there is the “cost of compilation”; some compilers have usage costs and, in some cases, require a certain type of hardware. Moreover, almost all the compilers carry out various kinds of optimizations, which certainly can lead to longer compilation times, different occupied memory space and execution times.
Let’s focus for a second to the cost of execution. Different languages, different execution behavior. For example, a language that does many run time type check will certainly be expensive to run.
Today,a lot of programmers ignore execution efficiency problems for most applications, but ignoring them can lead to higher cost in the future and even to application failure. So, be careful about what and when to ignore. For example, users don’t worry about efficiency if the application is a virtual wallet, while instead it becomes a big issue if they want to pass from gaming at 30 fps to 60 fps.
Then there are the costs related to reliability. For example, a language that has good and easy to use concurrency mechanism, can more easily be used in systems where concurrency is critical. Imagine the costs you would have in the banking sector, if you have to implement secure data access from scratch, without language support to concurrency, or to deal with errors caused by bad language design.
Finally, the costs associated with maintaining the code (both modification and correction).
Maintenance costs depend on many factors, but mainly on readability. In fact, maintenance is done by someone other than who originally wrote the code.
Honorable Mentions
I cite you other evaluation criteria of a language, on which, however, I do not go into detail.
Portability, that is, the ease in bringing a code from one hardware implementation to another.
This factor strongly depends on the standardization of the language.
Finally, the generality and the well-definedness: respectively, the size of the set of problems for which a language can be applied (that is, language applicability), and the completeness and precision of the definition of the language documentation.
