this post was submitted on 19 Mar 2024
145 points (92.9% liked)
Programming
17489 readers
66 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
This statement could also be applied to Perl, PHP, JavaScript, and most other languages that eventually add new ways of doing things, especially if they preserve backward compatibility. I'm not sure that this is a condemnation of C++ so much as an inevitable consequence of being successful for a long time.
To be clear, I'm not defending C++. Just pointing out that it's not unusual in this regard. I have no doubt that Rust will also have vestigial warts in time, if it doesn't already.
Why can’t it be both a condemnation of C++ AND an inevitable consequence of success? C++ was a success, but we’ve learned a lot and it’s time to move on
Condemning apples for having seeds doesn't make a reasonable case for choosing other fruit, which also have seeds.
it does if the other ones have edible seeds, seeds without arsenic, or fewer seeds... your analogy makes no sense.
You are very close to a deep truth of language design: all large popular languages slowly die from committees overloading them with cruft and redundant features, and at the end of their healthspans, they become painful for all involved. In your list, this includes both PHP and ECMAScript; Perl 5 avoided this fate, but Raku certainly suffers from it.