Relic: Functional relational programming for Clojure(Script)
github.com
github.com
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
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...
Conceptually I think you could equate components with relations. For example a "grid location" component could be imagined as a relation with "entity ID" and "coordinate" columns. I suppose that admits multiple component instances per entity ID though which is typically not what you want.
6th Normal Form? I was taught that 3NF should be enough for all intents and purposes, which now sounds like the quote about 640k memory.
I'm almost starting to regret not picking Clojurescript for my app
But the rewards are in line with the risks.
It's a bit of a tragedy it has been mostly abandoned. I wish a Lisp, such as Clojure, emulated Mozart/Oz semantics.
There's also a summary poster [2].
Actually, CTM was in Rich Hickey's reading list when he designed Clojure [3].
[1] https://www.info.ucl.ac.be/~pvr/book.html
[2] https://www.info.ucl.ac.be/~pvr/paradigmsDIAGRAMeng201.pdf
[3] https://www.goodreads.com/list/show/137472.Rich_Hickey_s_Clo...
Agreed. But wow the documentation was a mess. So much language progress these last decades has been around increasing minimum expectations for ecosystem.
Poplog (integrated CommonLisp, prolog, ML, an a C-like; 1980's) is another on my list of roads regrettably not taken. Killed by commercialization. Which also zombied CL.
https://github.com/hebisch/poplog https://www.cs.bham.ac.uk/research/projects/poplog/freepoplo...
> Of course, many of these paradigms are useless in practice, such as the empty paradigm (no concepts)[1] or paradigms with only one concept.
> [1]: Similar reasoning explains why Baskin-Robbins has exactly 31 flavors of ice cream. We postulate that they have only 5 flavors, which gives 2^5 − 1 = 31 combinations with at least one flavor. The 32nd combination is the empty flavor. The taste of the empty flavor is an open research question.
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.
See https://redux.js.org/understanding/history-and-design/prior-... which lists Elm right under Flux.
Now we just have to get a handle on all the leaky stuff at the edges of every “functional core”, because there lay many dragons.
In my experience, languages like C, Go, Java, C# still dominate the backend. Replacing JavaScript is such a simple and well-defined task that I expect it will be completed much sooner. Maybe only a decade or two.
My gut is telling me erlang might have tackled this.
Think of how we do it on the wire: we send a description of a event (command/effect) to an API server which routes/dispatches it to something that applies an effect. It’s not a function call, but a generic (implementation agnostic) description of intent in pure data.
It’s like that but inside your program.
Just a function.
> where it's sending that once it's created, and then where the "drivers" would come from and how they would get invoked
Depends on entirely on how you'd do it.
You can apply the Functional Core Imperative Shell architecture, where side-effecting, stateful code (imperative shell) always calls the functional code (functional core). The shell basically handles files, db connections, HTTP/TCP, exceptions, retries etc. and basically asks the functional core of what to do by providing the data that comes out of those things.
For example there's no reason a HTTP routing library has to do IoC. It can also be structured in a way so you you give it a path and it returns you data, such as an event description, a set of questions or a command description etc.
There are also frameworks that work this way, for example the UI state management framework re-frame. It handles the side effects for you and calls your functions that you register on certain UI events. The re-frame documentation is very good at explaining this step by step.
(rf/reg-event-fx
:stop-timer
(fn [{:keys [db]} _]
(let [handle (db :ticker-handle)]
{:db (assoc db :ticker-handle nil)
:stop-ticker [handle]})))
The event handler is just describing the side effect that is to occur by returning the map.
Sorry, I know no clojurescript, so I'm having a hard time parsing it even googling the syntax
There is a piece of code which emits the event :stop-timer, that stops a js timer in the window.
:on-click (fn [_](rf/dispatch-sync [:stop-timer]))
{:key :value}
There is then a further function which does the actual event
(rf/reg-fx
:stop-ticker
(fn [[handle]]
(when (not (nil? handle))
(js/clearInterval handle))))
Personally I'm not a fan of this abstraction (another layer of indirection). I'd rather take a `transact` function as an argument.
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!
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.
He mentions it in various videos but these snippets are two quick finds:
In contrast, a system that only handles base data in terms of triples assumes that you have a perfect attribute-oriented information model figured out upfront. But given this is rarely the case users will want tools that help them to easily transform/migrate their data and schema over time. Ideally this takes the form of a declarative language that minimises the amount of code that needs to be written. However, without a compelling end-to-end transformation language figured out I think any alternative database systems with their alternative information models (triple-based or otherwise) will struggle to compare favourably with mainstream databases, where declarative data munging with SQL is considered valuable and routine.
Triples may well prove to be the best way to handle information in software over the long-term, but I'm not sure that the systems which currently work with triples are good enough or widespread enough to test that theory.
Curious, where do you think datomic and datalog fall short (assuming one is using clojure and datomic's performance is tolerable)? By "perfect attribute-oriented model" I assume you are referring to the database's information model and support for that model, not to domain modeling with triples. Triples and relations are equally flexible but which models require more effort to maintain and transform along side with your application?
I think Hickey's point is that the structurally rigid nature of relations and stuff like arbitrary join tables needed to created many-to-many relations is that they get hard-coded throughout your application making your applications very hard to change over time, forcing you to put extreme effort to provide a set of logical views to isolate the application from the physical structural decisions. He says 'the more structural components(tables/intersection tables and having to name them(places)) you have in your model the more rigidity you get in your applications, but as you mentioned, triples haven't prove themselves.
I'm not experienced enough to understand all the tradeoffs here and can't tell if Hickey is wearing a salesman hat ;)
Of course, databases like postgres would be my first choice for most projects (even if using clojure which I like but is still a hard sell for webapps), as you said, they have too much going for them (flexibility of relational algebra, SQL, they are well understood, widespread, great ahd well supported implementations, etc..)
> provide a set of logical views to isolate the application from the physical structural decisions
To me this feels like the holy grail for what people really want from databases (beyond the basics of transactions/durability), and triples definitely still hold promise as a helpful abstraction. However I suspect Incremental View Maintenance (as Relic discusses) has a potentially even bigger role to play here.
Of course you can have dev time scratch environments to play with stuff without to support
[1] https://docs.datomic.com/on-prem/best-practices.html?search=...
[2] https://docs.datomic.com/on-prem/best-practices.html?search=...
"It's Maps All the Day Down"
Spend a lot of time, just learning how you (CRUD) map contents.
There will be enough time to tackle the other cases/tech (atoms, protocols etc) but until you get good at maps don't get bogged down by the other cool stuff.
In reality - its actually Trees all the way down. But, because you don't have proper structures in Clojure, one uses Maps when one should actually be using Trees.
Every now and then I try to check out a Lisp project and this is my reaction the moment I see the code: https://giphy.com/gifs/seinfeld-bye-jerry-106PwpLIIXJnXi
Don't look at the parens and don't stop at the superficial look :]
However I agree with you on some level. Lisp code can easily be written in a way that’s hard to read. Specifically because of nesting expression way more often than is comfortable for me to read. I much rather prefer let bindings and threading so most of the code reads from left to right.
Just know that almost no one STARTS off by liking Lisp-Syntax, but oh boy does it grow on you.
And, the non-Lisp languages tend to have more rat droppings => , ; . etc.
f is a function which takes two arguments, adds them, and returns the result.
Clojure: (def my-var ["hello" 123 (f 10 20)]) -> my-var: ["hello" 123 30]
([""()]) -> 8 noisy characters
JavaScript: const my_var = ["hello", 123, f(10, 20)]; -> myVar: ["hello", 123, 30]
=["",,(,)]; -> 11 noisy characters
Obviously this difference becomes more pronounced with longer argument lists or array element counts.
Regarding Python, I've always disliked its functional whitespace and OO inclination. Given its popularity, though, I'm clearly a minority!
TL;DR — to each their own.
And you get the bonus of being able to construct or parse code from within code, since the structure is so uniform and flat.
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.
For example, why not name "car" function as "first", "head" or "beginning"? Why not name "cdr" as "rest", "tail", "end" or "back"?
If anything, other languages are different for the sake of being different.
Btw, Clojure makes those exact changes you mention (first instead of car etc.)
roughly 25 years after Common Lisp introduced first,..,tenth, and rest
ANSI Common Lisp has first and rest as synonyms of car and cdr. Books from the middle 1980s on the then emerging Common Lisp already cover this.
It's like you're griping about an issue that was closed before CVS existed, let alone git.
car and cdr still exist because of backward compatibility and because they are good names for when cons cell structure is just arbitrary structure and not a list. The car is not always the first item of a list, and cdr is not always the continuation of a list. These words are deeply entrenched in the Lisp culture. The words have no confusing associations with anything else but the parts of a cons cell. I've not come across any "car" or "cdr" usage in computing anywhere, except Lisp-inspired jokes like in the "Locator/Identifier Separation Protocol". In the telecomm industry, CDR stands for "call detail record", but that's removed from programming language and data structuring.
Knuth defined some binary-cell tree structures in TAOCP. He used the words alink and blink (as in A link, B link). Those words are not bad.
It's good if the parts of a flexible data structure that programs use for representing all kinds of things have names that don't have any confusing associations. When you see those names, you know they are just literally about that structure, and you can see from how those words are used what the shape of the structure is.
Unless you carefully study the reactions of nonprogrammers, you are biased.
To a nonprogramming person, this is quite probably "different"
(p->arr[x].pfn(y)>>SHIFT)&MASKThe magic of S-Expr is like drug-addiction... someday you wakeup and realise... damnn I can't go without S-Expr in my daily-driver-languages :/
Yes I always tell ppl, sure you don't need to like LISP but as a serious CS professional, AT LEAST give it a real HONEST go! Then if you still don't like it, cool, move on !
There is an active and lively and long-lived LISP-Like community even today, there is a high probability there is something there.
YMMV :)
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 !
Alan Perlis