Rich Hickey: The Value of Values • Hacker News Board

Re: Rich Hickey: The Value of Values

#41

Post by talaketu » Wed, Aug 15, 2012, 1:18 PM UTC

yason wrote: post #33

mickeyp wrote: post #27

Earlier quoted context omitted.

> you pass a primary key and it could be anything by the time the receiver gets around to using it. If instead the value was immutable passing a primary key would be fine. Not sure what you mean by receiver here -- receiver as in the database or another component in your software hierarchy? The best way to ensure that your data goes unchanged across atomically disparate events is to insist that (Oracle, which is what…

I think the parent meant the value vs. reference separation. Consider that you create a record, give it a primary key N, then start referring to that value by the primary key and at some point make an update to the record, the same primary key now refers to another value . The primary key is just a reference pointer to a placeholder (=record) and depending on whatnot the value in the placeholder can change to anythin…

Exactly. Primary key is a subset of attributes - thus necessarily populated by values.

It's worth considering the correspondence between the concept of functional dependency in the relational model, and the concept of a pure function in functional programming. The issue under discussion, then, is whether referential transparency is afforded in the database.

While referential transparency in a database is achieved momentarily at the right isolation level, it is not achieved in the eternal sense of a pure function.

This is because the functional dependency in FP encodes an intensional definition, whereas the functional dependency captured in a relation is extensional, usually modelling the state of the knowledge of the relevant world, and therefore being subject to change.

Re: Rich Hickey: The Value of Values

#42

Post by Chris_Newton » Wed, Aug 15, 2012, 2:18 PM UTC

danenania wrote: post #39

Chris_Newton wrote: post #28

Earlier quoted context omitted.

For the avoidance of doubt, when I’m talking about (not) doing away with a time dimension here, I mean from the perspective of the world changing over time as our program runs, not of associating values that effectively last forever with a certain point in time (as in purely functional data structures, version control systems, etc.). That is, even if we follow the current trend of adopting more ideas from functional…

I'm far from an expert on this topic, but it seems that you're still missing the main point--this talk is exactly about how to model time dependent data (immutable data), and how not to (mutable state, oo). Hickey definitely isn't advocating a system that can't change with time. Such a system would be pointless. He wants changes in state (which, naturally, occur on a time axis) to be represented by new values, not as…

I’m pretty sure I understand where Rich is coming from. I’m just arguing that while moving to persistent, immutable values is a big step in what could be a good direction, it’s not sufficient by itself to justify or cause a shift in mainstream programming styles on the scale of abandoning OOP (as suggested in the original post I replied to).

You lose things in that transition, very useful things that are widely applicable. We’re not going to just give those up without having something good enough to replace them, and I thought that in this specific talk those two areas I mentioned were glossed over far too readily.

For example, although Rich said very clearly that he thought it was OK to manipulate data in-place as an implementation detail of how a new value is built, he then argued that once the finished result was ready it should become an immutable value, and that we no longer need to use abstractions that are based on or tied to that kind of underlying behaviour. I contend that there are many cases where it is not so simple even with today’s technology, and that the idea of constraining in-place mutation to the initial creation of a value is a leaky abstraction that will not survive a lot of practical applications.

Later on, processes are briefly mentioned, but that part of the talk is about information systems, which are mostly concerned with pure data analysis. That makes it is rather easy to dismiss the idea of modelling interactive processes in context, but unfortunately, very many real world programs do need to be concerned with the wider time-related concepts like effects.

I’m sure Rich himself is well aware of all of these issues. He’s discussed related ideas in far more detail on other occasions, including in the talk that lrenn cited above. But I find his challenge near the end of this talk, “If you can afford to do this, why would you do anything else? What’s a really good reason for doing something else?” to be rather unconvincing. For one thing, that’s a mighty big “if”, whether you interpret “afford” in terms of performance or dollars. For another thing, the answer to those questions could simply be “Because ‘this’ isn’t capable of modelling my real world, interactive system effectively.”

Re: Rich Hickey: The Value of Values

#43

Post by barrkel » Wed, Aug 15, 2012, 2:27 PM UTC

dustingetz wrote: post #8

gingerlime wrote: post #6

Great talk, and without having any experience with FP, it really makes sense on many levels. I love data, and how transparent it is, and how objects seem to get in the way a lot of the time. I like queues, and shipping data from one process to another rather than sharing objects. RESTful interfaces, etc. Those concepts and tools are powerful. The only thing I'm not too comfortable with is that space isn't really infi…

> This is why we rotate logs, archive them and trash them eventually. i think an organization trashes old logs for out-of-band reasons - acquiring more disk space requires following an organization's procurement process which imposes tons of friction, or because compliance with applicable regulations requires saving, e.g., emails, for three months and saving them for longer is a legal risk.

Old logs may be a privacy liability; and depending on the type of log and the load on the system, the fully loaded cost of keeping logs indefinitely may be too high to justify based on the revenue for a customer (I'm thinking of ISP logs in particular, for example).

Re: Rich Hickey: The Value of Values

#44

Post by jcromartie » Mon, Aug 20, 2012, 8:23 PM UTC

ajcronk wrote: post #10

Has anyone seen a Sales CRM implemented with a temporal+value approach? Seems quite useful for tracking movement through a funnel.

Anything that touches financial records-keeping would be ripe for this kind of software, too. I spent quite some time on a financial services system and our number one enemy was mutable state.