Just to be pedantic... Scheme and Common Lisp are both Lisps. Lisp is a super-set of languages. Or, to use the terminology lispers prefer, Scheme and Common Lisp are two different "dialects" of Lisp.

------------
:Wq
Not an editor command: Wq
[download]

If you mean Structure and Interpretation of Computer Programs then ++. It's excellent

Scheme is not newer than Common Lisp. It is newer than most of the Lisps on which Common Lisp is based, but Scheme definitely had influence on the shape of Common Lisp. For example, refer to:

The introduction to the Hyperspec

I learned Haskell in my first semestre at university and it was a very interesting new perspective on programming. I'll wholeheartedly recommend Haskell as the most "pure" functional language I know and thus the one you'd probably want to learn first.

However, because of this "pureness", some common tasks are made awfully awkward. Best example are probably IO routines which, by definition, are not free of side-effects because the side-effect (here: the disk operater or whatever) is the operations whole purpose. Since that doesn't fit in the concept of purely functional languages, the purists couldn't sleep well. But they were clever purists and decided that hence forth, such operations were to be called monads, which, as the documentation told me, are some obscure mathematical functions that may have side-effects. I'll refrain from posting example code since that'd become really off topic.

On the positive side is that Haskell has a graphics library and both interpreters and compilers for ease of debugging or speed. It's easy to read once you got the hang of it, too. I suggest you start with Haskell.

Steffen

Not having any experience in Haskell, but having tried Prolog a few times in the 80s and 90s, I remember the pain of doing things that fell outside the "declarative" realm.

For example, just about everything that had to do with a user interface. Printing text is a "side effect" (or in your Haskell terminology, probably seen as a monad). Asking a user a question. Responding to the user's input.

The big problem in Prolog with such constructions was that Prolog's whole view of the world was that you could search a database of rules and backtrack as necessary. But with monadic tasks, you really don't want any backtracking. You don't want to pop up a dialog on the user's screen, wait for an answer, and then backtrack (possibly trying a different dialog box) when you realize that the user's answer didn't get your program any closer to a "solution."

--
[ e d @ h a l l e y . c c ]

Having just read ANSI Common Lisp, I have to say it is a truly excellent book. It's not that it just teaches you Lisp well, it also enthuses you with why Lisp is an enjoyable language to program in.

While I can think of several books that have managed this with Perl, comparatively few covering other languages seem to be suffused with the authors love of the language. The only other example that immediately springs to mind is Peter Van Der Linden's Expert C Programming - Deep C Secrets.

Go with Haskell. Lisp will allow you to fall into faux-imperative style programming, and you'll make many of the same mistakes tilly did when he wrote the node you linked above.

Ditto all the SICP stuff though. You can even download the lectures, in glorious EIGHTIESOVISION video. Worth doing, if only for the first couple of chapters.

My AI class in college was taught in lisp. I found Lisp to be cool, but limited in terms of provided API's bindings, etc... is Haskell any better in that extent? Are there options for graphics libraries (i.e. if you were sick-and-twisted enough can you do OpenGL in Haskell?).

Anyhow, these kind of languages are what Computer Science is meant to be about. It's what draws me to Perl. Text processing isn't a huge chunk of the allure -- more so, it's the closures, anonymous subroutines, and other constructs which are more closely related to Lisp and other languages -- and harder to implement in most of the "business" languages of the day.

It appears Haskell is the way to go -- after all, one won't go blind from reading on too many parenthesis :)

As an aside, I'm a graduate of NC State University, where my AI professor lead a little project called 'Mimesis'...essentially there were writing an intelligent story generator in Lisp that drove a Quake engine which retold part of the story of Beowulf. Interesting idea -- but I knew one of the guys who worked on it -- and he said he had to roll his own XML parser in Lisp! Ouch! Things like that tend to keep me away from new languages, when the tools aren't there -- Perl is nice in this manner because there is a low barrier to entry in any sort of new task -- and a strong toolkit. But yes, it's too easy to think you are doing functional programming when you are not.

That last bit is always the rub, no? If something is largely pre-implemented (via CPAN, etc.) in Perl and Perl will perform adequately, I tend to use it. If I'm going to need to write a lot of my own code I tend to use Lisp. Fortunately more and more useful stuff is becoming available in Lisp all the time, e.g. at Cliki. Anywhere near CPAN? No. But often enough to push the amount of stuff I need to do on my own down enough to where I can use Lisp.

Thanks for the Lispy links. I *did* like Lisp, it was just that I didn't know how to do a lot in it. Fun language, challenges your neurons to reprogram themselves, and I consider that a Good Thing (TM).

Actually, I find XML to be pretty simple to parse. If you know XML well and you have a decent grasp on parsing in general, writing a non-validating XML parser is a simple task. Not surprisingly, either, as that was one of the stated goals of the working group, after SGML failed to be accepted due for the most part to excessive complexity.

