5 ms·

Agreed that it _can_ make code challenging to understand. However, the engineer in me thinks that this is not a linguistic deficit, but rather illustrates poor

Agreed that it _can_ make code challenging to understand. However, the engineer in me thinks that this is not a linguistic deficit, but rather illustrates poor judgement and taste on the part of the implementors. The litmus test of 'can this be expressed as a function?' will usually suffice for determining whether or not macros are being abused. Under this rule, debugging macros is no harder than debugging "normal" code. Of course, people will disagree with me regarding poor taste, offering something that boils down to "if everyone using a tool is doing something poorly, then surely the tool is to blame." The problem is (1) that obviously isn't true as it boils down to a fundamental lack of skill and (2) in this case, there are numerous examples on the web of good use of macros that make code easier to understand. Tools themselves are casually inert and deserve no blame for the outcome of their uses as directed by the will of a separate entity, i.e. the programmer. Judicious (read: professional) usage of macros will only ever make code easier to understand. If a macro is obfuscating meaning, then the macro has been used poorly. Luckily, a few books (LOL) have numerous examples of tastefully done macros. Lots of Clojure libraries have also shown what macros can do. TL;DR: we're free to write good code, we're free to write bad code.

fake-name 10y ago
Sure you're "free" to write bad code, but the language can either assist or make it harder. Python is designed with the express purpose of making writing horrible code at lest a little bit harder to do. I did not (and do not) claim that there are not cases where macros can result in more readable code. However, I don't think you can dispute that, on the whole, macros lead to generally less readable code. The point here is that if a language feature is mostly known for it's negative effects, maybe it's not a good feature?
- bthornbury 10y ago
  > Python is designed with the express purpose of making writing horrible code at lest a little bit harder to do. This will of course depend on your definition of "horrible code" but in general I don't agree with this. From the standpoint of horrible code being non-readable there exists many constructs in python that don't lend themselves to readable code despite being very useful and expressive. Not that an experienced practitioner cannot invent patterns to make these constructs as readable as possible (list comprehensions are top of mind here). I think the key here is for the practitioner to invent the patterns that make constructs like macros usable. In the right contexts, they're incredibly powerful and can increase the productivity of an individual, and when used right even a whole team. > The point here is that if a language feature is mostly known for it's negative effects, maybe it's not a good feature? I would counter that it's likely not a feature for beginners, rather than being a bad feature.

fake-name 10y ago

Sure you're "free" to write bad code, but the language can either assist or make it harder. Python is designed with the express purpose of making writing horrible code at lest a little bit harder to do. I did not (and do not) claim that there are not cases where macros can result in more readable code. However, I don't think you can dispute that, on the whole, macros lead to generally less readable code. The point here is that if a language feature is mostly known for it's negative effects, maybe it's not a good feature?

bthornbury 10y ago
> Python is designed with the express purpose of making writing horrible code at lest a little bit harder to do. This will of course depend on your definition of "horrible code" but in general I don't agree with this. From the standpoint of horrible code being non-readable there exists many constructs in python that don't lend themselves to readable code despite being very useful and expressive. Not that an experienced practitioner cannot invent patterns to make these constructs as readable as possible (list comprehensions are top of mind here). I think the key here is for the practitioner to invent the patterns that make constructs like macros usable. In the right contexts, they're incredibly powerful and can increase the productivity of an individual, and when used right even a whole team. > The point here is that if a language feature is mostly known for it's negative effects, maybe it's not a good feature? I would counter that it's likely not a feature for beginners, rather than being a bad feature.