Programming languages may be good at implementing a computer program, but they are a lousy way to think about the intended program. Instead of thinking about what we want the program to do, we end up thinking about the features that are available in the selected programming language. And then we develop the program structure based on the features available in that language instead of what we want the program to do.
For example, if we want to build a program that will find the square root of the volume of Kim Kardashian’s butt (don’t ask why – just go with it), we first have to decide if we’re building a command line program or a GUI program. And that basic decision shapes our thinking about how we will build the program and the language that we use to implement the program. Very little of the code from a command line version of the program could be used in a GUI version of the program.
And then when we talk about how we are calculating that value, it is almost impossible to explain what we are doing without describing the code we are using to implement the calculations. What we are doing becomes all mixed up with how we are doing it. For example, if our chosen language includes a “calcButtCheekVolume” function then our code will be relatively simple; without that function, we have to calculate the volume ourselves based on butt cheek curvature and cheek width, etc, making it much harder to code. All because of one single function. It would tempt one to use an inappropriate or obsolete language just to gain access to that one function.
The Mac programming world has jumped onto the Model-View-Controller (MVC) paradigm, where the Model and the View do not directly interact but instead process all updates thru the Controller. This separation allows the programs to cleanly separate display requirements from implementation requirements, allowing developers to modify the back end processes without affecting the front end (display).
So back to Kim Kardashian’s butt, using MVC, we would find a way to Model the volume of a butt cheek and then add a way to display (View) the volume (graph, chart, photo-morphing, etc), and then the Controller code would make adjustments to the model, depending on if she is standing or sitting, gaining weight or losing weight, etc.
Unfortunately, we programmers are still functioning at a primitive level, where the program structure is still based on the language that was selected to implement the program. We have no way to deeply describe the functionality of a program without also including implementation details such as the language, the library, and how the user will interact with the program.
Programming languages need the equivalent of MVC so it would be possible to cleanly separate what we want a program to do from how we want it to do it and implement it. For example, the Model would be the data that the program uses and the View would be the user interface of the generated program, and the Controller would respond to changes in the Model or manipulate the Model as required, updating the View as required.
Developers would then be able to calculate the square root of the volume of Kim’s butt without worrying about which language (and library) was being used to implement the solution or how that solution would be displayed to the user (CLI vs GUI). Which means Fortran could be used to calculate the volume and c could be used to calculate the changes in the shape if she is jumping and Java could be used to calculate the shape if she is sitting, etc. The compiler(s) and MVC-like Programmer’s Interface would manage the code and generate the desired output of the eventual program without requiring language and structural concessions on the part of developers.
Blindly adopting the MVC model is not the answer because programming languages solve many problems beyond the MVC model. The point here is that our thinking about developing programming solutions has remained mired in a 1950’s mentality, where programs are developed in a single muddy interconnected language-feature-functionality-library lump, where changing any single component dramatically affects the implementation of the whole program.
We need to develop a programming vocabulary that can describe what a program will do that is independent of the programming language chosen if we are to ever hope to become more efficient and faster at developing computer programs. And if we can’t get better at developing relatively simple single-threaded solutions, we’ll have almost zero chance at getting better and faster at developing the comparatively more difficult parallel programs.