Sir. I have no idea what to say. You were my direct inspiration for a long time. I'm a gamedev (worked at a couple studios now) and I've wanted to integrate Lisp into gameplay for years. I even got a Franz CL evaluation. The discovery of GOAL/Crash Bandicoot further motivated my efforts.

Ultimately nothing came out of it; Lua and Python are just so much easier to integrate into a realtime C++ simulation (video game) and are nearly as effective. However, I became a better programmer for life. Discovering GOAL enabled me to think like "if Naughty Dog could do it, then so could I", which sparked me along a path of learning that profoundly impacted my sense of programming aesthetics and quality. Thank you.

One of the interesting things about LISP is that it's actually a pretty easy language to parse, interpret, and compile. This isn't actually an accident as the S-expression syntax I'm sure was initially chosen for it's machine regularity (in those early days of underpowered machines). Newer languages are syntactically much more complicated. Ironically most normal programmers, being human, seem to find the more complicated syntax easier and the "simple" S-expression syntax confusing (being backward much of the time to normal human convention). I always found it unambiguous, but go figure. It's also precisely this regularity that makes the awesome macrology of LISP possible. In Ruby you can manually build up strings and feed them into the interpreter, which is equivalent to simple backquote. But you can't do the kind of cool nested constructions that are trivial in LISP.

I still don't know How to start learning lisp as a beginner and use it for my day to day needs?

I don't think anybody today has the time to study the science behind lisp and then see where its useful to them.

We want some thing that we can browse through and straight away go and use now!

Is there a recipe book?

If you then decide you want to learn Lisp more deeply:

How to Design Programs is a book that teaches basic Scheme programming. It is oriented towards beginners, so if you want to understand recursion, higher order functions and data structures this book is for you. Conversely, if you already understand those things, this book is not for you. http://www.htdp.org/2003-09-26/Book/curriculum.html

Structure and Interpretation of Computer Programming is a more advanced and probably challenging book that goes through all aspects of recursion, data structures, symbolic mathematics, generic operations & implementing an object system in Scheme, continuations, writing a Scheme interpreter, writing a Prolog interpreter, and writing a hardware simulator and a compiler that compiles Scheme to that hardware's assembly language. http://mitpress.mit.edu/sicp/full-text/book/book.html

While Structure and Interpretation of Computer Programming all about code=data, it doesn't actually teach you about macros. For that you could read Paul Graham's On Lisp, which is essentially a whole book on macros. It is a good book to learn about macros which are useful in any Lisp but it uses Common Lisp which I'd not advice using.

In ruby you can[1] do this, and in python more natively[2]. It is not pretty though.

[1] http://bit.ly/sVYe8l

[2] http://docs.python.org/library/ast.html

In the end, we moved to Python for similar reasons.

But you inspired me. Thanks.

We want to know all about your Lisp experiences; or at least, I would personally love to hear about them.

I couldn't disagree with this more. I don't see what is so different about their type system but SBCL is doing more and more type inference for you.

As far as object model, generic functions are a superset of message passive. One good way to gauge the power of different languages is to look at the kinds of language-deficiency patterns you have to use. What drew me to Smalltalk was that it needed so few compared to, e.g. Java. What made me leave Smalltalk for Lisp was double-dispatch patterns. Double-dispatch patterns (e.g. Visitor) simply aren't needed in a language with generic functions.

>And 30 years later, listeners still rule!

With this, do you mean the REPL or something else?

Not that I think that is a good trade-off vs all the advantages of generic functions. Besides, the things people accomplish with doesNotUnderstand are much better accomplished with macros anyway.

I would say they are. Generic functions can dispatch on a single object if they want to.

As far as doesNotUnderstand, most OO languages don't support it anyway. Further, while I can't find it just now, I seem to recall MOP or CLOS itself providing doesNotUnderstand functionality. You could also either provide a doesNotUnderstand specialization on T, or set up a single handler for it.

If you insist on similar semantics to Smalltalk/Ruby/JS(?) then it wouldn't be hard to use MOP to create a new kind of method dispatch that simply turned the call for a failed specialization lookup into a does-not-understand call as a last step instead of signaling error.

    class Foo
      def method_missing(meth, *args)
        puts "#{meth}(#{args.join(',')})"
      end
    end

    f = Foo.new
    f.foo() # prints foo()
    f.bar(1,2) # prints bar(1,2)
    f[2] = "hello" # prints []=("hello")

Why is this interesting? For example because with this you can implement transparent remote objects. When you make a call on the object, it makes a network request, on the other computer the call is made and the result is sent back over the network, and finally the original method call returns. So the code would end up looking something like this:

    # server on ip 1.2.3.4
    shared_object = Array.new
    shared_object[3] = "good morning"
    serve_object("foo", shared_object)

    # client
    remote_object = RemoteObject.new("1.2.3.4", "foo")
    remote_object.length        # makes a network call to 1.2.3.4 and computes the length
    remote_object[3]            # returns "good morning"
    remote_object[3] = "hello"  # sets the index 3 to the string "hello"
    # code in the server can now access shared_object[3] and it will get "hello"

All in all, I think that generic functions are better than message passing, but generic functions are definitely not strictly more powerful.

Are you using Ruby in game runtimes, or just tools? How do you feel the use of Racket worked out in the Uncharted games? It seems like an embeddable Lisp (like Racket) might just hit the sweet spot for enabling DSLs and dynamism without bogging you down in an outdated platform like CL.

(P.S. big Naughty Dog fan here... I've always wondered about these sorts of details. I think a lot of programmers are very curious about your war stories.)

http://all-things-andy-gavin.com/2011/10/25/lispings-ala-joh...

Smalltalk, more than Lisp or Java, is just not suited to little programs that get the job done. It is really great for rapid development of things that live in the Smalltalk image and play with other Smalltalk objects... but stepping outside of those boundaries is often painful and frustrating. Squeak, for example, is plagued by arcane and undocumented classes for socket I/O or HTTP.

It just feels like its own isolated world compared to a simple Ruby hashbang script that reads from stdin and writes to stdout.