A recent exchange on the NZ2.0 mailing list involved a good few formal arguments, put forward by Mark Rickerby and Richard Clark.
Here's Mark, summarizing arguments Richard allegedly made earlier in the thread:
- All complacent developers are using PHP
- I am using PHP
- Therefore, I am complacent
- Apps built in Rails, Django, or Seaside are innovative
- Your app doesn't use Rails, Django, or Seaside
- Therefore, your app is not innovative
I believe the term for these is non sequitur...
The first is affirming the consequent, and the second is denying the antecedent. Both are fallacies, which makes them non sequitur simply from the fact that they're invalid (all logical fallacies are non sequitur if you take that meaning of the term). I learnt a different meaning for the term. Here's an example of a non sequitur as I learnt it:
- If Socrates is a man, then Socrates is mortal.
- The sun sets every day.
- Therefore, Socrates is mortal.
That is, I learnt that for an argument to be a non sequitur, one of the premises would be a non sequitur (in the ordinary sense of the word) - not following the line of deduction. Apparently that's a non-standard definition. I like it. Why not just call invalid arguments "invalid"?
In any case, Richard didn't like Mark's characterisation of his arguments. I think, reading back, Mark's critique was justified; Richard hadn't particularly given any reason to believe the converse (q -> p) or inverse (~p -> ~q) of the implications in question (PHP -> complacency, not-rails -> not-innovation). Here's his response:
The term for that is strawman. The correct set would be:[Argument 3]
- Rails, Django and Turbogears are innovative
- You have not tried Rails, Django or Turbogears
- Therefore you are complacent
- Rails, Django and Turbogears offer powerful features that let you innovate faster and better
- You haven't used Rails, Django and Turbogears
- Therefore you have fewer, less innovative features for the same amount of development time
First, I think it's great that Richard responded with formal arguments - with a concise statement of his position - rather than trying to bluster his way through Mark's critique. However, these later two arguments aren't very good at all.
In its current form, argument 3 doesn't work at all, because the conclusion doesn't follow from premises. It's non-deductive. So, we try to add a premise to make it deductive. The first premise talks about innovation, and the conclusion about complacency, so we have to somehow link the two. We could try adding something like:
If you're not using an innovative framework, you're complacent
But this isn't enough. The argument doesn't claim that Rails, Django and Turbogears are the only innovative frameworks - that'd be a materially false claim anyway. So, that means that the second premise (that you're not using one of those three frameworks), together with our new premise, still wouldn't imply that you're complacent: for, you might be using TurboDjarails, an extremely innovative framework. So, what we actually need is this premise:
If you're not using Rails, Django or Turbogears, then you're complacent
But, that sounds awfully like what the argument is trying to establish. It's technically modus ponens from that premise, with premise 2, to establish the conclusion. But it's become a pretty facile argument to make, because you have to get someone to accept this premise, without any reason for doing so.
Argument 4 is more straightforward. It's certainly valid. But too much so; I think it begs the question. For, I can think of no way in which you'd believe in the first premise without already being convinced of the truth of the conclusion. In fact, the first premise (especially if we elide 'innovate' to 'develop innovative features') is just the conclusion couched in different terms. So, the argument doesn't do any work.
And that's without considering the material truth of the first premise. Assuming "faster and better" is suffixed by "than PHP", the premise is still certainly false in some cases, probably false in many cases, and perhaps false in the majority of cases.