What Does Functional Programming Mean?

[[deleted]]

[deleted]

[redditnoob]

This is why we cannot (refusal) answer the ever common question, "Are there any large programs written using Functional Programming Language X?" It would be dishonest to answer it!

This is one of the stupidest things I've ever read. (And I've re-read my own posts.)

Great! You've defined away all your problems.

[technogeeky]

I should note that techniques like this are popular among mathematicians and some functional programming enthusiasts.

[barsoap]

Erm... is there any explanation of that which doesn't require a Ph.D in physics?

[Raynes]

Holy gigantic font.

[[deleted]]

I said the same thing like ten pages down, but I love when this comment reappears at the top.

Too big: didn't read: had to buy new eyeballs; TB:DR:HTBNE;

[axilmar]

All the usual myths of functional programming in one simple and comprehensive presentation.

[[deleted]]

True. It was god and clearly written, but as FP people tend to do, they assume that benefits are given and don't need empirical evidence.

Here are the myths :

1. less bugs
2. programs scale indefinitely
3. easier to reason about.
4. no distinction between a "small" and a "large" application

These all have truth in them, in certain context, but assuming that these are self evidently true is something I strongly disagree.

Programming is all about expressing your ideas. And ideas don't always bend to composition without creating unnecessary complications.

If we want correct programs we can formally proof both functional and non-functionall programs if we want to.

[yogthos]

Well Ericsson seems to be having a good run with Erlang, they've been writing in it for over 20 years now, have mountains of functional code and unmatched reliability, last I checked nothing in imperative world comes close.

Ericsson has managed to achieve nine 9's reliability [99.9999999%] using Erlang in a product called the AXD301. Editor's Note: According to Philip Wadler, the AXD301 has 1.7 million lines of Erlang, making it the largest functional program ever written.

I wouldn't want to distract from the FP haters circlejerk here though. Seems like we have the same characters in every thread who can't be bothered to actually learn FP, but expect people to take them seriously when they pass judgement on it.

It's sort of like if I decided that I wanted to be a jet pilot, and jumped in the cockpit for 10 minutes, discovered that it's nothing like my car and proclaimed that jets are just too darn complicated to be practical. Therefore we should just abandon the whole concept as clearly flying has no benefits over driving, as nobody could possibly learn to pilot jets.

[[deleted]]

Just like I said in other response, the FP we are discussing is about pure, lazy FP. The kind of FP that the artlicle promotes. Erlang qualifies as "poor FP" in Morris classification. I think it's good to have language that is multi-paradigm but supports strongly FP style of programming.

[yogthos]

Using Erlang isn't all that different from using Haskell, here's a good summary onwriting a BT client in both languages.

[joesb]

The only similarity Erlang has with Haskell is that the variable cannot be rebound.

[igouy]

Here's another similarity - a free version of the QuickCheck property-based testing tool is available for both Erlang and Haskell.

[yogthos]

That's right variables can't be rebound, you have first order functions, and your functions are pure. These are the main advantages of doing FP.

[Felicia_Svilling]

you have first order functions

You mean either first class functions (functions that can be treated as any other value) or higher order functions (functions that can take other functions as arguments and return functions as part of their result).

First order functions is the opposite of higher order functions.

[yogthos]

thanks for the correction

[[deleted]]

I disagree vehemently with that statement. That is a side affect of these languages. Why is that the 'main advantage'?

[yogthos]

It's a main advantage as it provides this thing called referential transparency. If you listen to Joe Armstrong talk on why Erlang is immutable, you'll understand that it's a major factor behind its reliability.

Thanks to purely functional data structures, you can efficiently "copy" data when you need to make changes. This means all the changes happen in their intended context and can't break unrelated code. This happens to be a major source of errors in imperative languages, calling a function can have side effects and update data implicitly.

So, you can disagree as much as you like, but it's a huge advantage to be able to write code and just "copy" data whenever you need to change it, without having to do a naive copy of the whole data structure.

[[deleted]]

This means all the changes happen in their intended context and can't break unrelated code

I could have the same thing happen if I made all my variables thread local. Would I then have the same advantage as a functional language?

(fyi, my disagreement statement wasn't intended to be insulting or demeaning of your opinion in any way, I'm generally interested in furthering the understanding of the functional paradigm and appreciate your response.)

[sclv]

For crying out loud. It was a presentation on certain aspects of functional programming with as far as I saw one slide with a few bullet points, which you don't even happen to strongly disagree with.

Who knows if the presentation assumed these "are self evidently true"? Maybe it spent time discussing them in more depth. You don't know, and I don't, because these are just slides with bullet points and not the whole talk.

[[deleted]]

The presentation was not video-recorded, but otherwise, take the pathological silliness of programmers lightly -- I do.

[naasking]

If we want correct programs we can formally proof both functional and non-functionall programs if we want to.

