"The thing you would try by default, works by default."

Ahh I've been meaning to make a daily habit of using nushell

These changes make it look very mature

Hello, what's this? A folder on my desktop labeled minikanren. I suppose some more things are about to fall into it. I read the first edition of the Reasoned Schemer a good, long while back. I wanted to love it, but the execution of the idea left something to be desired, I recall.

Might I recommend this tiniest, most digestible distillate? μKanren implements the core of the system in 40 lines of scheme. ❤

http://webyrd.net/scheme-2013/papers/HemannMuKanren2013.pdf

Thank you, this is the paper I'd (tried to) read a few years ago and spent several hours yesterday trying to remember. I'd forgotten that it's 'micro', not 'mini'.

Jack Rusher Are λ_g and λ_$ just regular lambdas? Are the suffixes just for documentation?

Is the terminology of "serious calls" just something in this paper, or more broadly understood?

Getting a complete strategy from an incomplete one by swapping two tokens = 🤯

Kartik Agaram Yeah, the stream/goal designations are for us, not the computer. So far as I'm aware, the "serious" terminology was coined in Byrd's PhD.

I don't think so. Let me guess before looking: object capabilities. And nope. It's about "service abstractions" sounds like encapsulation. What did you find compelling?

(I find the whole topic this way)

"different object-oriented implementations of a type can interoperate" as the big idea presented here – interesting

I mean, this old essay of mine uses the same kernel VFS example to make the point. It's all well-trodden ground for old timers, which might be why I'm so bored with these arguments by this stage. 😜

https://jackrusher.com/journal/on-object-orientation.html

I have so many thoughts, I should probably not take the time to write them all here. Let me just say a few things. First I love Cooks definition of object oriented programming. Making a version of OO that does not use mutable state at all is really interesting. After reading his paper I went and played with my own little Cookesque OO language written as a dsl in clojure https://github.com/jimmyhmiller/PlayGround/blob/master/oop.clj

But even though I really like what Cook has to say, I really don’t like this paper. First I think that these sorts of “service abstractions” are bad. They in my view almost always lead to unreadable messes of programs where understanding the behavior requires following several layers of indirection just to get at something that could have been stated very directly.

But further, I don’t think the extensibility they want can only be achieved through these sorts of abstractions. I think react and its move away from classes is a great example of this. React is exactly the sort of framework they are talking about and yet, you can do full extensibility without needing these sorts of abstractions (functional react + hooks to be clear).

Now just to give the caveats, I’m not saying there is never a use case for service abstraction. But what I am saying is if I could get rid of one technique that I see used over and over again in application code bases, that would be it. Yes, objects can do the things the author described, but should we really do those things? Most of the time no.