7 ms·

Some ideas that are ubiquitous within functional programming are certainly on the rise, for example: - functions as first-class entities in programming languag

Some ideas that are ubiquitous within functional programming are certainly on the rise, for example: - functions as first-class entities in programming languages, and consequences like higher-order functions and partial evaluation; - a common set of basic data structures (set, sequence, dictionary, tree, etc.) and generalised operations for manipulating and combining them (map, filter, reduce, intersection, union, zip, convert a tree to a sequence breadth-first or depth-first, etc.); - a more declarative programming style, writing specifications rather than instructions; - a programming style that emphasizes the data flow more than the control flow. I see these as distinct, though certainly not independent, concepts. I’m not sure whether functional programming itself is really on the rise, not to the extent of becoming a common approach in the mainstream programming world any time soon. I don’t think we’ve figured out how to cope with effectful systems and the real world having a time dimension very well yet. (I don’t think we’ve figured it out very well in imperative programming yet either, but the weakness is less damaging there because there is an implicit time dimension whether you want it or not.)

rayiner 14y ago
What is your third point if not functional programming?
- ufo 14y ago
  declarative vs imperative is kind of a subjective thing but functional programming is not the only way to do declarative programming (logic programming and SQL are two examples that come to mind)
- Chris_Newton 14y ago
  Functional programming, by definition, is expressing a program as a function to be evaluated. That implies that, at least to some extent, all functional programs are written in a declarative style. However, we use a declarative style for other kinds of language as well: Prolog, SQL and CSS are three very different examples, none of which is a functional programming language similar to ML or Haskell or Clojure.
  - rayiner 14y ago
    I don't think there is one uniform definition of functional programming. It's a vague characteristic of a language in the same sense as "object oriented."
    - jberryman 14y ago
      > I don't think there is one uniform definition of functional programming. Only because people are lazy in their words and thinking.
      - PnuklOEvolu 14y ago
        I agree people never evaluate the function early enough, glad I'm not one.
SilasX 14y ago
I tend to agree. It's a lot like with object-oriented programming: "Hey, this is so awesome! You can encapsulate data, have well-defined interfaces, enforce separation-of-concerns, and, and ..." --> Er, I've always been able to do all that, I just didn't call it OO. That said, I'm still doing what I can to assimilate those techniques and understand where to apply them.
jekor 14y ago
Yes, a lot of these are characteristic of functional programming, and many are being adopted. But I think that the idea of using mathematically pure functions---programming without side effects or mutation---is a/the key idea behind functional programming. And it's this purity that divides the communities. You can take high-order functions and folds and put them in just about any language, and you could put OOP concepts like subtype polymorphism into functional languages. But there's a line that neither class of languages can cross over, and that's mutable state. I know that some developers are beginning to lean in the direction of functional programming by relying on const annotations and adopting a functional style. And I'm very excited and hopeful about the overall trend.
- Chris_Newton 14y ago
  But I think that the idea of using mathematically pure functions---programming without side effects or mutation---is a/the key idea behind functional programming. Indeed, and it is either a blessing or a curse depending on what kind of software you’re trying to write and the sort of situations you’re trying to model. For most of the programming work I’ve ever done myself, what I’d really like to use is languages that do have concepts like time and side effects, because they’re very useful, but which only use them in controlled ways and when the programmer actually wants them. I’ve often wondered whether such ideas might be elevated to first class concepts within future programming languages, complete with their own rules and specified interactions, just as today we have variables and types and functions, and a language will prevent errors like calling a function with only two values when it expects three or trying to use the value 20 where a string is expected. For now, I’m hoping that functional programming, in the pure sense, will raise awareness of the potential benefits of controlling side effects rather than allowing them more-or-less arbitrarily as most imperative languages today do. With a bit of luck, the generation of industrial languages in a few years will then borrow ideas that stand the test of time from today’s research into type/effect systems, software transactional memory, and so on, and perhaps we can have something of the best of both worlds.
  - tikhonj 14y ago
    What you describe is exactly what Haskell does. You have pure functions by default, but you can have mutable state wherever you want it--it is just constrained to a particular scope by the type system. That is, you can use mutable references, mutable arrays and so on all you want inside a computation, and the compiler will guarantee that none of these references leak outside their scope. Haskell accomplishes this with "state threads" (ST[1]). [1]: http://hackage.haskell.org/packages/archive/base/4.2.0.1/doc/html/Control-Monad-ST.html http://hackage.haskell.org/packages/archive/base/4.2.0.1/doc... Similarly, Haskell has the IO type for containing any side effects at all. This type, as the name implies, can have not only mutable state but also arbitrary I/O--really anything you like. This has some very nice advantages: for example, you can create your own wrapper around the IO type which only exposes some IO operations. You could use this for ensuring that plugins can't do things like delete files, for example. (This is one of the example use cases for Safe Haskell[2], which is worth reading about.) [2]: http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/safe-haskell.html#uses-of-safe-haskell http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/safe-... You can even reify time explicitly, rather than modelling it implicitly with mutable state. This leads to functional reactive programming (FRP[3]), a new and more declarative way to write things like UIs. FRP replaces event and callback oriented programming, fixing much of the spaghetti code common to most UI frameworks. [3]: http://stackoverflow.com/questions/1028250/what-is-functional-reactive-programming http://stackoverflow.com/questions/1028250/what-is-functiona... Really, I think "purely functional" is a very unfortunate term for Haskell from a marketing standpoint. "Purely functional" does not mean that we cannot have side-effects, or mutation, or what have you. It just means that side-effects aren't everywhere by default, and don't implicitly permute your otherwise pretty code.
