4 ms·

There isn't, as far as I'm aware, another language with CL's popularity that provides either its condition system or the full power of the CLOS (method combinat

There isn't, as far as I'm aware, another language with CL's popularity that provides either its condition system or the full power of the CLOS (method combination, for instance). These two major subsystems are still significant improvements over what modern languages have to offer.

hga 13y ago
Good point about CLOS, but for a lot of us who've gained an allergy to OO over the years, especially in its difficult relation to functional programming, that's of limited appeal unless you're working in one of the areas its fruitfully employed. Would have to look at it's condition system, it's been way too long.
- fusiongyro 13y ago
  If you're giving up CL for Ruby, the CLOS is worth discussing. If you're giving up CL for Haskell, well, it's a different story. :) I never used the condition system extensively (or CL) but my recollection is that when you raise the condition you can also furnish various recovery strategies to be selected by the handler. If the caller doesn't handle, it will travel up the stack to someone who does, but that entity is not limited to innovating its own handling strategy, it can also choose one of the provided ones without breaking the abstraction or involving intermediate callers. The toplevel handler shows the provided restarts, adds the retry/fail options and lets the user interactively select one. It's pretty sophisticated.
- pnathan 13y ago
  CLOS is, IMO, much closer to an inheritable Rust trait than C++.
- Theriac25 13y ago
  Have you really looked into CLOS? Because IMHO it doesn't have much common with any of the OO systems in any of the mainstream languages.
  - hga 13y ago
    Yes, I have, and starting from the Lisp Machine Flavors precursor. While I haven't used it in anger, it's in theory by far my most favorite OO system. This is in part philosophical, the "prefer 10 data types and 90 functions that operate on them, often all of them" sort of thing, in part my horror at smearing behavior and data all over the place, and pragmatically, how that's much more of an imperative than functional approach. And functional is where its at for what I want to do. And experience in using OOSE to develop a greenfields system. That was utterly cool and amazing, but ... see my last sentence below. Which is not to say that the next time I do a GUI I'm not going to use OO to model the widgets et. al. on the screen. I believe it has its place, but that it's used much more widely than makes sense.

hga 13y ago

Good point about CLOS, but for a lot of us who've gained an allergy to OO over the years, especially in its difficult relation to functional programming, that's of limited appeal unless you're working in one of the areas its fruitfully employed. Would have to look at it's condition system, it's been way too long.

fusiongyro 13y ago
If you're giving up CL for Ruby, the CLOS is worth discussing. If you're giving up CL for Haskell, well, it's a different story. :) I never used the condition system extensively (or CL) but my recollection is that when you raise the condition you can also furnish various recovery strategies to be selected by the handler. If the caller doesn't handle, it will travel up the stack to someone who does, but that entity is not limited to innovating its own handling strategy, it can also choose one of the provided ones without breaking the abstraction or involving intermediate callers. The toplevel handler shows the provided restarts, adds the retry/fail options and lets the user interactively select one. It's pretty sophisticated.
pnathan 13y ago
CLOS is, IMO, much closer to an inheritable Rust trait than C++.
Theriac25 13y ago
Have you really looked into CLOS? Because IMHO it doesn't have much common with any of the OO systems in any of the mainstream languages.
- hga 13y ago
  Yes, I have, and starting from the Lisp Machine Flavors precursor. While I haven't used it in anger, it's in theory by far my most favorite OO system. This is in part philosophical, the "prefer 10 data types and 90 functions that operate on them, often all of them" sort of thing, in part my horror at smearing behavior and data all over the place, and pragmatically, how that's much more of an imperative than functional approach. And functional is where its at for what I want to do. And experience in using OOSE to develop a greenfields system. That was utterly cool and amazing, but ... see my last sentence below. Which is not to say that the next time I do a GUI I'm not going to use OO to model the widgets et. al. on the screen. I believe it has its place, but that it's used much more widely than makes sense.