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.'"

Comments

C/C++ is dying!

[KillerCow]

But does Netcraft confirm it?

Re:C/C++ is dying!

[Tackhead]

But does Netcraft confirm it?

No, but Stroustrup himself is reputed to have apologized for C++ as far back as 1998.

"It was only supposed to be a joke, I never thought people would take the book seriously."
- From the lost tapes of the legendary IEEE interview of 1998 :)

Re:C/C++ is dying!

[SatanicPuppy]

1. Java.....20.5%
2. C........14.7%
3. VB.......11.6%
4. PHP......10.3%
5. C++.......9.9%
6. Perl......5.9%
7. Python....4.5%
8. C#........3.8%
9. Ruby......2.9%
10. Delphi...2.7%

The other 10 in the top 20 are:
JavaScript, D, PL/SQL, SAS, Pascal, Lisp/Scheme, FoxPro/xBase, COBOL, Ada, and ColdFusion

Re:C/C++ is dying!

[LabRat007]

For those of you who can't open the page...

1. Java
2. C
4. PHP
5. C++
6. Perl
7. Python
8. C#
9. Ruby
10.Delphi

Please note, there is no language in the 3rd position this year. Seriously.

Re:C/C++ is dying!

[neokushan]

Surely it's not really a fair indication just because it's web presence is dropping? I could easily argue that Java is only so "popular" because more people are posting with problems they're having using the language and that C\C++ are only loosing ground because better information on using the language is already out there.

Re:C/C++ is dying!

[Bozdune]

VB not a programming language?

Yes, because:

1) Only noobs and losers use VB.
2) It's not object-oriented and I took an OO class and they said everything should be OO or it sucks, so VB sucks.
3) I have to create global variables sometimes and I was taught that I should never use global variables for anything because they're bad.
4) Only noobs and losers use VB.
5) VB lets me create classes but they don't work the way classes are supposed to so I hate them.
6) I don't like VB controls, they're ugly, I like to make little hexagonal corners and stuff and piss away weeks of development on cute little clickable thingies.
7) Only noobs and losers use VB.
8) I don't like VB because writing Windows applications should be really hard.
9) "Hello, world" only takes one line, and that can't be right, because I learned in Java class that it should take pages and pages of setup code and stuff.
10) Only noobs and losers use VB.
11) Some idiot can build a simple windows app in about 30 seconds and it's not fair, that same app took me two weeks in C++ class.
12) The dweebs in Accounting are building VB apps and they shouldn't be programming, they don't know what they're doing.
13) Only noobs and losers use VB.
14) I heard Ruby is where it's at, I only want Ruby jobs now because it's kewl.
15) I heard that VB is wicked slow, but then I found out it compiles and stuff which totally isn't fair.
16) Only noobs and losers use VB.

Re:C/C++ is dying!

[smellotron]

If they really are dying... I'd say only one thing:

FINALLY!

There is no finally! That's what destructors and the RAII idiom are for, duh.

Re:C/C++ is dying!

[billcopc]

I agree with you on Coldfusion, simply because I'm forced to work with it on a daily basis. As a longtime "real" programmer, CF is an insult to my skill and experience, but sadly I need to eat.

Delphi though, slow down! Everyone keeps repeating how Pascal is a teaching language, yet it was my official language for many years. Back in the 90's I was developing commercial games with little more than Borland Pascal 7 and Turbo Assembler. I did the speedy bits in assembler, and the logic in Pascal. My development time was extremely short and my code was very reliable and reusable.

When Delphi happened, well honestly the first few versions stank, but I remember writing all sorts of apps in Delphi 4 (yes, even DirectX games). Delphi today has turned into a schizophrenic marketing clusterfuck thanks to Borland/Inprise/Codegear/TrendyNameOfTheMomentInc, but I think Delphi as language is just right for a large number of situations.

