Fork me on GitHub
#off-topic
<
2020-11-13
>
dominicm04:11:21

https://ferd.ca/you-reap-what-you-code.html this is a really nice article. I can see many overlaps with Clojure-y things here (and some that are just things I learned through Clojure, rather than being actual Clojurey things) > If you're not able to replace everything, consider framing things as adding it to your system rather than replacing. It's something you add to your stack. This framing is going to change the approach you have in terms of teaching, maintenance, and in terms of pretty much everything that you have to care about so you avoid the common trap of deprecating a piece of critical technology with nothing to replace it. If you can replace a piece of technology then do it, but if you can't, don't fool yourself. Assume the cost of keeping things going.

3
telekid20:11:28

I just read about cloudflare's Durable Objects (https://blog.cloudflare.com/introducing-workers-durable-objects/) – they seem very cool. It would be interesting to create an IRef-able based on this.

noisesmith21:11:28

it's really hard to do transaction safe refs like clojure has with distributed state

noisesmith21:11:08

actors are much messier, but they are a better fit as an abstraction over distributed state

hiredman22:11:34

nah, atom like constructs using compare and set like operations are very doable in distributed settings

emccue22:11:11

IRef is kinda a boring interface in some ways

hiredman22:11:32

IAtom is the thing

emccue22:11:04

more or less just IDeref with callbacks

emccue22:11:25

and IDeref just lets you use @ to get the current state

emccue22:11:52

so its not as if there is some grand abstraction that this can fit under right now

hiredman22:11:01

IRef is all stuff I don't care about or use often if at all (validators, watches, etc)

noisesmith22:11:05

I thought they specifically meant IRef - I agree that atom is doable, ref reaches for a lot more

hiredman22:11:14

IAtom is the good stuff

borkdude22:11:59

I also like IAtom2, the sequel

emccue22:11:01

Apparently IAtom doesn't extend IDeref

emccue22:11:14

oh god the what?

emccue22:11:32

why does this exist

borkdude22:11:42

it's for swap-vals, etc.

noisesmith22:11:48

@emccue clojure interfaces tend to work by composition not inheritence

dominicm22:11:50

I did not expect that to be real

emccue22:11:47

The "woulda been nice to have had default methods" interface

emccue22:11:31

Shopping cart: An online storefront could track a user's shopping cart in an object. The rest of the storefront could be served as a fully static web site. Cloudflare will automatically host the cart object close to the end user, minimizing latency.
    Game server: A multiplayer game could track the state of a match in an object, hosted on the edge close to the players.
    IoT coordination: Devices within a family's house could coordinate through an object, avoiding the need to talk to distant servers.
    Social feeds: Each user could have a Durable Object that aggregates their subscriptions.
    Comment/chat widgets: A web site that is otherwise static content can add a comment widget or even a live chat widget on individual articles. Each article would use a separate Durable Object to coordinate. This way the origin server can focus on static content only.

emccue22:11:52

their use cases for this are interesting

emccue22:11:15

its a mix between "per user caching" and "you can emulate live view!"

andy.fingerhut22:11:16

And I believe also the "go to some lengths to avoid breaking any existing 3rd party code that extended IAtom before" approach.

borkdude22:11:02

@andy.fingerhut I don't think adding methods to interfaces breaks Clojure code, only Java I think right?

borkdude22:11:22

barring aot

emccue22:11:25

eh, clojure being dynamic means someone has dug into every corner of the internals

emccue22:11:36

and AOT is still considered afaik

hiredman22:11:50

it doesn't break java code, it breaks the java compiler

andy.fingerhut22:11:59

Not sure -- couldn't it break someone who used deftype to implement IAtom, but not the new methods in IAtom2?

borkdude22:11:19

@andy.fingerhut I think that keeps working, since you don't have to implement every method

emccue22:11:21

I think you are able to leave off methods and it will just crash at runtime

hiredman22:11:26

deftype and the jvm itself are fine with missing methods for interfaces

hiredman22:11:44

javac tends to complain

borkdude22:11:04

that's what I meant with breaking Java code (for which you typically use javac to compile)

hiredman22:11:52

the java is source compatibility and java binary compatibility

borkdude22:11:55

I guess it's nice that it's backwards compatible, although I don't know a lot of examples in the wild that implement IAtom in Java. There could be.

andy.fingerhut22:11:06

They don't have to be open source, of course.

telekid22:11:18

This conversation brings up a common issue I have when thinking about Clojure interfaces – namely, which one do I want and what does it do?

telekid22:11:08

Are there any good resources out there that go over Clojure core protocols and interfaces?

telekid22:11:42

This diagram is great

telekid22:11:50

could probably use an update though πŸ˜†

andy.fingerhut11:11:30

@him I did a little bit of hacking in order to generate an updated figure for Clojure 1.10.1 here: https://github.com/jafingerhut/clojure-classes/blob/master/generate/graph-1.10.1.pdf

πŸ‘ 6
sogaiu12:11:06

may be i should print out a poster-size version and put it on my wall πŸ™‚

borkdude12:11:46

or we should make a game out of this: given an object, visit all the implemented interfaces as quickly as possible!

sogaiu12:11:45

lol -- gamification at work i guess :)

sogaiu12:11:28

this reminds me a bit of: https://gist.github.com/ghoseb/2049970 it was in an old talk by ghoseb

sogaiu12:11:10

it was about deftype including an example: https://www.youtube.com/watch?v=iBUthApQQw4

andy.fingerhut01:11:46

I added a comment to to the clojure-site issue here with the latest auto-generated graphs: https://github.com/clojure/clojure-site/issues/17

πŸ‘ 6
andy.fingerhut06:11:14

I did some more hacking on that code, and now there are instructions in the README to generate such a graph from the REPL, but maybe more useful than generating the fairly large graphs that it does by default, is that you can give it a list of one or more classes as input, and it will generate and draw the graph for only those classes and the superclasses (and interfaces they implement), not for all Clojure classes. Smaller graphs can be useful when you want to focus on part of the implementation. You can also use the code from within your own project, in case you want to make drawings for classes outside of Clojure's.

noisesmith22:11:34

@him as an exploratory technique, I've looked at (supers (class x)) to see all the clojure interfaces something implements

noisesmith22:11:54

then look at the methods defined by each interface to see which aspect of its behavior comes from each

borkdude22:11:00

Also there's this issue at the clojure-site: https://github.com/clojure/clojure-site/issues/17

borkdude22:11:35

I usually just browse the code on github and ascend upwards until I find what I need

alexmiller22:11:53

There a whole section in Clojure Applied that covers this fyi

alexmiller22:11:10

(and the ebook will be 40% off over Thanksgiving fyi)

borkdude22:11:40

this is the second edition right? I think I only have the first one

alexmiller22:11:04

there's only one edition

alexmiller22:11:13

if you've got the 2nd, please send it to me :)

πŸ˜„ 12
dpsutton22:11:48

They aren’t queryable through cljs.repl/doc and apropos right?

borkdude22:11:44

Github now has some code navigation features for Java code, which should make navigating through the interfaces a bit easier

dominicm23:11:40

http://sr.ht allows you to upload your own :) I've been wanting to write a clojure thing for it that uses kondo to allow navigation of clojure code on http://sr.ht