7 ms·

> Yes - the value of functional programming isn't that working in OCAML, or F#, or Haskell is 10x as productive as other languages. This is not true in my pers

> Yes - the value of functional programming isn't that working in OCAML, or F#, or Haskell is 10x as productive as other languages. This is not true in my personal experience. As has been famously said (paraphrased): Functional programming makes tough problems easy and easy problems tough. In other words the value of functional programming depends on your domain.

NinoScript 2y ago
So you’re saying that it does make you 10x as productive?
initplus 2y ago
Maybe my phrasing is not clear - I meant that these languages are indeed not significantly more productive.
- marcosdumay 2y ago
  But (and I agree with the GP) they are. They are overwhelmingly more productive, in a way that you often can't even compare quantitatively. They are also a lot less productive. It depends entirely on what you are doing.
- grumpyprole 2y ago
  By what measure? Haskell can be a huge productivity multiplier. The standard library is built upon many powerful, unifying and consistent mathematical abstractions. For example, there is almost no boilerplate to write for any traversal, mapping, error handling etc. The average Pythonista simply has no idea what they are missing. But Haskell doesn't have anywhere near the third party ecosystem of Python, so is less productive by some measures.
antonvs 2y ago
> easy problems tough. That needs a qualifier: it can make easy problems tough if you're not familiar with how to solve them in a functional context. A big part of that is because smart people have already solved the tough problems and made them available as language features or libraries.
- jiggawatts 2y ago
  Absolutely! Any beginner can readily combine the catamorphisms and anamorphisms in `recursion-schemes`, or use the ready-made hylomorphisms for common tasks such as setting a value in a data structure. What could be simpler? /s https://wiki.haskell.org/Zygohistomorphic_prepromorphisms https://wiki.haskell.org/Zygohistomorphic_prepromorphisms
  - amoss 2y ago
    They have played us for absolute fools.
- cubefox 2y ago
  > That needs a qualifier: it can make easy problems tough if you're not familiar with how to solve them in a functional context. All problems are easy if you are familiar with how to solve them. Unfortunately it's part of the problem to find out how to solve them, and that can be unusually hard in case of functional programming. Like solving something with recursion instead of loops + states. There is a reason cookbooks use loops not recursion.
- simiones 2y ago
  Not really, certain problems are just inherently harder to express in a purely functional way than they are in an imperative way (and the reverse is just as true). For example, computing a histogram is much simpler in imperative terms (keep an array of histogram values, go through the original list, add 1 to the array element corresponding to the current element in this list) than in a purely functional style, especially if you need a somewhat efficient implementation. My favorite example of this is implementing quicksort. It's significantly easier in C than it is in Haskell.
  - chuckadams 2y ago
    > My favorite example of this is implementing quicksort. It's significantly easier in C than it is in Haskell. Oh please, what's so hard about qsort :: Ord a => [a] -> [a] qsort [] = [] qsort (p:xs) = qsort lesser ++ [p] ++ qsort greater where lesser = filter (< p) xs greater = filter (>= p) xs :) folks, take that with a big ol /s, you would never want to actually use that algorithm. But the real deal isn't all that awful: https://mmhaskell.com/blog/2019/5/13/quicksort-with-haskell https://mmhaskell.com/blog/2019/5/13/quicksort-with-haskell
kreyenborgi 2y ago
> makes tough problems easy and easy problems tough And because of mutual recursion, that means that tough is easy (and easy tough). In other words, if we call the class of tough problems T and easy problems NT, we have T==NT, given FP.
williamcotton 2y ago
What easy problems are tough in F#? I’ve been using it for writing random scripts and as a Python replacement.
- z500 2y ago
  Writing recursive descent parsers in F# is a lot of fun with ADTs and pattern matching.
- DimmieMan 2y ago
  It's an overgeneralisation. If you try and turn F# into Haskell at home you may run into that problem. F# is functional first language so if an object oriented or procedural solution is the right call the options right there when you need it.
chrischen 2y ago
It’s only tough to change your way of thinking. Most people making the switch find it tough because they are trying to find imperative techniques to do something in a functional way and struggling because they can’t find an if else statement or a for loop. But if you were never taught to think in terms of conditional branching or looping indexes you’ll save a lot of time.
- theCodeStig 2y ago
  Exactly. I've long held the sentiment, that pure functional programming is easier than imperative programming. The only hard part, is switching from an imperative mindset.
pyuser583 2y ago
How do you “Hello World” in a functional language? Doesn’t it have side effects?
- sevensor 2y ago
  There's some real confusion about what "functional" means, because it depends on who's speaking. Writing _exclusively_ pure functions is a Haskell thing. A much looser definition of the functional style would be to say that you mostly write pure functions over immutable data, but when you have to actually do a side effect you write a procedure that talks to the outside world and go on with your day. If you go digging in this site's archives from about ten years ago, I recall numerous debates about what constituted functional programming, and whether the latter counts at all. But if we _are_ talking about Haskell, the answer to your question is obviously "Monads."
- cess11 2y ago
  The string "Hello World" evaluates to itself, what else do you need? Edit: Eh, I thought it was a fun quip.
  - pyuser583 2y ago
    I laughed
  - NateEag 2y ago
    Never forget PHP's "Hello World": Hello, world!
- trealira 2y ago
  Yes, and AFAIK, you're pretty much free to cause side-effects in functional languages; it's just a bit awkward and somewhat discouraged. It's kind of like how C still has goto, yet it's still a structured programming language. Even in Haskell, which tries to control side-effects more, it's not hard; it's just that it's stuck with an "IO" annotation. Any function that calls an IO function also becomes an IO function; it's infectious. main :: IO () main = putStrLn "hello, world"
