BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Presentations Keynote: The Value of Values

Keynote: The Value of Values

Bookmarks
58:53

Summary

Rich Hickey compares value-oriented programming with place-oriented programming concluding that the time of imperative languages has passed and it is the time of functional programming.

Bio

Rich Hickey, the author of Clojure, is an independent software designer, consultant and application architect with over 20 years of experience in all facets of software development. Rich has worked on scheduling systems, broadcast automation, audio analysis and fingerprinting, database design, yield management, exit poll systems, and machine listening.

About the conference

For the second time we are launching the GOTO Copenhagen conference in May 2012 after a successful execution in 2011. GOTO Aarhus has been an annual event in Denmark since 1996 and attracts more than 1200 participants (formerly known as JAOO). The target audience for GOTO conferences are software developers, IT architects and project managers.http://gotocon.com/

Recorded at:

Aug 14, 2012

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Agreed but bad ROI

    by Duraid Duraid,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Values are better than place but they're extremely more complex. Yes programmers use source control systems but it wasn't until git (or distributed source control systems) that programmers got them right and they are very complicated compared to writing to a directory (which is not that crazy since linux used no source control until git).

    Building value based systems is way more difficult than place systems and the return is questionable.

    So I disagree with the point that place oriented systems existed only because of storage limitation. I think for the most part they still exist because it's much easier to think about now only if you can afford to.

  • A non place-oriented database

    by Tin Pavlinic,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Can anybody recommend an existing database that is not place-oriented?

  • Re: Agreed but bad ROI

    by Erik Bakstad,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The pedant in me could help it: Linux started using BitKeeper in 2002, so git was not the first source control.

  • Re: A non place-oriented database

    by Cédric Pineau,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Datomic (authored by Rich) is value based.

    Cédric

  • Re: Agreed but bad ROI

    by Michael Ahern,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Well, until you have requirements that depend on the feature...

    I have been working on a particular project now for 4 years and back at the beginning I could not even conceive of how important the time issue would be.

    After being in production for years a common issue from the field is object level backup & restore. Users - not just admins - would periodically delete or mess up data and wish to restore to a previous version. With data structures that did not have versioning carefully baked into the schema this was such a massive undertaking (given the product size) that I doubt it will ever get implemented.

    With edge cases of course, had I had a data store like this, I could almost get the feature for free by just finding the transaction id and the corresponding assertion/retractions.

    The point this and the point of the not-only-SQL movement is to choose the data store fits your problem space. At least for what I am doing, this data model (if it works as advertised) is a perfect fit.

  • Event sourcing

    by mark bryant,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I believe you can go a long way towards obtaining the benefits of a system that records all state information by using Event sourcing. This does not address the issue at the small scale though as it applies to the interaction between aggregates. However it does allow us to leverage the momentum of experience imperative languages currently have.

  • Value oriented development really needs a temporal database

    by peter lin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    One of the big challenges with value oriented development/design is it really needs temporal database. Since most existing databases RDB and NoSql don't provide a consistent and scalable way to store/query temporal data, most people have been stuck with what rich calls "place" oriented systems.

    For anyone that has built bi-temporal databases multiple times, you know how hard it is to do this.

  • Re: Agreed but bad ROI

    by Alexander Semenov,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    > Building value based systems is way more difficult than place systems and the return is questionable.

    I'm not sure it is. With all those benefits from values why are you still saying that PLOP is simpler? What about concurrency?

  • Re: Event sourcing

    by mark bryant,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Here is talk by Greg Young discussing how event sourcing leads to a value & functional domain model and how it can be implemented in an imperative language skillsmatter.com/podcast/design-architecture/dd... But then asks the question why not take the leap to a functional one.

  • Re: Agreed but bad ROI

    by Duraid Duraid,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    why are you still saying that PLOP is simpler? What about concurrency?


    In the presentation, Rich himself said that it is very difficult to get the NOW value in a value based system and said "it is very difficult don't do it yourself" (not exact words). Getting the NOW value in a PLOP system is trivial and cheap and we do it all the time since all you have is NOW.

    I agree that PLOP is problematic for concurrency. However, it is extreme to say that you need concurrency for every single value in your program. I suggest that in the areas of the program that require concurrency you use a value based system and pay the price of the added complexity. In that case it's a worthwhile compromise.

  • Re: Agreed but bad ROI

    by Zach Thompson,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    In the presentation, Rich himself said that it is very difficult to get the NOW value in a value based system and said "it is very difficult don't do it yourself" (not exact words). Getting the NOW value in a PLOP system is trivial and cheap and we do it all the time since all you have is NOW.

    I'm pretty sure he was talking about trying to roll your own value-based system in PLOP by using timestamps with an append only model (~42:05). Writing the now query to get the latest value for each entity not being fun.

  • Re: Agreed but bad ROI

    by peter lin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The challenge/issue is far more complicated and subtle than just getting "now" value. Look at the field of active databases and temporal databases. When you start considering time with databases, you can't escape the complexities of temporal databases and the notion of time. It's not just having a timestamp with each record. If you wanted to find what happened in a given period of time, how do you query for it? What system of time do you use?

    There's a reason why temporal logic and temporal databases is still where it is today. Building these types of systems is actually very hard and far beyond what a typical developer can handle. Even with academic researchers, many challenges are still unresolved today.

  • Re: Agreed but bad ROI

    by Robert Gacki,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    So I disagree with the point that place oriented systems existed only because of storage limitation. I think for the most part they still exist because it's much easier to think about now only if you can afford to.


    Yes, he contradicts himself a bit, if he implies that adding new values would solve the place or implementation (logic) problem. I think, in the end, what he tries to say is, that you should add new values whenever you can (even when the structure changes) and do not update the existing ones, just because memory is cheap. Of course, the new values will take new places. And the retrieval of values has to be somehow magically hidden (queries) from the user/system. What he hides is that as soon values are used, there are constraints to them. And those constraints need to be managed too, like value formats (data structure), concurrency / state issues or the queries which retrieve the values in the first place. And if we keep the immutable values around, the constraints increase each time the structure of values change. So not having old immutable values around reduces complexity when there are transitions in logic (implementation or protocol) that uses or generates those values. In the end, values are worthless when there is no logic that uses them. That's another reason not to keep old values around, to migrate the value structure or backup and remove them completely. By adding new values independently of their structure or meaning, Hickey just pushes complexity out of the value store, but to the implementation / protocol level. And yes, that's hard to maintain.

    So if we should add new data just because memory is cheap, that contradicts the reason for information management. Too much data around can be as harmful as missing some. Data still needs to get managed, by logic. And that logic needs to get maintained as well.

  • Re: Agreed but bad ROI

    by Pierre Lhoste,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    What Rich emphasizes, from what I've understood (apart from the Linus's way of bashing, but let's reckon Rich has style, and no haughtiness), there is no excuse nowadays, to dismiss data-oriented-programing in favor or PLOP, without first telling your boss all about it. Mine was scared shitless, cause any modification in our pipeline requires months of testing before it can safely go into prod.

    We're a very small company, and the gist of what we're manipulating is historical data for slow moving organisations which require to be able and consult things that are 15 years old every so often, across a shitload of legacy apps (some of them still in ASP classic, yes you read that correctly), and the only solution we've implemented that satisfied us sofar was logging everything, piping legacy logs to augmented logs, and snapshoting the TB of data (still plain old rsync and hard links for the most part on RAID clusters), and using ONLY databases as a fast readonly snapshot (built and updated from the logs, not the other way around) for 99% of user requests. All that in... perl, because our 1998 legacy scripts still work. Not fun. Horrible scalability problems,... And the "as of now" request Rich talks about is where 50% of the maintenance goes.

    No need to add that we jumped on the free version of Datomic to begin testing, and sofar, apart for the change in paradygm for the younger developers in our team (but as of now it's me lagging behind them), Closure has been a treat.

    I'm one of those not so old dinosaurs who never really embraced OOP since I read that book on Java in 94, because... well never could tell anyone why exactly. Then I watched this talk, and click : it's not what our company is about. We're a log company, a data company, a record company, a FACT company. We don't frigging care about the coolness of the language, we need to access our historical data in a fast and consistent way. That's it.

    So as a conclusion, I guess Rich's talk is more or less relevant depending on what drives your company's activity.

  • Anyone for a REST?

    by Conor Moran,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I wonder about the intended scope of this talk. Is Rich talking language paradigms or more. It seems a lot wider to me.
    It seems to me the whole REST thing is all about Place - a place with an address (URI). We have the standard verbs which allow us to access/update that place.
    So is HTTP as the transport mechanism of the WEB simply wrong? Is that your conscious contention here Rich?

  • Re: Agreed but bad ROI

    by Jonathan Hartley,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    @Duraid It doesn't sound like you're saying that because you've built large systems using both techniques. It sounds more like you're familiar with 'plop', and have played around with 'vlop', but are a bit stuck on one or two things, so prefer using what you're familiar with. It's an entirely reasonable to object to 'vlop' because it's unfamiliar to many people, or because there are hurdles when transitioning from plot to vlop. But I don't think these reasons are sufficient to entirely dismiss the technique, which is what you sounds like you're doing.

  • Re: Anyone for a REST?

    by Jonathan Hartley,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    He references 'http' and 'rest' in the talk several times as systems which are generally doing it 'right', by exchanging values embedded in the content.

    I would guess that a natural extension of rest to accomodate what Rich is saying is that a particular 'resource', exposed at a fixed URL, represents the state of an entity at a particular time. Updates to that resource would not update it in place, but would create a new resource. Hence once could imaging:

    GET state at a particular time or version
    domain.com/resource/<id>/<version>

    GET shorthand for 'get the latest version':
    domain.com/resource/<id>

    To do an 'update', you POST to:
    domain.com/resource/<id>
    This returns the URL of the new latest state:
    domain.com/resource/<id>/<version>+1

    I think that this ends up being a superset of traditional REST. If you take away the access to the endpoints ending in <id> (and exposing them is entirely optional, depending on whether you need that), then that's just traditional REST. So REST is already entirely in tune with what Rich is advocating.

    Do you think I'm barking up the right tree?</id></version></id></id></id></version></id>

  • Re: Anyone for a REST?

    by Jonathan Hartley,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    s/take away the access to the endpoints ending in <id>/take away the access to the endpoints ending in <version>


    oops.</version></id>

  • Re: Agreed but bad ROI

    by Duraid Duraid,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Familiarity is a factor, I agree, but that was not my point. My point is that vlop is much more complex than plop, in Rich's words "don't try it at home". Thus, applying a complex solution where a simpler one suffices is bad ROI.

    Also, I disagree with Rich's argument that the only reason for vlop not taking over is historical hardware limitation. I think it is the complexity of vlop that was, and still is, the major factor.

  • Please make this work on the desktop without Flash

    by Tim Schafer,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The video player doesn't work on Chrome with it's built in flash disabled. Neither does it work on Safari without flash installed. Yet it does work on the iPad. So clearly it CAN work without flash. Chrome is much better behaved with flash disabled. It would be really great if this site would work without flash on the desktop! Since disabling flash in Chrome, this is the only site that doesn't work. Even netflix works without flash!

  • the future

    by Val Waeselynck,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I deeply agree with this - our current IT tools are wrong. I can testify that basing our IT systems on the classical place-oriented feels just as safe as bookkeeping with a slate. Unfortunately, as of 2015, I do not see a lot of technological options for value-based databases (except Datomic, which is not affordable to everyone).

  • Extremelly exaggerated

    by Evandro Pomatti,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Reusability is the biggest lie in OO? That is just dishonest and extremist of him to guide the audience in that direction. He is clearly using very specific examples that are exceptions, not the general case.

    A honest approach would consider the cost, impact and problems of what he is proposing.

    There is value on what he presents (no pun intended), but the presentation is too single-minded and sensationalist for me to give any credit.

  • Re: Extremelly exaggerated

    by Val Waeselynck,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Reusability is the biggest lie in OO? That is just dishonest and extremist of him to guide the audience in that direction.


    I have known many people who would agree with you that OO is good at reuse - including me several years ago. All these people had in common that they had never tried anything else. In my view, your argument would be much stronger if you showed experience with functional / data-oriented technologies.

    Now that I have tried both approaches, when I hear people tell me that OO is great because inheritance lets you reuse code, it's as if they told me that the Sahara is great because oases let you drink :).

    the only reason for my former way of thinking was that I didn't know any better, but I'm curious to hear arguments based on experience and an informed comparison if you have them.

  • Link to transcript

    by Andy Fingerhut,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Here is a link to a transcript of this 1-hour version of Rich's talk: github.com/matthiasn/talk-transcripts/blob/mast...

    There is a shorter 30-min version given a couple of months later, with a transcript and video link here: github.com/matthiasn/talk-transcripts/blob/mast...

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT