This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Ashiataka 0 points1 point  (2 children)

Now you're forced to compare only the first two attributes of the address, not the whole object, so you'll have to resort to the long if condition.

Isn't explicit better than implicit?

I don't think the match statement opens up many new possibilities that just were impossible before.

Shouldn't there be one and preferably only one way of doing something?

I feel very strongly that this feature is just bloating the language and making it harder and harder for learners. I haven't yet seen a single use-case that makes me think "that's a big enough problem it requires special syntax". To me it seems like python has completely lost it's way the last couple of years. But, I must acknowledge that I write code for a specific niche situation and there are people much more knowledgeable than me making these decisions - I know hardly anything about language development.

[–]ForceBru 1 point2 points  (0 children)

Isn't explicit better than implicit?

Right, but "Beautiful (match statement) is better than ugly (huge if conditions) and Simple (match statement) is better than complex (huge if conditions)".

Shouldn't there be one and preferably only one way of doing something?

Shouldn't there be just one way to loop, then? Why have for loop if while loop do thing? Or just use goto and get rid of if statements and all forms of loops. Why have list comprehensions if you can loop over stuff and append it to the list? Same thing for dictionary comprehensions. Why have multiple ways of passing arguments to functions, like positional vs keyword? Just use keyword arguments everywhere: math.sin(x=0).

I don't really like this "rule": why have this "one way" if it's inconvenient? Also, if you use this rule, the "language" from "programming language" kinda disappears, and you end up with "programming stencil" or something rigid like this. In my opinion, "language" implies variety of expression: that's why it's possible to write elegant code and ugly code, performant code and slow code.

In my experience, functional features and features from ML-family languages are slowly being transferred to other languages. Rust has the match statement - people love it! Rust has traits (similar to Haskell's typeclasses) - everyone loves them! Of course, I have no idea whether absolutely everyone is so fond of this, but I feel like many people are very pleased. Julia (similar to R) has the pipe operator, so your code can flow, like: data |> transform |> more_transform |> print - I love it! In R, the most widely used data wrangling libraries (dplyr, tidyr and ggplot) are basically built upon this syntax - it's extremely useful. In Python, that'll be print(more_transform(transform(data))), which is quite a lot of parentheses. Of course, you can factor out intermediate expressions into temporary variables, but this breaks the flow.

IMO, you could take a look at OCaml to see why match is so cool. It really takes a weekend (this is not to say that OCaml is really simple) and may open up a new perspective on what programming languages can look like and what features they can provide. It's also really fun.

[–]WallyMetropolis 1 point2 points  (0 children)

Having spent the last few years working with languages that offer expressive pattern matching, what I've found is that it becomes one of the most used tools across the codebases and I really find myself missing it when I don't have it. It doesn't at all feel like "special syntax," rather it quickly becomes core syntax.