3 ms·

> 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 pa

> 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
  - simiones 2y ago
    Well, I'd say using an entirely different collection type than the rest of language (STArray instead of [a]) is already a big complication. It also ends up being more than double the size of the Java code. And, as the author admits, it's actually even slower than the original not-quicksort implementation above, because it actually has to make a copy of the original list, and then return a copy of the mutated array. So, one of the best sorting algorithms ever devised is not actually usable to sort a [a] in Haskell... I maintain this is a good example of making an easy problem tough.
    - tome 2y ago
      > I'd say using an entirely different collection type than the rest of language (STArray instead of [a]) is already a big complication Haskell uses many different collection types, just like any other language. Why not? > it's actually even slower than the original not-quicksort implementation above, because it actually has to make a copy of the original list, and then return a copy of the mutated array. Sure, but it could also not do that, if callers are happy to provide a mutable array, just like any other language ... > one of the best sorting algorithms ever devised is not actually usable to sort a [a] in Haskell Indeed! One of the best algorithms for sorting a mutable array can't be used on an immutable data type, just like any other language ... None of this invalidates your original claim that "It's significantly easier in C than it is in Haskell" of course.
    - 2y ago

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
- simiones 2y ago
  Well, I'd say using an entirely different collection type than the rest of language (STArray instead of [a]) is already a big complication. It also ends up being more than double the size of the Java code. And, as the author admits, it's actually even slower than the original not-quicksort implementation above, because it actually has to make a copy of the original list, and then return a copy of the mutated array. So, one of the best sorting algorithms ever devised is not actually usable to sort a [a] in Haskell... I maintain this is a good example of making an easy problem tough.
  - tome 2y ago
    > I'd say using an entirely different collection type than the rest of language (STArray instead of [a]) is already a big complication Haskell uses many different collection types, just like any other language. Why not? > it's actually even slower than the original not-quicksort implementation above, because it actually has to make a copy of the original list, and then return a copy of the mutated array. Sure, but it could also not do that, if callers are happy to provide a mutable array, just like any other language ... > one of the best sorting algorithms ever devised is not actually usable to sort a [a] in Haskell Indeed! One of the best algorithms for sorting a mutable array can't be used on an immutable data type, just like any other language ... None of this invalidates your original claim that "It's significantly easier in C than it is in Haskell" of course.
  - 2y ago