Am 19.04.2017 um 15:13 schrieb Sergiu Ivanov:
Seemed to be related to Haskells expressivity, with the type system pretty much preventing the typical errors that people make.
I tend to see Haskell's type system as very restrictive and only allowing behaviour which composes well.
From a library writer's and library user's perspective, that would actually be a Good Thing.
However, there are a couple big "backdoors", like the IO monad.
Well, it's so awkward that people don't *want* to use it.
Typechecking gives zero guarantees for functions of type IO (), for example.
That doesn't match what I hear from elsewhere. I don't know what is the cause for that difference though.
Though I doubt that that will hold up once you get more proficient in Haskell and start tackling really complicated things
To me, it really depends on the kind of complicated things. If you manage to explain the thing at the type level, then typechecking may give you pretty strong guarantees. I'm thinking of parsing and concurrency as positive examples and exception handling as a somewhat negative example.
That matches what I heard :-)
(Ironically, people instantly started investigating ways to work around that. Still, the sort-of globals you can introduce via the State monad are still better-controlled than the globals in any other language.)
In fact, I believe having pure functions does not so much target removing state as it does making the state _explicit_.
Except State tends to make state implicit again, except for the fact that there *is* state (which might be actually enough, I don't have enough insight for any judgemental statements on the issue).
Thus, the State monad is not a work-around to purity, it's a way of purely describing state.
True.
And I think you can trace that to the need to interface with the real world.
I have the same gut feeling.
I think interfacing with the outside world (still not "real" but just bits inside the operating system and on disk) is one major source of unreliability, but not the only one, and not necessarily the primary one. YMMV.
Yes, that unreliability comes with crossing the frontier between theoretical and applied computer sciences (that's an imprecise metaphor :-) )
:-D