@[email protected] I think #CommonLisp is ugly as hell and I've been at it on and off for 40 years.
Powerful, yes. But ugly too. (Not the syntax, to be clear, but all the cruft in the created-by-committee language.)
Just my opinion. Most of the Lisp hackers I know don't care about that stuff as much as I do.
Flavors was the lisp machine's original OO system. For its day, it was quite innovative (and its implementation even more so)!
Some example features of Flavors: multiple inheritance, different inheritance types (e.g., CASE method combination?!), optimizations when instance variable ordering is known, demon methods/wrappers (automatically generated, "the fruit of the immaculate compilation"), and so on.
But CLOS was "better", in that it was more regular rather than the product of a decade of organic growth. True, it was simplified down a bit and didn't contain all the Flavors features. But once you understood the gist of it, you understood all of it, pretty much.
(I thought for sure you were going to argue about the aesthetics of LOOP. For about 2 generations now, purists have complained it's not Lispy enough. Pragmatists have responded with an argument that boils down to "shut up, I'm busy programming a loop here". I'm with the pragmatists, for once.)
By "better" object system I meant (a) generic functions, which just soothe my brain instead of making me thing message-passing is something different, and (b) a bit more regular in form, from having been designed all at once.
Probably not better along a number of other dimensions!
Personally, I like organizing around what Java folk would call interfaces, and back in the day we called protocols. It's both a class and generic function thing, but it clearly establishes boundaries and Dijkstra-like "separation of concerns" in your code.
Dylan took that even further, by giving very, very heavy weight to being statically analyzable most of the time. (E.g., classes sealed by default, some oddball rules around inheritance, etc. that all mean methods are completely discoverable at library-level compilation time.)
Now, there's also tight vs loose binding, which is Dylan's version of the fragile base class problem. I dunno the solution to that.
I finished out my career hacking stats & applied math in R, and now I fiddle around the edges of Haskell.
@weekend_editor @lispm @[email protected]
RE: "[T]here's also tight vs loose binding, which is Dylan's version of the fragile base class problem."
I think that may be one reason why the names were officially changed to "development" and "production" modes. One should compile code in "production" mode when running in production.
Carl Gay
lispm
Weekend Editor