Very detailed and serious comparison of functional and imperative programming styles

Alright, it's not a detailed and serious comparison of functional and imperative programming styles.

It's just a modification of a picture that accompanied an article in american scientist magazine, written by Brian Hayes.

I've been thinking about functional programming since i read 'functional programming for the rest of us', last week. fascinating topic for your geeky-minded kid like me.

'Currying' and 'Pattern-Matching' look like two pieces of syntactic cleverness that could be baked straight into any .net language.

'Wesner Moise' on Mon, 26 Jun 2006 05:09:10 GMT, sez:

Functional styles can have variables... it's just that there is a limit of one assignment per variable.

'lb' on Mon, 26 Jun 2006 05:15:28 GMT, sez:

>a limit of one assignment per variable

if you can only assign to it once then maybe it's not exactly "vary-able" ?

it's more of a 'result' or a 'value' (or a function?) ?

i know i'm no expert on this stuff at all,... i've only read the articles listed above... in 'functional programming for the rest of us' he refers to this kind of variable as a 'symbol'

'optionsScalper' on Wed, 28 Jun 2006 02:17:14 GMT, sez:

Secret Dude,

". . . 'Currying' and 'Pattern-Matching' look like two pieces of syntactic cleverness that could be baked straight into any .net language. . . ."

Already there in F#. lambdas, closures, etc., etc.

But, I totally agree. This is the most detailed comparison that I have seen in years. Your choice of colors in your exhibit is likely the feature which makes this whole explanation useful.

BTW, F# allows for imperative AND functional program constructs in the same body of a program. Two-for-the-price-of-one kinda stuff.

---O

p.s. A few other .NET languages get into this stuff too, but I'm only an evangelist for this F# stuff ( http://cs.hubFS.net ). If you are a serious student of FP, then a useful text is Chris Okasaki's "Purely Functional Data Structures".

'lb' on Wed, 28 Jun 2006 02:30:18 GMT, sez:

phew... an F# dude read this post and didn't totally flame me... pure luck maybe.

still sweating on dipping my toe into a big ocean of misunderstanding...

and i know that .net framework 3 will lean on FP ideas more, but i don't really know where...

'ags' on Thu, 29 Jun 2006 09:47:01 GMT, sez:

.net framework 3? Can't call it *that* anymore!

'Wesley Shephard' on Thu, 29 Jun 2006 14:08:51 GMT, sez:

F# was the incubation ground for many of the functional pieces that will be in the next major framework version (whatever they will call it). F# had to build it on top of the CLR, while the new CLR will have support for such functional ideas baked in. Mmmmm. Baked lambdas.

'WaterBreath' on Thu, 29 Jun 2006 15:47:33 GMT, sez:

This is a nice illustration of the syntatic and executional differences between functional and declarative programming languages. What we need next is a nice illustration of when and why functional can be better than declarative.

The first thing a curmudgeonly programmer who loves him some declarative programming will see is a runaway call stack. This example looks ok for 4 iterations. But what if the scenario called for a thousand, or a million? That's a million context switches: a million parameter lists, a million code pointers, etc.

Not being particularly experienced with functional programming, I would assume this runaway scenario is avoided either explicitly by some other language feature not shown here, or implicitly by the compiler/optimizer. This type of information is "need-to-know" for people wanting to know "what can a functional language do for me?"

'lb' on Thu, 29 Jun 2006 21:09:40 GMT, sez:

re:
>.net framework 3? Can't call it *that* anymore!

i was careful to say 'framework' as opposed to just .net 3...

what i mean is... the next major version of the .net libraries and .net clr...

not "the next big package from microsoft that has a .net sticker on it".

'lb' on Thu, 29 Jun 2006 21:12:00 GMT, sez:

>a runaway call stack

yep, i'm certain they do stuff about this...

a nice little description of what they do, and how would be fun to read.

>curmudgeonly programmer who loves him some declarative programming

love it.

>Mmmmm. Baked lambdas

I like mine curried!

'Wesley Shephard' on Fri, 30 Jun 2006 15:32:08 GMT, sez:

The runaway call stack is avoided by "tail recursion" optimization. If the recursion is the *last* thing being done on a call path (which it is in the example program here), there is no reason to maintain the stack frame anymore.

So instead of pushing a stack frame, we call the recusive call in the context of the old stack frame, and when it returns there is only that single stack frame (the initial call) to pop off.

'WaterBreath' on Fri, 30 Jun 2006 16:19:15 GMT, sez:

> we call the recusive call in the context of the old stack frame

Kind of like a GOTO... But _after_ compile, so it's not "considered harmful". ;)

> when it returns there is only that single stack frame (the initial call) to pop off

Very interesting. So sounds like this type of example would compile down very similarly to a traditional explicit loop. Good to know. I am still curious about more complicated scenarios--things less arithmetical--but I suppose I can look into that for myself. =)

Anyway, thanks!

'mqb' on Wed, 08 Nov 2006 19:58:22 GMT, sez:

> If the recursion is the *last* thing being done on a call path (which it is in the example program here)

Not to be too pedantic, but technically in this example tail recursion isn't applicable. The last operation being performed is a multiplication, not a recursive call. (n*factR(...)).

There are ways of transforming recursive calls that are not properly tail recursive to improve performance and to avoid over-exercising the stack. I am not entirely certain if the compiler(s) will do this transformation automatically.

'Invisigoth' on Thu, 12 Apr 2007 20:53:27 GMT, sez:

or you could make it TR by doing this:

fact(n) = fact_aux(1,n)

fact_aux(m, n) = if n == 0 then return m
else fact_aux(m*n, n-1)

you can probably convert any recursive function to be TR

'hellfeuer' on Mon, 25 Jun 2007 16:28:58 GMT, sez:

re: f#

it was not really the "incubation ground" for the functional pieces to add to the .net framework...
its merely a port of the OCaml programming language to the .net framework
SML.net is similair, and meant for the SML/NJ language (which is very similair to Ocaml)
i'm

'hellfeuer' on Mon, 25 Jun 2007 16:29:29 GMT, sez:

whooops.. i dunno how that "i'm" got ther..

name


website (optional)


enter the word:
 

comment (HTML not allowed)

All viewpoints welcome. But the right to delete any post for any reason is reserved. Don't make me do it. Comments may be republished, emailed to your loved ones or printed and used as toilet paper. Who reads this legal bit anyhow?

TimeSnapper_{Know thyself!}

TimeSnapper is a life analysis system that stores and plays-back your computer use. It makes timesheet recording a breeze, helps you recover lost work and shows you how to sharpen your act.

TimeSnapper won last year's Developer Competition at Larkware.com, and is used by over 10,000 people.