It tries to build a theory in an Aristotelian manner, i.e. not based on careful observation but mostly on rationalization (and maybe very partial, biased observations). The problem with rationalizations is that they can often be made to support any claim when the empirical picture isn't clear. An additional problem in this particular case is that when No Silver Bullet was published, the same kind of people (PL enthusiasts) made roughly the same arguments, but their predictions proved wrong, whereas Brooks's proved right. It's not the end of the story, but it does mean that their theory needs, at the very least, to be revised.
The tarpit paper is also not a prediction or forecast the way that the No Silver Bullet paper is. It reparameterizes and expands upon essential and accidental tasks and proposes a development framework to minimize accidental tasks.
The company I currently work for uses a code generation framework inspired by the ideas from the tarpit paper. It's very successful in simplifying and speeding up the development process.
It is an empirical claim, one that at least has not been refuted by observation.
> Otherwise they'd be incidental.
I don't understand this. It's an empirical claim about software in the wild.
> It reparameterizes and expands upon essential and accidental tasks and proposes a development framework to minimize accidental tasks.
... and yet, no one has found a silver bullet yet (as per Brooks's definition), nor anything close to it.
There are no sources or pieces of evidence cited in the section on what the essential tasks are. If it's an empirical claim, then the any claim made in the tarpit paper is certainly equally empirical.
> ... and yet, no one has found a silver bullet yet (as per Brooks's definition), nor anything close to it.
There was no such claim.
Then what does it have to do with No Silver Bullet? Brooks's point isn't that you can't make languages that some people may find more attractive, but that you can't drastically reduce complexity.
> There are no sources or pieces of evidence cited in the section on what the essential tasks are.
Right, that's why it's a claim. But it comes with an empirical prediction that was later verified by observation.
> If it's an empirical claim, then the any claim made in the tarpit paper is certainly equally empirical.
Of course it is, but if we take it as a silver-bullet claim (i.e. the ability to drastically cut down complexity), then it just doesn't fit with observation.
Not to mention what observations are you talking about? Because I'm not too aware of any tarpit inspired languages/development frameworks, let alone an actual FRP framework.
The paper's response to Brooks's central assumption, which leads to his prediction is, and I quote the full sentence, "We disagree."
It is an interesting opinion piece but it is entirely "Aristotelian".
> Because I'm not too aware of any tarpit inspired languages/development frameworks, let alone an actual FRP framework.
Different languages and frameworks have adopted different parts, usually the more practical ones. None proved to be a silver bullet.
>Following Brooks we distinguish accidental from essential diculty, but disagree with his premise that most complexity remaining in contemporary systems is essential
There's no silver bullet claim.
> Brooks asserts ... that the majority... of the complexity that we find in contemporary large systems is of the essential type. We disagree.
That means a silver bullet is possible (against Brooks's claim), and then they go on to describe what they think is a particular silver bullet.