Do Not Use Python Unless You Must
💢 “So then because thou art lukewarm, and neither cold nor hot, I will spew thee out of my mouth.” (Revelations 3:16)
Some people say Python is a good duct tape coding language, but it really isn’t. Python is too heavy and inflexible for duct taping immediate solutions and too light for serious software development. This leaves Python in it’s dopey, lukewarm happy place — not the best at anything but okay for a lot of things.
“Hell, SQLite and GTK+ are built in and who doesn’t want that!?”
No one who actually has a clue.
“But Python is the fastest growing language because of data science!”
That’s factually incorrect. 51% of all Python usage is on legacy server-side back-end web development, not “data science”.
Some people think this is what makes Python so great.
It isn’t great.
Python may be super trendy and growing fast in popularity, but at it’s heart Python is an ancient, legacy language with unfixable problems and it shows.
Something Simple Like Default Variable Assignment
Take something as simple as default variable assignment.
Most Python programmers don’t even know such things exist.
Most Still Use Python for Web Development
Even though 2013 exploded with high-profile blogs about companies like DropBox porting everything from Python to Go and seeing 30-40% efficiency gains 54% of Python Development is still for Web development.
That means most of Python modern development is legacy development of server-side web platforms where Python is well-known to be horribly inefficient. This usage of Python is the same as all the people still using Java — because they have a huge dependency on it from years of development in it and too much technical debt to upgrade. I would bet most of it is Python 2.
Just because something is used a lot does not make it good. People still use the yards to measure things but the intelligent people use meters.
Your preferences do not change objective facts no matter how much you might not like them.
“4 out of 5 Python developers use it as their main language.” (2017 JetBrains Python Developer Survey
Look, it’s natural to have a special place in your heart for your first language. Many would say every language you learn from that point on will be compared to it. But Python should never be that first language.
I have personally witnessed brilliant young coders who learned Python first refuse to learn other languages because their initial bias toward Python is so overwhelming. This is one reason TensorFlow Python still has such a strong hold even though Python is clearly a horrible language for enterprise-scale machine learning applications development.
💢 This one made me very angry to discover over the first five years teaching it to members. It felt like a bad breakup or divorce. I fell in love with Python myself only to discover everything I thought about it was actually just lies put forth by the zealous and dogmatic Python community.
I blame whitespace for this. Sure Python looks simpler and cleaner than the other languages, but it is also that very difference from every other language that makes is so insidiously bad as a first language. When a junior programmer sees curly brackets used for blocks for the first time it is totally foreign to them even though curly bracket blocks are in every other major programming language.
The great tragedy of this is that these bigots never see the flaws inhibiting their progress, they become defensive and prone to Python dogma, which is based on broken hypocrisy.
[Don’t become a one-trick Python pony.]
Python for Machine Learning
Google openly admits it only chose Python first for TensorFlow because a lot of scientists were already using it. Scientists might like Python for being great to duct tape scientific models together, but as machine learning and data science continue to become mainstream and needed by enterprise-scale applications writing them in a duck typed language is a preposterously unsustainable position — especially for applications that will be so involved with very important data.
Let’s look at database science for the last 50 years. The SQL language came about because identifying data types down to their specific length was a major requirement to maintain the
ACID compliance. Organization data integrity and durability are so important to most bottom lines that it has almost always received top priority. That is why database administrators have made six figures since the 70s. Data are the corporate jewels of all companies (including mine).
In contrast, most Python coders — especially scientists — have no idea what ACID even is (go on, ask them next time).
Scientists have different needs than a corporation dependent critically on data integrity — which is really weird because you would think data integrity would be the top priority of a scientist — but for some reason they insist on liking a language that doesn’t even have constants or data types and a very bad history with the
// operators. I guess scientists can be just as irrational as the rest of us.
Some in the industry tried to drop SQL — with the NoSQL movement — but it fell on its face with large corporations — including Twitter — scrambling to get (back) onto a “proper” database as soon as possible. Turns out data integrity and constraints actually do matter.
The reasons “proper” SQL databases are required for all applications that actually matter in the long term are the very same reasons Python will ultimately fail as the darling language of machine learning:
- Python has no constants.
- Python has almost zero data types of any kind.
- Python was never meant to be anything more than a scripting language.
That makes those choosing Python for core systems in their organization architecture massive failures responsible for cementing decades of future technical debt and costly unforeseen problems.
📰 This is exactly why Facebook contributed TensorFlow bindings in Go, which was created at Google to replace Python and C++ for many of these uses.
Mainstream Machine Learning Demands More Than Python
Go Destroys Python for Most Use Cases
“Anywhere Python is used you can replace it easily with Go.” (Ignat Korchagin)
In fact, the only reason Go isn’t the darling machine learning language is because a lot of very smart people are too bothered, old, or stupid to learn Go. That’s just the plain facts. Even Google agrees.
😕 And Google’s concurrency is ridiculously better than the currently conflicting
async/awaitimplemented in Python 3.7 that causes it to be incompatible with the latest TensorFlow.
The reality is that corporate imperatives and needs will ultimately trump these lazy scientists and make Go, Rust or C++ the top machine learning language for applications that actually matter.
💢 Python is a brain-dead stupid choice for those who want to learn machine learning and be able to develop sustainable, enterprise-level applications in the future. But there are a lot of uninformed and short-sighted machine learning developers at the moment.
- is more available to you,
- has the most modern syntax,
- gives you more possibilities,
- deals better with concurrency, and
- helps you learn other languages faster later.
And No Python Didn’t Beat Perl, Bash Did
Once upon a time Perl was the king of duct tape languages — not to mention all server-side web development.
A lot of misinformed people think Python beat Perl — but it was actually mostly Bash that caught up removing most reasons to keep using Perl. We’ll never have any formal numbers on this because most coding is informal and never represented in surveys and organizational studies.
Python Does have Better Objects
Everything in Python is an object. That was once thought to be a good thing. It’s not. Brian Cantrill, (CTO of Joyent) called the 90s emergence of OOP a “time when great darkness fell across the land.” OOP was a massive failure.
Python did take over for those wanting more formality for larger projects and a better OOP approach — which isn’t duct tape coding at that point — but then Go and Rust and TypeScript happened and Python’s usefulness was obliterated. You won’t hear that from the one-trick-ponies — because they can’t grok it. 🤪
The Infamous Python Whitespace Problem
Python was the first significant language to use syntactically significant whitespace. It is one of the most moronic, brain-dead, unethical, evil language design decisions in history. It permanently crippled Python and all the applications that use it.
🤔 Do your own research.
There are so many problems with this it is hard to list them all, but the absolute biggest issue for most beginning and advanced programmers is how badly it cripples them from doing something as simple as cutting and pasting code from another program.
When you copy a bock of code from someplace else you cannot just run your linter and have it fix all your indentation. Tab and untab that newly pasted block to exactly the right level.
And God help you if you have long lines, which Python promotes with its comprehensions. Your editor will start to look like the worst spaghetti code on the planet.
Python is supposed to be the best at writing readable code and yet some of the most unreadable code I have ever seen was written in “idiomatic Python.” Python failed at most of its core missions outlined in the Zen of Python — most of all with the use of whitespace.
By the way, whitespace is the main reason anonymous functions never made it into Python even though pretty much every other language on the planet has them. They certainly tried. The email thread of them trying to work it out is absolutely hilarious to read now. At every turn it was the whitespace that stopped them from creating them. It is one of the dirtiest of secrets most Python programmers don’t know and will never be told. Instead you will get some story about how “they really aren’t needed” (which just makes me laugh out loud when I hear it).
Lack of Any Strong Terminal Support
Libraries like Go’s TView destroy Python for creating text-based interfaces. The binaries that Go produces are usable as is on any target device for this Go can be cross-compiled. To obtain the same with Python you would have to install the right Python — or worse — a Python “virtual environment” before you can even get the Python script. Then you have to wait for the thing to start and pray you have a portable terminal graphics library you can actually use.
Go was born to replace Python for these sort of distributed text-based terminal utilities which have had true concurrency built in with the language instead of bolted on like Python keeps attempting to do.
Python is absolutely horrible at this stuff.
“But Python has built in GTK support?”
Who cares. It’s a terminal-centric world and your GTK app looks intensely ugly. If you need graphics that bad use Electron and leverage all that Web technology has to offer.
💢 Having just embarked in a terminal version of my member database management terminal app in Go after having made GTK and terminal apps in Python I am absolutely disgusted by how completely horrible Python is. It’s an absolute embarrassment to the Python community. No wonder Guido finally stepped down.