5 ms·

The one roadblock I run into whenever I write functional is the ridiculous number of functions that result. Don't get me wrong, it's great that everything can b

The one roadblock I run into whenever I write functional is the ridiculous number of functions that result. Don't get me wrong, it's great that everything can be abstracted away and easily tested as pure functions, but a kitchen sink of thousands of functions is difficult to remember, let alone introduce someone else to. Namespaces help, but not everything fits into an obvious namespace. Admittedly this is mostly a personal organization issue, but when writing object-oriented code, in my experience it encourages better encapsulation. That being said, I like functional more. :)

mixedCase 9y ago
> but a kitchen sink of thousands of functions is difficult to remember, let alone introduce someone else to That's pretty much the point: You don't have to remember what the function does, just read its name (and function signature, if your language is statically typed). This is a "best practice" in imperative land as well.
- kevmo314 9y ago
  I can't remember a thousand function signatures, and pulling up the list of function names and args is a huge pain if you have to browse through it every single time to find the one function that meets your specific transform, whereas you may as well just write it yourself in half the time. In imperative land, I find that I have to write fewer functions, for better or for worse. As a result, this is not as much of an issue.
  - mixedCase 9y ago
    > and pulling up the list of function names and args is a huge pain if you have to browse through it every single time to find the one function that meets your specific transform Not a problem in Haskell and Idris, at least. With the :search REPL command it will give you all the functions that match the signature you give it as an argument. And really, you can have "longer functions" in any functional language, and they're used all the time: let..in...where, piping transforms (with the |> pipe operator or the . function composition), and of course, the do-notation which resembles imperative programming while being just syntax sugar for nested monadic operations.

mixedCase 9y ago

> but a kitchen sink of thousands of functions is difficult to remember, let alone introduce someone else to That's pretty much the point: You don't have to remember what the function does, just read its name (and function signature, if your language is statically typed). This is a "best practice" in imperative land as well.

kevmo314 9y ago
I can't remember a thousand function signatures, and pulling up the list of function names and args is a huge pain if you have to browse through it every single time to find the one function that meets your specific transform, whereas you may as well just write it yourself in half the time. In imperative land, I find that I have to write fewer functions, for better or for worse. As a result, this is not as much of an issue.
- mixedCase 9y ago
  > and pulling up the list of function names and args is a huge pain if you have to browse through it every single time to find the one function that meets your specific transform Not a problem in Haskell and Idris, at least. With the :search REPL command it will give you all the functions that match the signature you give it as an argument. And really, you can have "longer functions" in any functional language, and they're used all the time: let..in...where, piping transforms (with the |> pipe operator or the . function composition), and of course, the do-notation which resembles imperative programming while being just syntax sugar for nested monadic operations.