Programming Fundamentals Part 1: What Is A Program?
This article series is based on rough drafts of what I intend to eventually turn into a series of lectures and course ware for my brogrammers and siscripters out there. Feedback is welcome, and if it proves useful, I would be happy to list you as a contributor.
1. What Is A Program? — A set of instructions to be executed by an Information Processing System
2. The Problem Domain — How to design a program/application
3. Storing Information — How to Model Information (data) in an Information Processing System.
4. Logic And Errors — The two (primary) types of logic in an Information Processing System; how to handle errors properly
5. Separation Of Concerns — The most important Software Architecture principle I have ever come across
6. Proving Programs With Tests — An explanation of the theory, practice, and benefits of testing your software, and applying Test Driven Development
What Is A Program (Literally)?
A program is in essence, a set of instructions to be given to an Information Processing System (or IPS for short). Before we define what a program is further, I would like to spend some time discussing Information Processing Systems (such as computers) in order to be specific about the kind of programs we’ll be writing in this course. We will begin by looking at each term in the name “Information Processing System” in isolation, as they point to descriptions, requirements, and limitations of modern programs as well as the machines which interpret them.
Of the three terms, information is admittedly the most general, and therefore the most difficult to define in a concrete way. Take, for example, the following pieces of information, which are conveyed to you, via the English language, Arabic numerals, and the mathematical “+” operator:
(x) — “Assuming Base 10 Arithmetic, 1 + 1 is equal to 2”
(y) — “The Earth Orbits the Sun”
From the above examples, it is my assessment that information typically possesses the following qualities:
Firstly, information, at least for the purposes of this course, must have some relationship to observations of physical reality, such as y, or must have a relationship to abstractions which are derived from physical reality such as x. For brevity’s sake, I will simply use the term reality from here on.
In order to understand the previous definition, we must discuss abstractions and the way in which they are used by minds to model and deduce information about reality. Abstractions are used by animals and machines alike, to represent information (facts, details, circumstances) and patterns which are present in reality (admitting that our abstractions may be false, inaccurate, or useless). They do not need to look the same aesthetically, but they can be verified to be true or false based on whether or not they appear consistent with a detailed and objective analysis of reality.
For example, I look down at my hands and notice that I have two of them (at least at this moment in time). By convention, I would represent the number of hands that I possess, as the Arabic numeral “2”. However, if an ancient Roman were to look down at his or her hands, they might by convention arrive at “I I ” as the appropriate abstraction to represent what is the same quantity. I must point out that my convention of using “2”, versus an ancient Roman using “I I ”, versus a computer using “10” (which is equivalent to 2 in binary; being a base 2 counting system), does not imply that my convention is superior, or more correct.
At this present moment in history (although I suspect this may change in under 50 years), humans are capable of representing information not just in letters and numerical symbols, but they can do so through two dimensional, three dimensional, auditory, kinesthetic, and other forms of abstractions. Computers, by contrast, is currently limited to representing information as collections of ON and OFF values (or 0 and 1), do not possess the same capacity.
Note: When we say ON and OFF or 0 and 1, the truth of this matter in modern computers, this is an abstraction of different ranges of voltages in digital circuits. As you can already imagine, it is easier to stick to talking about 0s and 1s then.
My intention in explaining these philosophical points is not to bore you, but to point out the limitations of the kind of programs we can create with modern computers. It is very trivial to write a computer program to add “1 + 1”, as this level of abstraction is well suited to a mind which stores information almost exclusively in 0s and 1s.
The challenge for us programmers then is to find ways to store, create, examine, and compute complex information in a way which is intelligible on some level to ourselves and the machines we use to perform these precise and often tedious operations. It follows that the programs we write in high-level languages are specifically designed for this purpose of finding mutual intelligibility between human and machine.
Processing implies that information stored in memory can be manipulated (changed, combined, inputted, outputted, and so forth) according to specific rules which can also be stored in the system. This is a much simpler point than the previous one and does not require further explanation.
Be it an animal or machine, an Information Processing System (at least one which is useful to us humans), appears to have a set of requirements necessary in order to function:
- Memory, in order to store information either temporarily, during run time (discussed later), or for the entire duration of the IPS’ existence
- Decision-making capacity, in order to solve problems based on what information and or events are currently relevant to solving the current problem
- Input and Output devices (or channels), to supply new information to the IPS, and to be able to see the results of processing this information
These fundamental parts of an IPS were best described in what is known as the Von Neumann Architecture (the above list of requirements I gave is a slight generalization of it), which is still used by most modern computers:
In any case, I chose the word “System”, as it is important not to think of computers as being singular entities, but rather that they are the result of several distinct parts sending and receiving information over time. We will revisit the benefits of treating programs in this manner as well, by applying separation of concerns in our own software architecture designs.
What is a Program (figuratively)?
In the previous section, I defined a “program” as being, “a set of instructions to be given to an Information Processing System.” While this definition, and its explanation, were intended to be precise in a philosophical and somewhat technical way, one does not need to understand it completely in order to write useful programs (at least if you are starting with “high level” languages such as Java).
In fact, although it is more correct to think of programs as collections of instructions to be translated in to machine code at run time, the beauty of object-oriented programming, is that we can benefit greatly by imagining these different collections of instructions (which are generally kept in separate files), as actors that come to life in virtual space, sending messages to each other, each time a key is pressed, value is computed, or a millisecond goes by.
From here on, I will do my best to explain programming in this more figurative way, as I have found it to be easier to understand than the dense, jargon-filled explanations which I was given as a beginner. I may still rely on some technical definitions (particularly in sections like this which are more theoretical in nature), but I will only introduce them when I feel it would be detrimental not to.
We will revisit this more lifelike perspective of programming in several of the following modules, but the first step in writing any program is to consider what information it will need to represent. This very information is what we refer to as the “Problem Domain.”
Follow the wiseAss Community:
Consider donating if you learned something: