C++ for the next decade(successfulsoftware.net)
successfulsoftware.net
C++ for the next decade
http://successfulsoftware.net/2008/11/09/c-for-the-next-decade/
4 comments
For some reason, programming "pure" C instead of C++ gives me more satisfaction.
Being 4th for questions on stackoverflow (as the article mentions) could mean a lot of things... could mean it's popular, could also mean that people using it have more questions.
The trend it's moving in is also important.
If stackoverflow debuted 10 years ago, where would C++ be on that list? What does that imply for how much C++ will be used in the future?
If stackoverflow debuted 10 years ago, where would C++ be on that list? What does that imply for how much C++ will be used in the future?
It may help if they tried removing things instead of adding more bloat on top.
There must be billions of lines of C++ in production systems. Backward compatibility is crucial.
If you need a fast object-oriented language that can interact with most C software and libraries and doesn't need a fancy GUI, C++ is great.
C++ does fancy GUIs just fine. See Qt.
Qt is my favorite gui API of all time. Their new IDE is amazing as well:
http://trolltech.com/developer/qt-creator
It feels like google made an IDE. It's got Chrome like simplicity and power. Certainly worth a look if you're Qt hacker.
http://trolltech.com/developer/qt-creator
It feels like google made an IDE. It's got Chrome like simplicity and power. Certainly worth a look if you're Qt hacker.
[deleted]
Qt is GPL.
Qt has several licences.
They no longer show prices for the other licenses on their webpage. But a few years back it was high enough to cover about 3 months of my living costs. Which is probably no big deal for larger companies, but for a startup it is.
exactly. funny to be modded down on a hacker forum for pointing out the obvious: the lack of free GUI development tools is a mark against doing GUI development in a specific language.
> and doesn't need a fancy GUI, C++ is great.
And what's great for fancy GUIs? I'm curious too.
And what's great for fancy GUIs? I'm curious too.
Whatever's native to the platform. On Windows, that usually means C#/.NET. On Linux, C/Gnome or C++/Qt. On the Mac, Objective-C/Cocoa. On the web, JavaScript.
So is Lua.
Java will never, ever replace c++. Because there will always be a need for stuff that "really compiles" rather than "compiles with respect to the JVM" for both performance, and reliability issues.
In my personal opinion, Java is a fad for children. However, that may be a bit harsh. Perhaps Java too has its place. But just as sport cars, loved by teenagers, won't ever replace the need for a reliable sedan in one's more mature years, similarly, there will always be grownup applications that need the speed and reliability of c/c++, even if they are not as "easy to program" (read: rely on plug-in libs) or are not as "flashy" in terms of the ui. Just as I personally no longer fancy swing sets, I really haven't a need for SWING either. :-)
(Oh, one other thing I almost forgot: Java doesn't have pointers. No programming language without pointers should be taken seriously by people who have reached age 21. It's kind of like having a car without a combustion engine. It's just nonsense.)
In my personal opinion, Java is a fad for children. However, that may be a bit harsh. Perhaps Java too has its place. But just as sport cars, loved by teenagers, won't ever replace the need for a reliable sedan in one's more mature years, similarly, there will always be grownup applications that need the speed and reliability of c/c++, even if they are not as "easy to program" (read: rely on plug-in libs) or are not as "flashy" in terms of the ui. Just as I personally no longer fancy swing sets, I really haven't a need for SWING either. :-)
(Oh, one other thing I almost forgot: Java doesn't have pointers. No programming language without pointers should be taken seriously by people who have reached age 21. It's kind of like having a car without a combustion engine. It's just nonsense.)
I honestly can't tell if this is satire. Does your universe of programming languages seriously consist of just C++ and Java?
I'm glad that coding in C++ makes you feel like more of a man, but Java's not the only competition. C++ and Java have both (awkwardly) added closures in their latest specification, so they're obviously maneuvering against something outside of your little duality.
Also, I don't see how you can knock Java for its libraries when C++ is essentially worthless for large-scale development without Boost.
I'm glad that coding in C++ makes you feel like more of a man, but Java's not the only competition. C++ and Java have both (awkwardly) added closures in their latest specification, so they're obviously maneuvering against something outside of your little duality.
Also, I don't see how you can knock Java for its libraries when C++ is essentially worthless for large-scale development without Boost.
prospero, I have been looking for C++ replacement for desktop programs non-stop for at least 5 years and found nothing. Rubies, lisps and pythons are great in a little dark corner of server-side development where everything is under your control, but for targeting thousands of varying desktops you just can't take that route since many additional variables come into play: size of downloads, performance, startup times, windows compatibility, etc etc etc. Plus, all VM-based languages suffer from so-so integration into native OS or/and excessive weight. You can write an IDE or an Excel replacement in them, sure, but most desktop software tends to be much smaller.
My last C++ project was a background daemon that would download your RSS feeds and do some fancy parsing. I wish I could show you how much memory Java prototype has eaten vs C++ version processing the same OPML file.
No, C++ is not "essentially worthless" without Boost. In fact I never use all of Boost: your build times becomes #1 conversation topic in the office when you do. It's better to cherry-pick a few important and lightweight pieces (like pointers, any, functional, etc). Don't forget about HUGE selection of plain C libraries too.
Whatever C++ has been used for is still being written and re-written in C++ as we speak. Newer languages and paradigms wiped out the giant Visual Basic army of developers (yes, this is what people used to code "basecamps of the 90s" in, but I don't see these languages threaten C++/C/Obj-C domination for desktop software on Win/Linux/OSX.
In fact, how many native Python or Ruby GUI libraries are out there? I haven't heard of one. Only bindings to GTK/Qt.
With all that said, I will be the first to jump the wagon. If I ever get so lucky.
My last C++ project was a background daemon that would download your RSS feeds and do some fancy parsing. I wish I could show you how much memory Java prototype has eaten vs C++ version processing the same OPML file.
No, C++ is not "essentially worthless" without Boost. In fact I never use all of Boost: your build times becomes #1 conversation topic in the office when you do. It's better to cherry-pick a few important and lightweight pieces (like pointers, any, functional, etc). Don't forget about HUGE selection of plain C libraries too.
Whatever C++ has been used for is still being written and re-written in C++ as we speak. Newer languages and paradigms wiped out the giant Visual Basic army of developers (yes, this is what people used to code "basecamps of the 90s" in, but I don't see these languages threaten C++/C/Obj-C domination for desktop software on Win/Linux/OSX.
In fact, how many native Python or Ruby GUI libraries are out there? I haven't heard of one. Only bindings to GTK/Qt.
With all that said, I will be the first to jump the wagon. If I ever get so lucky.
If you have a small, well-scoped application, like your RSS daemon, C++ is going to be best of breed in most cases. Similarly, if performance is your absolute primary concern, there's nothing out there that can compete.
For most desktop software, though, neither of these things are true. The design and scope of the application are constantly changing, and mostly it just sits there. I write desktop software for a living, including a lot of CPU-intensive graphics stuff, and I'm infinitely grateful that I work in C# rather than C++. It makes me many times more productive, makes my work conceptually cleaner, and makes me a happier person all round. There's a memory cost, to be sure, but it's acceptable, and 90% of the clock cycles are spent in C libraries no matter what, so I don't see much of a downside.
My background's in 3D graphics and computational geometry. I've always enjoyed working in C++ on computationally intensive problems, and reducing a problem to its cleanest, fastest implementation. But I think that in the real world, 99% of the time, what really matters are the features, and that the widespread fascination with efficiency is mostly just techno-fetishism.
For most desktop software, though, neither of these things are true. The design and scope of the application are constantly changing, and mostly it just sits there. I write desktop software for a living, including a lot of CPU-intensive graphics stuff, and I'm infinitely grateful that I work in C# rather than C++. It makes me many times more productive, makes my work conceptually cleaner, and makes me a happier person all round. There's a memory cost, to be sure, but it's acceptable, and 90% of the clock cycles are spent in C libraries no matter what, so I don't see much of a downside.
My background's in 3D graphics and computational geometry. I've always enjoyed working in C++ on computationally intensive problems, and reducing a problem to its cleanest, fastest implementation. But I think that in the real world, 99% of the time, what really matters are the features, and that the widespread fascination with efficiency is mostly just techno-fetishism.
You're lucky: I also do desktop software but we can't afford to ignore the growing number of Mac users. While they still represent only about 8% of all computer purchases, they account for nearly half of "customers who pay for software" and C# isn't an option for us although we keep monitoring Mono's progress.
Also, allow me to disagree with you on something:
"If you have a small, well-scoped application, like your RSS daemon, C++ is going to be best of breed in most cases. Similarly, if performance is your absolute primary concern, there's nothing out there that can compete. For most desktop software, though, neither of these things are true."
Perhaps it's our difference in backgrounds, but most desktop software is more like that: small pieces that need small downloads, small memory footprints and instantaneous startup times. Just count the number of executable files on your hard drive and see what percentage of them eats more than 3MB of RAM (measured in 'private bytes'). Or you can look at the list of running processes: you'll see perhaps 1-3 behemoths like Firefox or Photoshop there, and one can only wonder how FireFox memory consumption would look like under JVM or .NET VM.
Also, allow me to disagree with you on something:
"If you have a small, well-scoped application, like your RSS daemon, C++ is going to be best of breed in most cases. Similarly, if performance is your absolute primary concern, there's nothing out there that can compete. For most desktop software, though, neither of these things are true."
Perhaps it's our difference in backgrounds, but most desktop software is more like that: small pieces that need small downloads, small memory footprints and instantaneous startup times. Just count the number of executable files on your hard drive and see what percentage of them eats more than 3MB of RAM (measured in 'private bytes'). Or you can look at the list of running processes: you'll see perhaps 1-3 behemoths like Firefox or Photoshop there, and one can only wonder how FireFox memory consumption would look like under JVM or .NET VM.
>they account for nearly half of "customers who pay for software"
Have you got any data to back that up?
More like 15% in my experience.
Have you got any data to back that up?
More like 15% in my experience.
I guess it heavily depends on a market segment, but for "family computer software" it is true: lots of PC users playing with free/evaluation versions but for when it comes to premium subscriptions and premium features - most of them evaporate, whereas Mac users like to stick around.
Look at various PC/Mac softwares out there: most of PC-only software belongs to "free&shitty" category, but nearly everything for OSX you have to pay for, and they (users) are accustomed to it.
I am not sure if I can post results of the research my company has done (and paid for) here.
Look at various PC/Mac softwares out there: most of PC-only software belongs to "free&shitty" category, but nearly everything for OSX you have to pay for, and they (users) are accustomed to it.
I am not sure if I can post results of the research my company has done (and paid for) here.
> 90% of the clock cycles are spent in C libraries no matter what, so I don't see much of a downside
Which of course raises the question: why C#/Java instead of C++ in conjunction with something like perl or python?
Which of course raises the question: why C#/Java instead of C++ in conjunction with something like perl or python?
I write Windows applications. C# has Win32 bindings that are vastly superior to anything else out there. There are tools designed to let me leverage these capabilities that are much more polished than the comparable tools for Python, Ruby, or anything else.
C# isn't the best language out there, and certainly not the most elegant, but it's been carefully designed by some very smart people, and it shows. At the end of the day, for what I do, it's the best tool available.
C# isn't the best language out there, and certainly not the most elegant, but it's been carefully designed by some very smart people, and it shows. At the end of the day, for what I do, it's the best tool available.
My point was more philosophical, I guess. Obviously if you're doing Windows desktop apps you use whatever Visual Studio gives you. I'm just pro-dynamic language. I also like C++ and fail to see Java or C# as sufficiently improved over C++.
I like dynamic languages too, and often wish C# was looser in its typing (or at least less verbose in its typecasting). If it were practical to use Ruby/C to do my job, I probably would.
That being said, C# is a huge step above C++, at least with respect to application development. Garbage collection aside, it has first-class functions, well-implemented closures, an integrated query DSL, and decent (if a little awkward) reflection capabilities. It's not an exciting language, and I don't feel particularly cool saying I use it, but I think it gets a pretty bum rap.
That being said, C# is a huge step above C++, at least with respect to application development. Garbage collection aside, it has first-class functions, well-implemented closures, an integrated query DSL, and decent (if a little awkward) reflection capabilities. It's not an exciting language, and I don't feel particularly cool saying I use it, but I think it gets a pretty bum rap.
I'm aware of the feature set, I just don't think it buys you that much over modern C++ (different story six years ago). If you're using boost correctly garbage collection isn't necessary, and higher order stuff is quite doable.
I have dealt with Java memory problems several times now and am convinced that garbage collection has no business near performance bottleneck code.
I have dealt with Java memory problems several times now and am convinced that garbage collection has no business near performance bottleneck code.
C++ makes programming slow in many ways. You have to specifiy (and and maintain) every function signature twice. Compile times are measured in minutes for any substantial code base, unless you spend considerable time decoupling layers of headers, which slows programming down even more. Finding bugs is much more difficult without a stack trace, etc.
I'm not saying C++ shouldn't be used because if it really adds to the quality of the result the additional effort may be worth it. It's a balance between the quality of the product and time to market.
There's one more issue that shouldn't actually play a role but does: I have rarely seen C++ code that isn't full of incredibly stupid errors like copying large collections three times in a single function call. Even smart professional programmers very often write C++ code that is complete crap and way slower than the most naive C# or Java implementation.
But as someone who writes very data intensive apps I have to say there's just no way around C/C++. C# and Java VMs have twice the memory consumption of C/C++. I don't know whether C code uses more memory than assembly, but I doubt that a factor of two will ever be negligible, particularly because it translates into a factor of 100 as soon as you run out of memory and have to hit the disk.
Unfortunately the combination of C/C++ and dynamic languages doesn't work for many of my own scenarios because of the GIL.
I mean look Rails (just as an example). A typical rails app runs in 16 processes, each consuming 150MB of RAM (after a while of running) just for the framework itself and a few controllers and views basically. Nothing but little helpers doing CRUD.
There's just no memory left to do anything interesting with data in-memory because all that data would have to be duplicated in each process. That's why dynamic languages driving a C++ core doesn't really fly for interactive apps. It works for batch processes like what google does.
I'm not saying C++ shouldn't be used because if it really adds to the quality of the result the additional effort may be worth it. It's a balance between the quality of the product and time to market.
There's one more issue that shouldn't actually play a role but does: I have rarely seen C++ code that isn't full of incredibly stupid errors like copying large collections three times in a single function call. Even smart professional programmers very often write C++ code that is complete crap and way slower than the most naive C# or Java implementation.
But as someone who writes very data intensive apps I have to say there's just no way around C/C++. C# and Java VMs have twice the memory consumption of C/C++. I don't know whether C code uses more memory than assembly, but I doubt that a factor of two will ever be negligible, particularly because it translates into a factor of 100 as soon as you run out of memory and have to hit the disk.
Unfortunately the combination of C/C++ and dynamic languages doesn't work for many of my own scenarios because of the GIL.
I mean look Rails (just as an example). A typical rails app runs in 16 processes, each consuming 150MB of RAM (after a while of running) just for the framework itself and a few controllers and views basically. Nothing but little helpers doing CRUD.
There's just no memory left to do anything interesting with data in-memory because all that data would have to be duplicated in each process. That's why dynamic languages driving a C++ core doesn't really fly for interactive apps. It works for batch processes like what google does.
Java will never, ever replace c++
Because there will always be a need for stuff that "really compiles" rather than "compiles with respect to
the JVM" for both performance, and reliability issues.
In my personal opinion, Java is a fad for children. However, that may be a bit harsh.
<the car and teenagers rant>
not as "easy to program"
<the pointer rant>
The same was said about assembly when C was first being used professionally for microcomputer development. C was too slow, it didn't give the programmer enough control, how can you possibly get stuff done without having full access to the computer's registers, what if you wanted to use processor-specific instructions, etc?
People got over it. Many of the complaints are actually true - there are some domains where you still need to use assembly. But people figure they'll just use C for the main program and toss the assembly stuff in special subroutines in the arch/ subdirectory, and forget about it for the 99% of the time it doesn't matter.
People got over it. Many of the complaints are actually true - there are some domains where you still need to use assembly. But people figure they'll just use C for the main program and toss the assembly stuff in special subroutines in the arch/ subdirectory, and forget about it for the 99% of the time it doesn't matter.
And the ironic part is your programming language of choice is coded in C and uses libraries with optimizations in assembly.
When all you know is the hammer... This saying applies to both extremes, be it a dynamic language or a low level language. I try to use the best tool for the job, from my knowledge chest. That's why it's important to learn several languages.
When all you know is the hammer... This saying applies to both extremes, be it a dynamic language or a low level language. I try to use the best tool for the job, from my knowledge chest. That's why it's important to learn several languages.
Electric cars don't have combustion engines, which kills your analogy. Although maybe it doesn't, since a language without pointers is valid for non-systems programming.