Comparison of programming languages

Type systems

Failsafe I/O and system calls

Most programming languages will print an error message or throw an exception if an input/output operation or other system call (e.g., chmod, kill) fails, unless the programmer has explicitly arranged for different handling of these events. Thus, these languages fail safely in this regard.

Some (mostly older) languages require that programmers explicitly add checks for these kinds of errors. Psychologically, different cognitive biases (e.g., optimism bias) may affect novices and experts alike and lead them to skip these checks. This can lead to erroneous behavior.

Failsafe I/O is a feature of 1C:Enterprise, Ada (exceptions), ALGOL (exceptions or return value depending on function), Ballerina, C#, Common Lisp ("conditions and restarts" system), Curry, D (throwing on failure), Erlang, Fortran, Go (unless result explicitly ignored), Gosu, Harbour, Haskell, ISLISP, Java, Julia, Kotlin, LabVIEW, Mathematica, Objective-C (exceptions), OCaml (exceptions), OpenLisp, PHP, Python, Raku, Rebol, Rexx (with optional signal on... trap handling), Ruby, Rust (unless result explicitly ignored), Scala, Smalltalk, Standard ML , Swift ≥ 2.0 (exceptions), Tcl, Visual Basic, Visual Basic (.NET), Visual Prolog, Wolfram Language, Xojo, XPath/XQuery (exceptions), and Zeek.

No Failsafe I/O: AutoHotkey (global ErrorLevel must be explicitly checked), C, COBOL, Eiffel (it actually depends on the library and it is not defined by the language), GLBasic (will generally cause program to crash), RPG, Lua (some functions do not warn or throw exceptions), and Perl.

Some I/O checking is built in C++ (STL iostreams throw on failure but C APIs like stdio or POSIX do not) and Object Pascal, in Bash it is optional.

Expressiveness

The literature on programming languages contains an abundance of informal claims about their relative expressive power, but there is no framework for formalizing such statements nor for deriving interesting consequences. This table provides two measures of expressiveness from two different sources. An additional measure of expressiveness, in GZip bytes, can be found on the Computer Language Benchmarks Game.

Benchmarks

Benchmarks are designed to mimic a particular type of workload on a component or system. The computer programs used for compiling some of the benchmark data in this section may not have been fully optimized, and the relevance of the data is disputed. The most accurate benchmarks are those that are customized to your particular situation. Other people's benchmark data may have some value to others, but proper interpretation brings many challenges. The Computer Language Benchmarks Game site warns against over-generalizing from benchmark data, but contains a large number of micro-benchmarks of reader-contributed code snippets, with an interface that generates various charts and tables comparing specific programming languages and types of tests.

Timeline of specific language comparisons

• 1974 – Comparative Notes on Algol 68 and PL/I – S. H. Valentine – November 1974
• 1976 – Evaluation of ALGOL 68, JOVIAL J3B, Pascal, Simula 67, and TACPOL Versus TINMAN – Requirements for a Common High Order Programming Language.
• 1977 – A comparison of PASCAL and ALGOL 68 – Andrew S. Tanenbaum – June 1977.
• 1993 – Five Little Languages and How They Grew – BLISS, Pascal, ALGOL 68, BCPL & C – Dennis M. Ritchie – April 1993.
• 2009 – On Go – oh, go on – How well will Google's Go stand up against Brand X programming language? – David Given – November 2009