Talk:Functional programming

Phony contrived examples

It's unhelpful to the reader when concepts are introduced or compared using phony examples -- contrived code snippets that supposedly depict a particular style or concept, but in fact do not represent the way any programmer would actually work.

The following example is currently in the article:

# imperative style
target = [] # create empty list
for item in source_list: # iterate over each thing in source
   trans1 = G(item) # transform the item with the G() function
   trans2 = F(trans1) # second transform with the F() function
   target.append(trans2) # add transformed item to target

It is intended to illustrate "imperative" style by eliminating composition, and to contrast with "functional" examples that use it. However, this is a flat lie: imperative-style programmers use composition all the time, even in languages that are even less "functional" than Python, such as C.

Using contrived examples like this amounts to lying to our readers. Unless someone can come up with a really freakin' good justification for things like this, I'm going to remove them. --FOo (talk) 19:46, 25 November 2007 (UTC)

I don't understand this point at all. Of course imperative code that stores intermediate results is used all the time. I write such things on a daily basis (even though I "wrote the book" on FP in Python). There's nothing either wrong, nor even atypical, about the imperative example (other than perhaps being a little bit simpler than most "real life" code). This very simple case can, of course, be done as a listcomp, but if it had a dozen intermediate values, maybe a nested loop, some 'if' blocks, and so on, doing something a lot like this "loop over items, collect intermediate values" is exactly what most everyone does in an imperative style. LotLE×talk 21:25, 25 November 2007 (UTC)

What is it you would like better, anyway? To write "imperative" code that was "as FP as possible"?! Of course you can do that... but it would completely eliminate the point of contrasting coding styles. This isn't a game of coding golf, as an anon poster seems to want; nor is it a tutorial in "best Python practices" or whatever. If you are so overwhelmed by the presence of listcomps in Python, just write the same thing in Pascal instead (except that won't work, since it lacks first-class functions). LotLE×talk 21:36, 25 November 2007 (UTC)

The obvious way that a programmer who didn't use list comprehensions (for whatever reason) would do it is:

target = []
for item in source_list:
   target.append(F(G(item)))

I'm not objecting to having an example of imperative-style code. I'm objecting to having an example that erroneously implies that there exists any programming style that eschews composition. Treating composition as if it were a feature of "functional programming", which must be eschewed in order to create an imperative-style program, is simply lying to our readers. Composition is a normal feature of all sorts of programming languages that cannot even pretend to Python's level of functional-ness. --FOo (talk) 09:39, 26 November 2007 (UTC)

To put it another way: It's not that the example in the article says anything wrong about functional programming. Rather, it claims to be contrasting functional style with a different style, which it labels "imperative". The chief characteristic of that style is that every operation must be done as a separate command, with no composition or other combination of operations. However, this style is a fiction.

Sure, there are cases where people store intermediate results -- generally when those results are going to be used as well, or when they are the result of a long complicated expression. However, what the example here claims is that "imperative" is a style, and that style requires eschewing composition. This is a simply false claim. --FOo (talk) 09:46, 26 November 2007 (UTC)

I'm sorry, this argument looks more sophistical every time Fubar repeats it. Obviously no programming language eschews composition... well, maybe assembly, or some obscure research language. The point for an article on FP, is that pure-FP doesn't allow intermediate results to be stored in the manner that typical imperative code often does. The temporary-value style becomes more "natural" as examples get longer... but snippets in articles like this are, almost by definition, not fully fleshed out programs. The code given is enough to illustrate the point being made, without containing extraneous extras.

If you really want an example where composition, listcomps, etc. become less obvious to the "golfers" here, it only takes adding a line or two, e.g.:

# imperative style
intermed = [] # store intermediate results
target = [] # create empty list

for item in source_list: # iterate over each thing in source
   trans1 = G(item) # transform the item with the G() function
   intermed.append(trans1)
   trans2 = F(trans1) # second transform with the F() function
   target.append(trans2) # add transformed item to target

Of course I could think of some clever way to stick that all into a listcomp, or add some sort of composition. But doing so suddenly becomes "clever" rather than "normal" coding. I certainly don't advocate adding such gratuitous extra lines to the article itself... but for the talk page, it more than suffices to refute the absurdly repeated claim that imperative programmers never (or rarely) store intermediate values. LotLE×talk 18:34, 26 November 2007 (UTC)

