10 ms·

Except that there is a real advantage to using pure functional programming; being able to easily prove theorems about your code and understand different compone

Except that there is a real advantage to using pure functional programming; being able to easily prove theorems about your code and understand different components in isolation. There is a reason why the majority of proof assistants are implemented as functional languages. Most functional languages even give you ways of modelling imperative code (e.g. monads) in a way which hardly sacrifices expressiveness. The real problem with OOP is not that it forces you to do things a particular way, it's that what's new about it (privileging the first argument of each procedure, inheritance, lots of hidden mutable state) is bad, and what's good about it (encapsulation, polymorphism) is not new.

overgard 10y ago
There are things that are painful to express in a pure functional language. I'll give you an example: rasterize a triangle to a mutable buffer. (An inherently mutable and stateful algorithm). You can certainly do this in a purely functional language, but I doubt it will be any clearer or more performant than its procedural C counterpart. I think pure functional programming is super useful in other contexts, for instance, a compiler. I'm weary of people suggesting that a specific school of thought is universally applicable, though.
- MaulingMonkey 10y ago
  While I agree, within the same context, I want to point out that right next to rasterization you have shaders, which are a poster child for functional programming. A vertex shader just transforms an input vertex (and some other inputs) into an output vertex, and a fragment shader just transforms an input fragment (and some other inputs) into an output fragment. This is done at a scale so massively parallel that we have dedicated hardware for it, because your CPU doesn't have enough parallelism. Sure, HLSL and GLSL are locally procedural. The most recent fancy versions ofo them even allow for some shared state mutation within a thread wave, useful for certain niche uses. But in in their traditional contexts? I find even local mutation for most use cases to merely be a source of bugs and obfuscation via poor naming. And most of the built-in functions are pure.
  - VladimirGolovin 10y ago
    > Sure, HLSL and GLSL are locally procedural. Just wanted to add that shaders lend themselves very well to the functional / dataflow paradigm. There are numerous visual node-based shader editing tools where you construct shaders from blocks, which essentially are pure functions.
lispm 10y ago
The real disadvantage of pure functional programming is that it is notoriously difficult to use and thus only very few programs outside specialized domains are written in them. For example I would guess that in a typical enterprise (say, a manufacturing company), 0.0001% of the software is written in a pure functional language. Things OO languages 'force' us seem to be relatively easy to use: sending a message to a certain object, thinking in categories (elephants, houses, chairs, moveable objects, ...), state (position, speed, size, shape),... Thus it is not surprising that the overwhelming majority of software written in the last 10 years has been written in OO languages.
- whateveracct 10y ago
  I work in a group of teams that is mostly new college grads and nobody has trouble writing pure FP business logic in Scala. We don't go as far as doing pure FP for all effects though (although we are starting to do that more as well) If we can do it, so can everyone else ;)
  - Apocryphon 10y ago
    They come Berkeley and MIT, colleges that are renowned for teaching functional languages in their intro to programming courses, don't they.
    - whateveracct 10y ago
      Nope we mostly come from either state schools of our original residence or small liberal arts schools. I know of two hires from those schools, and I am the one who taught them pure typed FP. I'm the only one who came in knowing pure FP at all and I didn't learn it via classes.
    - seanmcdirmid 10y ago
      That's a bit biased. Berkeley and MIT students are pretty pragmatic, and are not typically FP enthusiasts (as in, many aren't even if some are on their own accord). Many European universities have more of an affinity to FP, comparatively speaking.
l_dopa 10y ago
"Pure" functional programming isn't the only alternative. There's plenty of benefit from just using a language with reasonable semantics (e.g. ML) that doesn't force you to contort simple programs into bizarre "OO" patterns. Whether or not you want your language to enforce segregating (most) effects is a separate issue, about which reasonable people can disagree.
- eutectic 10y ago
  Agreed. And for the record, I also like imperative languages (e.g. C), where appropriate.
