Starting with Lisp: A collection of beginner pointers(dreamincode.net)
dreamincode.net
Starting with Lisp: A collection of beginner pointers
http://www.dreamincode.net/forums/blog/48/entry-3070-starting-with-lisp/
23 comments
Thanks for your straight-up and instructive comment.
> And indeed, there is a point in the learning curve where you get confused about the proper numbers of parentheses for certain kinds of expressions (so-called 'special forms'). [...] In my experience, what happens is that as you become familiar with these 'special forms', you learn to recognize the visual patterns of indentation and parentheses that are particular to each of these expressions.
Yes. This seemingly mundane topic actually interests me a great deal.
One thing that I appreciate about Arc, despite all of the language's shortcomings today (few libraries, no module system, tiny community, scarce documentation, etc.), is that its designer has taken great care to minimize the number of parentheses. The core language almost as a rule doesn't employ parentheses unless absolutely necessary, and it's nice to have a guiding heuristic like this while you're learning because it allows you to internalize the special forms more quickly.
> And indeed, there is a point in the learning curve where you get confused about the proper numbers of parentheses for certain kinds of expressions (so-called 'special forms'). [...] In my experience, what happens is that as you become familiar with these 'special forms', you learn to recognize the visual patterns of indentation and parentheses that are particular to each of these expressions.
Yes. This seemingly mundane topic actually interests me a great deal.
One thing that I appreciate about Arc, despite all of the language's shortcomings today (few libraries, no module system, tiny community, scarce documentation, etc.), is that its designer has taken great care to minimize the number of parentheses. The core language almost as a rule doesn't employ parentheses unless absolutely necessary, and it's nice to have a guiding heuristic like this while you're learning because it allows you to internalize the special forms more quickly.
Rich Hickey (the creator of clojure) sais something about this too. Something like this:
"Only use parentheses when it is absolutely necessary witch makes it a little harder for macro writers but much easier for users."
If i work with CL i really hate that i have to write pairs in parens. In cond or let: CL: (let ((a 1) (b 2))) Clojure: (let [a 1 b 2])
"Only use parentheses when it is absolutely necessary witch makes it a little harder for macro writers but much easier for users."
If i work with CL i really hate that i have to write pairs in parens. In cond or let: CL: (let ((a 1) (b 2))) Clojure: (let [a 1 b 2])
In my code, where the binding forms would typically be longer than (a 1) or (b 2), they each go on their own line, and the editor will align them by their left parentheses. In those cases where the initialization form needs to be broken into another line, the editor will indent the continuation properly, and the 'terminating' parenthesis is actually a helpful visual cue that the form is done.
I haven't written any Clojure so I'm not sure how my brain would react to non-delimited forms (ie, the implicit pairs). I also don't know how Emacs handles the indentation for these, or whether in more complicated cases, my brain would have to work harder to group the binding forms. I read the Clojure specs on 'let' and it appears to be a somewhat different beast than the CL 'let'. In more complicated cases, it doesn't appear to be an apples-to-apples comparison in terms of parsing the 'shape' of the expressions.
I haven't written any Clojure so I'm not sure how my brain would react to non-delimited forms (ie, the implicit pairs). I also don't know how Emacs handles the indentation for these, or whether in more complicated cases, my brain would have to work harder to group the binding forms. I read the Clojure specs on 'let' and it appears to be a somewhat different beast than the CL 'let'. In more complicated cases, it doesn't appear to be an apples-to-apples comparison in terms of parsing the 'shape' of the expressions.
> I'm not sure how my brain would react to non-delimited forms (ie, the implicit pairs).
You probably wouldn't like it. ;) Seriously though, I think what we're used to plays a tremendous role in our preference here.
> I also don't know how Emacs handles the indentation for these
For Arc, anyway, the indentation algorithm is constantly making mistakes. I always hesitate to auto-indent a region because I know I'll have to go through and manually fix things. But I'm not sure this is the language's fault - the Emacs mode probably just needs to be smarter.
You probably wouldn't like it. ;) Seriously though, I think what we're used to plays a tremendous role in our preference here.
> I also don't know how Emacs handles the indentation for these
For Arc, anyway, the indentation algorithm is constantly making mistakes. I always hesitate to auto-indent a region because I know I'll have to go through and manually fix things. But I'm not sure this is the language's fault - the Emacs mode probably just needs to be smarter.
I would add that reading SICP or HtDP is not enough, you need to work through the exercises to sink in the important programming principles they try to teach you. Also, I miss the Schemer/Lisper series by Friedman et al. in that list.
Just out of curiosity, regarding claims like "Common Lisp has a fairly sized community which is widely regarded as a tough bunch" or "The Scheme community is really one of the most tolerant communities of them all", are those based on personal experience? How did you come up with such conclusions? I'm really interested :)
Just out of curiosity, regarding claims like "Common Lisp has a fairly sized community which is widely regarded as a tough bunch" or "The Scheme community is really one of the most tolerant communities of them all", are those based on personal experience? How did you come up with such conclusions? I'm really interested :)
I would say this is from personal experience based on lurking on CLL and a couple of dumb questions I asked on #lisp once. I don't really mind the CL community, its just that the help starts once you've one (atleast, even the introductory one's) or a major chunk of one book down cold. After that they're really eager to show you the path.
Compare this with many other language communities, people regularly ask questions regarding where are the installer's kept which is answered with great politeness by some good netizen. The contrast only occurs that the benchmark of the CL community starts at a higher bar. Recently though, as I wrote in the blog post, even the big-name lisper's seem to guide newbie's to LispBox's URL or suggesting the command line to install SBCL on Ubuntu which certainly is making CL communities a fairly friendly place to be.
The #scheme guys are just amazing. So are the individual mailing lists of the implementation Racket. Somebody on #scheme actually held my hand (metaphorically) to clear my confusion as to which function is the "main" function where execution starts. I used code a little in C/C++/Java and was expecting a function named "main" even though I was testing individual functions from the DrScheme IDE's split window REPL.
Compare this with many other language communities, people regularly ask questions regarding where are the installer's kept which is answered with great politeness by some good netizen. The contrast only occurs that the benchmark of the CL community starts at a higher bar. Recently though, as I wrote in the blog post, even the big-name lisper's seem to guide newbie's to LispBox's URL or suggesting the command line to install SBCL on Ubuntu which certainly is making CL communities a fairly friendly place to be.
The #scheme guys are just amazing. So are the individual mailing lists of the implementation Racket. Somebody on #scheme actually held my hand (metaphorically) to clear my confusion as to which function is the "main" function where execution starts. I used code a little in C/C++/Java and was expecting a function named "main" even though I was testing individual functions from the DrScheme IDE's split window REPL.
I find rather amusing that lispers and schemers differ that much when it comes to lend a hand to people, especially when Scheme is a dialect of Lisp. Do lispers regard the poor schemers in an envious way just because tail-call optimization is part of the Scheme standard? :)
No, seriously. Nowadays, it seems like people sometimes forget what they struggled with when they were learning the ropes of some technology.
No, seriously. Nowadays, it seems like people sometimes forget what they struggled with when they were learning the ropes of some technology.
Having interacted with both, I can definitely say yes. Post an obvious or basic question to comp.lang.lisp, and enjoy being ripped to shreds.
This type of attitude is what keeps some aspiring people away. How does a beginner know what an obvious question is? Honestly I'm long past tired of this attitude among developers. When you're really good at something you've been doing for a long time, your definition of hard and easy changes so much.
I can say that building web applications with Rails is the easiest way to go, but I've been doing it for almost six years. When I teach a class on Rails to complete newbies, it takes us 8 hours to comfortably get through setting up the environment, writing some basic code, and ending up with little more than a few pages and a scaffold.
So when I ask for help from someone who has done significant work with something I want to learn, I'm hoping that they'll remember what it was like when they get started, and not tell me that my questions are "stupid" or "obvious". I may not even know what resources I should have looked at first.
I can say that building web applications with Rails is the easiest way to go, but I've been doing it for almost six years. When I teach a class on Rails to complete newbies, it takes us 8 hours to comfortably get through setting up the environment, writing some basic code, and ending up with little more than a few pages and a scaffold.
So when I ask for help from someone who has done significant work with something I want to learn, I'm hoping that they'll remember what it was like when they get started, and not tell me that my questions are "stupid" or "obvious". I may not even know what resources I should have looked at first.
I am no lisp expert, and I'm well aware of the legendary cloud of terror and harshness which is said to hover on comp.lang.lisp. However, by lurking there for a while, I came to understand better the reasons of the residents.
Here, "obvious" means "I don't even remotely know what I'm talking about, but I find easier to ask stupid questions instead of studying a bit and then ask reasonable questions."
The fact is, Common Lisp is a niche language, and one that is not easy to learn (until you want to translate from your-language-of-choice to lisp, which is pointless anyway). Until one wants to dedicate some time digging this wonderful and partly forgotten civilization, there's no sense wasting time with it, either yours or the others'. But if one does his homework, I've found that the quality of the help provided by the community is the highest I've ever seen.
Here, "obvious" means "I don't even remotely know what I'm talking about, but I find easier to ask stupid questions instead of studying a bit and then ask reasonable questions."
The fact is, Common Lisp is a niche language, and one that is not easy to learn (until you want to translate from your-language-of-choice to lisp, which is pointless anyway). Until one wants to dedicate some time digging this wonderful and partly forgotten civilization, there's no sense wasting time with it, either yours or the others'. But if one does his homework, I've found that the quality of the help provided by the community is the highest I've ever seen.
Never had any problem with the CL community. You often get really good and extensive replies, provided you don't ask questions before connecting the brain.
How 'bout Land of Lisp? [1]
----
[1]: http://landoflisp.com/
----
[1]: http://landoflisp.com/
I wanted to include it but I have not read it :) It seems really interesting but is not available in my local bookstores and my current set of books (the one's I mentioned) keep me humming along.
However judging from other people's reactions, I'd say it should a top notch work.
However judging from other people's reactions, I'd say it should a top notch work.
Just got through reading the first suggested item in the Background section: http://www.defmacro.org/ramblings/lisp.html
I recommend this to anyone interested in learning about the appeal of Lisp. It's well-written, and lays a nice foundation for those trying to figure out what all the buzz surrounding Lisp is about. I'm sold.
I recommend this to anyone interested in learning about the appeal of Lisp. It's well-written, and lays a nice foundation for those trying to figure out what all the buzz surrounding Lisp is about. I'm sold.
A few more tips I found helpful as a beginner:
* Most lisps can compile a binary, even the free ones.
* sbcl seems to have a ton of popularity and support.
* Want to mix Lisp directly into your C code? Try ECL. Most important: it works, and should not take you long to connect it to your program.
* clisp has a nice readline-like commandline; you can get something like it in sbcl with the linedit module
* ASDF isn't horrible, but quicklisp makes packages much easier to get
* cliki.net - browse packages, ideas, etc
* CFFI package lets you use any external library with your Lisp program. Lisp has its own version of C header files that you can build via CFFI.
* Edit lisp in any editor. Emacs is neat. Vim works, too. Both have some extra support tools for Lisp. Emacs is more supported. Worry about learning Lisp first.
* At minimum, your editor should help you figure out what ()s match (or provide them for you). Otherwise, you will spend time counting and being annoyed with ()s rather than loving them.
* Before you write your fourth Lisp program, read some typical Lisp code. Just get a feel for it. Look at how it is indented and arranged. Go back to writing code.
* Most lisps can compile a binary, even the free ones.
* sbcl seems to have a ton of popularity and support.
* Want to mix Lisp directly into your C code? Try ECL. Most important: it works, and should not take you long to connect it to your program.
* clisp has a nice readline-like commandline; you can get something like it in sbcl with the linedit module
* ASDF isn't horrible, but quicklisp makes packages much easier to get
* cliki.net - browse packages, ideas, etc
* CFFI package lets you use any external library with your Lisp program. Lisp has its own version of C header files that you can build via CFFI.
* Edit lisp in any editor. Emacs is neat. Vim works, too. Both have some extra support tools for Lisp. Emacs is more supported. Worry about learning Lisp first.
* At minimum, your editor should help you figure out what ()s match (or provide them for you). Otherwise, you will spend time counting and being annoyed with ()s rather than loving them.
* Before you write your fourth Lisp program, read some typical Lisp code. Just get a feel for it. Look at how it is indented and arranged. Go back to writing code.
I'm just beginning my road down the path of learning Lisp. My plan for learning is:
1. Read the Practical Common Lisp chapters which introduce Lisp features.
2. Write a web application using Common Lisp (Hunchentoot/Postmodern). After all, the only way to learn a language is to use a language.
3. Re-read Practical Common Lisp and/or other Lisp books.
I realize that I won't remember 90% of the material read in Practical Common Lisp in Step 1. However, I'm hoping that I can get an overview of the features available in the language to help design a better web application. Knowing some names of features like CLOS, cons cells, plists, alists (and others that I haven't gotten to yet) will just make it easier for me to search for help when I run into problems.
If anyone has any references to good materials for the following:
- Learning Common Lisp
- Creating CL applications using Hunchentoot and/or Postmodern
- Quality Common Lisp API specs
- Any other tips for an aspiring Lisper
I'd be grateful for any additional information that might help me along the way.
1. Read the Practical Common Lisp chapters which introduce Lisp features.
2. Write a web application using Common Lisp (Hunchentoot/Postmodern). After all, the only way to learn a language is to use a language.
3. Re-read Practical Common Lisp and/or other Lisp books.
I realize that I won't remember 90% of the material read in Practical Common Lisp in Step 1. However, I'm hoping that I can get an overview of the features available in the language to help design a better web application. Knowing some names of features like CLOS, cons cells, plists, alists (and others that I haven't gotten to yet) will just make it easier for me to search for help when I run into problems.
If anyone has any references to good materials for the following:
- Learning Common Lisp
- Creating CL applications using Hunchentoot and/or Postmodern
- Quality Common Lisp API specs
- Any other tips for an aspiring Lisper
I'd be grateful for any additional information that might help me along the way.
I am not sure that writing a web app is the best way to learn common lisp; it introduces a lot of extra complexity (libraries, web server, etc) in a language that is itself quite complex. You'd better start from a simple CLI application as your first project.
Books: there is also Graham's "ANSI Common Lisp", which has a different approach from PCL; I found it clearer as first text (but PCL is a necessary reading anyway, for various reasons). But it's a matter of cognitive styles, start from the one that you prefer.
Absolutely download the Common Lisp Hyperspec and familiarize with it. Is the main everyday referemce tool of any CLisper.
Environment: Emacs + SLIME is the most popular option. Commercial lisps (and their free evaluation versions) also have good IDEs.
Have fun!
Books: there is also Graham's "ANSI Common Lisp", which has a different approach from PCL; I found it clearer as first text (but PCL is a necessary reading anyway, for various reasons). But it's a matter of cognitive styles, start from the one that you prefer.
Absolutely download the Common Lisp Hyperspec and familiarize with it. Is the main everyday referemce tool of any CLisper.
Environment: Emacs + SLIME is the most popular option. Commercial lisps (and their free evaluation versions) also have good IDEs.
Have fun!
Well, I had an idea for a web application that I'd otherwise create in Python. I figured I'd use Lisp to get some experience using it (also, my AI class next semester uses Lisp).
While it will probably cause some additional hurdles of complexity (such as figuring how how to use ASDF and manage packages), I find it is hard to motivate myself without a shiny carrot in front of me. The web application is something that I would use and want to build, whereas writing a simple and purely educational program doesn't provide the same kind of motivation.
While it will probably cause some additional hurdles of complexity (such as figuring how how to use ASDF and manage packages), I find it is hard to motivate myself without a shiny carrot in front of me. The web application is something that I would use and want to build, whereas writing a simple and purely educational program doesn't provide the same kind of motivation.
If you can handle, go for it! But if after a while you'll think that lisp is not so different from the other languages after all, it's probably because you tried to learn too many things at once. In that case, persist. :-)
A few tips from another aspiring lisper, who's only a little bit ahead down the road:
- Read a lot of code. Its essential to learn to read and understand common lisp code with little effort. In many cases, a lot of libraries have incomplete or outdated documentation, so the source code is the best documentation available.
- You'll have to learn to piece together a lot of incomplete information, scattered around in blogs, documentation, wikies, and source code.
- Prefer portable libraries rather than implementation specific extensions, if possible.
- Learn emacs.
- I would suggest also learning a bit about the history of lisp, a lot of weird things in lisp make a lot more sense if you consider the historical context in which many design decisions were made.
- Don't whine or complain, be a doer. My favorite quote from "The bipolar lisp programmer" is at the end: "Lisp is, like life, what you make of it." You have to take matters into your own hands in order for things to get better. Even though I've only been using common lisp for a few months, i like to think of myself as personally responsible for the state of the Lisp ecosystem, because im not writing libraries or documentation, nobody is going to do this stuff for you. There simply aren't enough of us.
- Avoid the "Smug lisp weenie" mentality, its not helping. Sure, lisp is better than java(by some criteria), but feeling smug about this isn't helping at all. It only drives people away.
Im currently compiling a larger list of such tips and opinions. I hope to be able to publish it soon, so more experienced lispers can help me with it.
- Read a lot of code. Its essential to learn to read and understand common lisp code with little effort. In many cases, a lot of libraries have incomplete or outdated documentation, so the source code is the best documentation available.
- You'll have to learn to piece together a lot of incomplete information, scattered around in blogs, documentation, wikies, and source code.
- Prefer portable libraries rather than implementation specific extensions, if possible.
- Learn emacs.
- I would suggest also learning a bit about the history of lisp, a lot of weird things in lisp make a lot more sense if you consider the historical context in which many design decisions were made.
- Don't whine or complain, be a doer. My favorite quote from "The bipolar lisp programmer" is at the end: "Lisp is, like life, what you make of it." You have to take matters into your own hands in order for things to get better. Even though I've only been using common lisp for a few months, i like to think of myself as personally responsible for the state of the Lisp ecosystem, because im not writing libraries or documentation, nobody is going to do this stuff for you. There simply aren't enough of us.
- Avoid the "Smug lisp weenie" mentality, its not helping. Sure, lisp is better than java(by some criteria), but feeling smug about this isn't helping at all. It only drives people away.
Im currently compiling a larger list of such tips and opinions. I hope to be able to publish it soon, so more experienced lispers can help me with it.
In addition to reading archives of comp.lang.lisp, I recommend exploring Lispforum.com, planet.lisp.org, common-lisp.net/pipermail/pro, and searches such as https://github.com/search?q=common+lisp.
As a new lisper coming from Python, my impression is that while there is a ton of good reference material going way back, it's also important to find where the contemporary work and discussion happens, what the current best practices are, and so on.
For books for the beginner to intermediate programmer, I would go with PCL and Successful Lisp in tandem; for cross-platform implementations SBCL and Clozure (formerly OpenMCL).
And of course, this: http://abhishek.geek.nz/docs/lisp-answers/.
As a new lisper coming from Python, my impression is that while there is a ton of good reference material going way back, it's also important to find where the contemporary work and discussion happens, what the current best practices are, and so on.
For books for the beginner to intermediate programmer, I would go with PCL and Successful Lisp in tandem; for cross-platform implementations SBCL and Clozure (formerly OpenMCL).
And of course, this: http://abhishek.geek.nz/docs/lisp-answers/.
Rather than re-read PCL, you could use this to review after reading the tutorial introduction:
ftp://ftp.walrond.org/cl/Practical%20Common%20Lisp%20-%20Distilled.pdf
If you have your heart set on a web app, here are a few links I've stashed away on web apps with CL:
http://postabon.posterous.com/a-simple-lisp-webapp-for-begin...
http://www.adampetersen.se/articles/lispweb.htm
I've heard that the second one is a bit out of date, but I'm not sure. Maybe someone else can comment on whether these are any good? I haven't gotten to the write-a-web-app stage of my Lisp study yet...
ftp://ftp.walrond.org/cl/Practical%20Common%20Lisp%20-%20Distilled.pdf
If you have your heart set on a web app, here are a few links I've stashed away on web apps with CL:
http://postabon.posterous.com/a-simple-lisp-webapp-for-begin...
http://www.adampetersen.se/articles/lispweb.htm
I've heard that the second one is a bit out of date, but I'm not sure. Maybe someone else can comment on whether these are any good? I haven't gotten to the write-a-web-app stage of my Lisp study yet...
As a sidenote, when you first look into Lisp, you hear a lot of kvetching and mocking about parentheses. And indeed, there is a point in the learning curve where you get confused about the proper numbers of parentheses for certain kinds of expressions (so-called 'special forms'). And you see Lisp apologists countering that it's not the parentheses that matter; rather the indentation is what helps you understand the code.
In my experience, what happens is that as you become familiar with these 'special forms', you learn to recognize the visual patterns of indentation and parentheses that are particular to each of these expressions. And once you write a number of them yourself, grokking the code of others is no problem. And as in all languages, a decent editor and syntax coloring is helpful.