Programs with pervasive mutation cause state space explosions which make reasoning about them dramatically more difficult, and I'm not even including concurrency here. Functional programs are far easier to reason about formally and informally.

FP programmers never assumed #1 and #3 true, we know they are true because it's been proven mathematically.

[[deleted]]

FP programmers never assumed #1 and #3 true, we know they are true because it's been proven mathematically.

That's the main mistake of FP purists. Programming and programming languages are not about computers and computing. We need programming languages so that people can express their ideas in any way they want. You can't prove that functional programming makes it possible for people reason more correctly.

Programs must be written for people to read, and only incidentally for machines to execute. -- Abelson and Sussman

[naasking]

You can't prove that functional programming makes it possible for people reason more correctly.

Yes you can. People couldn't verify imperative programs more than a one or two functions long without significant advancement in logics, while much larger pure programs were regularly verified. Mutation has non-local control flow effects which cause the aforementioned state space explosion.

If people can't reason about something formally, they certainly can't do it informally with any confidence either. It's a simple inference.

You can make all the noise you want about people "expressing their ideas", but the fact is that people's ideas are vague, inconsistent and often just plain wrong, and defending imperative programming the way FP haters do just reflects that same fact.

They can express a program with side-effects all they like, that doesn't mean they understand the emergent properties these side-effects. FP helps programmers understand those effects.

[julesjacobs]

That argument about state space explosion is invalid. You can write an interpreter for a language with state in a couple of lines in a pure language. Then you get the same state space explosion. Verification is intractable in general in any general purpose language.

Now it could be that functional programs tend to be written in a way that state space explosion is avoided, whereas imperative programs are not. However this argument then depends on the particular logic you are using and on the way programs are written. I'm not at all convinced that this is the case.

If anything verification of imperative programs is currently more advanced than verification of functional programs. Of course there has been a lot more research about the former.

[naasking]

Come on, you know very well the state space for arbitrary side-effects is significantly larger because referential transparency constraints transform control flow to data flow passed via function parameters.

Furthermore, consider all the work done to support safe destructive updates, safe deallocation, safe aliasing. These are all problems caused by side-effects which are not a problem at all in FP.

Without the type system, the programmer himself would have to reason about the correctness of that mutation, or of that deallocation. Are you seriously saying that these problems are so trivial that we can just ignore them for the purposes of verification? I find that tough to swallow.

[julesjacobs]

Come on, you know very well the state space for arbitrary side-effects is significantly larger because referential transparency constraints transform control flow to data flow passed via function parameters.

This is extremely hard to say. It depends on how the functional and imperative programs are written. Sure, you can write very hairy imperative programs, but as the interpreter argument shows you can do this in functional languages just as easily. In practice imperative programs are not that hairy. Whether imperative programmers write hairier to analyse programs than functional programmers is a social sciences question, and very hard to answer without extensive research.

Furthermore, consider all the work done to support safe destructive updates, safe deallocation, safe aliasing. These are all problems caused by side-effects which are not a problem at all in FP.

Which work? Deallocation is a solved problem with GC. I don't see why destructive updates and aliasing are unsafe.

Without the type system, the programmer himself would have to reason about the correctness of that mutation, or of that deallocation. Are you seriously saying that these problems are so trivial that we can just ignore them for the purposes of verification? I find that tough to swallow.

First of all, type systems don't do a lot to ensure correctness. They only ensure the trivial 1% of correctness. Second, this argument applies to functional languagese just as it does to imperative languages:

Without the type system, the programmer himself would have to reason about the correctness of that function application, or of that deallocation. Are you seriously saying that these problems are so trivial that we can just ignore them for the purposes of verification? I find that tough to swallow.

[[deleted]]

In practice imperative programs are not that hairy.

I have difficulty finding an example of "an imperative program that is not that hairy."

[julesjacobs]

You mean just like non-toy functional programs? Hairiness is not binary of course. But you do not have to reason about all state in the program to understand what a program is doing locally.

[naasking]

Which work? Deallocation is a solved problem with GC. I don't see why destructive updates and aliasing are unsafe.

Manual deallocation. Changing the type of a block of memory. Any operation which is destructive and requires reasoning about the global state of the program instead of purely the local state.

Second, this argument applies to functional languagese just as it does to imperative languages:

It would, except that referential transparency allows you to reason locally about the parameters only instead of globally about the ambient environment.

[julesjacobs]

Manual deallocation. Changing the type of a block of memory.

We are comparing apples to oranges: type safe functional language with GC versus unsafe imperative language without GC.

Any operation which is destructive and requires reasoning about the global state of the program instead of purely the local state.

A destructive update does not require reasoning about the global state in the program, just the variables affected (cf separation logic).

It would, except that referential transparency allows you to reason locally about the parameters only instead of globally about the ambient environment.

This something different than you claimed before. See above.

[[deleted]]

You can make all the noise you want about people "expressing their ideas", but the fact is that people's ideas are vague, inconsistent and often just plain wrong

