I dont use LISP or similar blends of functional programming mostly because how difficult it is for me to grasp whats going on. Perhaps its because of my first couple languages I've dabbled in, or perhaps the way I'm genetically built, or whatever, it is just a very difficult thing for me.

I have been spoon-fed the basics of a few blends of the LISP family and I had to work 10x as hard to pass the project.

I think LISP in principle is awesome - so long as you can grasp it easily/quickly.

My thoughts are: I've got along fine thusfar without Lisp, what should compell me to try it *now*? I started using C++ because of C's lack of features, I started using Java because of C++'s irresponsible design, and I started using C# because of Java's bloat. What does Lisp get me from the deal, how quickly does it get it for me, and why wouldn't I just interop with F# instead?

Quote: Original post by Zahlman
[...]In vim (and regardless of the language), moving the cursor next to a bracket will highlight it and its matching open/close.

Every programming editor I've ever used does something similar, and it helps a lot for C++ or PHP or other such languages.
Unfortunately, when staring at a screenful of Lisp code, knowing what a single parenthesis matches doesn't help. I need to be able to take it all in at once and just know from the appearance what the structure of the code is. In C++, for example, it's trivial to visually identify nested 'if' statements. In Lisp, using any of the many traditional conventions, it'd be a complete pain and entirely not intuitive based solely on the layout of the text.

Quote: Original post by capn_midnight
My thoughts are: I've got along fine thusfar without Lisp, what should compell me to try it *now*? I started using C++ because of C's lack of features, I started using Java because of C++'s irresponsible design, and I started using C# because of Java's bloat. What does Lisp get me from the deal, how quickly does it get it for me, and why wouldn't I just interop with F# instead?

Lisp brings enlightenment.

At the very least, if you've never read the original Lisp paper, you should do so: RECURSIVE FUNCTIONS OF SYMBOLIC EXPRESSIONS AND THEIR COMPUTATION BY MACHINE

In my opinion, Lisp is amazingly elegant from a computer science point of view, but if your main concern is software development, it's only worth admiring from afar, much like lambda calculus or combinatory logic.

Quote: Original post by Extrarius
Lisp brings enlightenment.

You might as well have said "Lisp brings chips to the party;" it would be equally meaningless to me. Lisp has had the last 50 years to "take the world by storm" and I've yet to see a definitive argument for why. Saying, "you have to experience it" isn't enough. Be articulate enough to describe what you mean without resorting to hand-waivery. "I use C# over Java because the .NET class library is cleaner than Java's class library" is a reason to use C# over Java. "I use C# over Java because C# makes me feel like I'm on mushrooms" is NOT a reason to use C# over Java. I understand how to write recursive functions, I understand their importance, I understand all of that. What does Lisp bring to the table that I can't get elsewhere? Hell, even &#106avascript gives me functional programming these days. Dispense with the flowery language, please.<br><br>It's probably this very attitude, this exclusive "if you haven't experienced it, you wouldn't know anyway" mindset, that turns so many people off of Lisp. We might all be interested in how Lisp can help us, but damn, it's like pulling teeth getting any answers about it.

No, see, you're still doing the hand waivery thing. You have yet to mention anything unique to Lisp that makes learning Lisp a constructive use of time. Sure, the proliferation of functional programming concepts may be due to some pioneering that Lisp did, but we don't learn ALGOL over C these days.

As it stands, I already do a *lot* of functional programming in &#106avascript. It's pretty much the only way to avoid breaking someone else's code when working on a large project with multiple people. I do *some* functional programming in C# 3.0 whenever I use Language Integrated Query, and the opportunity is there to use it in plenty of other instances. Ruby, Pythong, C#, &#106avascript, I could go &#111;n, all have functional programming built into them, without having the durned-all goofy syntax that Lisp has. Yes, yes, yes, you're manipulating the parse tree. A) Still not convinced that's even a good idea, and B) doing that doesn't require the syntax to suck so hard. Given that a good portion of software development tasks are procedural by their very nature (e.g. I/O), it probably makes more sense to make functional programming the exception rather than the rule in a programming language, just as all these other languages have done.<br><br>Like Extrarius said, give me something to break the code up some, so I can see what's going &#111;n.

Quote: Original post by capn_midnight
No, see, you're still doing the hand waivery thing. You have yet to mention anything unique to Lisp that makes learning Lisp a constructive use of time. Sure, the proliferation of functional programming concepts may be due to some pioneering that Lisp did, but we don't learn ALGOL over C these days.

If you want some well articulated arguments for using Lisp, Paul Graham's essays are a great place to start

Interesting diversions aside, the original point of this thread was to ask people who are using Common Lisp and other functional languages to come forward and discuss what they've found when using those languages for games.

Quote: Original post by capn_midnight

Quote: Original post by Extrarius
Lisp brings enlightenment.

You might as well have said "Lisp brings chips to the party;" it would be equally meaningless to me. Lisp has had the last 50 years to "take the world by storm" and I've yet to see a definitive argument for why. Saying, "you have to experience it" isn't enough.[...]

In the last sentence in my previous post, I specifically said that Lisp isn't for software development, which kind of nullifies the rest of your post. It doesn't have a huge class library of relevant utilities, most of its functions are cryptically named (despite allowing more symbols in names than most languages and never having name length limits - they were cryptic from the start), it doesn't have basic features like threading or interprocess communication, it supports referencing external functions but won't mesh well with them due to its different paradigm, etc.

If you're not interested in things like Gödel's theorems, or Escher's paintings, or Bach's symphonies, you can happily ignore Lisp along with other beautiful things. If you enjoy beauty, it's worth learning (note that I didn't say using) because it is beautiful. It defines an amazingly elegant language that has features that modern languages just picked up in the last few years.

If you want me to play art critic: The idea behind Lisp's elegance is that "Everything is the Same". It reaches a level of uniformity that no other readable language I've seen approaches. For example, there are no infix or postfix operators - every operator is a function (or special form, in a few rare cases, but it has the same syntax). The only distinction between code and data is the way you treat it. You can use the extensive list processing functions to manipulate a list into just the right form and then execute it, because "Code Is Data".

Consider that "Lisp" is "List Processing" and that Lisp code is stored in lists. It's simple, elegant, powerful, and excessively flexible. It's an extensible programming language.

Sure, modern languages have reflection, but text processing is messy. Making a C# program that can load a C# source file and optimize all calls to Math::Sine (or whatever C# calls it) that specify a constant is possible, but it'd be a huge undertaking. In Lisp, which has significant list processing features and which stores code as lists, it is not nearly as difficult to do.

Other functional languages might support 'code is data', but without s-expressions that represent code as lists, the transformation between an easily modifiable representation and an executable statement gets messier and becomes more difficult to deal with. When you introduce infix and postfix operators, you have to start doing serious transformation in order to parse a language, but because Lisp only has functions and it parses the code from the tree-in-text representation to tree-in-memory for you (in a way that you can hook and modify, if desired), it's trivial to modify code in its native form.

Quote: Original post by pTymN
Interesting diversions aside, the original point of this thread was to ask people who are using Common Lisp and other functional languages to come forward and discuss what they've found when using those languages for games.

Sorry to have broken your thread, but as you can tell, Lisp is a hot topic around here. I think Lisp is amazing, but it thwarted my attempts to do serious work in it, and after a lot of meditation on how something so amazing can be not-good, I came to the conclusions I've expressed in this thread.

[Edited by - Extrarius on January 18, 2008 9:16:28 AM]