10 ms·

CLOS: Integrating Object-Oriented and Functional Programming (2004) [pdf]

122 points by mepian 3y ago

pmoriarty 3y ago
Do any of the languages that are popular today have object systems that are as powerful and flexible as CLOS?
- messe 3y ago
  Julia, perhaps? Although calling it popular is a stretch maybe. Its multiple dispatch system is even more ingrained to the language than CLOS (all functions are generic by default). It's very much a Lisp in Matlab's clothing.
  - cmrdporcupine 3y ago
    ... ish? There's a lot of furniture that's bolted into Julia's runtime in terms of task management and so on, that isn't really like a Lisp runtime? It doesn't have that same "It's Turtles All the Way Down" self-consistent vibe that a Lisp has. On paper Julia looks like a great piece of kit. Once I worked in it professionally for a couple months, it started to leave a bad taste in my mouth.
- pjmlp 3y ago
  Julia, as answered on the sybling comment. Clojure has a subset, and I guess Racket is quite flexible with its language modeling framework. Going on an edge, C++ is also quite flexible when one looks beyond of plain classes, and combines them alongside type parameters in templates, and compile time reflexion via template metaprogramming and concepts (although it is quite clunky).
- deleted 3y ago
  [deleted]
- drnewman 3y ago
  Ruby has a meta object protocol. The net effect of the language isn't as powerful as Common Lisp since you don't have code-as-data in method definitions, but Ruby's object system is comparably powerful as CLOS (though made in the image of Smalltalk) it comes with a meta protocol for methods, objects, classes, modules, even lexical variables. https://ruby-doc.org/3.2.2/Object.html https://ruby-doc.org/3.2.2/Object.html https://ruby-doc.org/3.2.2/Method.html https://ruby-doc.org/3.2.2/Method.html https://ruby-doc.org/3.2.2/Class.html https://ruby-doc.org/3.2.2/Class.html https://ruby-doc.org/3.2.2/Module.html https://ruby-doc.org/3.2.2/Module.html https://ruby-doc.org/3.2.2/Binding.html https://ruby-doc.org/3.2.2/Binding.html
galdor 3y ago
For anyone finding CLOS interesting, "The Art of the Metaobject Protocol" is the next logical step. A good way to dig deep into how CLOS is built. It should be a mandatory read for anyone looking to design a programming language with object concepts.
- rileyphone 3y ago
  Agreed - another good resource is the original Flavors paper. Many of the parts are there like multiple inheritance and method combination but without the MOPs and multiple dispatch. https://www.softwarepreservation.org/projects/LISP/MIT/nnnfla1-20040122.pdf https://www.softwarepreservation.org/projects/LISP/MIT/nnnfl...
- EdwardCoffin 3y ago
  I think I'd recommend reading Sonya Keene's Object-Oriented Programming in Common Lisp: A Programmer's Guide to CLOS first though. I really don't know any other ways of learning all the things like method combinations and the like that make the MOP so powerful. All the CLOS tutorials I am aware of lack a real discussion of these features of CLOS.
  - mikelevins 3y ago
    Agreed. It's easier to learn how to do practical programming with CLOS from Keene's book. AMOP is more useful for those who want to know more about how things work under the hood, or who maybe want to build their own implementation of CLOS or something similar, and easier to understand after you've absorbed Keene.
  - r9550684 3y ago
    unrelated to your point, Sonya keene's book is the only one I know that was authored and typeset using Symbolics's in-house publishing system Concordia. (besides symbolics documentation sets of course) Concordia (and its display component document examiner) had a pretty novel hypertext approach to authoring. all the content was made up of individual notes, that you could link together either with explicit links, or implicit one-follows-the-other links. I don't know if that's how Sonya used it, but when I authored some documents using Concordia, I discovered that it was very easy to focus on addressing specific points in almost a throwaway fashion. write a note on some subject you want to address. if you don't like it, write another take on the same subject. now you have the option to put either note into the book flow, refine them in parallel, and defer editorial decisions to the very end. the process is very reminiscent of explorative programming in lisp, so in other words symbolics people figured out how to write books in the same way as they write their code. ultimate vertical integration.