seanmcdirmid 10y ago
> Except that there is a real advantage to using pure functional programming; being able to easily prove theorems about your code and understand different components in isolation. And how often does that occur in practice for most of the programs people write? Even the most hardcore Haskell programmer isn't going around proving theorems about their modules beyond what the type system can provide for free (and that is true of statically typed OO also). > The real problem with OOP is not that it forces you to do things a particular way, it's that what's new about it (privileging the first argument of each procedure, inheritance, lots of hidden mutable state) is bad, and what's good about it (encapsulation, polymorphism) is not new. Encapsulated state has its own benefits and drawbacks (having explicit unencapsulated state limits reuse as they are reflected in type signatures), and anyways, is not unique to OOP (any commonly used language sans Haskell supports encapsulated state). The only way to get encapsulated state in Haskell is World -> World, which would pollute all function signatures it buried through (there is some good work in parametric effect systems, but its still early). OOP also is not very new, being formed from the culmination have patterns used in the 70s, and is about the same vintage as FP.
- sbmassey 10y ago
  Any sort of thinking about what the code does or does not do is essentially proving theorems about it, is it not? It seems to me one does that all the time when debugging.
  - seanmcdirmid 10y ago
    I don't think about coding that way. To me debugging is more like a Sherlock Holmes investigation rather than a formal theorem proving process. I guess we maybe work on different kinds of programs.
    - l_dopa 10y ago
      You're still, at some point, simulating the steps of some abstract machine in your head to understand what the debugger is telling you. The simplest case is replacing an expression with its value, given an environment of lexical bindings that are apprent from the source program. Not much investigation necessary. That's FP. For OO code, you just need to keep track of a lot more context: the state of the receiver of the currently executing method, its heirarchy of parent classes, the runtime class of each object because late binding is pervasive. Of course you can write code that doesn't use any OO features, but the languages clearly aren't designed for it. See: any number of "functional C++" articles. And, of course, you can get the same kind of highly dynamic behavior in FP languages by explicitly using open recursion, higher-order state and hiding everything behind existentials. But very few codebases do that because the vast, vast majority of the time just one of these features is enough to solve a problem.
tmptmp 10y ago
>>Except that there is a real advantage to using pure functional programming; being able to easily prove theorems about your code and understand different components in isolation. How much of the Haskell (a pure FP language) library code is formally proved? Just curious. Also I wonder, if code like xmonad can be proved at all.
- eru 10y ago
  XMonad comes with quite a few QuickCheck properties. See https://donsbot.wordpress.com/2007/05/17/roll-your-own-window-manager-tracking-focus-with-a-zipper/ https://donsbot.wordpress.com/2007/05/17/roll-your-own-windo... and https://donsbot.wordpress.com/2007/05/01/roll-your-own-window-manager-part-1-defining-and-testing-a-model/ https://donsbot.wordpress.com/2007/05/01/roll-your-own-windo... for some readable introduction. One might consider proving the properties instead of just checking them with a few thousand random examples.
jonnybgood 10y ago
> pure functional programming; being able to easily prove theorems about your code I believe you're referring to a type system. That is different. There is little about functional programming that allows you to easily prove theorems about your code.
- iainmerrick 10y ago
  No, FP is great for analyzing your code! Internal state and side effects are the main things that make code hard to analyze, and it's exactly those things that FP avoids.
  - jonnybgood 10y ago
    How is that related to easily proving theorems about the code?
    - eru 10y ago
      It's easier to prove stuff about simpler code.
