141–150 of 218 posts
Earlier quoted context omitted.
Why not SML/CML where you basically get haskell syntax and types, but get modules, no laziness, and you can mutate things when it's more efficient to do so.
I couldn't stand to work without HKT now that I'm used to them. (Hell, I'm struggling with Scala's lack of polykinded types; you don't need them until you do, but then you really need them).
Earlier quoted context omitted.
Have you looked at Swift? It's pretty similar to Rust, but eschews all the lifetime stuff in favour of a runtime that does reference counting.
Actually Swift 4.0 just got some memory ownership support, with more to come later.
Earlier quoted context omitted.
Yet there are not many large codebases in languages with HKT, and even those which are there (mainly big Scala projects) do not use HKT
Most large codebases are terrible, and these facts are not unrelated.
I suspect that it is closer to the truth to say that most large codebases are terrible, regardless of language, and that HKT won't save you. (Using HKT may help, some. Using HTK well may help more. But the problem with large codebases is that enough programmers work on it that the talent level tends toward the average of the universe of programmers. That's... not good. It means that whatever tool or technique you choose won't be used well.)
Earlier quoted context omitted.
Wasn't the selling point of laziness performance? "It only does what is needed!" I didn't use Haskell but Nix and at least there it seemed reasonable to "not do" everything.
I don't think anything is the unique selling point of laziness. Wikipedia[1] says "The benefits of lazy evaluation include: * The ability to define control flow (structures) as abstractions instead of primitives. * The ability to define potentially infinite data structures. This allows for more straightforward implementation of some algorithms. * Performance increases by avoiding needless calculations, and error cond…
Earlier quoted context omitted.
Hence a reason why so many people are sticking to ML despite the lack of social momentum.
ocaml is a great language in its own right too; the only haskell features I find myself really missing are do notation and operator overloading.
Not saying these are insurmountable, unforgivable problems, just really annoying.
Something that I found about going from Haskell to Rust was that Rust provides many powerful abstractions without compromising on performance. It was very frustrating to try reasoning about performance in Haskell due to its laziness. Every language has quirks about how to write performant code, but Haskell is notorious in my mind for being quite easy to write obscenely slow code in.
for (int i = 0; i for (int i = 0; i foo :: [Int] -> [Int]
foo :: [(Int, Int)] -> [(Int, Int)]
There are limits to how much you can restructure a list that's exported outside the compilation unit (my Haskell knowledge is fuzzy here so that's probably not the right terminology). And if the list is being re-stitched in odd ways it might be a bad idea. But as far as I can tell it ought to be doable and useful in most common cases. Of course maybe it's already doing this in those cases where it can prove that it works and that's why Haskell performance generally is good but fragile.
Earlier quoted context omitted.
Actually Swift 4.0 just got some memory ownership support, with more to come later.
Link? Last I checked all of Swift's ownership ideas were just in-progress proposals, with implementation to be left to far-future releases.
Basically 4.0 will introduce the notion of exclusive access, with more affine type ideas to follow up on 4.x.
EDIT: This feature is described by SE-0176.
https://github.com/apple/swift-evolution/blob/master/proposa...
Earlier quoted context omitted.
> .. you can write vastly more complicated programs that are, say, 80% as fast as hand-optimized C for only 10% of the effort of hand-optimized C. I don't mean to be personal, but your quantative claim smells a little like unsubstantiated BS. Do you have any data to back it up? > That said, Haskell performs pretty well in the toy benchmarks anyway. Currently, "pretty well" looks like GHC performance is 50% to 10% of…
The make errors are a bit weird because the programs build on my machine no problem. In parts haskells slowness seems to be because no one cares enough to work on it. Can't say for sure, though, so maybe I just should try a task and implement it to see how fast it'd be without amazing optimization foo. Although of course these benchmarks aren't really representative of the real world because they'd just end up as a c…
It cannot.
The line "main = putStr.pidgits.read.head =<< getArgs" has been commented out because the program author has optimised-away some of the work that must be done.
Earlier quoted context omitted.
This is utter nonsense. Everything you wrote is somewhere between 90° and 180° wrong.
I'm totally correct. You are completely unaware of what's going on. We can discuss this logically in the comments, you'll see. It's not going to pretty for you as my arguments will pick you apart piece by piece.
Something that I found about going from Haskell to Rust was that Rust provides many powerful abstractions without compromising on performance. It was very frustrating to try reasoning about performance in Haskell due to its laziness. Every language has quirks about how to write performant code, but Haskell is notorious in my mind for being quite easy to write obscenely slow code in.
Something I've always wondered about Haskell is whether there is, in practice, rope for the compiler to optimize things away from the theoretical underlying implementation. For instance a C compiler is free to turn for (int i = 0; i into for (int i = 0; i It seems like GHC ought to similarly be able to turn some foo :: [Int] -> [Int] into foo :: [(Int, Int)] -> [(Int, Int)] under the covers for a similar speedup as l…
for (int i = 0; i t = 0;
for (int i = 0; i