3 ms·

Yes, but reading code is much more important than writing it in most contexts, and you're not limited by typing speed anyways. The one-liner would be harder fo

by jbooth 13y ago

Yes, but reading code is much more important than writing it in most contexts, and you're not limited by typing speed anyways. The one-liner would be harder for me to unpack, in most situations, than a 3-liner. You've got 3 calls, give me space to work with them.

copergi 13y ago
They don't need to be on one line. If you really want to pretend that having them on one line is a problem, then put them each on their own line. You can even be needlessly verbose if you want to: do a <- GetBar foo b <- GetBaz a c <- GetCat b return c
- jbooth 13y ago
  That's much more to my liking, but still, we've got multiple ways of doing option types and now I've seen 2 different operators, which I presume are overloaded to deal with those types somewhere? Or we're dealing with a ton of built-in types and built-in operators to deal with them? I'm not trying to sell anyone, code however you like -- I prefer the situation of "simpler environment, don't write bugs" to "really complicated environment that makes it theoretically impossible to write bugs". I bet I can still write bugs.
  - copergi 13y ago
    >now I've seen 2 different operators, which I presume are overloaded to deal with those types somewhere? Or we're dealing with a ton of built-in types and built-in operators to deal with them? No. Remember we're talking about using a language that is not broken by design instead of go. You have one operator (>>=) and it works on one typeclass (Monad). Do notation (do and <-) is merely syntactic sugar that desugars to using >>=. >I prefer the situation of "simpler environment, don't write bugs" to "really complicated environment that makes it theoretically impossible to write bugs" And since those are not the options available, people tell you that those are not the options available. Doing it right is very simple. Your options are "simple and with lots of chances to create bugs" or "just as simple but with fewer chances to create bugs".

by jbooth 13y ago

copergi 13y ago

They don't need to be on one line. If you really want to pretend that having them on one line is a problem, then put them each on their own line. You can even be needlessly verbose if you want to: do a <- GetBar foo b <- GetBaz a c <- GetCat b return c

jbooth 13y ago
That's much more to my liking, but still, we've got multiple ways of doing option types and now I've seen 2 different operators, which I presume are overloaded to deal with those types somewhere? Or we're dealing with a ton of built-in types and built-in operators to deal with them? I'm not trying to sell anyone, code however you like -- I prefer the situation of "simpler environment, don't write bugs" to "really complicated environment that makes it theoretically impossible to write bugs". I bet I can still write bugs.
- copergi 13y ago
  >now I've seen 2 different operators, which I presume are overloaded to deal with those types somewhere? Or we're dealing with a ton of built-in types and built-in operators to deal with them? No. Remember we're talking about using a language that is not broken by design instead of go. You have one operator (>>=) and it works on one typeclass (Monad). Do notation (do and <-) is merely syntactic sugar that desugars to using >>=. >I prefer the situation of "simpler environment, don't write bugs" to "really complicated environment that makes it theoretically impossible to write bugs" And since those are not the options available, people tell you that those are not the options available. Doing it right is very simple. Your options are "simple and with lots of chances to create bugs" or "just as simple but with fewer chances to create bugs".