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.
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.
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.
You can use keywords any way you want. To be able to distinguish names globally, there is one convention, though: They should be unique. But that still leaves you with a lot of options: my-org.my-program.names/last-name for example. Or, if you want to completely ignore the namespace part: my-org.my-program/last-name (consider my-org and my-program to be placeholders for actual names). That way you can use the same namespace for every keyword in your data but still ensure that your keywords will be distinct from everybody else’s. I dont fully understand what problem you describe in the second part of your comment, but here is an example of keywords in nested maps: {:my-org.my-program.person/name {:my-org.my-program.person.name/last-name “some name” :my-org.my-program.person.name/first-name “some name”}} To retrieve the respective nested values, assuming the map is assigned to a symbol called “person”: (get-in person [:my-org.my-program.person/name :my-org.my-program.person.name/first-name])
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.)
Every day I'm forced to program in another programming language than Clojure feels like a lost day!
at 26:53 function called "keys-named" has a hardcoded string "id" inside, I think there should be parameter n instead.
Love the comment blocks suggestion, I always have intermediate things I evaluate, and always throw them away, this is a good little practice,
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.
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.
I'm a happy app written by a happy Clojure developer.
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.
You can use keywords any way you want. To be able to distinguish names globally, there is one convention, though: They should be unique. But that still leaves you with a lot of options: my-org.my-program.names/last-name for example. Or, if you want to completely ignore the namespace part: my-org.my-program/last-name (consider my-org and my-program to be placeholders for actual names). That way you can use the same namespace for every keyword in your data but still ensure that your keywords will be distinct from everybody else’s.
I dont fully understand what problem you describe in the second part of your comment, but here is an example of keywords in nested maps:
{:my-org.my-program.person/name {:my-org.my-program.person.name/last-name “some name”
:my-org.my-program.person.name/first-name “some name”}}
To retrieve the respective nested values, assuming the map is assigned to a symbol called “person”:
(get-in person [:my-org.my-program.person/name :my-org.my-program.person.name/first-name])
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.)