First, my own observation agrees with GreenRoot. My view is less systematic but much longer, I’ve been watching this area since the 70s. (Perhaps longer, I was fascinated in my teens by Leibnitz’s injunction “Let us calculate”.)
Empirically I think several decades of experiment have established that no obvious or simple approach will work. Unless someone has a major new idea we should not pursue straightforward graphical representations.
On the other hand we do have a domain where machine usable representation of thought has been successful, and where in fact that representation has evolved fairly rapidly. That domain is “programming” in a broad sense.
Graphical representations of programs have been tried too, and all such attempts have been failures. (I was a project manager for such an attempt in the 80s.) The basic problem is that a program is naturally a high-dimensional object, and when mapped down into a two dimensional picture it is about as comprehensible as a bowl of spagetti.
The really interesting aspect of programming for representing arguments isn’t the mainstream “get it done” perspective, but the background work that has been done on tools for analyzing, transforming, optimizing, etc. code. These tools all depend on extracting and maintaining the semantics of the code through a lot of non-trivial changes. Furthermore over time the representations they use have evolved from imperative, time-bound ones toward declarative ones that describe relationships in a timeless way.
At the same time programming languages have evolved to move more of the “mechanical” semantics into runtimes or implicit operations during compile time, such as type inference. This turns out to be essential to keep down the clutter in the code, and to maintain global consistency.
The effect is that programming languages are moving closer to formal symbolic calculi, and program transformations are moving closer to automated proof checking (while automated proof checking is evolving to take advantage of some of these same ideas).
In my opinion, all of that is necessary for any kind of machine support of the semantics of rational discussion. But it is not sufficient. The problem is that our discussion allows, and realistically has to allow a wide range of vagueness, while existing programming semantics are never nearly vague enough. In our arguments we have to refer to only partially specified, or in some cases nearly unspecified “things”, and then refine our specification of those things over time as necessary. (An extremely limited but useful form of this is already supported in advanced programming languages as “lazy”, potentially infinite data structures. These are vague only about how many terms of a sequence will be calculated—as many as you ask for, plus possibly more.)
For example look at the first sentence of my paragraph above. What does “all of that” refer to? You know enough from context to understand my point. But if we actually ended up pursuing this as a project, by the time we could build anything that works we’d have an extremely complex understanding of the previous relevant work, and how to tie back to it. In the process we would have looked at a lot of stuff that initially seemed relevant (i.e.currently included in “all of that”) but that after due consideration we found we needed to exclude. If we had to specify “all of that” in advance (even in terms of sharp criteria for inclusion) we’d never get anywhere.
So any representation of arguments has to allow vagueness in all respects, and also allow the vagueness to be challenged and elaborated as necessary. The representation has to allow multiple versions of the argument, so different approaches can be explored. It has to allow different (partial) successes to be merged, resolving any inconsistencies by some combination of manual and machine labor. (We have pretty good tools for versioning and merging in programming, to the extent the material being manipulated has machine-checkable semantics.)
The tools for handling vagueness are coming along (in linguistic theory and statistical modeling) but they are not yet at the engineering cookbook level. However if an effort to build semantic argumentation tools on a programming technology base got started now, the two trajectories would probably intersect in a fairly useful way a few years out.
The implications of all of this for AI would be interesting to discuss, but perhaps belong in another context.
From professional experience (I’ve been a programmer since the 80′s and was paid for it from the 90′s onward) I agree with you entirely re. graphical representation. That doesn’t keep generation after generation of tool vendors crowing that thanks to their new insight, programming will finally be made easy thanks to “visual this, that or the other”. UML being the latest such to have a significant impact.
You have me pondering what we might gain from whipping up a Domain-Specific Language (say, in a DSL-friendly base language such as Ruby) to represent arguments in. It couldn’t be too hard to bake some basics of Bayesian inference into that.
PyMC is a DSL in python for (non-recursive) Bayesian models and Bayesian probability computations. I have been thinking of trying to make an ad-hoc collaborative scenario projection tool with PyMC and ikiwiki. Users would edit Literate Python (e.g. PyLit or Ly) wiki pages that defined PyMC model modules, and ikiwiki triggers would maintain Monte Carlo sampling computations and update results pages. But it won’t be enough for real argument mapping without decision theory (and possibly some other things).
I wish I could be optimistic about some DSL approach. The history of AI has a lot of examples of people creating little domain languages. The problem is the lack of ability to handle vagueness. The domain languages work OK on some toy problems and then break down when the researcher tries to extend them to problems of realistic complexity.
On the other hand there are AI systems that work. The best examples I know about are at Stanford—controlling cars, helicopters, etc. In those cases the researchers are confronting realistic domains that are largely out of their control. They are using statistical modeling techniques to handle the ill-defined aspects of the domain.
Notably in both the cars and the helicopters, a lot of the domain definition is done implicitly, by learning from expert humans (drivers or stunt pilots). The resulting representation of domain models is explicit but messy. However it is subject to investigation, refinement, etc. as needed to make it work well enough to handle the target domain.
Both of these examples use Bayesian semantics, but go well beyond cookbook Bayesian approaches, and use control theory, some fairly fancy model acquisition techniques, etc.
There is a lot of relevant tech out there if Less Wrong is really serious about its mission. I haven’t seen much attempt to pursue it yet.
I strongly support the notion of whipping up a DSL for argumention targeted at LessWrong readers. Philosophy and law argumentation tools seem to be targeting users without any math or logic who demand a graphical interface as the primary means of creating argument. My guess is that LessWrong readers would be more tolerant of Bayesian math and formal logic, the necessity of learning a little syntax, and only exporting a graphical representation.
Features might include:
Compose in ordinary ASCII or UTF-8
Compose primarily a running-text argument, indicating the formal structure with annotations
Export as a prettified document, still mostly running text (html and LaTeX)
Export as a diagram (automatically layed out, perhaps by graphviz)
Export as a bayes net (in possibly several bayes net formats)
Export as a machine-checkable proof (in possibly several formats)
I’m currently learning noweb, the literate programming tool by Norman Ramsey.
Graphical representations of programs have been tried too, and all such attempts have been failures. (I was a project manager for such an attempt in the 80s.) The basic problem is that a program is naturally a high-dimensional object, and when mapped down into a two dimensional picture it is about as comprehensible as a bowl of spagetti.
The problem has consitently appeard to me to be related to the use of incorrect abstractions. Most of the visual attempts I’ve seen have been roughly equivalent to printing binary code to screen as an attempt for a textual representation of a program. I’m still (very optimistically) waiting for a video-game which tackles this problem succesfully (some of the FF series ones have done an ok job).
It’s not terribly obvious but the little ‘Help’ link at the bottom of the comment box gives the most useful markup conventions. More complete documentation is here.
First, my own observation agrees with GreenRoot. My view is less systematic but much longer, I’ve been watching this area since the 70s. (Perhaps longer, I was fascinated in my teens by Leibnitz’s injunction “Let us calculate”.)
Empirically I think several decades of experiment have established that no obvious or simple approach will work. Unless someone has a major new idea we should not pursue straightforward graphical representations.
On the other hand we do have a domain where machine usable representation of thought has been successful, and where in fact that representation has evolved fairly rapidly. That domain is “programming” in a broad sense.
Graphical representations of programs have been tried too, and all such attempts have been failures. (I was a project manager for such an attempt in the 80s.) The basic problem is that a program is naturally a high-dimensional object, and when mapped down into a two dimensional picture it is about as comprehensible as a bowl of spagetti.
The really interesting aspect of programming for representing arguments isn’t the mainstream “get it done” perspective, but the background work that has been done on tools for analyzing, transforming, optimizing, etc. code. These tools all depend on extracting and maintaining the semantics of the code through a lot of non-trivial changes. Furthermore over time the representations they use have evolved from imperative, time-bound ones toward declarative ones that describe relationships in a timeless way.
At the same time programming languages have evolved to move more of the “mechanical” semantics into runtimes or implicit operations during compile time, such as type inference. This turns out to be essential to keep down the clutter in the code, and to maintain global consistency.
The effect is that programming languages are moving closer to formal symbolic calculi, and program transformations are moving closer to automated proof checking (while automated proof checking is evolving to take advantage of some of these same ideas).
In my opinion, all of that is necessary for any kind of machine support of the semantics of rational discussion. But it is not sufficient. The problem is that our discussion allows, and realistically has to allow a wide range of vagueness, while existing programming semantics are never nearly vague enough. In our arguments we have to refer to only partially specified, or in some cases nearly unspecified “things”, and then refine our specification of those things over time as necessary. (An extremely limited but useful form of this is already supported in advanced programming languages as “lazy”, potentially infinite data structures. These are vague only about how many terms of a sequence will be calculated—as many as you ask for, plus possibly more.)
For example look at the first sentence of my paragraph above. What does “all of that” refer to? You know enough from context to understand my point. But if we actually ended up pursuing this as a project, by the time we could build anything that works we’d have an extremely complex understanding of the previous relevant work, and how to tie back to it. In the process we would have looked at a lot of stuff that initially seemed relevant (i.e.currently included in “all of that”) but that after due consideration we found we needed to exclude. If we had to specify “all of that” in advance (even in terms of sharp criteria for inclusion) we’d never get anywhere.
So any representation of arguments has to allow vagueness in all respects, and also allow the vagueness to be challenged and elaborated as necessary. The representation has to allow multiple versions of the argument, so different approaches can be explored. It has to allow different (partial) successes to be merged, resolving any inconsistencies by some combination of manual and machine labor. (We have pretty good tools for versioning and merging in programming, to the extent the material being manipulated has machine-checkable semantics.)
The tools for handling vagueness are coming along (in linguistic theory and statistical modeling) but they are not yet at the engineering cookbook level. However if an effort to build semantic argumentation tools on a programming technology base got started now, the two trajectories would probably intersect in a fairly useful way a few years out.
The implications of all of this for AI would be interesting to discuss, but perhaps belong in another context.
Couldn’t help but think of Wikipedia as a kind of example of this “vagueness/resolution” problem.
From professional experience (I’ve been a programmer since the 80′s and was paid for it from the 90′s onward) I agree with you entirely re. graphical representation. That doesn’t keep generation after generation of tool vendors crowing that thanks to their new insight, programming will finally be made easy thanks to “visual this, that or the other”. UML being the latest such to have a significant impact.
You have me pondering what we might gain from whipping up a Domain-Specific Language (say, in a DSL-friendly base language such as Ruby) to represent arguments in. It couldn’t be too hard to bake some basics of Bayesian inference into that.
PyMC is a DSL in python for (non-recursive) Bayesian models and Bayesian probability computations. I have been thinking of trying to make an ad-hoc collaborative scenario projection tool with PyMC and ikiwiki. Users would edit Literate Python (e.g. PyLit or Ly) wiki pages that defined PyMC model modules, and ikiwiki triggers would maintain Monte Carlo sampling computations and update results pages. But it won’t be enough for real argument mapping without decision theory (and possibly some other things).
I wish I could be optimistic about some DSL approach. The history of AI has a lot of examples of people creating little domain languages. The problem is the lack of ability to handle vagueness. The domain languages work OK on some toy problems and then break down when the researcher tries to extend them to problems of realistic complexity.
On the other hand there are AI systems that work. The best examples I know about are at Stanford—controlling cars, helicopters, etc. In those cases the researchers are confronting realistic domains that are largely out of their control. They are using statistical modeling techniques to handle the ill-defined aspects of the domain.
Notably in both the cars and the helicopters, a lot of the domain definition is done implicitly, by learning from expert humans (drivers or stunt pilots). The resulting representation of domain models is explicit but messy. However it is subject to investigation, refinement, etc. as needed to make it work well enough to handle the target domain.
Both of these examples use Bayesian semantics, but go well beyond cookbook Bayesian approaches, and use control theory, some fairly fancy model acquisition techniques, etc.
There is a lot of relevant tech out there if Less Wrong is really serious about its mission. I haven’t seen much attempt to pursue it yet.
I strongly support the notion of whipping up a DSL for argumention targeted at LessWrong readers. Philosophy and law argumentation tools seem to be targeting users without any math or logic who demand a graphical interface as the primary means of creating argument. My guess is that LessWrong readers would be more tolerant of Bayesian math and formal logic, the necessity of learning a little syntax, and only exporting a graphical representation.
Features might include:
Compose in ordinary ASCII or UTF-8
Compose primarily a running-text argument, indicating the formal structure with annotations
Export as a prettified document, still mostly running text (html and LaTeX)
Export as a diagram (automatically layed out, perhaps by graphviz)
Export as a bayes net (in possibly several bayes net formats)
Export as a machine-checkable proof (in possibly several formats)
I’m currently learning noweb, the literate programming tool by Norman Ramsey.
Well visual programing of visual things, is good. but thats just WYSIWYG.
The problem has consitently appeard to me to be related to the use of incorrect abstractions. Most of the visual attempts I’ve seen have been roughly equivalent to printing binary code to screen as an attempt for a textual representation of a program. I’m still (very optimistically) waiting for a video-game which tackles this problem succesfully (some of the FF series ones have done an ok job).
You can use *italics* for italics and **bold** for bold.
Good comment btw, from experience I’m very much in agreement about the futility of visual programming.
Yes, sorry, fixed. I couldn’t find any description of the markup conventions and there’s no preview button (but thankfully an edit button).
It’s not terribly obvious but the little ‘Help’ link at the bottom of the comment box gives the most useful markup conventions. More complete documentation is here.