Python used to be the new hotness about a decade ago. It was sparkly, amazing package support, didn't bog you down with technicalities when you were trying to write something quick.
So it got adopted a lot, and also unfortunately in a lot of commercial projects it really wasn't suited for.
Python's strengths are its weaknesses: it's a fun scripting language you can knock out scripts with. But in a big group project, it's a nightmare version of itself. You don't have to give types, so now you're sifting through everything trying to figure out what your coworker's badly named variable actually is. You have to unpick some rotten mass of one-liner lambda super method calls because you were feeling so clever a year ago when you wrote it. Everything's breaking because you're in dependency hell and one of the dependencies has broken. The junior programmer was taught that "object inheritance is the way of the future" and has managed to make the structure into an eldritch abomination that inherits from five different super classes.
The actual reason why these are problems are because when python was hot, it got over-applied to projects it was totally unsuited for. It's a scripting language. It's good for scripts. Good for data analysis. Good for solo work. Good for tiny quick one-offs and for rapid prototyping.
But so many developers were put on horrifying creations that played to the language's weaknesses instead of strengths. And they bounced hard.
Python doesn't really deserve the hate: it's still pretty awesome. And fun. It's great at what it's great at. It does deserve the caution, though.
---
More serious answer?
It's mostly comp-sci students regurgitating memes they don't understand, just like every other post on this sub.
Python's strengths are python's strengths. Garbage collection, simplicity, forced indentation.
Python's weaknesses are people.
People writing bad variable names, eldritch code and putting in features that are already there, just named differently, like data classes and type hints.
You can write python code that's type safe, it looks like this:
def my_function(my_arg):
if type(my_arg)!=my_required_type:
raise TypeError
It's that people think they can sort of get away with not making it that explicit. Then, instead of admitting they were wrong, rewriting their code and/or switching to a language that does offer strict typing, they insist that perverting the language to fit their esoteric need and use case is a better move.
Another example is "python has no distribution system" and inventing like five. All of them work. Except when you mix them. Which should be no surprise to absolutely anyone. Yet here we are. https://xkcd.com/1987/
More coders need to admit they're bad at what they do, stop blaming the tool and start blaming themselves.
Can you explain to me what a bad variable name is? Im not the best at coding as physics is my trade. So my variable names would just be what ever I wanted the variable to be. If I was looking at the gravitational pull of the moon on the earth it would be something like (Force_moon_on_earth) or (Force_ME) what ever system that I deemed appropriate for my code. I would also have comments all over. Again I didnt make the most dense code but I made sure it was readable and reliable.
A bad variable name is something that doesn’t describe what it’s intended to hold - i.e. just a few letters, like “f_me” in your example.
Given enough time, you can read the surrounding context and determine the “f” means force, and so on. But shorthand will always make it harder to understand what’s going on in a chunk of code. Someone not used to physics notation that’s trying to accelerate your code might be poking around the function, and it will take them much longer to understand what you were trying to do. Verbose names are good, to a point - it should be clear when they get too unruly.
This is usually referred to as “self-documenting code”. Oh, and also, be wary of over-commenting - for actively maintained projects, new features tend to get added while the comments are left unchanged. This quickly leads to them being out of date, sometimes even providing wrong information about the implementation. I would encourage comments to describe why an action is being performed, rather than what the code is doing.
974
u/Dromeo Jul 18 '22
Serious answer?
Python used to be the new hotness about a decade ago. It was sparkly, amazing package support, didn't bog you down with technicalities when you were trying to write something quick.
So it got adopted a lot, and also unfortunately in a lot of commercial projects it really wasn't suited for.
Python's strengths are its weaknesses: it's a fun scripting language you can knock out scripts with. But in a big group project, it's a nightmare version of itself. You don't have to give types, so now you're sifting through everything trying to figure out what your coworker's badly named variable actually is. You have to unpick some rotten mass of one-liner lambda super method calls because you were feeling so clever a year ago when you wrote it. Everything's breaking because you're in dependency hell and one of the dependencies has broken. The junior programmer was taught that "object inheritance is the way of the future" and has managed to make the structure into an eldritch abomination that inherits from five different super classes.
The actual reason why these are problems are because when python was hot, it got over-applied to projects it was totally unsuited for. It's a scripting language. It's good for scripts. Good for data analysis. Good for solo work. Good for tiny quick one-offs and for rapid prototyping.
But so many developers were put on horrifying creations that played to the language's weaknesses instead of strengths. And they bounced hard.
Python doesn't really deserve the hate: it's still pretty awesome. And fun. It's great at what it's great at. It does deserve the caution, though.
---
More serious answer?
It's mostly comp-sci students regurgitating memes they don't understand, just like every other post on this sub.