Looking for a Project to Help Me Gain a LISP Vocab

So I'm working my way through the emacs tutorial, and I'm catching on pretty well, but the problem is that I'm kinda... bored. I mean, I find the material interesting enough, and I want to learn, but the learning process just isn't all that compelling. What I think I need is a project to work on as sort of a primary end; I figure out what I might need to solve some sub-issue, and then look it up, and *bam*, I've learned lisp-necessity X. My problem is that I can't really figure which things are important to learn without knowing which things are important to learn, i.e., reading the darn tutorial. So I was hoping I could get some suggestions for a project here.

The ideal project would:
1) Require me to learn a substantial amount of the "must-knows" for lisp programming, thereby helping me toward competence and confidence
2) Be somewhat limited in scope (Is 50 hours worth reasonable?)
3) Be digestible - I should be able to figure at least a possible strategy without knowing everything already

I have very applicable backgrounds in cognitive neuroscience and logic if that helps (tapping these interests couldn't hurt), but this is my first programming language. Thanks for any help in advance.

If you're into mathematics, here's a couple sources of inspiration for small code projects.
http://projecteuler.net/
http://www.azspcs.net/

Project Euler is particularly good; as you work through the problems, you will start building up a toolbox of routines.

If the above don't catch your fancy, then what types of stuff would?

These are good, but I would have kittens over an AI project; complex decision making or visual processing, for example. Obviously I don't plan to make an A.I. or solve one of those problems, but the ability to build a imperfect model would be fantastic. But, again, I don't know if that's a good learning project, or is even very LISP-y.

EdibleComplex wrote:These are good, but I would have kittens over an AI project; complex decision making or visual processing, for example. Obviously I don't plan to make an A.I. or solve one of those problems, but the ability to build a imperfect model would be fantastic. But, again, I don't know if that's a good learning project, or is even very LISP-y.

A project (or a problem) can't be unLispy, only a way to create such project (or to solve such problem) might or might not be Lispy. And many of the problems in Project Euler are quite easy, you won't need to create a complex A.I program to solve them (the first one can be solved with no computer at all, for instance, and most of them only require only 10 or so lines of code).

Anyway, do as you like.

StumpWM needs alot of features added (resize in floating, more automation for things like dumping window-property rules and tags) and some overall polishing.
if a patch is good, it's in. No politics.

It'll help to know git, too.

EdibleComplex wrote:These are good, but I would have kittens over an AI project; complex decision making or visual processing, for example. Obviously I don't plan to make an A.I. or solve one of those problems, but the ability to build a imperfect model would be fantastic. But, again, I don't know if that's a good learning project, or is even very LISP-y.

My first programming project of any significant size was to write a Connect 4 game, with an AI player, and I'd highly recommend that, especially if you are interested in playing around with a bit of AI. Connect 4 is a really nice toy project, it's really easy to get the basic rules down, and writing an AI player which can play better than an average human player is just the right level of challenge for a first time programmer. It's pretty much perfect in terms of your requirement that the project be "digestible" too, assuming you know the rules of Connect 4 you'll already know where to start, but the chances are there's a lot about connect 4 you've not thought about yet, but will easily be able to work out just by thinking about the problem from the point of view of writing an AI.

As for LISP-y-ness, I can't really comment since I'm only learning LISP myself. gugamilare probably knows more than I do, so just listen to him and don't worry about it (Although I recon that a Connect 4 AI will naturally lend itself to getting a lot out of a couple of well written macros. And experience in writing macros is definitely important for mastering Lisp.)

dbdkmezz wrote:My first programming project of any significant size was to write a Connect 4 game, with an AI player, and I'd highly recommend that, especially if you are interested in playing around with a bit of AI.

Whether you choose Connect 4 or not, I second the motion to start with a small game. For whatever reason, that always seems to be a good way to learn program. The task is usually sufficient to get you out of the "toy program" category, yet isn't so huge as to be impossible to complete.

findinglisp wrote:

dbdkmezz wrote:My first programming project of any significant size was to write a Connect 4 game, with an AI player, and I'd highly recommend that, especially if you are interested in playing around with a bit of AI.

Whether you choose Connect 4 or not, I second the motion to start with a small game. For whatever reason, that always seems to be a good way to learn program. The task is usually sufficient to get you out of the "toy program" category, yet isn't so huge as to be impossible to complete.

Yeah, I'd agree. I would disagree that writing a good AI for connect 4 is an easy task for a first-time programmer, unless they pick up the algorithm from somewhere else. The first real program I ever wrote in C was a Tic-Tac-Toe program (and I wound up writing it so that it had kind of nice graphics, for DOS, which was also educational.) Of course the right way to program that is to look at all future game states and pick a branch that doesn't lose. But since this was the first real program I ever wrote, and since I couldn't go look it up on the web, I had to figure out an algorithm for Tic-Tac-Toe with no outside input. What I came up with was a way of assigning numerical values to each cell and then summing them- basically a heuristic for where to play. It worked pretty well- it would draw against most play. But it would lose to a few sequences, since it didn't actually look ahead.

If someone had told me that the key idea was to actually recursively look at all future game states and then minimax I suspect I could have implemented that then. But I think there was some value in actually sitting down and asking: how do you get a computer to play Tic-Tac-Toe? Connect 4 is more complicated, but it might be interesting to do the same thing, with no outside input. But, if you've never programmed before, don't be discouraged if your first stab at it isn't a very good player.

duncan wrote:If someone had told me that the key idea was to actually recursively look at all future game states and then minimax I suspect I could have implemented that then. But I think there was some value in actually sitting down and asking: how do you get a computer to play Tic-Tac-Toe? Connect 4 is more complicated, but it might be interesting to do the same thing, with no outside input. But, if you've never programmed before, don't be discouraged if your first stab at it isn't a very good player.

Another option is that game where you control a snake that eats apples (What is its "official" name? Snakes?). I made it with ncurses (in C) when I was taking programming classes during my graduation, it is pretty simple to do, and would also be a good learning project, and no AI is needed. In CL, you may want to use either cl-screen or cl-ncurses, though I never used any of those libraries. A first look reveals that neither have (external) documentation, but cl-ncurses have tests which you can look at to learn how to use the library.

This reminds me the first game I made with a bit AI. It was a Pacman game, made with opengl and glut, in C, during my programming classes. The discipline's professor taught an algorithm to make the phantoms pursue the pacman, but either each phantom should have a distinct speed or the phantoms would make the exact same path. Instead of doing that, I put the one more restriction to each phantom: each phantom would not go to a passageway if there was a phantom already there (unless the phantom has no choice). I'm yet to see a pacman game as smart as that one . I am still very proud of having made it. Unfortunately, I don't have the code anymore (I have only a not-working version).

duncan wrote:Yeah, I'd agree. I would disagree that writing a good AI for connect 4 is an easy task for a first-time programmer, unless they pick up the algorithm from somewhere else. The first real program I ever wrote in C was a Tic-Tac-Toe program (and I wound up writing it so that it had kind of nice graphics, for DOS, which was also educational.) Of course the right way to program that is to look at all future game states and pick a branch that doesn't lose. But since this was the first real program I ever wrote, and since I couldn't go look it up on the web, I had to figure out an algorithm for Tic-Tac-Toe with no outside input. What I came up with was a way of assigning numerical values to each cell and then summing them- basically a heuristic for where to play. It worked pretty well- it would draw against most play. But it would lose to a few sequences, since it didn't actually look ahead.

If someone had told me that the key idea was to actually recursively look at all future game states and then minimax I suspect I could have implemented that then. But I think there was some value in actually sitting down and asking: how do you get a computer to play Tic-Tac-Toe? Connect 4 is more complicated, but it might be interesting to do the same thing, with no outside input. But, if you've never programmed before, don't be discouraged if your first stab at it isn't a very good player.

Right. I would actually recommend a simple gambling game of some sort (e.g. craps or blackjack). The rules tend to be simple and because it's a game of chance, there is no AI (don't choose poker, which is not a game of chance, because of this).