Fork me on GitHub
Oliver George04:11:31

How well do you know your chrome console utilities...

đź‘Ť 1
Oliver George04:11:46

debug(function) and monitor(function) are news to me


I’m looking for the name of a concept, it is related to debouncing and throttling, but not quite the same: Imagine you have some pure function slow which is slow, and you’re in a multi threaded environment, so multiple threads can call slow with the same arguments, thus producing the same result, concurrently. What I want to ensure is that if we have a thread one which has already called slow with args args, a thread two, calling slow with args args is kept waiting until slow has returned a value for thread one, and gets the same return value, ie we do the slow computation once, but both threads get an answer. AFAIC memoization will not work here, because it won’t block caller two. So, not really looking for an implementation, but rather what something like this is called?


So the problem I’m describing is this:

Ben Sless10:11:08

Yeah, wanted to say it sounds like a thunk

Ben Sless10:11:19

If you memoize the function and return a delay you're golden. If the arguments are complex memoization might have its own overhead


Of course I didn’t tell the whole story. This should of course work across several servers, so basically distributed. Searching for “distributed promise” gave me this


Which is basically what I implemented in Clojure.


> but rather what something like this is called? perhaps 'grabbing a distributed lock'? IIRC it's what I've seen used commonly/informally whenever a computation is protected by a redis lock


Don't know of an official name for this, but feels like a specialization of memoize? Compute once memoize? Optimized memoize? Queued compute memoize? Distributed memoize?

Sam Ritchie14:11:19

This is the right thing to do on one machine!

Sam Ritchie14:11:15

Oh whoops thought that would be threaded. I meant a cache with “delay” values. Everyone stampedes and blocks on reading the delay created and read by the initial caller


“dataloader” is a popular JS library that solves this problem, and many other ecosystems have copied it


I think of it just like memoization of a function that returns a promise/future with the result of the computation, rather than the result itself


Has anybody stumbled on a decent enough name yet @U04V5VAUN? Cost effective memoize? Locking memoize? Next-gen memoize? (I seem to like including “memoize”).

Sam Ritchie18:11:39

async-memoize perhaps?

Ben Sless19:11:46

It's clearly a thunk / delay, so memoized-delay is legit.

(defn memoized-delay [f] (memoize (fn [& args] (delay (apply f args)))))

Ben Sless19:11:04

Keep in mind that if args are big then you'll pay a cost on the lookup, so a specialized implementation might be required


I think you often want a freshness check to see if you should return the cached delay or compute a new one


e.g. like dataloader, that ensures requests (but could also be computations) over a period of time aren’t done twice, but after some lag evicts the cache


and allows a new request for the same args to be started


if your computation is idempotent then the above is fine, though there’s no GC

Sam Ritchie20:11:25

Memoized-delay is a bit odd since you are not returning a delay

Sam Ritchie20:11:31

You are augmenting a function to both be memoized and return a delay, so you want a verb


Hey guys, anyone know if anyone's attempted to write Eclipse plugins in Clojure? I really like DBeaver and was thinking I could write an Execution Plan visualizer or something


Is there a code city generator for clojure? ( )


Haven’t seen these before. Really cool Hope there is :star-struck:

Dimitar Uzunov13:11:29 - you may want to try this, it definitely supports clojure (it is also written in it).


Yea, I think I saw a presetnation someone from codescene did... It is worth checking out... although Im partial to seeing a city style layout, as that seems to make sense to me.


I wonder if he's heard of clojure


In very broad terms, one could say that rich 's talk what focused on 'micro' complexity e.g. this defn is complected, this codebase is complected. while the article is focused on 'macro' complexity i.e. our systems are excessively distributed and heterogeneous now


Personally I've seen plently of professional clojure developers push for macro complexity, awarely or not. So these are IMO quite unrelated, clojure won't automatically solve your problems or make you think better