But, yeah, having to hand roll all the tools for every aspect of the task at hand is boring drone work.

Makeshifts last the longest.

I prefer Common Lisp, but I don't necessarily recommend it for learning functional programming, as imperative and object-oriented programming are just as common in Lisp and functional. Schemers tend to be more functional than Common Lispers, but I still don't think that Scheme forces functional programming on one the way that Haskell or an ML would (in ML's case because it's hard, but not impossible, to do anything else).

If at some point you want to learn (Common) Lisp, I recommend Peter Norvig's Paradigms in Artificial Intelligence Programming. In spite of the title, it's more a study of how to program in Lisp than of AI. And unlike Graham, who has a "funny accent" in his Lisp, Norvig's code is very mainstream.

ANSI Common Lisp is (IMHO) and excellent book. It gets a little dense towards the end with macros and such, especially if you are just reading it, and not writing and experimenting with LISP along with it. But the first half is an excellent introduction (and I must stress introduction) to the basics of what functional programming is all about.

Keep in mind that tilly's post is not really about the same kind of functional programming though. Its a classic post, dont get me wrong, but its just not the same thing.

As for Haskell and other such "pure" functional languages, I have never really liked them. Not having been a Comp Sci or Math major I found some of the syntax and paradigms to be pretty difficult to get my head around initially since i lacked a solid background in the underlying concepts (especially since I was doing it for fun and not for profit). Also, IMO Haskell is sometimes just too strict, I mean its a nice idea to model things like I/O in a side effect free way, but the fact is that when writing to a disk, you really are going for the side effect. I kinda think it just goes too far.

I would look into other not-so-pure functional languages too. Erlang is a favorite of mine, it looks alot like Prolog and is therefore sorta declarative, but is not so much about backtracing through a db of rules. It has single assignment variables, and uses recursion as its prefered means of iteration. While not as pure as Haskell, etc. it still has some valuable lessons to teach the curious programmer.

Also, and this has been mentioned here too, Standard ML is a great language for learning the functional paradigm. You can still do imperative stuff in ML if you want, and it has a pretty cool module system called functors. Its syntax is not as obtuse (to non-functional programmers) as some of its derivatives (OCaml, Caml, etc). It has an intensly cool type inference system (for more info on that read Dominus's article on Strong Typing in Perl chapter14 onward talks alot about ML's type inference system and why its sooo cool). There are a number of good ML books out there, and plenty of online info, most of which is pretty solid.

And dont forget about Perl! Perl is truely a multi-paradigm langauge, and can do functional pretty well. I once wrote a side-effect free, assignment-free perl module after reading too many books/sites about functional programming. I posted it on my scratchpad if you care to look, almost 300 lines and not one '=' operator. Of course it's pretty inefficient and largely useless in any real-world scenario, but hey this is functional programming we are talking about, so purity is paramount!

Anyway, enjoy your foray into the world of functional programming, IMO its one of the most valuable tools you will (almost) never use :-)

1. Do you call this

   sub tail (@) { shift; @_ }
   [download]

   functional programming? You clearly rely on the side effect of shift here. Better use

   sub tail (@) { @_[1..@_-1] }
   [download]

   or something like that.
2. Please do not make links to your scratchpad from your post. The data from will most probably disappear eventually from the scrartchpad, but the post will live forever so if someone reads it years later he'll be upset than he cannot see the code.

re: #1
You are absolutely correct. Good eyes there. Of course if we are gonna be picky, then head should be:

sub head (@) { $_[0] }
[download]

to also avoid the "side-effect" effect of shift.

re: #2
I see what you are saying here, but approx. 300 lines of code IMO, is not really appropraite to post in a node. As for posting the code elsewhere (website/CPAN/whatever), it was really just an exercise for fun, to see how far i could push Perl into the realm of functional programming, I have no delusions that it is good for anything outside of that.

-stvn

More information...

The resource I have always recommended here is How To Design Programs. This online book will take you through the basics of Scheme. Its fairly low level, so you can skim the first few chapters, but it has a ton of exercizes, so you'll get a lot of opportunities to extend the examples.

The other book I always end up recommending is The Structure and Interpretation of Computer Programs. This one leans more toward traditional computer science, but you'll definitely learn a lot if you've never read this book before.

Strangely noone in this thread mentions commercial computer-algebra systems, altough those do support functional programming (even more than lisps I think).

Or an Open Source Computer Algebra System, which uses lisp and is so much fun, it's amazing that it's not USA-illegal.
It should work perfectly the first time! - toma

It has most of the elements of functional programming built-in. I used it to go through the first two chapters of SICP. I started with this page, specifically an article on Perl's implementation of Lambda Calculus, and went from there. The Lambda Calculus is at the heart of functional programming.

There is also an article on using Perl for functional programming over at IBM. After you've read this you'll see (assuming you didn't know of course) that you've done some functional programming before and just didn't know it.

A Google search will find more.

Hope this helps,

Cheers,

John