Software Development

I have read the paper in its entirety. I understood everything in it and found it rather dry. I'll go through a few sections just to give a feeling of how this paper reads.

2.2.2 Applicative models.
Examples: Church's lambda calculus, Curry's system of combinators, pure Lisp, functional programming systems described in this paper. Foundations: concise and useful. History sensitivity: no storage, not history sensitive. Semantics: reduction semantics, no states. Program clarity: programs can be clear and conceptually useful.

2.2.3 Von Neumann models. Examples: von Neumann computers, conventional programming languages. Foundations: complex, bulky, not useful. History sensitivity: have storage, are history sensitive. Semantics: state transition with complex states. Program clarity: programs can be moderately clear, are not very useful conceptually.

The paper gets quite repetitive in this respect. Von Neumann bad! Functional GOOD! It goes on in caveman style narrative until we reach the section where quite unnecessary complex equations are found. These are somehow deemed simpler than von Neumann styled languages. The abrupt transition into hieroglyphs that only serve to confuse is rather curious considering the extensive sections devoted to how simple pure functional programming is supposed to be.

The repetition makes one wonder why this was necessary. Did Backup not feel that the work could speak for itself? I suppose that at the time, Backus may not have been subjected to infomercials, but I am sure that he would have found a home quite easily in this area.

Never was there any reasoning as to why von Neumann models are bad and why functional (or what Backus calls applicative) models are good. He says they are. But I found nothing convincing other than his insistence that the bus between data and the CPU is a bottleneck. This is what he calls the word-at-a-time bottleneck.

Von Neumann machines have a data store where the CPU can modify this data one item at a time. With functional programming, you have functions and reductions. There is never any named data or external entity that can be modified. There are apparently no states (more on this later).

The absence of full scale, effective programming styles founded on non-von Neumann principles has deprived designers of an intellectual foundation for new computer architectures.

On and on, it goes like this. Even the attempts at giving a reason are just rehashes of the same tired unfounded assumptions.

I agree that the von Neumann model is perhaps not the best. I have used many of Backus' contributions and am grateful for them. I was really optimistic as I started to read this paper. I wanted to agree with him and I would have let some items slide if there was some attempt at minimal logic or reasoning behind the arguments. I so longed to have one of the greats teach me something new or just appreciate the knowledge that was handed down at the time. But no. This paper is nothing more than an infomercial.

But the complacent acceptance most of us give to these enormous, weak languages has puzzled and disturbed me for a long time.

Baseless accusations and insulting those who use imperative and OO languages all in one sentence. Not bad. Looks like I can learn something after all. This statement also says that he does not understand why people use imperative (and OO) languages. So there's something Backus doesn't get. It should be noted that instead of looking at why these people use these languages, he decided that there was nothing to learn here. I could say the exact same comment about anything. Doesn't mean I'm right. So I find the above comment rather strange considering the circumstances. Though I'm not sure how this paper was created. Was it picked after the awards? Or was it written afterwards? In any case, such written language should not find itself in any respectable published paper no matter who wrote it.

The funniest thing is after reading this paper and how simple he claimed the functional model was, I longed for the for loop presented at the top of the paper:

c := 0
for i := 1 step 1 until n do
  c := c + a[i] * b[i]

Call me crazy, but that's as simple as it gets. Apparently, I'm wrong. Makes me wonder where FORTRAN came from in the first place if Backus had these opinions.

All right. That about sums up the paper. But there's more under the surface. It shows a basic lack of understanding of computers by most researchers. I've been searching for a long time why programming languages were so low level. I think this paper demonstrates more about this stagnation than anything else.

First, there is a serious lack of understanding as to what a function is. These researchers seem to be proponents of mathematical constructs, yet they fail completely when attempting to apply these principles to computers. This isn't targeted at Backus, but to all computer researchers who deal in programming languages. They just don't get it.

In many papers, including this one, they confuse the properties of a function. These papers all trip over themselves as they try to make a point that is impossible to make. Backus himself erroneously states that the substitution operation yields near unlimited power. The confusion lies in the fact that they think that a function can both produce an output and at the same time be reduced or substituted. I understand what they mean, but they don't see a distinction between how a function acts and the more generic consequences of producing an output.

A function seems to take an input and produce an output. It looks that way, but it's not entirely true. It has very definitive restrictions. Let's say I had an 'entity' that took an input and produced an output. For example, a post office. I deliver a letter to the post office (as input) and the post office stamps it (processing) and sends it elsewhere as its output. See how this differs from a function. A function REQUIRES that the output be sent back to the provider of the input. But in general, something that takes an input and produces an output has no such requirement as can be seen with the post office example. Do you understand that? Backus and others do not. Researchers do not understand this. Math only works with the return to sender requirement. That is NOT enough.

Returning to the sender is a critical property of reduction. It's also what makes possible inlining of functions. The arguments and return values are 'sockets' or 'terminals' to be linked in to another function. Placeholders if you will. But both the arguments and return values must be present (and linked) within the same calling or containing function. As such, it uses a restrictive form of input and output. One where it almost should not be called input and output at all because you cannot send the output to a different location than where the input came from. A function is nothing more than a group of operations that can be reused. Hey, great. You can reuse. But pretending that functions are not restrictive forms of input/ouput processing is very dangerous and why all these papers all fail and trip over themselves.

In computers, imperative programming is able to take inputs from the data store. A device can place data there (such as HD via DMA). Then your software (triggered directly or indirectly by interrupts) can take that data and transfer it to something else such as your video or audio card. This imperative software has input and output. But it doesn't send its output to the same device that produced the input. It can if it wants to and if the device supports it. But herein lies the flexibility. That's where imperative programming has a nice balance. It is internally restricted via function calls to return to the sender, but via state, it can escape this restriction. The functional model has no such balance. A functional model, by itself, cannot exist. A substitution model, when applied to its fullest, will end up with a single entity. Without interaction, it may as well not exist.

Object Oriented programming suffers from the same problems. If you ask an object to do something, there's no reason that function couldn't just be inlined inside the caller. If many objects call the same object (even with different functions), the local data binds all these calling objects together. It gets messy because we no longer have a clean model of input/processing/output. We have many return to sender functions using the same object data. The point of storage was to provide the input/processing/output model where the input and output were not the same entity. But if this data is locked into an object, the purpose seems rather moot. You could use it to transfer data from one called function to another later called function. However, the nature of a single CPU renders this a dubious strategy as well.

Both functional and OO have never understood what a function actually is. More so, it has never respected the properties of a function and what purpose storage is supposed to play in software.

We need both reductions and input/output processing where the output need not be sent to the provider of the input. BOTH! Functional has only reductions. And OO, well, it just warped the intention of storage. Merging the two would not help though. There's still denial about what the execution point is doing.

Returning to an earlier topic, functional programs do have state. I don't care how many times I hear someone say it doesn't, it's just not true. Functional programming is where state is always coupled to execution (or its equivalent reduction model). But this does not mean that there is no state. What they mean is there is no uncoupled state. The only way you can uncouple this state is by applying its associated function otherwise known as a reduction. This is how you change state.

Math is fine, but it's only one side of the equation. The other side is interaction. This is why most functional languages are not pure. So they can push the functional paradigm all they want, but these languages will never be pure. They can't be. I have yet to see a single paper that understands this duality between modularity and interaction. Without it, all papers fail.

The reason people use imperative and OO languages should be clear. Even if OO is a little warped, these languages provide a mechanism to unbind itself from the return to sender paradigm when it makes sense to do so. Imperative languages still have the best balance. Data flow would be optimal if there was an available framework that didn't require the execution point.

Also, interaction isn't between TWO entities, but THREE different entities! One entity produces the input, another processes it, and a final one takes that output. In this way, you can connect and produce networks of infinite size and complexity. With today's notion of programming, which hasn't changed in 50 years, we can't even attempt to get there. So there are plenty of unnecessary difficulties that make our software less than optimal right from the start. We cannot talk about improving software until we understand the properties of our tools and accept them at face value.

Recent papers offer no better analysis of the true properties of a software model. I hope that future papers can improve and correct the work of the past. Improvement is at the heart of all work, whether in computers or any other field. I am saddened that there is much political influence in the computing field. I am further saddened that there are still some that do not understand that math is only half the equation and that this pursuit will doom us all. However, I am hopeful that progress will be made. I am confident that we will turn a new page in computing very soon. Not by the researchers, but by the users. By the very people who get things done and whose only motivations are to fulfill this goal.