smsm42 10y ago
For some values of "pure", sure. The problem is, keeping this level of purity - that allows to strictly prove theorems about your code - is very hard. And most real code would compromise, while still pretending that they are pure and their results are proven. That's not a road to a good place. I seriously doubt there's much industrial code made in functional languages that has been proven to be correct. And I'm not talking about halting problem, etc., not that deep, I mean just writing a spec of what the code would do in every situation and proving that indeed it does that. I haven't seen any. Maybe in theory it'd be possible, in practice, it doesn't happen. In fact, if that happened frequently, unit testing in functional environments would not exist - you don't need to test what you can prove to be correct. In reality, it very well exists. > There is a reason why the majority of proof assistants are implemented as functional languages. It's not the direction you need to prove though. Surely, it is easier to express things we can prove in functional terms. The challenge, however, is to see if it's easy to prove that code follows certain specs when that spec is not specially fit for being expressed in functional terms. > it's that what's new about it (privileging the first argument of each procedure, inheritance, lots of hidden mutable state) is bad Hidden mutable state is not mandated by OOP in any way. And arguing that inheritance and special arguments are bad would require some more than just saying "it's bad". > and what's good about it (encapsulation, polymorphism) is not new So what? Where's the problem if it's not new? Letters we're using aren't new, so aren't numbers, still serve us well. Not everything good must be new, if it's old and still good - even better. I fail to see how "it's not new" is any meaningful criticism - it's like criticizing a math library that the result it returns for 2+2 is not new. Why would we want it to be new?
klibertp 10y ago
> Except that there is a real advantage to using pure functional programming That's only true for certain values of "real". In real "real" terms, the advantage is purely virtual - even very simple programs require hundreds of pages of proof. In effect, formal proofs are almost never done in real reality and the "advantage" remains purely virtual. > what's new about it (privileging the first argument of each procedure Multimethods, CLOS, Dylan? > inheritance Don't use it if you don't like it that much... > lots of hidden mutable state It's not hidden, it's encapsulated. Do you know Smalltalk? If not, you should try learning it; I liked Pharo very much. Look at Morphic, work with it for a while and you'll see the difference. You can also try devising purely functional equivalent of Morphic while you're at it (good luck!).
norea-armozel 10y ago
The problem I have with the functional paradigm is that it's couched in the idea that all problems can be reduced to same kind of algorithms. It's better to accept that all problems can be reduced to some king of algorithm whether or not it follows neatly along with the functional paradigm. That's why OOD sometimes works better for some problems over others and vice versa. Plus, I think not all functional programming languages are equal in this regard. I have a bias toward Ocaml since it's fairly easy to get into it without having to abandon previous knowledge. You can learn Ocaml even if most of your professional life you've written code in C. Whereas Haskell you have to unlearn lots of old idioms which worked well in C to get a basic comprehension of Haskell. So, just picking up Haskell because you think a specific problem is easier within the functional paradigm is a bad idea IMO. Unless you have plenty of time to learn then go for broke.
- dmbarbour 10y ago
  I don't believe FP has any strong assumption that all problems reduce to the same kind of algorithm. Rather, different kinds of algorithm are modeled typefully - e.g. with various monads or abstract data types. As you mention, pure FP does require learning different idioms. OTOH, a lot of those idioms can be applied effectively to imperative programming, so learning isn't necessarily a wasted effort even if you spend most of your time wrist deep in C code.
  - norea-armozel 10y ago
    I see you point. I just think there's better options if you're going to approach FP. I think picking a language that's flexible about it's enforcement is one approach. I think I've learned more from Common LISP and Ocaml about FP than I ever did from Haskell. It's not to say Haskell is a bad language, but it's just not one you can pick up in a day.

overgard 10y ago

There are things that are painful to express in a pure functional language. I'll give you an example: rasterize a triangle to a mutable buffer. (An inherently mutable and stateful algorithm). You can certainly do this in a purely functional language, but I doubt it will be any clearer or more performant than its procedural C counterpart. I think pure functional programming is super useful in other contexts, for instance, a compiler. I'm weary of people suggesting that a specific school of thought is universally applicable, though.

MaulingMonkey 10y ago
While I agree, within the same context, I want to point out that right next to rasterization you have shaders, which are a poster child for functional programming. A vertex shader just transforms an input vertex (and some other inputs) into an output vertex, and a fragment shader just transforms an input fragment (and some other inputs) into an output fragment. This is done at a scale so massively parallel that we have dedicated hardware for it, because your CPU doesn't have enough parallelism. Sure, HLSL and GLSL are locally procedural. The most recent fancy versions ofo them even allow for some shared state mutation within a thread wave, useful for certain niche uses. But in in their traditional contexts? I find even local mutation for most use cases to merely be a source of bugs and obfuscation via poor naming. And most of the built-in functions are pure.
- VladimirGolovin 10y ago
  > Sure, HLSL and GLSL are locally procedural. Just wanted to add that shaders lend themselves very well to the functional / dataflow paradigm. There are numerous visual node-based shader editing tools where you construct shaders from blocks, which essentially are pure functions.

lispm 10y ago

The real disadvantage of pure functional programming is that it is notoriously difficult to use and thus only very few programs outside specialized domains are written in them. For example I would guess that in a typical enterprise (say, a manufacturing company), 0.0001% of the software is written in a pure functional language. Things OO languages 'force' us seem to be relatively easy to use: sending a message to a certain object, thinking in categories (elephants, houses, chairs, moveable objects, ...), state (position, speed, size, shape),... Thus it is not surprising that the overwhelming majority of software written in the last 10 years has been written in OO languages.

whateveracct 10y ago
I work in a group of teams that is mostly new college grads and nobody has trouble writing pure FP business logic in Scala. We don't go as far as doing pure FP for all effects though (although we are starting to do that more as well) If we can do it, so can everyone else ;)
- Apocryphon 10y ago
  They come Berkeley and MIT, colleges that are renowned for teaching functional languages in their intro to programming courses, don't they.
  - whateveracct 10y ago
    Nope we mostly come from either state schools of our original residence or small liberal arts schools. I know of two hires from those schools, and I am the one who taught them pure typed FP. I'm the only one who came in knowing pure FP at all and I didn't learn it via classes.
  - seanmcdirmid 10y ago
    That's a bit biased. Berkeley and MIT students are pretty pragmatic, and are not typically FP enthusiasts (as in, many aren't even if some are on their own accord). Many European universities have more of an affinity to FP, comparatively speaking.

