4 ms·

For me it's much simpler. I don't feel like "FP" would bring me anything at all. Let's enumerate the Haskell features that will supposedly save my soul. - Immu

by p0nce 12y ago

For me it's much simpler. I don't feel like "FP" would bring me anything at all. Let's enumerate the Haskell features that will supposedly save my soul. - Immutability. You have to minimize state whatever the program you write, be it language-enforced or not. - Purity: same story. - Traits. I can use compile-time duck-typed interfaces in C++ or D that achieve the same thing that eg. Caml modules. - Monads: if I understand correctly could be done with compile-time interfaces in many languages, doesn't mean we want to. - Getting access to the GPU power by using some magic library. I'll be honest: I don't believe it. - Laziness: never needed it, I think SPJ said the next Haskell would be strict. - Better type inference. This was already nice in Ocaml. It doesn't bring anything for maintenance work, types are _nice to read_, and inference inside functions is done in "lesser" languages. - exhaustive match: Very nice. Other languages have equivalents. - deconstructed match: I think it can lead to abuse. I never need to match the first three elements of a list. - closures: every language have them now. C++ even allow to manipulate the capture as a first class value. And guess what? In practice closures are less readable that their retarded brother, the Object. - tuple syntax: I think it's considered cool while it's not readable. Aggregates have names, tuples have "first element", "2nd element", no semantic meaning. - named tuple syntax: available with other language aggregate literals most of the time. - custom operators: considered a liability, I don't want to learn to read your super duper (+=+) operator. - true parametric polymorphism: implies uniform representation, implies lessened performance, implies not being a general purpose language. You want to be used for any program, _be fast_ or go home. - forced to write good code. No no no I want to be _able_ to crank out stinking code when I want, so that I can automate something in the first place given a time budget. AFAIK Haskell has no story for custom memory allocations, explicit SIMD intrinsics, use two different string types, one of which is a list of Char. A list. Why a list? This is never needed in high performance programs. There is also a perception that "the compiler will make my program fast because $compiler_guy is super smart" which is terribly junior, and this hipster community tells me I'm dumb for not using Haskell. Also wtf with the preprocessor? Really? Am I not "getting FP"?

the_af 12y ago
> - Immutability. You have to minimize state whatever the program you write, be it language-enforced or not. > - Purity: same story. I agree you can write decent code in any language, but the point is which guarantees your language gives you about the code other people wrote. Which is most of the code, usually. Your average imperative language gives you far fewer guarantees than Haskell. Even with your own code, you can achieve purity and immutability in Java or C++ if you want to, but you are mostly fighting against the language. > - Laziness: never needed it, I think SPJ said the next Haskell would be strict. On the other hand, Wadler himself in "Why Functional Programming Matters" argues that laziness is essential to achieve modularity and composability.
- p0nce 12y ago
  > On the other hand, Wadler himself in "Why Functional Programming Matters" argues that laziness is essential to achieve modularity and composability. I just read the part about it, I agree that lazy computation is a powerful tool for modularity and composability. But it's nothing specific to FP languages. Python and Nimrod do that through generators (yield keyword), D through "ranges" (no language support). Also not all algorithms you would want to write only once are easily expressible in a lazy way (eg. push parsers).
  - the_af 12y ago
    Yes, fully agreed, it's not specific to FP languages and it's not always easy to use.
    - tel 12y ago
      I'm pretty convinced that the holy grail is one where either laziness or strictness is a tracked effect and both evaluation schemes are used as optimal.
- Shorel 12y ago
  > Even with your own code, you can achieve purity and immutability in Java or C++ if you want to, but you are mostly fighting against the language. I think purity works very nice in D, using D definition of purity.
