3 ms·

Can you expand on the second point? What can you do with CL OO that is hard in C/C++?

remexre 6y ago
I like the Circle-Ellipse Problem [0] as an example of something CLOS / multimethods are good at that C++ isn't. In general, Expression Problem-like [1, 2] problems are much much nicer to solve in CL. [0]: https://en.wikipedia.org/wiki/Circle%E2%80%93ellipse_problem https://en.wikipedia.org/wiki/Circle%E2%80%93ellipse_problem [1]: https://en.wikipedia.org/wiki/Expression_problem https://en.wikipedia.org/wiki/Expression_problem [2]: https://wiki.c2.com/?ExpressionProblem https://wiki.c2.com/?ExpressionProblem
lisper 6y ago
The big win is not so much in the actual underlying power, but rather in the syntactic uniformity. In traditional OO languages there is a semantic difference between f(arg1, arg2) and arg1.f(arg2) and as a programmer I have to remember which one is the right one for any particular operation I want to do. In CL the syntax for a regular function call and a generic function call is exactly the same, so as a programmer I don't have to worry about it. I just write (do-something arg1 arg2) and let the compiler figure it out. It removes a tremendous amount of cognitive burden. But there are lots of examples where it really makes sense to be able to dispatch on multiple arguments. Arithmetic operations, for example. It's really nice to be able to add, say, arrays using the same syntax as adding numbers, or to be able to do array-array multiplication and array-scalar multiplication using the same syntax as multiplying numbers. Or, if you're doing graphics, to be able to specialize on both the object being drawn and the target to which it is being drawn. There are loads of other things as well. The meta-object protocol allows you to do all kinds of wizzy things. Using EQL specialization lets you define special-case handling for a privileged object without cluttering up the rest of your code. BEFORE and AFTER methods let you tweak arguments on the way in or results on the way out. Here's an example from a real-world project I'm working on: it's a 30-year-old legacy system and it's chock-full of hard-coded path names, literally thousands of them. We had to port it to a new environment where those paths don't exist. Normally this would have been a huge project to go through the source code and manually find and change all of the paths. Instead, I was able to define a BEFORE method on the OPEN function [1] which translated the incoming hard-coded path name to the correct value in the new environment. What would normally have been a multi-day headache was instead a five-minute tweak. [1] Yes, I know OPEN is not actually a generic function, and so this is not actually possible in portable CL. But this was in ACL which provides this feature as an extension. And even in portable CL you can always shadow OPEN and redefine it. This is now getting away from the advantages of the OO system and into other parts of CL, but the bottom line is that many, many things that are a PITA in other languages are easy in CL.

I like the Circle-Ellipse Problem [0] as an example of something CLOS / multimethods are good at that C++ isn't. In general, Expression Problem-like [1, 2] problems are much much nicer to solve in CL. [0]: https://en.wikipedia.org/wiki/Circle%E2%80%93ellipse_problem https://en.wikipedia.org/wiki/Circle%E2%80%93ellipse_problem [1]: https://en.wikipedia.org/wiki/Expression_problem https://en.wikipedia.org/wiki/Expression_problem [2]: https://wiki.c2.com/?ExpressionProblem https://wiki.c2.com/?ExpressionProblem

lisper 6y ago

The big win is not so much in the actual underlying power, but rather in the syntactic uniformity. In traditional OO languages there is a semantic difference between f(arg1, arg2) and arg1.f(arg2) and as a programmer I have to remember which one is the right one for any particular operation I want to do. In CL the syntax for a regular function call and a generic function call is exactly the same, so as a programmer I don't have to worry about it. I just write (do-something arg1 arg2) and let the compiler figure it out. It removes a tremendous amount of cognitive burden. But there are lots of examples where it really makes sense to be able to dispatch on multiple arguments. Arithmetic operations, for example. It's really nice to be able to add, say, arrays using the same syntax as adding numbers, or to be able to do array-array multiplication and array-scalar multiplication using the same syntax as multiplying numbers. Or, if you're doing graphics, to be able to specialize on both the object being drawn and the target to which it is being drawn. There are loads of other things as well. The meta-object protocol allows you to do all kinds of wizzy things. Using EQL specialization lets you define special-case handling for a privileged object without cluttering up the rest of your code. BEFORE and AFTER methods let you tweak arguments on the way in or results on the way out. Here's an example from a real-world project I'm working on: it's a 30-year-old legacy system and it's chock-full of hard-coded path names, literally thousands of them. We had to port it to a new environment where those paths don't exist. Normally this would have been a huge project to go through the source code and manually find and change all of the paths. Instead, I was able to define a BEFORE method on the OPEN function [1] which translated the incoming hard-coded path name to the correct value in the new environment. What would normally have been a multi-day headache was instead a five-minute tweak. [1] Yes, I know OPEN is not actually a generic function, and so this is not actually possible in portable CL. But this was in ACL which provides this feature as an extension. And even in portable CL you can always shadow OPEN and redefine it. This is now getting away from the advantages of the OO system and into other parts of CL, but the bottom line is that many, many things that are a PITA in other languages are easy in CL.