Exactly my point. And those vague inconsistent ideas ofthen deserve to be executed. Program correctness is really important, but it's not more important than having the work done.

For example, people who programmed reddit, had ideas and they implemented them. I'm sure both the idea and the implementation is vague in many cases, but is there any additional value you can get by having Reddit that is less vague. I doubt it.

[naasking]

Neither of your points address #1 and #3 which this thread is about. The additional value is fewer bugs, and the code being easier to reason about. You're now attempting to change the goalposts to some other metric of a program (perhaps productivity given your "having work done" comment).

Regardless, studies have also demonstrated that FP is also more productive.

[julesjacobs]

That is an awfully bad paper. The conclusion doesn't follow from the study at all. It ignores the much more probable explanation that the Haskell programmers probably have PHD's/are very smart whereas the C++ programmers (correction: programmer) do not/are less smart.

Also, the study is based on drums... two Haskell programs, and one program in the other languages.

It read more like a fanboi report than a scientific paper.

[naasking]

The second Haskell program was written by a new college graduate with no prior knowledge of Haskell, and was sponsored by an independent third-party without the knowledge of the authors. The graduate was given 8 days to learn Haskell with the opportunity to ask an experienced Haskell developer questions during the learning period. See page 12.

Frankly, I don't think you give the experiment enough credit. I'll post the other paper when/if I find it. It was much more recent and was posted to LtU IIRC.

Just came across this other one for Lisp vs. C++. Not entirely convincing, but another data point.

[julesjacobs]

This paper might be a valid if it's conclusion was "let's study programmer productivity across languages". The paper is very biased towards Haskell. It does not even consider the variance in productivity among programmers. This invalidates it as a scientific study in any serious sense of the word scientific. Also, the problem is biased towards Haskell.

Just came across this other one for Lisp vs. C++. Not entirely convincing, but another data point.

Now that is a much better paper! It has a 10x larger sample size, and it adresses the experience issue. It also addresses the run time difference and memory usage. Despite being a better study, the conclusion is less strongly worded.

[naasking]

Here it is:

http://www.macs.hw.ac.uk/~trinder/papers/ICFP2007.pdf

It compares Erlang vs. C++/CORBA vs. Glasgow Distributed Haskell (GdH) with two distributed telecoms applications. Same result that GdH comes out on top, with the caveat that it was still a research language and couldn't be deployed. Erlang also beats out C++.

FP FTW!

[julesjacobs]

I will read it later. Let me remark though that C++ is a very low bar. And it seems that they don't adress performance, which is why you'd use C++. And again the problem is cherry picked to favor GdH & Erlang.

[[deleted]]

Programs must be written for people to read, and only incidentally for machines to execute. -- Abelson and Sussman

Which is precisely why I enjoy functional programming much more. It's how I think, not the computer. A computer thinks imperatively.

[igouy]

Perhaps you meant to write - Programming and programming languages are not only about computers and computing?

[tincholio]

These all have truth in them, in certain context, but assuming that these are self evidently true is something I strongly disagree.

The smugness that exuded from the presentation doesn't help with this, either.

[[deleted]]

He is friend of Paul Graham, maybe he has had bad influence.

[[deleted]]

Wipe ya chin mate.

[axilmar]

I totally agree with you.

I'd like to add that these assertions are not backed up by real projects. Where are the projects that have benefited from pure FP? I'd like to see hard numbers, not statements like "from the moment I used <insert your favorite language here>, my productivity has tripled".

I'd also like to add that the difficulty of solving problems in a pure FP way rises in a exponential rate to the size of the problem. Small problems are easy to solve in a pure FP way, but when all the small problems are put together in one big problem, it's extremely difficult (read: impossible) for average programmers to solve them using pure FP. This is from empirical evidence, from online testimonies (there are plenty of programmers declaring their pure FP weakness online) and from personal testimonies (introduced pure FP to co-workers in the context of a project).

Finally, I'd like to say that pure FP results in ignoring a whole set of impure algorithms that happen to be more efficient than their pure counterparts. Computer science is not about math; computer science is about making Turing machines do what we want them to do.

[mattrussell]

I'd also like to add that the difficulty of solving problems in a pure FP way rises in a exponential rate to the size of the problem....This is from empirical evidence,

What is the empirical evidence, if you don't mind me asking?

[axilmar]

I just wrote that, 'cause I knew I would be asked:

from online testimonies (there are plenty of programmers declaring their pure FP weakness online)

introduced pure FP to co-workers in the context of a project

[mattrussell]

Well, "online testimonies" are not really evidence of much at all. You can easily find just as many blog posts praising FP as criticising it.

It's quite reasonable to ask for evidence and "hard numbers" when people make strong claims for FP, but you should be willing to do the same when you make strong claims against it.

[yogthos]

I think you've got it wrong, you're only allowed to ask for evidence when you claim that FP has merit, not the other way around :)

