3 ms·

> 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, b

by 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.
- tel 12y ago
  I don't think anyone claims you get too performance, merely great performance while retaining high level coding. I don't think syntax is that important, it's about a 3/10 while semantics are a 15/10. For your tradeshow example I can personally attest to the ability to hack together a script in IO on the fly under pressure. It's not a huge problem, and if you're worried about typing IO then just use inference. Your problem with primitive types is valid, but I've always seen this easily handled by optimizing inner loops. It's ugly, but so is all low-level optimized code. And many languages trade off between uniform access, byte-string representation, and Unicode. Haskell just splits each use case into its own type.
  - p0nce 12y ago
    > Your problem with primitive types is valid, but I've always seen this easily handled by optimizing inner loops. It's ugly, but so is all low-level optimized code. OK. I guess if there is a way for the optimizing backend output which unboxing failed it would satisfy me. For us native programmers having tagged pointers that are often optimized, but we don't really know when, is a concern. Might be irrational terror for sure like with the GC fear. So FP languages proponents need to explain more why and how these features like GC/uniform representation/whatever are not a speed impediment (imho). > And many languages trade off between uniform access, byte-string representation, and Unicode. Haskell just splits each use case into its own type. True and this can indeed be contentious where this isn't done.

by tel 12y ago

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.

tel 12y ago
I don't think anyone claims you get too performance, merely great performance while retaining high level coding. I don't think syntax is that important, it's about a 3/10 while semantics are a 15/10. For your tradeshow example I can personally attest to the ability to hack together a script in IO on the fly under pressure. It's not a huge problem, and if you're worried about typing IO then just use inference. Your problem with primitive types is valid, but I've always seen this easily handled by optimizing inner loops. It's ugly, but so is all low-level optimized code. And many languages trade off between uniform access, byte-string representation, and Unicode. Haskell just splits each use case into its own type.
- p0nce 12y ago
  > Your problem with primitive types is valid, but I've always seen this easily handled by optimizing inner loops. It's ugly, but so is all low-level optimized code. OK. I guess if there is a way for the optimizing backend output which unboxing failed it would satisfy me. For us native programmers having tagged pointers that are often optimized, but we don't really know when, is a concern. Might be irrational terror for sure like with the GC fear. So FP languages proponents need to explain more why and how these features like GC/uniform representation/whatever are not a speed impediment (imho). > And many languages trade off between uniform access, byte-string representation, and Unicode. Haskell just splits each use case into its own type. True and this can indeed be contentious where this isn't done.