41–50 of 218 posts
Earlier quoted context omitted.
Haskell definitely allows imperative programming, it's just not particularly good at it.
What is it lacking for imperative programming? I find it to be immensely good at it!
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.
Earlier quoted context omitted.
The benchmarks game falls squarely under the umbrella of "short, simple programs", not the sort of real-world stuff where you would benefit from having a language that scales well. That said, Haskell performs pretty well in the toy benchmarks anyway. Your comparison between Haskell and Go is about market size, not language design. I suspect you would have a similarly hard time finding Rust devs as Haskell devs (i.e.…
> .. 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…
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 ffi call in most languages if they actually were that performance critical.
Haskell/GHC will soon have an extension for linear types, which will bring the languages much closer: http://blog.tweag.io/posts/2017-03-13-linear-types.html
Yeah right. If only the standard library (the base package) could immediately be converted to use linear types and we can all benefit from that! (Hint: it won't. Even the fairly no-brainer AMP and BBP took an absurdly long time. This is extremely slow by Rust standards. The Haskell community might, but the stewards of the standard libraries don't have the move-fast-and-break-things attitude.)
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.
Earlier quoted context omitted.
What is it lacking for imperative programming? I find it to be immensely good at it!
Don't know... mutable collections? A way to make sure things are evaluated without writing seq every other line?
Mutable arrays: https://hackage.haskell.org/package/vector-0.12.0.1/docs/Dat...
Strict by default: Put {#- Language Strict #-} at the top of files where necessary but usually you'd just use bangpatterns and unbox-strict-fields.
Earlier quoted context omitted.
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.
Some people also complain about a tiny set of syntactic issues. Other than that I like both ml and ocaml.
Maybe the only thing I would complain would be the separation between integer and floating point math.
Earlier quoted context omitted.
This is what's really nice about Nim. It writes like Python, but is fast like Rust. Ran across Option in it the other day, though it's not used heavily. I really wish there was something like Haskell but with a runtime like Nim or Go. Perhaps that is OCaml?
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.
Earlier quoted context omitted.
Yeah right. If only the standard library (the base package) could immediately be converted to use linear types and we can all benefit from that! (Hint: it won't. Even the fairly no-brainer AMP and BBP took an absurdly long time. This is extremely slow by Rust standards. The Haskell community might, but the stewards of the standard libraries don't have the move-fast-and-break-things attitude.)
Did rust ever have a large scale breaking change? Anyway, the linear type proposal is designed to be completely backwards compatible so that shouldn't be as big of an issue.
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.
I don't use Haskell but didn't I read recently that the latest version of Haskell addresses this common concern by allowing you to turn off laziness altogether so everything evaluates eagerly?