@dominicm could you use a compressed trie? i.e. to match foo|bar|baz: {"f" {"o" {"o" ::match}}, "b" {"a" {"r" ::match", "z" ::match}}}

(get-in trie (map str (into [] "foo"))) => ::match (get-in trie (map str (into [] "food"))) => nil

I'd like to remove an item from a set.... this seems awkard. (into #{} (remove #{3} #{1 3 4}))

(clojure.set/difference #{1 2 3} #{3})

what about disj ?

@bja Thanks... also (disj #{1 3 4} 3)

interesting, set/difference is implemented in terms of disj, such that if you want to remove a single element, you might as well always use disj

actually, my bigger problem is changing stuff in a large atom (reagent) ... I keep writting lots of little functions to navigate different parts of the tree. I know about specter (but I've not taken learning it on yet) ... and I use update-in and assoc-in etc... but I wonder if there isnt an easier way to update these structures....

@bherrmann when I last checked, there was an idea to use something called a cursor in reagent

particularly when the types of the objects in the tree change, combinations of vectors, sets, lists

and you want to modifiy their contents but not accidently change the vector and or set into a list... etc...

so that when you passed the state to your child, they got a cursor that was a view onto the Ratom that could avoid some of the nested manipulation

ah, for that I'd probably define helpers (instead of using assoc-in/etc directly) and then use truss/schema/spec to make assertions

instead of (update-in user-ratom [:users] conj {:user "brandon}) I'd define (defn add-user [ratom user] (update-in ratom [:users] conj {:user "brandon}))

so that if you wanted validation, you could do it

the #reagent channel probably has more advice from people who use the library more often than I do (once every few weeks)

@bja Thx!

@dominicm can you expand on how automat was too slow?

I would have expected "too much of a pain to adapt to standard regex behavior", but not "too slow"

thought i'd share a couple thoughts on programming in general, see what you guys think? I think when writing in a programming language, we should strive to be similar to mathematical syntax, because it maps mathematical concepts to symbols directly. so what we should do is write code that maps directly to our concepts, so that it's clear to see the relationship between them

@cjhowe can you give an example of this? and how it is achieved/not achieved in existing PLs?

ah, i mean, it is achieved in languages based on predicate logic and lambda calculus, like lisp

i'm saying we should do that in the application domain as well, trying to make sure the code is a direct mapping to our conceptual understanding of the application domain

i guess i'm just restating "write declarative code"

oh well

perhaps, but that's also the problem. Reality very rarely maps to clean mathematical concepts.

i mean, aren't other engineering fields pretty good at doing that already? they tend to do it more methodically, so why can't we?

In some projects I've worked on, the Project Manager's overview of what the current "business practices" are, sounds like a game of Fizbin

you mean APL

@cjhowe sounds like you have never seen a physicist doing math lol

Since this is off-topic, actual footage of a client discussing his business needs with me: https://www.youtube.com/watch?v=v77SF4TFUoM

But back on topic, that's the problem, real life is messy, and most of the time the work I do revolves around conversions of data from format A to format B. Most of that work is around complexity management. One way to manage that complexity is through declarative interfaces, so on that point I agree.

But declarative systems also come with drawbacks. One such drawback is that if you define a declarative language in which to express your application, you've now limited yourself to the subset of solutions that language can express.

lein

😄

not knocking it. its quite nice for straightforward things that it has contemplated

but at work our project.clj file that manages different assets for different targets is creative

okay, so like, i guess the clojure community tends to think of declarative as "just data", but it's not quite the same thing, right? like, you can write declarative lisp code

Right, or back in the day I used to enjoy reading about Makefiles vs Scons (scons being a build system with the full power of Python available)

That's actually a problem with the community, imo. Just data often insinuates a "Data DSL" where somewhere you have an interpreter that acts on the data. The question is then "how extensible is the data DSL" and "how hard will it be for me to learn it".

Which boils down to a question of data modeling, which is a whole other ball of wax.

Another funny side to all that, is that lisp code is data. So you could say all of Lisp is a "Data DSL".

like XML scripting languages

lol

Yep, I've always been tempted to write a Clojure -> XML scripting language hack as a joke.

yeah, well, that's one reason why lisp is generally pretty declarative, right?

it can be, but it's not always that way.

For example, compare get-in which is rather declarative, to cond which is not.

hmm, yeah, i guess that goes back to, it's really not easy to make a perfect mapping from reality

we have things like mutability and cond to work around situations where the mapping is very messy

however, i could say we are at least striving towards mapping real-world concepts to programming languages, even if it is an impossible goal

should it be the opposite though? solving real work problems by bringing languages closer to reality?

I think that's what immutable data is all about, facts don't change over time, we just have new facts, and that's what immutable data is all about.