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

[jcranberry]

The actual quote.

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

[pron]

It very much is a silver bullet claim (following Brooks's definition). But here's the quote I was referring to, in context:

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