Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Out of the Tar Pit (2006) [pdf]

curtclifton.net

Post reply on HN
Print view View original

61–68 of 68 posts

Re: Out of the Tar Pit (2006) [pdf]

#61

Post by dcre »

jameshart wrote: post #49
dcre wrote: post #5

This paper was very influential on me when I first started programming professionally around 2012. I don't plan on reading it again, but my vague memory of what I got out of it is pretty simple and I think has become pretty standard practice at this point: avoid mutable state and use pure functions where possible. The framing of accidental and essential complexity is of course very useful and not really unique to thi…

For anyone who is not aware, 'accidental and essential complexity' were coined in Fred Brooks' 1986 paper No Silver Bullet .

I was very curious about this claim and it seems that's not quite right. Of course the phrase "essential complexity" was applied to non-software topics before Brooks (Wikipedia correctly notes that the distinction between essence and accident goes back to Aristotle), but it seems Brooks was not the first to apply it to software either. I would not deny that he popularized it.

Book search results for "accidental complexity" between 1920 and 1985: https://www.google.com/search?q=%22accidental+complexity%22&...

Book search results for "essential complexity" between 1920 and 1985 (a lot more results): https://www.google.com/search?q=%22essential+complexity%22&l...

Here's a publication from 1981 defining "essential complexity" specifically with reference to computer programs. https://www.google.com/books/edition/Validation_Verification...

Note that there's another result that claims to be from 1968 but the text of the book says it's from 1996.

Interestingly "essential complexity" was used earlier and more often than "accidental complexity", probably because the former sufficiently implies the existence of the latter.

https://books.google.com/ngrams/graph?content=essential+comp...

Re: Out of the Tar Pit (2006) [pdf]

#63

Post by kragen »

deathanatos wrote: post #35
kccqzy wrote: post #26

Earlier quoted context omitted.

You are not getting the point of my comment or the original article. It's clear to me that the kind of complexity being talked about in the article is cognitive complexity not computational complexity. It's not about choosing between an O(n) copying of data and O(1) in-place mutation; it's about choosing code that's easy to comprehend and maintain.

Their point is that you can't choose the cognitively simpler choice because of real world design constraints, such as not consuming all available RAM — i.e., because of essential complexity.

that's complexity introduced by your approach to the solution (using an inadequately large computer) rather than essential to the problem you're trying to solve

Re: Out of the Tar Pit (2006) [pdf]

#64

Post by akkartik »

kragen wrote: post #63
deathanatos wrote: post #35

Earlier quoted context omitted.

Their point is that you can't choose the cognitively simpler choice because of real world design constraints, such as not consuming all available RAM — i.e., because of essential complexity.

that's complexity introduced by your approach to the solution (using an inadequately large computer) rather than essential to the problem you're trying to solve

I think the crux is which side gets to be called "essential". Is it the abstract problem the code is intended for, or is it the real world we're living in. Mike Acton argues for the latter (https://www.youtube.com/watch?v=rX0ItVEVjHc)

And all this is heat rather than light because there is absolutely a significant fraction of concerns that both sides would agree are utterly incidental/accidental complexity.

Re: Out of the Tar Pit (2006) [pdf]

#65

Post by kragen »

akkartik wrote: post #64
kragen wrote: post #63

Earlier quoted context omitted.

that's complexity introduced by your approach to the solution (using an inadequately large computer) rather than essential to the problem you're trying to solve

I think the crux is which side gets to be called "essential". Is it the abstract problem the code is intended for, or is it the real world we're living in. Mike Acton argues for the latter ( https://www.youtube.com/watch?v=rX0ItVEVjHc ) And all this is heat rather than light because there is absolutely a significant fraction of concerns that both sides would agree are utterly incidental/accidental complexity.

i think that's a purely semantic or terminological debate, so it isn't important which part we declare 'essential' and which part we declare 'accidental', and arguments that one definition or the other is better are pointless

what is important is that we understand which definitions people were using in particular utterances, that our definitions have adequate ontological coherence (avoiding "eargrayish" reasoning errors), and that other people can understand which definitions we are using

in brooks's 01986 paper he clearly considers questions like copying 2 gigabytes of data 'accidental' http://worrydream.com/refs/Brooks-NoSilverBullet.pdf

> All software construction involves essential tasks, the fashioning of the complex conceptual structures that compose the abstract software entity, and accidental tasks, the representation of these abstract entities in programming languages and the mapping of these onto machine languages within space and speed constraints. Most of the big past gains in software productivity have come from removing artificial barriers that have made the accidental tasks inordinately hard, such as severe hardware constraints, awkward programming languages, lack of machine time. ... The essence of a software entity is a construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocations of functions. This essence is abstract, in that the conceptual construct is the same under many different representations. It is nonetheless highly precise and richly detailed. ...

so it isn't important what mike acton thinks the terms should mean unless we're trying to understand how he uses them; brooks, moseley, and marks lump space and speed constraints into the category of 'accidental' rather than 'essential', and their arguments need to be interpreted using the definitions they intended to use, not conflicting definitions invented by a youtuber decades later

similarly, people commenting on moseley and marks's paper should be assumed to be using the same definitions as moseley and marks, not conflicting definitions, unless they explicitly state otherwise

Re: Out of the Tar Pit (2006) [pdf]

#66

Post by akkartik »

kragen wrote: post #65
akkartik wrote: post #64

Earlier quoted context omitted.

I think the crux is which side gets to be called "essential". Is it the abstract problem the code is intended for, or is it the real world we're living in. Mike Acton argues for the latter ( https://www.youtube.com/watch?v=rX0ItVEVjHc ) And all this is heat rather than light because there is absolutely a significant fraction of concerns that both sides would agree are utterly incidental/accidental complexity.

i think that's a purely semantic or terminological debate, so it isn't important which part we declare 'essential' and which part we declare 'accidental', and arguments that one definition or the other is better are pointless what is important is that we understand which definitions people were using in particular utterances, that our definitions have adequate ontological coherence (avoiding "eargrayish" reasoning er…

Totally fair. Sorry, I'm walking in halfway to this conversation with a different axe to grind.

Re: Out of the Tar Pit (2006) [pdf]

#67

Post by kragen »

akkartik wrote: post #66
kragen wrote: post #65

Earlier quoted context omitted.

i think that's a purely semantic or terminological debate, so it isn't important which part we declare 'essential' and which part we declare 'accidental', and arguments that one definition or the other is better are pointless what is important is that we understand which definitions people were using in particular utterances, that our definitions have adequate ontological coherence (avoiding "eargrayish" reasoning er…

Totally fair. Sorry, I'm walking in halfway to this conversation with a different axe to grind.

there's an interesting aspect to recursive decomposition there; an 'essential problem' at one level of abstraction may merely be an accident introduced one level higher up

like, lots of programs are specified to do one or another thing with the filesystem, and have to include extra complexity to do it, but the filesystem is something we introduced and could do without; it doesn't exist in objective reality outside the computer. is that complexity accidental or essential? at the level of the program it's essential (especially if the program is something like find(1) or cp(1), whose job can't be defined at all without presupposing a filesystem) but at the level of the system it's accidental

Re: Out of the Tar Pit (2006) [pdf]

#68

Post by akkartik »

kragen wrote: post #67
akkartik wrote: post #66

Earlier quoted context omitted.

Totally fair. Sorry, I'm walking in halfway to this conversation with a different axe to grind.

there's an interesting aspect to recursive decomposition there; an 'essential problem' at one level of abstraction may merely be an accident introduced one level higher up like, lots of programs are specified to do one or another thing with the filesystem, and have to include extra complexity to do it, but the filesystem is something we introduced and could do without; it doesn't exist in objective reality outside th…

100%

Division of labor: making accidental complexity essential since 1945.

Then again, perhaps we need to account for opportunity cost. Even if persistent storage can take many forms, it's hard to imagine that equivalent features could be 10x simpler. Maybe Chuck Moore would disagree, but his modus is usually to insist you don't need something.. (also totally fair)

Post reply on HN