It's right in the sweet spot between useless VB and painful C, plus it compiles crazy fast and performs very respectably, given how easy it is to develop. In fact, its qualities closely resemble those of C#, only Delphi did it over 12 years ago. It's no coincidence, Microsoft hired the creator of Turbo Pascal, Anders Hejlsberg, to create C#, J++ and many key architectural features of .NET. If Borland hadn't gone mental in the mid-90s, .NET would not exist today, instead we'd have Borland's equivalent and people would be praising Delphi, just as they praise C# in today's reality. It would probably run a helluva lot faster too!

Always be there

[ohxten]

C/C++ will always be there. Period. Just look at all of the C/C++ projects on SourceForge. New languages will come and go, but C/C++ are just too stable to go so quickly.

Re:Always be there

[wkring]

Cobol projects go on the Share tape.

Re:Always be there

[fyngyrz]

Seriously, most people want to sit down and write the logic for their application, not invent (or even copy-paste) memory management schemes.

Yes, I understand that perfectly. I'm a huge fan of Python for that very reason.

However, in C, writing memory management only needs to be done once; while writing the "logic for the[ir] application" is done many times. Consequently, the apparent load of writing memory management is much lighter than one might initially recognize. Or to put it another way, once it's done, it's done and represents no load at all.

Further, there are huge advantages to having 100% control over the memory management of your application; speed advantages, fewer wasted/tied-up resources, and all the downhill consequences of those things -- if you don't waste resources, they're available for the user, or for other aspects of your programs. Likewise, if you get things done faster, more CPU is available elsewhere.

Another thing: Depending on an external agency to manage your resources is a two-edged sword. If there are bugs in *your* code, you can fix them as fast as you are competent to do so. Considering you wrote it in the first place, the presumption that you are competent to fix it is usually on target.

If there are bugs in an external agency, you typically get to report them... and wait, bugs happily chewing on the users of your applications, until said external agency gets around to fixing whatever it was. If indeed they ever do.

Same thing goes for list management, etc. Write it once, learn all about it (which is interesting AND increases your Leet Skillz) and now you have a generally useful tool that is as fast as you can make it, totally amenable to fixes and updates, and invulnerable to the ass-draggery of outside influences. I have used my list management module in AI apps, ray tracers, image processing, file management, and even in dialogs to control layer types in various (what I think are) clever ways. I have huge confidence in it, but, should it turn out to be broken... I could fix it in minutes. At which point every app I've written gains ground, all my customers win, etc.

There's something else that has always remained in the back of my mind. As languages get more sophisticated, there is a trend for them to generate much larger and much slower resulting applications. It isn't uniform, and it depends on what you're doing, compilers as compared to interpreters, etc., but the trend itself is pretty clear. For instance, a Python app seems small, until you realize that the Python interpreter is loaded for your one-liner. C++ apps tend to be huge compared to C apps. And so on.

This trend - basically - tracks the increasing availability of memory and CPU power. Seems reasonable enough. But the funny thing is, if you take an app that was designed to run at adequate speed on hardware from, say, 1992, keep the technology behind the app the same if you update it - that is, keep writing efficient C and so on - then the increase in memory and CPU resources serve to turn the app into some kind of blistering miracle implementation instead of the run of the mill performance you get from depending on the latest and greatest HLL with garbage collection, the implicit inclusion of module after module of object-oriented processing and modeling, data hiding, etc., etc.

Directly related to this is the fact that if you attempt a modern task - such as an image manipulation system - in a modern language, you, as the programmer, can be significantly enabled by the language; that is, you can be done sooner, and you can have a lot of things done, too, many coming along for the ride, for "free." Garbage collection / memory management being one such thing. But if you approach the task using C, which is basically capable of creating as fast an application as you are capable of writing, it is so close to assembly, while we can certainly agree up front it'll take you longer, the end result coul

Visual Basic at #3?

[eldavojohn]

I can handle C and C++ losing ground.

But did anyone else find Visual Basic rising two spots to #3 past PHP & C++ to be a sure sign of the apocalypse?

