3 ms·
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 ab
by 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.