Computer Programming Languages -- Recapitulation

By Herbert J. Bernstein

## Introduction

### Algorithms and programming languages

Those who work with computers have changed the earlier meanings of many words. Until recently, an "algorithm" was a specific step-by-step method of numeric calculation, e.g. a way to compute the product of two numbers, or their quotient, or the square root of a number, etc. A "program" was a plan of action, again usually step-by-step, but usually intended to connote something more general than a specific algorithm. (See the O.E.D.) In the world of computers, an algorithm is a plan of action for solving a problem, while a a program is a specific set of instructions for a computer to carry out the algorithm.

Programs, as they are actually stored and executed in most computers, are lists of numbers, sometimes expressed as decimal numbers, but more often as binary, octal, or hexadecimal numbers. This is very inconvenient to work with. In order to simplify the process of writing programs, various tools (which are, as might be expected, themselves programs) have been designed:

• Assemblers Assemblers allow symbolic names to be used instead of numeric machine instructions and instead of numeric machine addresses for data.
• Macro Assemblers Macro assemblers allow groups of instructions to be given names, i.e. to be made into macro-instructions.
• Compilers and Interpreters Compilers and Interpreters allow statements more oriented to the problem domain than to the structure of computers to be used to specify a program. A compiler takes large groups of statements and converts them to machine code for subsequent execution, while an interpreter translates one statement at a time and executes it immediately.

Most programming languages today are specified by rigorous syntax definitions, defining the statements of the languages in terms of simpler constructs, much as a English language sentence might be defined in terms of nouns, verbs, subjects, predicates, etc.

## Overview of Languages

There many more languages for use with computers than any person, project or organization might need. In the earlier days of computing, programming languages were created because they were needed. Fortran made computers accessible to scientists who were not prepared to deal with the intricacies of machine language programming. COBOL did the same for business programmers. Arguably, many recent languages have not been creating to meet any pressing need, but to satisfy the intellectual curiosity of their creators. If one wants a Ph.D. in computer science, writing a new language can be an effective route to the degree. Some of these "language of the month" creations will introduce new ideas which will be adopted by the community, and a few will survive and prosper, but most are, at best, of academic interest. Only time will tell which are which.

As of this writing, the languages of most interest for those who will have an interest in the mainstream of computer science are:

TypeMeaningExamples
procedural (Imperative) von Neumann model instructions executed in sequence Fortran, Cobol, C
logic (production) rule-based, non-procedural BNF, Prolog
functional (applicative) based on mappings, non-procedural Lisp, Scheme, ML, Haskell
object-oriented support for encapsulation, classes, objects Simula, Smalltalk, C++, Java
pattern-matching combine parsing rules with procedural execution Snobol, Awk, Perl

In most cases, languages of any of these types include features and libraries to solve problems of all types, but time can be saved by using a language which expresses the class of problems at hand cleanly and efficiently.

## Issues in Translating Languages

A compiler translates major blocks of statements (source code) for subsequent execution (object code). An interpreter translates small portions of code for immediate execution.

There are two computational contexts to consider:

 translation context the context within which the language is translated. execution context the context within which the translated statements are executed.

Each context may be a physical machine or a virtual machine created in software, and these contexts need not be the same. A common practice is the make the language or a subset of the language define the translation context, so that the translator is written in terms of the language itself. This requires manual compilation for the first system, and cross-compilation to move from system to system.

Compilation may be to so-called intermediate languages, i.e. languages which define virtual machines, such a stack-oriented machine or a simple one-address machine with an accumulator.

A virtual execution environment may be created by threaded code in which virtual instructions are created by sequences of indices into a vector of procedure entry pointers.

## Issues for Object-Oriented Languages

• Abstract data types
• Encapsulation, abstraction, information hiding
• Abstraction in SIMULA 67, Ada, Modula-2, C++, Java
• Object-oriented programming
• Classes, objects, inheritance, polymorphism
• Smalltalk
• Object-orientation in C++, Java, Ada, Eiffel

## Other issues

• Parallelism
• Multiprocessing and multiprogramming
• Communication, synchronization, semaphores
• Exception handling, interrupts, stacks
• Language implications, C, C++, Ada, Java, Fortran, PL/I
• GUI languages
• Functional programming
• Avoiding side-effects
• Functions, lambda notation
• Logic programming
• Meaning and differences from procedural languages
• Predicate calculus
• Theorem proving
• Declarative semantics
• Prolog
• Terms, variables, instantiation
• Facts, rules , goals
• Reasoning strategies, backtracking and cuts

Last Updated on 13 September 2003
By Herbert J. Bernstein
Email: yaya@bernstein-plus-sons.com