Yes C++ is complex, but so are Python, Ruby, Ada, Fortran, C#, F#, Haskell, OCaml, Java...
Even Go will get caught in the complexity game if it gets enterprise adoption at scale.
If not the language, the libraries surely will.
Yes C++ is complex, but so are Python, Ruby, Ada, Fortran, C#, F#, Haskell, OCaml, Java...
Even Go will get caught in the complexity game if it gets enterprise adoption at scale.
If not the language, the libraries surely will.
Its not a "complexity game" in so much as poor design being over-compensated for. C++ is like cancer infecting the minds of young programmers with buggy habits -- and no amount of features and static analysis will change what lies beneath... :p
The only thing Ada has thrown away was GC support that no compiler vendor has ever bothered to implement.
What other features were thrown away across Ada83, Ada95, Ada2005 and Ada2012?
If I present you Ada random code snippet X, are you sure you will be able to say which language version it requires?
Also Python is the poster child of what happens when you throw compatibility away.
C is a mine-field of devastating design flaws which have caused many people to die because of decades old decisions made on a whim and any change to basic libraries to make them safer and removing dangerous functions is heresy.
As far as Python, yes the two versions of the language is troublesome for users but the language is objectively better and students learning programming for the first time benefit from a more robust version.
Feel free to give me a random code snippet ;p
It does provide the necessary language features for security conscious developers to write safe code, the fact that many write C++ as if it was "C with C++ compiler" is an unfortunate one.
Yes it would have been great that we had Ada instead of C++, sadly that wasn't what greedy Ada compiler vendors wanted us to have.
In fact, from that list it seems like it is finally meeting parody on key Ada 95 features -- so maybe we dont have to be so sad :)
Wow. Hyperbole much?
I get that you don't like C, but you sound like a raving lunatic who is completely unconnected with reality.
Devastating design flaws? Flaws I can agree with. Devastating? That sounds a bit overstated.
Caused many people to die? I call BS. (Yes, I'm pretty sure you might be able to document a few. But you said "many", and I'm calling you on it.)
Decisions made on a whim? Again, BS. In fact, at this point you're just making stuff up.
There are so many parts of C that are unsafe that a secondary tool is needed to have an reasonable type-checking and that tends to be devastating if they can be easily avoided by even safety critical engineers.
https://users.ece.cmu.edu/~koopman/pubs/koopman14_toyota_ua_... "Toyota does not claim to have followed MISRA Guidelines"
And honestly I dont think we agree on what "a few" is. In my book if any more than 4 or 10 people die from a solved problem in computer science (like strong typing, mutexes, and range checking) that is already way too yes many
As far as decisions on a whim compare the two language design efforts and i'll let you decide:
http://www.adapower.com/index.php?Command=Class&ClassID=FAQ&... "The requirements were not a language specification, but instead they attempted to define rigorously the needed characteristics in a form that could be critically reviewed."
https://www.codingunit.com/the-history-of-the-c-language “It’s entirely Dennis Ritchie’s work”
It took a decade to even decide what the C language really was and standardize it -- sounds pretty undefined and whimsical to me. But we all use and understand words differently so let's agree to disagree :)
And what, exactly, happened?
For years I avoided Python3. Updating my code base was a hassle I did not want to deal with.
Finally, a few months ago, I had some spare time and took the dive.
And nothing bad happened. I did not even spend hours on it. At this point, all the libraries I need exist for Python3, and the automated tools update my code for Python3 without manual intervention almost every time.
A minor problem compared to dealing with developers continually using poor paradigms for eternity because C++ did not want to break compatibility.
And I believe the developers who backport to 2.x are not those who implement the features in 3.x. The latter don't care at all about 2.x. Those who backport do not see it as a "pain" but as a new feature to add to their language.
Fortunately the architects of the change said that they've learned their lesson. They don't have much choice either, another one like this and it would be bye bye python.
Certainly did not affect me or anyone I know.