Using the relational model for app data in memory is really interesting.
Martin Fowler wrote about doing that as a way to get around the "object-relational mismatch" issue[1]. Richard Fabian describes "data-oriented design" as having a lot of overlap with the relational model[2]. ECSes becoming very popular in game engines are basically in-memory relational databases where "components" are "tables"[3].
No, components are columns. Each entity is a row in a table and an archetype (the set of all entities with the same components) is a table.
In ECS it's usual to store components together, this corresponds to columnar storage in database terms (or equivalently, it's as if data were in sixth normal form [0]). However in some systems you can opt to store a more traditional row-based column.
This idea was raised years before Martin Fowler blogged about it. The tar pit paper linked in the article is from 2006 and the author's had been doing this year's prior to that.
Clojure(script) always seems to me to be this hotbed of interesting ideas in programming. I.e. you'll see something wild like this start here then eventually the concepts make their way out into regular JavaScript.
I'm almost starting to regret not picking Clojurescript for my app
Lots of stuff now established as "best practices" or whatever in frontend JavaScript applications comes from being made popular with ClojureScript development. Side-effects as data, hot reloading, keeping your app state in one place all were inspired from work happening in the ClojureScript community at the time JavaScript community "discovered" it.
The ClojureScript community obviously didn't come up with everything, many of the ideas are very old ideas for UI development but didn't really exist in the "web-sphere" before. I'm pretty sure I can remember Dan Abramov saying Redux was directly inspired by stuff happening in the ClojureScript community, particularly around atoms and hot-reloading. Also I think Pete Hunt mentioned stuff David Nolen was working on when talking about React as well initially, but less confident about this.
This looks really interesting! As someone who has worked with relational databases and Clojure in the past, I can definitely see the appeal of a functional relational programming model.
I like that relic provides support for declarative data processing and declarative relational constraints. These are areas that can be tricky to handle when working with traditional relational databases, so it's great to see a library that addresses these pain points.
The ability to use relic with reactive programming is also a big plus. I'm curious to see how this would work in practice, particularly in the context of an interactive application.
Overall, relic seems like a promising library for anyone looking to work with normalized data in Clojure. I'll definitely be giving it a try on my next project!
Dan recently recorded a session about Relic, if you'd like to hear him speak more about the origins of the library, some design choices, and some examples:
I guess sqlite + honeysql would be an alternative. Curious to know why the author prefers the relations/table/codd model over graph-map-databases like datomic and thinks something like datomic "feels out" of "out of the tarpit".
Beautiful. I've been noodling on exactly this same idea. So far I've explored using SQLite but it would be ideal if there was no SQL between me and my relations. Another direction I've taken is adding STM to JavaScript and implementing a JS api for querying relations.
How are updates triggered, what's the mechanism? From the examples it seems like you don't need to subscribe and provide a function to be called when changes happen, but then how does it work?
A relic db is a persistent data-structure [1]. Applying a transaction with rel/transact gives you a new database, rel/track-transact also returns the changes to relations you have opted-in to change tracking (using rel/watch).
Funnyduck99 is probably mocking all the people that go into HN posts about Clojure to complain about how their team of non-Clojure programmers went to work on a Clojure project and it was a bad experience.
We (professional developers using lisp-like languages daily) don't have the reaction of "ewww" as soon as we see something foreign, but instead we think "hmm, that looks different, I wonder why it looks different?" and then we start to try to understand it. Then you give a lisp-like language a try (Clojure in my case) and suddenly it's really hard to program in any other language, because they're not as good as a lisp language.
If you have a knee-jerk reaction to everything that looks different, you'll lose out on lots of fun stuff. You should give lisp a try, I'm sure you won't regret it.
I like the structure that S-expressions convey. Must be something with how my brain works. It's probably also why I find Python code utterly unreadable.
To each their own! I feel the same way about Algol family languages, too many arbitrary design decisions that have been internalised for decades at this point for my liking.
[+] [-] crabmusket|3 years ago|reply
Martin Fowler wrote about doing that as a way to get around the "object-relational mismatch" issue[1]. Richard Fabian describes "data-oriented design" as having a lot of overlap with the relational model[2]. ECSes becoming very popular in game engines are basically in-memory relational databases where "components" are "tables"[3].
[1]: https://martinfowler.com/bliki/OrmHate.html
[2]: https://dataorienteddesign.com/dodbook/
[3]: https://github.com/SanderMertens/ecs-faq#what-is-ecs
[+] [-] nextaccountic|3 years ago|reply
No, components are columns. Each entity is a row in a table and an archetype (the set of all entities with the same components) is a table.
In ECS it's usual to store components together, this corresponds to columnar storage in database terms (or equivalently, it's as if data were in sixth normal form [0]). However in some systems you can opt to store a more traditional row-based column.
[0] https://en.wikipedia.org/wiki/Database_normalization#Satisfy...
[+] [-] sitkack|3 years ago|reply
[+] [-] grumpyprole|3 years ago|reply
[+] [-] Rodeoclash|3 years ago|reply
I'm almost starting to regret not picking Clojurescript for my app
[+] [-] capableweb|3 years ago|reply
The ClojureScript community obviously didn't come up with everything, many of the ideas are very old ideas for UI development but didn't really exist in the "web-sphere" before. I'm pretty sure I can remember Dan Abramov saying Redux was directly inspired by stuff happening in the ClojureScript community, particularly around atoms and hot-reloading. Also I think Pete Hunt mentioned stuff David Nolen was working on when talking about React as well initially, but less confident about this.
[+] [-] nextos|3 years ago|reply
It's a bit of a tragedy it has been mostly abandoned. I wish a Lisp, such as Clojure, emulated Mozart/Oz semantics.
[1] https://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf
[+] [-] wotbrew|3 years ago|reply
[+] [-] prettyStandard|3 years ago|reply
I like that relic provides support for declarative data processing and declarative relational constraints. These are areas that can be tricky to handle when working with traditional relational databases, so it's great to see a library that addresses these pain points.
The ability to use relic with reactive programming is also a big plus. I'm curious to see how this would work in practice, particularly in the context of an interactive application.
Overall, relic seems like a promising library for anyone looking to work with normalized data in Clojure. I'll definitely be giving it a try on my next project!
[+] [-] joelittlejohn|3 years ago|reply
https://youtube.com/watch?v=QsEJ5O2e4Es
[+] [-] sesm|3 years ago|reply
[+] [-] Scarbutt|3 years ago|reply
[+] [-] wotbrew|3 years ago|reply
I do think for some it might be easier to reason mechanically about dataflow through collection-oriented operators. But I suppose it's subjective.
clj-3df [1] to my understanding does something like Relic for datomic datalog using differential dataflow.
Disclaimer: I now work on XTDB [2], so datalog is somewhat now my day job.
[1] https://github.com/sixthnormal/clj-3df
[2] https://xtdb.com/
[+] [-] tantaman|3 years ago|reply
[+] [-] wcerfgba|3 years ago|reply
[+] [-] wotbrew|3 years ago|reply
[1] https://en.wikipedia.org/wiki/Persistent_data_structure
[+] [-] lincpa|3 years ago|reply
[deleted]
[+] [-] Funnyduck99|3 years ago|reply
[+] [-] ballpark|3 years ago|reply
[+] [-] brap|3 years ago|reply
[+] [-] capableweb|3 years ago|reply
If you have a knee-jerk reaction to everything that looks different, you'll lose out on lots of fun stuff. You should give lisp a try, I'm sure you won't regret it.
[+] [-] yogthos|3 years ago|reply
[+] [-] tmtvl|3 years ago|reply
[+] [-] rawoke083600|3 years ago|reply
Then suddenly after a month or so you suddenly realise wow, this is actually nice and useful and now all other non S-Exp feels jukky.
You get to that point NOT because you are now simply enduring/accepting that it looks ugly but it really after a while becomes pretty !
It's like picking up smoking, no one likes the first or two cigarettes at first, it taste like sht, yet if you keep doing it becomes lovely. *
PS. Don't smoke kids !
[+] [-] butternoodle|3 years ago|reply
[+] [-] michaelteter|3 years ago|reply
[+] [-] chitowneats|3 years ago|reply
[deleted]