

Explaining Lisp to my father - craigbellot
http://www.jakevoytko.com/blog/2008/07/21/explaining-lisp-to-my-father/

======
gm
Cool post.

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)

~~~
bprater
Ding, ding, ding. Great thoughts.

------
parenthesis
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
_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
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!

------
ibsulon
Most languages are like a Home Depot. You have big pieces in the end and you
assemble, usually in predictable forms. It's easier, but not as flexible.

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. :)

~~~
Chocobean
Home Depot's slogan: "You can do it, we can help." Lisp's slogan: "You can do
it." (emphasis on "you" doing it and lack of offer to help)

------
senthil_rajasek
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...

~~~
bprater
FP is function pointers, functional programming, Frontpage, floating point,
frame pointer, flower power?

~~~
staticshock
around here? functional programming

------
bprater
I appreciate folks who take a shot at explaining a difficult concept in ways
that other folks can take a stab at understanding.

