This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-02-17
Channels
- # adventofcode (3)
- # announcements (1)
- # babashka (25)
- # beginners (55)
- # calva (12)
- # cider (40)
- # clj-kondo (13)
- # clojure-australia (2)
- # clojure-dev (11)
- # clojure-europe (67)
- # clojure-france (6)
- # clojure-nl (16)
- # clojure-uk (9)
- # clojuredesign-podcast (9)
- # clojurescript (17)
- # conjure (7)
- # cursive (3)
- # datomic (3)
- # emacs (8)
- # figwheel-main (7)
- # fulcro (21)
- # google-cloud (21)
- # graphql (8)
- # helix (1)
- # honeysql (32)
- # instaparse (2)
- # jobs (2)
- # jobs-discuss (2)
- # meander (80)
- # mount (1)
- # off-topic (25)
- # pathom (31)
- # polylith (1)
- # rdf (24)
- # re-frame (21)
- # reagent (29)
- # releases (1)
- # remote-jobs (1)
- # shadow-cljs (16)
- # slack-help (6)
- # sql (5)
- # tools-deps (23)
- # uncomplicate (2)
- # wasm (2)
- # xtdb (4)
@theller has checked the repo and thinks the problem must be somewhere on the meander side
Sorry I didn't get a chance to check this last night. Will today.
Everyone, eventually this message will vanish but apart from bug fixes that people mention, I’m no longer working on epsilon
anymore. I’m only working on zeta
from here on out and have been in this mode for a little while.
So far, things are looking good on the zeta
branch. There is a new design at work which has, overall, lead to reduction pretty big reduction in code. There is still a lot to do and test, however.
Not yet
A lot of progress has been made. Essentially, the whole thing has been rewritten to accommodate the things people have asked for such as explanations, being able to interpret matching/rewriting, as well as a few things I’ve wanted.
What I did was abstract the overlapping parts of compilation and interpretation such that the code which builds an interpreter for a pattern can also build a compiler for it.
Also, both sides of rewriting use the same abstraction which means that both interpreters and compilers can make more aggressive optimizations.
Can I read something about the decisions and the idea behind the meander? Key words will suffice, I can google myself if I know what to look for
I'm too weak for most ingenius things, but meander combines cool solutions with really simple use
I’m by no means a genius. I have to look stuff up all the time. I can’t remember anything. And I certainly won’t be solving any deep mathematical problems before I die.
To a dog, all humans are magicians because they can open doors. As I read @jimmy's blog, this is how I felt
But I think programming in most of its currently formulations hinders interesting creative efforts, experimentation, and creates social problems.
There’s definitely a lot of different things coming together in meander. A big one is term rewriting. https://vimeo.com/155448425 Lot’s of stuff borrowed from Racket, particularly their pattern matching https://docs.racket-lang.org/reference/match.html There are a bunch of different influences that @noprompt synthesized together and made something fairly unique. But those should be some good jumping off points.
usually the hardest part is synthesizing the knowledge. everyone has the same elements, but not everyone can make something unique out of it
Some of my biggest influences are • TXL https://en.wikipedia.org/wiki/TXL_(programming_language) • Maude https://en.wikipedia.org/wiki/Maude_system • Datalog • miniKanren • Regular Expression • Definite Clause Grammars https://en.wikipedia.org/wiki/Definite_clause_grammar • Operational semantics https://en.wikipedia.org/wiki/Operational_semantics
I will let people know when I feel comfortable with them playing with the zeta
branch the first moment I get that feeling.
The most important thing for me on this branch is making sure the experience is smooth and performant. And when it is not I would like it to be very convenient for people to either solve their own problems or report issues with the explanation feature.
Pretty soon it will generate code that ensures thats calls to functions are made exactly once.
as of today, meander can successfully replace datascript. pull without reverse lookup is 50 loc and is faster 10x, q is 40 loc and we have working datalog, which even looks identical. For simple queries it is slower 5x, but for longer ones it is faster ~2x.
Asami is very fast. AFAIK sure it is faster than datascript and most certainly would be faster than Meander for its particular niche.
But also, Paula Gearon, is an expert in the space. She’s on our team at Cisco and we use Asami heavily.
@noprompt May I ask do your team mainly use asami in the backend or in the frontend? I have been heard of asami for a long time but haven't yet evaluated it.
Indirectly means that, on the front end, our consumers not using directly but, rather, going through an API.
If it's not a secret, what do you use on the front end? CLJS? TS? JS? If CLJS, then reagent? re-frame? fulcro?
On our team, not especially. We work with a data model that is well defined and that gets loaded pretty quickly into asami. In some places we use meander, and in others, when nothing seems to work well, we turn to algorithms.
IOW there’s pressure to make it go faster and she’s more than happy to accommodate us. 🙂
asami looks great, but I think it works poorly in combination with reagent and re-frame
This is an idea that has been on my mind, but the language barrier doesn't seem to help me convey it
when I finish it and I think it's not a junk, I'll probably post it as one of the uses of meander