Earlier quoted context omitted.
i think of "blueprint" as an analogy for what "class" is supposed to describe.
Earlier lisps called it „flavour“ Defflavor instead of defclass
That makes sense only when multiple inheritance is supported though.
Common Lisp Object System (CLOS)
71–80 of 90 posts
Re: Common Lisp Object System (CLOS)
#72Meh.. 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…
Personally, I use CLOS all the time and think it's great. Even without defining my own classes, I use multiple dispatch and methods on arbitrary types quite a bit. Admittedly, I don't really use the advanced features like MOP, but I appreciate that they're there and that I can manipulate how the object system works if I ever need to.
As far as performance goes, it just hasn't been a problem for me, even when doing graphics and image processing. A pattern that's worked really well is to use OOP to structure and organize everything, and then have the implementation details flushed out with functional or imperative code. It's the best of all worlds.
And it's actually a good pattern in most OOP languages because it slows things down in most of them. The vtable in C++, extra GC in Java, object attributes vs. locals in Python, etc. Avoiding objects in performance critical code is just generally a good idea.
Re: Common Lisp Object System (CLOS)
#73Earlier 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.
...and that's the sort of critique I'm interested in and which should have been given initially.
Re: Common Lisp Object System (CLOS)
#74One 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…
From https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&d... : ‘ We chose the terms “class” and “objects” of classes for our new Simula. The notion of subclass was especially appealing to us, since we had seen many cases of objects belonging to different classes having common properties. It would be useful to collect the common properties in a separate class, say C to be specialised differently for different…
yes. and in addition the word existed before, with the morning of "kind, category, group" of whatever.
https://www.thesaurus.com/browse/class
naming is hard and class is a good name for it's meaning in software.
Re: Common Lisp Object System (CLOS)
#75I'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 ch…
CLOS 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.
Re: Common Lisp Object System (CLOS)
#76> 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.
Though possible. See for example https://github.com/blakemcbride/Dynace
Re: Common Lisp Object System (CLOS)
#77I 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
Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
Re: Common Lisp Object System (CLOS)
#78Earlier quoted context omitted.
Agreed. 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.
> 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 an…
> I want to define a new method on an object in Java, I have to either subclass it or modify the class itself.
objective-c/swift/kotlin/c# all support them to varying degrees (but sadly not java afaik)
Re: Common Lisp Object System (CLOS)
#79Alan 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... ] His reference to ‘LISP’ is, of course, referring to C…
Erlang is AFAIK the only production programming language that is OO by this definition.
Re: Common Lisp Object System (CLOS)
#80Earlier quoted context omitted.
> 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 an…
> 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)
Yes, those are a huge improvement over the Java/C++ way. I cant tell if in a typical implementation all extension methods share the same namespace though (i.e. if the language has the concept of a "namespace" can one safely define two different extension methods on the same object in two different namespaces; this is trivial in CLOS since methods are not namesepaced to objects in any manner).
A quick read of the wikipedia article makes it look like in C# you can do this, but not in Ruby.