3 ms·
That is really not true, but I do agree Haskell passes that impression, for the wrong reasons. I'm working hard to fix these misconceptions on HVM, Kind-Lang an
by LightMachine 5y ago
That is really not true, but I do agree Haskell passes that impression, for the wrong reasons. I'm working hard to fix these misconceptions on HVM, Kind-Lang and related projects!
- CyberRabbi 5y agoIt is true and it’s not a bug. It’s a feature. It’s an inherent property of the lazy pure functional programming model, not any particular language. I can’t remember where he said this but SPJ himself said that was a design goal of Haskell. In C you must specify both how and where computations take place. In Java you don’t have to worry about the where (because memory allocation is automatic) but you still how to worry about the how. Haskell goes one step further and abstracts both time and space away from the programmer. Touting this as a benefit of the language but then denying the negative consequences is attempting to have your cake and eat it too. And for the record Java and other garbage collected languages are not generally suitable for interactive applications either. Anyone who has ever waited on a GC pause can attest to that. This is the exact reason Rust exists and why people continue to use C/C++ despite being inconvenient languages to use.
- LightMachine 5y agoI do disagree with SPJ here, though. On HVM, you can have complete control over how the resources (both space and time) are used in your programs and algorithms. That is why it outputs the memory (space) and rewrites (time) cost of each program you run, and it is so precise you can even make formulas of how much memory and how many rewrites your functions will demand. You can absolutely have tight memory control in HVM, just like in C. Being lazy, high-level, etc. is NOT incompatible with that, I'd argue.