[pron]

The Tarpit paper, if taken as a response to Brooks, suffers from a similar problem to the one I discussed here: https://news.ycombinator.com/item?id=20829129

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.

[jcranberry]

Brooks suppositions on essential tasks are not empirical at all. Otherwise they'd be incidental. And that's what the tarpit paper focuses on.

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.

[pron]

> Brooks suppositions on essential tasks are not empirical at all.

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.

[jcranberry]

> It is an empirical claim, one that at least has not been refuted by observation.

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.

[pron]

> 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.

[jcranberry]

I'm beginning to get skeptical whether you've actually read the paper. It is not making a silver bullet claim or denying the forecast originally present in No Silver Bullet. If so, it would be asserting some way to significantly reduce or completely remove essential complexity. It instead attempts to find a minimal definition of essential complexity, and proposes a method to mitigate the cost of non-essential complexity. It is supplementary to No Silver Bullet, not a refutation of it.

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.

[pron]

> It is not making a silver bullet claim or denying the forecast originally present in No Silver Bullet.

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.