Re: Oft-shared (perhaps?) Impressions of a Lisp Newbie

On Apr 11, 7:09 pm, nefi...@xxxxxxxxx wrote:
My concern, however, as I proceed through the book, is the increasing
number of things it seems to require me to keep in my brain. It has me
worried that the pure effort of memorization will be staggering, as
the built-in functions and macros seem quite unintuitive to me. setf
or getf or setq or eq or eql or defvar or defparameter or funcall or
apply or return or return-from or let or let* or...

Some of the software projects that people work on dwarf the complexity
of programming languages.

Today I performed a three-way merge on a codebase consisting of 25,000
source files, taking up around half a gigabyte.

1) Is there a pretty steep "memorization curve" for the "standard
library" of Common Lisp?

A professional developer works with lots of tools, all of which have
some kind of memorization curve.

If something isn't in the language, it will be in some common library,
or perhaps in a common code generation tool (or macro library, in the
case of Lisp). If it's not in a common library or macro, you will whip
it together yourself. And other programmers will whip together
themselves something which is similar, but different and incompatible.

You can't reduce your memorization curve by eliminating something
essential in one place. The complexity shows up elsewhere. If
eliminating one unit of complexity over here causes ten units to crop
up elsewhere, you are losing.

As a rule, pushing complexity into programming language reduces
complexity by reducing the number of wheels that are reinvented.

In a large C project, you might find M linked list libraries and N
character string libraries. I'd rather learn one list manipulation
library containing 50 functions, than 10 libraries containing 10
functions.

(i.e., are my first impressions correct?)

You're only a newbie once (hopefully; alas, unfortunately, there do
exist permanent newbies). So one day you will not even remember your
first impression. It's not a question of whether or not it is correct,
but rather that it is not something of value that will stick with you.

so, what tools are out there to aid in overcoming that? (SLIME is
great at helping once you already know what function/macro/whatever is
right for the job, but until then...)

The symbols in the Common Lisp language are organized into subsystems.
So for instance everything having to do with the lexical analysis of
the printed representation of Lisp objects (and thus Lisp source code)
is part of the reader, which is covered in Chapter 23 of the Common
Lisp HyperSpec. You don't have to memorize everything about the
reader; you just have to develop an intuition for what types of
problems are solved in a way that somehow involves the reader, and
where to find the documentation for that part of Lisp.

Similarly, if you are working with sequences (lists or vectors) of
items, there is a sequences library. It's good to know it, but you
don't have to remember everything. If some problem requires the
extraction of data from a sequence of other some such manipulation,
you can glance through the Sequences Dictionary (17.3) to see whether
anything rings a bell.

The more years you spend as a programmer, the more you learn ways to
avoid memorizing reams of stuff. You need to have the information
summarized in your head, in a kind of structure of hierarchical
detail. There are two somewhat competing goals: 1) avoid spending too
much time searching for something and 2) do not get caught in some
``local maximum'' whereby you think you have found the best solution
but are overlooking something.

To the newbie, it looks as if total memorization must be the answer to
satisfy these goals at the same time. How do you know that you aren't
overlooking something if you don't have everything in your head, and
do not recursively traverse every shred of documentation?

What happens is that you end up internalizing architectural patterns.

Here is an analogy. All of the world's airports are different. But
after a bit of traveling, you can find your way around in them quite
easily.

2) Is the Lisp way of programming truly worthwhile to my overall skill
and mindset as a programmer? More directly, is it worth sinking the
hours into for this purpose? If you were in my shoes, as a new
programmer in 2008 with few preferences or barriers with regard to
what to learn, would you learn Lisp? If so, how would you attack it?

If I were a new programmer in 2008, I have no clue what that would be
like, sorry. I was an ``old'' programmer in 2001, and the answer was
yes, to plunge in the Lisp thing.
.

Relevant Pages
Loading