3 ms·
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
by 6ren 16y ago
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.
- gchpaco 16y agoI 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.