Oft-shared (perhaps?) Impressions of a Lisp Newbie
nef...@gmail.com
In need of something to occupy my brain this week, I decided to start
reading the excellent Practical Common Lisp book and trying my hand at
the language.
I am new to programming, and have really only been doing it a couple
years, with experience in Ruby, C#, C, PHP, a bit of Java, and more
recently Perl. I fancy myself an open-minded newbie, and have tried to
approach each language without being biased by what I have heard about
that language. And really, I have enjoyed seeing how each has its own
particular strengths and gives me more perspective as a programmer.
Even when I don't care for using a language (like PHP) I appreciate
the things that it makes simple or simpler. (The only language that's
really rubbed me wrong, actually, is C++... for some reason,
everything I've done in it has seemed unnecessarily complicated. I
imagine, as a newbie, I'm incapable of yet grasping its strengths,
which I imagine come in forms like 3D game engine development, which
are too much for my poor brain to handle.)
My first glimpse at Lisp came a few weeks ago when I started learning
Emacs. It looked quite foreign to me, but I did appreciate how
integrated it was with the editor--programming in a programmable
editor is pretty neat :)
And after making it through a few chapters of Practical Common Lisp,
it's been cool to see that Lisp is really so modern in a lot of ways,
supporting lots of the features I love from other languages. (P.S.,
SLIME is awesome.)
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...
Now, I don't doubt for a minute that that all becomes obvious once you
have all those names memorized, and I realize that the whole point of
the book I am reading is to explain such things. I'm simply worried
that there seems to be a general pattern of a very complicated "API",
with a lot of similarly-named constructs, arbitrary abbreviations,
etc.
Learning about a language is easy and fun--learning a language well is
an investment. As an extension of my brain--a tool to translate my
thoughts into instructions--I think a language will have to "mesh"
with my style in order for me to be an effective programmer in it. I
fought for a long time with the "Ruby way" of doing things, as it was
different from what I learned in C#. But I felt it was instructive and
helpful in the long run.
I would therefore like to ask of you, Lispers, 2 things:
1) Is there a pretty steep "memorization curve" for the "standard
library" of Common Lisp? (i.e., are my first impressions correct?) If
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...)
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?
I know this has been long and probably rambling; sorry! But I greatly
appreciate any response--even the "get back to PHP if your widdle
bwain hurts, noob" ones :)
-J
Pascal Bourguignon
No, the curve is not steep. It just goes up and up for a long time.
Plan to spend ten years on lisp before starting to leave the newbie
state.
That is not as bad as it sounds. First for a lot of domains, you
really need ten years to master it. Then, Common Lisp is actually a
language + a library ( + a lot of third party libraries ). You don't
need to know everything before becoming proficient in CL.
> 2) Is the Lisp way of programming truly worthwhile to my overall skill
> and mindset as a programmer?
Yes.
> More directly, is it worth sinking the
> hours into for this purpose?
Definitely.
> 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?
I would learn only lisp. I only regret having lost my time on all the
other programming languages (but perhaps 680x0 assembler).
> If so, how would you attack it?
Well, you're on the right path. Finish PCL. Have some fun writing
some code. Be sure to use intensively the HyperSpec reference. And
start reading SICP:
Structure and Interpretation of Computer Programs
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html
http://swiss.csail.mit.edu/classes/6.001/abelson-sussman-lectures/
But write some code!
This is the best way to learn and understand why all these operators
exist.
GETF is unrelated to SETF.
You can mostly forgot SETQ and always use SETF. SETQ is like SETF
only it's limited to simple symbols as the places to be assigned. It
cannot do anything that SETF cannot do.
DEVAR is very different than DEFPARAMETER. DEFVAR assigns the
variable defined only if it is not already defined. DEFPARAMETER
assigns it always.
(defvar *x* expr) =~= (progn (declaim (special *x*))
(unless (boundp '*x*)
(setf *x* expr)))
(defparameter *x* expr) =~= (progn (declaim (special *x*))
(setf *x* expr))
Imagine you define variables in a file, and then you load this file,
run some functions, which change the state of these variables, and
then reload this file. For some of these variable, you may want the
value to be reset, but for some others you may rather want to keep the
changed value. For example, if the variable holds a database storing
user input, you may not want to lost it just because you reload the
file to take into account some debugged function. DEFVAR is for these
variables you don't want to reset everytime you load the file.
Otherwise you use DEFPARAMETER. (In fact, by default I use DEFPARAMETER).
Another case, is when you define some global parameters for your
program. Perhaps the user will want to set these parameters before
loading the program (eg. in the initialization file of the lisp
implementation). Then when you load your program file, you don't want
to reset the user's settings, so you'll use DEFVAR instead of
DEFPARAMETER (yes, I find also that the names have been swapped).
You can define FUNCALL with APPLY:
(defun funcall (func &rest args) (apply func args))
but you cannot define APPLY with FUNCALL. APPLY is more primitive.
But it is easier to write (funcall operation 1 2 3) than (apply
operation (list 1 2 3)). That's why CL defines funcall, to avoid that
every programmer defines his own funcall function. Remember, CL is a
_practical_ programming language, it tries to provide some niceties
and useful tools some other languages leave up to libraries or to
divergent implementations.
Similarly, RETURN is defined as:
(defmacro return (result) `(return-from nil ,result))
Since there are a lot of blocks named NIL implicitely defined by the
various flow control operators, most returns are done from blocks
named NIL and it's tiring to write always (return-from nil expr)...
The difference between LET and LET* is also important.
(let* ((a1 e1)
(a2 e2)
...
(aN eN))
body)
is equivalent to:
(let ((a1 e1))
(let ((a2 e2))
...
(let ((aN eN))
body)))
and when any of the expression ei refers some variable aj with j<i,
it's very different from:
(let ((a1 e1)
(a2 e2)
...
(aN eN))
body)
which evaluates all the expression BEFORE creating the variables aj.
(lambda (a b)
(if (< a b)
(print `(< ,a ,b))
(let ((a b)
(b a)) ; This refers the parameter a of the function,
; not the variable bound on the preceding line.
(print `(< ,a ,b)))))
(let ((a 0) (b 0) (c 0))
(let* ((c 1)
(b (+ c 2))
(a (+ b 3)))
(list a b c))) --> (6 3 1)
(let ((a 0) (b 0) (c 0))
(let ((c 1)
(b (+ c 2))
(a (+ b 3)))
(list a b c))) --> (3 2 1)
So LET and LET* are very different, and depending on the case, you may
want to use one or the other. But to know that, you must write enough
code for these cases to occur to you.
> I know this has been long and probably rambling; sorry! But I greatly
> appreciate any response--even the "get back to PHP if your widdle
> bwain hurts, noob" ones :)
--
__Pascal Bourguignon__ http://www.informatimago.com/
Wanna go outside.
Oh, no! Help! I got outside!
Let me back inside!
D Herring
> 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?
It depends.
Take me. I've tinkered with Lisp at home; but I'm paid to develop C++
(and occasionally Java or Matlab) at work.
Today, you can hear the screams of "its 2008 and C++ still doesn't
have {lambda functions, multi-methods, macros, runtime function
redefinition, garbage collection, ...}?!?"
Before learning Lisp, these were mere murmers of "C++ is hard."
Half my assignment for the past two years has been an object lesson in
Greenspun's tenth.
Back on topic: Do you prefer hammering away with primitive tools,
a) not knowing any better
or
b) because the power tools aren't OSHA approved
?
Yeah, Common Lisp is missing big pieces of useful functionality -- but
that's due more to the small, often eccentric community than to the
language itself.
You just have to learn to look past the parentheses. See code for
what it is -- data which the computer manipulates and eventually
executes. Most languages try to hide this simple truth. They pretend
the compiler is some invariant virtual machine which shouldn't be touched.
- Daniel
Ken Tilton
> worried that the pure effort of memorization...
"memorization"? Did you say "memorization"? Awesome, I am submitting a
proposal to O'Reilly tomorrow to publish a set of Lisp flash cards so we
can memorize the thousand-page index.
Silly me, I have been using apropos and hitting F1 to automatically look
things up!
>... will be staggering, as
> the built-in functions and macros seem quite unintuitive to me.
Thank god you started with "I know nothing about programming" or I would
be sitting here trying to figure out how the most intuitive library
extant could be construed as counter-intuitive.
> 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...
well, ok...
>
> Now, I don't doubt for a minute that that all becomes obvious once you
> have all those names memorized,
You just said that word again. Could you please stop it or even better
completely go away until you have programmed even a goddamn tower of
hanoi? Jesus H! I have the same problem with Chinese, I took ten classes
and I am worried about how I am going to /memorize/ the whole thing!
And what about the guitar? I bought one and hit some of the strings and
I am worried about how I am going to memorize all the motions it will
take to be like Hendrix! Do they have flash cards for guitars??? I can
only hope...
>... and I realize that the whole point of
> the book I am reading is to explain such things. I'm simply worried
> that there seems to be a general pattern of a very complicated "API",
> with a lot of similarly-named constructs, arbitrary abbreviations,
> etc.
I recommend 6502 assembler. Ok, three addressing modes, but beyond that
you could /memorize/ it in a night. <sigh>
>
> Learning about a language is easy and fun--learning a language well is
> an investment. As an extension of my brain--a tool to translate my
> thoughts into instructions--I think a language will have to "mesh"
> with my style in order for me to be an effective programmer in it.
Your style being "I have no intention of actually programming anything
so there is very little chance I will get fluent in any language"?
> I
> fought for a long time with the "Ruby way" of doing things, as it was
> different from what I learned in C#. But I felt it was instructive and
> helpful in the long run.
Oh, good, go back to Ruby, quick!
>
> I would therefore like to ask of you, Lispers, 2 things:
>
> 1) Is there a pretty steep "memorization curve" for the "standard
> library" of Common Lisp? (i.e., are my first impressions correct?) If
> so, what tools are out there to aid in overcoming that?
Sorry, just heard back from O'Reilly: No Lisp submissions welcome. :(
>(SLIME is
> great at helping once you already know what function/macro/whatever is
> right for the job, but until then...)
Try (apropos "APROPOS"), see what turns up. <sigh>
>
> 2) Is the Lisp way of programming truly worthwhile to my overall skill
> and mindset as a programmer?
There's a fat pitch. Thanks!
> More directly, is it worth sinking the
> hours into for this purpose?
if you were not a complete waste of time you would be Actually
Programming, not grandstanding in this NG with your handwringing.
> 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?
STFU and write some code? Too easy? Oh, I forgot, you have no interest
in programming.
> I know this has been long and probably rambling; sorry! But I greatly
> appreciate any response--even the "get back to PHP if your widdle
> bwain hurts, noob" ones :)
Sh*t, if I had read this far I could have saved myself a lot of trouble.
Really, you are not cut out for this game, I recommend tennis--the new
racquets are awesome.
hth, kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"I've never read the rulebook. My job is to catch the ball."
-- Catcher Josh Bard after making a great catch on a foul ball
and then sliding into the dugout, which by the rules allowed the
runners to advance one base costing his pitcher a possible shutout
because there was a runner on third base.
"My sig is longer than most of my articles."
-- Kenny Tilton
Paul Donnelly
> 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...
Once you've internalized these common functions (hint: write some code),
I think you'll find that Lisp actually requires you to keep fewer things
in your brain, since its syntax is so regular. Don't worry about
remembering the proper arguments or argument order to functions like
GETHASH -- SLIME will remind you. Similarly, there's no need to remember
every function in the language. You just want to know them well enough
that something in the back of your mind tells you to check the library
before you go rewriting half of it.
> 1) Is there a pretty steep "memorization curve" for the "standard
> library" of Common Lisp? (i.e., are my first impressions correct?) If
> 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...)
Not especially. You can write useful code with only a handful of
functions. It's easy to learn enough of them to get going, and the
others will just seep in as you go.
> 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?
Common Lisp, for all the "Lisp is different", is a practical
language. If I were a new programmer and learning Lisp was some kind of
nebulous self-improvement exercise I'd put it on the back burner next to
Haskell. But Lisp is useful and actualy fun to use, so I'd learn it.
joseph....@googlemail.com
> 1) Is there a pretty steep "memorization curve" for the "standard
> library" of Common Lisp? (i.e., are my first impressions correct?) If
> 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...)
I had a pretty similar viewpoint to you, when I began learning (from
Paul Graham's ANSI Common Lisp) that there seems like an awful lot of
things which are counterintuitive and hard to remember.
What I did was that I went away and started to learn Scheme; which has
much simpler naming conventions but the same basic syntax as Common
Lisp. When I finished reading about Scheme I went back to Common Lisp
and I'm finding it a lot easier now.
You can find the excellent `Teach Yourself Scheme in Fixnum Days' for
free all over the web, just Google it
Hope it helps!
Joseph
John Thingstad
> Hello!
>
>
> I would therefore like to ask of you, Lispers, 2 things:
>
> 1) Is there a pretty steep "memorization curve" for the "standard
> library" of Common Lisp? (i.e., are my first impressions correct?) If
> 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...)
>
Well I remember when I was learning Common Lisp the task was somewhat
daunting.
You might want to read "Teach Yourself Programming in Ten Years" by Peter
Norvig
http://norvig.com/21-days.html
In the beginning it is bound to be some memory overload.
There are a few things that might help.
1. Learn to look things up (context sensitivity) in the hyper-spec from
SLIME.
2. Look at other peoples code. Find something that almost does what you
want and modify it.
3. Learn from experts.
Kent Pitman, Edi Weitz, Pascal Costanza, Pascal Bourmignon, Russel
Crowe, Ron Garreth
might be some of the names on comp.lang.lisp to look out for.
After a while you will learn to to see this yourself.
4. Ask questions. You will find people on comp.lang.lisp can provide
guidance, reviews and suggestions for improvement. Note that questions on
the line "What is wrong here?" or "Is there a better way to do this?" get
better treatment than things on the form "Solve this for me.". Effort
counts..
5. Write code. Remember that if it seems simple its hard, if it seems hard
it's damn near impossible. So adjust you ambitions accordingly. Start
simple. Do lots of small programs. Write code to test whether you
understood some parts etc. Then as you confidence grows scale up.
6. Use the REPL. If in doubt try running the program section in the REPL
and see if it does what you expect. Write a function, test a function
seems to work pretty well.
7. As for "Tools" what about
CL-COOKBOOK http://cl-cookbook.sourceforge.net/
cliki http://www.cliki.net/index
Norvig http://norvig.com
SLIME tutorial video
http://video.google.com/videoplay?docid=-2140275496971874400
Http server writing video
http://homepage.mac.com/svc/LispMovies/index.html
> 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?
>
Lisp is programming language for people that like to program.
In the end only you can say whether you find it worth it.
--------------
John Thingstad
Tayssir John Gabbour
> 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...
The situation isn't so linear as it may seem; these things aren't
equally used. For instance, I almost never use return and return-from.
It is perhaps better to get a vague sense of what things do, then look
them up when needed.
Also, there's a couple sources which I've found very helpful in
segmenting the soup of operators:
* "Common Lisp the Language, 2nd ed"
* the appendix of Paul Graham's "Ansi Common Lisp"
True, Common Lisp doesn't nicely segment built-in operators into
separate packages, as in many other languages.
> 1) Is there a pretty steep "memorization curve" for the "standard
> library" of Common Lisp? (i.e., are my first impressions correct?) If
> 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 memorization doesn't have to be rote or "intellectual". I'm
reminded of Alan Kay's claims in "Doing with images makes symbols."
http://video.google.com/videoplay?docid=-533537336174204822#51m0s
> 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?
Unclear. If you are familiar with Emacs, Slime and ASDF, then you've
greatly lowered the obstacles to using Lisp. (Potential obstacles
include "batteries not included," social/community problems, library
incompleteness, etc.)
Personally, I probably would've been driven to learn Lisp (by that I
mean a family of languages culminating in Common Lisp, such as those
used on the Lisp machines) because... in certains ways it's saner than
other programming languages. I don't have much time to explain this
further.
> I know this has been long and probably rambling; sorry! But I greatly
> appreciate any response--even the "get back to PHP if your widdle
> bwain hurts, noob" ones :)
Actually, I suspect other languages may impose more of an intellectual
burden. Certain things are harder in those languages, because you're
pretty much stuck with the special operators they offer (for loops,
etc) unless you go outside the language.
Tayssir
viper-2
> 3. Learn from experts.
> Kent Pitman, Edi Weitz, Pascal Costanza, Pascal Bourmignon, Russel
> Crowe, Ron Garreth
> might be some of the names on comp.lang.lisp to look out for.
John, yes these are some of my favourite Lisp gladiators too - but
don't you mean "Alan Crowe" and not "Russell Crowe" ? :-)
agt
John Thingstad
<visi...@mail.infochan.com>:
lol.. Yes just took it from the top of my head.
(But I liked him in "Far side of the World"!)
--------------
John Thingstad
Ken Tilton
You, sir, have a beautiful mind.
Meanwhile, I can't believe how nice everyone is being to the OP. Why
doesn't some one just admit that Lisp is hard, then we can all go shopping?
viper-2
> På Sat, 12 Apr 2008 15:43:21 +0200, skrev viper-2
>
> > On Apr 12, 4:27 am, "John Thingstad" <jpth...@online.no> wrote:
> >> På Sat, 12 Apr 2008 04:09:23 +0200, skrev <nefi...@gmail.com>:
>
> >> 3. Learn from experts.
> >> Kent Pitman, Edi Weitz, Pascal Costanza, Pascal Bourmignon, Russel
> >> Crowe, Ron Garreth
> >> might be some of the names on comp.lang.lisp to look out for.
>
> > John, yes these are some of my favourite Lisp gladiators too - but
> > don't you mean "Alan Crowe" and not "Russell Crowe" ? :-)
>
> lol.. Yes just took it from the top of my head.
> (But I liked him in "Far side of the World"!)
>
I've been a bit on the far side of the Lisp world myself lately -
learning Java, of all things!!:-)
Seriously, though, PCL is a good book from all the reviews I've seen,
but I think newbies would be better off combining the gems in PCL with
an introductory book that has loads of "homework" problems. Lisp 3rd
edition worked very well for me, but I gather this might not be a
popular choice. How about "Common Lisp: A Gentle Inroduction to
Symbolic Computation" by David Touretzky (AGI) http://www.cs.cmu.edu/~dst/LispBook/
?
I haven't actually used this book, just briefly skimmed sections of
it; but I've seen good reviews from time to time.
agt
viper-2
> viper-2 wrote:
> > On Apr 12, 4:27 am, "John Thingstad" <jpth...@online.no> wrote:
>
> >>På Sat, 12 Apr 2008 04:09:23 +0200, skrev <nefi...@gmail.com>:
>
> >>3. Learn from experts.
> >> Kent Pitman, Edi Weitz, Pascal Costanza, Pascal Bourmignon, Russel
> >>Crowe, Ron Garreth
> >> might be some of the names on comp.lang.lisp to look out for.
>
> > John, yes these are some of my favourite Lisp gladiators too - but
> > don't you mean "Alan Crowe" and not "Russell Crowe" ? :-)
>
> > agt
>
> You, sir, have a beautiful mind.
Why, thank you Kenny. You are one of my favourite gladiators too, John
just forgot to mention you.;-)
>
> Meanwhile, I can't believe how nice everyone is being to the OP. Why
> doesn't some one just admit that Lisp is hard, then we can all go shopping?
>
Well if you work hard at it, like everything else, it becomes easier.
agt
John Thingstad
<visi...@mail.infochan.com>:
> On Apr 12, 12:06 pm, Ken Tilton <kennytil...@optonline.net> wrote:
>> viper-2 wrote:
>> > On Apr 12, 4:27 am, "John Thingstad" <jpth...@online.no> wrote:
>>
>> >>På Sat, 12 Apr 2008 04:09:23 +0200, skrev <nefi...@gmail.com>:
>>
>> >>3. Learn from experts.
>> >> Kent Pitman, Edi Weitz, Pascal Costanza, Pascal Bourmignon, Russel
>> >>Crowe, Ron Garreth
>> >> might be some of the names on comp.lang.lisp to look out for.
>>
>> > John, yes these are some of my favourite Lisp gladiators too - but
>> > don't you mean "Alan Crowe" and not "Russell Crowe" ? :-)
>>
>> > agt
>>
>> You, sir, have a beautiful mind.
>
> Why, thank you Kenny. You are one of my favourite gladiators too, John
> just forgot to mention you.;-)
>
That would be in the Newbie Warning! section..
(See Naggum complex.)
:)
--------------
John Thingstad
Robert Maas, http://tinyurl.com/uh3t
> I ... have tried to approach each language without being biased
> by what I have heard about that language. And really, I have
> enjoyed seeing how each has its own particular strengths and gives
> me more perspective as a programmer. Even when I don't care for
> using a language (like PHP) I appreciate the things that it makes
> simple or simpler.
The only really good thing about PHP is that it's the only
server-side scripting language available on some free Web-hosting
services, and it's easy to use MySQL on such services. (Also, it
has nice regular-expression facilities built-in, but Perl has
essentially the same services.)
But I like your attitude of looking for what's good about each
language, like why would anybody in their right mind want to ever
use this langauge. Please take a look at this:
<http://www.rawbw.com/~rem/HelloPlus/hellos.html#s4outl>
skip to this section:
* Lesson 6: Briefly comparing the various programming languages
+ Why ever use another language except Lisp?
If you see any really major advantage to any particular non-Lisp
language that I've overlooked, please contact me with your
suggestion, and I might add your info to that section.
> The only language that's really rubbed me wrong, actually, is
> C++... for some reason, everything I've done in it has seemed
> unnecessarily complicated.
Hmm, I took one class in C++, mostly to satisfy requirements for
C++ knowledge in job ads, and although I got an 'A' in the class I
didn't much like it either, although I'd be willing to do some
small programs in C++ if somebody paid me. If you're willing to
deal with destructors, instead of having a decent garbage collector
as with Lisp and Java, C++ might be tolerable.
> My first glimpse at Lisp came a few weeks ago when I started
> learning Emacs.
Beware! That's Emacs-lisp, not Common Lisp, major differences, even
if the core stuff like car/cdr/cons is all the same. Emacs-Lisp is
fine for just getting started at the basics, but you really need to
learn Common Lisp eventually. It's so much better for programming a
wide range of data-processing applications. If you like Emacs as
an environment for development, where you don't have to
copy-and-paste from one window to another but just C-X C-E or
somesuch to execute the current s-expression, then you might
consider implementing a pipe from Emacs to a Common Lisp, whereby
any expresssion you mark in Emacs you can transfer to the Common
Lisp for read-eval-print. The way I did that (to Java BeanShell,
not to Common Lisp) on my laptop (running Linux) was to use a fifo
as the link between the two programs. Anything that Emacs wrote to
the fifo was then read-eval-printed by the other program (Java in
my case, Common Lisp in your future case).
> It looked quite foreign to me, but I did appreciate how
> integrated it was with the editor--programming in a programmable
> editor is pretty neat :)
Yeah, that's the big win about Emacs lisp. (That was a big win
about Macintosh Allegro Common Lisp too, which had Fred as the
editor, basically similar to Emacs, and R-E-P in other window.)
But with my idea for pipe between Emacs and Common Lisp, you can
have that nice Emacs interface with that nicer version of Lisp too.
> 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.
Writing software is *not* like a closed-book exam in college, where
you are forbidden to use any sort of crib sheets/notes, where you
must memorize everything ahead of time or flunk the test. You are
*encouraged* to make liberal use of notes!! I suggest you
copy&paste sample code from whereever you find them (or key them in
manually if you're copying from a book) into a text file, using
whatever editor you like best, rearrange and organize them however
you like, maybe even set up a Web page so that you can browse
through links by just a click instead of having to manually search
for keyword strings. At first you could have the really basic stuff
in your sample-code notes, such as:
Assignment: (setq varName expressionToEvaluateForNewValue)
CONS pairs, access: (car pr) (cdr pr)
modifying: (setf (car pr) expressionToEvaluateForNewValue)
Some of the Lisp experts won't like this, but I recommend starting
with lots of SETQs, a new SETQ at every step, explicitly naming
every intermediate result when you assign to that new variable,
then fetching that value later by referring to that variable again.
In this way the R-E-P loop lets you debug one line of code at a
time. Then when you're ready to define a function, wrap (PROG ()
) around all your lines of code copy the names of the variables to
that () at the top of the PROG, and see if that block of code works
as a whole, then wrap (DEFUN fnName (parameters) ) around your
prog, and wrap return around the result to be returned, and see if
that works. Worry about refactoring into LET* or nested expressions
after you get the basic PROG version working. With punch cards
(1964-1977), refactoring syntax was a royal pain. But with text
editors on your personal computer (1989-present) that allow moving
sub-expressions around easily, refactoring from a PROG to something
more "nice" is so trivial you should plan on refactoring as a
regular course of programming. So do the first draft of an
algorithm the way that makes debugging easiest, then refactor into
the "nice" version later after you're confident of the algorithm.
Me? Yeah, I use my own software as a crib sheet for copy&paste. I
remember something I did before that's similar to what I want to do
now, use grep to find where I did it, load that source into editor,
find where I did it, and copy&paste to my new code I'm working on,
then change the parts that need changing.
By the way, in addition to that book you're reading, and the Common
Lisp hyper-reference, you might also want to glance at my
<http://www.rawbw.com/~rem/HelloPlus/CookBook/Matrix.html>
which tries to organize how-to-do-stuff in six different languages
(including Lisp) according to the one or two datatypes primarily
involved. I stopped work on it because nobody else thought it was
worth the effort, but if you like the basic idea I might get back
to finishing it.
> 1) Is there a pretty steep "memorization curve" for the "standard
> library" of Common Lisp?
No. All you need is (1) understand that basic idea of CONS-cells
and how they relate to nested lists and general binary trees, and
what Read Eval and Print do (Read parses text syntax to produce
CONS-cell structures, Print does the inverse, Eval is the one you
must understand fully), and how the R-E-P loop works, then (2)
build up your crib sheet of templates for doing stuff, starting
with the most basic, and working your way forward through that book
or whatever else you're trying to learn about Lisp.
> 2) Is the Lisp way of programming truly worthwhile to my overall
> skill and mindset as a programmer?
It isn't *the* Lisp way! Lisp supports several different ways to program:
- Procedural: Assign variables, call functions by name.
- Object-oriented: Define classes of objects with methods, invoke methods.
- Functional: Define and use higher-order functionals as first-class citizens.
- Continuation/Iterator: Define and use lazy-evaluated stream-like objects.
- Probably a few more styles that I can't think of at the moment.
and you can intermix all those styles any time you want any way you want.
> More directly, is it worth sinking the hours into for this purpose?
Yes. What other language lets you mix all those styles, and *all*
available within an integrated read-eval-print loop (via stdio or
emacs) for ease of debugging line-at-a-time?
> 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?
Yes.
> If so, how would you attack it?
By making liberal use of crib sheets for snippets of code to copy&paste.
By making liberal use of text editor for organizing the snippets
any way you want, as plain-text edit or as Web page with links.
Mikael Jansson
For homework-style reading, I recommend PAIP (Paradigms of AI
Programming) by Peter Norvig. Short exercises to help you understand
what you've just read about, while assuming you do understand the
basics of programming (just not Lisp).
--
Mikael Jansson
http://mikael.jansson.be
Robert Maas, http://tinyurl.com/uh3t
> I am submitting a proposal to O'Reilly tomorrow to publish a set
> of Lisp flash cards so we can memorize the thousand-page index.
No need. I have an online program that is much more effective at
memorizing flashcards than doing it via manual cards. Try my free
demo sometime (I have existing decks for missing English common
words, English-->Spanish missing common words,
English-->MandarinPinyan single words, and some ESL etc. stuff.)
Log in under the guest account and give it a try.
(Click on Contact Me to see info about guest account, then back at
the main page click on the login form.)
> Silly me, I have been using apropos and hitting F1 to
> automatically look things up!
That works if you happen to remember the right keyword per the
specific jargon of Emacs-Lisp. But an organized outline of stuff
would be useful for browsing in cases where you don't yet know the
jargon keyword.
> I have the same problem with Chinese, I took ten classes and I am
> worried about how I am going to /memorize/ the whole thing!
For the past several months I've been proposing an alternative, for
people who see Chinese text (in newspapers left around in public
places, and on some UHF TV stations that have Chinese-language
programs with Chinese text captions), namely a Web site that lets
you draw a character on your screen and submit it to a lookup
engine which then tells you what that character means, and includes
a link to the UniCode chart for that character which has lots of
additional information about that character. Maybe you'd work with
me to design and test such a system? (I'd do all the actual
Web-site programming.)
Robert Maas, http://tinyurl.com/uh3t
> True, Common Lisp doesn't nicely segment built-in operators into
> separate packages, as in many other languages.
Especially Java perhaps?
Nicely annotated listing of packages:
<http://java.sun.com/j2se/1.3/docs/api/overview-summary.html>
Alphabetical listing of all individual classes:
<http://java.sun.com/j2se/1.3/docs/api/allclasses-frame.html>
For Lisp, I like the idea of organizing according to the primary data type:
- Numbers
- Characters
- Strings and other sequences
- Symbols and the stuff hanging from them (print name, property list, etc.)
- Arrays
- Hash tables
- Streams
- Structures (similar to Pascal or C structs)
- CLOS classes and objects and methods and generic functions
etc.
This is of course after you get past the basic stuff about defining
and calling functions, using symbols as variables, read-eval-print
loop, CONS-based lists and other tree structures, and simple
control structures such as COND LOOP etc.
I've also been toying with organizing according to *two* datatypes:
<http://www.rawbw.com/~rem/HelloPlus/CookBook/Matrix.html>
Robert Maas, http://tinyurl.com/uh3t
> I can't believe how nice everyone is being to the OP.
Except for you. Your earlier followup was somewhat un-nice to the OP,
accusing him of not wanting to really write a program, just complain.
> Why doesn't some one just admit that Lisp is hard, then we can
> all go shopping?
Because that would be a lie. Lisp is easy!! All you need to learn is:
- Relation between syntax (s-expressions) and internal form (CONS-cell trees).
- How Read-Eval-Print works.
- A few simple templates for doing simple things:
- Literals for numbers and strings: 42 "This is a test."
- Call a function: (functionName arg1 arg2 ...)
- Assign a value to a variable: (SETQ varName newValue)
- Functions for building and decomposing CONS-cell tree-structures:
- (CONS leftPart rightPart) => pr
- (CAR pr) => leftPart
- (CDR pr) => rightPart
- Nesting one template/form inside another, for example:
(SETQ pr (CONS 42 "This is a test."))
(SETQ z (+ (car pr) 624))
Then you can sit at the REP playing with building and decomposing
structure as long as it takes to get a deep feeling for it.
Then you decide what type of data you want to play with, for
example numbers or strings or arrays, and look in the chapter on
that data type to see a whole lot more functions you can play with.
For example, in the chapter on arrays, first you do (make-array ...),
then you can play with that array using all the other functions in
the chapter. Likewise (make-hashtable ...), (make-string ...), etc.
It's all easy, except perhaps for those very first two steps.
Once you get past them, it's all easy!!
Ken Tilton
Robert Maas, http://tinyurl.com/uh3t wrote:
>>From: Ken Tilton <kennytil...@optonline.net>
>>I can't believe how nice everyone is being to the OP.
>
>
> Except for you. Your earlier followup was somewhat un-nice to the OP,
> accusing him of not wanting to really write a program, just complain.
But I was right. Can you not read minds? Actually, all you need to be
able to do is read, both what the OP wrote and the great honking neon
arrow I pointed to his use of the word "memorize".
What real programmer ever thinks of learning a computer language as
memorizing?
You people really need to turn up the gain on your antennae.
John Thingstad
<kenny...@optonline.net>:
>
>
> Robert Maas, http://tinyurl.com/uh3t wrote:
>>> From: Ken Tilton <kennytil...@optonline.net>
>>> I can't believe how nice everyone is being to the OP.
>> Except for you. Your earlier followup was somewhat un-nice to the OP,
>> accusing him of not wanting to really write a program, just complain.
>
> But I was right. Can you not read minds? Actually, all you need to be
> able to do is read, both what the OP wrote and the great honking neon
> arrow I pointed to his use of the word "memorize".
>
> What real programmer ever thinks of learning a computer language as
> memorizing?
>
> You people really need to turn up the gain on your antennae.
>
> hth, kenny
>
The hyper-spec is useless if you don't know what to look for.
It takes time to know naming conventions and hyper-spec structure well
enough to be able to find the right thing.
I seem to remember spending hours writing code with would have taken me 20
minutes in C++ simply finding the functions and understanding the
behaviour. The spec can also be difficult to understand in places.
Then also it doen't explain how functions work togeter or what other
otions you have.
I'd say you need to memorize a good number of function names. PCL does go
a long way of filling that gap.
However I think he might have to read it a couple of times before the all
important finer details like the difference between defvar and
defparameter or setf and setq sink in. (Yes, they are in fact explained in
the book.) PCL is 500 page book and introduces 100's of functions. I'd say
anyone would find remembering all of it a bit daunting.
--------------
John Thingstad
Russell McManus
> I'd say you need to memorize a good number of function names. PCL
> does go a long way of filling that gap.
All Kenny is saying is that you don't memorize function names. You
struggle to write programs, until you know what the primitives are,
what idioms are useful, what garbage code looks like, and what good
code looks like. If you're good, you learn some of this by reading
other people's code.
It's like when you see a spelling mistake of an obscure word in your
native language. You may not be able to spell the word properly, but
you sure know that the way it's spelled on the page is wrong. You
don't memorize words, you encounter them in books, they get burned
into your brain, and then you can't forget them if you tried.
It's true that Common Lisp is a big language, so there are a lot of
things to learn. That's cool though, because once you know your way
around, the tool you need is always handy.
-russ
Duane Rettig
> På Sat, 12 Apr 2008 23:50:09 +0200, skrev Ken Tilton
> <kenny...@optonline.net>:
>
>>
>>
>> Robert Maas, http://tinyurl.com/uh3t wrote:
>>>> From: Ken Tilton <kennytil...@optonline.net>
>>>> I can't believe how nice everyone is being to the OP.
>>> Except for you. Your earlier followup was somewhat un-nice to the OP,
>>> accusing him of not wanting to really write a program, just complain.
>>
>> But I was right. Can you not read minds? Actually, all you need to
>> be able to do is read, both what the OP wrote and the great honking
>> neon arrow I pointed to his use of the word "memorize".
>>
>> What real programmer ever thinks of learning a computer language as
>> memorizing?
>>
>> You people really need to turn up the gain on your antennae.
>>
>> hth, kenny
>>
>
> The hyper-spec is useless if you don't know what to look for.
Unless you have the right tools:
http://www.franz.com/search/index.lhtml#ansispec
I try never to memorize what I can just look up.
--
Duane Rettig du...@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Ken Tilton
Duane Rettig wrote:
> "John Thingstad" <jpt...@online.no> writes:
>
>
>>På Sat, 12 Apr 2008 23:50:09 +0200, skrev Ken Tilton
>><kenny...@optonline.net>:
>>
>>
>>>
>>>Robert Maas, http://tinyurl.com/uh3t wrote:
>>>
>>>>>From: Ken Tilton <kennytil...@optonline.net>
>>>>>I can't believe how nice everyone is being to the OP.
>>>>
>>>> Except for you. Your earlier followup was somewhat un-nice to the OP,
>>>>accusing him of not wanting to really write a program, just complain.
>>>
>>>But I was right. Can you not read minds? Actually, all you need to
>>>be able to do is read, both what the OP wrote and the great honking
>>>neon arrow I pointed to his use of the word "memorize".
>>>
>>>What real programmer ever thinks of learning a computer language as
>>>memorizing?
>>>
>>>You people really need to turn up the gain on your antennae.
>>>
>>>hth, kenny
>>>
>>
>>The hyper-spec is useless if you don't know what to look for.
God I love a non-sequitor! What is this idiot Thinging? No wonder he is
in my killfile. Do I need killfile by association? Anyone quoting anyone
in my killfile is a goner? That would cover everyone, I think, free up
even more time for freecell.
Read my lips, Thing: no programmer has ever memorized anything.
>
>
> Unless you have the right tools:
>
> http://www.franz.com/search/index.lhtml#ansispec
>
> I try never to memorize what I can just look up.
>
Right. I never memorized C precedence, I dog-eared that one page in K&R
and/or threw in a pair of air-bag parens and skipped the lookup altogether,
peace. out. kzo.
John Thingstad
<russell...@yahoo.com>:
Yes, but I think Kenny is gotten all worked up over a choice of word.
Perhaps "spitsgeful" is better. That is you need to work the functions
into your fingers.
It's obviously no purpose to memorize a index line by line. We are
programmer's not actors.
But I am pretty sure that is not what he means.
Like I said he looks for a fight. Sees something he disagrees with and
misses the rest of the text.
Thus he misses the point.
--------------
John Thingstad
Giorgos Keramidas
>Duane Rettig wrote:
>>"John Thingstad" <jpt...@online.no> writes:
>>>The hyper-spec is useless if you don't know what to look for.
> God I love a non-sequitor! What is this idiot Thinging? No wonder he
> is in my killfile. Do I need killfile by association? Anyone quoting
> anyone in my killfile is a goner? That would cover everyone, I think,
> free up even more time for freecell.
Seeing that this has already been implemented in certain newsreaders,
it's probably a good idea. At least someone found it useful enough to
sit down and write the code to do it.
Triple yay for freecell! :-)
Robert Maas, http://tinyurl.com/uh3t
> The hyper-spec is useless if you don't know what to look for.
Agreed. That's why I prefer a manual that is organized according to
the data-type. Mostly I still use CLtL1. It doesn't include CLOS,
so if I want to read about CLOS I use Google to find a CLOS
tutorial somewhere.
Now if I can guess the name of the function I want, I have three
options:
- Index in back of CLtL1
- (describe 'nameOfFunction)
- HyperSpec
Unfortunately the info in (describe ...) in CMUCL is often quite
deficient/incomplete, so I really need to read CLtL1 or HyperSpec
to get the full story. But (describe ...) is so much more
convenient, so I often try it before switching to the HyperSpec.
> It takes time to know naming conventions and hyper-spec structure
> well enough to be able to find the right thing.
Agreed. Same remarks as above.
> I seem to remember spending hours writing code with [sic] would have
> taken me 20 minutes in C++ simply finding the functions and
> understanding the behaviour.
It would have taken only 5 minutes in Common Lisp if you could
quickly find the relevant useful function. Too bad nobody
showed any interest in my CookBook/Matrix:
<http://www.rawbw.com/~rem/HelloPlus/CookBook/Matrix.html>
I started out to accomplish two milestones:
-1- Document all the routines available in the standard C library
-2- Show how to do the same things, and better, in Common Lisp
but I got bogged down in -1- and without anybody showing any
interest I lost the energy to continue. But do you like the *idea*
of what it was to accomplish, how if it *were* completed you
*might* be able to find what you want really quickly, and
copy&paste the relevant code snippets directly from the document to
your in-edit source? After I finish my current project (my first
real development of ProxHash for practical benefit, hence first
real test of the technology), would you like to encourage me to
finish the CookBook/Matrix, or not?
> The spec can also be difficult to understand in places.
Yes, but those places are rare IMO.
> Then also it doen't explain how functions work togeter [sic] or
> what other otions [sic] you have.
Yes. That's why there are "CookBooks" for various programming
languages. Unfortunately most of the CookBooks show completed
programs for totally useless stuff such as the Tower of Hanoi or
Eight Queens. More useful would be snippets of how to do really
basic tasks, such as parse an integer from a string in a totally
safe way suitable for ServerSide Web applications via CGI:
<http://www.rawbw.com/~rem/HelloPlus/CookBook/h4s.html>
or how to read lines from a file and process them sequentially,
gracefully exiting the loop after the last line before EOF has been
processed, or how to break a string into "words" separated by some
delimiter such as whitespace or comma-with-optional-whitespace.
> I'd say you need to memorize a good number of function names.
I'd say you don't have to memorize even one. You just look at the
listing of datatypes, and try to think which would be suitable for
your purpose, and click on the link for details of how to do
various things with that datatype, and browse that listing of
details to find the service you need, or something close, and
copy&paste the code snippet, and adapt it to your needs, and test
it in the REP loop until you achieve the effect you wanted. Where
does memorizing happen here??? You do have to memorize how to use a
mouse to click the link and sweep the sample code, and where the
scroll bar on your browser is located, and it helps to know that
Copy and Paste are in the Edit menu, nothing else, right?
> PCL does go a long way of filling that gap.
> However I think he might have to read it a couple of times before
> the all important finer details like the difference between defvar
> and defparameter or setf and setq sink in.
My advice: Don't bother with defvar etc. at all when you're first
writing and testing one line of code at a time in the REP loop.
Ignore those annoying warnings about undeclared variables. When
those warnings get too annoying, make sure you know the difference
between globals you intended and globals that happened during
line-at-a-time testing that go away when you build the code into
functions. For *only* the deliberate globals, make them all defvar,
at the top of your set-up script, and explicitly setq their initial
values from your set-up script. Later when you're more comfortable
with Common Lisp and cleaning up your code, you can revisit all
those defvars to see which ought to really be defconstants or
defparameters. You don't have to memorize anything. Just sit
looking at your variables, with your **comments** as to what each
of them is supposed to be used for, and in another part of your
visual scene the section in the book that explains the difference
between them, and right there while everything is in front of you
and you're not distracted by developing new code, decide for each
defvar whether it is fine as-is or should really be changed to
defconstant or defparameter. You never need to memorize that info.
As for setq and setf, always use setq for assigning values to
symbols used as variables. Use setf only when you are reading about
how the way to modify something is via setf. For example, in the
chapter on hashtables, it says (in CLtL1) that you use gethash to
look for a key in a hash table, and it says you can make new
entries in a hash table by using setf with gethash, and by looking
at the exaples you can guess that you say
(setf (gethash key table) newvalue)
So just copy&paste that to your source code at that moment, modify
it to have the key and table and new value you want to use, and
nothing has to be *memorized*!!! You can even forget about setf
until the next time you learn that the way to change something in
an array or whatever is by using sets.
> PCL is 500 page book and introduces 100's of functions. I'd say
> anyone would find remembering all of it a bit daunting.
Anybody who would try to memorize all that is either a fool, or a
liar trying to talk his way through a job interview that requires
experience with Common Lisp which the applicant doesn't have but is
pretending to have. Better to write some useful utility and show
your interviewer the source listing and be prepared to explain any
questions about how your code works to prove you really wrote that
code (or at least understand how it works if you stole it). For
example, here's a utility I wrote:
- read-lines-of-file
;Read each line of file into one string, and pack all the strings into
; one array, except if keeplist is true then don't convert to array.
- load-whole-file-to-string
;Read the entire contents of a text file into one large string.
- ;Inline read one s-expression from a file (the file presumably contains
; just this one huge s-expression)
- ;Inline read all s-expressions from a file, return list of them.
- load-file-by-method
;Given name of file, and method of loading, just loads that file in
; and returns the result.
;method = :BIGREAD | :ALLREADS | :BIGSTR | :ALLLINES
load-file-by-method can then be called from an auto-loading
mechanism that works from a table that simply lists each file and
corresponding mode of loading and what to do with the result, such
as setting a global to that value.
So long as we have computers, and the InterNet, and electricity to
run them all, it will make more sense to look up details like which
function finds the index of a sub-string within a longer string
<http://www.rawbw.com/~rem/HelloPlus/CookBook/Matrix.html#StrInt>
Find substring in string: Given strings needle,haystack, find first
location where needle exactly matches a substring of haystack:
rather than memorize every such bit of useful trivia.
And if we ever do *not* have computers or electricity, you won't
need this information anyway, so stop memorizing already!
Griff
> and mindset as a programmer?
Yes.
> More directly, is it worth sinking the
> hours into for this purpose?
Yes.
> 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?
Start by learning Scheme. If you start with Common Lisp you will just
end up obsessing over the Common Lisp Object System.
1) Read _The Scheme Programming Language 3rd edition_. Do as many of
the problems as you can, skip whatever you don't get. Read it a second
time, but do all of the problems this time.
2) Read _The Little Schemer_.
3) By now you will have seen the majority of new concepts that Lisp
provides.
4) Learn Common Lisp.
Mikael Jansson
> [snip]
>
> Start by learning Scheme. If you start with Common Lisp you will just
> end up obsessing over the Common Lisp Object System.
>
> 1) Read _The Scheme Programming Language 3rd edition_. Do as many of
> the problems as you can, skip whatever you don't get. Read it a second
> time, but do all of the problems this time.
> 2) Read _The Little Schemer_.
> 3) By now you will have seen the majority of new concepts that Lisp
> provides.
> 4) Learn Common Lisp.
... and unlearn names like "lst" ...
Robert Uhl
>
> What real programmer ever thinks of learning a computer language as
> memorizing?
I think maybe syntax makes it feel less like memorisation to some
folks. Instead of learning a bunch of functions, they're learning a
bunch of syntax--and that seems easier.
--
Robert Uhl <http://public.xdi.org/=ruhl>
I intend to smoke a good cigar to the glory of God before I go to bed
to-night. --Rev. Charles Spurgeon
Kaz Kylheku
> 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
> 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.
Scott Burson
> 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,
>
> complexity by reducing the number of wheels that are reinvented.
>
All excellent points. I have never understood those who complain
about the size of the Common Lisp libraries. (That is, I've never
understood complaints about size per se. Complaints that the same
functionality could be provided by a more elegant basis set of
primitives have some truth to them, I think, in some cases.)
-- Scott
Pascal Costanza
No, not really, and I believe (!) that Scheme currently actually proves
otherwise. Yes, the core language of Scheme (roughly the subset defined
in R3RS/R4RS) is somewhat cleaner and more elegant that CL, but that
didn't prevent full-sized Scheme implementations to become complex
either. I would actually argue that R6RS is more complex and bloated
than CL. So a clean and elegant core language doesn't seem to help.
To the best of my knowledge nobody ever succeeded to grow a complex big
system from a simple and orthogonal core language. I am convinced that
this is a pipe dream that cannot be achieved - the requirements at the
macro level are simply different than at the micro level, and the belief
that everything can look more or less the same at every level is a myth,
IMHO.
Smalltalk seems to be a counter example to a certain degree: The
language remained essentially the same since the early 80's, but
Smalltalkers seem to be successful at writing large and complex systems
with a relatively simple core language. Alas, not everyone is happy with
the lack of change over there either...
Pascal
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pertti Kellomäki
> To the best of my knowledge nobody ever succeeded to grow a complex big
> system from a simple and orthogonal core language.
That is basically what Guy Steele is trying to do with Fortress.
> I am convinced that
> this is a pipe dream that cannot be achieved - the requirements at the
> macro level are simply different than at the micro level, and the belief
> that everything can look more or less the same at every level is a myth,
> IMHO.
One thing that seems to be different is that libraries can provide
syntax as well as semantics, so things need not look the same at
different levels. So who knows, maybe the Age of Aquarius will
finally be upon us ;-)
--
Pertti
Ken Tilton
Pertti Kellomäki wrote:
> Pascal Costanza wrote:
>
>> To the best of my knowledge nobody ever succeeded to grow a complex
>> big system from a simple and orthogonal core language.
>
>
> That is basically what Guy Steele is trying to do with Fortress.
The poster boy for failed languages? The Darth Vader of the Lisp Way?
Constraints programming was linear dataflow gone mad, Scheme was
minimalism mistaken for a design objective, and Java was a productivity
dead-end through excessive safeguarding (but he still crows about the
productivity gain made before hitting the ceiling -- I can see him in a
museum for suits of armor thinking "great idea!").
Actually Cells might be great for Fortress since they automatically lay
bare dependency information needed for parallelizing code automatically,
but he'd probably just cock it up again.
kt
Scott Burson
> Pertti Kellomäki wrote:
> > Pascal Costanza wrote:
>
> >> To the best of my knowledge nobody ever succeeded to grow a complex
> >> big system from a simple and orthogonal core language.
>
> > That is basically what Guy Steele is trying to do with Fortress.
>
> The poster boy for failed languages? The Darth Vader of the Lisp Way?
And the author of CLtL and CLtL2.
> Constraints programming was linear dataflow gone mad, Scheme was
> minimalism mistaken for a design objective
Scheme played a key role in expanding the computer science community's
understanding of programming language design and implementation. The
language itself was intended primarily as a teaching language, a job
it has filled very well.
If Scheme hadn't existed, Common Lisp would very likely have lacked
lexical closures.
Okay, the constraints thing didn't work out that well.
> and Java was a productivity
> dead-end through excessive safeguarding
Huh. I'd rather be working in Java than the C++ I have to use in my
day job.
-- Scott
Griff
> otherwise. Yes, the core language of Scheme (roughly the subset defined
> in R3RS/R4RS) is somewhat cleaner and more elegant that CL, but that
> didn't prevent full-sized Scheme implementations to become complex
> either. I would actually argue that R6RS is more complex and bloated
> than CL. So a clean and elegant core language doesn't seem to help.
Scheme's simplicity is essential to how it removes barriers to
learning.
I've never heard anyone claim that those features are going to take
you from "programming the small" to "programming in the large".
Ken Tilton
Scott Burson wrote:
> On Apr 16, 5:56 am, Ken Tilton <kennytil...@optonline.net> wrote:
>
>>Pertti Kellomäki wrote:
>>
>>>Pascal Costanza wrote:
>>
>>>>To the best of my knowledge nobody ever succeeded to grow a complex
>>>>big system from a simple and orthogonal core language.
>>
>>>That is basically what Guy Steele is trying to do with Fortress.
>>
>>The poster boy for failed languages? The Darth Vader of the Lisp Way?
>
>
> And the author of CLtL and CLtL2.
?? That just means he has no excuse.
>
>
>>Constraints programming was linear dataflow gone mad, Scheme was
>>minimalism mistaken for a design objective
>
>
> Scheme played a key role in expanding the computer science community's
> understanding of programming language design and implementation. The
> language itself was intended primarily as a teaching language, a job
> it has filled very well.
Tell the Schemers their language is just a research/teaching device. :)
>
> If Scheme hadn't existed, Common Lisp would very likely have lacked
> lexical closures.
Doing Scheme magically made them think up lexical closures? Nope.
CL cannot do lexical closures? Nope.
So Scheme helped CL? Nope.
Scheme fragmented the Lisp world? Yep.
>
> Okay, the constraints thing didn't work out that well.
>
>
>>and Java was a productivity
>>dead-end through excessive safeguarding
>
>
> Huh. I'd rather be working in Java than the C++ I have to use in my
> day job.
Was that supposed to be saying something good about Java? :) And are you
sure you could live without even a preprocessor?
Ken Tilton
Btw, Steele has two meta-problems: he always thinks you need a new
language to try a new idea. One of the first things I noticed about
Cells is that I did not have to write a compiler, editor, debugger, etc,
etc. I mean, there is a reason we like programmable programming
languages, yes?
Second, his knee-jerk instinct for all-x-all-the-time. His constraints
language used constraints for assignment to variables. They discovered
they should stop that because it was intractably slow. But why were they
even trying?
Hey, X is great! (fine)
Let's use it for /everything!/ (death. examples: prolog, smalltalk, F#)
First, we'll make a new language... (oh, go away)
Meanwhile Steele famously claims Java is halfway to Lisp. Perhaps he
meant starting from the stone axe?
kenny
Pascal Costanza
>> No, not really, and I believe (!) that Scheme currently actually proves
>> otherwise. Yes, the core language of Scheme (roughly the subset defined
>> in R3RS/R4RS) is somewhat cleaner and more elegant that CL, but that
>> didn't prevent full-sized Scheme implementations to become complex
>> either. I would actually argue that R6RS is more complex and bloated
>> than CL. So a clean and elegant core language doesn't seem to help.
>
> Scheme's simplicity is essential to how it removes barriers to
> learning.
True.
> I've never heard anyone claim that those features are going to take
> you from "programming the small" to "programming in the large".
Read the intro of the Scheme specification, for example
http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-3.html#node_chap_Temp_3
Pascal Costanza
>
>
> Scott Burson wrote:
>> On Apr 16, 5:56 am, Ken Tilton <kennytil...@optonline.net> wrote:
>>
>>> Pertti Kellomäki wrote:
>>>
>>>> Pascal Costanza wrote:
>>>
>>>>> To the best of my knowledge nobody ever succeeded to grow a complex
>>>>> big system from a simple and orthogonal core language.
>>>
>>>> That is basically what Guy Steele is trying to do with Fortress.
>>>
>>> The poster boy for failed languages? The Darth Vader of the Lisp Way?
>>
>>
>> And the author of CLtL and CLtL2.
>
> ?? That just means he has no excuse.
>
>>
>>
>>> Constraints programming was linear dataflow gone mad, Scheme was
>>> minimalism mistaken for a design objective
>>
>>
>> Scheme played a key role in expanding the computer science community's
>> understanding of programming language design and implementation. The
>> language itself was intended primarily as a teaching language, a job
>> it has filled very well.
>
> Tell the Schemers their language is just a research/teaching device. :)
>
>>
>> If Scheme hadn't existed, Common Lisp would very likely have lacked
>> lexical closures.
>
> Doing Scheme magically made them think up lexical closures? Nope.
> CL cannot do lexical closures? Nope.
> So Scheme helped CL? Nope.
> Scheme fragmented the Lisp world? Yep.
You seem to have skipped the history classes...
Scott Burson
> Scott Burson wrote:
> > If Scheme hadn't existed, Common Lisp would very likely have lacked
> > lexical closures.
>
> Doing Scheme magically made them think up lexical closures? Nope.
The existence of Scheme, and its demonst