3 ms·

I liked this comment from/on the post: Cory on July 21st, 2008 3:16 am My Father is a carpenter and a hobby mechanic. My best shot and explaining how Lisp is

I liked this comment from/on the post: Cory on July 21st, 2008 3:16 am My Father is a carpenter and a hobby mechanic. My best shot and explaining how Lisp is different would be something like: Programming languages are collections of tools to make products. “Language A vs. Language B” is usually similar to “Saws and Hammers vs. Wrenches and Screwdrivers”. Lisp, however, is a collection of solid and useful tools that are amazingly made entirely out of Lego bricks. If you need a new tool, you can easily make one on the fly. You can even build configurable Lego machines that spit out custom Lego creations on demand. But, you have to be careful that you don’t end up with a shop full of oddities that even you don’t understand anymore.

gruseom 18y ago
But, you have to be careful that you don’t end up with a shop full of oddities that even you don’t understand anymore. You always have to be careful of this, regardless of what language you're working in. It's a problem with complex code in general that has nothing to do with macros or Lisp. Indeed the problem is worse in lower-level languages, not higher-level ones which have more tools available to combat obscurity. I realize you're only quoting; my dispute is with the quoted point which gets repeated a lot, usually along the lines of "macros are powerful but complicated, so they're risky". This just isn't true, except in the trivial sense that they seem risky to people who aren't familiar with them. Macros do introduce some complexity. You have to understand the difference between macro-expansion time, compile time, and runtime. You can't just pretend that macros are functions. But the idea that macros yield code "oddities" that are complex and hard to understand seems ignorant to me. Macros abstract away repetitive noise, leaving only the unique stuff that the code is doing. Almost by definition the resulting code will tend to be more readable, not less. The point is to make code simpler, not more complicated. Why else would people write it?
- silentbicycle 18y ago
  Yes, definitely. A big benefit of macros is being able to abstract away boilerplate and reduce code to what it actually means. If extracting repeated type declarations and syntactic noise makes your code harder to understand, you have much bigger problems than using macros well!

gruseom 18y ago

But, you have to be careful that you don’t end up with a shop full of oddities that even you don’t understand anymore. You always have to be careful of this, regardless of what language you're working in. It's a problem with complex code in general that has nothing to do with macros or Lisp. Indeed the problem is worse in lower-level languages, not higher-level ones which have more tools available to combat obscurity. I realize you're only quoting; my dispute is with the quoted point which gets repeated a lot, usually along the lines of "macros are powerful but complicated, so they're risky". This just isn't true, except in the trivial sense that they seem risky to people who aren't familiar with them. Macros do introduce some complexity. You have to understand the difference between macro-expansion time, compile time, and runtime. You can't just pretend that macros are functions. But the idea that macros yield code "oddities" that are complex and hard to understand seems ignorant to me. Macros abstract away repetitive noise, leaving only the unique stuff that the code is doing. Almost by definition the resulting code will tend to be more readable, not less. The point is to make code simpler, not more complicated. Why else would people write it?

silentbicycle 18y ago
Yes, definitely. A big benefit of macros is being able to abstract away boilerplate and reduce code to what it actually means. If extracting repeated type declarations and syntactic noise makes your code harder to understand, you have much bigger problems than using macros well!