A call for a programming manifesto
The term "programming" is dangerously beleaguered.
A recent article entitled 'A Future Without Programming' (IDG News Service, Nov. 20, 2008)
starts as follows:
"Do-it-yourself applications development is on the rise as business users increasingly
turn to codeless programming tools to create applications."
It is unfortunately more the rule than the exception that authors call this
"without programming" presumably because it does not involve the use of
Java, C#, Ruby or such. As if "codeless programming tools" did not involve
the formal (graphical or textual or otherwise) executable specification of processes!
I have noticed that some authors use the term
"design" even though what they are talking about has nothing to do
with planning and rendering that plan (which is
what 'design' means). [1] I suspect they use 'design' because it
sounds sexier than 'programming' -- worst of all, I have seen 'design'
used instead of 'coding'.
Think of this message as a call to arms to save the term 'programming'
from being usurped by distractive, muddled, pompous terms such as
'model-driven architecture', 'design' and others, whether the people
behind them do it for image reasons ("design" has to do with models
walking down catwalks, "programming" with unshaved nerds imbibing Coca
Cola), pompousness ('model-driven architecture' -- isn't the archetype
of that the von Neumann architecture?) or the -- unfortunately ignorant --
belief that 'programming' is whatever happens to be 'programming practice'
at some given point in time. The latter is like believing that the 'The
Wild West' is the same as 'St. Louis, Missouri', just because it was around St. Louis
in the early-1800s. Programming
is neither Assembly language, Pascal, or Java programming, however,
but it moves through these terroritories as it moves on and leaves
civilization [2] behind it.
The importance of rescuing and clarifying what 'programming' is should
not be underestimated, especially in a world where a core competency
of computer scientists is termed 'programming': Many people might
misunderstand this as "coding in X1, X2, and X3", where Xi are fixed
bindings to particular programming languages. Which is like saying
The Wild West is still in St. Louis in the late 1800s, and calling
what is going on in Montana 'model-driven architecture', and in
Wyoming it is 'design'...
Fritz
[1] Caveat emptor: Given the well-known notoriety of scientists to
come up with clever explanations, let me counterargue that a coded
program is a (rendered) design. True, it represents a 'plan', and the
plan can then subsequently be executed -- by the the (abstract)
machine. It is not a plan for the programming (software development)
job, however, and there already is a term for something that
represents a fully-specified plan ready for execution: program.
[2] To be understood without value judgement, at least in the case of
The Wild West.
- hengleins blog
- log ind eller opret konto for at skrive kommentarer
'systematic problem solving' ?
One of my core competences is the art of misunderstanding even then simplest
of things. So, it shouldn't be surprising that I'm not sure I understood your
message (BTW it didn't help that I had to look up words like 'beleaguered' and
'usurped' just to be sure...).
But from what I understand you're attacking people that describe programming
tasks using sexier words like 'design', and 'architecture'. You want the word
'programming' to be used more often.
IMHO programming is simply the act of systematically describing the solution to
some problem. So, 'programming' has nothing to do with _how_ you express the
solution (i.e. choice of programming language) -- it doesn't even have to
involve a computer. But these days the word 'programming' is very tied up to the
computer. So, perhaps you shouldn't attempt to save the word 'programming'.
Perhaps it would be better to simply call it something like 'systematic problem
solving' (okay, it should be describable using only one word, so this description
needs some work...) ?
Søren
P.S. you also posted this message to the 'stipendiat' mailing list, but in that
message you used parentheses to denote footnotes, but in your blog you used
square brackets. Why?
Programming
I referred to 'programming' in the context of 'computing'. These days the term 'programming' seems to be getting its meaning from the contexts in which it is used instead of having a broadly accepted intrinsic meaning. This makes for a certain semantic dynamics -- it can change a term's meaning over time, just by being used sufficiently often in a different way -- but that is outright dangerous for a discipline like computer science with a stipulated core competency of 'programming'. The reason is that, in contrast to, say, twenty years ago, computer scientists constitute a small fragment of all the people working professionally with computing -- including, you know, 'programming'. Semantics-by-use terms are controlled by whatever majority may feel self-empowered to use a term. In other words, non-computer-scientists nowadays determine what a self-declared core competency of a computer scientist is. The danger lies in not being in agreement on what that is.
The article I referred to implicitly uses 'programming' in the sense of 'text-based coding in one of the general-purpose Turing-complete system and application programming languages du-jour, such as C++, Java or Ruby'.
My point was that programming consists of (a) the specification of a process (something that is dynamic) and its requirements (its raison d'etre) together with (b) the formalized rendering of that specification ("code") and supporting argument for the process actually satisfying the requirements (testing, validation, verification). The du-jour part is a transient: assembly, Fortran/Cobol, Pascal/C, Ada/C++, Java/C#, report generation languages, languages with graphical 'syntax' (the rules for drawing boxes and connecting them with arrows are also 'syntax'), etc.
What I wanted to say was that 'applications without programming' in the quoted IDG News article was nonsensical: The application is programmed in higher-level, probabably domain-oriented language, most likely one with a graphical syntax, not a text-based one. It is still programming, even though neither Java or C# or Ruby or such stare the 'user' (programmer!) in the face.
My concern is that you are pushing the term in the other direction, namely of being so general as to be without concrete meaning, when you propose 'systematic problem solving' -- aren't all people doing that some of the time? So are all people programming when they do that?Generating lines of code in itself is not 'programming', it is just 'coding'.
I believe the term 'systematic problem solving' is not sufficient for capturing
programming either, however:
It does not necessarily imply a process description (describing a general process, not just a single, specific execution of such, with a mathematically precise semantics) and it misses the formalization (rendering as "code") part of programming: The key point is that code is data, and data can be subjected to
other programming -- and to mathematical analysis. The coding part is also a key difference to the notion of 'algorithm': algorithms are not 'data'. They are more like design patterns. So 'algorithms' is not programming, either.
The importance of formalization (coding -- representing as bits or other abstract data types, if you wish) is illustrated by the fact that the big break-through in the mathematicians' struggle in the 19th Century to define what an 'algorithm' was and what not -- numerical algorithms were very important in mathematics in the 19th Century -- came from the logicians. (The early 20th Century was doubtlessly a hard time for mathematicians' self-esteem and their previously widely held disinterest in Boole and Frege and the seemingly weird and useless stuff they had done). Logicians and mathematicians with a weakness for logic formalized the informal notion of algorithm in particular formalisms such as Turing Machines, recursion equations, Markov models, lambda-calculus, which each turned the set of algorithms into a domain subject to mathematical analysis! In particular they showed, mathematically, all of the formalizations to be equivalent; thus the notion
of algorithm was now defined "up to equivalence"! Indeed, one might say programming was born...
I think of Polya's "How to solve it" as a training for doing 'systematic problem solving', but I don't think of it as a book teaching 'how to program'. Mind you,
anybody can do 'coding' without prerequisites, but programming presupposes systematic problem solving. The latter is what I expect others to have of me as a computer scientist, but I am afraid it is the former many people inside and outside of 'information technology' connect with 'programming'
-- and you really don't need to be at a university for any nontrivial length of time to master that. Programming, however, takes years...
Fritz
PS: I needed a notation for footnotes. I used parentheses first. Brackets indicate citations (not just remarks), but this isn't a technical report, so I eventually used them in the dikutal post.
Some not-so-common words may have snuck in. Sorry about that. They simply seemed to be the most precise for what I wanted to say. But, paraphrasing Blaise Pascal's apology ("If I had have more time this letter would have been shorter, of course."): If I had had more time, I would have made this post more readable, of course.