[ricky_clarkson]

You made assertions that possible things were impossible, and asked how to do intrinsically non-functional things in a functional way.

I think you experienced a typical IRC reaction of "annoy the newbie because it's easier than answering him". It seemed to work. I've seen it in non-Lisp channels too.

You need to store things on the heap or on the stack, there is nowhere else. When you're thinking in objects, program in objects. To think in objects but then try to write functionally is going to cause you difficulty. You can write procedurally in Lisp, without OOP, it's not just a choice between OOP and FP. Lisp programmers treat these as tools, not lifestyle choices.

[palish]

I think you experienced a typical IRC reaction of "annoy the newbie because it's easier than answering him". It seemed to work. I've seen it in non-Lisp channels too.

Hell yes it worked; that's why I wrote this article. The problem with the Lisp community is that it's the first reaction, not the last. You won't get this on #gamedev. You'll either get a "Google it" or a helpful response.

I also asked if Lisp constructs could be stored on the stack, instead of the heap; not whether they could be stored in some magical place that doesn't exist.

[shiro]

Yeah, I've seen the pattern. Part of the problem is, I guess, that Lisp has long history and stable user base so that the newbie/expert ratio is much lower than other languages; and (a) experts tend to forget how they were like when they were newbies, or (b) even they remember, there weren't such a thing like irc back then and they figured out most by themselves, so they expect a newbie nowadays can do the same thing.

However, another part of the problem, which I think is larger, is that the way of functional thinking is so different than the way of procedural thinking, and it is simply impossible to tell concisely "this is the functional way" (except very abstract statement like "avoid side effects"). If the asking one only has procedural background, his very question often doesn't make sense when viewed from the functional world; and we cannot answer a question which is not really a question.

Take one example: You asked about stack and heap. Probably you assumed a specific storage model, used mainly in C, C++, etc. However, in many functional languages, the extent of objects are just infinite by default, conceptually---and you just let the compiler to figure out which objects can be stack allocated and which should be heap allocated. Or, even a compiler can allocate everything on stack first, and when stack is popped or becomes full it moves live objects into heap, effectively using stack as a nursery of objects. It all depends on implementations, not the language. See, just asking "how to put an object on the stack instead of a heap" doesn't really make sense, except you are talking about a specific optimization technique on a specific implementation (in which case you should've already known the language and quite deeply about the implementation.)

This is just an example. Treating states, when to use mutation, how to model I/O, ... all require very different views.

I program in Lisp/Scheme both for work and hobby, and I feel sorry about your experience. If you still think giving a try to the functional way, another path may be to taste a few other functional languages (Haskell seems to get quite attention recently, and ML claims very fast); then you'll get the perspective of procedural vs functional ways, instead of (all other languages) vs Lisp.

[ricky_clarkson]

If you look at the relevant logs, and see what Peter Seibel said to you, your question was answered immediately. I'm not sure that you noticed though.