A great essay. I suggest Out of the Tarpit as a later exploration (20 years after No Silver Bullet) with fantastic and challenging analysis. If reading the whole paper is too daunting, checkout the summary (and subscribe to his regular email summaries of interesting papers) at: https://blog.acolyer.org/2015/03/20/out-of-the-tar-pit/
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.
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.
> 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.
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.
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.
>Following Brooks we distinguish accidental from essential diculty, but disagree with his premise that most complexity remaining in contemporary systems is essential
