The title of this article, for example. The idea of this article is that functional programming is hard, because it forces you to think in a new way. But here, calling functional programming hard is just used to pat oneself on the back. Great, this article says you can map a function over a collection and then sum it. You don't need to think of yourself as some elite programmer that casts a shadow over procedural programmers. It's not true.
Functional programming is just the general notion of using more functions, and less computer-architectury things, to express your ideas. It's not necessarily about map/reduce, monads, or whatever. Encode your ideas mostly as functions where possible. That's it.
It's bad to say that functional programming is hard on purpose, or that it makes you a part of some elite cadre. Functional programming should be, and usually is, no harder than any other way to explicitly write down your ideas. The whole point is to make it more simple to express your ideas in a way that can be evaluated by a computer. Functional programming isn't hard. Programming is hard.
"Functional programming is just the general notion of using more functions, and less computer-architectury things, to express your ideas."
Umm, no, that is not what functional programming is. Functional programming is, basically, programming without side-effects. A purely functional language will have variables that are completely immutable. This is a bit of a shift away from the way things are done in C or C++.
Speaking just for myself, I started into the programming world with Java (not counting QBasic), and I am finding it incredibly hard to wrap my brain around the idea of functional programming.
My understanding is that most programmers that have a background primarily working with non-functional languages have a challenging time initially grasping the concepts of functional programming. However, I would guess that a programmer that learns a functional programming style early on would probably have very little difficulty understanding non-functional constructs.
For more information, I would like to point you towards some easy reading:
Edit: To whoever down-voted me, I would appreciate some explanation of your views. The fact is that functional programming is not just using functions. The article plainly refers to functional programming languages and not simply using functions. There is a difference.
I don't ninja downvote, but if I had to guess I'd say it's because if you're finding functional programming incredibly difficult, you maybe shouldn't be lecturing on what it is.
As my cousin points out, it's true that it's easy to think of functions as just being macros in a language like C. If you call a function which doesn't have a return value, and which modifies some global state, that's not a "real" function, just a stored procedure.
However, if you write a C function which doesn't modify global state, but simply takes an input and returns an output, as even novice programmers do all the time, hey presto— that's the functional paradigm! There's nothing mystical about it, and what the GP is saying is that telling people who have done this that functional programming is something different is fundamentally confusing.
"I'd say it's because if you're finding functional programming incredibly difficult, you maybe shouldn't be lecturing on what it is."
Thank you for your thoughtful reply. I really do appreciate it.
It isn't the programming that is the hard thing. Writing some code to do something meaningful is not what is giving me a problem. Actually, it is trying to develop a deep understanding of functional programming that I am finding difficult. Maybe the problem is that I am confusing functional programming with purely functional programming?
My apologies to tumult if it came off that I was lecturing in my original post. I find it challenging to get tone perfectly right on the Internet. Face to face conversation or conversation over a phone is far better.
I think maybe this entire thread comes down to a question of semantics. When I program in non-functional languages I tend to lean towards using map/reduce type constructs a lot, but I never really thought of that as "functional programming". I guess I always thought that in order to really do functional programming, you really needed to have some kind of deep understanding of it.
Maybe if I had a formal computer science background, my perspective would be a little bit different because I would have more easily seen the point that you are making. As it stands, my background is in the social sciences and my knowledge of the science part of computer science is sometimes lacking.
Perhaps you are right, I should have been better informed before attempting to inform others. But if I had not typed my original post, then I would have never received your helpful reply and I would still be in the dark!
Maybe the problem is that I am confusing functional programming with purely functional programming?
Yeah, you nailed it. Writing a whole program with purely functional constructs is a little mind bending, since procedurally fundamental things like "printf" don't really exist. But that's just something that's much easier to do procedurally; it's hard for everyone, and there's no real secret to understanding it.
The important thing to remember is that languages don't have just one paradigm. An imperative language with first-class functions (as most high-level scripting languages have) is functional, just not "as" functional as, say, Haskell. You can use functional concepts in a language which isn't purely functional, just like you can use OO concepts in a language which isn't purely OO.
The good news is it sounds like you get functional programming much more than you thought, and you've definitely got the right attitude towards learning.
As long as you're open to being corrected, and honest about the limits of your knowledge, there's nothing wrong with trying to teach something you don't fully understand yourself. Teaching is one of the best ways to learn. Keep it up :)
My understanding is that most programmers that have a background primarily working with non-functional languages have a challenging time initially grasping the concepts of functional programming.
I'd guess that "most programmers that have a background primarily working with non-functional languages" could just be shortened to "most programmers". Take a look at any of the "language ranking" pages around and you'll find that they're all dominated by imperative/procedural languages.
However, I would guess that a programmer that learns a functional programming style early on would probably have very little difficulty understanding non-functional constructs.
You're right; unfortunately, it seems that most CS curriculums these days just rush people through some basic programming classes in Java/Python (maybe C++) then through a few more "upper level" electives while just skimming over the algorithmic and data structures stuff that FP is most useful for.
I'd argue that the algorithmic / data structures material (maybe with an intro to some FP language mixed in) is much more important than those elective classes, because the elective stuff is much easier to pick up later on (as needed), while someone who doesn't know their algorithms could spend a whole career writing buggy, slow code because of it.
I'm not expert enough to call you out on this, but isn't "function", the way it's used in "functional programming", working from a different and more strict definition of the word "function" that (say) a C programmer is used to? I don't know that you're wrong about this summary of FP, but it doesn't smell right to me.
That's about right. A "function" in functional programming is supposed to be just like the functions you remember from grade-school algebra class, e.g.,
f(x) = 2x + 5
If you look at that function, you'll notice that for any given value of 'x', the function always produces the same output value. For example, no matter how many times you try it, plugging in 3 for 'x' always returns 11. This means that f(x) is a "pure" function.
The only difference between the trivial example with f(x) above, and say, Haskell, is that the functions you're working with in Haskell are much more complicated. Boil it down though, and they're still pure, mathematical functions nonetheless.
Now, you can (should?) write purely functional programs in C if you follow the same principals. The main difference is that C doesn't force you do write your code this way, and since writing purely functional code can be a bit tedious, most people don't.
This leads to impure functions in your code, like when you read a file from disk -- if the file is there, the function does one thing; if not, it may do something else (like crash). Since the output of an impure function can vary depending on when/where/why/how it's executed, it can be much harder to find bugs in it, since the code may compile and run just fine until the moment it doesn't.
Anyway, that's the basic rundown on FP. I'm not an FP expert, so if I've missed anything, someone please correct me.
It depends. A C function is actually a procedure: a list of statements that have some effect on the computer, and then (maybe) shove some return value through the stack at the end. A function in languages like Clean or Haskell or Clojure or Agda or Coq can only return values, and have no effect on the machine (like mutating memory). Of course, this construct is used only as a way to express ideas. The notion of a function that has no other effect on the machine is actually a lie. The time it takes to evaluate the function is a real effect. So is the memory it uses. It's not a perfect abstraction (none are) but for many types of problems, pure functions can work as a tool to help a programmer.
I believe there have been functional programming contests where the language used by the winners was the functional subset of C, which as you would expect includes C functions.
But the term "FP" is as much about freedom from side effects, lambdas, currying, and sometimes lazy evaluation as it is about the superficially-similar functions in a typical imperative language.
Like you said, functional programming isn't hard, but I think the problem is that learning a completely new language with an unfamiliar syntax and abstractions is hard, and trying to apply functional programming techniques in most current mainstream languages is equally hard.
The fundamental language feature that makes true functional programming possible is first class functions, since that allows higher order functions and anonymous functions. The lack of that feature in most mainstream languages is why functional programming feels so foreign to most programmers. Sure, you can write functions without side effects, but making good use of them without polluting your namespace, explicitly passing around function pointers, or having lots of extra boilerplate code lying around is difficult in a lot of languages.
That's constantly changing though. I think as more languages start adding support for higher order functions, even established languages like C++ and Java, we'll see more and more people using a functional style and less nonsense discussion about how "hard" it is, because it really isn't hard at all. Already, you see bits and pieces of functional Javascript code littered all over the Internet on a regular basis.
In fact, I'm willing to bet that at some point in the future, functional programming techniques be considered easier and more natural than a purely imperative approach, simply because more programmers will have encountered it sooner in their programming careers and made effective use of it. It'll be an everyday occurrence to meet a programmer who uses anonymous functions for callbacks and commonly makes use of fold, reduce, and map instead of explicit loops and state variables.
Meanwhile, meeting someone who knows what a pointer is or even how to manage heap memory will be a one in twenty event, and chances are that person will be an embedded developer who also knows how to write interrupt handlers and even a custom, deterministic memory allocator for real time applications.
