Physical Reasons Why Languages Fail – 5

Conditional Statements

Our single-threaded consciousness also struggles to correctly handle conditional statements in a program. To successfully process that “simple” IF statement, we have to correctly write the code that handles both the true and the false outcomes of that IF statement. And since we can’t think about and write both the true and false responses simultaneously, we have to time-slice our attention between on case and the other.

Typically, we’ll start by writing the code to handle one condition and do nothing if the other condition exists (IF {some special condition} exists THEN {perform some special procedure} ).

And then during testing we find that the other condition needs to receive special processing (IF {some special condition} exists THEN {perform some special procedure} ELSE {perform some different special procedure} ).

And before we know it, we find other special conditions (or combinations of conditions) that need to be handled and end up with a bunch of nested conditionals with each branch requiring special processing to get the right results in all situations.

Unfortunately, we have to focus all of our attention on one branch at a time because of the way our brains work. We can’t code the sequence of actions in two or three branches simultaneously. Instead, we have to mentally switch the spotlight back and forth between the various branches to try to get them all to work together, just like we did when we were switching perspectives. For more … Programming Languages Are Not Our Friends

Unit testing programs encourage testing every branch of every conditional statement to ensure that the right outcomes are achieved. Unit testing can be extremely effective but until this tool or similar tools are used 100%, we are limited by the single-threadedness of our own minds.

Code Complexity

Counting the number of lines of code in a program is one way of estimating the “difficultness” or complexity of that program. TJ McCabe, back in 1976, suggested an alternative measure of code complexity would be the number of conditional statements in the code (“A Complexity Measure”. IEEE Transactions on Software Engineering: 308–320). McCabe developed a method of estimating the complexity of a program, referred to as its Cyclomatic Complexity.

And things don’t seem to be getting any better, despite the passage of time and the “improvements” in programming languages. In 2008, Les Hatton stated as part of his keynote speech (Keynote at TAIC-PART 2008, Windsor, UK, Sept 2008) that McCabe Cyclomatic Complexity has the same prediction ability as lines of code.

I find it astounding that despite the rise and eventual fall of BASIC, Pascal, Ada, Modula, c, c++, Java, and all of the less popular languages, we’re really no better at managing the complexity of our programs than we were almost 40 years ago. In other words, the languages that have come and gone (or still remain) don’t address the limitations that our single-threaded consciousness impose upon us. And until we provide a system that intentionally compensates for our physical limitations, we shall probably not get any better at developing computer programs.

Leave a Reply

Your email address will not be published. Required fields are marked *