Clojurians Log v2

Since twitter isn't the most conducive forum for long form discussion I'll bring it over here

I think the coffee grinder sort of takes us back from the benefits of functional programming

They reintroduce state. Instead of simplifying it via composition, passing around a context map is equivalent for creating an ad-hoc namespace for every incoming message and defing everything in there

it's the most in-place procedural solution

See Out Of The Tarpit section 5.2.3

http://curtclifton.net/papers/MoseleyMarks06a.pdf

Super interesting! But what would be the alternative? You mentioned: > simplifying it via composition Do you mean having encapsulated (possibly stateful) components with that? Or how could purely functional composition solve state management? In the context of the paper to me it does not exactly read like it is a bad thing to use this pattern though. It’s more about being aware of the trade-offs. It is not a solution to every problem and you might still want to have stateful components in your bigger architecture.

I didn't know the tarpit referenced this. This is known as "stamp coupling" and "God object".

In a way it's inescapable because you always need some state in your program otherwise it doesn't do anything. I think the problems begin where you do something like chain 3 functions (f g h) and f shoves in to the map some key k which only h uses afterwards. Mentally, the code becomes an elaborate game of catch, where you have to realize why some field was set up only for a function 2 (or 30) calls down the line uses. If f modifies the collection in such a way that only h will use it afterwards and that field will be subsequently ignored, f and h should be composed, and the complexity introduced disappears. It's similar to composing typed functions for A ->B with B -> C creating a new function with type A -> C. You don't need to know about the intermediate values and can use the function "as is"

> god object Good name. Makes you consider your choices in life 🙂

Yes, there is definitely a cost/tradeoff with this approach. Still, I think Clojure’s dynamic typing with open map types and namespaced keys make these kind of context objects a very attractive tool 🙂

Attractive sounds like a synonym for "easy". It won't make you code simple, though 😉

I'm putting out a new release of lambdaisland/glogi {:mvn/version "0.0-36"}, adds a spy macro as suggested here, and fixes an issue where lambdaisland.glogi.console was always using console.log, instead of using the most appropriate method (`warn`, error, etc)

looks like this

(log/spy (+ 1 1)) ;;=> 2

[your.ns] {:spy (+ 1 1), :=> 2, :line 1}

Hi, how do you start logging a certain channel from this Slack instance so that the logs are captured in clojurians-log ? I seem to remember that you have to invite the bot, but can’t dig up the bot’s name now. If I get the answer to the above, I’ll add it somewhere in the repo (I know that about page is being worked on). Thanks

@dotemacs @logbot

Thanks @dominicm and is the process to start the logging just inviting the logbot into the channel?

conversation settings -> add an app?

I think so

this worked for another channel, fwiw

Why I asked in the first place: because I saw that there isn’t any logs for #interceptors channel. I’ve invited the user and now I can see that the Log Bot is there. But I didn’t check under Apps of that channel before. So I’m not sure if it was my invite that got the Log Bot into the channel or was Log Bot there all along… I can’t see any logs here https://clojurians-log.clojureverse.org/interceptors , so I’m assuming that no logging was started up until just now?

No logging starts until invited and then you talk

can confirm all of the above, just inviting @logbot should be enough

note that logs don't update instantly

the recommended channel for this kind of stuff is #community-development btw

I would definitely not advocate that the whole system should be one giant map. Having well encapsulated components with their own state management is a crucial architectural building block for software. That said, I also see the value of coffee grinders like for example interceptors to solve specific problems within components. But of course one can take it too far by trying to solve all problems with the same solution :)