(Visual) Basic 11.699% +3.42% A Could someone reassure me that's a mistake before I go home to sit down with a bottle of Jack Daniels and a revolver with a single bullet in it?

Re:Visual Basic at #3?

[Hoplite3]

Not a mistake. But if I could make a suggestion, it would be to upgrade your burbon to Booker's. You won't need that money later.

That's a broken way to think of it

[krog]

C and C++ are entrenched, but it was never their stability which caused it. Computer languages are theoretical; one valid language is just as 'stable' as another. The real issue of stability lies in the implementation, and that is language-independent.

Anyway, C is going to stick around because it is the most superb assembly language developed by man. C++ will of course stay around as well, but by modern standards it fails as a "high-level" language. The ceiling got a lot higher in the intervening 20 years; other languages reach much higher in a very useful way. I'd be happy to see less C++.

Re:That's a broken way to think of it

[wmshub]

Duh.

I think the parent was implying that C often directly maps into assembly language, and he's right. As an embedded programmer, one of the benefits of C is that, other than register selection, I can often tell you exactly what assembly statements will be emitted by a chunk of C code. Often I do use C as a shorthand for assembly.

Nobody who knows the term "assembly language" will think that C is one. But it's a lot closer than you might think.

Re:That's a broken way to think of it

[Schraegstrichpunkt]

OK, since there's no C standard type for "32 bit int", what works on this compiler?

C99 fixed that: #include <stdint.h>, then use either uint32_t or int32_t.

Re:That's a broken way to think of it

[Nursie]

Jesus christ there's another one....

C has been doing multi process for decades, and multi thread for a decade or more.

It's used in commercial apps all over the world.

How many times - threads and parallelism have been with us for years. Just because games haven't been threaded doesn't mean the rest of the world hasn't been doing it, and doing it well for a long time

Look up pthreads sometime.

Seriously, threaded processing in C is damn simple.

C and C++ might die at different rates.

[jythie]

I could actually see C++ slowly going away over the next decade as it is replaced by other languages that fill the same needs but better. C on the other hand is probably going to be around for a long, long time.

Statistics

[Anonymous Coward]

Measuring by internet web pages mentioning it? Can you say, "worthless statistic," kids? I write code that controls hardware. You bet it's C++. I write code that's IN the hardware. An interpreted language? Are you out of your damn mind? Do I blog about it? Don't be absurd. Am I generating "web presence" for it? Only on slashdot. Go away useless statistic.

Re:Managed code is the way to go

[pclminion]

I'm not sure why you feel you need to "track memory" in C++. I did an analysis of all the code I've written a year or so ago, and I found that there is approximately one usage of a pointer in every 5700 lines of code (the way I write it, at least).

We have this great stuff called containers and RAII. And for when you absolutely must, must use a pointer, you have boost::scoped_ptr and boost::shared_ptr. I have not coded a memory leak or buffer overrun in C++ in over six years.

The best way to not leak memory is to never allocate it in the first place. The best way to avoid overflowing raw buffers is to not use raw buffers. Use the containers. When you think you can't, think harder.

Re:C++ is as good as C# _if_ used correctly.

[pclminion]

GC is available for C++, but IMHO inappropriate. One of the great advantages of C++ is that the construction/destruction mechanism, along with automatic variables, gives you absolute control of the lifetime of every single resource. Whereas a garbage collected language like Java gives you absolutely no control over when (if ever) an object is destructed. I think it is a little wacky to give up this total control of object lifetimes in return for such a puny benefit, a benefit which could easily be achieved through C++ resource management techniques like RAII.

And anyway, garbage collection is irrelevant if you never "new" anything in the first place.

Absolutely

[DoofusOfDeath]

Are C and C++ Losing Ground?

Yes, but on the bright side, they lose ground about 1.5x faster than Java in most applications.

We've replaced C/C++ with Python wherever possible

[Sarusa]

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.

bandwagonism

[epine]

I wouldn't say C or C++ is losing ground. They both continue to serve well in the niches they established.

