March 2, 2026 implementation meeting links
11 views
Skip to first unread message
Paolo Amoroso
Mar 2, 2026, 2:48:33 PMMar 2
to Medley Interlisp core
The links we shared in the March 2, 2026 implementation meeting:
--
Paolo Amoroso
Mar 3, 2026, 5:10:47 AMMar 3
to Medley Interlisp core
The likely reason he asked this Quora question to Alan Kay is François-René Rideau is writing "Lambda: the Ultimate Object - Object Orientation Elucidated". The book offers a theory of Object Orientation that it elucidates in simple terms on top of Functional Programming, with examples and code in Scheme.
pixel...@gmail.com
Mar 4, 2026, 1:52:30 AMMar 4
to Medley Interlisp core
I'm somewhat glad he's writing it...
OOP has become a "bad word" the last 5 or so years as newer programmers tend to favor data flattening and transformations in a map/filter/reduce style.
I've had discussions about OOP with competent programmers before and my counter is always "Ok, you say OOP is 'bad' but which notion of it"?
This is usually met with the C++ or JavaScript lineage of it. And then I go into CLOS and Smalltalk notions eventually dipping into implementing it in Scheme from nothing but lambda.
Without going into it too far, Clojure and Lisps descended from it outright reject OOP culturally favoring more poorly defined hash table blobs passed around 3rd party libraries.
My concern grows as this continues. Lisp should enable ANY paradigm the programmer sees fit to explore in his approach.
Historically we've seen Lisp OOP (In at least 6 forms LOOPS, CLOS, Flavors, SRFIs, Racket, EIEIO), we've seen Logic/Rules programming, we've seen Functional Programming.
Looking back to Scheme (a very minimal language), there are solid examples creating forms of objects with owned methods from simple closures and nothing more.
I think the Scheme example is particularly good because Scheme is essentially a camping trip in the woods with a pocket knife and hatchet.
You can draw an "object system" from the primordial pool of conses and lambdas. This is different from a Class system baked in.
This is a toy, it doesn't approach the depth of the examples in the book. Hopefully my comments are good-enough-p.
https://pastebin.com/D2UmpBji
I could probably do the same exercise with Interlisp currently - dipping into Common Lisp's lexical scope (FUNCTION would have also worked but alas the second argument is dropped now).
As a back of the napkin exercise, I did make a small example of OOP in Clojure adhering to the bizarre cultural rules of no mutation and no classes.
This is not a whitepaper grade demonstration but it was meant to make people feel a bit uncomfortable about their rejection of OOP as I made a pure Functional form following the proper dogma.
https://github.com/RyanBurnside/verboten
Sincerely,
Ryan
OOP has become a "bad word" the last 5 or so years as newer programmers tend to favor data flattening and transformations in a map/filter/reduce style.
I've had discussions about OOP with competent programmers before and my counter is always "Ok, you say OOP is 'bad' but which notion of it"?
This is usually met with the C++ or JavaScript lineage of it. And then I go into CLOS and Smalltalk notions eventually dipping into implementing it in Scheme from nothing but lambda.
Without going into it too far, Clojure and Lisps descended from it outright reject OOP culturally favoring more poorly defined hash table blobs passed around 3rd party libraries.
My concern grows as this continues. Lisp should enable ANY paradigm the programmer sees fit to explore in his approach.
Historically we've seen Lisp OOP (In at least 6 forms LOOPS, CLOS, Flavors, SRFIs, Racket, EIEIO), we've seen Logic/Rules programming, we've seen Functional Programming.
Looking back to Scheme (a very minimal language), there are solid examples creating forms of objects with owned methods from simple closures and nothing more.
I think the Scheme example is particularly good because Scheme is essentially a camping trip in the woods with a pocket knife and hatchet.
You can draw an "object system" from the primordial pool of conses and lambdas. This is different from a Class system baked in.
This is a toy, it doesn't approach the depth of the examples in the book. Hopefully my comments are good-enough-p.
https://pastebin.com/D2UmpBji
I could probably do the same exercise with Interlisp currently - dipping into Common Lisp's lexical scope (FUNCTION would have also worked but alas the second argument is dropped now).
As a back of the napkin exercise, I did make a small example of OOP in Clojure adhering to the bizarre cultural rules of no mutation and no classes.
This is not a whitepaper grade demonstration but it was meant to make people feel a bit uncomfortable about their rejection of OOP as I made a pure Functional form following the proper dogma.
https://github.com/RyanBurnside/verboten
Sincerely,
Ryan
Paolo Amoroso
Mar 4, 2026, 2:57:31 AMMar 4
to pixel...@gmail.com, Medley Interlisp core
I've also noticed a widespread rejection of OOP, often on the basis that it can be implemented with lower level constructs. Which is true in a kind of Turing completeness way, but I wonder why give up the nice syntactic sugar OOP languages and features offer. And Lisp is all about building such domain-specific languages.
--
You received this message because you are subscribed to the Google Groups "Medley Interlisp core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lispcore+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/lispcore/abb3b741-88da-4161-9625-addc20db333en%40googlegroups.com.
pixel...@gmail.com
Mar 4, 2026, 5:09:49 AMMar 4
to Medley Interlisp core
There's been a substantial uptick in Ocaml and Haskell and other strictly Functional Programming languages recently. I think they tend to reject OOP on the basis that it involves mutation of state internally. Having talked to a lot of FP purists many of them have the notion that state should be avoided as much as possible by having a program recur into itself and produce a new version with the data updated rather than have objects with data that gets "set". In idiomatic Clojure for example, you can't reset a value once defined you must recreate the entire form that contains it (this is optimized though). Clojure probably has more people from Haskell and Ocaml tradition than Common Lisp. They may also argue that objects aren't "composable" like functions are (think combinators). Yet we can design NEW systems in Lisp and challenge that assertion. So from what I see, FP is sold as a panacea and OOP is the enemy of immutability which is a tennant of modern FP. In fact that's a funny thing, in Emacs Lisp we see "OClosures" which are a hybrid, we see "funcallable classes" in CL, and in Smalltalk the blocks have properties of both object and function. So I would say their entire basis for rejection of OOP comes from FP language "best practices/limitation" and unfamiliarity with both Lisp history and the entire branch of OOP study. There's a real fear that a program with state becomes magically unmaintainable. I'd rather work in unopinionated languages that let me model how I see fit like most older Lisps.
Just my experience I suppose ...
Paolo Amoroso
Mar 4, 2026, 5:41:00 AMMar 4
to pixel...@gmail.com, Medley Interlisp core
I can understand the hesitation of FP practitioners, what I don't understand is the rejection of OOP by developers who work with more traditional stateful languages.
To view this discussion visit https://groups.google.com/d/msgid/lispcore/7e7f2a1d-f8c0-4cec-87ee-42ce212cbf64n%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages