Lady Subroutine
The roots of Open Systems were born with the first electronic general-purpose computer called ENIAC. In year 1947 Kathleen “Kay” McNulty Mauchly Antonelli discovered something super important while she was programming ENIAC. She just used very human capability of abstraction to solve a nasty problem with a simple, now obvious and practical solution.
Humans are good in dealing with abstract concepts in their languages. They discover and package new things such like stories, phenomenon, principles, creatures, etc and then give them a name. Car, for example.
A car is an abstract, but usually a tangible thing. We are able to recognize even quite different cars. Let’s borrow and apply the definition of car by Wikipedia:
Wheeled motor vehicle used for transportation. They run primarily on roads, seat one to eight people, have four tires, and mainly transport people rather than goods.
You don’t have to know everything about the cars to talk about cars. It is enough to understand the concept of car at high level. There will be always people who are more dedicated by their passion to know more about the cars.
Without human capability to discover, encapsulate and name things, we should explain the thing from the roots each time. Having a single word to represent the whole idea, talking became very easy. I think they were Marx brothers, but also Monty Python made jokes about inability to conceptualize things with one word only. The life would be really complicated.
A computer program is basically a single chain of actions between the begin and the end. This way a computer is programmed to do what is expected.
In comparison, planning a car drive in a city from place A to B gives us multiple route options to be used. The road crossings are designed to ensure smooth traffic flow from city design perspective. The signs show what is allowed and what is not. Despite of many road options, the driver chooses the most suitable one to serve the need. The same applies with the computer programs. There are multiple crossings and condition checks along the way from the begin to the end. This determines one path to be driven by the computer. Data given to computer fine tunes the decision making for path in details.
While the previous diagram from begin to end was shown from ground level perspective, the next illustration shows the route from bird perspective from the begin (A) to the end (B).
Closer look in a city shows that the road crossings are quite similar to each others. The same pattern repeat may times in a city. For example: Go straight; No turn left or no turn right.
The same applies to computer programs. The design patterns repeats itself many times in a program code. The patterns X and Y were marked in the following program code to consider this situation with ground level view.
Back then the ENIAC programming personnel didn’t always know what the project was about using the computer. Their task was to prepare, configure and do some of the programming. Sometimes less sometimes more. The master programmer, as customer, completed the entire program for execution, so they knew what the program was used for. The personnel only helped to test and debug the program. The majority of program was the craftsmanship of the ENIAC personnel.
Kathleen Antonelli discovered the repeating pattern as a problem and a solution at the same time:
“Oh, I know, I know, I know, We can use a master programmer to repeat code.”
Kathleen discovered the concept of subroutine. The program is split at the repeating patterns X’s and Y’s. Both pattern type of codes are taken away from the program, harmonized to fit together and placed in a separate program; in a subroutine. The remaining (main) program became shorter and easier to manage. Also the independent subroutines are easy to manage.
The locations where the code was removed, now become a use points of subroutines, the users of subroutine. Code in subroutine is written only once, but used many times. If there was an error in subroutine the error correction is automatically applied for every use cases. One correction solves as many problems as there are use for the same pattern. A super handy solution!
Hence, as a side production they discovered the famous principle of modularity in programming. A clear cut between subroutines and the main program. Another nice finding was a recursive subroutine loop.
Master programmer could now implement the main program from the begin to the end by herself, while the programmer personnel could prepare the computer with configuration and subroutines beforehand.
Looking once more in the code path that computer runs with the code from begin to end.
The red line shows the path the computer walks through while executing the program, including the main program and the subroutines.
At first, it might look overly complicated using subroutines. No worries. This is really piece of cake for both human and machine. Computers love to execute the path shown to them. No sweat. For human the modularity makes programming a lot easier. Also software architecting became part of problem solving benefiting the modularity. Code becomes more easy to manage. Both subroutines in the example are executed three times, which means that code space has 2/3 savings compared to the original single program code model.
Kathleen Antonelli made a huge breakthrough with her idea of subroutine. Later on the subroutine was enhanced by other handy ideas, such as the concept of stack. However, without the breakthrough there wouldn’t be need for stack either. We are happily using her discovery still more than 70 years later.
(Edit: Sidenote: There must have been some kind of stack since the beginning to tell ENIAC from where to continue the execution in the main program after a subroutine is complete. Also to tell where to continue in a subroutine in case the subroutine called another subroutine in chain. Information exchange was perhaps via global variables in very beginning. However, this all is a natural problem solving development after the breakthrough idea. Many times the first answer generates more questions to be answered before the solution becomes mature.)
Application Programming Interface, API, is one of the consequences we have used after since. The latest movement API Economy in this century benefits from the idea of splitting a monolith code in smaller easily manageable pieces. API is a form of subroutine, running in the Internet 24/7.
Ladies, welcome back to coding.
We need you! Coding is fun and pulls everyone in a fantastic world of limitless imagination. You know this better.
The writer is the founder of APITIE with the mission to help organizations to capitalize the API economy capabilities to improve their businesses.
