programming with functions

is functional programming at least most of what it's cracked up to be? nothing is everything it's cracked up to be, so is FP at least most of what it claims to be?

i know whats-his-face says you should learn LISP because it turns on god-mode for programming and LISP has a bunch of functional...paradigms, i guess, but functional programming seems like a lot of super-academic handjobbing and hobnobbery.

>>1
functional programming
programming with functions
Back to /pr/ please.

>>LISP has a bunch of functional...paradigms, i guess

LISP has no paradigm.

or more correctly, LISP has every paradigm. 

This is why it is God of programming languages.

Lisp is multi-paradigm.
Meta-programming, imperative, functional, object-oriented, anything you could imagine, it has it, as long as you can imagine it.

>>5
If you mean FIOC as in indentation-based syntax, it can be done if you use a custom reader. I'm pretty sure I heard of people experimenting with similar readers. There's also Dylan, but I don't think that's FIOC.

If you mean FIOC paradigm as in, limiting the programmer's options and going in a ``there's only one way to do it'', then yes and no - Scheme is somewhat minimal, but they don't really limit what you do with it(it's still a Lisp... to some degree), except the culture is geared towards minimal language like FIOC. CL is geared toward the other extreme (larger initial library), but the language doesn't change, unlike Scheme which is still getting new revisions. It doesn't really matter, since if you have macros(in a homoiconic language), high-order functions and a decent set of data types and functions to operate on them, you're already limited by very little, so I don't think it can be FIOC in the sense of S&M, even if some dialects do go there slightly.

Fuck, I keep meaning to learn Lisp but I keep putting it off.

I just can't get into any of the intro Lisp books (and I have other projects to work on)

>>7
http://www.lisperati.com/casting.html

>>4
What about a strict type system?

>>9
You can implement type inference if you need it. Some CL compilers do it, as CL does support type declarations (either to obtain speed or to improve type-checking).

You could also implement your own statically-typed Lisp(see Qi  for an example), or take a statically typed language like Haskell or O'Caml and write an S-Expression based syntax.

However, even if all these things are possible, most Lispers aren't that keen on static type systems (or other things based on restricting how a language works. My personal opinion here is that I find writing Lisp more effortless than I find writing ML, but the experience is a bit too different to describe). They'll usually take the fun parts, like pattern matching languages and just keep their dynamicly typed language.

>>7
Here's some starting resources for you:

Scheme:

SICP - General programming book/bible, but it also shows Scheme.
Little Schemer - Introductory Scheme book
HtDP - SICP-like, simplified.
RnRS - The standards. Read them. ( Read at least R5RS. )
LISP in small pieces - Intermediate-Advanced. Mostly Scheme-oriented compiler/interpreter building book. Very interesting and entertaining read, show semantics of various Lisps. Even if it's written in Scheme, a lot of CL-related semantics are discussed too.

Common Lisp:

http://www.gigamonkeys.com/book/ PCL - great introductory-advanced book, compehensive, practical, up to date.

http://norvig.com/paip.html PAIP - Teaches both AI and CL, great book.

http://www.cs.cmu.edu/Groups/AI/html/cltl/cltl2.html CLtL2 - pre-ANSI CL reference, more readable than the Hyperspec, but there are some differences from that and the standardized version

http://www.paulgraham.com/acl.html ANSI CL - introductory-intermediate, decent, but PG will only show off the parts of the language he likes and in the way he likes it, which means you'll miss some rather cool features. If you choose to start with this, be sure to check out PCL as well.

http://www.paulgraham.com/onlisp.html - On Lisp. Beginner-Advanced - focuses on macro writing, closure networks, parsing, pattern matching and other interesting topics.

Keene's Object-Oriented Programming in Common Lisp - Beginner-Intermediate - Pretty good CLOS introduction. Easy to read, also a good book about OO design in general.

The Art of the Metaobject Protocol - Intermediary/Advanced. Great book if you want to truly understand CLOS(and its MOP) and how to extend/"redefine" it.

http://lisp-book.org/ - Lisp Outside the Box - Incomplete book about the practical matters of using current CL implementations and libraries. You should also check out its SLIME chapter as it's a really useful Emacs interaction mode.

http://www.lispworks.com/documentation/HyperSpec/Front/ - The Hyperspec. HTML version of the standard, the REFERENCE. Set up your Emacs to look up function definitions here. It's very useful when learning, and not only. It's not meant to be read in full, unless you're already familiar with CL, and possibly plan on implementing the language. If you're serious about CL, you'll probably end up reading most of it anyway when you look things up. Newbies might find it terse.