- 2y ago
deleted 2y ago
[deleted]

NinoScript 2y ago

So you’re saying that it does make you 10x as productive?

initplus 2y ago

Maybe my phrasing is not clear - I meant that these languages are indeed not significantly more productive.

marcosdumay 2y ago
But (and I agree with the GP) they are. They are overwhelmingly more productive, in a way that you often can't even compare quantitatively. They are also a lot less productive. It depends entirely on what you are doing.
grumpyprole 2y ago
By what measure? Haskell can be a huge productivity multiplier. The standard library is built upon many powerful, unifying and consistent mathematical abstractions. For example, there is almost no boilerplate to write for any traversal, mapping, error handling etc. The average Pythonista simply has no idea what they are missing. But Haskell doesn't have anywhere near the third party ecosystem of Python, so is less productive by some measures.

antonvs 2y ago

> easy problems tough. That needs a qualifier: it can make easy problems tough if you're not familiar with how to solve them in a functional context. A big part of that is because smart people have already solved the tough problems and made them available as language features or libraries.

jiggawatts 2y ago
Absolutely! Any beginner can readily combine the catamorphisms and anamorphisms in `recursion-schemes`, or use the ready-made hylomorphisms for common tasks such as setting a value in a data structure. What could be simpler? /s https://wiki.haskell.org/Zygohistomorphic_prepromorphisms https://wiki.haskell.org/Zygohistomorphic_prepromorphisms
- amoss 2y ago
  They have played us for absolute fools.
cubefox 2y ago
> That needs a qualifier: it can make easy problems tough if you're not familiar with how to solve them in a functional context. All problems are easy if you are familiar with how to solve them. Unfortunately it's part of the problem to find out how to solve them, and that can be unusually hard in case of functional programming. Like solving something with recursion instead of loops + states. There is a reason cookbooks use loops not recursion.
simiones 2y ago
Not really, certain problems are just inherently harder to express in a purely functional way than they are in an imperative way (and the reverse is just as true). For example, computing a histogram is much simpler in imperative terms (keep an array of histogram values, go through the original list, add 1 to the array element corresponding to the current element in this list) than in a purely functional style, especially if you need a somewhat efficient implementation. My favorite example of this is implementing quicksort. It's significantly easier in C than it is in Haskell.
- chuckadams 2y ago
  > My favorite example of this is implementing quicksort. It's significantly easier in C than it is in Haskell. Oh please, what's so hard about qsort :: Ord a => [a] -> [a] qsort [] = [] qsort (p:xs) = qsort lesser ++ [p] ++ qsort greater where lesser = filter (< p) xs greater = filter (>= p) xs :) folks, take that with a big ol /s, you would never want to actually use that algorithm. But the real deal isn't all that awful: https://mmhaskell.com/blog/2019/5/13/quicksort-with-haskell https://mmhaskell.com/blog/2019/5/13/quicksort-with-haskell

kreyenborgi 2y ago

> makes tough problems easy and easy problems tough And because of mutual recursion, that means that tough is easy (and easy tough). In other words, if we call the class of tough problems T and easy problems NT, we have T==NT, given FP.

williamcotton 2y ago

What easy problems are tough in F#? I’ve been using it for writing random scripts and as a Python replacement.

z500 2y ago
Writing recursive descent parsers in F# is a lot of fun with ADTs and pattern matching.
DimmieMan 2y ago
It's an overgeneralisation. If you try and turn F# into Haskell at home you may run into that problem. F# is functional first language so if an object oriented or procedural solution is the right call the options right there when you need it.

chrischen 2y ago

It’s only tough to change your way of thinking. Most people making the switch find it tough because they are trying to find imperative techniques to do something in a functional way and struggling because they can’t find an if else statement or a for loop. But if you were never taught to think in terms of conditional branching or looping indexes you’ll save a lot of time.

theCodeStig 2y ago
Exactly. I've long held the sentiment, that pure functional programming is easier than imperative programming. The only hard part, is switching from an imperative mindset.

pyuser583 2y ago

How do you “Hello World” in a functional language? Doesn’t it have side effects?

sevensor 2y ago
There's some real confusion about what "functional" means, because it depends on who's speaking. Writing _exclusively_ pure functions is a Haskell thing. A much looser definition of the functional style would be to say that you mostly write pure functions over immutable data, but when you have to actually do a side effect you write a procedure that talks to the outside world and go on with your day. If you go digging in this site's archives from about ten years ago, I recall numerous debates about what constituted functional programming, and whether the latter counts at all. But if we _are_ talking about Haskell, the answer to your question is obviously "Monads."
cess11 2y ago
The string "Hello World" evaluates to itself, what else do you need? Edit: Eh, I thought it was a fun quip.
- pyuser583 2y ago
  I laughed
- NateEag 2y ago
  Never forget PHP's "Hello World": Hello, world!
trealira 2y ago
Yes, and AFAIK, you're pretty much free to cause side-effects in functional languages; it's just a bit awkward and somewhat discouraged. It's kind of like how C still has goto, yet it's still a structured programming language. Even in Haskell, which tries to control side-effects more, it's not hard; it's just that it's stuck with an "IO" annotation. Any function that calls an IO function also becomes an IO function; it's infectious. main :: IO () main = putStrLn "hello, world"
2y ago

deleted 2y ago

[deleted]