Am 15.07.2018 um 18:06 schrieb Paul:
* But it is not lazy - one. Remember, laziness is our requirement here. Whatever you propose _must _ work in a context of laziness.
Does it mean because Haskell is lazy (Clean – not) then linear types are impossible in Haskell?
Laziness and linear types are orthogonal.
If they are possible why we need monads?
"Monadic" as a term is at the same level as "associative". A very simple concept that is visible everywhere, and if you can arrange your computations in a monadic manner you'll get a certain level of sanity. And lo and behold, you can even write useful libraries just based on the assumption that you're dealing with monadic structures, that's monad transformers (so they're more interesting than associativity). So monads are interesting and useful (read: important) regardless of whether you have laziness or linear types. Again: orthogonal.
Haskell “tracks” effects obviously. But I shown example with State monad already. As I saw, nobody understand that State monad does not solve problem of spaghetti-code style manipulation with global state.
Actually that's pretty well-known. Not just for State for for anything that hides state out of plain sight, i.e. somewhere else than in function parameters. I.e. either some struct type, or by returning a partially evaluated function that has that data. People get bitten by those things, and they learn to avoid these patterns except where it's safe - just as with spaghetti code, which people stopped writing a few years ago (nowadays it's more spaghetti data but at least that's analyzable). So I think if you don't see anybody explicitly mentioning spaghetti issues with State that's for some people it's just hiding in plain sight and they either aren't consciously aware of it, or find that area so self-explaining that they do not think they really need to explain that. Or you simply misunderstood what people are saying.
But it was solved in OOP when all changes of state happen in *one place* under FSM control Sorry, but that's not what OO is about. Also, I do not think that you're using general FSMs, else you'd be having transition spaghetti.
(with explicit rules of denied transitions: instead of change you have *a request to change*/a message, which can fail if transition is denied). Which does nothing about keeping transitions under control. Let me repeat: What you call a "message" is just a standard synchronous function call. The one difference is that the caller allows the target type to influence what function gets actually called, and while that's powerful it's quite far from what people assume if you throw that "message" terminology around. This conflation of terminology has been misleading people since the invention of Smalltalk. I wish people would finally stop using that terminology, and highlight those things where Smalltalk really deviates from other OO languages (#doesNotUnderstand, clean everything-is-an-object concepts, Metaclasses Done Right). This message send terminology is just a distraction.
Haskell HAS mutable structures, side-effects and allows spaghetti-code. Nope. Its functions can model these, and to the point that the Haskell code is still spaghetti. But that's not the point. The point is that Haskell makes it easy to write non-spaghetti.
BTW you have similar claims about FSMs. Ordinarily they are spaghetti incarnate, but you say they work quite beautifully if done right. (I'm staying sceptical because your arguments in that direction didn't make sense to me, but that might be because I'm lacking background information, and filling in these gaps is really too far off-topic to be of interest.)
But magical word “monad” allows to forget about problem and the real solution and to lie that no such problem at whole (it automatically solved due to magical safety of Haskell). Sure, you can do it in Haskell too, but Haskell does not force you, but Smalltalk, for example, forces you.
WTF? You can do spaghetti in Smalltalk. Easily actually, there are plenty of antipatterns for that language.
We often repeat this: “side-effects”, “tracks”, “safe”. But what does it actually mean? Can I have side-effects in Haskell? Yes. Can I mix side-effects? Yes. But in more difficult way than in ML or F#, for example. What is the benefit?
That it is difficult to accidentally introduce side effects. Or, rather, the problems of side effects. Formally, no Haskell program can have a side effect (unless using UnsafeIO or FFI, but that's not what we're talking about here).
Actually no any benefit, Really. You *should* listen more. If the overwhelming majority of Haskell programmers who're using it in practice tell you that there are benefits, you should question your analysis, not their experience. You should ask rather than make bold statements that run contrary to practical experience. That way, everybody is going to learn: You about your misjudgements, and (maybe) Haskell programmers about the limits of the approach. The way you're approaching this is just going to give you an antibody reaction: Everybody is homing in on you, with the sole intent of neutralizing you. (Been there, done that, on both sides of the fence.)
it’s easy
understandable with simple experiment: if I have a big D program and I remove all “pure” keywords, will it become automatically buggy? No. If I stop to use “pure” totally, will it become buggy? No.
Sure. It will still be pure.
If I add “print”
for debug purpose in some subroutines, will they become buggy? No.
Yes they will. Some tests will fail if they expect specific output. If the program has a text-based user interface, it will become unusable.
If I
mix read/write effects in my subroutine, will it make it buggy? No.
Yes they will become buggy. You'll get aliasing issues. And these are the nastiest thing to debug because they will hit you if and only if the program is so large that you don't know all the data flows anymore, and your assumptions about what might be an alias start to fall down. Or not you but maybe the new coworker who doesn't yet know all the parts of the program. That's exactly why data flow is being pushed to being explicit.
But it’s really very philosophical question, I think that monads are over-hyped actually. I stopped seeing the value of monads by themselves.
Yeah, a lot of people think that monads are somehow state. It's just that state usually is pretty monadic. Or, rather, the functions that are built for computing a "next state" are by nature monadic, so that was the first big application area of monads. But monads are really much more general than for handling state. It's like assuming that associativity is for arithmetic, but there's a whole lot of other associative operators in the world, some of them even useful (such as string concatenation).
* Third, AFAIK CLR restrictions do not allow implementing things like Functor, Monad, etc. in F# directly because they can't support HKT. So they workaround the problem.
https://fsprojects.github.io/FSharpPlus/abstractions.html(btw, you can see that monad is monoid here 😉)
Nope, monoid is a special case of monad (the case where all input and output types are the same). (BTW monoid is associativity + neutral element. Not 100% sure whether monad's "return" qualifies as a neutral element, and my monoid-equals-monotyped-monad claim above may fall down if it is not. Also, different definitions of monad may add different operators so the subconcept relationship may not be straightforward.) (I'm running out of time and interest so I'll leave the remaining points uncommented.) Regards, Jo