9 ms·
Common Lisp Object System (CLOS)
- bradrn 4y agoAlan Kay’s immortal quote about OOP: > OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them. [http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...] His reference to ‘LISP’ is, of course, referring to CLOS.
- ngcc_hk 4y agoAnd the message idea live on objective c and lisp, but not the other c++ system.
- signa11 4y agodon’t forget erlang !
- mikelevins 4y agoMaybe, though Alan Kay is certainly familiar with other object-oriented programming systems for Lisp that predate the design of CLOS.
- phtrivier 4y agoI bet Erlang/OTP also fits (which the added niceties of potentially distributing the object graph.)
- deckard1 4y ago> His reference to ‘LISP’ is, of course, referring to CLOS. Definitely not. The all-caps "LISP" should be the strongest hint, but he name drops McCarthy and Carl Hewitt. McCarthy's LISP didn't have closures, so I'm thinking Alan is referring to something closer to Scheme. Which might make sense as Scheme is based on ideas from Hewitt (actors, message passing, etc.). But Alan isn't being terribly specific. You have to understand there are thousands of different "LISP" systems in the world. Many of which are just in some thesis or white paper.
- bradrn 4y agoHmm, this is interesting. Rereading that post, it looks to me like McCarthy and Hewitt are mentioned as influences rather than a manifestation of ‘OOP’ as such, and I can’t quite think of any OOP system in Lisp he could be referring to other than CLOS, but then again I don’t know sufficiently much about this area to be sure either way.
- arunix 4y agoThat reminded me of Peter Norvig's comment: > Depending on your definition, CLOS is or is not object-oriented. It doesn't support encapsulation. Lack of encapsulation would preclude the protection and hiding of state-process.
- dreamcompiler 4y agoIt depends on what you mean by encapsulation. CLOS classes don't own their methods, which makes CLOS much more flexible than other OOP systems. But it also means there are no "private" methods, or slots for that matter. One way to "privatize" slots or methods is to put them in a special package, which serves as a private namespace. This doesn't prevent programmers from seeing them but it can flag any use of them as "odd" style in the source code.
- deterministic 4y agoErlang is AFAIK the only production programming language that is OO by this definition.
- EdwardCoffin 4y ago> I don’t know the exact implementation details of CLOS, but I feel that it can be easily replicated in C This makes me think he's barely scratched the surface of what CLOS has to offer.
- twoodfin 4y ago“Easily” is a stretch, but with a few Lisp->C idiom translations, you could follow along straightforwardly with “The Art of the Metaobject Protocol”[1]. [1] https://mitpress.mit.edu/9780262610742/the-art-of-the-metaobject-protocol/ https://mitpress.mit.edu/9780262610742/the-art-of-the-metaob...
- EdwardCoffin 4y agoI've read the MOP too. I seriously doubt that this is the case. There is a lot just below the surface in CLOS that a casual encounter would not reveal. This post [1] by Joe Marshall gives a taste of how these features can go unnoticed until you need them, then you appreciate CLOS for these things. [1] CLOS!? https://www.ca.crh.com/host-http-funcall.blogspot.be/2013/07/clos.html https://www.ca.crh.com/host-http-funcall.blogspot.be/2013/07...
- zachbeane 4y agoThe class and instance evolution protocols for starters seem not all that easy.
- dreamcompiler 4y agoExactly. Under the sheets you need class wrappers at a minimum to support these things.
- mikelevins 4y ago"Easily" is a stretch, for sure, but John Wainwright developed a framework that he called "oic", for "Objects in C", that was a fairly substantial subset of CLOS. I met him at OOPSLA ‘89 (or it might have been at AAAI) and introduced him to a couple of Apple developer guys, because I thought oic was cool. Whether because of that introduction or other reasons I’m not aware of, John ended up selling oic to Apple for use as the basis of the ScriptX object system, which was the programming language of the Kaleida Media Player (https://en.wikipedia.org/wiki/Kaleida_Labs https://en.wikipedia.org/wiki/Kaleida_Labs).
- gjvc 4y agoThe definitive book on implementing CLOS (not how to use it) is https://en.wikipedia.org/wiki/The_Art_of_the_Metaobject_Protocol https://en.wikipedia.org/wiki/The_Art_of_the_Metaobject_Prot...
- dj_mc_merlin 4y agoMeh.. I code in Common Lisp at home and Java professionally and I've never understood why people praise the CLOS so much. Like the author says, 99% of the time you don't have a reason to use OOP, and the few times you do you'd prefer to use as little as possible to keep everything sane. It's also one of the few parts of CL which are not optimized well by default, using structs or other basic data structures instead of objects has visible performance benefits in SBCL if you care about that for some reason. Yes I'm aware of the things you get in CL you don't get in Java: multiple inheritance, defmethod works on arbitrary types by default rather than having to create interfaces, better introspection.. but I don't care. If you're using these features so much there's probably something overly complex with your code to need to do so. Or you're working in such a complex domain you need to, in which case go ahead..
- rosebay 4y agoAgreed. I program in CL and other languages too. I find Java developers tend to have a stronger understanding of OOP and that might be behind your insight. For all its benefits, it feels like at times many CL users miss the point of OOP. CLOS itself is great, however the decoupling of data and methods is something at times I find leads to harder to understand code.
- aidenn0 4y ago> CLOS itself is great, however the decoupling of data and methods is something at times I find leads to harder to understand code. I think that might be familiarity rather than anything fundamental. I often find the coupling of data and methods to lead to harder to understand code; if I want to define a new method on an object in Java, I have to either subclass it or modify the class itself. Even if the method is ancillary to the core functionality of the class. That seems strange to me.
- andrekandre 4y ago> I want to define a new method on an object in Java, I have to either subclass it or modify the class itself. maybe what you are looking for is extension methods? objective-c/swift/kotlin/c# all support them to varying degrees (but sadly not java afaik)
- timonoko 4y agoOne thing bad is the word 'class'. What it is supposed to even mean? It was some fancy concept by stupid Normen when defining Simula. My Simula teacher said that you could just translate it as "design" as in "design of car and its implementation". Anyways Python's "class" is even worse: class c: a=10 print c.a c.a=13 print c.a I cannot think any English word to replace the "class". The word I am thinking of could be translated as "box". "Box of things and improved versions of it".
- medo-bear 4y agoisnt this just a small journal entry saying, "i started to learn clos and i think i like it". i dont see any siginificant information about why clos is great here. doing general oop in lisp is powerful from the get-go because you can update classes and instances interactively. you will use clos for this basic functionality. however clos also allows you to extend the oop ideas in directions that are just not available in other languages
- PeterStuer 4y ago!00% agree at the basic level. The approach here with multiple dispactch to me feels so much more natural than the Smalltalk/Java type of OO.
- bcrosby95 4y agoI've been exploring CLOS for the past couple of weeks. From what I can tell, it seems especially nice for a system that needs extreme flexibility. I like to program MUDs and rougelikes as side projects, and after initial exploration, CLOS seems perfect for that - it can enable certain interactions that I would otherwise have to spend a lot of work and design achieving in other languages. It turns what feels like a chore in other languages into something fun. I would imagine that how much this is a pro or con depends upon the work you do. Some might see such potential flexibility as error prone and overly complex because the domains they work in don't require such complexity. But others might see it as the building blocks for a domain with complex interactions that they have to build regardless of the language they use.
- infinite8s 4y agoI once made a rules engine for Magic the Gathering in python. As a design problem it is quite interesting since the key thing about MtG is that the pieces of the game can override the game rules. After reading about CLOS a few years later it seems I reinvented some of the main ideas (like cleanly re-entrant method combinators, cleanly overriding functionality of other objects in a way that can be reverted) using python's dynamiticity (especially descriptors which let you override what obj.[accesor] means).
- kaveh808 4y agoCLOS extends the Common Lisp philosophy of emphasizing developer flexibility, possibly at the expense of execution efficiency (not trying to open a can of worms here). For any application of substantial size, I can't imagine not using CLOS classes and generic dispatch. It may be overkill for small projects, but as the code complexity grows the abstractions of CLOS make their worth known. That's been my experience most recently with my 3D graphics system.
- retrocryptid 4y agoIf you like CLOS, be sure to look up "The Art of the Meta-Object Protocol." It Was written by people who were at PARC back in the day so were on the ground when Smalltalkish concepts were being developed and extended. But... it's focused on Lisp. It describes the thinking behind an implementation of OOP for Lisp, and along the process reveals parts of the mental journey to both Smalltalk and CLOS. https://en.m.wikipedia.org/wiki/The_Art_of_the_Metaobject_Protocol https://en.m.wikipedia.org/wiki/The_Art_of_the_Metaobject_Pr...
- santillaner 4y agoAspectJ was created by one of the authors and introduced some of CLOS ideas neatly into Java. Most of the time I find that closures are simpler than OOP to capture state and logic together…
- 0x445442 4y ago> Instead of instructions like in imperative programming (and modularizing it with functions), your program is a set of entities talking to each other and collectively achieving the required goal. So it looks like the author discovered a key characteristic of OOP which many languages including Java, support.
- ynniv 4y agoI don’t know the exact implementation details of CLOS, but I feel that it can be easily replicated in C by adding the needed metadata in the structure and doing the needed type checking in the functions. And thus Objective-C was reborn
- nevdka 4y agoAny sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule
- ynniv 4y agoFor more about ObjC: https://gnustep.github.io/resources/documentation/ObjectivCBook.pdf https://gnustep.github.io/resources/documentation/ObjectivCB... https://gnustep.github.io/developers/documentation.html https://gnustep.github.io/developers/documentation.html
- ilyash 4y agoOOP implementation in Next Generation Shell was inspired by CLOS but it's way simpler. Defining a type: type MyType. At any point one can declare method: F myMethod(..., mt:MyType, ...) some_code() Anything defined by F is automatically a multimethod. When invoked, all methods in the multimethod are searched bottom up. The first one where the call arguments match the parameters (by type, with inheritance) is invoked. That's roughly it.