[war1025]

Maybe I'm missing something, but how is that any more readable than:

  for val in xrange(1, 100):
    if val % 15 == 0:
      print "FizzBuzz"
    elif val % 5 == 0:
      print "Buzz"
    elif val % 3 == 0:
      print "Fizz"
    else:
      print val

[andrewstellman]

Well, yes, you're right – like beauty, readability is in the eye of the beholder. I've been writing a ton of Scala code lately, and my version is very Scala-like, so it looks better to me.

That said, I think there are several advantages:

• It's more compact, with fewer lines and fewer characters, but at least as readable

• There's simple separation of concerns: it only has a single print statement – the whole range is transformed, then printed – which makes it easy to refactor later if I need to use those values for something other than printing

• It's obvious that all of the cases are handled

• In an amazing coincidence, it looks like code I write :) so I personally prefer it

If you're implying that there are times that if/elif/else syntax is more readable than pattern matching, then yes, absolutely! There are times when one is preferable, and times when the other is.

Pattern matching is especially nice when you need to include conditionals and types:

  vehicle match {
     case car: Car if (car.passengers > 2) => addToHovLane(car)
     case truck: Truck                     => reject("No trucks allowed")
     case _                                => totalTraffic += 1
  }

There's a lot of casting going on there, and it's all handled in the pattern match. Converting this to if/else statements would require a lot of type tests and intermediate variables. Personally, I think that would make things harder to read.

That said, sometimes (often!) the more compact code is, the harder it is to read. I think it's always worth taking a few extra characters to improver readability. So I only use pattern matching with types and discards when I think it makes the code more readable and more flexible (e.g. easier to refactor, improves separation of concerns).

BTW, thanks for pushing back on this. I'm working on the 4th edition of Head First C# (O'Reilly), and C# added syntax very similar to this (borrowed from F#). Writing this reply gave me the opportunity to start thinking through how I want to teach it.

[war1025]

Pattern matching seems like a useful technique. The languages I use most often don't have it, so I haven't used it much personally. I can see how it would be nice to have for your vehicle example and things like that. FizzBuzz is just so trivial that I don't think the benefits really shine through as benefits and seem more like just alternate syntax.

[setr]

Well for one, the cases of a match statement are guaranteed to use the same variables and return the same output, in every case — the equivalent if-elseif-else does not offer the same guarantees, and has to be read in full to reach the same conclusion

So the statements are equivalent in whole, but the difference is that a match statement requires less reading (as it holds more meaning)

[pmontra]

I agree with you. Pattern matching is detrimental to readability in this case. Everybody can understand your example above. The pattern matching one leaves me a little O_o (pun intended) despite I'm using pattern matching everyday in Elixir.

Sometimes boring code beats clever code.

[Someone]

I think that’s more a matter of familiarity than of readability proper. The same argument could have been made against Arabic numerals, against the use of “=“ for assignment and “==“ for equality (“=“ had been used in mathematics for equality for ¿centuries?), etc.

One could also argue that, by using the knowledge that “is divisible by 3 and 5” is equivalent to “is divisible by 15”, the code using %15 is cleverer than the example that just follows the problem description.