3 ms·
That seems like a huge stretch. Lisp has nothing to do with that paper, and minimizing state and complexity could hardly be more obvious design concerns. The co
by gruseom 15y ago
That seems like a huge stretch. Lisp has nothing to do with that paper, and minimizing state and complexity could hardly be more obvious design concerns. The concurrency aspect I can't comment on, but it's not a major theme there either.
Perhaps I just don't get it, but I'm a little miffed at having tried several times to absorb the gems of wisdom in that paper and come up with nothing that isn't obvious (even the idea of functional programming over relational data is obvious) and that couldn't have been said less pretentiously in easily a tenth of the space - ironically, for a paper about minimizing complexity.
- arohner 15y agoThe paper was about several things: 1) accidental complexity is the source of a large number of bugs 2) implicit, unnecessary, tightly-coupled state is the cause of a significant number of bugs. 3) mostly-functional programming reduces the amount of state in 2 4) RDMS databases, with transactions and triggers, are a good way of reducing state as well Clojure applies all of these lessons. lisp reduces accidental complexity in the language. FP reduces accidental complexity wrt to state. the STM and agents are close analogues to DB transactions and triggers. "even the idea of functional programming over relational data is obvious". Yes, but where else has that been tried?
- gruseom 15y agoI posted a reply, but decided I was repeating myself. Thanks for the discussion.