l_dopa 10y ago

"Pure" functional programming isn't the only alternative. There's plenty of benefit from just using a language with reasonable semantics (e.g. ML) that doesn't force you to contort simple programs into bizarre "OO" patterns. Whether or not you want your language to enforce segregating (most) effects is a separate issue, about which reasonable people can disagree.

eutectic 10y ago
Agreed. And for the record, I also like imperative languages (e.g. C), where appropriate.

seanmcdirmid 10y ago

> Except that there is a real advantage to using pure functional programming; being able to easily prove theorems about your code and understand different components in isolation. And how often does that occur in practice for most of the programs people write? Even the most hardcore Haskell programmer isn't going around proving theorems about their modules beyond what the type system can provide for free (and that is true of statically typed OO also). > The real problem with OOP is not that it forces you to do things a particular way, it's that what's new about it (privileging the first argument of each procedure, inheritance, lots of hidden mutable state) is bad, and what's good about it (encapsulation, polymorphism) is not new. Encapsulated state has its own benefits and drawbacks (having explicit unencapsulated state limits reuse as they are reflected in type signatures), and anyways, is not unique to OOP (any commonly used language sans Haskell supports encapsulated state). The only way to get encapsulated state in Haskell is World -> World, which would pollute all function signatures it buried through (there is some good work in parametric effect systems, but its still early). OOP also is not very new, being formed from the culmination have patterns used in the 70s, and is about the same vintage as FP.

sbmassey 10y ago
Any sort of thinking about what the code does or does not do is essentially proving theorems about it, is it not? It seems to me one does that all the time when debugging.
- seanmcdirmid 10y ago
  I don't think about coding that way. To me debugging is more like a Sherlock Holmes investigation rather than a formal theorem proving process. I guess we maybe work on different kinds of programs.
  - l_dopa 10y ago
    You're still, at some point, simulating the steps of some abstract machine in your head to understand what the debugger is telling you. The simplest case is replacing an expression with its value, given an environment of lexical bindings that are apprent from the source program. Not much investigation necessary. That's FP. For OO code, you just need to keep track of a lot more context: the state of the receiver of the currently executing method, its heirarchy of parent classes, the runtime class of each object because late binding is pervasive. Of course you can write code that doesn't use any OO features, but the languages clearly aren't designed for it. See: any number of "functional C++" articles. And, of course, you can get the same kind of highly dynamic behavior in FP languages by explicitly using open recursion, higher-order state and hiding everything behind existentials. But very few codebases do that because the vast, vast majority of the time just one of these features is enough to solve a problem.

tmptmp 10y ago

>>Except that there is a real advantage to using pure functional programming; being able to easily prove theorems about your code and understand different components in isolation. How much of the Haskell (a pure FP language) library code is formally proved? Just curious. Also I wonder, if code like xmonad can be proved at all.

eru 10y ago
XMonad comes with quite a few QuickCheck properties. See https://donsbot.wordpress.com/2007/05/17/roll-your-own-window-manager-tracking-focus-with-a-zipper/ https://donsbot.wordpress.com/2007/05/17/roll-your-own-windo... and https://donsbot.wordpress.com/2007/05/01/roll-your-own-window-manager-part-1-defining-and-testing-a-model/ https://donsbot.wordpress.com/2007/05/01/roll-your-own-windo... for some readable introduction. One might consider proving the properties instead of just checking them with a few thousand random examples.

