Fork me on GitHub

Well, “open source is/is not for you” made an appearance in the CIDER talk, which is why I put it under controversial


But it was also very entertaining and well prepared, as well as informative. Would watch again ;)


Cool. I'll make sure to watch it, once it hits the web.


Watching Yehonathan's OO/FP talk now...


...good talk! (but not particularly novel -- Amit Rathore showed off almost identical code in the workshop where I learned Clojure back in 2010 -- it's just a good example of Clojure's power)


Agreed. I guess it’s fine to repeat these things to new audiences. For me it felt more pitched at beginners, rather than looking at more interesting things like implementing CLOS like abstractions etc.


was it a variant of the 'implement OO in scheme' thing?


to me it was “reinvent javascript prototype-based oo” but ¯\(ツ)


I don’t think every talk needs to be novel; it’s just that there’s a good reason people abandoned this style of coding. Also, imo it’s incompatible with the message passing paradigm. Also, that is not what message passing is.


will have a read 👍


there's some people very keen about DDD at work, and every time I mention FP or FP patterns/practice it always gets hijacked by 'DDD in FP' discussions... that's kinda how I feel about objects, like, orthogonal to the point of a deliberately completely different paradigm


hmmm that thread is really interesting, esp the point about erlang


vigorous nodding


I hear a lot about how Kay style OOP is best embodied in Erlang, and superficially that’s true as Erlang’s process model is based entirely on message passing. However in practice I always thought Erlang was a pretty terrible OOP (or functional) language.


I’m not saying Erlang is a terrible language. It’s just in my mind not a particularly good functional or OOP one. In particular I always found Erlang to suffer a lot from a lack of good first class abstractions… i.e. processes (which if you’re to believe the message-passing OOP analogy are erlang’s objects) are closed case statements, which are inextensible; and there’s no real language level support for polymorphism. The closest thing Erlang has to polymorphism are really OTP behaviours; which are essentially just callbacks. I was really keen on Erlang about 12 or 13 years ago; to the point that I applied for and got offered a job at an Erlang consultancy; which in the end I declined. Shortly after I discovered clojure - though did do some professional work extending ejabberd for a startup. ejabberd’s code was almost impossible to extend without essentially copy/pasting a thousand+ of lines of code. This experience led me to conclude that Rich essentially nailed it with many of the ideas in clojure. In particular how atoms/`agents`/etc are more extensible than actors; and how multimethods and protocols are superior to case statements. Pattern matching is of course quite cool; but again I think Rich has it right in decomplecting destructuring from conditionals.


Though I’m still eagerly awaiting David Nolen implementing predicate dispatch in Clojure 🙂. Though given his radio silence on that issue for many years one has to assume it’s incredibly hard to do efficiently in an extensible system like clojure.


Well, the point was message passing rather than “is it everything we expect from OOP these days”. But if you’d rather some other example, I guess you could say CORBA was a message passing paradigm. Or microservices with some kind of central discovery service. (What would that make of serverless? 😄 )


hehe yes we’re doomed to reinvent the past. I did a bit of CORBA when I worked as an intern at NCR many years ago. Though to my mind CORBA was more RPC / remote method calling rather than message passing. The difference being that in RPC you’re blocking on a response by default. However I think you’re right too; as Kay’s smalltalk messages are synchronous too. I wonder if the key difference comes from their starting points. i.e. CORBA really had its roots in C++ (though it was intended to be language agnostic) so more the mainstream OOP tradition, rather than the smalltalk message-passing one? This feels like a pretty wooly distinction though… Contrasted to Erlang where message passing is fire and forget, and you have to build RPC if you need it; (it’s a short 1 or 2 liner though). I feel like this difference is important though; probably because you can build RPC efficiently on message passing; but building message passing on RPC is inefficient.


I did Jini for many years. That was a pretty cool distributed systems technology that sadly never took off.


@rickmoynihan Didn't someone do it recently?


not efficiently, but


There was a lot of talk on this about 8 years ago. Rich was very keen to add it to clojure in the early days.


@danieleneal: there was a claim on the mailing list. I took a brief look at it, and I was skeptical. The implementation seemed far too small to be correct… but I could be completely wrong about that.


ah yeah, that's what I was thinking of


it doesn't do any of the clever stuff they were talking about, I think


that would make it efficient


IIRC ordering clauses is very important; for correctness and efficiency… and I don’t recall seeing anything that would do that — but I didn’t really look at it. I was quite excited to see the thread revived though.


Anyway I’m no authority on this. Don’t let my comments dissuade any of you from looking at it 🙂


Open predicate dispatch seems to require a relational system in order to allow for efficiencies.


Which is exactly where David Nolen and core.logic came in…


when I asked rich about it at the conj he said something along the lines of "well, we have datomic's datalog which I think covers most that area now"


you were asking rich about predicate dispatch? was that at the conj in 2017?


I sometimes find myself wanting an open predicate system, like multimethods. But not often enough.


@maleghast is presenting at ClojureX right now and gushing about our wonderful community

❤️ 32

It was great to meet @maleghast last week at Conj!


I ❤️ this channel


Thanks for the chat last night at ClojureX @otfrom - let's arrange a date for having a chat about all things remote.