Oh, and here's a reasonable, but a bit outdated introduction by someone else: http://p-cos.net/lisp/guide.html

There's probably other good books that I forgot to mention, but you should probably read at least SICP from those books, and then get a feel for Scheme and CL, and learn one or both of them. I'm mostly a CLer, but I'm fluent in Scheme as well, even if I don't write much code in it. Knowing more than one Lisp dialect isn't hard, but you'll probably end up liking to write code in one more than the other (some like Lisp-1, others like Lisp-2. Some like small languages in which they can experiment on things like language semantics, others like bigger languages with well-defined behaviour geared towards more large-scale development).

Oh, and if you plan on learning, be sure to get a good implementation and a good editor that comes with it. For CL, that would be Emacs+SLIME+Paredit+Redshank and SBCL, ClozureCL, CLISP, LispWorks, Allegro ... as an implementation. For Scheme, I've mostly used PLT (now named Racket) and MIT Scheme.

>>10
You could [...] take a statically typed language like Haskell or O'Caml and write an S-Expression based syntax.
most Lispers aren't that keen on static type systems (or other things based on restricting how a language works

I wish these concepts weren't confused so much. Functional programming is not required for static typing and type inference.

Taking Haskell and changing the syntax will not accomplish anything; the syntax is not what is wrong with Haskell. What is wrong with it is that few people like programming in a purely functional language, and few people are capable of doing so, and few programs lend themselves well to this style.

I know most Lispers are not fond of static typing, and I'm really not sure why. It seems to me that Lisp would be great as a high-performance language for stuff like game development if it offered static typing and an incremental (non-blocking) garbage collector. Manually bolting in type annotations after the fact is a terrible way to improve the performance of code.

Functional programming is not required for static typing and type inference.
Where did I claim that? A language supporting the functional paradigm does to require dynamic or static typing.

Taking Haskell and changing the syntax will not accomplish anything; the syntax is not what is wrong with Haskell.
Did I claim that there's something wrong with Haskell? The reason I said to make a Lisp-like syntax is to allow for easier macros, as removing the syntactic soup and just using S-Expressions allows you to do that. I'm actually not entirely sure it's such a good idea, without actually defining a macro system (will it be a macro system allowing the full power of the language? can one integrate it with haskell's purely functional style? will it be a pattern-based macro system which enforces hygiene? and such questions).

It seems to me that Lisp would be great as a high-performance language for stuff like game development if it offered static typing

