Herein to describe my thoughts on programming language paradigms.

There are two important behaviours of an algorithm - memory use and time use.

Memory use may occur as:

  • Intermediate results in the calculation of expressions. In (a+b)+(c+d), no names for the results of a+b and c+d occur in the source code, but these are still calculated and stored pending further processing.
  • On a function call stack, with storage for the parameters of each calling of a function

Important behaviours of programming languages and language families are:

  • Ease at rewriting code to express similar but different ideas
  • Ease at deducing the behaviour of a block of code

A preliminary remark follows. A procedural program with no side effects other than calculating a value is trivially also a functional program, where its variable state at time t+1 is a function of the same at time t.

To illustrate one advantage of functional over imperative languages, consider the following psuedo-)code:
a := c + 2
d := f + e
m := c + 3

The statements may be executed in any order. Now consider:
a := c + 2
d := f + a
m := c + 3

Here line 2 depends on the value of a set in line 1. So lines 1 and 2 cannot be swapped round.

These two segments however look very similar. So one must stop and reconsider the definitions of variables after every line if the program is to be proven correct, which is time-consuming.

Here is another example:

declare output-file as File // the output file

Both the comment and the variable name here are partially misleading. They are inaccurate descriptions for the variable before it has been set up to have the information about the output file.

Algorithm design

Data structures represent abstract knowledge structures, and are manipulated by algorithms. Manipulation of the data correspond to transformations of the abstract structures. The various transformations which are needed, and how common they are, should be taken into account in deciding what data structures to use, and how much redundancy to have. For example, you could represent the position of a chess board as (a) a 8x8 grid of pieces or free spaces, or (b) as a list of pieces with their locations. Both imply the other, and both will be more useful in performing certain tasks. Structure (a) would be better for displaying the chess board on the screen. Structure (b) would be better for calculating a score (pawn = 1, knight = 3 etc.) for what pieces a player has left on the board.


There are certain choices to be made in the design of a program. It can be useful to make a point of explicitly considering these choices rather than going along with the first idea.

  • Generality vs. Extensibility - Modularity, extensibility, generality, whatever you want to call it, are not a completely good thing. In fact, the most general program is a text editor with a compiler, or maybe raw materials to build your own computer with. Extensibility makes the system more complicated. See object-orientated programming - you don't have to have the capacity to extend data structures and to call functions operating thereon through a vtable for every single data structure you use. When writing a video game, be careful that you don't start writing a video game development system instead. Often you don't need full generality - you can limit the numbers of game objects, for example.
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-NoDerivs 3.0 License