Hacker News Reader

Comment by anthk | Hacker News Reader

CL can do OO programming too.

Common Lisp is one of the few truly multi-paradigm languages.

It's annoying the standard has not evolved a bit to bring some ideas you see in Clojure, or some computation models featured in CTM & Mozart/Oz that have made it to Racket.

Still, a fantastic language. And the ecosystem is far from stagnant, with things like https://clasp-developers.github.io and https://coalton-lang.github.io coming out lately.

What killed Scala at my last employer was that nobody could agree on what idiomatic code should look like, so there were vast stylistic differences between areas. Despite working in the same language, it ended up being hard to move between codebases, in unpredictable ways.

This strikes me as the same sort of flexibility: you can do just about anything. If you do do just about anything, it's a bad time for all concerned.

Common Lisp has CLOS (Common Lisp Object System), which is quite sophisticated object system with metaobject protocol and multiple dispatch, as a part of its spec. Not that it's smth people need to invent on their own each time

The Meta-Object Protocol is optional and not a part of the standard.

It would be far more consistent than the Scala in the example, if everyone used SBCL with the same implementation, right?

I would think that Scala is slightly more object-oriented than Common Lisp, given that one can mostly ignore OOP in some Common Lisp applications. Thus that part already (macros !) makes CL very flexible in expressing different ways of programming. CLOS without MOP has a range of possible use. I haven't thought about how consistent typical code actually is, using CLOS without MOP. My intuition would say that there is some common CLOS style, but maybe that's wrong. It would be an interesting question to look at, how CLOS code bases make use of its features and if they share common architecture principles. Actually there is not that many literature on software engineering principles for CLOS. For example see: "CLOS in Context: The Shape of the Design Space" by Bobrow&Gabriel&White.

https://www.dreamsongs.com/Files/clos-book.pdf

The MOP itself was thought to make CLOS programmable and thus to support a wide range of different object-oriented styles in a single language framework. In practice there is use of that, but it's not that common and actually also a bit complicated/tricky/challenging to program the object system in itself for different behavior.

Every modern CL compiler (SBCL, CCL, ECL)... will implement it 'de facto'.

It's just that "it" has no defined standard. See https://github.com/pcostanza/closer-mop/blob/master/features... for the MOP differences on platforms which have support.

Closer to MOP is a library which tries to fix many/most of these differences.

https://github.com/pcostanza/closer-mop

Well yes. The problem isn't people building their own implementation. The problems with Scala aren't with them inventing their own type system, or pattern matching, or whatever. It's the lack of agreement on what is the idiomatic subset of features to use in a given environment.

Reply on news.ycombinator.com