Fix your shit

Most of the "points" you had in here are completely ridiculous and make no sense in the modern versions of Python.
Maybe you should stop using Python from the 90s and use the latest version.

Signed-off-by: SkyTheCodeMaster <pythoniscool@skystuff.games>
This commit is contained in:
SkyTheCodeMaster 2022-05-04 22:32:08 +00:00
parent 53309a5fb4
commit b2a4e0ff2f

View file

@ -1,42 +1,23 @@
+++ +++
title = "Why python is a bad language" title = "Why Python is a 'bad' language"
+++ +++
{{ sec_header(name="Weird Syntax") }} {{ sec_header(name="Weird Syntax") }}
- It is hard to read, because it is missing semicolons and braces. - It is hard to read, because it is missing semicolons and braces.
- Indentation as a syntactical element is just silly. This takes away freedom from the developer and makes the code less readable without any benefit.
- Indentation-dependant scopes make multiple statements on one line look horrible. - Indentation-dependant scopes make multiple statements on one line look horrible.
- Doc comments - Doc comments
- They use triple quotes which doesn't make sense for a comment.
- They go under what they are documenting, which looks wrong and is very unusual. - They go under what they are documenting, which looks wrong and is very unusual.
- They are technically not comments, which is a terrible idea.
- They are accessible at runtime, but shouldn't since this encourages spaghetti code.
- The `def` keyword does not imply a function, so one may think it is declaring a variable, or something else. - The `def` keyword does not imply a function, so one may think it is declaring a variable, or something else.
- Strange naming - Strange naming
- `__init__` or `__add__` looks like an internal function. That these define operators looks like someone was too lazy to do this properly (yet again!).
- Exception handling using `raise` and `except` instead of the usual `throw` and `catch`. There is literally no point to do this, and it confuses users. - Exception handling using `raise` and `except` instead of the usual `throw` and `catch`. There is literally no point to do this, and it confuses users.
- Same goes for `elif` instead of `else if`. This is just pointless, and again looks like a lazy implementation. - Same goes for `elif` instead of `else if`. This is just pointless, and again looks like a lazy implementation.
- Strange symbols
- `not`, `and` and `or` instead of the more conventional and cleaner looking `!`, `&&` and `||`.
- Normal `if` and `else` statements are not expressions. If they were, the additional ternary operator syntax would be completely redundant, and the code would be cleaner. - Normal `if` and `else` statements are not expressions. If they were, the additional ternary operator syntax would be completely redundant, and the code would be cleaner.
- The syntax for inheritance looks really confusing. `Foo(Bar)` looks like `Foo` has a constructor that takes a `Bar` as an argument, and not like `Foo` extends `Bar`. - The syntax for inheritance looks really confusing. `class Foo(Bar)` looks like `Foo` has a constructor that takes a `Bar` as an argument, and not like `Foo` extends `Bar`.
- For some reason, the `pass` keyword exists. Why can't we just leave the block empty or omit the `:`? Yet another lazy implementation! - For some reason, the `pass` keyword exists. Why can't we just leave the block empty or omit the `:`? Yet another lazy implementation!
- The recently added `:=` (assignment expression) operator exists, instead of simply making the normal assignment (`=`) an expression. - `True` and `False` are capitalized which is unconventional.
- `True` and `False` are capitalized which is unconventional and annoying.
- Functions can have named arguments like `foo(bar=baz)` which looks strange, and instead functions should just take dictionaries instead like `foo({bar: baz})`
{{ sec_header(name="Lacking Features") }}
- Lambdas are a poorly implemented afterthought.
- There is absolutely no `switch` statement or anything along those lines, leading to absolutely **HUGE** `elif` blocks!
{{ sec_header(name="Intepreter") }}
- Intepreters lead to runtime errors which could otherwise be detected at compile time. This often causes bad errors to make it into production due to untested edge cases.
- **Very bad** performance.
- Python is hard to package. Of course tools exist that can do it, but they are slow and large as they always include the interpreter as opposed to compiling the code or using some sort of faster intermediate language. Packaged python also includes the source code, which may be undesirable.
{{ sec_header(name="Dynamic Typing") }} {{ sec_header(name="Dynamic Typing") }}
- Passing an invalid type into a function may cause unpredictable behaviour. Manual type checks are annoying, and type hints are still just hints. - Passing an invalid type into a function may cause unpredictable behaviour. Manual type checks are annoying, and type hints are still just hints.
- It is often unclear what type a function is expecting, thus it can be hard to know how to call it, especially if it is undocumented.
- A function can return whatever type it wants, so it is hard to work with and unpredictable. - A function can return whatever type it wants, so it is hard to work with and unpredictable.
- Variables don't need to be declared. This leads to many issues, such as accidentally overwriting other variables with the same name, or typos going undetected. - Variables don't need to be declared. This leads to many issues, such as accidentally overwriting other variables with the same name, or typos going undetected.
- A variable's type may be changed after its assignment, making it harder to work with. - A variable's type may be changed after its assignment, making it harder to work with.
@ -44,22 +25,10 @@ title = "Why python is a bad language"
{{ sec_header(name="Poorly done Classes") }} {{ sec_header(name="Poorly done Classes") }}
- The `self` parameter being passed into functions explicitly is pointless boilerplate. Instead it should just be there implicitly, and static functions should be declared with a keyword such as `static`. - The `self` parameter being passed into functions explicitly is pointless boilerplate. Instead it should just be there implicitly, and static functions should be declared with a keyword such as `static`.
- Fields do not need to be declared. This leads to issues mentioned before. It also makes the data a class stores undefined, making it harder to work with. It is recommended to declare fields, but unfortunately not enforced. - Fields do not need to be declared. This leads to issues mentioned before. It also makes the data a class stores undefined, making it harder to work with. It is recommended to declare fields, but unfortunately not enforced.
- Enums are basically just classes, and are yet another lazy afterthought.
{{ sec_header(name="Wide Spread Because Of The Wrong Reason") }}
- Python is seen as "the beginner's language", and it really should not be. As said earlier on this website, Python has numerous issues that stop the newbie from quickly getting used to other PLs, by lacking basic functions.
- Python should only be used if you wanna handicap yourself into an inferior PL, just to see what you can do. No more, no less.
{{ sec_header(name="Other Issues") }} {{ sec_header(name="Other Issues") }}
- Strings can be evaluated as code, also encouraging spaghetti code.
- Doc comments are available at runtime using `help(element)`, and they should not be, because this too encourages spaghetti code.
- The command line REPL prints `Use exit() or Ctrl-Z plus Return to exit` for no reason, instead of simply exiting.
- Operator chaning often works in completely nonsensical ways. For example `False == False in [False]` is treated as `False == False and False in [False]` and not as something that makes sense such as `(False == False) in [False]` or `False == (False in [False])`. - Operator chaning often works in completely nonsensical ways. For example `False == False in [False]` is treated as `False == False and False in [False]` and not as something that makes sense such as `(False == False) in [False]` or `False == (False in [False])`.
{{ sec_header(name="Conclusion") }} {{ sec_header(name="Conclusion") }}
Python is a bad programming language that no one should use. Please don't hesitate to quit using programs made in Python. If you continue using them, it will motivate the Python devs to keep making this garbage, plus programs written in Python are usually **VERY** slow. And NEVER, EVER, EVER, EVER use Python in your own programming shenanigans. It's YOUR project. You have full control over it. Why even use Python if that's the case? Python is a perfectly fine language for beginners and experienced devs alike. There is nothing wrong with using it directly, or programs made with it.
And, one more thing:
Please spread the site so more people know the truth. It would mean the world to me. Thanks.