Are we in a functional programming fad?

Question

I use both functional and imperative languages daily, and it's rather amusing to see the surge of adoption of functional languages from both sides of the fence. It strikes me, however, that it looks rather like a fad.

Do you think that it's a fad? I know the reasons for using functional languages at times and imperative languages in others, but do you really think that this trend will continue due to the cliched "many-core" revolution that has been only "18 months from now" since 2004 (sort of like communism's Radiant Future), or do you think that it's only temporary; a fascination of the mainstream developer that will be quickly replaced by the next shiny idea, like Web 3.0 or GPGPU?

Note, that I'm not trying to start a flamewar or anything (sorry if it sounds bitter), I'm just curious as to whether people will think functional or functional/imperative languages will become mainstream.

Edit: By mainstream, I mean, equal number of programmers to say, Python, Java, C#, etc

Answer 1

purely functional programming was/is a fad, but functional constructs like first-class functions, closures, optional immutability are not a "fashion", in my opinion.

we use them all the time in javascript and it's not going away anytime soon.

Answer 2

I don't expect to see functional languages being massively widely adopted. What I expect to see is people learning a functional language as a way of helping them to use functional idioms where appropriate within more mainstream languages. For instance, C# 3.0 encourages a much more functional way of working with collections via LINQ and lambda expressions. The more someone understands about functional languages, the more effective they will be with C# 3.0. That doesn't mean they need to actually use those functional languages for production tasks (although with things like F#, they could do so and interoperate with other .NET languages).

Answer 3

I want to challenge your premise - that functional languages are significantly more "in" now than they were 10, 20 or 30 years ago.

I think there has always been an undercurrent of people discovering functional programming, falling in love, trying to make it work on a broad-scale, and managing to cut out only a niche market.

Has that really changed? What evidence would you offer?

[Notes: This is a strong opinion, weakly held. Back in 1995, I worked as a research assistant on an academic project which had a basic thesis that it was only the lack of debuggers that held functional programming back from the mainstream. Even at the time, I found this hard to swallow. Even at the time, I loved the opportunity to be paid to do functional programming.]

Answer 4

I guess it will depend on how well the education system picks FP up. (I don't mean self-education).

FP requires, IMO, a different mindset (a more rigorous one) and investment of time (steep learning curve). Until the new breed of graduating programmers come equipped with these, it is really difficult for industries to switch to a different paradigm.

Answer 5

Elements of functional programming slowly creep into "mainstream" languages, as raw computing power and available memory size increases.

The first functional feature to become generally accepted was garbage collection -- arguably the most important productivity improvement introduced in java.

The next one will be first-class functions (very much alive in Javascript; syntactically unconvenient in Java's anonymous classes).

The inclusion of map/reduce (or fork/join) frameworks in Java 7 (jsr166) will introduce many people to a more functional mindset, at least where parallelism is important.

Maybe Java8 will introduce Erlang-style message-passing concurrency mechanism, and Java9 will finally kill of the old threading/synchronization model ;-)

Answer 6

No, I don't think that we are in a functional programming "fad".

Penetration of functional programming constructs/features into or via mainstream programming languages like Python, Ruby, C# is just normal language evolution.

We drifted away from the crudely organized BASIC and FORTRAN programming languages, which lent themselves to writing infamous "spaghetti" code (no offense to the Flying Spaghetti Monster intended) in the late 1970s and early 1980s.

Structured programming languages like Pascal became part of the norm then. C, though allowing some pretty wild things, was a lot better suited to structured programming than early FORTRAN.

That caught on and these days probably very few people are writing "spaghetti" code. Java, for instance, does not even have a GOTO statement. Dijkstra's famous "GOTO Considered Harmful" statement was heard. His advice was followed.

Later, in the 1990, object oriented programming (OOP) constructions & mechanisms became widely adopted language features. Today, we take them for granted.

Python and Ruby were more or less born with functional programming capabilities. It is part of their appeal. C++ gained them too. Not at the syntax-level of the language but through the introduction of its standard templates library. C# and Java will probably be giving them to their programmers soon.

I think we are just seeing steady evolution - nothing more - away from the early nucleus of features that the earliest general purpose programming languages had. Their features were born from a desire to uplift programmers from the chaos and complexity of assembly language and machine language programming.

Despite being an answer to drawbacks of programming a computer right at the level of its native, proprietary machine language instruction set - languages like BASIC and FORTRAN were also heavily influenced by it.

FOR-NEXT loops, GOTO statements, and GOSUB & RETURN statements - these all have analogs in machine language, being represented as one or several machine language instructions.

Functional programming, object-oriented programming, and now aspect oriented programming (AOP) are simply well-proven improvements to contemporary mainstream programming languages & practices.

When you ask why we are changing and why we are evolving our programming languages & habits, go back and look at some assembly language source code.

Would you seriously want to write all of your programs that way?

One final thing to consider.

Go back and take a look at the design patterns that became popularized in the mid-1990s. Design patterns are an accepted repertoire of solutions to common programming problems. Things like Composites and the undoable Command pattern really benefit from this functional programming stuff. It is how OOP graphics programmers have been doing things for decades.

As a specific example, weigh how commonplace GUI programming and event-driven programming is today. GUI programming, especially graphics applications, really benefit a lot from functional programming. You are basically applying a verb to an object, a list of objects, or a group composed of objects.

That is what functional programming (FP) is all about! You compose functions of other functions, you "apply" a verb/action/function and perhaps some arguments/parameters to one - or many - objects.

So, adoption of functional programming by the mainstream programming community and languages is not a transitory thing. It it is a transition toward a mechanism that will make it easier to solve the challenges we are faced with today. Easier than it is to program modern applications with the original FORTRAN & BASIC programming languages of the mid-1900s.

What I think you will see when functional programming features are added to your favorite programming language is something that will bring you happiness. Many good programmers will adopt an FP-oriented style for certain places, such as I have already alluded to - where an FP-coded solution is clearer, shorter, and more maintainable.

I think most people will like that. And who knows, it might just guide some brilliant prodigy on the path to craft some completely new kind of application. One that functional programming - combined with these other programming traditions - makes totally natural & easy.

I also predict that languages having these capabilities will also lead to more powerful programming libraries for addressing various problem & solution domain concerns by writing less custom code.

Functional programming will not replace these other things. It will augment them.

The better programmers will combine FP and the other things like OOP, AOP, and so on to create sounder solutions. The new solutions will be a little cheaper, faster, and smaller - and more easily maintained/understood. That is what resulted from adoption of these other things, which were not "fads" either.

Answer 7

which lent themselves to writing infamous "spaghetti" code (no offense to the Flying Spaghetti Monster intended)

Why do you think we call it "spaghetti code"? It because only the divine mind of the Spaghetti Monster can comprehend its noodly structure.

Aside: Cook's theorem states that SATed is Nutritionally Polynomial-time Complete ;-)

Answer 8

I don't think that the functional paradigm is a fad. However "pure" functional paradigm may be a fad. We are starting to see both concepts (imperative, functional) co-exist in harmony. One can't replace the other. But both can be used in conjunction to write better code. We already saw imperative programming languages such as C# incorporating functional programming constructs with Linq. Languages like F#, which is inspired by OCaml, allows mutable variables whereas in "pure functional" Haskell you would have to use Monads. At the same time, languages like Scala allows both functional and imperatives style, with some OO-ness thrown into the picture. This is great, because this signals the maturing of functional programming, and multi-paradigm languages is here to stay.

Answer 9

"many-core" isn't just a fad. As predicted, you can no longer buy a new desktop computer which isn't multi-core. It is here to stay. Concurrent programming is going to be a requirement to take advantage of that power. It will continue to be more and more important.

Answer 10

Yes - and no.

I use F# as my second language now, because I like the functional paradigm.

However, I really hope that in the end C# (my main language) will get all the features from F#, maybe with new features that allow us to write the same elegant things in C# as we do in F# now. Pipelining, etc... we also seriously need some way of enforced purity.

How about an async keyword in C# that requires the strict use of immutable data and pure methods in its scope?

I don't think that there will be a place for RAD - victims in the software industry 10 years from now. With the the functional paradigm on the rise, we will go back to more informatics, more theory and more "braincell usage coverage", which is a good thing.