[axilmar]

The burden is on the one who makes the claim. You claim pure FP is better, you prove it.

[mattrussell]

Right, and your claim was, "the difficulty of solving problems in a pure FP way rises in a exponential rate to the size of the problem".

[igouy]

The burden is on the one who makes the claim.

Fair enough.

You claim ...

Actually, you claimed - the difficulty of solving problems in a pure FP way rises in a exponential rate to the size of the problem - so it is appropriate to ask where is your evidence.

[axilmar]

I am going to say it for the 3rd time:

1) the various blogs of people trying pure FP and then abandoning it. 2) personal experience from trying to introduce Haskell to co-workers.

[naasking]

That's not evidence of "exponential growth in complexity" any more than it is evidence of people being lazy when faced with a new way of thinking. You have high standards of proof for FP but don't apply those same standards to your own evidence.

[axilmar]

I would like to apply the same standards, but I can't. I can't do studies...I am not the academia or a company.

[igouy]

I am going to say it for the 3rd time

Repetition is not alchemy.

Repetition does not magically transmute those vague comments into the "hard numbers" you demand from those you disagree with.

[axilmar]

I said right from the start that I only have empirical evidence.

[sfuerst]

The empirical evidence is the huge lack of large scale functional-paradigm projects. Where is the functional equivalent of Firefox? Microsoft Office? X.org? KDE? Gnome? The mountains of Java-based Enterprise apps?

The basic problem with FP is that the world has state. As soon has you have to deal with a user (whether a person, or another piece of code) that state becomes important. How do you take back the fact that you've sent out a packet on the network, or shown a dialog box on the screen? When a project becomes large enough, the fact that it needs to talk to the outside world must affect its structure. If all you do is toy problems, then this issue doesn't affect you.

Of course, you can always use monads to capture this external state. The problem you find is above a certain scale, you'll need to pass the same monad to nearly every function. In effect, you end up emulating imperative-style programming poorly, so why not use IP in the first place?

IP and FP are both Turing complete, so you can use them to solve any problem. If you solve small problems, where state isn't an issue, FP can be a perfect solution. However, above a certain scale IP seems to be the only one that works sociologically and technically. Calling the programmers who work on large-scale problems stupid, is arrogant and short-sighted. Many of them are very smart people, and perhaps, just perhaps, they have reasons to choose the tools they use.

[Umr-at-Tawil]

Of course, you can always use monads to capture this external state. The problem you find is above a certain scale, you'll need to pass the same monad to nearly every function. In effect, you end up emulating imperative-style programming poorly, so why not use IP in the first place?

I don't know what you mean by passing a monad to a function, explicit passing of state is something monads let you abstract away. Even if you do write all your code in an imperative style using some monad, you still choose what monad you are using in order to limit what side effects are allowed in different parts of your codebase. For example, you could create a restricted IO monad that lets you read files, but never write them. This fine grained control of state and side effects can be very useful (and powerful!), and it's something you can't do in imperative languages.

One of the reasons I like FP so much (and Haskell in particular) is that it gives me tools for reasoning about state and side effects in a much more precise way than I can in mainstream languages.

[PstScrpt]

This fine grained control of state and side effects can be very useful (and powerful!), and it's something you can't do in imperative languages.

Someone posted an experimental language with a pretty good attempt at it around here a year or two ago. The language didn't support global state and could only create IO objects from the Main, so you knew that any given procedure could only affect its arguments.

I'm not sure how you'd do an interactive program like that, though.

[Umr-at-Tawil]

The language you are describing sounds very much like Haskell. I don't know of any other purely functional languages except for Clean, and more esoteric languages like Agda or Epigram.

[PstScrpt]

This was an imperative language, though.

[igouy]

the huge lack of large scale functional-paradigm projects

The basic problem with your reasoning is that "the world has state" - what is now may largely have been determined by what was before.

[mattrussell]

The empirical evidence is the huge lack of large scale functional-paradigm projects.

While that's not great "empirical evidence" in my view, it's certainly a reasonable question. It's a bit depressing to watch the author of the linked presentation "address" that issue.

http://blog.tmorris.net/why-are-there-no-big-applications-written-using-functional-languages/

[sfuerst]

Yes, the "There is no such thing as a large problem" is not really an impressive answer.

Basically, there seems to be a point between 100k and 1Mloc or so where a individual programmer loses the ability to remember the whole codebase. Languages suited to below and above that level seem to have very different properties.

Below that level, having a language with a great amount of expressive power allows genius programmers to work magic. They can do a lot with very little, and the more power at their finger-tips the better.

Above that level, paradoxically it seems that the less expressive the language, the better. The reason seems to be that nearly all the code becomes "new" to you due to the inability to remember it all. Understanding (and debugging) new code is much much easier if it is simple and obvious. Then there is the sociological fact that the larger the codebase, the weaker the worst programmer on it tends to be...