lispm 3y ago
A bit more from RPG about CLOS: https://dreamsongs.com/CLOS.html https://dreamsongs.com/CLOS.html The CLOS spec was a collaboration of: Linda G. DeMichiel, Richard P. Gabriel (short RPG) : both from Lucid, Inc. Sonya E. Keene, David A. Moon : both from Symbolics, Inc. Daniel G. Bobrow, Gregor Kiczales : both from Xerox PARC The actual CLOS Specification: https://dreamsongs.com/Files/concepts.pdf https://dreamsongs.com/Files/concepts.pdf https://dreamsongs.com/Files/Functions.pdf https://dreamsongs.com/Files/Functions.pdf Published here: https://dl.acm.org/doi/10.1145/885631.885632 https://dl.acm.org/doi/10.1145/885631.885632 There is also a CLOS MOP spec, but that's not a part of the Common Lisp standard: http://lispm.de/docs/Publications/Lisp%20Language%20Manuals/1988%20CLOS%20Specification,%203.pdf http://lispm.de/docs/Publications/Lisp%20Language%20Manuals/...
whartung 3y ago
I essentially use "abbreviated" CLOS. In CL, defstruct structures walk on both sides of the CLOS line. They're not as robust as full boat CLOS classes, but they're not just a bag of fields either. They fully participate in CLOS dispatch, you can do composition with defstruct, you can create custom constructors and such. So, they fit right in with many "dumb object", or perhaps "slightly clever object" use cases without all of the wordiness of a full CLOS class. Mind, I'm not an experience CLOS user. I'm not choosing defstruct over defclass for any other reason save that I find it less verbose and it offers the functionality that I need. I'm sure my code might be idiomatically different were I to use true CLOS classes instead of defstructs, but I can't say right now that I'm "missing" anything. But I do think it's cool that defstructs participate very well with CLOS and that's it's not a "my way or the highway" type of system, it just integrates really well with the rest of CL.
- lispm 3y ago
  > They're not as robust as full boat CLOS classes Structures support single inheritance, CLOS classes support multiple inheritance. The main reason for structures is that they are faster to use by default - but they are less flexible. For example: CLOS classes support updates of existing objects when the class definition changes, structures don't support updates.
  - pfdietz 3y ago
    My feeling on this is that Common Lisp implementations should support classes in a way that idiomatic usage is just about as fast as structures. This is nontrivial, but I think it could be done.
    - dreamcompiler 3y ago
      There was a time (the early 1990s) when structures were dependably and significantly faster than classes, and you had to use structures for any application that was even remotely speed-sensitive. I haven't metered CLOS in a while, but since modern hardware is around 100x faster now and modern Common Lisp compilers are a lot better, I suspect structures are no longer faster than classes or if they are, classes are fast enough that their extra flexibility is more important except in a very small set of apps where raw speed is paramount. I would encourage CL programmers who stick to structures for speed reasons to try rewriting some of your code with classes and meter it. You might be pleasantly surprised.
EdwardCoffin 3y ago
On the related subject of the Meta Object Protocol, Gregor Kiczales talked at a meeting of the Vancouver Lisp Users Group in 2006, which they called a MOP retrospective [1]. He gave some thoughts on subjects like why more recent languages don't have MOPs. The link below is to archive.org's copy of the page and the .ogg recording of the talk along with Q&A throughout and after. [1] https://web.archive.org/web/20060821003818/http://bc.tech.coop/blog/060709.html https://web.archive.org/web/20060821003818/http://bc.tech.co...
- 7thaccount 3y ago
  I'm not a hotshot developer, but I'd guess a lot of recent languages (e.g. golang) are more structured around how to keep things simple (not necessarily easy) and uniform to where there aren't many surprises for new developers and the company can more or less turn coding into something more like an assembly line (to use an overly simplistic metaphor). Contrast that with languages like Lisp with crazy amounts of flexibility that really cater to small teams of rockstar developers (to use another overly simplistic metaphor) and you can see the problem. Most companies want the former and not the latter.
  - leetrout 3y ago
    I prefer Go over Lisp on the cover because I prefer the explicit, low magic code of Go with all its boiler plate and using my brain power on business problems not what makes me more productive or feel better / clever while doing my work. Horses for courses - I will never be a language designer / developer with this attitude.
    - sph 3y ago
      > using my brain power on business problems not what makes me more productive This doesn't make any sense. It's like saying you prefer hitting rocks together to make music because you don't have to use all your brain power at operating something complex like the sax or the piano. Tool enable, or kill, creativity. I'd rather not use my brain power to fight an obtuse tool, like Go can be, but instead choose to become a violin, or Lisp, virtuoso. The real issue is that many people don't want to become virtuoso, but just want to learn as little from their tools to make rent. That's fine, but let's not blame the tool, then. You know who doesn't like rockstars and soloists? Large companies, so they make us feel as if we're weird, unruly, opinionated, just because we don't conform to the Standard Programmer mould to fit inside the cubicle. Whenever I hear someone mention rockstar engineers, I wonder if they mean it as an insult, instead of something to be encouraged and celebrated.

