In this chapter, the author takes us back in time to when Dijkstra started working as programmer.

Dijsktra was studying both theoretical physics and computer programming, but was fascinated by programming and decided to pursue it as his career.

He wanted to apply mathematical proofs to programming. His vision was that programmers would use structures proven by mathematical proofs and use code to tie these structures together, which would then prove themselves correct.

While trying to prove computer problems mathematically, he had to break them down into sub problems. During this work, he found that use of goto statement makes it hard to divide problems into small enough functions, thereby making them unsolvable using mathemetical proofs.

He also discovered certain control statements like sequence, if/then/else and do/while could be proven mathematically. He proved sequence using enumeration. Enumeration is a technique that traces inputs of sequence to output of sequence. He proved selection (if/then/else) by reapplication of enumerations. If the selected path gave the same result as expected path, then it proves the selected path correct. For induction, his logic was, if it works for one enumeration, and N enumerations then it would also work for N+1 enumeration. 

Modern structured programming’s principle to break large system into multiple modules which get further broken into functions and so on, is based on his work of breaking problem in to small provable units. He was not able to use mathematical proofs, instead we turned to science to get that provability.

Just like in science, we don’t try to prove a statement true, instead try to prove that statement false. If we cannot prove it false after enough experiments, we deem it provable for our purposes. Like this we break software system into small testable/falsifiable units which can be proven wrong individually and also collectively as a system. 

Today, we break a problem given to us into small functions, code those functions and then write test-cases to prove those functions wrong. 

For any feature we develop, our testers/Quality Assurance Engineers perform testing with all possible permutation/combination they can think of. If they don’t find any bugs, they give green light to release the feature. Even if they don’t find bugs, there is possibility that there are still bugs hidden in the system. For present, we just took a decision that it is good to go. 

Testing shows presence not absence of bugs.

Dijkstra

These falsifiable units makes structured programming important today. From big system to its smallest unit, everything is falsifiable. 

Thanks for stopping by! Hope this gives you a perspective on structured programming. Post comments to start a discussion.

Notes on previous chapters can be found here.

See you in the next post.