Here's an Asteroids clone I wrote in Clojure a few years back, which has less than 400 lines and some neat stuff like procedurally generated 3D asteroids: https://github.com/ztellman/penumbra/blob/master/test/exampl...

Some of the design decisions are discussed in detail at http://ideolalia.com/creating-a-simple-game-in-clojure

The Lisp code used multiple dispatch to handle collisions between objects, whereas your Clojure code instead uses list comprehensions to generate pairs of colliding objects by type. I know Clojure also supports multiple dispatch, so I'm wondering if you could comment on this design decision.

The only collisions I care about in my implementation are asteroid/ship and bullet/asteroid, and they're easier to express directly. The OP's version appears to have many more types of collisions, which makes multiple dispatch a more obvious choice.

Could you update the penumbra README? I'd like to try it out but the instructions are outdated.

Outdated how? They were working the last time I made a commit a year ago, I'm not sure what could have changed.

Thanks for the blog post. Very informative and concise.

Looks pretty good overall, but there are a few little oddities.

Not to turn this into a design review, but using EQ to test for 0 seems like it's asking for trouble, and it looks like that * has only one argument.

Thanks for the tip. I didn't realize numbers with the same value could be different to eq.

It would be incredible to me if someone could write some commentary about this for the non-lisper. Skimming it now, it seems very familiar to me (as in, I don't really see anything about it that expresses anything particularly beautifully), but I might be missing some of the finer points. Overall, I recognize a lot of familiar code that I've written for games in javascript. It's hard to appreciate the aesthetics of this, since I'm not familiar with the language.

My guess is that the author is new to common lisp. It's the only CL project in his github account, and he wrote it using vim. Most people who have been using SBCL for a while will use emacs with SLIME as it is the recommended IDE for using SBCL.

So I wouldn't expect it to contain any particularly awesome lisp-isms. My first read made me think it was using multiple-dispatch, but it isn't doing so in a way that wouldn't also be possible in a language with overloading, as no more than 1 parameter is ambiguously typed at function call time.

Some of the best lispers use vim. cf Doug Hotye (antiweb, Let Over Lambda) and Paul Graham. I use vim + slimv to develop with SBCL.

I think it's a little disingenuous to expect less of someone for using a different editor. Good catch on the multiple dispatch though.

I think it would be fair to say that the characteristics of the code you write could change depending on whether you use an editor or an IDE though.

If emacs + slime is to lisp what eclipse is to java, then I think that is what the GP was alluding to.

To avoid the politics: "it makes just as much sense as Bayesian inference".

I suppose that's better. Great Lispers are statistically unlikely to be using Vim, but the number of people using Vim is so large that merely using Vim isn't damning evidence that code is poorly written.

It's not 'great lispers' it's 'programmers reading lisp tutorials'

If you can find one Lisp tutorial that mentions only Vim or even shows Vim and Emacs as competing setups I would be genuinely surprised.

Here is one: http://ycombinator.com/arc/tut.txt

"There are 4 parentheses at the end of that call to cons. How do Lisp programmers deal with this? They don't. You could add or subtract a right paren from that expression and most wouldn't notice. Lisp programmers don't count parens. They read code by indentation, not parens, and when writing code they let the editor match parens (use :set sm in vi, M-x lisp-mode in Emacs)."

He mentioned the editor second. The fact that it was the only CL project in his github first. In my perspective he mentioned the editor as a weaker circumstantial evidence.

Hi, author here. I am new to Lisp (about 4 months in) and I've been a happy Vim user for many years, so I'm not finding the transition to Emacs very easy. I am trying, though.

I'm a very happy vim user too. Sadly, short of commercial IDEs, developing lisp without slime is like developing Java without eclipse or intellij; it's just an inferior way to interface with the language.

For vim users, the two choices are vim+slimv and emacs+evil. I find evil to be closer to vim than slimv is to a good slime experience, but that can change. Also, if you have any vim plugins that you really depend on then slimv probably edges out evil.

On the other hand I started out several years ago with viper plus a bunch of hand-coded elisp functions to use my most commonly-used vim commands, so we've come a long way.

I was planning to write about my experience writing this, so I'll keep you posted.

It's really not elegant or special code at all, though, just something I used to learn some more about Lisp.

Please do!

Lisp has this reputation within the hacker community, and I'd love to hear some impressions from people who are new to it.

This was on /r/programming and now it's here - I'm sorry, but I don't really understand what this is all about. 600 lines doesn't seem ultra-small to me. And Lisp - well sure, not too common a language for games, but it's not as if this was written in a purely functional style or something. In fact, it looks like pretty standard imperative programming to me - it wouldn't look much different in C.

Am I missing something here?

I wasn't trying to write it in less than 600 lines, that's just what the OP used for an interesting title, I guess.

It's just a fun project I did to learn a bit of CL. I translated the code from a Python game, so it's not in pure functional style. Now that you mention it, though, I feel like I should try that.

Nice to see a project using http://code.google.com/p/lispbuilder/wiki/LispbuilderSDL which wraps the SDL library amongst others and works on Linux, Mac OS X and Windows.

great!

it's a nice project, it's free, it's modern, it works, it's an interactive-graphic-non-boring thing, it's a game!

lisp needs more of this.

party's open: more functional, macro wiser and skinnier ones are welcome.

vim should be welcome too as I run ASTeroids fine under vim+slimv (just like the terminal) while under emacs+slime it doesn't display some white line segments here and there... (same sbcl for all)

last thing, I scored 3432 (level 11) with the first coin...;)

Thanks for your support! I totally agree with you - I put the code up on Github because I figured someone like me might want to improve it or take it in another direction.

no macros? I'm no expert and I'm asking to experts: macros are one of the key features of Lisp. Should macros have helped reducing LOC or improving maintainability?

Disclaimer: I'm not a lisper. But according to Paul Graham, Macros are harder to write than ordinary Lisp functions, and it's considered to be bad style to use them when they're not necessary. http://www.paulgraham.com/avg.html

"If the browser ran bytecodes instead of javascript..."

Not even using libasteroid...

Thanks!

I just observed , whenever there is a discussion about Common Lisp , some how somebody would inject something about Clojure. Did anybody noticed that ?

Its simple Logic,

Programmers Those who use C = C Programmers. Scheme = Scheme Programmers. Common Lisp = Common Lisp Programmers. Clojure = Clojure Programmers.

Programmers Who use Clojure != Common Lisp Programmers.

So Please, please stop posting about Clojure in Common Lisp Posts.

I don't want Clojure solution for Common Lisp problem.

if I want to eat steak, i'd search about steak, why the hell i need to check about broccoli. Same thing if i want to learn Common Lisp, i need more info about Common Lisp, Why the hell i need info about Clojure.