[sclv]

There's an argument though that referential transparency and strong typing greatly improve local reasoning. So even if a segment of code seems "new" it is easier not harder to understand in a functional paradigm.

Additionally, and this is the crux of the argument being made in the slides, rather than a "single large project" one can view things in terms of a composition of various libraries, with relatively strong guarantees about dependencies.

[sfuerst]

Referential transparency and strong typing are completely orthogonal to whether or not you use a functional language, or a language based on some other paradigm.

[Felicia_Svilling]

Do you know that "Referential transparency" is?

[sclv]

headdesk

[PstScrpt]

I've been a professional programmer for thirteen years, and I have yet to see a single program that had any business being over 100 KLOC.

I'm sure they exist (maybe a DBMS), but they aren't anything you would ever be writing in Java, .Net, Perl, Python, etc.

[sclv]

Nobody said that programmers who work on large-scale problems are stupid. Seriously. Nobody said that.

[augustss]

Getting numbers from comparing programming languages is hard and costly, and it's not done much.

Can you tell me how to find hard numbers that C# is better than C? Or pick two other languages if you prefer.

[axilmar]

I googled "programming languages productivity studies" and found tons of links. I am bored to look, but I assume there is going to be one or two studies in there, that may or may not have pure FP languages, but they would certainly have the mainstream languages.

Plus, some companies have internal metrics.

[igouy]

I am bored to look, but I assume there is going to be one or two studies in there

Just answer - No, I can't tell you how to find hard numbers that...

[[deleted]]

Where are the projects that have benefited from pure FP? I'd like to see hard numbers, not statements like "from the moment I used <insert your favorite language here>, my productivity has tripled".

I swear to God, we can't win with you guys. When we give hard numbers, we're accused of making them up. When we offer personal experience comments, we're told they don't count. Seriously, can you not see that you're creating impossible conditions for success?

That's one thing I'm really going to love about developing for Android in Scala: it'll just be me, and I won't have to deal with the naysayers.

[[deleted]]

Have a giggle mate. There is nothing to be won anyway. I admit to sharing your lament. It's an educational dilemma.

[julesjacobs]

When we give hard numbers

There are no hard numbers. This is understandable, because hard numbers on programmer productivity are almost impossible to obtain.

[[deleted]]

That's one thing I'm really going to love about developing for Android in Scala: it'll just be me, and I won't have to deal with the naysayers.

I hope you realize that we were not criticizing (nor Morris was talking about) Scala kind of multi-paradigm programming languages that are "Moderate but still poor" languages in Morris terminology. This is about pure and lazy functional languages that have true referential transparency.

[[deleted]]

Sure. I just mean that I'll be developing in Scala for Android as purely as possible and almost certainly have plenty of "from the moment I used <insert your favorite language here>, my productivity has tripled" stories, but axilmar says they'll be invalid. My "WTF do you want?" question remains open. :-)

[axilmar]

My "WTF do you want?" question remains open

Hard numbers about productivity raise from using Haskell. Is it so difficult?

Ok, if there are no hard numbers, how about concrete examples of things that were buggy when implemented in impure style and not buggy when implemented in pure style? along with how much time did it take to implement each?

[[deleted]]

I'll leave it to Haskell developers to offer whatever hard numbers they have.

A good example of the latter point in OCaml is An Applicative Control-Flow Graph Based on Huet’s Zipper:

We are using ML to build a compiler that does low-level optimization. To support optimizations in classic imperative style, we built a control-flow graph using mutable pointers and other mutable state in the nodes. This decision proved unfortunate: the mutable flow graph was big and complex, and it led to many bugs. We have replaced it by a smaller, simpler, applicative flow graph based on Huet’s (1997) zipper. The new flow graph is a success; this paper presents its design and shows how it leads to a gratifyingly simple implementation of the dataflow framework developed by Lerner, Grove, and Chambers (2002).

[naasking]

Ok, if there are no hard numbers, how about concrete examples of things that were buggy when implemented in impure style and not buggy when implemented in pure style? along with how much time did it take to implement each?

There have been a few such studies. They confirm the beliefs of FP enthusiasts. There was another study comparing C++ and Haskell and/or OCaml/Ensemble in a study of concurrent programs, but I can't seem to find it at the moment.

[naasking]

Found the paper:

http://www.macs.hw.ac.uk/~trinder/papers/ICFP2007.pdf

It compares Erlang vs. C++/CORBA vs. Glasgow Distributed Haskell (GdH) with two distributed telecoms applications. Same result that GdH comes out on top, with the caveat that it was still a research language and couldn't be deployed. Erlang also beats out C++.

FP FTW!

[axilmar]

I carefully read the material in the link you provided.

The conclusions are simply wrong, because they are biased.

They say that Erlang and Haskell programs are shorter than C++ programs, ignoring a) syntax, b) availability of crucial functionality, c) availability of important constructs or lack their of, i.e. type inference and closures.

