Live data from Hacker News

Common Lisp Object System (CLOS)

hescaide.me

51–60 of 90 posts

Re: Common Lisp Object System (CLOS)

#51

Earlier quoted context omitted.

You absolutely can use it without CLOS. It was an afterthought poorly bolted on that was worse than its predecessor in most ways as to be portable. It didn't exist when CLtL1 was written and barely existed when CLtL2 was released.

This "afterthought ... poorly bolted ... worse than its predecessor" is a type of HN comment that's too common. Not being a CLOS or Lisp user, I have no idea why you say this and can learn nothing from it. HN's really starting to put me off with suchlike rife blanket-damning posts that are uninformative and usually come from people who have little experience.

I don't know what their own thoughts on it are, but I personally think it's poorly bolted on because it's not actually used by the rest of the spec. There's a massive proliferation of functions acting on data structures, and none of them are generic even if they do the same thing. Poorly bolted on indeed.

Re: Common Lisp Object System (CLOS)

#53

Meh.. 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 o…

From what I know about CLOS, it's a great tool if you have a tight-knit team of seasoned devs, but it's a giant sack of footguns otherwise. You can redefine so much about the object system that your codebase will instantly become unmaintainable.

Redefining things about the object system sounds more like MOP than CLOS. The MOP is an extension of CLOS, but it's not part of the Common Lisp standard like CLOS is.

If you meant one part of the system redefining things defined in another part, this can be addressed with package locking, if your CL implementation supports that (sbcl does). This is a general problem of lisps, not something specific to CLOS.

Re: Common Lisp Object System (CLOS)

#54

Earlier quoted context omitted.

This "afterthought ... poorly bolted ... worse than its predecessor" is a type of HN comment that's too common. Not being a CLOS or Lisp user, I have no idea why you say this and can learn nothing from it. HN's really starting to put me off with suchlike rife blanket-damning posts that are uninformative and usually come from people who have little experience.

I don't know what their own thoughts on it are, but I personally think it's poorly bolted on because it's not actually used by the rest of the spec. There's a massive proliferation of functions acting on data structures, and none of them are generic even if they do the same thing. Poorly bolted on indeed.

This is a valid criticism. Many of the (possibly) non-generic functions in Common Lisp could be made generic. That they weren't was a bow to existing implementations of Lisp that wouldn't have supported it. The stakeholders engaging in the standardization process didn't want extensions that would be excessively (at the time) costly for them to implement, especially in a way that wouldn't have a large runtime performance impact.

Re: Common Lisp Object System (CLOS)

#55

  I 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

Re: Common Lisp Object System (CLOS)

#56

Earlier quoted context omitted.

You cannot use Common Lisp without the CLOS. The fact that you can delude yourself into thinking that most of the time you don't have a reason to use it is what makes it so great.

You absolutely can use it without CLOS. It was an afterthought poorly bolted on that was worse than its predecessor in most ways as to be portable. It didn't exist when CLtL1 was written and barely existed when CLtL2 was released.

Ok, I will try to use Common Lisp without the CLOS:

  * 123
  123
That looks good, let's see...

  * (describe *)
  123
    [fixnum]
Huh? What's a FIXNUM?

  * (describe 'fixnum)
  COMMON-LISP:FIXNUM
    [symbol]

  FIXNUM names the built-in-class #:
    Class precedence-list: FIXNUM, INTEGER, RATIONAL, REAL, NUMBER, T
    Direct superclasses: INTEGER
    No subclasses.
    Sealed.
    No direct slots.
Uh-oh.

Anyway, you see what I mean now by not being able to use Common Lisp without the CLOS. Unless by using the CLOS you mean having to explicitly opt-in by using classes, multiple dispatch, multiple inheritance, generic functions, the MOP and all that weird stuff.

Re: Common Lisp Object System (CLOS)

#57

Earlier quoted context omitted.

This "afterthought ... poorly bolted ... worse than its predecessor" is a type of HN comment that's too common. Not being a CLOS or Lisp user, I have no idea why you say this and can learn nothing from it. HN's really starting to put me off with suchlike rife blanket-damning posts that are uninformative and usually come from people who have little experience.

I don't know what their own thoughts on it are, but I personally think it's poorly bolted on because it's not actually used by the rest of the spec. There's a massive proliferation of functions acting on data structures, and none of them are generic even if they do the same thing. Poorly bolted on indeed.

CL's functionality is an amalgamation of the prior Lisps (thus "Common") which didn't have CLOS. But it was CLOS-ifying a variety of things by the time of the 1994 standard. You just don't see more because the immediate goal was a large degree of compatibility with those prior Lisps. If a second standard had developed a larger portion of the system would probably have been brought under CLOS.

Re: Common Lisp Object System (CLOS)

#58

Meh.. 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 o…

I think you have to take the praise in perspective? Go into it with the idea that you want to do OOP, and CLOS is pretty amazing.

I agree with you, though, OOP should be something you reach for purposely, not as a default. And, unfortunately, the waters have been so muddied, that I couldn't tell you the best purposes to reach for it. About the best I can see is that it does lend itself well to metaphor, and people communicate almost exclusively in metaphors, when it comes to programming?

Re: Common Lisp Object System (CLOS)

#59

If 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.wikipe…

AspectJ 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…

Re: Common Lisp Object System (CLOS)

#60
post #9

One 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…

This is why I find prototype-based object systems so much more natural. Inevitably any dynamic object system ends up having to represent classes as objects, but that retroactively opens up a lot of mind-bending complexity. Prototypes on the other hand make far more sense in a dynamic context. You just create objects that you can clone and extend. Classes just become a design pattern. It also highlights that the interfaces of an object are more important than the class.
Post reply on HN