[HN Gopher] CLOS: Integrating Object-Oriented and Functional Pro...
___________________________________________________________________
CLOS: Integrating Object-Oriented and Functional Programming (2004)
[pdf]
Author : mepian
Score : 87 points
Date : 2023-08-12 16:03 UTC (6 hours ago)
(HTM) web link (dreamsongs.com)
(TXT) w3m dump (dreamsongs.com)
| whartung wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| pfdietz wrote:
| The problem comes from dynamism. Accessors to class slots
| are generic functions, and in current implementations
| cannot be inlined in general, as new methods can be added
| to them, even if the class of the argument is known
| statically. Even direct access to slots suffers from the
| effects of dynamism, since classes can be redefined at
| any time and the slots moved around.
|
| So, what's needed is a general way to get efficient code
| for such things even in the face of dynamic redefinition.
| This is possible, using generated code snippets that are
| relinked into code when definitions change, but I don't
| know of any Common Lisp compiler that currently does
| this.
| EdwardCoffin wrote:
| 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.co...
| 7thaccount wrote:
| 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.
| ecshafer wrote:
| Go was made popular and successful for only one reason,
| google used/made it. And this was at the height of googles
| coolness. So other companies followed on the bandwagon, or
| were made by former google developers and brought it over.
| The success is completely secondary to how many people like
| go or the features it has.
|
| As far as simplicity I think I would disagree and agree with
| that. Rust is not a simple language. Other languages like F#
| or Scala or Kotlin that have arisen in the same timeframe as
| go are also not simple. But they do try and make some hard
| things easier, like concurrency or type safety.
| coldtea wrote:
| Well, Google also made Dart and it went nowhere. So it's
| not necessarily that.
|
| Go had a simple familiar syntax that's easy to pick up,
| decent tooling from the get go, good enough speed and
| memory use, and promised easy parallelism. It also arrived
| at 1.0 relatively quickly and quite mature with few rough
| edges and a feature full standard lib.
|
| Most "indie" languages don't have those even after 10 years
| of development.
| wtetzner wrote:
| I don't really buy into this view of Go. Go doesn't keep
| things simple and uniform. It's more limited in many ways
| than other languages, but it's feature set is largely
| arbitrary, and not particularly simple. Limited and simple
| are not synonyms.
| leetrout wrote:
| 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.
| panick21_ wrote:
| Go concurrency is lots of magic.
| BaculumMeumEst wrote:
| It's also dramatically more useful than CLOS, and its
| real-world impact has far outweighed that of CLOS. Having
| excellent concurrency features built into a language
| turns out to be pretty important.
| wtetzner wrote:
| > 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.
|
| This seems like a false dichotomy. Boilerplate-heavy code
| is the opposite of focusing on business logic. Incidental
| complexity ends up being intertwined with business logic
| everywhere. More powerful languages allow programmers to do
| clever tricks and make a mess, but they don't _require_ it.
| Those languages also allow programmers to abstract away
| incidental complexity and expose business logic more
| clearly.
|
| I think the future of programming languages is going to be
| in finding a balance that allows powerful abstractions
| while still making the semantics as clear as possible.
|
| Though I have to say, I don't really see what Go buys you
| over something like OCaml, which is still very explicit (in
| many ways more so than Go) while still providing powerful
| abstraction facilities. It even competes with Go on the
| compile-time front.
| sph wrote:
| > 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.
| coldtea wrote:
| > _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._
|
| It's more like saying that he'd rather play the piano and
| get musical results faster, than study some instrument
| much fewer people use, with 200 microtonal keys, 10
| pedals, additional sliders and rotary switches, and a
| microprocessor that you can study a 500 page guide to
| learn and create custom sounds for, and the music scores
| for which look like line noise.
| leetrout wrote:
| This is correct. Thank you for the defense.
| lispm wrote:
| One of the ideas of Lisp is that you can extend/change the
| language to bring it near the actual domain level. The so-
| called "Embedded Domain Specific Language" is common in
| Lisp.
| leetrout wrote:
| In my VERY limited experience this is only maintainable
| in very capable hands. They all start off OK and then
| creep and bloat.
| taeric wrote:
| In my not so limited experience, this is true of all
| programming.
| wtetzner wrote:
| To be fair, I don't think I'd want someone who's _not_
| very capable working on anything important, no matter
| what language they 're using. I know it happens all the
| time, but I don't think that's a particularly compelling
| argument.
| pmoriarty wrote:
| Do any of the languages that are popular today have object
| systems that are as powerful and flexible as CLOS?
| [deleted]
| drnewman wrote:
| Ruby has a meta object protocol. The net effect of the system
| isn't as powerful as Common Lisp since you don't have code-as-
| data in method definitions, but Ruby comes with a meta protocol
| for everything else. Methods, Objects, Classes, Modules, even
| lexical variables.
|
| https://ruby-doc.org/3.2.2/Object.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/Binding.html
| messe wrote:
| 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.
| pjmlp wrote:
| 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).
| lispm wrote:
| A bit more from RPG about CLOS:
|
| 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/Functions.pdf
|
| Published here: 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/...
| galdor wrote:
| 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 wrote:
| 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/nnnfl...
| EdwardCoffin wrote:
| 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 wrote:
| 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 wrote:
| 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.
| bmitc wrote:
| > Symbolics's in-house publishing system Concordia
|
| What you describe regarding Concordia sounds very
| intriguing. I can search for information on Concordia, but
| do you have any goto references (books, papers, videos) on
| it that you'd recommend?
| lispm wrote:
| I once recorded a demo video, running Concordia on an
| actual Symbolics Lisp Machine.
|
| https://vimeo.com/83886950
| [deleted]
| bmitc wrote:
| Thank you!
| lispm wrote:
| "Lisp Lore: A Guide to Programming the Lisp Machine" by
| Bromley&Lamson was also written using Concordia AFAIK. The
| Symbolics documentation also has Jensen&Wirth "Pascal User
| Manual and Report" and Harbison & Steele, C: A Reference
| Manual.
| jauntywundrkind wrote:
| One of the core points about metaobject protocols is that while
| it's important to language design, a good language to me also
| exposes & makes flexible the object system to users of the
| language too.
|
| From a review (https://www.adamtornhill.com/reviews/amop.htm),
|
| > _The metaobject protocol behaves like an interface towards
| the language itself, available for the programmer to
| incrementally customize. Just as we can specialize and extend
| the behavior of the classes we define in our own applications,
| we can now extend the language itself using the very same
| mechanisms._
|
| One of the points that has rather surprised me is that we devs
| have not more broadly explored what we could do with our
| metaobject protocols. We havent had a boom in metaprogramming,
| we haven't seen a largescale return of AOP; we've been letting
| objects stay dumb unextended objects for a long time now.
|
| The one sizable exception I have on my radar is React's Higher
| Order Components, where components/classes were
| wrapped/composed in other classes. Slices of object behavior
| were spliced into place.
|
| Now that's replaced with hooks, which invert the relationship,
| making the function up front composed all behavior it might
| want as hooks that it calls.
|
| I don't know enough about how Rust macros are made & used. My
| vague impression is they are very scarcely considered. Maybe I
| just missed the discussions but I'd expect there to be lots of
| blogging about this topic if metaprogramming here was really as
| fertile a field here as to be expected.
| jmeister wrote:
| You might find this interesting:
|
| Metaobject Protocols for Julia https://drops.dagstuhl.de/opus
| /volltexte/2022/16759/pdf/OASI...
| travisgriggs wrote:
| > One of the points that has rather surprised me is that we
| devs have not more broadly explored what we could do with our
| metaobject protocols. We havent had a boom in
| metaprogramming, we haven't seen a largescale return of AOP;
| we've been letting objects stay dumb unextended objects for a
| long time now.
|
| The other day I showed some newer devs how they could replace
| a good 10+ lines of for/index/loop/conditional code whose
| purpose was to find either the next or previous elements
| following an element that matched a condition with wrap
| around semantics. I did it using a zip and a filter. Good old
| "functional" approach. That's cool they said, and then got
| rid of me as quick as they could. They had been close to
| pushing their changes. And indeed did.
|
| It used to be the case that a sizable number of my peers were
| interested in furthering their craft. Those that "just ship
| it, it works, ok?" We're tolerated. Now it seems that
| enthusiast peers that are interested in "exploration" and
| "discovery" are few and far between. I'm surrounded by people
| that do their hours and clock out tickets.
|
| So no, I am no longer surprised by this lack of meta
| programming interest. Or any other "higher level" linguistic
| pursuits.
| pjmlp wrote:
| > We havent had a boom in metaprogramming, we haven't seen a
| largescale return of AOP; we've been letting objects stay
| dumb unextended objects for a long time now.
|
| As user of Java, .NET and C++ ecosystems, I beg to differ,
| those subjects are quite present.
___________________________________________________________________
(page generated 2023-08-12 23:00 UTC)