Skip to content

Commit

Permalink
Update 2024-05-03-python-you-have-problems.md
Browse files Browse the repository at this point in the history
  • Loading branch information
LandonTClipp committed May 6, 2024
1 parent d1a407a commit ca1f443
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion docs/blog/posts/2024-05-03-python-you-have-problems.md
Original file line number Diff line number Diff line change
Expand Up @@ -380,7 +380,7 @@ Hopefully by this point, I've successfully enumerated my varying complaints with

Any time a huge amount of complexity is introduced into a system to solve some fundamental problem, that usually means that the foundational model on which that system depends is inherently flawed. In Python's case, package management, lack of strict typing, its GIL, its concurrency primitives, are all examples of things that are just foundationally bad. Their existence necessitates a huge amount of complexity in the Python ecosystem that should have, and could have, been solved by changing the underlying model, but for reasons that I totally understand, at this point in Python's life, doing such a thing would be totally infeasible. Just look at how painful the Python 2->3 conversion was, we're still dealing with the affects of it 16 years later!

It is totally absurd to me how much talent is wasted in solving these kinds of problems. In my view, the only reason why these problems are worth solving at all is because Python's momentum is so great that asking people to use something else is often just not practical. If it had obtained less popularity, my reaction would be to totally abandon the language altogether because these issues are real dealbreakers from a reliability and time efficiency perspective. The proliferation of packaging tools, of the existence of asyncio and function coloring, the large number of different implementations of the language itself (I mean come on, _seriously?_), all point to the fact that what was given to us in the reference implementation of the language (obviously, CPython) is just simply inadequate. So much incredible talent, creating admittedly incredible solutions, has been spent working around what is fundamentally a big stinky :poop:.
It is totally absurd to me how much talent is wasted in solving these kinds of problems. In my view, the only reason why these problems are worth solving at all is because Python's momentum is so great that asking people to use something else is often just not practical. If it had obtained less popularity, my reaction would be to totally abandon the language altogether because these issues are real dealbreakers from a reliability and time efficiency perspective. The proliferation of packaging tools, of the existence of asyncio and function coloring, the large number of different implementations of the language itself (I mean come on, _seriously?_), all point to the fact that what was given to us in the reference implementation of the language (obviously, CPython) is just simply inadequate. So much incredible talent, creating admittedly incredible solutions, has been spent working around what is fundamentally a big stinky pile of :poop:.

It should also be noted that one of Python's main selling points is that it's so easy to use, so much so that it's often the first language developers learn. This is only a shallow marketing tactic because once you peel back the veil and see the man behind the curtain, you realize how unfriendly becomes. This is in fact a common complaint amongst newcomers that the proliferation of tooling, and the lack of any real standard for just about _anything_, can make it difficult to become effective at the language in a professional environment.

Expand Down

0 comments on commit ca1f443

Please sign in to comment.