jarrett 14y ago
To me, the future will most likely be languages that allows both functional and OO styles to interoperate. Programmers will pick the style or mix of styles most appropriate to the particular sub-problem they're solving. We already do this with some of our high-level languages like Ruby and JavaScript. With these, we have higher-order functions, map and friends, closures, etc.. But we also have our familiar OO constructs. Almost every program I write in these languages uses all of the above, not just the functional or OO subset. I so far have not seen any practical advantage in going purely functional. I've tried it a number of times, but I always find that the real-world programs I write need to be stateful. Yes, functional languages do of course have facilities for handling state, but they always seem super awkward, especially compared to the elegance of state handling in OOP. For example, consider a simple, 1980s-style arcade game. There are a bunch of entities on screen, each with attributes like velocity, health, etc.. How do you maintain this state in a purely functional language? I've seen various suggestions, but they all seem to boil down to setting up a game loop with tail recursion, and then passing some game state object(s) to this function on each recursion. Doesn't sound so bad, but what happens when you have a bunch of different types of entities? E.g. player characters, monsters, projectiles, pickups, etc.. Well, every time you add a new type of entity (or a new data structure to index existing entities), you could add another parameter to the main game loop. But that gets crazy pretty fast. So then you have the clever idea to maintain one massive game state hash, and just pass that around. But wait, now you've lost something key to functional programming: You can no longer tell exactly what aspects of the game state a function is updating, because it just receives and returns the big game state hash. You don't really know what data your functions depend on our modify. Effectively, it's almost like you're using global variables. I'm using games as an example here, but the same sorts of problems come up with almost any stateful application. This is why I prefer languages that allow you to seamlessly mix functional and OO styles. They give you many of the benefits of FP without forcing you to deal with the difficulties described above.
- eru 14y ago
  > Well, every time you add a new type of entity (or a new data structure to index existing entities), you could add another parameter to the main game loop. But that gets crazy pretty fast. So then you have the clever idea to maintain one massive game state hash, and just pass that around. But wait, now you've lost something key to functional programming: You can no longer tell exactly what aspects of the game state a function is updating, because it just receives and returns the big game state hash. You don't really know what data your functions depend on our modify. Effectively, it's almost like you're using global variables. You have to explain how that works. By "hash", do you mean a finite map (or dict, in Python terms)? In Haskell you can use a state monad for these game loops. Some game industry insiders (see http://lambda-the-ultimate.org/node/1277 http://lambda-the-ultimate.org/node/1277) argue explicitly for this style.

rayiner 14y ago

What is your third point if not functional programming?

ufo 14y ago
declarative vs imperative is kind of a subjective thing but functional programming is not the only way to do declarative programming (logic programming and SQL are two examples that come to mind)
Chris_Newton 14y ago
Functional programming, by definition, is expressing a program as a function to be evaluated. That implies that, at least to some extent, all functional programs are written in a declarative style. However, we use a declarative style for other kinds of language as well: Prolog, SQL and CSS are three very different examples, none of which is a functional programming language similar to ML or Haskell or Clojure.
- rayiner 14y ago
  I don't think there is one uniform definition of functional programming. It's a vague characteristic of a language in the same sense as "object oriented."
  - jberryman 14y ago
    > I don't think there is one uniform definition of functional programming. Only because people are lazy in their words and thinking.
    - PnuklOEvolu 14y ago
      I agree people never evaluate the function early enough, glad I'm not one.

SilasX 14y ago

I tend to agree. It's a lot like with object-oriented programming: "Hey, this is so awesome! You can encapsulate data, have well-defined interfaces, enforce separation-of-concerns, and, and ..." --> Er, I've always been able to do all that, I just didn't call it OO. That said, I'm still doing what I can to assimilate those techniques and understand where to apply them.

jekor 14y ago

Yes, a lot of these are characteristic of functional programming, and many are being adopted. But I think that the idea of using mathematically pure functions---programming without side effects or mutation---is a/the key idea behind functional programming. And it's this purity that divides the communities. You can take high-order functions and folds and put them in just about any language, and you could put OOP concepts like subtype polymorphism into functional languages. But there's a line that neither class of languages can cross over, and that's mutable state. I know that some developers are beginning to lean in the direction of functional programming by relying on const annotations and adopting a functional style. And I'm very excited and hopeful about the overall trend.

Chris_Newton 14y ago
But I think that the idea of using mathematically pure functions---programming without side effects or mutation---is a/the key idea behind functional programming. Indeed, and it is either a blessing or a curse depending on what kind of software you’re trying to write and the sort of situations you’re trying to model. For most of the programming work I’ve ever done myself, what I’d really like to use is languages that do have concepts like time and side effects, because they’re very useful, but which only use them in controlled ways and when the programmer actually wants them. I’ve often wondered whether such ideas might be elevated to first class concepts within future programming languages, complete with their own rules and specified interactions, just as today we have variables and types and functions, and a language will prevent errors like calling a function with only two values when it expects three or trying to use the value 20 where a string is expected. For now, I’m hoping that functional programming, in the pure sense, will raise awareness of the potential benefits of controlling side effects rather than allowing them more-or-less arbitrarily as most imperative languages today do. With a bit of luck, the generation of industrial languages in a few years will then borrow ideas that stand the test of time from today’s research into type/effect systems, software transactional memory, and so on, and perhaps we can have something of the best of both worlds.
- tikhonj 14y ago
  What you describe is exactly what Haskell does. You have pure functions by default, but you can have mutable state wherever you want it--it is just constrained to a particular scope by the type system. That is, you can use mutable references, mutable arrays and so on all you want inside a computation, and the compiler will guarantee that none of these references leak outside their scope. Haskell accomplishes this with "state threads" (ST[1]). [1]: http://hackage.haskell.org/packages/archive/base/4.2.0.1/doc/html/Control-Monad-ST.html http://hackage.haskell.org/packages/archive/base/4.2.0.1/doc... Similarly, Haskell has the IO type for containing any side effects at all. This type, as the name implies, can have not only mutable state but also arbitrary I/O--really anything you like. This has some very nice advantages: for example, you can create your own wrapper around the IO type which only exposes some IO operations. You could use this for ensuring that plugins can't do things like delete files, for example. (This is one of the example use cases for Safe Haskell[2], which is worth reading about.) [2]: http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/safe-haskell.html#uses-of-safe-haskell http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/safe-... You can even reify time explicitly, rather than modelling it implicitly with mutable state. This leads to functional reactive programming (FRP[3]), a new and more declarative way to write things like UIs. FRP replaces event and callback oriented programming, fixing much of the spaghetti code common to most UI frameworks. [3]: http://stackoverflow.com/questions/1028250/what-is-functional-reactive-programming http://stackoverflow.com/questions/1028250/what-is-functiona... Really, I think "purely functional" is a very unfortunate term for Haskell from a marketing standpoint. "Purely functional" does not mean that we cannot have side-effects, or mutation, or what have you. It just means that side-effects aren't everywhere by default, and don't implicitly permute your otherwise pretty code.

jarrett 14y ago

To me, the future will most likely be languages that allows both functional and OO styles to interoperate. Programmers will pick the style or mix of styles most appropriate to the particular sub-problem they're solving. We already do this with some of our high-level languages like Ruby and JavaScript. With these, we have higher-order functions, map and friends, closures, etc.. But we also have our familiar OO constructs. Almost every program I write in these languages uses all of the above, not just the functional or OO subset. I so far have not seen any practical advantage in going purely functional. I've tried it a number of times, but I always find that the real-world programs I write need to be stateful. Yes, functional languages do of course have facilities for handling state, but they always seem super awkward, especially compared to the elegance of state handling in OOP. For example, consider a simple, 1980s-style arcade game. There are a bunch of entities on screen, each with attributes like velocity, health, etc.. How do you maintain this state in a purely functional language? I've seen various suggestions, but they all seem to boil down to setting up a game loop with tail recursion, and then passing some game state object(s) to this function on each recursion. Doesn't sound so bad, but what happens when you have a bunch of different types of entities? E.g. player characters, monsters, projectiles, pickups, etc.. Well, every time you add a new type of entity (or a new data structure to index existing entities), you could add another parameter to the main game loop. But that gets crazy pretty fast. So then you have the clever idea to maintain one massive game state hash, and just pass that around. But wait, now you've lost something key to functional programming: You can no longer tell exactly what aspects of the game state a function is updating, because it just receives and returns the big game state hash. You don't really know what data your functions depend on our modify. Effectively, it's almost like you're using global variables. I'm using games as an example here, but the same sorts of problems come up with almost any stateful application. This is why I prefer languages that allow you to seamlessly mix functional and OO styles. They give you many of the benefits of FP without forcing you to deal with the difficulties described above.

eru 14y ago
> Well, every time you add a new type of entity (or a new data structure to index existing entities), you could add another parameter to the main game loop. But that gets crazy pretty fast. So then you have the clever idea to maintain one massive game state hash, and just pass that around. But wait, now you've lost something key to functional programming: You can no longer tell exactly what aspects of the game state a function is updating, because it just receives and returns the big game state hash. You don't really know what data your functions depend on our modify. Effectively, it's almost like you're using global variables. You have to explain how that works. By "hash", do you mean a finite map (or dict, in Python terms)? In Haskell you can use a state monad for these game loops. Some game industry insiders (see http://lambda-the-ultimate.org/node/1277 http://lambda-the-ultimate.org/node/1277) argue explicitly for this style.