21 ms·
The NIMBYism is strong in this thread. There is nothing about this feature that will make Python any harder to learn for newcomers. You can choose not to use it
by whalesalad 6y ago
The NIMBYism is strong in this thread. There is nothing about this feature that will make Python any harder to learn for newcomers. You can choose not to use it.
- kazinator 6y ago> you can choose not to use it What's more, you can even choose not to understand it. An easy way to do that is to choose not to work with other people's Python code. Don't apply for Python jobs, and in a non-Python job, dodge tasks that involve touching Python code that contains constructs you don't wish to understand.
- whalesalad 6y agoGotta make up your mind here - are we complaining about newcomers to the language or professionals? If you are a professional programmer there is nothing about this change that should phase you. In fact, if you are a professional Python programmer this should be an exciting addition. My argument still stands. I am so sick of people complaining about progress, especially armchair quarterbacks on HN.
- kazinator 6y agoI'm only saying that the "don't use parts you don't like" argument has limited applicability. We have to acknowledge that some newcomers are eager to learn everything, and that a bigger everything is harder than a smaller everything. That's just a fact; it doesn't meant that a smaller everything is better. Now that Python has pattern matching, newcomers should learn it. In my opinion, newcomers should learn pattern matching before they learn lower-level, more verbose ways of writing code for classifying objects for type, shape and content. The more verbose code should be the appendix, like "in older Python before pattern maching, we would have had to write it like this ...". Or, to put it alternatively, newcomers no longer should learn how to use basic primitives like if comparisons and whatnot, to write code which combines multiple tests for object type, shape and content in multiple cases. They should be steered toward pattern matching, with a caution about how that is new and doesn't work with Python versions lower than x.y.z. Pattern matching is particularly good for beginner programmers, because beginners programmers are not good at planning the design of a program ahead of time: they don't have an intuition for the right data structures and such. Pattern matching can patch over some representational difficulties/tensions in the program so that the code looks good and is easy to reason about and debug. If all you have is a switch/case type statement, you might be told that, at some point, the pain you're feeling is from abusing that and should switch to something else, like proper OOP. In some of those same situations, you could instead switch to pattern matching. Pattern matching is less abstract and more literal-minded, since it uses "pictures" of data, which can overcome disparities in its structuring in a way that looks obvious in the code. Pattern matching has processing "under the hood", but what that does is not only largely intuitive, but also localized to the spot in the program where it is happening. I believe all of that favors the skill level of newbies. The pitfalls in this miserable implementation are another story, but I think that will only help Python. Pitfalls bring Python people together to form communities and help each other. People band together and cooperate when they have common enemies, like sabre-toothed tigers, inclement weather or shitty programming languages and systems. The six-week-old Python newbie is eager to explain the quirks of pattern matching to the day-old newbies, and so it goes. Other than the Python-specific quirks, newbies will likely struggle with bugs involving the order of pattern matching cases, when they place a more general case before a more specific one, such that it unexpectedly takes some (or even all) matches from that one. Adding new cases to a pattern matching block ahead of existing cases is tricky, if they match anything in common. With pattern matching, you can write a small amount of code that handles a lot of ad hoc complexity---and if that doesn't have test coverage, that can spell trouble.
- pansa2 6y ago> You can choose not to use it. I hear this a lot about features in Python. Type hints, dataclasses, walruses, and now pattern matching. Whenever someone complains about language bloat, the reply is “it’s optional”. But that’s only true as long as you’re writing code by yourself. Most developers spend much more time reading code than writing it, and with no control over which features others use, it’s necessary to be comfortable with the entire language.
- memco 6y agoOn the flip side: whole projects are stuck on older versions so even though something like the walrus is interesting and could be useful no one else on the team has any interest in doing the work of switching to a newer version so none of the new features matter.
- slightwinder 6y agoBut you can't choose that other are not using them. If you read other peoples code, and beginner will do that a lot at some point, then you will likely encounter unknown syntax. Good if you read if for that purpose, bad if you just wanna enhance/fix the code.
- ledauphin 6y agois unknown syntax that much more of an issue than unknown function/library calls? I very much doubt it. If it were, the industry would have settled on languages with way less syntax a while ago, e.g. Clojure. At least with unknown syntax there's usually some kind of keyword you can look up with Google. It's generally the non-syntactic sorts of unknowns that are much harder to figure out for a given codebase.
- fulafel 6y agoIt's a much easier to look up library functions than language keywords in Python docs, and it's one of the first things Python programmers learn.
- mixmastamyk 6y agoFalse. There are multiple documented footguns and inconsistencies that will baffle newcomers and pros alike. The quality of this proposal is much lower than other new features of the last decade.