122 points by mepian 3y ago

pmoriarty 3y ago

Do any of the languages that are popular today have object systems that are as powerful and flexible as CLOS?

messe 3y ago
Julia, perhaps? Although calling it popular is a stretch maybe. Its multiple dispatch system is even more ingrained to the language than CLOS (all functions are generic by default). It's very much a Lisp in Matlab's clothing.
- cmrdporcupine 3y ago
  ... ish? There's a lot of furniture that's bolted into Julia's runtime in terms of task management and so on, that isn't really like a Lisp runtime? It doesn't have that same "It's Turtles All the Way Down" self-consistent vibe that a Lisp has. On paper Julia looks like a great piece of kit. Once I worked in it professionally for a couple months, it started to leave a bad taste in my mouth.
pjmlp 3y ago
Julia, as answered on the sybling comment. Clojure has a subset, and I guess Racket is quite flexible with its language modeling framework. Going on an edge, C++ is also quite flexible when one looks beyond of plain classes, and combines them alongside type parameters in templates, and compile time reflexion via template metaprogramming and concepts (although it is quite clunky).
deleted 3y ago
[deleted]
drnewman 3y ago
Ruby has a meta object protocol. The net effect of the language isn't as powerful as Common Lisp since you don't have code-as-data in method definitions, but Ruby's object system is comparably powerful as CLOS (though made in the image of Smalltalk) it comes with a meta protocol for methods, objects, classes, modules, even lexical variables. https://ruby-doc.org/3.2.2/Object.html https://ruby-doc.org/3.2.2/Object.html https://ruby-doc.org/3.2.2/Method.html https://ruby-doc.org/3.2.2/Method.html https://ruby-doc.org/3.2.2/Class.html https://ruby-doc.org/3.2.2/Class.html https://ruby-doc.org/3.2.2/Module.html https://ruby-doc.org/3.2.2/Module.html https://ruby-doc.org/3.2.2/Binding.html https://ruby-doc.org/3.2.2/Binding.html

galdor 3y ago

For anyone finding CLOS interesting, "The Art of the Metaobject Protocol" is the next logical step. A good way to dig deep into how CLOS is built. It should be a mandatory read for anyone looking to design a programming language with object concepts.

rileyphone 3y ago
Agreed - another good resource is the original Flavors paper. Many of the parts are there like multiple inheritance and method combination but without the MOPs and multiple dispatch. https://www.softwarepreservation.org/projects/LISP/MIT/nnnfla1-20040122.pdf https://www.softwarepreservation.org/projects/LISP/MIT/nnnfl...
EdwardCoffin 3y ago
I think I'd recommend reading Sonya Keene's Object-Oriented Programming in Common Lisp: A Programmer's Guide to CLOS first though. I really don't know any other ways of learning all the things like method combinations and the like that make the MOP so powerful. All the CLOS tutorials I am aware of lack a real discussion of these features of CLOS.
- mikelevins 3y ago
  Agreed. It's easier to learn how to do practical programming with CLOS from Keene's book. AMOP is more useful for those who want to know more about how things work under the hood, or who maybe want to build their own implementation of CLOS or something similar, and easier to understand after you've absorbed Keene.
- r9550684 3y ago
  unrelated to your point, Sonya keene's book is the only one I know that was authored and typeset using Symbolics's in-house publishing system Concordia. (besides symbolics documentation sets of course) Concordia (and its display component document examiner) had a pretty novel hypertext approach to authoring. all the content was made up of individual notes, that you could link together either with explicit links, or implicit one-follows-the-other links. I don't know if that's how Sonya used it, but when I authored some documents using Concordia, I discovered that it was very easy to focus on addressing specific points in almost a throwaway fashion. write a note on some subject you want to address. if you don't like it, write another take on the same subject. now you have the option to put either note into the book flow, refine them in parallel, and defer editorial decisions to the very end. the process is very reminiscent of explorative programming in lisp, so in other words symbolics people figured out how to write books in the same way as they write their code. ultimate vertical integration.

lispm 3y ago

