This presentation is great. I think we need more explanation of how to work with lisps like this one. I always end-up explaining to newcomers that most experienced lispers don't use the repl per-se, but use key bindings to send pieces of code from a file to a repl.
Reminds me very much of Paul Graham's description of bottom up programming, in the first Chapter of "On Lisp". Also, when coming from any non-lisp language, understanding what is meant by "the lisp image" is central here. There are a few which have something similar, one being Smalltalk.
Can you use reactive variables instead of functional for good repl based development. Reactive variables are like getter/setters that notify their dependents to update themselves based on a formula.
name/last looks strange for me :/ May be if this is an analog of table-field. For example, how then should look terms "principal amount, overdue amount, accrued interest amount, principal account, overdue account". Is it like this :amount/principal, :amount/accrued interest and :account/principal ? And why not opposite like :principal/amount ? and what if one level of "struct" is not enough? then keyword ns doed not suite. And if then we have to use nested maps then why we need ns? Sometimes the lack of node.node.node.leaf notation in Clojure is confusing me
There is one name, with two sub-parts: last and first. So the sub-parts are organized together under the same parent node. For the other terms you list, there's not one single amount; there are several different amounts so we wouldn't categorize them all under an :amount node. We could say :account/principal :account/accrued-interest :account/overdue since a single account has multiple quantities associated with it. I find "amount" redundant, but you could write :account/principal-amount if you like.
Nice talk. I'm a bit leery of your worry about "perfectly good facts" being mistaking for incomplete structures in a "slot" language. SQL is a slot-language, in some sense, but if you take a selection (projection, mathematically speaking) you just get a relation with fewer keys. Where's the fire? (By contrast, I usually want to exclude misspelled keys because the computer can't spell.)
This presentation is great. I think we need more explanation of how to work with lisps like this one. I always end-up explaining to newcomers that most experienced lispers don't use the repl per-se, but use key bindings to send pieces of code from a file to a repl.
at 26:53 function called "keys-named" has a hardcoded string "id" inside, I think there should be parameter n instead.
Reminds me very much of Paul Graham's description of bottom up programming, in the first Chapter of "On Lisp". Also, when coming from any non-lisp language, understanding what is meant by "the lisp image" is central here. There are a few which have something similar, one being Smalltalk.
Love the comment blocks suggestion, I always have intermediate things I evaluate, and always throw them away, this is a good little practice,
Every day I'm forced to program in another programming language than Clojure feels like a lost day!
I'm a happy app written by a happy Clojure developer.
Can you use reactive variables instead of functional for good repl based development. Reactive variables are like getter/setters that notify their dependents to update themselves based on a formula.
name/last looks strange for me :/ May be if this is an analog of table-field.
For example, how then should look terms "principal amount, overdue amount, accrued interest amount, principal account, overdue account". Is it like this :amount/principal, :amount/accrued interest and :account/principal ? And why not opposite like :principal/amount ?
and what if one level of "struct" is not enough? then keyword ns doed not suite. And if then we have to use nested maps then why we need ns?
Sometimes the lack of node.node.node.leaf notation in Clojure is confusing me
There is one name, with two sub-parts: last and first. So the sub-parts are organized together under the same parent node.
For the other terms you list, there's not one single amount; there are several different amounts so we wouldn't categorize them all under an :amount node. We could say :account/principal :account/accrued-interest :account/overdue since a single account has multiple quantities associated with it. I find "amount" redundant, but you could write :account/principal-amount if you like.
Nice talk. I'm a bit leery of your worry about "perfectly good facts" being mistaking for incomplete structures in a "slot" language. SQL is a slot-language, in some sense, but if you take a selection (projection, mathematically speaking) you just get a relation with fewer keys. Where's the fire? (By contrast, I usually want to exclude misspelled keys because the computer can't spell.)