I'm a TA for several Bachelor level functional programming courses at my university. In every edition we have problems with some students that have the idea that functional programming is useless, because the industry doesn't use it. The more nuanced students add that some functional programming techniques are useful in any language (they think of lambda expressions in Java, map in Python, etc.) but that there is no point in learning pure functional programming as you cannot use it to build real-world applications (and if you can, nobody does it). These students usually tend to infect others and that can bring an unpleasant atmosphere.

I have read Hughes' 1990 paper Why Functional Programming Matters, where he explains that people in arguing for FP often tend to show what it doesn't have (assignment, side effects, ...) instead of what it does have. However, the things he mentions that FP does have (higher level of abstraction through gluing functions, lazy evaluation and thus easier modularity) are hard to grasp for mid-Bachelor students. In the end of the course they should be able to understand those advantages when you talk them through it, but the problem is motivating them from the start.

I know that most students will not end up as a functional programmer. But, learning one language means getting more proficient in others, and analogously for paradigms, so I think it is still helpful for them to study it. Yet when I explain this to the students the inevitable question is "why don't you teach us FP in a language that we can actually use later?".

What can I use to show the usefulness of functional programming?

Note: like many universities we don't use Haskell in all courses but a lesser known more academical functional programming language. This explains in part the complaints, however, we receive these complaints on Haskell courses as well.

  • 10
    $\begingroup$ It might be useful to show which programming langaues are "hot" right now and that these languages are all using some form of FP. (For example JavaScript, Swift, Rust, [Erlang&Elixir], Python, Scala, ...) And to fully understand what the advantages/disadvantages are one needs to understand the fundamental basics (.e.g. a pure FP language). $\endgroup$ – Raphael Ahrens Aug 28 '17 at 12:52
  • 1
    $\begingroup$ Comments are not for extended discussion; this conversation has been moved to chat. Any further discussion will be deleted and will not be moved to chat. $\endgroup$ – thesecretmaster Aug 29 '17 at 12:57
  • 3
    $\begingroup$ The assumed premise in this question is very questionable. After I finished my PhD not knowing any functional programming, the first company I joined turned into a Haskell shop and now I write Erlang for a living. Both languages are purely functional. Moreover, I see a lot of Python projects now strictly using functtools to write functional python despite it not being a functional language. So, I doubt the assumed premise in your question anecdotally. I've literally paid my bills since graduation with FP despite never thinking that once before hand. $\endgroup$ – Tommy Aug 31 '17 at 12:33
  • 2
    $\begingroup$ Sorry y'all. I'd love to move these comments to chat, but because I can't I've had to delete them. $\endgroup$ – thesecretmaster Sep 2 '17 at 1:12
  • 2
    $\begingroup$ Tell them Scala is used by Twitter, LinkedIn and eBay. Tell them that Akka, which requires that certain data be immutable, is used by Amazon, Walmart, PayPal, and Intel. $\endgroup$ – Brian McCutchon Sep 2 '17 at 23:50

12 Answers 12


What can I use to show the usefulness of functional programming?

This is the wrong question, and by trying to answer it you're falling into a trap of accepting and reinforcing the students' misunderstanding of what university is. If I had applied that standard of value to the courses in the bachelor's degree I studied, I think I would only have attended 30 hours of lectures over the three years.