the_af 12y ago
Also, re: laziness, it's more nuanced than that. See this quote by SPJ, from a 2009 interview ( https://www.simple-talk.com/opinion/geek-of-the-week/simon-peyton-jones-geek-of-the-week/ https://www.simple-talk.com/opinion/geek-of-the-week/simon-p... ): > "Laziness has lots of advantages, including modularity. These days, the strict/lazy decision isn’t a straight either/or choice. For example, a lazy language has ways of stating ‘use call by value here’, and even if you were to say ‘oh, the language should be call by value strict’ – which is the opposite of lazy - you’d want ways to achieve laziness anyway. > Any successor language to Haskell will have support for both strict and lazy functions. So the question then is: what’s the default, and how easy is it to get to these things? > How do you mix them together? But on balance yes, I’m definitely very happy with using the lazy approach, as that’s what made Haskell what it is and kept it pure." I'd say he is arguing that keeping laziness as the default was the right choice...
tel 12y ago
> Am I not "getting FP"? I think that's the case. Haskell never claimed it would save your soul. Quickly and in particular: Immutability/purity: of course, but being more explicit is beneficial and challenging, so the compiler helps Traits: if you mean typeclasses then they are much more than merely traits Monads: I don't think you understand correctly, sorry GPU: You don't have to believe it. It exists. Embedded DSLs and cross-compilation are very common in Haskell. Laziness: it's not a needed thing at all, it increases composability. SPJ has asked that question, but the jury is still very far out. Closures: Let's not argue readability, it just makes everyone look bad. Instead, I agree that Objects and anonymous functions are similar. The point is not to have them, it's to have a culture which really does use them everywhere that's appropriate. Syntax: not worth arguing about. If you dislike it, you dislike it. True parametric polymorphism: I have no idea what you're talking about here. Parametricity leads to much more program correctness and specialization recovers speed. Further, parametricity opens up compiler-enforced behavior leading to fusion which dramatically improves speed. Forced to write good code: you really aren't, you're just forced to mark it as bad code (i.e. live in IO) GHC has custom memory allocations, SIMD probably by the next version, and three different string types. Each has their own particular use and forcing them to be the same would lead to inefficiencies or incorrectness all around. Using CPP is annoying, no doubt. It'd be great if that were different.
- p0nce 12y ago
  > GPU: You don't have to believe it. It exists. Embedded DSLs and cross-compilation are very common in Haskell. Of course I believe it exist, I just don't believe it can achieve top performance (which I happen to need in $dayjob). > Let's not argue readability, it just makes everyone look bad. ??? It's still the most important thing for a programming language. Most of our problems are because programs are hard to understand and hard to change. > Forced to write good code: you really aren't, you're just forced to mark it as bad code (i.e. live in IO) If I need an ugly script quickly for splitting a big binary file in parts to people that went to a tradeshow (yes true example), I don't have time to type "IO" or even think about it. The language won't help me achieve anything in that case. > True parametric polymorphism: I have no idea what you're talking about here. Parametricity leads to much more program correctness and specialization recovers speed. Further, parametricity opens up compiler-enforced behavior leading to fusion which dramatically improves speed. http://www.haskell.org/ghc/docs/6.12.1/html/users_guide/primitives.html http://www.haskell.org/ghc/docs/6.12.1/html/users_guide/prim... https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/HaskellExecution/PointerTagging https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Haskell... Unboxing/specialization needs access to the whole source code like any whole program analysis. So what I get is that if you are lucky, the compiler will recover the speed that was lost in the first place. But you can't be sure. > Each has their own particular use and forcing them to be the same would lead to inefficiencies or incorrectness all around. It still an impediment to have three of them. Many languages have one, period.

by p0nce 12y ago

the_af 12y ago

> - Immutability. You have to minimize state whatever the program you write, be it language-enforced or not. > - Purity: same story. I agree you can write decent code in any language, but the point is which guarantees your language gives you about the code other people wrote. Which is most of the code, usually. Your average imperative language gives you far fewer guarantees than Haskell. Even with your own code, you can achieve purity and immutability in Java or C++ if you want to, but you are mostly fighting against the language. > - Laziness: never needed it, I think SPJ said the next Haskell would be strict. On the other hand, Wadler himself in "Why Functional Programming Matters" argues that laziness is essential to achieve modularity and composability.

p0nce 12y ago
> On the other hand, Wadler himself in "Why Functional Programming Matters" argues that laziness is essential to achieve modularity and composability. I just read the part about it, I agree that lazy computation is a powerful tool for modularity and composability. But it's nothing specific to FP languages. Python and Nimrod do that through generators (yield keyword), D through "ranges" (no language support). Also not all algorithms you would want to write only once are easily expressible in a lazy way (eg. push parsers).
- the_af 12y ago
  Yes, fully agreed, it's not specific to FP languages and it's not always easy to use.
  - tel 12y ago
    I'm pretty convinced that the holy grail is one where either laziness or strictness is a tracked effect and both evaluation schemes are used as optimal.