A bit more from RPG about CLOS: https://dreamsongs.com/CLOS.html https://dreamsongs.com/CLOS.html The CLOS spec was a collaboration of: Linda G. DeMichiel, Richard P. Gabriel (short RPG) : both from Lucid, Inc. Sonya E. Keene, David A. Moon : both from Symbolics, Inc. Daniel G. Bobrow, Gregor Kiczales : both from Xerox PARC The actual CLOS Specification: https://dreamsongs.com/Files/concepts.pdf https://dreamsongs.com/Files/concepts.pdf https://dreamsongs.com/Files/Functions.pdf https://dreamsongs.com/Files/Functions.pdf Published here: https://dl.acm.org/doi/10.1145/885631.885632 https://dl.acm.org/doi/10.1145/885631.885632 There is also a CLOS MOP spec, but that's not a part of the Common Lisp standard: http://lispm.de/docs/Publications/Lisp%20Language%20Manuals/1988%20CLOS%20Specification,%203.pdf http://lispm.de/docs/Publications/Lisp%20Language%20Manuals/...

whartung 3y ago

I essentially use "abbreviated" CLOS. In CL, defstruct structures walk on both sides of the CLOS line. They're not as robust as full boat CLOS classes, but they're not just a bag of fields either. They fully participate in CLOS dispatch, you can do composition with defstruct, you can create custom constructors and such. So, they fit right in with many "dumb object", or perhaps "slightly clever object" use cases without all of the wordiness of a full CLOS class. Mind, I'm not an experience CLOS user. I'm not choosing defstruct over defclass for any other reason save that I find it less verbose and it offers the functionality that I need. I'm sure my code might be idiomatically different were I to use true CLOS classes instead of defstructs, but I can't say right now that I'm "missing" anything. But I do think it's cool that defstructs participate very well with CLOS and that's it's not a "my way or the highway" type of system, it just integrates really well with the rest of CL.

lispm 3y ago
> They're not as robust as full boat CLOS classes Structures support single inheritance, CLOS classes support multiple inheritance. The main reason for structures is that they are faster to use by default - but they are less flexible. For example: CLOS classes support updates of existing objects when the class definition changes, structures don't support updates.
- pfdietz 3y ago
  My feeling on this is that Common Lisp implementations should support classes in a way that idiomatic usage is just about as fast as structures. This is nontrivial, but I think it could be done.
  - dreamcompiler 3y ago
    There was a time (the early 1990s) when structures were dependably and significantly faster than classes, and you had to use structures for any application that was even remotely speed-sensitive. I haven't metered CLOS in a while, but since modern hardware is around 100x faster now and modern Common Lisp compilers are a lot better, I suspect structures are no longer faster than classes or if they are, classes are fast enough that their extra flexibility is more important except in a very small set of apps where raw speed is paramount. I would encourage CL programmers who stick to structures for speed reasons to try rewriting some of your code with classes and meter it. You might be pleasantly surprised.

EdwardCoffin 3y ago

On the related subject of the Meta Object Protocol, Gregor Kiczales talked at a meeting of the Vancouver Lisp Users Group in 2006, which they called a MOP retrospective [1]. He gave some thoughts on subjects like why more recent languages don't have MOPs. The link below is to archive.org's copy of the page and the .ogg recording of the talk along with Q&A throughout and after. [1] https://web.archive.org/web/20060821003818/http://bc.tech.coop/blog/060709.html https://web.archive.org/web/20060821003818/http://bc.tech.co...

7thaccount 3y ago
I'm not a hotshot developer, but I'd guess a lot of recent languages (e.g. golang) are more structured around how to keep things simple (not necessarily easy) and uniform to where there aren't many surprises for new developers and the company can more or less turn coding into something more like an assembly line (to use an overly simplistic metaphor). Contrast that with languages like Lisp with crazy amounts of flexibility that really cater to small teams of rockstar developers (to use another overly simplistic metaphor) and you can see the problem. Most companies want the former and not the latter.
- leetrout 3y ago
  I prefer Go over Lisp on the cover because I prefer the explicit, low magic code of Go with all its boiler plate and using my brain power on business problems not what makes me more productive or feel better / clever while doing my work. Horses for courses - I will never be a language designer / developer with this attitude.
  - sph 3y ago
    > using my brain power on business problems not what makes me more productive This doesn't make any sense. It's like saying you prefer hitting rocks together to make music because you don't have to use all your brain power at operating something complex like the sax or the piano. Tool enable, or kill, creativity. I'd rather not use my brain power to fight an obtuse tool, like Go can be, but instead choose to become a violin, or Lisp, virtuoso. The real issue is that many people don't want to become virtuoso, but just want to learn as little from their tools to make rent. That's fine, but let's not blame the tool, then. You know who doesn't like rockstars and soloists? Large companies, so they make us feel as if we're weird, unruly, opinionated, just because we don't conform to the Standard Programmer mould to fit inside the cubicle. Whenever I hear someone mention rockstar engineers, I wonder if they mean it as an insult, instead of something to be encouraged and celebrated.