4 ms·

Functional programming was a fad and it's going out of fashion (again). It gives you rerefential transparency at the expense of real modularity. Real modular

Functional programming was a fad and it's going out of fashion (again). It gives you rerefential transparency at the expense of real modularity. Real modularity can only be achieved through proper separation of concerns. The best way to achieve that is by categorizing system state and system logic and allowing chunks of logic to be colocated with the relevant parts of the system state. This is what OOP excels at. With functional programming, you cannot colocate module logic with module state so you often end up with a large monolithic state store on one side of the system and logic which is completely decoupled and sitting on the opposite side of the system... Then the challenge is to apply functions to various relevant parts of the state to transform it in a referentially transparent way. The modularity problem then comes when you need to make a change to the schema/structure of the state; whenever you change the structure of the state, you need you need to search through your logic to identify all the parts of the logic which depend on that state and update them to work with the new structure. This is a massive problem and leads to what OOP developers call spaghetti code.

sbergot 7y ago
This is like saying non-nullable references are a problem because nullable refs are sometime useful. Nothing prevents you from having state in an haskell application. You just have to be explicit about it. Whether the language ergonomics are better or worse than a language that allows state without an explicit type is another question but your reasoning is questionable.
- cryptica 7y ago
  You can also have pure functions in OOP languages. You can even have a code linter to enforce it as a rule. When discussing programming languages, it's more about what behaviours they encourage rather than what behaviours they support.
  - rowanG077 7y ago
    OOP language aren't explicit in what function is pure. If I'm working on a 10MLoC project and touching hundreds of methods while working I can't lookup the implementation of each one to determine whether they are pure. And no a comment saying they are pure is not sufficient. The above is trivial in FP languages.
    - floatboth 7y ago
      Well, except D, D has a @pure annotation :)
      - rowanG077 7y ago
        D pure function aren't really pure though. They can modify the arguments that are passed in. Great concept otherwise.
  - mrkeen 7y ago
    How do I do this?
moomin 7y ago
I’m guessing you’ve never done any Haskell programming. I don’t know why you think FP people don’t practice separation of concerns (they do), why you can’t put state and the functions that manipulate that state in the same file (you can) or that a type-checker can’t spot all the places you need to modify when you change a data structure (it does). Also, you seem unaware of the real restrictions on modularity caused by eager evaluation.
- cryptica 7y ago
  In that case it is not pure functional programming because you are colocating state with logic. Functions in that file can mutate the state within that file; this means that it's only functionally transparent within that file but not from the outside. If you need to store state inside of that file, then it means that you are using it to affect the behaviour of functions which are exposed to the outside... Also, this approach would be sub-par because you would be constrained to singleton modules. What you described sounds like a Haskell programming anti-pattern. It sounds like a feature which was hacked on top to allow Haskell to emulate OOP languages without actually doing OOP. Also, lazy evaluation is a separate topic. OOP languages also support lazy evaluation.
  - asplake 7y ago
    No. OOP isn't "colocating", it's "encapsulating". FP does it differently, but whatever the paradigm, programmer ergonomics suggest that it would be unsurprising to see definitions of (say) data and functions close together.
  - Legogris 7y ago
    What source code files you happen to put declarations and definitions in has nothing to do with functional purity. Think of it this way: An array append function which adds an element to the input array is not purely functional. An array append function which returns a new array with the new element appended is purely functional. The same function applied to the same input will always return the same value, and won't cause that to break for any other functions. Of course, this makes things such as IO tricky and yo ideally want to minimize and isolate the places where this happens on a lower level. Haskell solves this with monads, which we have seen is a big hurdle for many developers. I personally think Idris's effect system[0] is a lot easier to deal with, but would be curious to see other approaches. [0]: http://docs.idris-lang.org/en/latest/effects/index.html http://docs.idris-lang.org/en/latest/effects/index.html
openfuture 7y ago
A fun quote: Object oriented programming is abstracting over race conditions. What you described is distributed computing, which (you are right) is fashionable. However, each 'computer' in the 'distributed computing' should be purely functional, referentially transparent, etc. Since that make it easier to reason about it as an 'object'. These ideas are just tools for organizing information systems, no need to get too caught up in a label war, even emacs and vim are converging :^)
whateveracct 7y ago
> proper separation of concerns My favorite part of working in Haskell professionally is that my coworkers never use imprecise folk programming terms like this :) Also everything you said just doesn't ring true given my professional experience :)
beders 7y ago
I'm not sure you understand what modularity is all about. There's ample evidence that Functional Programming (esp. with immutable data) gives you a lot of aspects of a 'module' for free. Any function programming language can describe and enforce module boundaries. Some mostly at run-time, but that is A-Ok in my book. I also find it funny you mentioned "large monolithic state" when most enterprise apps try to hide that fact that all your data is in a database (the large monolithic state), by stashing it into objects through some magic ORM...

