Fork me on GitHub

Good morning


Good Morning!


we're using juxt/bidi for our router atm, and i really like the extra abilities you get for free when your routes are a datastructure - to add interceptors to all handlers below some node in the route tree for example


my main concern is getting docs for free, whether that's openapi/swagger or whatnot


but you can do that with both specc'd functions or datastructures for your router so that's about where i get off the strong opinion bus


I have used bidi too. Now, for some reason try to get every flow problem into monadic form. But my Clojure have always been Haskell-ish. Anyway, I have been in touch with a big part of my team, also people here and everyone seems to prefer maps over functions for routing. My thinking was that action must be represented by code, immutable truths by data. Routing is often quite dynamic (I have developed routes that were translated to various languages; read from SQL; cached in Redis) and pure regex-like approach is something I see as leaky abstraction.


I'm still really confused :). Bidi is basically a linear prefix matching system, with defined meanings for interpreting data as a prefix match. I'd bet that functions can be used with bidi, but it's more convenient to match with a string. But I don't know why I'd want to use functions, that's very unfamiliar to me. Reitits benchmarks from optimizing pure data into a trie are impressive.


As I say, most people prefer maps over functions. In fact, I am the only Clj dev I know who prefers fns over data for that.


I don't like the word prefer. I get a few benefits from data route matching. I don't feel the need for functions.


We had interesting discussion connected with that. Lisps blur line between data and code. Does it mean we should represent more code-like (things representing action) as data, or should we represent state of the world (data) as code?


I have used the bidi protocols for a few esoteric things, which reitit couldn't have done so I appreciate that fallback.


All lisps (and overall functional languages) have awesome capabilities to work with data structures. This is a strong case for them. But if devs overreach in this, they will end up implementing own Lisp in data structures.