The Problem with Programming
May 11, 2012
[DRAFT] THE PROBLEM WITH PROGRAMMING
Programming is the art of tying thought to syllogism. The programmer must take an often nebulous idea and encode it into a symbolic logical language. By it’s very nature then, there is gap that must be breached between the thoughts of the programmer (harder still the thoughts of his client) and the construction of their autonomic model. This then is the problem of programming: finding ways to shrink that gap.
At it’s root a program is a series of logical ones and zeros, arranged just-so to create what can best be analogized to the non-programmer as the falling of dominoes.
…
It should be clear that to span the divide we must build systems that allow us to most readily convey our ideas about a “thing” and interconnect them in dynamic relationships. For instance, if I were to speak of a “ball”, a whole range of things would occur to the average person. Most everyone has had many experiences with a thing called “ball”. They would certainly know that they often bounce, though some can be quite hard; they come in all sizes, but they are almost always spherical. These facts might seem trivial to you and I, but to a computer, they are as far from us as quasars.
If we ever hope to be able to instruct computers in a fashion akin to our speech, and expect that the system will naturally arrange the ideas of which we speak, then we are going to have to start with encoding the nature of things we know. We do this presently with knowledge on the human level, via dictionaries, encyclopedia and the like. But we are speaking of computers and to convey things to a computer they must be extensively deconstructed.
ball:
definition:
source: Websters
number: 1
description: a round or roundish body or mass
shape:
terms: [round, sphere]
volume: 4/3*PI*r^3
surface: 4*PI*r^2
types: ['bowling', 'football', 'soccer', 'baseball']
Our ball is very simplistic and far from complete at this point, but the nascent idea is conveyed. Yet to actually do anything with these constructs, it will be important to provide functional information in addition to the descriptive. We get a hint of this already with the surface and volume definitions given. More complex functions could be provided, such as physical formulae for bouncing.
I do not believe we must be overly concerned about the exact hierarchical structure nor use of terms these constructs take. A general pattern will arise that developers will adopt as conventions. Such system of conventions tends to be reliable enough for such matters.
Now, taking this notion a step further, let us propose a universally available resource for creating and editing these semantic constructions. From which, they could be utilized as a general resource by all developers.