jonnybgood 10y ago

> pure functional programming; being able to easily prove theorems about your code I believe you're referring to a type system. That is different. There is little about functional programming that allows you to easily prove theorems about your code.

iainmerrick 10y ago
No, FP is great for analyzing your code! Internal state and side effects are the main things that make code hard to analyze, and it's exactly those things that FP avoids.
- jonnybgood 10y ago
  How is that related to easily proving theorems about the code?
  - eru 10y ago
    It's easier to prove stuff about simpler code.

smsm42 10y ago

For some values of "pure", sure. The problem is, keeping this level of purity - that allows to strictly prove theorems about your code - is very hard. And most real code would compromise, while still pretending that they are pure and their results are proven. That's not a road to a good place. I seriously doubt there's much industrial code made in functional languages that has been proven to be correct. And I'm not talking about halting problem, etc., not that deep, I mean just writing a spec of what the code would do in every situation and proving that indeed it does that. I haven't seen any. Maybe in theory it'd be possible, in practice, it doesn't happen. In fact, if that happened frequently, unit testing in functional environments would not exist - you don't need to test what you can prove to be correct. In reality, it very well exists. > There is a reason why the majority of proof assistants are implemented as functional languages. It's not the direction you need to prove though. Surely, it is easier to express things we can prove in functional terms. The challenge, however, is to see if it's easy to prove that code follows certain specs when that spec is not specially fit for being expressed in functional terms. > it's that what's new about it (privileging the first argument of each procedure, inheritance, lots of hidden mutable state) is bad Hidden mutable state is not mandated by OOP in any way. And arguing that inheritance and special arguments are bad would require some more than just saying "it's bad". > and what's good about it (encapsulation, polymorphism) is not new So what? Where's the problem if it's not new? Letters we're using aren't new, so aren't numbers, still serve us well. Not everything good must be new, if it's old and still good - even better. I fail to see how "it's not new" is any meaningful criticism - it's like criticizing a math library that the result it returns for 2+2 is not new. Why would we want it to be new?

klibertp 10y ago

> Except that there is a real advantage to using pure functional programming That's only true for certain values of "real". In real "real" terms, the advantage is purely virtual - even very simple programs require hundreds of pages of proof. In effect, formal proofs are almost never done in real reality and the "advantage" remains purely virtual. > what's new about it (privileging the first argument of each procedure Multimethods, CLOS, Dylan? > inheritance Don't use it if you don't like it that much... > lots of hidden mutable state It's not hidden, it's encapsulated. Do you know Smalltalk? If not, you should try learning it; I liked Pharo very much. Look at Morphic, work with it for a while and you'll see the difference. You can also try devising purely functional equivalent of Morphic while you're at it (good luck!).

norea-armozel 10y ago

The problem I have with the functional paradigm is that it's couched in the idea that all problems can be reduced to same kind of algorithms. It's better to accept that all problems can be reduced to some king of algorithm whether or not it follows neatly along with the functional paradigm. That's why OOD sometimes works better for some problems over others and vice versa. Plus, I think not all functional programming languages are equal in this regard. I have a bias toward Ocaml since it's fairly easy to get into it without having to abandon previous knowledge. You can learn Ocaml even if most of your professional life you've written code in C. Whereas Haskell you have to unlearn lots of old idioms which worked well in C to get a basic comprehension of Haskell. So, just picking up Haskell because you think a specific problem is easier within the functional paradigm is a bad idea IMO. Unless you have plenty of time to learn then go for broke.

dmbarbour 10y ago
I don't believe FP has any strong assumption that all problems reduce to the same kind of algorithm. Rather, different kinds of algorithm are modeled typefully - e.g. with various monads or abstract data types. As you mention, pure FP does require learning different idioms. OTOH, a lot of those idioms can be applied effectively to imperative programming, so learning isn't necessarily a wasted effort even if you spend most of your time wrist deep in C code.
- norea-armozel 10y ago
  I see you point. I just think there's better options if you're going to approach FP. I think picking a language that's flexible about it's enforcement is one approach. I think I've learned more from Common LISP and Ocaml about FP than I ever did from Haskell. It's not to say Haskell is a bad language, but it's just not one you can pick up in a day.