this reminds me a lot of "How to beat the CAP theorem" http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html
Rich Hickey: Deconstructing the Database
31–40 of 93 posts
Re: Rich Hickey: Deconstructing the Database
#32I often wonder, is Phd in computer science really required to do awesome work?
Of course not. You can certainly learn all you need to know on your own. However, that doesn't make the process of learning any easier. If you can get into a PhD program, it is a wonderful way to get access to information of various sorts.
If not, then the new free CS courses that are now being offered by Stanford and others provide extra help beyond reading books and papers. I'd highly recommend trying some!
Re: Rich Hickey: Deconstructing the Database
#33I often wonder, is Phd in computer science really required to do awesome work?
Rich Hickey never went to school for Computer Science as far as I know. He studied music composition.
Re: Rich Hickey: Deconstructing the Database
#34Earlier quoted context omitted.
One of the reasons I've adopted Clojure (for small things... so far...) is the high density of very smart folks using it and building it.
I did too until I realized I wasn't ready for so much lispiness, too abstract for me right now.
"too abstract" is not a phrase I'd think to associate with a lisp. It's all just data. If anything I'd expect people to say there's too little abstraction.
Re: Rich Hickey: Deconstructing the Database
#35I often wonder, is Phd in computer science really required to do awesome work?
I would say no, but a good chunk of knowledge is (though probably less is required than imagined) and if the academic methods of acquiring knowledge suit you (for many hackers they don't) then a Ph.D is a fine way to get a good chunk of knowledge. Here's Rich Hickey's recommended reading for Clojure specifically: http://www.amazon.com/Clojure-Bookshelf/lm/R3LG3ZBZS4GCTH/re... It's not exhaustive for even functional programming and design let alone the entirety of computer science, but it's certainly a good chunk of knowledge enough to do awesome work from.
Re: Rich Hickey: Deconstructing the Database
#36How would you idiomatically fix invalid data in Datomic? for example, if you needed to update a badly entered value in a record, but keep the record's timestamp the same so as not to screw up historical queries?
You wouldn't. You can't change history either. You would insert a compensating transaction and the data would be fixed from that time forward when you inserted the compensating transaction.
Re: Rich Hickey: Deconstructing the Database
#37Re: Rich Hickey: Deconstructing the Database
#38How would you idiomatically fix invalid data in Datomic? for example, if you needed to update a badly entered value in a record, but keep the record's timestamp the same so as not to screw up historical queries?
You can retract facts, just like you can assert facts.
Re: Rich Hickey: Deconstructing the Database
#39I'm always puzzled when the Datomic folks speak of reads not being covered under a transaction. This is dangerous.
Here's the scenario, that in a conventional update-oriented store, is termed as a "lost update". "A" reads object.v1, "B" reads the same version, "B" adds a fact to the object making it v2, then "A" comes along and writes obj.v3 based on its own _stale_ knowledge of the object. In effect, it has clobbered what "B" wrote, because A's write came later and has become the latest version of the object. The fact that DAtomic's transactor serialized writes is meaningless because it doesn't take into account read dependency.
In other words, DAtomic gives you an equivalent of Read-committed or snapshot isolation, but not true serializability. I wouldn't use it for a banking transaction for sure. To fix it, DAtomic would need to add a test-and-set primitive to implement optimistic concurrency, so that a client can say, "process this write only if this condition is still true". Otherwise, two clients are only going to be talking past each other.
Re: Rich Hickey: Deconstructing the Database
#40There are two people that I will stop what I'm doing and watch every new lecture they make: Rich Hickey and Bret Victor. Both are visionaries.
Interesting that you name them 'together'. On the surface, they are doing quite different things. On a deeper level, it seems to me, they approaching things in a very similar manner. I think what they share is a style of work very detached from the hectic, local improvement approach, which is usually forced upon us in industry for efficiency reasons. They inspiringly take their time to dig deep to identify hidden ass…
At a deeper level they are both pragmatic philosophers. They think at a high level but they are hands-on and have their feet firmly on ground realities. Inventing on principle is Bret Victor's contribution, but Rich Hickey surely lives it; and Hammock-Driven Development is Rich's notion, but there wouldn't be "Inventing on principle" without HDD on Bret's part. These two are awesome.