TM-type machines are the correct technology for performing arithmetic calculations, or logic operations on static and unchanging inputs, as Alan Turing theorized. TM-type machines are the wrong technology for complex systems having changing inputs. Discrete, static, frame-based controllers are inappropriate for controlling dynamic systems.

There can be no silver bullet for software as it is. In twenty more years, software will still be done similarly and have the same problems it has had from the beginning. There may be higher-level languages, and we have some now, but underneath it all—as the necessary and sufficient operations, the three primitive operators that can construct all the computers in existence—it is the same old triad: AND, NOT, and STORE.

The fundamental problems and limitations of software engineering thus lie within the discipline and are caused by the simplistic logic it attempts to manage. All of Boolean-sequential logic rests upon the two spatial relations of conjunction (AND) and negation (NOT), and one command, STORE. Three essential words. Software becomes overly complex because the words we use to compose it are too simple. It would be very difficult to write anything of significance using only three words. Having done so at great expense, it would be very difficult to understand, fix, or maintain. That is the situation.

These tools are data centric; the user is describing the flow of data instead of a linear sequence of instructions. The problem is that there is always some limit to the application that can be described in terms of pre-defined data flows. Most of these tools acknowledge this by building in some kind of custom action/script/external function capability. Since businesses don’t typically spend money on building functionality they don’t need the minute business A needs to access data from business B the domain specific modeling tool has to be extended with custom action.

Even if everyone has exposed their data with some common description format, say SOAP or what have you, what happens when I want to transform that data in ways not already built into the modeler?

SQL runs into this problem. It is wonderful for a wide range of operations but for some operations procedural statements are necessary. Some of the more convoluted sets are much more easily described procedurally than declaratively.

To make matters worse the more general a modeler becomes the steeper the learning curve. Eventually the modeler becomes as difficult to use, or more so, as any decent GPL.

Yes, never say never. Without going too far, see the Scott’s article:
“Anything You Can Do, I Can Do Meta”
http://www.technologyreview.com/Infotech/18047/

Well, Simonyi does not whine the old “impossible” song, even perhaps he is your guy leaving the party, but, as the article puts, he “has no target date or shipping deadline”.

Although you are mainly concerned with the software problems in SDI, there are other more serious ones. See http://www.commondreams.org/views/051100-101.htm

The larger problem is…we probably won’t survive much longer unless we figure out a way to get competent people into public office.

What was curious though is that these were active members. You occasionally got the new member who wanted to cause a fuss just for kicks. But the longest lived flame wars were by long time members. It’s also been said that talking directly works well because it takes away the audience, but as soon as they go back to the forum they revert back to the old behaviour in these flame wars. I’ve heard plenty of excuses like this by people researching social software and I know it’s not the audience. Not for long time members. They already have an audience.

Look at my conversation above with Dave C. We aren’t even talking about the same thing anymore. How did it get to this point? His last reply has nothing to do with what I was talking about. This has happened in the last three of his replies. Is Dave C. stupid? Why can he not understand simple stuff? How can I get through to him? Did he not see I already answered those questions? Why am I frustrated? Of course Dave C. is none of those things and the blame or problems have nothing to do with him. I get the very same questions and replies on my own blog and I have a completely different reaction there. So what gives?

Forums and conversations that are not meant to have a million replies are not conducive to discussions. They are conducive to presentation of ideas. And maybe a few reactions to those ideas. But that’s it. Most conversations need small, incremental exchanges of information in order for both sides to get a frame of reference. If just one point is missed or misunderstood on a forum (or blog message), you can’t correct it because the floor is to the one writing the reply. So the discussion gets steered in a direction that may seem ridiculous. The frustration comes because there’s no corrective behaviour possible in these kinds of discussion. We are helpless to fix them because the communication channel is severely limited. We have our hands tied behind our backs or driving blind when we reply. Even on the artist site I spoke of, ALL 100% of problems were solved on IM. All of them. None could ever be solved on the forum itself because it always got worse. We didn’t know why at the time, but we knew that IM enabled faster resolutions.

Why the long story? Well, the SASDS papers is a long list of frustrations. It’s a classic example of how flame wars start. Except in this case, there’s not really any other side. But all the classic signs are there. There’s clear frustration. There’s clear blaming. There’s no cohesiveness in the presentation of what the problem is. Everything is tossed out there seemingly at random and lumped together. On top of that, he’s getting the silent treatment. FYI, the other side is actually the machine(s) he’s trying to write software for.

Remember how frustrating those old “syntax errors” were? Those are caused by lack of communication channels. At university, I’ve seen my share of people curse at the monitor. I’ve even seen people damage property because of this. Today, we’re getting “systax errors” of a higher intellectual level. We don’t actually get a syntax error, but the error is still there.

What if the problem isn’t one of software only, but more specifically one of communication? When you have a discussion, you need the other side to be able to understand what you’re saying. If you want more complex systems, you need to enable a more complex communication channel. One that support incremental and error correcting exchanges of information. One where you don’t need to provide the minute details of every compound operation or “word”.

No one expects a five year old to understand quantum physics because he doesn’t have the vocabulary for it. We’d have to go through each and every piece of background information and explain it. Good luck! Yet we try to do exactly the same thing with computers. We’re still using the basic 7 primitive commands needed to be Turing complete when we program computers.

It’s somewhat like the chicken and the egg. You need a complex communication channel to get a complex system, but you need a complex system to understand the complex communication channel. The thing is that we only need one of them. Each one can build the other (or it should unlike today). While everyone is saying that the system itself is impossible to build, I have my doubts on the communication channel. That’s where I’m focusing my attention. And I don’t mean programming languages. They’re all built on the same set of 7 “words” where functions are just paragraphs, not new words. That may be the worst realisation of all. We thought the vocabulary was expanding, when all this time it was staying the same. Unfortunately, the OOP mentality of the last 20 years has completely corrupted any hope of understanding this.

A system can only be as complex as the communication channel. Or at least some upper limit based on it. If you were to create a robot that could walk, talk and do tasks, would you still use loops, if/then/else and math to tell it what to do? Or would you like some kind of verbal recognition of certain common words? Computers today are incredibly powerful, but they are dirt stupid. We have to tell it everything. If we continue this trend of trying to fit watermellons through a water hose, we’re looking pretty stupid ourselves. Frustration and no silver bullet indeed.

Discussing these topics is not the same as reinventing the wheel, imo.

Uhh… Maybe so we don’t reinvent the wheel, no?

What are we talking discussing? For me, I’m interested in looking at the papers posted with the hope and aim to glean more insight into developing software. Why were these papers written? What was the situation at that time? Have things changed? What have we learned?

I understand you believe a silver bullet is possible. But I’m not interested in discussing that in every post.