:thumbs_up: - it's to the point and informative
It may be interesting to point out that compared to popular languages, Haskell tends to make more use of immutable structures, which may have different performance characteristics - and related to that, zippers as a replacement for mutable pointers are actually pretty fast: https://arxiv.org/abs/1908.10926
And as you've mentioned, use of laziness in Haskell has it's problems too, in big part related to ecosystem.
Personally, after few years of using the language (and working in it) and talking to other Haskellers, if I were to decide whether Haskell should become fully strict, I would say no - not only it has important place in pure language for describing cyclic structures, but it allows for more data-driven approach to many problems - see dynamic programming, streaming, iterating (Rust can only replicate characteristics of our Data.List with complex hierarchy of wrappers), custom control flow operators or effortless combining of effectful operations.
But, while I think that laziness by default makes language more composable and elegant, I think that support for strict evaluation is just as important and that language should better nudge users towards it's use where applicable - not only by e.g. making behaviour of StrictData default, but too by having better support for unboxed datatypes - boxing strict data is usually just waste of space and time, while native unboxed types in GHC have limited support from libraries mostly related to low-level stuff. And even if using strict data was easier, all of that is useless without standard library that provides strict alternatives of general datatypes like e.g. tuples or lists.
I really enjoyed reading the article. As a C programmer that transitioned to Haskell, I could really appreciate it. It would be great if more people could appreciate the elegance of Haskell and the convenience (as opposed to the mythical inconvenience) that comes from strong typing.
I'm soliciting feedback on my blog post: https://arifordsham.com/is-haskell-fast/
:thumbs_up: - it's to the point and informative
It may be interesting to point out that compared to popular languages, Haskell tends to make more use of immutable structures, which may have different performance characteristics - and related to that, zippers as a replacement for mutable pointers are actually pretty fast: https://arxiv.org/abs/1908.10926
And as you've mentioned, use of laziness in Haskell has it's problems too, in big part related to ecosystem.
Personally, after few years of using the language (and working in it) and talking to other Haskellers, if I were to decide whether Haskell should become fully strict, I would say no - not only it has important place in pure language for describing cyclic structures, but it allows for more data-driven approach to many problems - see dynamic programming, streaming, iterating (Rust can only replicate characteristics of our
Data.Listwith complex hierarchy of wrappers), custom control flow operators or effortless combining of effectful operations.But, while I think that laziness by default makes language more composable and elegant, I think that support for strict evaluation is just as important and that language should better nudge users towards it's use where applicable - not only by e.g. making behaviour of
StrictDatadefault, but too by having better support for unboxed datatypes - boxing strict data is usually just waste of space and time, while native unboxed types in GHC have limited support from libraries mostly related to low-level stuff. And even if using strict data was easier, all of that is useless without standard library that provides strict alternatives of general datatypes like e.g. tuples or lists.I really enjoyed reading the article. As a C programmer that transitioned to Haskell, I could really appreciate it. It would be great if more people could appreciate the elegance of Haskell and the convenience (as opposed to the mythical inconvenience) that comes from strong typing.
Imagine know fp but having to write c :pensive: that me rn