Fork me on GitHub
#off-topic
<
2017-09-11
>
bja14:09:55

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

dominicm17:09:29

Perhaps. I'll have to think on it. Good idea.

dominicm17:09:26

Actually, not quite. I want behaviour like ".+" which can't be done with this.

bja16:09:14

If you want foo.+ then you would just index "foo" and accept a match. the trick would be foo.?$ which I guess could be a custom rule involving matching foo and then allowing one more character before resetting the search

bja14:09:45

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

bherrmann14:09:04

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

bja14:09:28

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

leonoel14:09:51

what about disj ?

bherrmann14:09:52

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

bja14:09:10

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

bherrmann14:09:36

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....

bja14:09:07

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

bherrmann14:09:19

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

bherrmann14:09:51

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

bja14:09:57

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

bja14:09:19

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

bja14:09:11

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}))

bja14:09:26

so that if you wanted validation, you could do it

bja14:09:57

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

ztellman17:09:22

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

dominicm17:09:01

@U066UJ2KE I didn't dig in (and maybe I should!) But a compiled jvm fsm was taking ~110ms to match a fsm of foo

dominicm17:09:23

Sorry, I just realised that's also ambiguous (and wrong). I used 51 strings, where one was a match of foo. The fsm was character to character. And I passed in the string to match on.

dominicm17:09:56

I think I wrote a reducer that reduced over the state and if it hit reject it did reduced

dominicm19:09:32

Maybe the expensive part was seq of strings or something.

ztellman19:09:06

that sounds very wrong, typical time to process a single input should be ~5ns

ztellman19:09:20

no big deal if you found a way that works for you, though

dominicm19:09:08

No, I've not found something I can use yet. I'll do some more experimentation if something is clearly wrong, thanks.

ztellman20:09:07

if you can provide a minimal example of this performance issue, happy to take a look

dominicm07:09:49

Might have something reproducible. It seems that instead of 5ns, I'm getting 500ns.

dominicm07:09:59

Will do the rest on github 🙂

ztellman17:09:41

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

cjhowe20:09:38

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

hmaurer21:09:41

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

cjhowe21:09:12

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

cjhowe21:09:34

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

cjhowe21:09:48

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

tbaldridge21:09:41

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

cjhowe21:09:30

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?

tbaldridge21:09:52

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

chris21:09:53

you mean APL

hmaurer21:09:02

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

tbaldridge21:09:39

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

tbaldridge21:09:00

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.

tbaldridge21:09:41

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.

dpsutton21:09:12

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

dpsutton21:09:34

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

cjhowe21:09:01

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

tbaldridge21:09:25

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)

tbaldridge21:09:39

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".

tbaldridge21:09:05

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

tbaldridge21:09:00

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

cjhowe21:09:24

like XML scripting languages

tbaldridge21:09:49

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

cjhowe21:09:17

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

tbaldridge21:09:23

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

tbaldridge21:09:48

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

cjhowe21:09:12

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

cjhowe21:09:42

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

cjhowe21:09:48

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

tbaldridge21:09:32

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

tbaldridge21:09:56

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.