4 ms·

No, it is absolutely the opposite. Lisp's object system(s) are much more powerful and much more expressive than what Python got. However, that expressiveness co

No, it is absolutely the opposite. Lisp's object system(s) are much more powerful and much more expressive than what Python got. However, that expressiveness comes with a cost; everyone and their grandmother builds their own object system because they are unhappy about some detail in the default object system. Personally, I prefer the Python approach where the object system is coded into the language. Strictly less powerful, but more practical and to me it doesn't "feel" very limiting.

jackdaniel 4y ago
In my experience people tend to use standard classes in Common Lisp, without further specialization (which is of course possible with MOP). They are part of the standard, so I'd say that they are "coded into the language" alright.
- bjourne 4y ago
  How many Lisp implementations follow the HyperSpec? I'm no Lisp expert but from what I've seen the object system can vary quite a bit depending on the exact implementation.
  - jackdaniel 4y ago
    Since we talk about CLOS (and HyperSpec, which is based on the last draft before the standard), I assume that we talk about Common Lisp. All conforming Common Lisp implementations have CLOS. To name a few which are used: free: ABCL, CLISP, CCL, CMUCL, ECL, SBCL; commercial: AllegroCL, LispWorks. There are more. I've made a diagram a few years back that shows the family with ancestors and sub-branches including these that are not complaint: https://ecl.common-lisp.dev/static/quarterly/img/vol4/all-hierarchy.png https://ecl.common-lisp.dev/static/quarterly/img/vol4/all-hi... Common Lisp strength is its standard; many programs developed on one implementation will work on another one. And standard includes CLOS. As far as I know, scheme had a bit of problems with that the standard was too small, and there were numerous implementations of the same functionality that were different; the issue with fragmentation was also problematic in pre-common lisp times - that was one of reasons why there was a grant to create the standard - to unify numerous implementations.
    - lispm 4y ago
      There are also derived versions of CLOS in other languages. Examples: Languages like Dylan and Scheme extensions (see http://community.schemewiki.org/?CLOS http://community.schemewiki.org/?CLOS ).

jackdaniel 4y ago

In my experience people tend to use standard classes in Common Lisp, without further specialization (which is of course possible with MOP). They are part of the standard, so I'd say that they are "coded into the language" alright.

bjourne 4y ago
How many Lisp implementations follow the HyperSpec? I'm no Lisp expert but from what I've seen the object system can vary quite a bit depending on the exact implementation.
- jackdaniel 4y ago
  Since we talk about CLOS (and HyperSpec, which is based on the last draft before the standard), I assume that we talk about Common Lisp. All conforming Common Lisp implementations have CLOS. To name a few which are used: free: ABCL, CLISP, CCL, CMUCL, ECL, SBCL; commercial: AllegroCL, LispWorks. There are more. I've made a diagram a few years back that shows the family with ancestors and sub-branches including these that are not complaint: https://ecl.common-lisp.dev/static/quarterly/img/vol4/all-hierarchy.png https://ecl.common-lisp.dev/static/quarterly/img/vol4/all-hi... Common Lisp strength is its standard; many programs developed on one implementation will work on another one. And standard includes CLOS. As far as I know, scheme had a bit of problems with that the standard was too small, and there were numerous implementations of the same functionality that were different; the issue with fragmentation was also problematic in pre-common lisp times - that was one of reasons why there was a grant to create the standard - to unify numerous implementations.
  - lispm 4y ago
    There are also derived versions of CLOS in other languages. Examples: Languages like Dylan and Scheme extensions (see http://community.schemewiki.org/?CLOS http://community.schemewiki.org/?CLOS ).