Explaining Lisp to my father
jakevoytko.com
jakevoytko.com
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)
[Or die, wait 50 years and then get understood and explained by someone obsessed with your obscure work.]
Beyond: the ability to communicate properly puts down your bus ticket a lot: your software may survive your interest in it.
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.
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?
Lisp is more like a machinist's shop. It takes considerably more skill, but the system is much more customizable.
Most projects can be done with either, but some are easier or more efficient in one or the other. ___
I would have posted on the blog, but it seems to have some error with the commenting system. :)
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...
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.