In FLOSS Weekly issue 57, about 20 minutes into the show, Randall Schwartz and Leo Laporte express genuine surprise that the XMBC media player application is all in C++. That is pretty telling, some parts of the computing world are indeed moving on to more modern pastures like Python, Perl, Ruby, and even Objective C (for the Mac people). And quite a contrast to the EDA world where C++ is still considered the new shiny thing, as I have lamented before… thanks for that small but golden genuine surprise, Randall and Leo!
But note that the application IS written in C++ still: that is the only choice on the xbox where the project started, by design by Microsoft. However, you can use my favorite scripting language Python to script and skin the application.
Define modern.
I guess I put my chin out for a beating there, right 🙂
Anyway, for me, modern is less about age and more about attitude: less code, less care about optimal performance, and less care about being able to solve absolutely everything in all possible ways. I guess it means being more abstracted from the machine, or more domain-specific.
I think C++ is trying too hard to do too many things to be a very nice language to work in.
With C++ you can lots and lots of abstractions and with zero overhead in many many situations (did you know this?). This is a really important feature, it means you can abstract without compromising performance at all. I think this will always be a modern and important feature.
The problem with C++ was always the very reduced size of STL. Without libraries, you can’t do much. Many C++ developers (including me) always tried to reinvent the wheel with terrible consecuences. Today, the work that David Abrahams started in 1998 right after the current C++ standarization, which is the Boost libraries (www.boost.org) is becoming a real reallity. I invite you to take a look at the libraries and judge for yourself. Take special look at smart_ptr. Here’s a template class named shared_ptr, and with this class you can get shared copies of a pointer that is freed when no one else owns a copy of this class. This means you can free resources right after no one needs it (in-place gc), without the need for a garbage collector to freeze the entire app collecting all the garbage, most of’em probably already in disk (i don’t consider swaping when you don’t need to to be a modern feature). For the record, the shared_ptr::get() method has zero overhead penalty, thanks to inlining and the use of the type directly. This means accessing the pointer directly.
Interpreted languages are very good for many applications, where C++ would suck at, but for many others they suck big time. In these ones, C++ will always have the advantage to do a lot more with the same amount of resources, always.
Yes, C++ (and often even better, C), is the de-facto only choice when you need to get lots of control over what is going on, in order to optimize performance. Correctly used, it is a very good power tool for the best programs and programmers. But more commonly, the need to care about memory management (including explicitly using something like boost gc), the freedom to point to anything, and the general weird behavior you get when using multiple inheritance and operator overloading makes it too easy to do stupid mistakes.
What I think I am saying is that most of the innovation in language design is really in other places today. And I do think that C++ is irksome in that strings are not a built-in type… and neither are arbitrary-length lists. Had it had these two, it would have been much easier for the kinds of things I am doing. Also, for me, the future of programming productivity is to use higher-level domain-specific languages that generate C or C++ code for further compilation. In that way, you get the best of both worlds. Ease of expression and high performance.
I think that GC efficiency depends on the language, the “Freeze everything” approach does not seem to be very common in modern JVMs or other virtual machines that I have encountered.
Another issue I have with C++, and that keeps me going back to C, is the fact that the C++ ABI is not sufficiently standardized that you can link independently-compiled shared objects from different compilers on a platform together reliably. With C, that is mostly not the case (apart from the Microsoft vs gcc issue on Windows).
I have looked at boost, and had I been programming in C++ today, I would have loved all its features. About a decade ago, I was fighting with the STL too, getting structures in place and cursing its lack of certain features.
For the strings you have std::string.
For lists you have std::list.
You’re right about the ABI. It’s hard to standarize it because it changes all the time when new features are put in the language. Also, C++ is allowed to be targeted to such a wide range of platforms that it would be impossible to make such. There is a proposal for Dynamic Libraries thou (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1496.html).
The only time when C++ could be “deprecated” is when people stop needing a language that is both close to the hardware, and able to deal with high level abstractions without compromising performance. Meanwhile evidence shows that we still need this kind of tool, and this particular one continues to evolve in the direction of supporting better ways of abstraction, and it’s libraries (stl+boost) are by using this abstractions for providing better tools.
If dynamic libraries, and Modules are introduced (http://herbsutter.wordpress.com/2007/02/07/iso-c0x-complete-public-review-draft-in-october-2007), thinks could really change for the C++ world, as it is happening today thanks to boost.
I understand what you are trying to say, but I just don’t agree much since I see a lot of innovation happening in C++.
Well, but using a library is far less powerful than using a true language built-in type that the compiler understands, knows about is semantics, and can optimize in a smart way.
The longer I have been programming, the more I appreciate good fundamentals in a language — not all things are convenient when solved in a library.
well, I mean here within a single environment. Obviously, the ABI is going to be different from ARM to PPC to MIPS to the dreaded x86… where most of the trouble is (even if ARM has it share of different ABIs as well).
“The longer I have been programming, the more I appreciate good fundamentals in a language — not all things are convenient when solved in a library.”
Well me and all the C++ comunity disagree with you completly. The philosophy of C++ is to build tools for making better abstractions, so we can then extend the language by the mean of libraries using these abstractions (following the C philosophy and the Unix itself philosophy). Thanks to the zero-overhead rule, the library version can be as fast as the in-language version.
I think this is the right aproach for this kind of language. For scripting this is not so, because it is better to provide language support for fundamentals since their implementation will be more efficient (made-in-C) than implementing it with the language directly.
I hope someday we can have standard ABIs for specific environments so you can compile with one compiler and link with another (in the same environment). ABI standarization is desirable.
I definitely think OOP with C++ is better than C for embedded programming with little to no extra overhead as is pointed out here. That being said I think the overhead of adding garbage collection and higher abstraction is worth the trade off if you can still meet performance requriements. I know some people who are using Python on embedded processors (like the AVR) and it sounds like Google is doing some interesting stuff with Python to really improve it’s performance. Also, at the application layer, Google is using Java for the Android platform which is Awesome. After programming in Python and Java for a while I shutter to think about having to go back to C/C++.
I used to like this thinking too — and C++ has most of it right (I still think things like multiple inheritance and templates together make for a very hard-to-understand semantics). But as time goes on, I find myself much more liking abstractions closer to the target domain, and less general.
C and C++ are excellent as the modern-day assembly language, but most programming needs to move up in abstraction and start using domain-specific languages or restricted subsets that make things simpler and with fewer choices. It is not dumbing-down, it is reducing the semantic gap from domain to program.
Scripting languages is one example of this, but I think the use of simple domain-specific languages that compile to efficient C or C++ is more interesting. By reducing generality, you gain expressive power. And if the domain is non-trivial, the gain is substantial in terms of quicker programming and more reliable code.
“By reducing generality, you gain expressive power.”
C++ proves this is not the only way. The expressive power C++ has is the highest one I’ve seen, and the language is still one of the most general in my opinion. To gain expressive power and still be general, all you have to do is provide tools for making better abstractions. Abstractions will give you the expressive power you need. You can also make the language give you this expressive power by adding direct features, but at the expense of making the language overwhelmingbly big. Even thou C++ is a large language, considering what it allows you to express it’s actually very small.
Plus, XMBC media player looks like an application that needs to be created by a general purpose language, and not some “domain-specific” one. It also seems to need to be as efficient as it can (it’s a media player). So let’s see:
– You need generality.
– You need efficiency.
– You need to be able to write good and highly portable code.
Answer: C++
This discussion is getting out of hand. Note that I CAN see the benefits of C++ in terms of close-to-metal performance and comparatively cheap abstraction (at least in terms of efficiency, I often find the abstractions not as easy to use as could have been hoped for). I use C and C++ exactly for that, all the time.
But when the question is efficiency of programming, the answer is different: domain-specific languages offer far more here in terms of combining efficiency and succinctness, and scripting languages offer nice quick hacking where performance is less important. And for parallelism, innovative solutions like Erlang absolutely rock.
I’m just “questioning your questioning” of the choice of C++ for XMBC, and specially that you refer C++ as an antique language and scripting ones as “modern” ones. You said in your first reply that for you “modern is less about age and more about attitude”, and mentioned that “less care about optimal performance” is an element of modernity. I didn’t mean to get the discussion out of hand, it’s just that you said many controversial things which I couldn’t pass. Anyway, I don’t think C++ isn’t modern, it’s just different and still very effective for many applications. If it stops evolving, some other language that has the same power (efficiency, abstraction, etc.) or better could make it antique, but until now there isn’t any.
Time will tell what will happen with C++, and with the other ones. For the moment, prepare yourselves to continue being surprised about the applications where C++ is going to be used.