It is very easy, as engineers, to forget how incredibly important it is to articulate what we work on. Not only to explain to our families, but to bridge the gap between the technical and the non-technical people.
Engineers, specially really good ones, a lot of times feel proud of understanding something no one else does. Proud to the point of not caring whether the audience understand even though you might be in a setting where it is to your advantage to have your audience understand (for example, when you are trying to tell people why your product is better than the competition's).
More people in the technical world should strive to bridge the gap rather than widen it to show their "superior intelligence." (Which isn't all that superior, it's far smarter to be able to communicate, which makes you useful. Inability to communicate makes you merely a curiosity)
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.
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?
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!
I had the same trouble trying to explain FP to my friend/programmer buddy. The best I could come up was FP lets you write efficient code and you can be as clever as you want.
Another technology that I was stumped trying to explain to laymen was IoC (Inversion of Control) containers. I used a lot of cliches like "holy grail of programming" etc., but only someone who has used IoC containers can appreciate how easily you can build loosely cooupled components.
There must be better ways of explaining FP to laymen or may be not at all...
"write efficient code" / "be as clever as you want" doesn't actually tell anybody anything, though. If they know C, try to explain the idea of higher-order functions, etc. in terms of passing around function pointers, perhaps. Also, definitely something about trying to contain side effects as much as possible. Maybe relate it to the sort of problems with global variables that have bitten most people at some point? If they are sufficiently interested, I would point them to the John Hughes paper, "Why Functional Programming Matters" ( http://www.cs.chalmers.se/~rjmh/Papers/whyfp.html ) and Raganwald's post about it ( http://weblog.raganwald.com/2007/03/why-why-functional-progr... ). Then, OCaml or Haskell.
When talking to non-programmers (i.e., most people), try to speak their language, especially if you know their interests / areas of expertise. Failing that, I usually fall back on cooking, because even if somebody doesn't have any experience making bread from scratch or what have you, it's not completely out of left field the way science and math can be. Everybody eats.
My spiel goes something like it means programming without side effects, which are changes in the state of the world caused by performing computation. Such as opening a gateway to the Hell Dimension. People generally agree then that functional programming is a good thing.
It is very easy, as engineers, to forget how incredibly important it is to articulate what we work on. Not only to explain to our families, but to bridge the gap between the technical and the non-technical people.
Engineers, specially really good ones, a lot of times feel proud of understanding something no one else does. Proud to the point of not caring whether the audience understand even though you might be in a setting where it is to your advantage to have your audience understand (for example, when you are trying to tell people why your product is better than the competition's).
More people in the technical world should strive to bridge the gap rather than widen it to show their "superior intelligence." (Which isn't all that superior, it's far smarter to be able to communicate, which makes you useful. Inability to communicate makes you merely a curiosity)