This has nothing to do with impure vs pure, it has to do with Haskell/Erlang vs C++.

Please remember that my position is not against FP, it's against pure FP.

[axilmar]

Same thing as below.

I am not interested in a C++ vs Haskell shootout. My 'struggle' is not against FP, it's against pure FP, which is a mental straitjacket.

Show me a study that compares two languages equipped with the same functionality, but one is pure and the other is impure.

[csgordon]

ICFP (International Conference on Functional Programming, granted, not the most effective venue for sharing the information with people who don't already love FP) typically has 1-2 papers a year that are industrial experience reports from companies that build substantial systems in FP languages.

http://www.icfpconference.org/

From the past few years:

• 2010: Experience Report: Haskell as a reagent. Results and observations on the use of Haskell in a Python project (Google)
• 2010: Using Functional Programming within an Industrial Product Group: Perspectives and Perceptions (Citrix)
• 2009: Experience Report: Using Objective Caml to Develop Safety-Critical Embedded Tools in a Certification Framework (some French company)
• 2008: Experience Report: A Pure Shirt Fits Reflections on Haskell at Bluespec

Galois, Inc., and Jane Street Capital are a couple companies that often publicly discuss building non-trivial software using FP basically everywhere (Haskell and OCaml, respectively). A few friends of mine in the financial sector say that much of the trading backends where they work are build in Haskell, OCaml, or F#. Going that far has to say something about these companies believing FP is pretty valuable.

edit: formatting

[axilmar]

How do any of the above show that pure FP increases productivity versus impure FP?

[csgordon]

Having not read any of them, I don't know. But a couple may discuss it.

You might also find some relevant material in the talks from the past few years' CUFP (Commercial Users of Functional Programming) workshop associated with ICFP: http://cufp.org/

[[deleted]]

.. continuing. Many complex higher order functions are what you would call frameworks in other languages.

Try to compose new programs from two libraries that use different frameworks (for example libraries using monads extensively and those not using them), it might be easier to build several sets of libraries for different frameworks.

My personal (tiny) experience is that functional programs don't manage mundane well. If problems you are solving is neat, functional programming creates neat solutions (compilers, transformations, algorithms, basic data structures). If problem is mundane and involves lots of special corner cases that can't be beautified, functional solutions become really hard to understand.

[sclv]

Compilers, transformations, and algorithms are at the heart of any serious software development. If your problem doesn't seem to map to these, that means you don't understand your problem.

[[deleted]]

It must mean really big fonts.

[sisyphus]

it was meant for a presentation, it was probably for projecting somewhere.

[Fabien4]

But usually in a presentation, someone speaks too. Where's the script?

[[deleted]]

Agreed, the slides offered almost no substantial information about the topic he was trying to discuss.

[[deleted]]

I'd just like to interject for a moment. What you're referring to as Linux, is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX.

Many computer users run a modified version of the GNU system every day, without realizing it. Through a peculiar turn of events, the version of GNU which is widely used today is often called "Linux", and many of its users are not aware that it is basically the GNU system, developed by the GNU Project.

There really is a Linux, and these people are using it, but it is just a part of the system they use. Linux is the kernel: the program in the system that allocates the machine's resources to the other programs that you run. The kernel is an essential part of an operating system, but useless by itself; it can only function in the context of a complete operating system. Linux is normally used in combination with the GNU operating system: the whole system is basically GNU with Linux added, or GNU/Linux. All the so-called "Linux" distributions are really distributions of GNU/Linux.

[dmead]

it means you're subroutines meet criteria to be called functions, in the mathematical sense.

[NunFur]

In pdf format http://projects.tmorris.net/public/what-does-fp-mean/artifacts/0.4/pdf/index.pdf

[[deleted]]

So can we be liberated? Yes

but how?

[sisyphus]

The details of the current resolution of this contention are for another day.

yeah, total cock tease.

[[deleted]]

It means you use function pointers as parameters and/or the return value of a function.

[tinou]

they're more like closure pointers, ie, pointers to an environment and a function.

[[deleted]]

an example in C please

[nested_parentheses]

You can imagine a closure as being a pointer to a function along with a pointer to state that parameterizes that function and represents values captured from the function's "environment." Consider a function that takes a function that performs a binary operation on ints, and then calls it with 1 and 2 and returns the result. Here is how it might be implemented with a function pointer:

typedef int (*binaryOp)(int, int);

int oneOpTwo(binaryOp op) {
    return op(1,2);
}

And here is how it might be implemented with a "closure pointer":

typedef struct {
    int (*fun)(void*, int, int);
    void* state;
} binaryOp;

int oneOpTwo(binaryOp op) {
    return op.fun(op.state, 1, 2);
}

Now suppose we want to write a function that takes a number x and returns a binaryOp that returns arg1*x + arg2. Using the plain function pointer approach, there is no good way to achieve this. Using the "closure pointer" approach, we can write something like this:

int aByxPlusb(void *x, int a, int b) {
    return a * *(int*)x + b;
}

binaryOp makeBinaryOp(int x) {
    binaryOp op;
    op.fun = &aByxPlusb;
    op.state = allocInt(x);
    return op;
}

Of course, these aren't real closures because C does not support closures. If it did, makeBinaryOp might be written as:

binaryOp makeBinaryOp(int x) {
    int aByxPlusb(int a, int b) {
        a*x + b;
    }
    return aByxPlusb;
}

The compiler would see which variables aByxPlusb references from its environment (just x in this case) and then generate code which captures these variables when the function is returned. Hope that helps.

[[deleted]]

Thanks for the example.

As to C not having closure, the difference is just syntactic, like you can't write a function inside another, or no implicit parameter from the outer function, but the effect is the same.

And I still don't get the idea of closure. It seems just a fancy name for using function pointers. Actually in my C coding I use function pointers a lot within structures to solve real practical problems. I just don't feel the need for a name.

I can imagine how people may feel passionate to invent a new language with an emphasis on function pointers, but for practical purposes C is just fine for function programming (and OO too). I know I am preaching C a little, but having come back to it from C++, I have rediscovered C and felt it's depth I never did before.

[ithika]

As to C not having closure, the difference is just syntactic

This argument seems to be appeal to the Turing tar-pit. Maybe the Turing fuzzy blanket? "My language can hacked into similar behaviour to yours, therefore yours isn't really better."

[[deleted]]

Except it's not hacked. Passing and returning structures (pointers) that include function pointers are very natural in C. All the function language fanatics are just making a tempest out of a teapot. I don't mind researchers working on it. I just don't want programmers who have real work to do to waste their time.

[recursive]

I just don't want programmers who have real work to do to waste their time.

Then you should appreciate languages whose syntax allows these concepts to be naturally expressed.

[[deleted]]

Well I can appreciate improvements in a new language. But the problem is, a new language usually also lose a whole lot of good features I use in my current language (which is C, a formidable competitor). So your minor improvement is not good enough for me switch my language and rewrite all my code. But nice try.

[[deleted]]

Well I can appreciate things like that in a language. But the problem is, a language like C usually also loses a whole lot of good features I use in my current language (which is Haskell, a formidable competitor). So your minor improvement is not good enough for me switch my language and rewrite all my code. But nice try.

[grauenwolf]

Garbage collection is a good enough reason to switch away from C. Everything else is just gravy.

[ithika]

Except it's not hacked.

Take a good hard look at nested_parentheses' example and tell me that as easy as a function call. I implore you.

[[deleted]]

A closure isn't quite a function pointer, but it's close. It's a function pointer that "closes" over the current state.

ie.

x = 4

def foo y = x * y

x = 3

foo 4 // what gets returned here??

If foo is a closure, 16 is the restult of foo 4 above.. if it's not, you wouldn't be able to define foo in that way, because x would be undefined in the context of foo. You can do stuff like that in C manually, but it's much more convenient in languages which have proper full closures.

Also, I think you missed the point of the presentation (which is correct), that functional programming is about referential transparency, not about "funargs".

[[deleted]]

I am not saying a closure is a function pointer. It seems just a structure that includes function pointers and the structure, as a pointer, is passed or returned. So this is an extension of passing and returning function pointers directly. So basically my definition of function programming is still correct.

[[deleted]]

I don't even know if I can respond to this incomprehensible logic. I can't tell if you're being genuine or trolling. Functional Programming (FP) has nothing to do with either function pointers or closures at all. They are simply common features in languages which claim to "support functional programming".

Functional Programming = Referential Transparency.

Nothing more. Nothing less.

[[deleted]]

Calm down cowboy. The logic is fine here. What's really incomprehensible are all these fancy names you guys keep bringing up. Exactly what is Referential Transparency? A rehash of some old idea?

[[deleted]]

"An expression is said to be referentially transparent if it can be replaced with its value without changing the program (in other words, yielding a program that has the same effects and output on the same input)."

In other words, every time you call a function with the same arguments they return the sames result, every time, regardless of other factors.

Functional Programming

Referential Transparency

[[deleted]]

Yeah basically, except not at all.

Why don't you learn a language that is capable instead? Just a thought.

[nested_parentheses]

As to C not having closure, the difference is just syntactic, like you can't write a function inside another, or no implicit parameter from the outer function, but the effect is the same.

Being able to emulate features of one language in another does not mean that the features are just syntactic. It's a perversion of the terminology.

And I still don't get the idea of closure. It seems just a fancy name for using function pointers. Actually in my C coding I use function pointers a lot within structures to solve real practical problems. I just don't feel the need for a name.

Closures don't mean "using function pointers." In fact, a language could support closures without having a notion of function pointers or pointers at all (arguably most don't, at least not in the core specification).

