In real arguments, people often dispute and eventually come to an agreement about the definitions of their terms, for the sake of a good, logical argument.
Argumentation-Map systems, AFAIK, still do not support this feature. Arguments have to be stated using the final version of the defined terms. Revising these can be a boring, repetitive process. (highlighting old usage would be a nice feature)
(apply Lakatos)
But definitions are only one thing that can change in a reasoning process. People also change their beliefs, intuitions, and the structure of the argument they believe justifies their contention.
The process of refining and manipulating such formal structures is analogous to what happens in software development.
The conventional wisdom in software development is to plan ahead: specify before you implement, imagine what the finished code looks like before you spend hours trying to implement it. Sometimes, the simple logic of specifications will reveal misconceptions in the programmer's idea, and sometimes one's imagination / intuition can work as a "theorem prover" of sorts, although the proof may not be consciously accessible. (maybe this is one way in which people are essentially different from computers: proof-based mathematics discovery systems only believe what they can prove (i.e. barring experience-based conjecture generators), whereas people can end up "seeing" something to be true through an unconscious process of intuition (which nevertheless might follow a logic and correspond to a formal proof)
Sometimes, however, the only way to know whether an implementation will work is to implement it. This is especially the case when the complexity of the problem makes it difficult to predict how the implementation will behave.
Argumentation-Map systems, AFAIK, still do not support this feature. Arguments have to be stated using the final version of the defined terms. Revising these can be a boring, repetitive process. (highlighting old usage would be a nice feature)
(apply Lakatos)
But definitions are only one thing that can change in a reasoning process. People also change their beliefs, intuitions, and the structure of the argument they believe justifies their contention.
The process of refining and manipulating such formal structures is analogous to what happens in software development.
The conventional wisdom in software development is to plan ahead: specify before you implement, imagine what the finished code looks like before you spend hours trying to implement it. Sometimes, the simple logic of specifications will reveal misconceptions in the programmer's idea, and sometimes one's imagination / intuition can work as a "theorem prover" of sorts, although the proof may not be consciously accessible. (maybe this is one way in which people are essentially different from computers: proof-based mathematics discovery systems only believe what they can prove (i.e. barring experience-based conjecture generators), whereas people can end up "seeing" something to be true through an unconscious process of intuition (which nevertheless might follow a logic and correspond to a formal proof)
Sometimes, however, the only way to know whether an implementation will work is to implement it. This is especially the case when the complexity of the problem makes it difficult to predict how the implementation will behave.