How about remaking the examples using C# 3.0? It supports both programming paradigms and has common C-style like syntax, which is well known by most of people. The syntax of Python is not that universal and thus difficult to understand for a non-open source fanatic. --Maxim reality (talk) 08:22, 24 July 2008 (UTC)

This is ridiculous. No competent programmer would ever use the code it LotLE's second example. Secondly, the whole point of the "Coding Styles" section seems flawed. Does encapsulating a for loop in a separate achieve anything semantically? That is the only difference in the end. I hope functional programming is more than a paradigm encouraging hundreds of minuscule functions. Interestingly, both the imperative coding examples will compile to the same thing as any decent compiler (IDK about JIT) will use registers for local variables. The FP example compiles the same with an additional function call.

A good example illustrating the difference between imperative programming and FP would use global state. OpenGL is a good example of global state in C, it stores state for everything :P. However good programmers minimize scope as much as possible. I really don't see the difference this section is trying to make. Ultimately it becomes a matter of aesthetics, that is, syntax + standard libraries. Comparing the two examples in python won't show the difference in succinctness, comparing something like haskell and C might. Either way the examples just don't cut the mustard, they are just too similar. 70.27.182.206 (talk) 21:20, 9 September 2010 (UTC)

It's true that this example could be more illustrative, but mainly because the structure of the "functional" code snippet is not typically functional. List examples are not a good example anyway. The real difference between the two styles is not function composition (which can be done on both), but iteration versus recursion - which is hidden behind the 'map' function whose definition is not shown. Diego Moya (talk) 08:50, 10 September 2010 (UTC)

I've replaced the list example with an algorithmic one. Diego Moya (talk) 09:28, 10 September 2010 (UTC)

Clojure

