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

21–30 of 68 posts

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

#21

Post by cubefox »

kilgnad wrote: post #11
ergeysay wrote: post #9

Earlier quoted context omitted.

Not to mention that pure FP completely handwaves away implicit global state such as heap.

That's the point. This hand waving allows the user to build more complex systems. The cost is efficiency but make no mistake not thinking about the heap allows people to build much more complex programs. It's a trade off between complexity and efficiency.

Then could it reversely be argued that not worrying about the stack (tail recursion) allows people to build more complex programs? Probably depends on which is more worrisome on average, heap or stack.

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

#22

Post by kccqzy »

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

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 shorter, more maintainable code. In such code, it would be a code smell if you continue to use mutexes, because that should've been an implementation detail. It should've been clear from the outset that the kind of complexity the article is talking about is cognitive complexity.

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

#23

Post by dannyobrien »

cubefox wrote: post #20
feoren wrote: post #7

Earlier quoted context omitted.

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…

I always thought the problem with a "purely" functional view is much more practical: From my limited Haskell experience, I gather that you have to use recursion instead of loops, since loops (and GOTOs) work by iteratively modifying some state, unlike recursion. But humans think in loops. If you look in a cookbook for a recipe, it will almost certainly contain loops and rarely any recursions. Recursion programs are p…

I definitely don't think in terms of recursion (and I don't think I've seen it explicitly in a recipe!), but I'm not sure loops and interation are necessarily that intuitive, either. I learned programming at an early age and I still distinctly remember the period when loop constructs "made sense".

I can believe that recursion is even less easy to teach than iteration, but it may be that this is a pedagological issue, or that we have yet to work out the best way to convey or document computation.

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

#24

Post by akimball »

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.

The optimizer removes that.

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

#25

Post by akimball »

kilgnad wrote: post #11
ergeysay wrote: post #9

Earlier quoted context omitted.

Not to mention that pure FP completely handwaves away implicit global state such as heap.

That's the point. This hand waving allows the user to build more complex systems. The cost is efficiency but make no mistake not thinking about the heap allows people to build much more complex programs. It's a trade off between complexity and efficiency.

Au contraire. It is a tradeoff between application programmer effort and compiler writer effort. Amortization infers it is better to have an extremely advanced IR optimizer.

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

#26

Post by kccqzy »

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.

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.

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

#27

Post by mrkeen »

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…

> Think of an IDE where a user is typing out code: the state is changing all the time.

That's easy mode. Mutability is often justifiable when one person is doing one thing to a computer at a time. Now extrapolate to multiple people editing the same document at once. Suddenly you're discussing CRDTs and other approaches. And now implement undo on top of that!

Likewise with git, or blockchain, or kafka. They're persistent logs so you can keep your head straight while figuring out what the current state(s) of the system can be. Even with git, when you do an in-place mutation (force-push) there's still an extra log (reflog) behind the scenes trying to keep the changes sane.

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

#28

Post by feoren »

mrkeen wrote: post #27
feoren wrote: post #7

Earlier quoted context omitted.

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…

> Think of an IDE where a user is typing out code: the state is changing all the time. That's easy mode. Mutability is often justifiable when one person is doing one thing to a computer at a time. Now extrapolate to multiple people editing the same document at once. Suddenly you're discussing CRDTs and other approaches. And now implement undo on top of that! Likewise with git, or blockchain, or kafka. They're persist…

I think this is a good example of why "simple CRUD systems" are actually much more complex than people usually give them credit for. Anything seems easy if you do it badly. But multiple people editing a document at once with CRDTs and undo is still even easier than a basic CRUD application done properly: now you have multiple people editing multiple different data types at once! In such cases we should be thinking about building CRDTs over all the various operations users may be doing with the data, which means thinking about associativity and commutativity of generic data operations. Git only has to deal with merging text files line by line; CRUD applications have to deal with merging lots of different data types!

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

#29

Post by dagss »

mpweiher wrote: post #14
feoren wrote: post #7

Earlier quoted context omitted.

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…

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

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

#30

Post by lucisferre »

ZitchDog wrote: post #4

A classic paper with a dream that has yet to be realized. We continue to bolt state on top of state. Redux bolted on top of GraphQL on top of Redis on top of Postgres. We can do better.

It continues to be such a sad state of affairs. We are constantly reinventing and repackaging well known bad practices.

I recall getting publicly lambasted on here for daring to question the wisdom of an ActiveRecord-like data layer for a front-end SPA framework.

Post reply on HN