|
|
|
|
|
by cousin_it
3841 days ago
|
|
> Haskell is a great language for expressing computations, the thing CS is about. I think Haskell is good at expressing a narrow range of ideas that, honestly, aren't all that fruitful outside the FP field. There are three main reasons why it's not a great language for expressing arbitrary algorithms: 1) It uses the pointer model instead of the integer RAM model. That leads to extra logarithmic factors. 2) Immutability. That's hypothesized to also cause extra logarithmic factors, but AFAIK that's still an open problem. 3) Non-strict evaluation. That wreaks havoc with space complexity, and compositional analysis of performance in general. Yes, you can add epicycles to remedy these drawbacks (arrays, ST, strictness annotations). But I'd rather use a C-like language in the first place. That's closer to the "core" of CS as I understand it, and that's how most algorithm research is done. |
|
Speaking more pragmatically, outside of CS study, most of the programs I write do not require me to write high-performance algorithms – they tend to be very I/O bound, and call out to external libraries/services for the data crunching. When I need performance (because of course I do at times), there is an amazing library that lets me write C code in Haskell[1]. The fact that some sections of my program is performance critical doesn't mean I have to write the entire program in C. I can write just the performance critical parts in C.
[1]: https://github.com/fpco/inline-c/blob/master/README.md