4 ms·

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

by 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 p0nce 12y ago

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.