You may be right that most of them will not end up earning their living by programming in functional languages, although given current industry trends I wouldn't be entirely surprised if you turn out to be wrong in the long term. But if their goal is merely to gain a superficial knowledge of whatever is currently popular in industry, they're not just in the wrong course: they're in the wrong institution, and should drop out and find a bootcamp.

  • $\begingroup$ Comments are not for extended discussion; this conversation has been moved to chat. $\endgroup$ – thesecretmaster Aug 29 '17 at 23:24
  • 4
    $\begingroup$ I don't agree with this answer. Usefulness != popular in industry. Or to put it another way, the question isn't "what can I use to show the usefulness in industry...? This is clear from the OP's penultimate paragraph, where he provides a reasonable justification for usefulness. University is about teaching useful content. Useful doesn't have to mean direct or immediate. Something can be useful because it gets the student thinking in a certain way, provides context for other knowledge, builds intuition, and a whole host of other reasons. $\endgroup$ – JBentley Sep 1 '17 at 15:00
  • 3
    $\begingroup$ Yes, it feels like the real question that needs to be answered here is the one asked at the end of the question: the inevitable question is "why don't you teach us FP in a language that we can actually use later?" Why on earth would anyone teach in a dead language? Nobody loves Latin, nor Cobol. Teach a paradigm in a language that they are familiar with, and they will learn the paradigm. Teach it in an unfamiliar language, and they will learn... language syntax. $\endgroup$ – Dewi Morgan Sep 1 '17 at 20:41
  • 1
    $\begingroup$ @DewiMorgan I don't know if anybody loves Cobol, but it's absolutely false to say "Nobody loves Latin". Clearly, many people do (including me, though my understanding is limited). It's relevant because the reasons often given for learning Latin are similar to those given for functional programming: it improves your thinking, it makes you better even at other languages, it builds character, etc. :-) $\endgroup$ – ShreevatsaR Sep 6 '17 at 4:37
  • 1
    $\begingroup$ @PeterTaylor The point of my first comment was given in my first comment: "the real question that needs to be answered here is the one asked at the end of the question". I agree, if students know no suitable language for the paradigm, one must be taught. That's a strong, valid answer to that question, but is unlikely to ever be true. Even then, the selection must be defensible: Lisp would be hard to defend. "This is the only functional lang I know" or "javascript isn't as good for functional code" risk being seen as weak, invalid attempts to justify laziness on the part of the teacher. $\endgroup$ – Dewi Morgan Sep 6 '17 at 16:34

Hughes is absolutely right, and the following paragraph from his paper hits the nail right on the head:

Such a catalogue of “advantages” is all very well, but one must not be surprised if outsiders don’t take it too seriously. It says a lot about what functional programming isn’t (it has no assignment, no side effects, no flow of control) but not much about what it is. The functional programmer sounds rather like a medieval monk, denying himself the pleasures of life in the hope that it will make him virtuous. To those more interested in material benefits, these “advantages” are totally unconvincing.

You say:

However, the things he mentions that FP does have (higher level of abstraction through gluing functions, lazy evaluation and thus easier modularity) are hard to grasp for mid-Bachelor students. In the end of the course they should be able to understand those advantages when you talk them through it, but the problem is motivating them from the start.

None of these things are particularly difficult to learn, unless you teach them in an inherently difficult style (such as Haskell or "a lesser known more academical functional programming language.") Many functional concepts are useful in the right places, as a "the right tool for the job" sort of thing, but functional languages have a tendency to go overboard and apply these concepts dogmatically rather than pragmatically.

Imperative languages get this right much more often. For example, you want your students to understand lazy evaluation? Teach them to use Python generators or C# iterators. That's what the yield keyword is: lazy evaluation. But it's set up in such a way that you decide when to use it as appropriate, rather than the language dropping it on you as the default. Want them to understand coroutines? Teach them async/await. Likewise, there's nothing at all in Hughes's explanations of "program gluing" that can't be easily rewritten in modern-day object-oriented languages.

Today, with LINQ (.NET), the Streams API (Java), and Itertools (Python), basic functional concepts are used all the time in industry. But they're used as "another tool in the toolbox," to be applied as appropriate. When your students balk at functional languages, a large part of the problem is because they don't have this approach; they try to cram all these concepts down your throat whether you want them (or even need them at all!) or not.

A classic example is recursion. Let's say you wanted to find the length of a linked list. In Python, you'd do it like this:

def length(list):
    result = 0
    while list is not None:
        result = result + 1
        list = list.next
    return result

