Imperative Programming: Lessons not learnt

We like to believe that Computer Science (or Information Technology) has advanced and keeps on advancing.

But has it?
What was called programming 60 years ago would today be called Imperative programming.  And it remains the mainstream (but see 7. below).

In short our field has a definite resistance to learning from our past.

A few examples will illustrate:

0. In the beginning…

Programs were just machine instructions.  Instructions were things that changed machine state.  And there was no limitation on this state-change.

A very early innovation arose from the realization that in many cases, restricting state change from the entire program to a smaller area would be very good for the programmer, even if it cost a few instructions more.  Brings us to Wilkes' creation of the…

1. The Subroutine

Followed quickly by a seemingly minor addition – the subroutine that returns a value or…

2. The Subfunction

While programming language practice stayed at these two pillars for a couple of decades, the wider problems in software engineering became apparent:

3. Cohesion and Coupling

Of which Cohesion is desirable and Coupling is undesirable.

The idea soon gained currency that

4. Global variables are bad

Though it remained in the softer area of praxis and not in technology. Until…

5. Modules, Classes, Objects

started appearing in programming languages; all of which share the property of allowing the programmer to create different limitations (or scopes as the techophiles call them) on the state-change in his programs

In short it is no exaggeration to say that many of the notable advances in programming languages have arisen from the realization that state-change needs to be limited or quite simply that

Imperative programming is a bad idea

And yet…

While in a few ivory-towers this was carried to its logical extreme:

6. Functional Programming

ie programming without any state-change,

for the most part programmers still continue blithely to use the imperative paradigm.

Now some programmers will take offense at this and say: Thats not true! Until the 80s, the mainstream used imperative programming. From the 90s this switched to

7. OOP

And isn't that a wonderful advance?

I believe it is not and is dealt with in bunch of other posts