I have used and been involved with a number of incarnations of what we can call loosely, the "decision table" or "rules" metaphor.

This way of working has a lot of appeal, and it is extremely powerful. The main thing I find good about it is that the tables can usually be given over to subject-matter experts to maintain, which means systems programmers like me don't have to mess with any of that dreadful application stuff. Nice.

However, what the mind of man can conceive, the hand of man can screw up. I have seen big projects go down at the bow with all hands lost in industries where the decision to use decision tables could not have been more right - like the insurance industry. It should have been a no-brainer. But the classical problems of poor project management, poor design, overwhelming complexity, poor team leadership, lack of technical skills in the team etc. still conspired against us.

Look, my take on all of the projects I've seen where this is involved...? There is still no substitute for a single, over-arching, godlike human intelligence that can encompass all of this complexity and think beyond the patterns. Somebody who knows what they are doing must be in charge and must be allowed to lead. Decision tables are great, but they are just another tool in the arsenal of the professional software developer.

In the right hands, such a tool will make a good outcome great. But in the wrong hands, the added weight of yet another piece of poorly understood technology may be just enough to send the project to the bottom. If you are working with people who are over-awed with technology, who can't think even three consequences ahead, and who can't do much more than cut and paste code they scrounge off the web, you're already dead, and Decision Tables, or IDE's for that matter can't save you.

At the end of the day, software is an extension of mind. It can never be better than the mind that created it, though it can be far far worse. So if you want good software, hire the finest minds you can find, let them select their own tools, and allow them to do the job you pay them to do.

I've studied the ideas around Subtext for a while. It's worth reiterating(if the videos and papers don't make it clear enough) that Subtext is really focused on exploiting the benefits of decision tables by expanding upon them and adding the complete set of constructs in addition to logic.

Decision tables, by the way, _work_. If you haven't tried them, it will only take a brief perusal of Wikipedia to get the concept. Their benefit is that all logic is represented in a single table: if every entry in the table has been filled, all cases are covered. Much easier to read than linear code, much less prone to error.

You can write your own decision table by hand in a spreadsheet program. But above a certain level of complexity(the point where you really, really want correct logic the first time) a complete decision table becomes very time-consuming to write by hand. By design it will still give more correct results than just hacking away, but automated approaches become very appealing. Decision tables were researched for a while in the 60s and early 70s, but were abandoned presumably as the field moved on to more prestigious topics.

Subtext's so-called "schematic table" does much to add the necessary automation - the next step in making it production-worthy would be to port such a system to output code in existing languages.

An unhandled case is only one kind of bug. Needless to say, filling in all those entries in your spreadsheet says absolutely nothing about whether those decisions are correct.

Look, this is a gimmick. Not having used such a tool, I'm not going to say that it's worthless. But I will say that I'm very suspicious of anyone who looks to gimmicks as the Salvation of Modern Programming. I've seen it too many times.

Not having used such a tool, I'm not going to say that it's worth using. But my reddit-crippled attention span managed to sit through the 38-minute demo and actually find it interesting because it seems to match the way I THINK about a program. Programming, for me, is about translating a mental concept into a specific programming language - this looks a lot closer to directly capturing (drawing, really) my mental concept. I pretty much taught myself to program, but this is actually similar to how programming was taught to us in certain classes - using flowcharts and logic tables. It's supposed to be about the logic, not about the language. He drives that point home towards the end of the demo, where he shows three completely different representations of a program - nested if statements, switch statements, and classes with polymorphism - collapsing into the same representation.

That being said, I've always been wary of "visual" tools that promise the sky and the moon, and I think I would go nuts if I had to use the mouse like in the demo, but it definitely looks interesting.

Which do humans use more for communication and reasoning - words or visuals? Considering that we have developed elaborate languages but done relatively little in the way of visual non-word communication, I would deduce that words and symbols are generally a superior medium. The graphs just seemed a bit cluttered towards the end I think. Interesting though.

I do still have a fondness of flow-based programming, as is used in Kamaelia, twisted flow, or graphical VHDL environments though.

Subtext is really cool!

If throughout the video presentation you were wondering, like me, if it was mouse-only, the FAQ says:

"Subtext 2 has been designed to be much less mouse-centric than the prior version. Although not yet implemented, it should be possible to do everything from the keyboard."

That's the one. Thankx!

I worked on an IDE that only allow refactoring - the demos at least were nice, even if ultimately it didn't go anywhere!

http://dynamicaspects.org/domain-j/demo.asp