Just wanted to add my 2 cents, seing as I've done very little Haskell, and most of my experience is from Javascript and Clojure. I prefer let-in over where. In no language I've worked in do you have such a construct, so these opinions could simply be due to lack of experience. But then again, that itself is a reason to prefer let over where.
For me, using let-in is easier because I rarely know what the returning statement should look like in any non-complex function. When writing code it's easier to first write down the things I know I need, and then figure out how to make those pieces fit in a way which gives me what I want. It's the same thing when reading code. It's easier, for me, to first read what I have, and then see how those things fit together to return the product. When I tried to learn Haskell, I always used let-in over where for this reason. Since where didn't really give me any advantages, I never used it. As a result, code using where was more difficult for me to read. Also, for me, the zig-zag reading argument against let-in doesn't make much sense. If I read a statement like [ my ++ implementation, details] I instantly forget it if I don't know what my, implementation and details are. Until I know those things, the statement is garbage. For me, there is more zig-zag reading with the where expression, due to how I understand code. The use of let-in or where, is subjective. However, I'd argue that a let-in pattern is much more comfortable for someone who comes from a language like javascript (or Clojure, for that matter), as that is how you're forced to write code in those languages. Some have argued that that is not a good argument, because people are already forced to learn a new language and a new way of doing things. But less people would be willing to do that the more complex features they find. I'd argue that Elm is a language people are willing to learn because it has very few constructs. Again, in my experience, I never finished learning Haskell because it simply became to much hassle. Elm I learned without any issue. I even tried Haskell again after learning Elm, and gave up once more. That Elm is trying to be easy to learn for Javascript developers is a good thing! (tm). Then there is the argument regarding having one way to do things. This is an argument I agree with. It makes things easier to read as there are less surprises when reading someone elses code. This might be a subjective thing, but I think Python is easier to read than Ruby, Go easier than C++, Elm easier than Haskell. I'd argue that it's a direct result of having less syntax and opinionated code formatting. Some have said that Elm already breaks this principle, and this is true for things like record.value and .value record. But that doesn't mean that we shouldn't strive to break this rule as little as possible. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