sbergot 7y ago

This is like saying non-nullable references are a problem because nullable refs are sometime useful. Nothing prevents you from having state in an haskell application. You just have to be explicit about it. Whether the language ergonomics are better or worse than a language that allows state without an explicit type is another question but your reasoning is questionable.

cryptica 7y ago
You can also have pure functions in OOP languages. You can even have a code linter to enforce it as a rule. When discussing programming languages, it's more about what behaviours they encourage rather than what behaviours they support.
- rowanG077 7y ago
  OOP language aren't explicit in what function is pure. If I'm working on a 10MLoC project and touching hundreds of methods while working I can't lookup the implementation of each one to determine whether they are pure. And no a comment saying they are pure is not sufficient. The above is trivial in FP languages.
  - floatboth 7y ago
    Well, except D, D has a @pure annotation :)
    - rowanG077 7y ago
      D pure function aren't really pure though. They can modify the arguments that are passed in. Great concept otherwise.
- mrkeen 7y ago
  How do I do this?

moomin 7y ago

I’m guessing you’ve never done any Haskell programming. I don’t know why you think FP people don’t practice separation of concerns (they do), why you can’t put state and the functions that manipulate that state in the same file (you can) or that a type-checker can’t spot all the places you need to modify when you change a data structure (it does). Also, you seem unaware of the real restrictions on modularity caused by eager evaluation.

cryptica 7y ago
In that case it is not pure functional programming because you are colocating state with logic. Functions in that file can mutate the state within that file; this means that it's only functionally transparent within that file but not from the outside. If you need to store state inside of that file, then it means that you are using it to affect the behaviour of functions which are exposed to the outside... Also, this approach would be sub-par because you would be constrained to singleton modules. What you described sounds like a Haskell programming anti-pattern. It sounds like a feature which was hacked on top to allow Haskell to emulate OOP languages without actually doing OOP. Also, lazy evaluation is a separate topic. OOP languages also support lazy evaluation.
- asplake 7y ago
  No. OOP isn't "colocating", it's "encapsulating". FP does it differently, but whatever the paradigm, programmer ergonomics suggest that it would be unsurprising to see definitions of (say) data and functions close together.
- Legogris 7y ago
  What source code files you happen to put declarations and definitions in has nothing to do with functional purity. Think of it this way: An array append function which adds an element to the input array is not purely functional. An array append function which returns a new array with the new element appended is purely functional. The same function applied to the same input will always return the same value, and won't cause that to break for any other functions. Of course, this makes things such as IO tricky and yo ideally want to minimize and isolate the places where this happens on a lower level. Haskell solves this with monads, which we have seen is a big hurdle for many developers. I personally think Idris's effect system[0] is a lot easier to deal with, but would be curious to see other approaches. [0]: http://docs.idris-lang.org/en/latest/effects/index.html http://docs.idris-lang.org/en/latest/effects/index.html

openfuture 7y ago

A fun quote: Object oriented programming is abstracting over race conditions. What you described is distributed computing, which (you are right) is fashionable. However, each 'computer' in the 'distributed computing' should be purely functional, referentially transparent, etc. Since that make it easier to reason about it as an 'object'. These ideas are just tools for organizing information systems, no need to get too caught up in a label war, even emacs and vim are converging :^)

whateveracct 7y ago

> proper separation of concerns My favorite part of working in Haskell professionally is that my coworkers never use imprecise folk programming terms like this :) Also everything you said just doesn't ring true given my professional experience :)

beders 7y ago

I'm not sure you understand what modularity is all about. There's ample evidence that Functional Programming (esp. with immutable data) gives you a lot of aspects of a 'module' for free. Any function programming language can describe and enforce module boundaries. Some mostly at run-time, but that is A-Ok in my book. I also find it funny you mentioned "large monolithic state" when most enterprise apps try to hide that fact that all your data is in a database (the large monolithic state), by stashing it into objects through some magic ORM...