LauBJensen has repeatedly added Clojure to the lead, in the list of "notable functional programming languages used in industrial and commercial applications by multiple organizations". Clojure, while no doubt a nifty language, is also quite new. So I'm skeptical of claims that it's (a) notable (ok, I've heard of it, but does that make it "notable"?), and (b) widely used in industry. I've asked for references, and the only one forthcoming so far has been a link to Lau's own consultancy website. This strikes me as both a conflict of interest, and a relatively poor indicator that Clojure is widely used. Is there any reason to believe that Clojure is actually notable and widely used? If so, does anyone have references to back that up?

On a related note, I'd prefer not to see the lead become crammed with a list of everyone's favourite functional language. Perhaps it would be helpful to have a more concrete set of criteria for inclusion in the lead than "notable" and "widely used in industry". Any suggestions? Some threshold number of industrial users perhaps? Longevity? Something else? If we can't come up with something, and the list continues to grow, perhaps it'd simply be better not to include it in the lead (i.e. move it in to the body of the article).

--Allan McInnes (talk) 06:11, 27 August 2009 (UTC)

I see that Lau has again added Clojure, this time with a link to his own consultancy, and a link to a blog as a reference. The blog in this case merely reports that Rich Hickey (creator of Clojure) gave a talk somewhere. Again, this hardly indicates wide use. I suppose it might indicate notability. The fact that the Pragmatic Programmers have a Clojure book is perhaps a better indication of notability. But it'd be nice to see some indication of wide industry use, which is after all what the list in question is about. I'm having trouble finding any references to that effect. --Allan McInnes (talk) 06:30, 27 August 2009 (UTC)

I agree with Allan McInnes here. Slightly reluctantly, since Clojure really does look like an interesting language that is gaining traction. And moreover, the second link Lau added is to my friend Chas Emerick, whose company Snowtide I even did a little bit of work for some years back. But while Chas likes Clojure, that's not a big industry player. I think it quite likely that in a couple years this addition will be merited, but not yet. LotLE×talk 07:37, 27 August 2009 (UTC)

As I'm sure you are aware I'm quite new to Wikipedia and therefore I'm probably uknowingly stepping on a few peoples toes. I will maintain my position that your personal oppinion of any given language does not change the facts and so does not belong on informative pages. Nor should those oppinions be permitted to slur the facts. I know of several companies that use Clojure. Among those are 2 of Denmarks largest Energy companies, customers in the national health care industry and others. In America, Chas Emerick is primarily using Clojure now for new developments and the fact that you dont regard him of a 'big player' is irrelevant. Secondly, flightcaster.com has a large data-crunching engine which is entirely made in Clojure as you can read on Clojure Google Group. So looking at this objectively, yes Clojure is used in industry, by several companies in several areas of industry. Please then, do not try to express your personal oppinions on Wikipedia and thereby slur the truth for those looking to get acquanted with industry-grade functional languages. If anyone should for any reason still feel that this addition is not merrited, please search yourselves for as many references as you would like to satisfy your personal criteria instead of battling on a public Wiki page. Thank you.

--LauBJensen (talk) 11:48, 28 August 2009 (GMT+1)

Please don't assume that you know what my personal opinions are, or how they impact my editing. In general, your best bet in Wikipedia is to assume good faith on the part of other editors. Regardless of my personal opinions of Clojure, the fact remains that it is a relatively new language, and thus there is likely to be certain amount of skepticism around claims about its notability or industrial uptake. Wikipedia's policy on verifiability makes it quite clear that assertions, particularly controversial ones, need to be backed up by references to reliable sources. As I mentioned above, neither a link to your own consultancy website nor a mention of the language in a blog post really count as good citations for establishing notability or wide industrial uptake. As the editor wishing to add this material to the article, the burden of evidence falls on you. If, as you say, it's easy to search around and find "as many references as you would like", then you should have no trouble in providing good reliable sources.

Since you are new to Wikipedia, I'd encourage you to have a look through Wikipedia's policies and guidelines. In particular, it would be worth your time to take a look at the policy on verifiability, the policies around how not to use Wikipedia, and Wikipedia's general editing policies. Thanks.

--Allan McInnes (talk) 23:43, 28 August 2009 (UTC)

Thank you for the links, Ive looked through them. Although some of it borders on relevance I maintain my position that since Clojure is used in industry it belongs on the list, regardless of this communities personal language preferences. I will add another reference. Please refrain from editing page based on previous given arguments which are false. Instead I'll recommend to you, to put valid arguments on this page for further discussion. The fact remains: Clojure is widely used in industry. Its verifiable.

Regarding my reference to Snowtides blog: The point was not to look at the content of the blog, but the fact that a Software development company uses Clojure. I'm also adding ThinkRelatives Clojurepage, to show you a 3.rd company using Clojure. /Lau —Preceding unsigned comment added by LauBJensen (talk • contribs) 06:04, 29 August 2009 (UTC)

As I've already mentioned, if it's verifiable then you should have no trouble providing references from reliable sources. A blog entry is not a reliable source. Your own consultancy website is not exactly a reliable source either. Your repeated posting of a link to it is a clear conflict of interest. I realize that you are posting it to provide a reference rather than to promote your company, but by posting you are also bordering on self-promotion, which the Wikipedia community tends to frown upon.

Please note that the list in the lead is not intended to be a comprehensive list of every functional language used in industry. It is merely intended to make clear the fact that, despite popular mythology to the contrary, functional programming is not restricted to academia. The four FP languages that are listed are well-established, have wide name recognition, have been around for a relatively long time, have been used in industry for quite some time, and have had their use widely reported. Clojure is a great language. Rich Hickey has done a really nice job on its design, and I think he's implemented seem really cool features. But I'm afraid that Clojure just doesn't come anywhere near the stature and notability of Erlang, Haskell, OCaml, or Scheme. Since you appear determined to add Clojure to the article, please consider inserting it further down the article (with appropriate references), in a section on industrial use of FP (in general the lead should summarize the article, so the fact that we mention industrial use means we really need an article section on it anyway). To that section we can also add mention of other FP languages that are being used in industry, such as Lisp, Scala, F#, SML, and so on. The Commercial Users of Functional Programming conference is a goldmine for examples.

--Allan McInnes (talk) 06:24, 29 August 2009 (UTC)

The new link you have added is a better reference than the others. --Allan McInnes (talk) 06:27, 29 August 2009 (UTC)

I've gone ahead and created a Use in industry section, as I outlined above. Clojure is included in that section. --Allan McInnes (talk) 09:37, 29 August 2009 (UTC)

The current link goes to somebody's training course, which seems a bit weak, and possibly promotional. I'd prefer some kind of evidence of significant industrial projects being done in Clojure in order to mention Clojure in that section. There is certainly plenty of such evidence (such as CUFP presentations) for Erlang, Haskell, and so forth. 67.122.211.205 (talk) 16:07, 27 September 2009 (UTC)

I agree, the link to the training course website seems self-promotional and does not look like a good-faith reference. Imho, it should be removed. Sohail Mirza 20:34, 4 January 2010 (UTC) —Preceding unsigned comment added by Mirzmaster (talk • contribs)

I changed the cite from the training course to a recent InfoQ article about a medical application. I had already looked around for better evidence of industrial use of Clojure without finding any. Clojure seems pretty marginal for this article to begin with. It's a Lisp dialect whose influence and relevance to FP (as a topic in computer science) is pretty slim (the case for Scala is much stronger). The InfoQ article gives the impression that the application it describes is one of the first times anyone did anything serious with Clojure. I decided against removing Clojure completely in order to avoid edit warring, and because it actually does seem to be getting some traction in the Lisp community. I guess the brief mention is ok. 66.127.55.192 (talk) 05:19, 26 January 2010 (UTC)

Footnotes

Two related issues. I think we overcite some claims, especially in the lead. For example, I really don't think we need four sources to demonstrate that Scheme is "used in industry"; one or two solid ones is more than enough for that point.

Second issue, which will make playing with the first one easier. I'm not sure when it was added, but I reasonably noticed the option of using a "<references> ... </references>" block in the References section to list named refs. These names can then be referred to inline, where needed, without requiring a large and visually disruptive citation template within the text flow. What is produced for the rendered page is identical, but it makes it much easier for future editors. Take a look at my recent edits to see how it works.

Now that I've moved some of the lead refs down to the bottom for safe keeping, I will prune some of them from use as citations in the lead. But they are mostly still used later in article for more specific points, so the current arrangement makes it more flexible to add or remove them from the body/lead as seems best (i.e. they stay available in article). LotLE×talk 19:21, 6 October 2009 (UTC)

Good idea! Thanks for tackling this. --Allan McInnes (talk) 21:31, 6 October 2009 (UTC)

Remove broken link?

"Functional Programming" — Chapter 4 of Advanced Programming Language Design by Raphael Finkel, an introductory explanation of functional programming —Preceding unsigned comment added by Timhoooey (talk • contribs) 02:39, 29 November 2009 (UTC)

I removed it. 66.127.55.192 (talk) 02:07, 27 January 2010 (UTC)

Efficiency

Before, here was a claim that an exponential slowdown is possible, with a reference to a paper. But the paper does not claim that there exist non-pure programs whose most efficient functional variant is exponentially less efficient! However, the logarithmic argument is quite well-known and obvious; so I guess that the person who wrote about exponential slowdown misunderstood the paper. —Preceding unsigned comment added by 93.92.202.116 (talk • contribs)

With respect to efficiency, it should be mentioned that the Fibonacci-example is unfortunate, as the "functional" version is very slow (I guess ~ 2^N) due to the redundant computation. Much more efficient would be a tail-recursive approach, which is admittedly harder to understand for the beginner, see e.g. http://en.literateprograms.org/Fibonacci_numbers_%28Scala%29 Regards Zoglala (talk) 11:35, 18 October 2010 (UTC)

Good point, I fixed it. 75.57.242.120 (talk) 12:24, 10 March 2011 (UTC)

Is functional not declarative?

Functional programming is not categorized under declarative languages, though in fact it should be, in my opinion. The categorization isn't really backed up by citations also... How did this come to be? Or am I missing a vital point here? :) — Preceding unsigned comment added by GerardVanHelden (talk • contribs) 15:57, 18 November 2011 (UTC)

I don't think of them as meaning the same thing, or of functional programming as necessarily being declarative. Functional programming is sort of a nebulous concept, but I'd say its main characteristics are that higher-order functions are first-class values, and that syntactic terms denote unique values (i.e. in pure functional programming, data is immutable). 67.117.145.9 (talk) 09:02, 3 March 2012 (UTC)