You desire that types be infered and declarations be made unnecessary? This is possible to some degree, and some compilers can do it (SBCL is pretty good at this, I've had it detect typing errors in my code quite a few times, and it does assume the types it infers, providing proper optimization settings are used), but the problem is less in the compiler and more in the language. CL itself was designed to be highly dynamic, and a lot of the functions allow a wide range of arguments (for example, generic sequence types, or having all arithmetic operations work on a wide variety of numeric types (fixnum, bignum, ratio, complex, float(s), real, ... ). The language's library was designed in ways not unlike CL's generic functions to allow polymorphism.

To make static typing truly work in Lisp, you'll need to define a new language or make a subset of a current one which lends itself to static typing and type inference. I'd be interested to see further work in this domain.

However, I don't think the performance of current CL implementations is bad. I believe some of them would be quite usable for games, maybe with a bit of gc tuning. I've used CL for some complex and intensive data processing tasks, and it has performed rather well (in modern implementations). Most of the time, the real reason the code is slow isn't because it's not written in C, but it's because of poor algorithmic choices - making changes to fix such problems is usually rather easy in Lisp and can be done with little effort. Porting the code to C could give you some 1.5-3+ times the speedup, at the cost of a lot of time spent porting and debugging, the question is if the gain is really worth doing the rewriting.

*does not require

>>12
Where did I claim that?
You recommended using an S-exp syntax wrapper to Haskell to get a statically typed Lisp. A horrible idea because Haskell is purely functional.

Did I claim that there's something wrong with Haskell?
No, I did. I went off on a tangent about how Haskell is too tedious to use in order to invalidate your claim that an S-exp wrapper for it is a good idea.

a lot of the functions allow a wide range of arguments
Irrelevant. C's operators do too (fixed, real, complex), and C++'s vastly more so because of operator overloading. These languages have no problems coping with static typing and limited (expression-based) type inference.

The language's library was designed in ways not unlike CL's generic functions to allow polymorphism.
Polymorphism can be supported in a language with type inference. Look at a language like Go; it already infers protocol adherence for you. Inferring the type to automatically choose a common protocol when differently typed references are shared should not be that difficult.

To make static typing truly work in Lisp, you'll need to define a new language or make a subset of a current one which lends itself to static typing and type inference.
Agree wholeheartedly. You certainly need at the very least a totally different API for the library. This is also largely why I think adding type annotations to Common Lisp aren't really a good solution at all.

You desire that types be infered and declarations be made unnecessary?
Indeed. Yes SBCL does it to some extent. The problem is those cases where it can't be inferred, it just transparently results in dynamic code; you can't reasonably expect what will be inferred, and it is in no way standardized or portable. If a type inference cannot be done, I would much prefer the compiler fail it and allow me to fix it (like Haskell.)

However, I don't think the performance of current CL implementations is bad. I believe some of them would be quite usable for games
It would not even be remotely useful for a modern 3D game engine, which is not only the largest part of the code, but also the part that would benefit the most from Lisp's features.

I say this of course speaking of high-end titles. You can't write a game that competes with your average off-the-shelf PS3 game in Lisp. It's just not possible. If you aren't going for great performance well you can write it in anything you want.

>[...] maybe with a bit of gc tuning.
I still don't understand why so few languages have an incremental generational copying collector. As much as I loathe Java, its garbage collector is great. Python's is a steaming pile of cow shit in comparison. I don't know where BCPL's lies; I've never actually tried to make Lisp fast (because when I need speed I choose a more appropriate language.)

a lot of the functions allow a wide range of arguments
Irrelevant.
Should I have said arbitrary arguments?
Take the function APPLY or special form MULTIPLE-VALUE-CALL. The only thing you can infer about them is that the first argument is supposed to be a function. You can't reason about any of their other arguments, or the return type, or even the amount of arguments that will be passed to the function (first argument). If the function is taken from another variable (such as an argument), you can't obtain any info about it, so you'll have to assume anything can be passed to the function.

Now take another issue, the standard lambda lists (rest, optional, key). If a function uses a rest argument, then all the arguments passed to it matching said rest argument's position will be consed up into a list and passed to the function (some implementations can optimize this in various ways to avoid consing, one of the most widely supported tricks being using dynamic-extent when the arguments are just supposed to be passed-through to another function).
A function which takes a rest argument will receive an arbitrary amount of arguments consed up as a list. That list can then be destructured/parsed in a variety of ways by the function to extract the needed information/arguments. Infering types here would be problematic again.

It should be kept in mind that these language features are often used in programs (because they are useful.), but they make infering useful types hard if not impossible (since the types that the functions are operating on are arbitrary lisp objects).

I'm not even mentioning how the language allows redefinition of code, and how CLOS itself is highly dynamic, and when MOP is involved, even moreso.

This doesn't mean that type inference cannot be done. It can be done on specific cases, and SBCL does seem to do a fair job with those cases, but it's not possible to fully infer the type signature of arbitrary CL functions and have it be useful.

To make a Lisp compatible with static typing, it'd have to be a new language designed from the ground-up with that goal in mind, or at least it'd have to be a restricted subset of the current language on which type inference can be performed reliably.

You can't write a game that competes with your average off-the-shelf PS3 game in Lisp. It's just not possible. If you aren't going for great performance well you can write it in anything you want.

That's assuming all those PS3 games squeezed every last bit of those SPU's and they're completly CPU-bound, and that the games themselves are using optimal algorithms in their work and so on.
I don't really see why it wouldn't be possible. Maybe not in portable Common Lisp, but if implementation-dependent extensions are allowed (and you'd need them anyway for a game), all bets are off. There's really no way to know until you try, but I don't think many companies are willing to take a risk and try something that differs from what everyone else on the market is doing.

As for SBCL's gc. It does have a generational gc, but not on all platforms (it has it on x86/-64 at least). The GC performs quite fine for normal applications, but I think for realtime games it would need some tweaking.

It might also be worth mentioning that SBCL isn't the only high-performance Lisp around. The commercial ones have some interesting offers(LispWorks, Sceineer, ...). LW even offers realtime GC if you ask for it.

On platforms like the PS3, I'd be more worried about getting the compiler to take advantage of all those SIMD instructions that the SPUs offer. I'd imagine current implementations aren't prepared for that... However, someone could probably write a compiler for a more low-level lisp which takes advantage of those instructions.

It's really hard to say what would be the limits until one's actually tackled the challenge.

<-- check em dubz