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

31–40 of 68 posts

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

#31

Post by dagss »

feoren wrote: post #15
dagss wrote: post #6

I feel event sourcing is a real world pragmatic approach to declarative programming that this paper advocates. For state changes you add events to the database to describe something that happened. Any question you may need an answer for / business decision you want to make can be answered by querying the events. The problem at the moment is that while event sourcing is excellent at reducing accidental complexity surr…

Event Sourcing is a nice card to have in your hand, but it should not be a goal in itself. A yard is 3 feet. The atomic mass of Hydrogen is 1.008 and its symbol is "H". These will never change. If someone came to me and said "your 'Chemical' table is not event-sourced. We're doing event-sourcing here. You need to change it." I would tell them to get lost. Why the hell would you have an event for "An Element's Mass wa…

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 something happened. Such input changes the data recorded, or appends what the system should know / has seen. This is an "event".

All input can be framed as being an event. But "an element's mass was modified" is not an event ... it doesn't describe someone or something giving input to our system.

The algebraic view on things you take seems to be treating the system at a different level than what I think about as event sourcing.

Neither "an element's mass was modified" or "sell" or "transaction" that you mention are realistic events. An event is "User U clicked a button in the web console to Sell share S at time T". Implementing the effects of that event -- computing a specific read model resulting from appending the event to the stored set of events -- may well be best done by some algebra like you suggest, but that seems like another topic.

You seem to talk about models for computing and transforming state. I talk about I/O vs data storage.

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

#32

Post by layer8 »

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

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…

> All essential mutable state can be modeled away to use no mutable state

However, that modeling introduces complexity of its own that not everyone agrees is entirely essential.

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

#33

Post by layer8 »

lucisferre wrote: post #30
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.

If only we could change that state of affairs!

;)

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

#34

Post by pletnes »

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.

Btrfs does stuff like instantaneous snapshots for a multi terabyte size filesystem. I have no idea how they do it, but apparently it’s 100% possible.

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

#35

Post by deathanatos »

kccqzy wrote: post #26
enlyth wrote: post #16

Earlier quoted context omitted.

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

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.

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

#36

Post by feoren »

dagss wrote: post #31
feoren wrote: post #15

Earlier quoted context omitted.

Event Sourcing is a nice card to have in your hand, but it should not be a goal in itself. A yard is 3 feet. The atomic mass of Hydrogen is 1.008 and its symbol is "H". These will never change. If someone came to me and said "your 'Chemical' table is not event-sourced. We're doing event-sourcing here. You need to change it." I would tell them to get lost. Why the hell would you have an event for "An Element's Mass wa…

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

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. Instead think about what operations make sense to do with your data, and then think about the mathematical properties of those operations.

> But "an element's mass was modified" is not an event ... it doesn't describe someone or something giving input to our system.

Sure it does. Someone gave you the input that a particular element has a particular mass. How is that not input? How else did you get that data?

> The algebraic view on things you take seems to be treating the system at a different level than what I think about as event sourcing.

This is my exact point. You should think about event sourcing this way, because that's the only reason it's useful: it's accidentally a source of important "domain algebra" that you otherwise might miss. But there's lots of other important "domain algebra" that you are still missing, and they don't necessarily look like event sourcing.

> An event is "User U clicked a button in the web console to Sell share S at time 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!? If that's what you think event sourcing is, sorry to be blunt, but you have very badly misunderstood it.

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

#37

Post by kilgnad »

akimball wrote: post #25
kilgnad wrote: post #11

Earlier quoted context omitted.

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.

Then why do zero cost abstractions exist? Languages like rust and C++ make the trade off on the application side rather then the compiler side.

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

#38

Post by dagss »

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…

Fair points. But how do I get from a "domain algebra" to practical implementation with a popular database?

Event sourcing can be translated to adding rows to tables, or adding documents to collections. Focusing so much on "append" isn't only because of what kind of events you would model, but because you store data in databases by, well, storing it..appending it..

If event sourcing is only useful as a source of an important "domain algebra": How does a domain algebra translate to practical use of a database system for your application? How can I focus on the "operations I want to do on my data", when the tools I am given is pretty much INSERT/UPDATE/SELECT, or GET/PUT, or some variety on these lines?

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

#39

Post by n0w »

I came across this after seeing relic[0] submitted the other day and thought it was pretty interesting.

I've been into CRDTs for a while and have started wondering about generic mechanisms for distributed data. This lead me to read a lot more about the Relational Model of data and eventually to the Event Calculus.

What's interesting to me is that these things end up feeling a lot like CRDTs[1] or Event Sourcing. I haven't quite finished pulling on these threads but the relic link was a timely read considering!

I really liked the first half of this paper and the Authors categorization of complexity. However the second half fell a bit short for me. It seems they made the same mistake as many other people (SQL != Relational) and their idea of Feeders and Observers seems a bit more like an escape hatch than an elegant method for interfacing with the outside world.

[0] https://github.com/wotbrew/relic [1] http://archagon.net/blog/2018/03/24/data-laced-with-history/

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

#40

Post by cubefox »

dannyobrien wrote: post #23
cubefox wrote: post #20

Earlier quoted context omitted.

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,…

Many recipes contain WHILE loops. E.g. while the pan is not full, layer meat sauce, lasagna noodles, and bechamel sauce. FOR loops (do the x process 10 times, or once for everything in a list) are also prefectly natural. Examples for recursion are not as easy to find. This points to recursion itself being harder for us than loops. Understanding loops in recipes doesn't require pedagogical attention.
Post reply on HN