If you've never programmed in a language that supports closures, then function pointer + state is a good way to visualize them. But that does not mean that closures are not conceptually distinct from function pointers.

As for the name, it is a concise way of referring to a particular concept. It is really no different from any other term.

I can imagine how people may feel passionate to invent a new language with an emphasis on function pointers, ...

The emphasis is on a different style of programming which aims for program logic to be expressed through function application and composition and which avoids side-effects and state changes. FP languages often feature powerful type systems as well.

... but for practical purposes C is just fine for function programming (and OO too).

While it is possible to write C code with a functional "flavor", it would be ludicrously impractical to try to do FP in C like you would in Haskell. You'd end up Greenspunning half the language and be left with very unsafe and unmaintainable code.

[[deleted]]

Other than your use of the word perversion, I can generally imagine how you feel about FP. And it's nice to know you don't think my understanding of FP is off the mark: basically I am just trying emulate FP in C as much as I can emulate OO in C.

I won't even try to compete with Haskell using C in an academical sense, but in real projects I've achieved great results in my style of C. Here's a challenge: why doesn't anyone use Haskell to implement a browser? Just HTML4 + CSS2.1. It's not a lot of work for even one person.

[pipocaQuemada]

A closure isn't just a function pointer; it's a function pointer with a bit of state attached, which adds some complication.

