C++ is a beautiful language on the inside. People just don't like it's ugly skin.
Those of us who like C++ see it as the language it wants to be, not the language that it is dragged in to being by it's C heritage.
Those of us who like C++ see it as the language it wants to be, not the language that it is dragged in to being by it's C heritage.
There are now a gazillion programming languages, and new ones popping up every once in a while -- like anal warts.
I'm tired of these fucking evangelists. Seeing these posts on the front page is like getting daily visits from Jahova's Witnesses.
Just use whatever makes you productive and your product do whatever it's supposed to do, and most importantly, shut the fuck up. </rant>
The best we can do is to ignore them altogether. I know it's sometimes hard, but it's definitely more productive that way :)
Almost every truly important software system is either implemented directly in one or both of them, or heavily depends on other software implemented in one or both of them.
In practice, you don't get implementations of languages like Java, Ruby, Python, Perl and Go without C and C++. Even if you're using something like JRuby, you'll still likely end up depending on a JVM written in C and/or C++. And all of this isn't even considering that your software, regardless of the language it's written in, will likely be dealing with an OS written in C and/or C++, and possibly communicating with a database or some other server software written in C and/or C++. These days, C and C++ are nearly inescapable when implementing real-world software.
Unless someone takes the time to free Python from C, by doing something like this:
https://en.wikipedia.org/wiki/PyPy
Really, the reason you see interpreters being written in C/C++ has less to do with any technical quality of C or C++ and more to do with something else you mentioned:
"your software, regardless of the language it's written in, will likely be dealing with an OS written in C and/or C++,"
Bingo. Sometimes software needs to do low-level things, even if the software itself is high-level, and that means the software is probably going to be making system calls. An interpreter for Python is going to have to make some system calls, and it is much easier to do that if the interpreter is written in the same language as the OS's API; most OSes have C APIs, and thus writing a Python interpreter in C makes sense.
"These days, C and C++ are nearly inescapable when implementing real-world software."
I doubt it, considering how much real-world software is being written in Java, C#, Ruby, Javascript, etc. Not all software needs to do things that involve directly deal with the OS. The fact that these systems are often implemented in C does not make C inescapable; it just means that nobody has bothered to free themselves from C yet. There is no technical feature of C that makes it inescapable as a language, it is just what we have to deal with until we put in the effort needed to rid ourselves of it.
And C++ doesn't want anything by itself, as C++ is not a person, but an ugly spec with a bunch of ugly compilers written according to that spec and the funny thing about languages beautiful on the inside, is that such languages will never get rid of their heritage, nor will that heritage become less important.
And IMHO there never was and never will be a mainstream language more ugly than C++, being successful only because people wanted C with extensions and they got it. Sometimes I wish normal people knew what C++ was, because sometimes I have a hard time explaining what absolute ugliness is and the first thing that pops into my head is C++.
> nobody is willing to put in the effort needed to get rid of C
This statement is wrong on multiple levels.
1. People are willing to put in the effort to move beyond C, and it's been happening for four decades. C++, Java, Python, C#, Haskell, Ruby...
2. Getting rid of C for new projects universally is not really desirable. It's still the only thing I would choose for writing the majority of an OS kernel, where dangerous low-level operations are necessary. For the same reason, we will never ditch assembly.
3. Rewriting old C projects in newer languages is often ill-advised. Source code contains the knowledge of those who worked on it, it is used to describe solved problems. Rewriting code means solving those problems over again, relearning the encoded knowledge, and making bugs that were fixed long ago.
If you asked me how my blind date went, and I reply, "She smelled better than the inside of a septic tank," I'm sure you would know what's up.
Wow! How would you propose giving access to low-level operations? Writing in assembly?
> but nobody is willing to put in the effort needed to get rid of C and move the programming world forward.
So, you want me to write DSP code in Python? How is that going to work?
How about making it possible to get low-level pointers and to do low-level operations, but not force programmers to do such things just to do something as simple as concatenate two strings?
"So, you want me to write DSP code in Python? How is that going to work?"
Who said anything about Python? There are a lot of other languages out there. There are Lisp systems that will let you access special CPU opcodes, low-level pointers, memory-mapped I/O, etc. There are hard real-time systems written in Ada.
Even if you could show that C is the absolutely best-performance language for some particular operation, why would you write an entire system in C? If it were me, I would write the one function in C, and then call it via an FFI in a high level language. Why constrain your ability to express your design for the sake of a single function?
Sadly the language didn't gain much traction over the years (for reasons due to library support and lack of environments). With the whole revival of functional (and hybrid) languages, I think that good old structured OOP as Bertrand Meyer envisioned will remain the realm of C++ for performance critical applications and C#, Java (and others) for more entreprisey stuff.
I didn't know about Sather, I'll have a look at it. Thanks for that !