for/yield is fine. Haskell people love to get excited about the one extra flatten but it's really not a big deal.
Side effects in Scala are a little less obvious than unsafePerformIO calls, but not by much. One little unmanaged println isn't going to destroy the universe. The fact that Haskell will invisibly transform your code into lazy thunks, radically altering its performance characteristics, causes a lot more trouble IME.
Stack overflow problems are real, but you can get a lot of value out of the monad functionality without hitting them, particularly these days with a lot of effects being implemented as Free monad + interpreter. I wonder if Scala.js avoids the issue?
I'd probably switch to Ceylon or Idris if either had the ecosystem to match Scala. But for the time being they don't.
(EDIT: sorry, rampant editing. I apologize if you happen to reply to any of my intermediate edits.)
> for/yield is fine. Haskell people love to get excited about the one extra flatten but it's really not a big deal.
No, it's a big deal. It pollutes everything you do in "do" / "for/yield" notation.
Part of why do notation in Haskell is so amazingly beatiful and concise is that it doesn't force this absurd amount of pointless boilerplate on you.
(We can agree that they're technically equivalent, but SYNTAX FUCKING MATTERS, YO)
My thinking here is that Martin Odersky actually understood what was going on at a technical level, but didn't appreciate what was going on at the cognitive level of the programmer... and so just implemented the mechanism.
If you compound this with the semi-recent "cats"/"scalaz" schism over Monad and Functor, thus making us reexperience the monads-tf/monads-fd schism in Haskell-land... making me think that the supremely clever people behind these projects (no sarcasm!) never experienced the pain that comes from split ecosystems. Because if they had, they wouldn't have started "cats" without getting concensus first. My point is that you cannot meaningfully talk about Monad/Functor without that type definition being a core part of the language -- which it isn't in Scala.
Listen, I appreciate that they have a more difficult problem in some sense, because they've accepted subtyping as an actual thing that's useful. But that's their problem. Subtyping generally isn't very useful[1] and they're driven by OOP ideology... which is fine per se, but don't complain when it doesn't work out -- when the problems of subtyping are well-known and have been for the last 20-30 years.
[1] Use lenses and contra-/covariant functors instead when you actually need it.
> One little unmanaged println isn't going to destroy the universe. The fact that Haskell will invisibly transform your code into lazy thunks, radically altering its performance characteristics, causes a lot more trouble IME.
Yes, it will. Because it isn't just a little "println" here and there (in practice). The deal here is: I can mechanically scan all the code for unsafePerformIO and unsafeInterleaveIO, etc. I cannot scan Scala code mechanically for unsafe things because the possibilities are almost literally infinte. It's about "permit evil selectively" vs. "forbid evil when you see it". The latter doesn't work.
making me think that the supremely clever people behind
these projects (no sarcasm!) never experienced the pain
that comes from split ecosystems. Because if they had,
they wouldn't have started "cats" without getting
concensus first.
What consensus? Do you understand why cat needed to be created in the first place?
It was created because it was impossible to work with these terrible, obnoxious (ex-)Haskell people anymore.
The main change from scalaz to cats is not the code, but the community: Friendly people behaving like adults who don't act gravely offended when people discuss potential approaches which don't look like 100% what Haskell came up with.
I think scalaz will fall out of use mid-term, because everyone is sick of their shit behavior.
> What consensus? Do you understand why cat needed to be created in the first place?
Consensus as in: Get the approval of the community or at least lobby for the inclusion of Monad/Functor/etc. in the Scala standard library. My point was that the inclusion in the standard library is key to making Monad/Functor/etc. work. If you don't have that then you end up with the sad sad situation of monad-tf/monad-fd except this time it's not Transformers[1], but the fundamental Monad/Functor/etc.
As for the rest of your comment: ... WHAT?
[1] Which, to be fair, were fairly controversial at the time.
I'm just stating facts. No idea why these terrible people decided to join Scala in the first place. Maybe the Haskell community ejected them and they just picked their next community to harass?
lomnakkus, I've never heard of you in the Haskell community, but if you do consider yourself part of our community then act more decently in future. You're giving us a bad name.
Side effects in Scala are a little less obvious than unsafePerformIO calls, but not by much. One little unmanaged println isn't going to destroy the universe. The fact that Haskell will invisibly transform your code into lazy thunks, radically altering its performance characteristics, causes a lot more trouble IME.
Stack overflow problems are real, but you can get a lot of value out of the monad functionality without hitting them, particularly these days with a lot of effects being implemented as Free monad + interpreter. I wonder if Scala.js avoids the issue?
I'd probably switch to Ceylon or Idris if either had the ecosystem to match Scala. But for the time being they don't.