4 ms·

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,

by tumult 15y ago

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.

tptacek 15y ago
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.
- tumult 15y ago
  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. Sorry, typed this on a phone, hard to edit.
- profquail 15y ago
  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.
- deleted 15y ago
  [deleted]
- thurn 15y ago
  I agree. Minimizing state and side effects are at least as core to functional programming as "you should use lots of functions."
- marshray 15y ago
  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.
Spyro7 15y ago
"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: * http://en.wikipedia.org/wiki/Side_effect_(computer_science) http://en.wikipedia.org/wiki/Side_effect_(computer_science) * http://learnyouahaskell.com/introduction#so-whats-haskell http://learnyouahaskell.com/introduction#so-whats-haskell 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.
- Cushman 15y ago
  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.
  - Spyro7 15y ago
jodoherty 15y ago
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.

by tumult 15y ago

tptacek 15y ago

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.

tumult 15y ago
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. Sorry, typed this on a phone, hard to edit.
profquail 15y ago
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.
deleted 15y ago
[deleted]
thurn 15y ago
I agree. Minimizing state and side effects are at least as core to functional programming as "you should use lots of functions."
marshray 15y ago
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.

Spyro7 15y ago

"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: * http://en.wikipedia.org/wiki/Side_effect_(computer_science) http://en.wikipedia.org/wiki/Side_effect_(computer_science) * http://learnyouahaskell.com/introduction#so-whats-haskell http://learnyouahaskell.com/introduction#so-whats-haskell 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.

Cushman 15y ago
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.
- Spyro7 15y ago

jodoherty 15y ago

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.