Slashdot Mirror
Are C and C++ Losing Ground?
Pickens writes "Dr. Dobbs has an interesting interview with Paul Jansen, the managing director of TIOBE Software, about the Programming Community Index, which measures the popularity of programming languages by monitoring their web presence. Since the TIOBE index has been published now for more than 6 years, it gives an interesting picture about trends in the usage of programming languages. Jansen says not much has affected the top ten programming languages in the last five years, with only Python entering the top 10 (replacing COBOL), but C and C++ are definitely losing ground. 'Languages without automated garbage collection are getting out of fashion,' says Jansen. 'The chance of running into all kinds of memory problems is gradually outweighing the performance penalty you have to pay for garbage collection.'"
I haven't written a line of code in C or C++ since I started with C# - C/C++ syntax with no tracking of memory (I detest tracking memory!!) except in the more obscure situations. Both .NET and Mono allow for C#, so you're not stuck on one platform.
What I love about such studies is that they can confirm any theory you want.
Truth remains that every particular market has requirements which dictate selection of languages.
I doubt that telecom industry (as it is right now) would ever get over C or C++. Just like kernel or system libraries in anything else but C.
If you look at rise of Web - and pleiades of supporting it languages - then both C/C++ are out of question of course. Though again I can hardly imaging Apache or MySQL or PHP being written in anything else but C or C++.
Market for system and telecom programming is definitely shrinking - and consequently their languages. Other markets are now blooming - and their languages are becoming more popular.
My point is that the languages are complementing - they are not competing. After all you have to write hardware, firmware and OS first. Only then your beloved automated garbage collection has possibility to kicks in.
All hope abandon ye who enter here.
We have certainly replaced C/C++ with Python wherever we can. This is about 90% of our software. Except where C is absolutely needed (which is mostly just in our kernel/device driver stuff), the 10x faster Python development and far easier code maintenance just outweighs everything else. That the Python is much less prone to crashing for programs beyond tiny one-offs is another big positive (yes, yes, if you write perfect C/C++ and don't use glib you'll never crash either, but in practice this never happens).
In practice the speed difference doesn't matter for almost every application we've run into - we have a high speed network load tester in Python, which sounds ridiculous, but it works and it makes it insanely easier to add new tests or behaviors. If we ever hit a bottleneck, we just write a small C extension module and call that from the Python.
I'm saying Python here, but insert your higher level language of choice.
Who's going to bother listening to my "back in my day, we programmed uphill in the snow both ways" stories when I don't even bother to use a monospaced font!
And before I started up my 80x25 terminal window, I tied an onion to my belt, which was the style at the time.
Yeah. Much better.
Do they somewhere discriminate between VB and VB.Net? Claiming that VB is not even a programming language is ... probably reasonable. VB.Net is just C# without curly braces, however.
Socialism: a lie told by totalitarians and believed by fools.
I'd _like_ to stop using C++, frankly, but I don't seem to have a choice. A lot of my work depends on real-time capability, the kind of speed that is still only really possible on natively compiled languages that don't do dynamic typing.
I don't even mean hardcore real-time mechanical nano-second control of knife-wielding deathbots, just simple, This Must Run As Fast or Faster Than The Rate At Which It Will Be Converted To Analog. Python and Java still don't replace C in this area. (Mainly audio, video, and high-speed mechanical control.) And when it gets complex and you need to get into object oriented models to simplify the programming, there is unfortunately no real alternative other than C++. Combine this with that fact that there are a bunch of great libraries out there written in C++ that would be very difficult to replace, and you're stuck with it.
(I sort of oscillate between liking C++ and hating it, but I'm preferring straight C more and more these days. But like I said, I don't always have the luxury of choice, depending on what libraries I need to use.)
All these other languages mentioned (Java, Python, Ruby, PHP, Perl, etc) do not compile to native code, and all do dynamic memory management. Hell, that's exactly what makes them *good*. But unfortunately they're not so good for real-time tasks.
For real-time, you need deterministic memory management, and native speed. I've been looking at some other languages that compile to native code these days, like D, or Vala, but I haven't really decided yet whether I can start using them on serious projects.
I'd really like to learn more about functional programming in this area, too, but there seem to be very few functional languages that are designed for real-time. FAUST is one, but it's only for audio.
Anyone know any other good natively-compiled languages that actually have well-implemented modern features?
I wish it were possible to have a compiled version of Python, for example, but there are many dynamic features it depends on. (Some stuff could be done in Pyrex, which is a pretty cool little project, but so far I've only used it to make bindings to C libraries.)
Delphi and Pascal are other puzzlers. Pascal is great as a teaching language, but there are later iterations of that family of languages - Modula-2 and Modula-3 - that arguably provide better rigor if rigor is what you are after. And I see no obvious reason to use Pascal or related languages if you're not after truly rigorous code.
C seems to be holding ground, the slight loss seems to be within the fluctuations other languages that are holding steady are seeing. It's too powerful, too close to bare-metal programming and too close to the actual machine architecture to fade for some time yet. C++ might genuinely be losing ground - C# and D provide a lot of the power and object-orientedness of C++ but make an effort to learn from the complexity of C++. Personally, I suspect D might stand a better chance as C# is still very much tied to a single vendor in people's minds. I don't see C++ vanishing, rather I see them reaching some common point and staying there.
VB is quick-n-dirty, and it's popular because it's so easy to write something in it. If it ever became unlawful to have a website that was dangerously insecure or a hazard to Internet traffic (in much the same way cars have to be inspected every so often in some places to ensure it meets certain minimum safety standards) I imagine Visual Basic would lose appeal. Well, that or the EU eventually raising the fines to the point of driving Microsoft out of international competition.
Given that so much new scientific code is still produced in Fortran, whereas not much is really written in COBOL although a lot of legacy code is maintained in it, I'm surprised COBOL is there and Fortran is not. (Fortran is popular enough that there are TWO competing front-ends for GCC for it. There are open-source COBOL compilers, but as far as I know, all work has stopped on all of them. To me, that says something about the level of interest and serious usage.)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
The current generation of managed code VMs clearly have some benefits. But but they fall far short on some of the key properties that make C and C++ so powerful. Even if I grant you that the JVM and
C and C++ are the only game in town for getting the best performance and a small memory footprint and the ability to have the lowest possible latency.
.NET communities, because they have empirically demonstrated that they culturally have no regard for small memory footprint, low overhead, short startup time, etc. They just don't consider huge memory footprint or ridiculous startup times a problem. This is not to ment
That said, I think that C and C++ are becoming harder to justify when you consider the havoc that memory errors can wreak. It's highly embarrassing to vendors and damaging to their customers when a buffer overflow exploit is discovered. malloc and free, even when used correctly, can still have some forgotten downsides like the memory fragmentation that was discovered in Firefox 2, and took some very smart people a lot of work to address.
What I would like to see is a language that gives the benefits of C and C++ (extremely fast, extremely small memory footprint, and no GC pauses) but that is also immune to C and C++'s weaknesses (memory corruption, memory leaks, memory fragmentation). Yep, I pretty much want to have my cake and eat it too. Why do I think this is possible? I think that the future is to have a fully concurrent, compacting GC. Everyone's telling us we're going to have more cores than we know what to do with soon, right? Well why not use all those extra cores to do GC in the background? Even if it's more expensive on the whole, we barely know what to do with all those extra cores as it is. With this strategy, you could get the performance guarantees and low overhead of C and C++ (on the real, non-GC thread, that is) without having to give up GC or suffer from memory fragmentation.
I'm also not willing to give up the option of dropping to C or C++ (or even assembly language) when it's justified. Mention JNI in a room of Java people and observe them reel in horror -- it's culturally shunned to deviate from "100% pure Java." Maybe this is a good value when you're on a big team of people writing a web app, but for systems and multimedia programming this is silly -- inner loops are inner loops, and some of them can benefit from machine-specific optimization.
Theoretically you could experiment with the fully concurrent GC using an existing language/runtime like Java, but I've sort of given up on the JVM and
Some drink at the fountain of knowledge. Others just gargle.
Well, as a VB developer, you have to remember that when people talk about VB now, they are talking about VB.Net. Which is exactly the same as C#, with a different syntax. Comparing VB.Net to VBScript or even VB6 is like comparing Java with Javascript. VB gets a bad name because it used to be pretty bad, and there's a lot of non-programmers using it to do a lot of stuff they aren't qualified to do, and messing it up royally. But that doesn't mean VB.Net is a terrible language. I wouldn't fault PHP for all the insecure newbie websites created with PHP.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
I completely agree - You know why I like C or C++? Because I only need to know one thing to do 90% of everything - C or C++. In the world of web development, I must no only be proficient in an equivilant amount of libraries found on a desktop platform, but also any number of scripting languages (PHP/JavaScript/Ruby/etc), HTML/XHTML/XML/SGL/DTD/RelaxNG/XMLSchema, perhaps ColdFusion, or maybe Adobe Flex/SilverLight - And I'm probably only scrapping the complexity of this odd little world.
Why the pain? Why not keep it simple? In spite of our advancement, it's amazing how much more practicality and common sense some software academics had 20 years ago compared to today.
When are web standards comittees or intellectuals going to quit trying to one up each other and start consolidating some of their standardizations?