Meanwhile, other segments of the pie are expanding, and few of these new applications are coded in C or C++. Does that mean C and C++ are losing ground?

There is no language out there that serves as a better C than C, or a better C++ than C++. The people who carp about C++ reject the C++ agenda, which is not to achieve supreme enlightenment, but to cope with any ugly reality you throw at it, across any scale of implementation.

For those who wish to gaze toward enlightenment, there is always Java. Enlightenment is on the other side of a thick, protective window, but my isn't the view pretty? I've yet to encounter an "enlightened" language that offers a doorway rather than a window seat. I would be first in line if the hatch ever opened.

The problem with C/C++ has long been that the number of programming projects far exceeds the number of people who have the particular aptitudes that C/C++ demand: those of us who don't need (or wish) to be protected from ourselves (or the guy programming next to us).

It's not economically practical to force programmers who don't have that temperament to begin with to fight a losing battle with self-imposed coding invariants. I'm glad these people have other language choices where they can thrive within the scope of their particular gifts. I don't feel my role is diminished by their successes.

For those of us who have gone to the trouble to cultivate hardcore program correctness skills, none of the supposed problems in the design of C or C++ are progress limiting factors, not within the zone of applications that demand a hardcore attitude toward program correctness.

It's the natural order of things that hardcore niches are soon vacated by those unsuited to thrive there, leaving behind a critical core of people who specialize in deep-down nastiness.

For example, it's not just anyone who maintains a root DNS server. I can say with some assurance that the person who does so did not earn his (or her) grey hairs by worrying about whether the implementation language supported automatic GC.

Let's take a metaphor from the security sector. Ten years ago, a perimeter firewall was considered a good security measure. This measure alone eliminated 99% of TCP/IP based remote exploits.

These days, most exploits are tunneled through http, or maybe I'm behind the times, and the true threat is now regarded to be some protocol tunneled within http.

Then some genius comes along and says "in the security sector, TCP/IP defenses are losing ground". Quoi? Actually, no one is out there dismantling their TCP/IP based perimeter firewall. It's continuing to do the same essential job as ever.

It's only the bandwagon that has picked up and moved camp. Yes, garbage collection and deep packet inspection are now all the rage. So it goes.

Why not go around saying that sexual reproduction is all the rage these days? Would that imply we could eliminate all the organisms that reproduce asexually, and the earth's ecology would continue to function? Hardly.

These new languages are soaking up much of the new code burden because these language are freed from having to cope with the nastiness at the extremes (small and large) that C/C++ have already taken care of.

I would almost say that defines a success criteria for a programming language: if it removes enough nastiness from the application space, that the next language that comes along is free to function on a higher plane of convenience. C/C++ have both earned their stripes. Which of these new languages will achieve as much?

So what?

[menace3society]

FORTRAN, Lisp, and Cobol have all lost ground. BASIC and Pascal used to be the big dogs instead of also-rans, and if Ada ever had any ground in the first place, it lost that.

Even Perl isn't as popular as it used to be, now that other languages have started to fill its niche.

Times change, and it should be unsurprising that the dominant programming languages change along with it. Some day, Java, PHP, Visual Basic, Python, and Ruby will all be obsolescent as well. Thirty years ago, computers were vastly different than they are now. In another thirty years, there will have been another quantum leap (intended) in computing. Why should the languages we program them with remain the same?

Re:not so..

[RiotingPacifist]

The day the linux kernel is coded in anything other than C, is the day i after i install duke nukem forever on hurd.

Re:Yes it is

[Weaselmancer]

Best laugh of the day - thank you. =)

Hey, you've given me an idea though. You know what would be even faster? Now...don't stop me until you hear me out, okay?

If Java is faster than C, we should rewrite the Java VM...in Java! Interpreted code running in an interpreter...that is *also* interpreted!

Just think of the speed increase! It would be like using uranium to fuel the space shuttle! Awesome multiplied by awesome.

Natively-compiled languages

[radarsat1]

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.)