It'll most likely be abandoned in droves. One of the main reasons to stick with C++ (and C) is that the investment you put in the code you're writing right now, no matter how fugly it is, will be there and keep working in the future.
Also:
> I think it also makes sense for C++ developers whose projects are relatively short-lived, e.g. some games.
There is a difference between games and engines - the games might be short lived, but most C++ engines are very long lived, going back decades (e.g. see how the recent Half-Life Alyx can trace its codebase back to Quake 1 or pretty much anything based on the Unreal Engine going back to the mid-90s - there are screenshots of UE1 running on what appears to be either Windows 3.1 or NT 3.51). Even when "engines" are being made "from scratch" this is often a marketing gimmick and the "from scratch" was just renaming the engine because it got a new rendering model and people can't tell the difference. EVEN when this isn't case, often new engines are based on existing code and/or libraries.
Agreed, I think looking at the Python 2 and 3 migration catastrophe gives a glimpse into what this could look like, but I imagine it would be much worse given the types of (large) projects that are backed by substantially "dated" C/C++ code.
The reasons the transitions worked were that:
- the languages were not that different, so no need to learn the new version
- python core devs gave 10 years to make the transition. Then extended it.
- it was possible to write code running on python 2 and 3
- python is very expressive, hence the code base have way less numbers of lines than in C++
- python cared only about one implementation, Cpython. The rest of the world needed to follow. Some didn't, like Jython and stackless, and the community didn't blink.
Despite all that, the transition was very painful.
> python is very expressive, hence the code base have way less numbers of lines than in C++
This doesn't match reality. In reality, many Python projects have way more lines of code than equivalent C++ projects. Probably because of the 'expressiveness' you cite; you can't really showcase your love of coding and job security though artificial complexity without 'expressive' bells and whistles. (This is the idea that lead to languages like Go, I'm pretty sure.)
That said, C++ is plenty 'expressive' itself.
> many Python projects have way more lines of code than equivalent C++ projects.
That is mathematically impossible. Even if the syntaxes were exactly the same (which they are not, python syntax is on average shorter), the low level nature of C++ requires your code to do operations that Python does need to do, such as memory management.
It's like stating the sky is red.
Once you've written sufficient unit tests to prove your code works as well as a C++ equivalent does just by compiling, I don't think Python ends up being more dense though.
I'd also argue that operator overloading etc lets C++ be just as expressive as Python, the libraries just need to be designed with that in mind.
> Once you've written sufficient unit tests to prove your code works as well as a C++ equivalent does just by compiling
You mean in the same way C++ dev write tests to prove that all their code has no memory error which you get in Python for free ?
Except:
- tests are way shorter to write in python than in C++
- C++ devs often write zero tests for their code, just like python devs
- python duck typing + REPL means compiler checks are rarely necessary
- if you need to be type checks, you use type hints in python, which even then is still less verbose than c++
> I'd also argue that operator overloading etc lets C++ be just as expressive as Python, the libraries just need to be designed with that in mind.
Ok, let's say you have this json:
[{
"name": "Kévin",
"age": 23,
"hired": "2005-06-03 02:12:33",
"emails": ["[email protected]", "[email protected]"]
}, {
}, {
"name": "Joël",
"age": 32,
"hired": "2003-01-02 12:32:11",
"emails": ["[email protected]", "[email protected]"]
},
... other entries
]
You want to print people details in alphabetical order this way:
Joël (32) - 02/01/03:
- [email protected]
- [email protected]
Kévin (23) - 03/06/05:
- [email protected]
- [email protected]
... other entries
In Python 3.7, which is already 2 years old, the code would be:
import json
import datetime as dt
with open("agenda.json") as fd:
agenda = sorted(json.load(fd), key=lambda people: people["name"])
for people in agenda:
hired = dt.datetime.fromisoformat(people["hired"])
print(f'{people["name"]} ({people["age"]}) - {hired:%d/%m/%y}:')
for email in people["emails"]:
print(f" - {email}")
It's not specific to Python, you would get this expressiveness with Ruby or Perl.
I don't see in which world you would get that in regular, honest to god, day to day, portable C++.
You have to declare types, many includes, you'll have headers and a main function. You have the memory and references to manage.
It doesn't make C++ a bad language.
It doesn't make python a better language.
The C++ version will take way less RAM than the Python version for example.
It's just the nature of those languages implies that.
It's a bit longer in C++ but frankly not by that much :
#include
#include
#include
#include
#include
#include
int main()
{
using namespace nlohmann;
using namespace ranges;
const json parsed = json::parse(std::ifstream("/tmp/json/test.json"));
std::vector agenda(parsed.begin(), parsed.end());
sort(agenda, {}, [] (const auto& j) { return j["name"]; });
for(const auto& people : agenda) try {
std::tm t{};
std::istringstream(people["hired"].get()) >> std::get_time(&t, "%Y-%m-%d %H:%M:%S");
std::cout << people["name"] << " (" << people["age"] << ") - " << std::put_time(&t, "%d/%m/%y") << ": \n";
for(const auto& email : people["emails"])
std::cout << " - " << email << "\n";
} catch (...) { }
}This is getting ridiculous.
We went from:
> many Python projects have way more lines of code than equivalent C++ projects
To:
> It's a bit longer in C++ but frankly not by that much
With the proof being literally __twice__ more characters, with one line being more than a 100 characters long.
I understand that C++ doesn't have a native JSON lib, and sorting is a bit out there, but giving 3rd party lib access to Python feels like cheating:
import pandas as pd
agenda = pd.read_json("agenda.json", convert_dates=["hired"])
for _, (name, age, hired, emails) in agenda.sort_values("name").iterrows():
print(f"{name} ({age}) - {hired:%d/%m/%y}:")
for email in emails:
print(f" - {email}")
Now again, this is not so say "Python is better than C++". That's not the point.
If you want to write a game engine, C++ makes sense, verbosity doesn't matter, and you don't want the Python GC to kick in. If you want to iterate on your Saas product API quickly, it's probably not the best choice.
Why pretend otherwise? What the point of stating the sky is red?
To be fair to the C++ version, you need to give as many guarantees from your code as C++ does from compiling. To me, in this case this is mainly the output formatting. Python won't tell you until runtime that you have a malformatted string, so add in some unit tests to make sure your string formatting won't crash, and you'll be at a similar number of lines of code as the C++ or Rust version.
> Python won't tell you until runtime that you have a malformatted string
Neither will C++, as far as I know, or do you mean that the compiler will validate the formatting of the string literal (python has linters that will validate this too!).
Hell, even with statically verifiable types, the python is shorter.
With iostreams there are no format strings so there is nothing to validate. Libraries such as https://github.com/fmtlib/fmt are allow to do compile-time parsing of the string though.