3 ms·

With macros being so easy to write, and so idiomatic to the way the language is used, isn't it very difficult to understand a Lisp codebase that you are unfamil

With macros being so easy to write, and so idiomatic to the way the language is used, isn't it very difficult to understand a Lisp codebase that you are unfamiliar with? While I like Lisp a lot for my own projects (well Racket in Dr. Racket to be specific), I don't feel very comfortable trying to understand other people's code. Other languages like Go, for example, seem a lot more tractable when you have to grok a large foreign codebase.

sklogic 11y ago
If macros are used properly, i.e., for implementing nice, multi-staged, composable eDSLs, instead of just another anaphoric if or similarly useless "extension", then a Lisp codebase is much easier to read than anything that does not allow implementing macro-based eDSLs.
mbrock 11y ago
Do you have concrete examples of this difficulty? I very often find it difficult to understand code in non-Lisp languages, too. For example, you may think you know Ruby, but that has nothing to do with understanding Rails or its myriad metalinguistic tricks. Abstractions are often difficult to understand, and require explanations. Introducing a new abstraction, regardless of implementation language, puts the burden on you to define it with clarity, to document its purpose and meaning, and so on. Lisp macros let you define abstractions in a certain way that's quite powerful. Fortunately, Lisp systems also tend to have good provisions for online documentation, and make available macro-expansion facilities that immediately explain exactly what a given macro is doing.
dllthomas 11y ago
In general, the more you can package up into single abstractions, the more someone will have to learn to thoroughly understand your code base. If those abstractions fit the problem domain well, hopefully they will ease the overall cognitive load of working in the system, even somewhat early on, but there will always be some ramp-up time. I'm not at all sure it's a big problem, just something you need to be aware of.
soegaard 11y ago
Experience says no. There are several reasons, but * macros are only used when functions doesn't make sense * there are documentation * most follow the conventions of the language

sklogic 11y ago

If macros are used properly, i.e., for implementing nice, multi-staged, composable eDSLs, instead of just another anaphoric if or similarly useless "extension", then a Lisp codebase is much easier to read than anything that does not allow implementing macro-based eDSLs.

mbrock 11y ago

Do you have concrete examples of this difficulty? I very often find it difficult to understand code in non-Lisp languages, too. For example, you may think you know Ruby, but that has nothing to do with understanding Rails or its myriad metalinguistic tricks. Abstractions are often difficult to understand, and require explanations. Introducing a new abstraction, regardless of implementation language, puts the burden on you to define it with clarity, to document its purpose and meaning, and so on. Lisp macros let you define abstractions in a certain way that's quite powerful. Fortunately, Lisp systems also tend to have good provisions for online documentation, and make available macro-expansion facilities that immediately explain exactly what a given macro is doing.

dllthomas 11y ago

In general, the more you can package up into single abstractions, the more someone will have to learn to thoroughly understand your code base. If those abstractions fit the problem domain well, hopefully they will ease the overall cognitive load of working in the system, even somewhat early on, but there will always be some ramp-up time. I'm not at all sure it's a big problem, just something you need to be aware of.

soegaard 11y ago

Experience says no. There are several reasons, but * macros are only used when functions doesn't make sense * there are documentation * most follow the conventions of the language