Functional Programming Version

[danc2]

Hi all,

I am a MS student (soon to be a graduated one) who just finished a programming course that centered around functional programming (FP). My interest is somewhat piqued and my professor informed me that some are using FP in distributed computing projects.

I wondered if anyone had any thoughts on if FP could be faster than the current C implementation. I've read recursion is optimized more so than an imperative language such as C and the speed of parallel computation is also pretty great. No state, but there are "ways around that" my professor told me (perhaps moving things over a network?).

It may be a side project I attempt as I am interested in learning more about FP and like the work that GIMPS does.
Thanks!
Daniel

[paulunderwood]

Originally Posted by danc2

Hi all,

I am a MS student (soon to be a graduated one) who just finished a programming course that centered around functional programming (FP). My interest is somewhat piqued and my professor informed me that some are using FP in distributed computing projects.

I wondered if anyone had any thoughts on if FP could be faster than the current C implementation. I've read recursion is optimized more so than an imperative language such as C and the speed of parallel computation is also pretty great. No state, but there are "ways around that" my professor told me (perhaps moving things over a network?).

It may be a side project I attempt as I am interested in learning more about FP and like the work that GIMPS does.
Thanks!
Daniel

The meat of the coding is done in assembly which close to metal. C/C++ is used for non-critical loops etc. Having direct control over CPU registers is going to be much quicker than trying to address them with a FP language.

[CRGreathouse]

The idea is that a well-designed functional programming language could let you program in a functional style without a performance penalty compared to a close-to-the-metal language. It's not going to outperform them unless the other coder is doing something wrong.

[LaurV]

During our Uni we really loved Lisp, and we really did nice things in it (like some playing-gomoku "brain") unfortunately it wasn't much of an opportunity to use it after. For a while we coquetted with it during the time it was supported by AutoDesk (their AutoLisp actually was nice and quite powerful, we use it to write a program that designed our LCD modules for us in AutoCad, given the dimensions and some other characteristics, then it was piece of cake to retouch here and there, much better and a million times faster than starting the design from scratch). Then our company switched to SolidWorks, which we still don't know how to handle properly... (well, much better price, aggressive marketing, etc). (In)fortunately, we don't do much of mechanical design now, being busy writing firmware (blind C and ARM assembler)...

[danc2]

Cool, thanks for the quick replys all! I had heard about Prime95 being written in assembly, but was unsure about the rest (probably should have made that clear) and what, if any performance tuning could occur. Looks like whoever made this software are wizards already .

[CRGreathouse]

Originally Posted by danc2

Cool, thanks for the quick replys all! I had heard about Prime95 being written in assembly, but was unsure about the rest (probably should have made that clear) and what, if any performance tuning could occur. Looks like whoever made this software are wizards already .

They are true wizards. But FP has real advantages, especially in multicore programming: it makes it much easier to avoid mistakes that can be hard to avoid in other languages, because of their lack of state. So we're not knocking FP by any means, just pointing out that it's not a hammer for every nail.

[xilman]

Challenge for you: write a useful program in C which is also purely functional in the FP sense.

It can be done, and I've faced and passed this challenge in the past, but it's not entirely easy to do.

And I do not mean something as trivial as main(){printf("Hello world\n")}.

[LaurV]

is the "factorial" good enough and functional enough?

or "hanoi towers" something?

[xilman]

Originally Posted by LaurV

is the "factorial" good enough and functional enough?

or "hanoi towers" something?

Yes, if you don't think you are a good enough programmer to implement anything less trivial.

If you do think you are any good, try implementing this rather simple function, given here in imperative pseudocode.

INTEGER FUNCTION sum_func (INTEGER FUNCTION (INTEGER x) fun,
                           INTEGER from,
                           INTEGER step,
                           INTEGER to)
BEGIN
    INTEGER temp;
    INTEGER i;
    temp := 0;
    FOR i := from STEP step TO to DO temp := temp + fun (i) OD;
    RETURN temp;
END

Wrap a purely functional program round it to prove it works. fun can be hard-coded if you wish but from, step and to should be taken from user input.

[kriesel]

Originally Posted by CRGreathouse

They are true wizards. But FP has real advantages, especially in multicore programming: it makes it much easier to avoid mistakes that can be hard to avoid in other languages, because of their lack of state. So we're not knocking FP by any means, just pointing out that it's not a hammer for every nail.

not the right hammer for every fastener/fastening technique. Sometimes you need a gravity-compensated power screwdriver, sometimes a MIG welder or adhesive dispensing robot or fastener-free snap fit.

[Uncwilly]

Originally Posted by kriesel

not the right hammer for every fastener/fastening technique. Sometimes you need a gravity-compensated power screwdriver, sometimes a MIG welder or adhesive dispensing robot or fastener-free snap fit.

Friction stir welding is good for somethings. Also, as a side note: Oxy-acetylene torches don't cut scrap dirt plywood the way it does steel (someone I know had this one pulled on them.)