Have you ever found it difficult to understand someone else's lisp project, because they have customized the language so much? (or vice versa, has a fellow lisper found your code hard to understand)
I wonder if the flexibility and power of lisp might work against co-operation in this way too.
I've witnessed confusion caused by operator-overloading in C++ (I heard that that's common); lisp is more customizable.
> Have you ever found it difficult to understand someone else's lisp project, because they have customized the language so much?
Yes. But that is not a problem unique to Lisp. It's possible to write unreadable code in any language. And in general Lisp's introspection capabilities and macroexpand make it easier to reverse-engineer things that in other languages.
opps, I what you mean; I actually meant well-written lisp.
Have you found that hard to understand, when it was heavily customized? I agree that tracing through complex code is taxing in any language; and it probably becomes much more important what concepts the author has chosen (and things like coupling/cohesion), than the language.
i.e. That the problem wasn't that the code was badly written, but it was because they had "customized the language so much". Extensive customization i how you're supposed to use lisp; it's an important source of its power. (The C++ example I mentioned was well-written.)
I can imagine it going either way (e.g. that lisp's customizations often aid clarity, by reducing code size); so I'm interested to hear someone's experience of how it actually goes in practice.
I have seen that happen before, but only when the domain was inherently complex. An example I actually committed; for a variety of reasons I needed a continuation driven LL(1) parser for my PhD thesis, and I needed it to be in Java. I wrote this as a Scheme program that output Java code. I tried hard to make things understandable (since I had to debug all of it!) but the Java code was basically incomprehensible and the Scheme program that generated it required some relatively sophisticated understandings of parser theory to understand the notation I was using.
A good theoretical example is: imagine trying to understand what a CPS driven compiler is doing with no understanding of CPS. That would be pretty hard in any language, and it's actually better in Lisp because you can express things closer to the theory.
I wonder if the flexibility and power of lisp might work against co-operation in this way too.
I've witnessed confusion caused by operator-overloading in C++ (I heard that that's common); lisp is more customizable.