The reason I like Lisp is because programming in it teaches you how to organize your code well using the most basic and important design pattern: the function.
Design patterns are patterns which can be used for designs. All patterns can be used for designs; "design pattern" as a phrase merely signals that the pattern was described in a certain book.
Functions are too simple and concrete to be patterns. A function is a mapping from one set to another. Even category theory manages to fully generalize functions several different ways without managing to define something as general as a pattern.
So, you might ask, what are patterns? Patterns are things which repeat somehow. That's it. There might be more to it, but I have yet to find it.
I'm glad that you like Lisp, but it's not the beginning nor the end of programming. For example, the Post correspondence problem is Turing-complete. So are Wang tiles. Where's your functions now?
I believe ktRolster may be refering to "Procedural Abstration". The term is used in SICP [1] (the Wizard Book using scheme, previously freshman programming text at MIT).
Abstration can take many forms. But can often be described as "seperating things that change and/or repeat from those that don't", or something like that.
The last paragraph may be a joke, or based on one of the Principles in the O'Reilly Design Patterns [2] book.
I've read your comment several times, but I'm not sure what you're saying, actually. Certainly functions have been described in several books. No one is said that functions are the only design pattern.
Why not? They are general repeatable solution to a commonly occurring problem in software design - ie, a design pattern. You had non-structured code, then people started using small chunks of code that you'd jump to and back from multiple locations. It's a pattern, that just happened to get encoded directly into some languages, just like others (Norvig talks about the levels of implementation in his presentation on the subject: http://www.norvig.com/design-patterns/design-patterns.pdf)
To me, functions alone aren't abstract enough to be considered a design pattern. If they were, any arbitrary chunk of code, however disorganized, could be considered an implementation of that pattern as long as it used functions, which seems counter intuitive.
I think they're just a victim of their own success. Particularly the iterative language concept of 'function' is by no means universal. They were kind of grafted onto mainframe architectures, and even the MIX from the original The Art of Computer Programming used self modifying code to perform subroutine calls.
Functions are an extremely common pattern more or less expected by every language, but I'd definitely call them patterns still.
A function is not a design pattern. A design pattern is a design that solves a problem. Without stating the problem to solve, you have not got a pattern. The OP stated that they used functions to organise their code, so you can imagine some problem that they were solving with functions. For another problem you might solve with functions, I was reminded recently that functions are an implementation of the state monad. If you read up about where you might use the state monad and why you need it, then perhaps you can get a better feeling for why a function is a good implementation of that pattern.
Says someone who's never used a language that only had gosub. Figuring out how to use functions appropriately is one of the most important skills of software engineering.
