Keynote: The Value of Values
Recorded at:
- Share
-
- |
Read later
My Reading List
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.
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.<a href="http://gotocon.com/">http://gotocon.com/</a>
Agreed but bad ROI
by
Duraid Duraid
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
Re: Agreed but bad ROI
by
Erik Bakstad
Re: Agreed but bad ROI
by
Michael Ahern
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
Value oriented development really needs a temporal database
by
peter lin
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
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
Re: Agreed but bad ROI
by
Duraid Duraid
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
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
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
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
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
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
Re: Anyone for a REST?
by
Jonathan Hartley
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
oops.</version></id>
Re: Agreed but bad ROI
by
Duraid Duraid
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.
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think