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

51–60 of 68 posts

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

#51

Post by hcrisp »

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 .

Chapter 1 of The Mythical Man Month by the same author is called "The Tar Pit" and has this memorable opening paragraph:

> No scene from prehistory is quite so vivid as that of the mortal struggles of great beasts in the tar pits. In the mind's eye one sees dinosaurs, mammoths, and sabertoothed tigers struggling against the grip of the tar. The fiercer the struggle, the more entangling the tar, and no beast is so strong or so skillful but that he ultimately sinks.

> Large-system programming has over the past decade been such a tar pit, and many great and powerful beasts have thrashed violently in it...

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

#52

Post by lmm »

feoren wrote: post #36
dagss wrote: post #31

Earlier quoted context omitted.

I'm not arguing that event sourcing should be done for its own sake, so I don't really want to disagree with you; but that said your post doesn't perfectly resonate with me either. When you write a typical backend system, the desired function of the system is to interact with the external world. Without I/O the system may as well not exist. Input is a desire from someone that something be done or recording that somet…

> All input can be framed as being an event. Sure, it could be, but is it useful to do that? If I stand up and shout "The price of a Banana is $4 per bushel!", you could record my voice and upload it as a raw wave file. That's the rawest "input event" you can come up with. Or you could write down "some random dude said that bananas cost $4 around 4:30 pm and I'm not sure whether I believe him or not". That's not the…

> Sure, it could be, but is it useful to do that? If I stand up and shout "The price of a Banana is $4 per bushel!", you could record my voice and upload it as a raw wave file. That's the rawest "input event" you can come up with. Or you could write down "some random dude said that bananas cost $4 around 4:30 pm and I'm not sure whether I believe him or not". That's not the "raw input", it's been transcribed and modified and annotated. Yet it's almost certainly more useful to your system, and it's kinda like event sourcing. Kinda.

Huh? Obviously you (ideally) keep the raw wave file, and the transcribed and annotated version is a downstream transformation of that that you'd use for most purposes, but you can always go back to the original raw data if you need to (e.g. if your transcriber turned out to be unreliable). That's much of the point of event sourcing.

> The problem with worrying about whether something is "input" or "output" or "internal" is that you can just move the dotted line anywhere around your system to change those. If you break a monolith into independent reusable building blocks, those building blocks are going to have a completely different idea of what counts as input and output. But who cares? You're not changing any fundamental truth about how the domain works. Your domain model should really be independent of worrying about what's "input" and "output". Those lines move all the time.

Not my experience at all. You can move your internal lines around all you like, but the data flow of the domain will not change. You take A and B in from outside, and ultimately you use them to compute C and send that back to outside; that changes rarely if at all. And if D is your normalised form of B, you'll always compute that from B, and which component you do it in might change but the B -> D -> C flow won't.

> But surely that's not what you're storing in your system! That would be an extreme coupling between the concept of "selling shares" and "clicking a button". Those are completely unrelated ideas! Why would you want to tightly couple them!?

On the contrary, they're tightly coupled in the user's understanding (which is the model that ultimately matters), they should be tightly coupled in the domain model. The code should reflect the domain.

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

#53

Post by gatane »

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…

While programming in FORTH, you have a similar advice: avoid stack mumbling (aka copy and store ops).

But sometimes all that stack changes could be avoided by using a temp register.

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

#54

Post by eternityforest »

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…

My experience has shown almost all of it to be essential except the stuff that is very obvious "Programmers playing with stuff that seems cool".

Once you account for hardware errors, human errors, respecting the user's time, compatibility with different file formats, multiplatform support, and the limited resources developers have, etc, most programs seem like they couldn't be any simpler while still being something I want to use.

Or, they potentially could, but nobody would pay enough to justify the extra time it would take.

Which is why I don't complain that Etcher is 99MB. It's like conceptual art, Yes, you could do it smaller, but you didn't, and I don't want to because I can just use the existing thing and move on, and I wouldn't pay for a lighter version when the heavier thing is free.

I just don't see all that much disappointing software in the commerical space at least.

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