Shorel 12y ago
> Even with your own code, you can achieve purity and immutability in Java or C++ if you want to, but you are mostly fighting against the language. I think purity works very nice in D, using D definition of purity.

the_af 12y ago

Also, re: laziness, it's more nuanced than that. See this quote by SPJ, from a 2009 interview ( https://www.simple-talk.com/opinion/geek-of-the-week/simon-peyton-jones-geek-of-the-week/ https://www.simple-talk.com/opinion/geek-of-the-week/simon-p... ): > "Laziness has lots of advantages, including modularity. These days, the strict/lazy decision isn’t a straight either/or choice. For example, a lazy language has ways of stating ‘use call by value here’, and even if you were to say ‘oh, the language should be call by value strict’ – which is the opposite of lazy - you’d want ways to achieve laziness anyway. > Any successor language to Haskell will have support for both strict and lazy functions. So the question then is: what’s the default, and how easy is it to get to these things? > How do you mix them together? But on balance yes, I’m definitely very happy with using the lazy approach, as that’s what made Haskell what it is and kept it pure." I'd say he is arguing that keeping laziness as the default was the right choice...

tel 12y ago

> Am I not "getting FP"? I think that's the case. Haskell never claimed it would save your soul. Quickly and in particular: Immutability/purity: of course, but being more explicit is beneficial and challenging, so the compiler helps Traits: if you mean typeclasses then they are much more than merely traits Monads: I don't think you understand correctly, sorry GPU: You don't have to believe it. It exists. Embedded DSLs and cross-compilation are very common in Haskell. Laziness: it's not a needed thing at all, it increases composability. SPJ has asked that question, but the jury is still very far out. Closures: Let's not argue readability, it just makes everyone look bad. Instead, I agree that Objects and anonymous functions are similar. The point is not to have them, it's to have a culture which really does use them everywhere that's appropriate. Syntax: not worth arguing about. If you dislike it, you dislike it. True parametric polymorphism: I have no idea what you're talking about here. Parametricity leads to much more program correctness and specialization recovers speed. Further, parametricity opens up compiler-enforced behavior leading to fusion which dramatically improves speed. Forced to write good code: you really aren't, you're just forced to mark it as bad code (i.e. live in IO) GHC has custom memory allocations, SIMD probably by the next version, and three different string types. Each has their own particular use and forcing them to be the same would lead to inefficiencies or incorrectness all around. Using CPP is annoying, no doubt. It'd be great if that were different.

p0nce 12y ago
> GPU: You don't have to believe it. It exists. Embedded DSLs and cross-compilation are very common in Haskell. Of course I believe it exist, I just don't believe it can achieve top performance (which I happen to need in $dayjob). > Let's not argue readability, it just makes everyone look bad. ??? It's still the most important thing for a programming language. Most of our problems are because programs are hard to understand and hard to change. > Forced to write good code: you really aren't, you're just forced to mark it as bad code (i.e. live in IO) If I need an ugly script quickly for splitting a big binary file in parts to people that went to a tradeshow (yes true example), I don't have time to type "IO" or even think about it. The language won't help me achieve anything in that case. > True parametric polymorphism: I have no idea what you're talking about here. Parametricity leads to much more program correctness and specialization recovers speed. Further, parametricity opens up compiler-enforced behavior leading to fusion which dramatically improves speed. http://www.haskell.org/ghc/docs/6.12.1/html/users_guide/primitives.html http://www.haskell.org/ghc/docs/6.12.1/html/users_guide/prim... https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/HaskellExecution/PointerTagging https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Haskell... Unboxing/specialization needs access to the whole source code like any whole program analysis. So what I get is that if you are lucky, the compiler will recover the speed that was lost in the first place. But you can't be sure. > Each has their own particular use and forcing them to be the same would lead to inefficiencies or incorrectness all around. It still an impediment to have three of them. Many languages have one, period.