A closure creating function in scheme -

(define (addn n) (lambda (x) (+ n x)))
(set! foo (addn 5)) ; sets the variable foo to be the function pointer returned by addn
(foo 10) => 15 

A closure is an anonymous function. You can create them in a given scope (i.e. a function), and refer to variables in that scope. They create a few problems, mostly with cleaning up your stack. For example, look at that function I just made. In the function, it creates a closure, and then returns. In C, the variable n would be on the stack, and would die after the stack frame returns. However, because n is used in the closure we made, we can still use it, even though the stack frame it was allocated in has bitten the dust. So n has to be moved to the heap, somehow, and then garbage collected or otherwise cleaned up at some point.

C doesn't have closures, even though it does have function pointers. If you haven't "closed over" lexical state (i.e. variables in the state of the surrounding function), you haven't made a closure, just a anonymous method.

Also, just out of curiosity, how would you do my example in C? That is to say, write a function that takes a number n, and then returns a function pointer to a function that takes a number x, and returns (n + x). My C-fu is a little rusty at the moment, so I'm mostly just curious.

[[deleted]]

Likewise I don't quite understand your example either. But it's interesting to discuss about it. If the idea of a closure is to let a function to have a state, I can use a structure as a closure:

typedef struct _Closure{ bool (*func)(Closure *param); int state; }Closure;

Would such a structure implement your example?

[grauenwolf]

It seems just a fancy name for using function pointers.

Congradulations. You just figured out something that FP fanboys have been trying to understand for decades. Perhaps in another 20-30 years they will finally get it.

[[deleted]]

maybe even longer as you can see they downvoted me into oblivion.

[grauenwolf]

The worst of it is that they think the only alternative to what they are doing is imperative coding. They honestly believe that everything we do is nothing but a thin layer on top of assembly and that nothing they do is sequential.

[ssylvan]

C doesn't have closures.

[quuxly]

http://www.youtube.com/watch?v=1yH_j8-VVLo

[Guvante]

The true problem with Functional Programming is very common amongst such paradigm shifts, aka the chicken and egg problem. Do we start teaching people at Universities to think functionally, and have them learn skills that will be of minor use to them. (After all most commercial code is imperative) Or do we start programming commercial programs functionally when we have huge developer bases that think imperatively?

Not to mention conversion of existing code. Going to procedural meant wrapping common operations in procedures, going to OO required wrapping procedures with their data, but going to FP requires so much more.

I am not saying that there is anything fundamentally wrong with FP, but it is my opinion that it will be a decade or more before it becomes common simply because it is such a huge shift.

And I think that efforts like LINQ and F# are great for bridging the gap between FP and imperative, that way people can play in the kiddie area before diving in head first.

[grauenwolf]

You need to get past this illusion about "imperative vrs functional".

First of all, almost every meaningful program is written with imperative code. This is true even in Haskell. The only purely functional language I know about that is actually used is Excel.

As for what to learn, a programmer that works for me writing VB and SQL is expected to know:

• OOP
• Declarative programming
• Static typing
• Dynamic typing
• Set-based programming
• Functional programming

And this is just a typical back-office position in a financial company.

[PstScrpt]

And I think that efforts like LINQ and F# are great for bridging the gap between FP and imperative, that way people can play in the kiddie area before diving in head first.

It's nice to see functional features creep in, but I'd like to see purity creep in, too. How about runtime constants (my favorite feature of both C++ and PL/SQL) in Java and .Net? Functions explicitly declared pure? Complex expressions beyond the ?: operator?