In Paul Graham's paper "On Lisp", he does it a different way. I'm not going to inflict Lisp upon the audience, (the originals can be found on pages 22 and 23 if you're really curious,) but his naive solution translates to:

def our_length(list):
    if list is None:
        return 0
    return 1 + our_length(list.next)

This is shorter and simpler than the way I did it, but as he then points out, there's an obvious problem with this: it can produce a stack overflow if the list is long enough. In order for a functional language to cope with this problem, it needs its functions to be tail-recursive. Here's the Python equivalent of his tail-recursive version:

def our_length(list):
    def rec(list, acc):
        if list is None:
            return acc
        return rec(list.next, 1 + acc)

    return rec(list, 0)

Wow! Look at that monstrosity! It's as long as my version (6 lines of code), but about twice as complicated and harder to read, requiring a nested function that does all the work for no easily-apparent reason. It's only when you understand that functional languages hate looping constructs and mutation of variables, and inflict recursion and immutability upon the developer dogmatically, rather than pragmatically allowing you to use them as appropriate, that this way even begins to make any sense at all! (Amusingly, the reason you have to write it as such a mess is so that the compiler can automagically detect that you're using tail recursion and transform the function into a loop featuring the accumulator as a mutable variable, factoring out the toxic recursion so it won't break the stack!) In reality, recursion is extremely useful when dealing with inherently recursive problems such as tree structures or divide-and-conquer algorithms, but trying to use it on linear problems where a loop is the natural fit is just asking for pain and trouble more often than not.

In summary, the reason it's difficult to convince your students that functional programming is not useless is largely because the specific flavor you're teaching them is, in fact, useless and counterproductive, an active impediment to productivity. Unfortunately, you probably can't get away from teaching the languages mandated by your curriculum, but if you can explain things in ways that are actually relevant to modern programming practice and their future careers, you'll likely see understanding dawn as they realize how and when these techniques can be appropriate. What they're missing, because dogmatic functional languages largely reject the concept, is the all-important notion of "the right tool for the job, as appropriate."

  • 12
    $\begingroup$ You miss out on abstraction. What's the equivalent to an efficient for loop? No, it's not tail recursion, its foldl'. You write def our_length(list): return list.reduce(x => x+1, 0) $\endgroup$ – Bergi Aug 29 '17 at 6:52
  • 1
    $\begingroup$ Comments are not for extended discussion; this conversation has been moved to chat. Any further discussion here will be deleted and will not be moved to chat. $\endgroup$ – thesecretmaster Aug 29 '17 at 23:08

I think the real trick is in teaching the value of Functional Programming rather than trying to teach the value of Functional Programming Languages. The latter will fail the pragmatic approach in almost all cases. Why? Because functional programming languages intentionally restrict themselves in the name of purity, and then try to demonstrate that they can be just as effective as other languages. Meanwhile, the other languages have sought to be productive as goal #1. It should be expected that the languages which strive for productivity first will be more productive than those which put productivity second. If not, those other languages have truly failed. The mere fact that C, C++, Python, PHP, etc. are all alive and well suggest that even the most staunch supporter of Haskell has to admit that these languages are good at doing what they strive to do. That thing they do may not be exactly what the Haskell developer wants to do in their programs, but they have to admit that the other languages do what the other people want them to do.

Instead of trying to promote the languages themselves, I would try to build a niche for these functional programing languages by building interest in functional programming in general. You mention that several students already have picked up that functional programming has been working it's way into "mainstream" languages like Java or Python, or even C++11. Don't fight that. Leverage that. Teach them that functional programming, itself, has value. Use whatever language it takes to teach that.

Once they start getting interested in functional programming itself, that is the time to start encouraging them to approach languages like Haskell. Once the students realize that there's another way to solve some of these problems, the functional way, then languages like Haskell can start to sell the argument that everything can be done functionally. In fact, the typical battle cry of Haskell lovers is that it can even be done efficiently and functionally! This battle cry falls flat if students are currently content with their tools, but if you have demonstrated to them that there is power to this new way of thinking, the battle cry sounds different.

The message should not be "learn Haskell, it's a great language." The message should be "Learn functional programming. It's a powerful tool that you can apply in many languages, and it's easy to hone your skills at it using Haskell." Or substitute your academic language. You should be selling the technique, not the language. Teach them to find a balance between the procedural styles and the functional styles. That balance will differ at every business that eventually employs your students. There is no one "right" balance, so teaching them how to strike the best balance for the moment is a great job skill.

I learn martial arts. In my martial arts class, I do lots of things that I will never find a need to do in real life. Why do I do them? Because they teach me skills I will use in my day to day life, and the most efficient way to learn them is to spend the hours in a pure environment dedicated to honing those skills.

Likewise, I have learned functional programming languages. In learning those languages, I do a lot of things that I will never do in my day-to-day career. Why do I do them? Because they teach me the set of skills I do use in my career, and the most efficient way to learn them was to spend the hours in a pure environment dedicated to honing those skills.


Consider what they are saying, discuss with the students, and agree with them that perhaps they are right. Its almost impossible to get anyone interested if they already know that they won't benefit (at least in the monetary sense) from it in the short and medium run.

By agreeing with them, you take them into your confidence. Then, find ways to incorporate some of the ideas of functional programming into your general discussion. For instance, C# is the regular (imperative) programming language, something that they would be happy to learn. However, while discussing C#, you can also talk about F# which is functional, and runs on visual studio and dot net.

If you play it sly, you could have your cake and eat it too. You never know. Some of the students might even realise (like when they are taking a bath) that acquiring a deeper understanding of functional programming will give them a leg up in the long run.

  • 11
    $\begingroup$ Yes show them how there is currently a trend toward functional. As there once was a trend toward structured, and object-oriented. But the new will not replace the old. It will improve it. $\endgroup$ – ctrl-alt-delor Aug 28 '17 at 10:54
  • $\begingroup$ By agreeing with them, we reinforce their confidence. That will close them for any discussion. $\endgroup$ – beroal Sep 10 '17 at 11:21

Functional programming knowledge will definitely benefit your students. I think Martin Odersky explains it best here:


He explains that there needs to be a paradigm shift in the way we think of processing data. As we progress with technology, we are reaching the limits of transistor size. Because of this, instead of making processors smaller and more efficient, we will be looking to add more of them.

This will then lead to more parallelization which prefers immutability. What is one of the crowning side effects of functional programming? Immutability

Look at big Apache libraries like Spark. Spark uses Scala, a functional programming language built off of Java, to process LARGE amounts of data very quickly.

I would say that your students are completely incorrect in their notion that functional programming has not relevance in today's tech world.

  • 4
    $\begingroup$ You would have to take a side-trip to explain big data, then satisfy the student's need to understand procedural programming, so that they have some concept of what algorithms are and how to code them, then go back to big data and start explaining how Functional is necessary there. I don't think you can go straight for the punchline, people will not get the joke. $\endgroup$ – user737 Aug 28 '17 at 12:27
  • $\begingroup$ Functional programming is great for extracting an answer from a dataset so huge it spans a multi-room computer system. It's horrible for writing Tetris. Far more programmers will spend their careers writing Tetris that will spend their careers developing for room-sized computers. $\endgroup$ – Mark Feb 12 '18 at 6:10

I think it is pretty hard to convince students focused on the here-and-now of a lot of things. However, the teacher's job is to teach them what they need to know, not just what they want to know.

There are two reasons for learning a functional language. The most important is that anything that gets you to think hard about something new will make you better at other things as well. If you want your body to be strong you do something like run hard and long so that you sweat and collapse at the end of it (or nearly). If you want to be smart, do the same with your mind. Make it run hard, sweat, and collapse. If you don't know functional programming, learning it will expand your mind. If you do know functional programming, learning, say, C will have a similar effect.

The other reason is that functional may turn out to be even more important than we think now (or some new paradigm in its place). In particular there are two end points of getting a computer to do something. The first is to describe (somehow) what is to be done. The second is to describe how it is to be done. Imperative programs and even OO programs do the latter. They implement algorithms. Every new problem needs a new algorithm - a new set of steps. But we have seen glimpses (mostly Prolog or SQL) of a different world, in which we describe what we want, not how to get it. Functional Programming is much closer to this way of working than the strictly algorithmic approach.

And the reason that that might be important to learn about is that as machines get more complex, including more parallelism/concurrency, the harder it becomes to program them algorithmically and the more important it may become to program them descriptively, with the computer itself figuring out an algorithm.

The reason why this hasn't been the norm, yet, is that machines were also insufficiently powerful to manage it. But that is ending now. People preferred imperative programming for efficiency, but at a certain level of power, that becomes less important than getting the correct answer. After all, it doesn't usually help us to get the wrong answer fast. And generalized algorithms may be the answer to this, pushing us toward the descriptive rather than the process end of the continuum.

  • 1
    $\begingroup$ “the teacher's job is to teach them what they need to know, not just what they want to know.” Sure, but it’s hard to teach it to them while they don’t want to know it. Most routes to effectively teaching anything involve bringing students around until they do want to know it. $\endgroup$ – Peter LeFanu Lumsdaine Aug 30 '17 at 21:26
  • 1
    $\begingroup$ "the teacher's job is to teach them what they need to know, not just what they want to know" - Sure, but it's not unreasonable for students to ask `I get that you think I need to know this, but could you explain why you think that?' It's not unreasonable for students to ask you to help them to understand why you think that they need to know it. So the question probably still deserves to be answered. If you have a compelling argument that they need to know it, it seems like them asking the question is a great opportunity to make the case for it. $\endgroup$ – D.W. Sep 3 '17 at 2:19
  • $\begingroup$ Agree. Of course. $\endgroup$ – Buffy Sep 3 '17 at 9:52

There are two types of learning

The two types of learning that are useful are:

  • to solve an immediate problem.
  • as an investment, this is the type that you will mostly do at university. Although you will also practice the former, it is not for what you learn, but to learn how to learn.

The language is irrelevant

How many words are there in Python? About 20. How long does it take to learn? How long did it take me to learn French? I still have not finished, because the word-space of French is big, but I did learn my first 3000 words in 2 hours, because French is a lot like English.

The more languages you know, the quicker you become at learning languages.

The Language is important

My spelling has improved in English since I learnt French. My object oriented programming has improved when I learnt functional programming. It was easier and quicker to learn the correct language. I only properly learnt functional when I did it in a functional language. I only properly learnt object-oriented when I did it in Eiffel.

The more languages you know, the better you become at the others.

Functional is the future

Moore's Law is coming to an end. Clock speeds have stopped increasing. Transistor count is continuing to increase for now. Core count is increasing.

Imperative programming does not scale in this environment: When you write a multi-threaded imperative program, you will fill it with locks. This will not only create bugs, but you are causing it to be single threaded.

No one uses it — are you sure?

A lot of server software uses functional; I know google uses it.

You may be correct that no one uses it on the desktop, much. But how much computing is done on the desktop? Look at servers, supercomputers and embedded. Most of the CPUs in the world are deployed in embedded systems. At least 80%.

Faster learning

It can be quicker to learn things separately. Learning functional programming in a functional language, then leaning a non-functional language. Can be quicker than leaning the non-functional language first. However this will depend on may things, including choice of language, how they are taught, etc.

Bertrand Meyer, in a touch of class, makes this claim about Object-orientation and Eiffel.

The language is irrelevant

Give me a functional language with lambdas, and I can implement mutation. Give me a non-functional language and I will write very clean, mostly functional code.

The Language is important

When looking at teaching/learning resources

  • for non-functional languages, they tend to start in lesson 1 with mutation. This is a bad idea even for learning procedural programming.

  • for functional languages, they leave mutation until much latter. In structure and interpretation of programming languages, it is about half way through. You will be surprised, I had to look back I could not believe that we had done all that without them.

  • 4
    $\begingroup$ Learning more languages can also confuse programmers more. There is no indication that functional is the future. Most programs run on a desktop/phone. "Can be quicker" is not a convincing argument as it depends on the person learning. $\endgroup$ – TwoThe Aug 28 '17 at 11:55
  • 1
    $\begingroup$ @TwoThe Learning how to learn new languages quickly is another skill they should be picking up. No language is perfect, after all, so they should always be expanding their toolbox even if they do neglect functional languages (which they shouldn't). Temporary confusion is a common symptom of learning something new. $\endgroup$ – Ray Aug 28 '17 at 18:39
  • $\begingroup$ I haven't seen a non-trivial case in which a compiler automatically multi-threaded independent expressions so as to better utilize a CPU's multiple threads. Sounds great in theory, but I've never seen it practice. For one, I worry about how a compiler would determine if two expressions are sufficiently expensive so at to benefit enough from being processed in parallel, and to be worth the huge overhead of spawning/synchronizing threads. Would love to be proven wrong, however. $\endgroup$ – Alexander Aug 29 '17 at 4:42
  • $\begingroup$ (1/2) Additionally, even though the statement "fp performs better because it can be automatically parallelized" is theoretically true, I would argue that it's not as much of an issue. It's already quite uncommon for performance to be the primary issue of a project. The primary challenges of software development are rapidly shifting away from hardware limitations, and towards project management/scale/complexity issues. $\endgroup$ – Alexander Aug 29 '17 at 4:47
  • $\begingroup$ (2/2) A strong argument can be made that languages need to strongly prioritize simplicity, rapid prototyping, maintainability. In many cases, FP excels at these things, but the argument for theoretical performance improvements is less relevant than ever, and it becomes a mere "nice-to-have". $\endgroup$ – Alexander Aug 29 '17 at 4:51

Give them the following task to implement in plain old Java:

Given is a list of Students with their name, area code and average test score. Write a program that calculates and prints out the average score of all students by each area.

Example input:

final List<Student> students = Arrays.asList(
    new Student("Meyers", "12345", 2.3f),
    new Student("Miller", "12345", 1.1f),
    new Student("Swanson", "34567", 3.4f)

Example output:

34567: 3,40
12345: 1,70

This task is trivial, but the amount of non-functional Java code you need to write is extensive. After they have presented their solutions, show them the solution written in functional Java:

    .collect(Collectors.groupingBy(Student::getAreaCode, Collectors.averagingDouble(Student::getAvgScore)))
    .forEach((code, score) -> System.out.printf("%s: %.2f\n", code, score));

Then explain that functional programming is a tool that serves well when you have to deal with tasks that can be described as a mathematical function. And using that will - as demonstrated - greatly reduce the amount of code you have to type.

  • 4
    $\begingroup$ Well, honestly, if I came upon that in a code review in an enterprise-y environment...I would probably send it back to be redone in a way that is less "elegant" but more "readable" or "maintainable"... $\endgroup$ – user3067860 Aug 28 '17 at 22:10
  • 6
    $\begingroup$ Readability and maintainability depend on the level of knowledge in the company. In my current company about every Java developer can fluently read and maintain that. But I've also been in companies where the word "stream" alone caused headaches, there I probably would write that differently. In the end it is however an artificial solution to demonstrate something. $\endgroup$ – TwoThe Aug 29 '17 at 7:42
  • 4
    $\begingroup$ @Walfrat let me play the devil's advocate right back. In C# you can write that code in C# and then have that run on the database by using a LINQ provider - where the abstract syntax tree is used to generate SQL. The fact it's functional is what makes this possible. This is how a LINQ provider do. $\endgroup$ – Benjamin Gruenbaum Aug 29 '17 at 13:54
  • 6
    $\begingroup$ @user3067860 You may have hit upon an answer to the original question there. Learning functional programming is useful because people who haven't can be confused by three lines of fairly trivial code. $\endgroup$ – Ray Aug 29 '17 at 18:40
  • 2
    $\begingroup$ @JerryCoffin True...but APL is a special case. Any language composed mostly of characters that don't even exist on a standard keyboard is going to be difficult to read. But the simplest evidence I have for the idea that anyone confused by TwoThe's example is confused by the functional programming and not the syntax or API is that I've never used Java's streams API and I was able to understand that code without any difficulty since the functional approach was so clear. $\endgroup$ – Ray Aug 31 '17 at 17:42

There is a really good teaching point here.

Ideas often arise repeatedly in different contexts. That includes the ideas behind Functional Programming.

We also all know how fast computing changes. Your job is to teach them computing, and its up to them to choose how to use it and the specialist areas they need most, which they probably don't yet know as 90% of what they will each specifically use, and several key paradigms they will come to rely on in their future careers spanning maybe 40+ years, hasn't yet been invented or become the main paradigm.

Given that you are preparing them for many years ahead, and a broad topic, it is reasonable to include FP and expect it to be taken as serious and useful. Like machine code, firmware, and logic gates, few of your students will directly use it, but many will indirectly use it and all will use tools and techniques which began in it.

As even the protesting students can't tell whether they'll find it useful in future, its got a strong ground for being taught, so they understand the concepts and history behind it, and behind what they now do. Also so its there if they do come in contact with FP work in future.


I would start by distinguishing between the claims

  1. Functional programming is useless., and
  2. Functional programming languages are useless.

It's likely that when students say the former, they actually mean the latter, and the latter is more likely to be true (or at least valid) from the perspective of their goals.

Regardless of whether functional programming languages will be useful to your students, functional programming gives a model for thinking about whether code in whatever language they end up working with has important properties, like being free of side-effects or internal state.


It seems to me that your students are asking for external validation: they want evidence that other people (the industry) value what you are teaching. For these students abstract claims such as "This will help you write better non functional code" or "you might need it in the future" usually do not suffice. Toy examples such as computing array/string length or mean/variance of a set of values are also equally insufficient because these problems are easily solved. Many other answers provided great concrete examples that might help to alleviate this need, but I believe that few have touched on what I believe to be a core issue: your courses that involve FP appear to rely mostly on intrinsic motivation (the drive to learn because something is cool, essentially). In a certain way, students are expected to be enthusiastic just because they signed up for the course. There is nothing wrong with having a curious mindset and wanting to learn a lot of things just because, but expecting most students to behave this way is not realistic.

I will expand on a different approach that involves changing the way the courses are taught to take into account students who are not intrinsically motivated. You could try being pragmatic and choose a difficult problem as an excuse to present FP concepts and tools. Essentially, functional Programming exists because it can solve a set of problems "better" than other tools. In some cases "better" means easier, in other it means at larger scale or more readable or less error prone. Start by presenting these problems and base your course activities around solving them. You can then go crazy with FP and present all functional goodness that we all know and love, but in a context where they are clearly valuable. If you can't find a context where something is valuable but you really want to teach it, you can make it an extra activity for those who are intrinsically motivated.

For instance, lazy evaluation and immutability are incredibly valuable in Spark and presenting them in this context can help sell these ideas. Compare this approach with a program using MPI and you have an easy winner.


Out in the real world (and I use this phrase only because the question is about the criticism of functional programming being useless) a functional language that is used often is SQL.

I have seen too many reasonable developers that are unable to grasp how to use SQL effectively because they can only think iteratively and not “functionally”. I have seen way too much code where only basic SQL is used to retrieve a result set and then rather complex loops, lists, dictionaries etc are used to further refine the results.