Python will be eradicated
Python will not just die, it will be eradicated, and your favorite language likely will to. Uncomfortable bold statement, but I'll back it up.
I've been listening lately as members of the Python community lay out their evidence of the eternal nature of Python. Their pious proof boils down to:
Some will venture out and call it a "glue code", and that it's performance is misunderstood. (This post isn't about performance, that war is won and it's hard to beat hand rolled C).
Let's kill off claim one: "It's Old"
There is this idea that because a language has been around for a long time, that it will continue to be around for a long time. By some virtue of time in grade, it must have proven it's stripes to warrant special treatment. In reality, code lives for one purpose: to run working software.
If business economics protecting old technology are changed, there is a point in which old technology is detrimental to the mission and the opportunity cost for change is higher than staying the same.
People also point me at COBOL as proof that old technologies never die... the opportunity cost has shifted there as well.
Claim two: "There are trillions of lines of code"
This is text book sunk cost fallacy. Just because the investment was made, doesn't mean you hold onto it for the sake of it being large, or that you double down.
What many python pundits forget when they argue that "code depth" is the reason it will never die, is that python is simply repeating the same 20-30 operators and 4-7 data structures over and over again. Just because there is "a lot of code", doesn't mean there should be, and it doesn't mean it is enshrined in imperishable crystal.
Graphing, profiling, and categorizing Python in production is what security software is doing (or should be), is it far fetched to imagine a world where production python code is reduced and converted to statically typed code?
Claim three: "There is an active community"
There are +11M devs that claim Python proficiency (JetBrains 2022) of the roughly 47M devs (SlashData) in the world. When you start adding up the devs that claim efficiency in other popular languages we begin to ask ourselves, how many exclusively use Python? Any guesses? As any developer will tell you, they almost all use more than one language. Developers are fans, not loyalist. If something makes their lives easier and/or pays more, they'll switch. That's how we got python in the first place.
The reality is, fans don't want python to die, not that it can't or that it won't. Unfortunately, the world doesn't run on wishes.
That said, there have been some crossroads appearing in the Python communities and the grumbling has been getting louder.
Companies like Meta have weighed Python and been actively approaching gain-in-efficiency (freebase C, remove the GIL) like they approached performance gains in PHP. They are proposing that it may be easier to fix Python than replace it like they have done before. Before, they didn't have tireless algorithms that were capable of multi-trillion line re-writes...
However re-writes alone (particularly algorithmic ones), have no assurance of completeness or correctness. This ambiguity of the dynamic nature of the language has led to proposals for progressive type systems (like Microsoft proposed for javascript with Typescript and now is being proposed for Elixir). What we are finding is that progressive type systems are not assurances either.
TLDR; Complete and Correct or Nothing.
Recommended by LinkedIn
My high level of conviction that python and most other will not just die but be eradicated in just a few years comes from several hundred hours of experimentation. If you think I'm about say "AI will kill it", you'd only be about 10% right.
Instead, what we've found:
can convert exceptionally large codebases into a statically typed graph that AI tools can utilize.
Reduce, Refactor, Recycle
However, the squeeze doesn't stop at just re-writes, it's all about "Reduce, Refactor, Recycle".
Most code in the world is a duplicate variation of other code, and code that's not, is trying to get around IP laws. Very precious little unique code exists, the uniqueness is mostly derived from the inputs and outputs of data in to the code.
As re-write costs race towards zero we are finding (that like most business processes) we have endless inefficiencies. We've just never had the tools to identify them at this scale before. It is now common to analyze an organizations' business and software processes and discover that active initiatives are just re-hashes of older processes up the chain, just carrying the baggage of history.
Given the right tools, business leaders equipped with confidence in those tools, will begin to order mass reduction of historical codebases, refactors into business rule code, and find ways to recycle those rules to complete the organization's mission.
What is Business Rule Code?
If you've read my posts before, I don't like to throw shade without providing a working alternative. In this case, the alternative is re-learning how to "code" in business rules. But what is a Business Rule?
Business rule code is what it sounds like. It's effectively an abstract that can complete any function of the business. Imagine it like this:
Any complex system that works is built on simple systems that work, And any simple system that work can make complex systems that work.
In the early days of "programming" there was very little code. It mostly reflected math problems. As higher level languages evolved, most code became oriented in other outcomes than just the most efficient solutions. Now, we are finding that inputs that lead to ideal outputs is a suitable alternative that is cheaper, easier to reason about, and more efficient.
To quickly wrap this up, it's Friday after all...
As the world's former "cheapest" CTO and now CEO of Squillo , over a decade ago I realized that almost any business rule could fit into a SQL database if it followed some simple rules. As such, N Lang was born (in which #Rust is a first class citizen). This is the ultimate way to express business rules and do all of what was discussed in this article. I can't wait to share it with you!
If you enjoyed this article, let me know!
Wishful thinking. You sort of point at the inertia of languages - but the reality is that so much stuff getting written in these languages that just isn't going away any time soon. Though in Python's case, where's the viable replacement for TensorFlow? I don't mean something written in C or similar, where's the replacement for TensorFlow, Pandas, etc. in a language that people can just use? And by people, I mean people who aren't deep-dive devs but that just need to get things done. The data analysis folks. The research scientists. They're not paying devs, nor are they devs, but they need a tool they can use to do this - and LLMs aren't it either. Until there's another decently high level language that is expressive, easy enough to dig into to get things done that doesn't bury people under syntax, but allows specificity and precision, with a lack of ambiguity and a presence of reproducibility, Python's going nowhere. PHP's more likely to die off than Python at this rate, and people have been declaring it dead for nearly 30 years... but it's still here and still getting the job done.
Psst ... 🤣
I've tried to rid the world of this crap for a decade, without success. On average Hyperlambda is 5 times as fast, and 1,000 times more scalable (because of Python's GC), and you only need 5% of the codebase - Still the thing is alive.
Are you suggesting Rust will become the de facto data engineering language? What’s the next best alternative if it isn’t Rust? Don’t the data engineering libraries matter as much as the language details themselves?
*laughs in Fortran*