News for hackers. Stuff that matters.
Re:SBCL: New in Version 2.1.0 by lisper on Wednesday December 30, 2020 @12:59PM (#25584078)
Yes, I use it professionally, and have for over 30 years, since before it became Common Lisp. It is far and away my favorite programming language (hence my HN handle :-) for two reasons: macros allow me to capture any design pattern and seamlessly add it to the language as a programming construct, and the generic function model of OO built in to CL is vastly more powerful than the C-based single-dispatch object.method() model that is ubiquitous in the rest of the programming language world.
Re:SBCL: New in Version 2.1.0 by gautamcgoel on Wednesday December 30, 2020 @01:49PM (#25584663)
Can you expand on the second point? What can you do with CL OO that is hard in C/C++?
Re:SBCL: New in Version 2.1.0 by lisper on Wednesday December 30, 2020 @02:12PM (#25584904)
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.

Re:SBCL: New in Version 2.1.0 by remexre on Wednesday December 30, 2020 @02:05PM (#25584821)
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 [1]: https://en.wikipedia.org/wiki/Expression_problem [2]: https://wiki.c2.com/?ExpressionProblem