Re:Reflecting on Haskell in 2017
by AnimalMuppet on Monday December 04, 2017 @01:33PM
(#15846251)
> That seems like a poor way to explain the concept since the entire point of programming is to mutate state and that's how the hardware actually works, too.
The hardware actually works using gotos, too (well, jumps in assembly language). That does not make it either ergonomic or safe to write code that way.
The entire point of programming is to compute results. In the hardware that results in mutations; in the programming model it doesn't necessarily have to.
My point was simply that saying “immutability works when everything is immutable” often sounds confusing and/or wrong because people know they need to mutate things. Saying that you're using a language with more advanced concepts to ensure that things only change in the desired manner avoids that initial point of confusion.
That seems like a poor way to explain the concept since the entire point of programming is to mutate state and that's how the hardware actually works, too. I prefer to discuss it as tackling that uncertainty by allowing the language to indicate more nuanced contracts and enforce them, where immutability-by-default is a reasonable design which still gives you the option of using a mutable structure where necessary.
> 2. Syntax is a non issue. Honestly, I stopped caring a long time ago about how language looks. You get used to it in the first month.
I think this is a big mistake: if you want a language to be successful, that first experience is pretty important if you want big open source community with many contributors. In the case of Haskell, this is especially important since there are a number of other hard concepts which people need to learn along with the syntax and the nature of the language means that other programming experience is less helpful.