#55

Post by kilgnad »

kccqzy wrote: post #22
kilgnad wrote: post #12

Earlier quoted context omitted.

Lambda calculus machines can't exist in reality though. Only the von Neumann machine can be actualized. Thus from a practical perspective the foundations of actual computing must be built on mutable state. You are wrong about the generations idea. It's a side effect. Functions themselves cannot actually do anything with a generation number. It's completely useless other then for letting you know how many times a valu…

You are not getting the point of either my comment or the original article. You are thinking from an engineering point of view, where if you look through all the layers of abstraction you see mutexes and shared mutable memory. That's not my point; my point is about building up those abstractions so they are sufficiently hidden. Functional programmers routinely operate on a higher level of abstraction, and they have s…

I am getting it. I am simply saying that you can't completely hide those details. They leak through.

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

#56

Post by bitwize »

feoren wrote: post #7
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…

Plenty of state -- even mutable state -- is essential complexity. Think of an IDE where a user is typing out code: the state is changing all the time. Pure functional programming has a hard time walking the line between "avoiding" mutable state, and "ignoring" mutable state. If you insist on functional purity, you're already admitting defeat in the face of essential mutable state. The walls of functional (and especia…

Ah, but if you model the mutable state as a function taking prior state to new state (and no cheating and modeling it as World -> World), you can constrain and control it into something you can reason about. You're one step closer to taming the dragon of chaos, bucko!

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

#57

Post by raatuter »

enlyth wrote: post #16
kccqzy wrote: post #8

Earlier quoted context omitted.

There is no essential mutable state in computer science. All essential mutable state can be modeled away to use no mutable state, as you have shown in the generation number idea which is one valid way. (I'm strictly talking about computer science problems not computer engineering problems such as drivers.) The generation number idea you have shown is an excellent idea. It immediately enables several new capabilities…

> There is no essential mutable state in computer science. Yes, theoretically. Now imagine your mutable state is 2GB in size, have fun creating a copy of it on every change.

Immutable data structures are often implemented as persistant data structures, which have the traits of immutability but does not "copy everything on every change" https://en.wikipedia.org/wiki/Persistent_data_structure

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

#58

Post by cloogshicer »

bts wrote: post #46
cloogshicer wrote: post #44

I think the crux of this paper is section 7.2.2: > There is one final practical problem that we want to consider — even though we believe it is fairly rare in most application domains. In section 7.1.1 we argued that immutable, derived data would correspond to accidental state and could be omitted (because the logic of the system could always be used to derive the data on-demand). Whilst this is true, there are occas…

You should look into the "comonad" abstraction from the functional programming world. Dual to monads, they're a natural fit for situations where you might have a value with some sort of (possibly infinite) context (think: neighborhood, or history, etc.) that can be either pre-computed or computed on-demand. This StackOverflow post[1] is a good starting point for understanding comonads. It points out that they can be…

Thank you very much, I'll look into that!

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

#59

Post by vendiddy »

There are a lot of comments saying that we can't avoid mutable state and dismiss this paper entirely.

I find a practical interpretation of this paper is:

- Favor pure functions over impure functions

- Reduce mutable state and be deliberate about where those mutations have to happen

- Prefer derived state over keeping state in sync

There are always exceptions. Use your judgment on when this simplifies code and when it doesn't.

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

#60

Post by SilasX »

dagss wrote: post #29
mpweiher wrote: post #14

Earlier quoted context omitted.

> Plenty of state -- even mutable state -- is essential complexity. Arguably most of it! After all, computer don't compute. https://www.youtube.com/watch?v=EKWGGDXe5MA&t=297s One of the miseries of life is that everyone names everything a litte bit wrong, and so it makes everything a little harder to understand in the world than it would be if it were named differently. A computer does not primarily compute in the se…

Related: The Norwegian word for "computer" is "datamaskin". Or, "data machine".

And in the Romance languages, some variant of “ordinator”, meaning someone who orders, regulates, or arranges, closer to the tasks we actually expect of computers.
Post reply on HN