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.'"
But does Netcraft confirm it?
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.
Need an automatic screenshot taker? Try here.
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?
My work here is dung.
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.
Of course C++ is losing ground. But does it matter? No.
If you still need optimum performance at any cost--like for OS's, many games, simulations, etc.--you must use the C's. If you don't, then your Java or favorite scripting language will give you faster development time and easier deployment.
So it just doesn't matter. I still don't consider someone a proper coder unless they know C++, though.
expandfairuse.org
I know I am gonna get flamed for this, but they said web programming, like its the only game out there. Sure its not web 2.0 friendly, and sure most web script kiddies don't use it...mainly because it don't hold their hand, but its far from dead when your are needing to squeeze every last ounce of power out of your hardware, or even that other 25-30% of it.
I develop desktop application software. Right now I wouldn't think about using anything else but C++.
Almost as bad as Jeff Atwood and Joel Spolsky calling them "dead languages" on their new podcast.
The cake is a pie
For image processing (film/video), real-time audio or any serious signal processing, the overhead of anything but C/C++ is killer. It'll be news when Adobe After Effects or Autodesk Flame is rewritten in python.
Besides, measuring the popularity of a language by the size of its web presence is the worst kind of fallacious reasoning.
...I say. If reference counting or basic allocation deallocation coupling is something you cannot do, you're in the wrong business. However, educating students in the art (c.i.t. I know) of programming with Java calls for these kinds of problems.
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++.
Cretin - a powerful and flexible CD reencoder
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.
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.
There is no "I disagree" mod for a reason. Flamebait, Troll, and Overrated are not substitutes.
Coming from someone who can't handle the concept of a contraction, it doesn't carry the weight you think it does.
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.
those who can code in binary and those who cant code.
OK, kidding aside.
There are those who write code so that a person can do something on a computer. In which case the users are comparatively slow and the high level languages give you a distinct advantage in development.
Then there are those who write code to make the computer do something, in which case the low level languages give you the ability to more effectively optimize how the computer interacts with itself, this is where languages like C, C++ really come into their own.
In the early days of computing it was all about the later, now its much more about the former, but the later will never go away. So the decrease is reasonable and IMHO does not represent a failing of the language, just a shift in the way computers are being used. I will be very surprised if the high level languages ever get widespread acceptance in the areas that require computational efficiency, ala computational physics, protein folding, etc.
-- The morphemes of your disquisition are ascertainable, but they have eschewed an ambit of transpicuous exposition.
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.
Fortran has been dead for ages but we still use it everyday on a variety of architectures. I know we're not the only ones. Many scientists still use it.
I do most of my work in Python and Java now. However, I often need to write in C/C++ to create JNI modules for Java or extension modules for Python. Wrapping low level (use 3rd party library) and performance intensive stuff for control via a higher level language is very productive. (C++ is handy for JNI, C is better for Python.) Furthermore, I even occasionally write small functions in assembler for C - usually to utilize a specialized instruction.
Yes, but on the bright side, they lose ground about 1.5x faster than Java in most applications.
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.
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?
Hi,
Yes, some things need to be done in assembly or C in order to `stay competetive' or even just to remain within the realm of the possible. How much that is depends on your application and your platform.
So, systems programmers, you need not worry, your skills are always going to be needed for something.
But let's be honest here, 80% of the applications you can code entirely in Haskell or Prolog or Python or whatever fancy high-level language you may personally have come to love. And of the remaining 20%, you can usually still code 80% of the application in your favourite language and optimise the core 20% in C. (After profiling. Let me repeat that, AFTER profiling.)
Will it run faster and in less memory if you do it all in C? If you do it properly, sure. But that's not the question to ask. If you work commercially, ask for `what will be most profitable in the long run, while remaining ethical'. If you work free software projects, ask for `what will benefit people the most'.
Don't confuse the above questions with `what will satisfy my C(++) hacker ego the most'. And remember that it's not just about getting the code working and making it fast, it's about making the code robust; and in many cases it's also about making the code readable for whoever will maintain it after you.
Apologies for this rant; feel free to mod it down if you so desire, but you, dear fellow programmers, have had it coming for quite a while, as did I.
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?
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.
I wouldn't be so sure.
I hate to say so, but MSFT's Singularity and now others(including Open Source versions) are doing a core OS in C# and .NET. It is something innovated from MSFT.
It will take time, but it's well within the foreseeable future.
i thought once I was found, but it was only a dream.
It's just slightly higher level. A C compiler outputs assembly code - that's the whole point of a C compiler. Think of C as the worlds greatest macro processor for assembly.
That's why most compilers have some sort of ASM pragma - so you can inject your assembly into the code if you feel the compiler is doing a poor job of it.
That's also why you'll never find a faster language. And that's why it'll never go away.
Weaselmancer
rediculous.
There's nothing to stop you from exclusively using reference-counted smart pointers and garbage collection in C++, for some or all of a project, if that's really your thing.
For me, C++ destructors (each object responsibe for it's own storage) remove most of the hassle of freeing storage, and I've never hankered after garbage collection.
That says nothing about those languages. All that says anything about is your job.
I write drivers, so I could make the opposite statement. Doesn't say anything about the relative merits of one language versus another though. All it says is that I'm in an environment where C makes more sense.
In summary: A hammer is best when your problem is a nail, and a screwdriver is best when your problem is a screw.
Weaselmancer
rediculous.
I've been in the "real world" for about six years now, after graduating with a computer science degree. I'm currently in Chicago, Illinois, USA. I've spent the past several months looking for a good software engineering job, both in the Chicago and Milwaukee (Wisconsin) areas. Just from this experience, my take is that Java and C#/.NET technologies are hottest right now.
My first job was using C and C++. This was partly due to historical reasons (the application was about 12 years old), but also because the API for the platform was only in C. Shortly before I came in, and during my tenure there, we were trying to move more towards C++ and build a more object-oriented framework. My current position is at a high-frequency trading firm. All our software is custom and mostly C++ (some C here and there, and a handful of Perl to glue things together).
So based on this experience, when I was looking for a job, I was focusing on C/C++ positions. What I found is that there aren't a lot of people looking for C/C++ developers. In Milwaukee, virtually all of the demand for C/C++ programmers was for embedded systems. In Chicago, there was little demand for experience in those languages outside of embedded systems and the finance industry (which I was/am trying to get out of!).
This is just my casual observation of a relatively small portion of the software engineer landscape as a whole.
On top of a diminishing demand for C/C++ programmers, I found that quite a few companies who were looking for Java/C# programmers wouldn't even consider C/C++ people. The languages aren't all that different, and the concepts should definitely be portable. I think knowing concepts, understanding programming ideas/patterns, problem solving, etc, are more important that knowing the specifics of a particular language. Shrug.
All you young bucks, let me tell you somethig. Back in the good ol' days when I was a programmer, we didn't have all these fancy "windows" and "icons". All we had were 1's and 0's. And sometimes we didn't have any 1's. Once I wrote a database using only 0's. And we liked it.
The day the linux kernel is coded in anything other than C, is the day i after i install duke nukem forever on hurd.
IranAir Flight 655 never forget!
I'm not really sure why C++ is so ill-favored lately. It may not be fully OO, but there are many times when a fully OO solution is counterintuitive. Instead, C++ allows the developer to choose whether they want an OO solution or not. I also see a lot of complaints about C++ performance in comparison to C performance, but really, when properly implemented there is little difference. The same goes for garbage collection. Granted you have to write it yourself, but program-specific garbage collection will ALWAYS be more efficient than automatic garbage collection.
I think it's generally agreed that C and C++ aren't going anywhere anytime soon, since a lower-level programming language will always be needed. However, sidelining C++ in favor of C is definitely not a good idea, as C++ does offer many advantages that C lacks. (Yes, even for kernel development.)
I'd go into more depth, but this article really does a good job of explaining it:
http://unthought.net/c++/c_vs_c++.html
...it just smells that way.
D also offers syntax and ease of writing comparable to C#/Java, but is faster, doesn't require VM and compiles to native code linkable with C.
Until a language comes along that can outperform C or C++, there will always be a use for them.
It's still right-tool-for-the-job. I don't use Ruby to write audio DSP plugins, and I don't use C/C++ to code a web application.
I'll keep both in my tool box, along with lisp,
In the work I do--scientific calculations with a lot of fast numerics, , python + fortran seems like nirvana, as each overcomes the shortcomings of the other. One could just as well use C except the efficient numeric libs and memory layout give fortran an edge.
This of course is not the match made in heaven for everyone but numerical scientists should look hard.
What's so good?
Utility:
Well there's a strong base of numeric libraries in Python that are fortran array freindly so there's a good base to grow off of.
Second F2PY, which creates python modules out of fortran subs works so well it's almost transparent and painless. Even cooler is that because fortran compiles are ludicrously fast compared to C++, you can generate fortran code in the python compiler at run time and compile it one the fly for creating modules optimized to your problem.
Given you are wrapping in python, the availability of groovy C++ libs is not really very enticing at all given the pain you will pay for having to write the whole program in C++.
Practical:
Fortran as a stand alone language kinda blows for versatility and modern program architectures. But if all you are doing is writing a function then it's a sweet language because it's language syntax is so tight that it's harder to make a syntax error that compiles, and hard to logic errors seem to be less evasive than in C. (e.g. using i++ instead of ++i or doing I=4 instead of i==4 are not possible in fortran's limited syntax).
Thus you write functions and let python deal with all the memory management, human interface, file management, command line arg parsing and all the messy bits that end up being a lot bigger than the function where the program spends all it's time.
Fortran is also very optimization friendly since things like matrix multiplies and out-of-order loops are part of the core language.
This is debatable but I find that fortran seems to have a more logical memory order in 2-d arrays. Namely if you take a sub-array you get elements that are consecutive in memory and thus for most microprocessors will all get pulled into the cache on the same page. Slices of C-arrays have consecutive elements spaced by the row width apart in memory. One can of course find cases where one is preferred over another.
I do however which python had some way of optionally typing variables that was less cumbersome and slow than decorators or explicit run-time type checking. I virtually never write python that takes advantage of introspection or dynamic typing so the ability not to have some protection--optionally and just to debug--by type checking is annoying.
But If I were starting from scratch and did not have a compelling need for all those wonderful fortran numeric libs, I think the optimal choice in the future is going to be
Java+ Groovy.
basically you learn one syntax and get the best of both interpreted and compiled languages. Develop it in groovy then migrate the slow bits to JAVA. import all the great JAVA libs.
And since it's nearly the same syntax it's easy to read.
Some drink at the fountain of knowledge. Others just gargle.
And anyway, garbage collection is irrelevant if you never "new" anything in the first place.
True, but your program is pretty trivial if it never needs to dynamically allocate a memory resource.
The enemies of Democracy are
Programs which use STL containers instead of manual memory management are "trivial?" This is news to me.
Avoiding the use of "new" is not the same as avoiding dynamic allocation. You simply let the containers handle it for you. Yes, there are pointers flying around, but they are out of sight, and managed by code that actually does things properly for you.
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.)
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
Well, the kernel definitely isn't written in Objective-C, here are the languages they use:
C for the kernel
Embedded C++ for the drivers (IO Kit)
But many of the applications that make up OS X however are written in Objective-C.
You didn't say what kind of software you're writing. Personally, I think using Python for large codebases is shooting yourself in the foot (I've seen it tried several times and the results were never pleasant).
Problems Python has that C++ doesn't (imho) - Python is oddly easier to write than read in my experience, because it's so dynamic. The result is that it's a lot of fun to write and really no fun at all to try and figure out when you're new to a codebase, because you can'
Python doesn't even try and be efficient. Fans of Python tend to say that it doesn't matter because either performance doesn't matter for their application, or because they can write the hot-spots in C. Well, for a lot of apps there aren't really any well defined hotspots after some optimisation. Instead the app just chugs. Look at the fate of Chandler or Sugar for instance. You can't fix that kind of thing by jucidiously rewriting the bottlenecks in C because there isn't one bottleneck - it's death by a thousand cuts. This is especially true of memory-constrained environments like desktop software. I've seen way too many apps where the developers clearly thought they'd "make it fast later" and then discovered that they didn't understand performance like they thought ...
It's rather hard to distribute Python apps without distributing a giant runtime with them as well. For many apps that doesn't matter, but if you want people to download your app, it's going to hurt. Any consumer desktop app for instance ...
The chance of running into all kinds of memory problems is gradually outweighing the performance penalty you have to pay for garbage collection
It's a myth that there is a performance penalty for garbage collection; garbage collection usually has less overhead than doing the same kind of memory management with malloc/free.
The reason that garbage collection has a reputation for being slower is that once people have garbage collection, they get sloppy and wasteful. And languages using garbage collection often just aren't designed for efficiency (e.g., Java).
It would be nice to have a safe, garbage collected systems language, and such languages are possible. Unfortunately, all we get is Java and C#, two bloated languages that make writing efficient programs harder than eating tomato soup with chopsticks.
Let me know when you're finished with that Linux replacement.
Clear, Dark Skies
Troll?
Annoyed, enflamed perhaps, but Troll?
Sorry but it's a pet hate of mine that here on slashdot, which is supposed to be a forward looking tech board, that people still regularly espouse the view that threaded programming is something either still in development, too complex for ordinary mortals, or only applicable in a few scientific arenas.
It's just thoroughly incorrect. Industry and open source have been doing threading for years. Please can we lose this myth.
And to bring the post back on topic - pthreads in C will do it all nicely. Hell, even MS VC++ 6.0 (almost 10 years old?) will compile your multithreaded Windows C app.
I'd also lik to express suprise at the title of this article. C is losing popularity at the same position as last year, number 2? OK, it'll fizzle out any day now, I believe you.
I think my job's safe for now.
I'm curious what the list looks like for embedded programming - particularly at the low end. For my money, C is hard to beat on small systems - it's a good compromise between efficiency and manageability. If you know how the compiler works, it's not hard to write code that's nearly as efficient as hand-optimized assembly.
I'm sure Java ranks high there, too, but I don't consider it to be in the same class. Native Java hardware is relatively expensive, and running a VM takes a significant amount of memory and processing power.
My latest project is pure C (aside from about 100 lines of assembly for a firmware upgrade bootloader), around 30 pages of source code at present, and it compiles to about 9k of object code. It's targeted for a $2.50 processor, and I'm able to do things like simultaneous Bell 202 and DTMF decoding in software because I know exactly how C arithmetic is implemented on the processor and can take advantage of that without having to actually do the implementation in assembler. Doing the same thing in Java would cost a lot more. And when $5 saved on the bill of materials means an extra $5-10k in my bank account at the end of the year, that's a big deal.
So what other languages can compete in that space?
The Mac OS X kernel is entirely written in C except for the bits that have to be written in assembler.
The preferred run time for graphical applications is Objective C but I'm willing to bet that the low level graphics are done in C.
And Objective C is the bastard son of C and Smalltalk (but it's still my favourite programming language). It's probably equally closely related to Java and C++.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
``The chance of running into all kinds of memory problems is gradually outweighing the performance penalty you have to pay for garbage collection.''
Moreover, automatic memory management makes for more elegant and workable APIs, and some things (I think closures are among those) need automatic memory management.
Also, automatic memory management is not necessarily slower than manual memory management. In fact, garbage collection can be faster than malloc/free, and has been demonstrated to be so in some cases. (One obvious case where a collector outperforms manual memory management is when the collector never has to run.)
Please correct me if I got my facts wrong.
So it could also be considered a niche on the scale of all the situation at which you can throw the other languages. C could be found on anything electronic that can run code between small embed micro-controllers up to package running on huge mainframes or cluster.
It's not bad, its very useful indeed. Just hasn't seen as many different usages as the other languages yet.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Strong typing. Garbage collection. Native code generation.
Lack of OO and a current up to date machine code generating compiler would be a detriment though
to a rollout anytime soon of this old language.
http://en.wikipedia.org/wiki/ALGOL_68/
H.
As Sterling Hanenkamp notes the TIOBE index is a bit flawed. It doesn't measure popularity - it measures hype, and not all of it too. That put aside, it is true that C and C++ are not used as much as they once used to, and that's because there are alternatives that are better for many uses. However, there are still many tasks for which they are still the best choice (warning - a link to my own article), and should be used. A lot of open-source code is written in ANSI C and C++, and usually for very good reasons.
While I expect the use of C and C++ to diminish, I wouldn't say they are "dying" or "losing ground". They just become more established and more "niche" languages. Another fact to note is that usually the virtual machines for higher-level languages are C-hosted - perl5, CPython, ruby, php, Tcl, the various Java VMs, Mono (and probably Microsoft's .NET too), Lua, Io, etc. are all written in ANSI C, and can normally be extended using it. Some languages are self-hosting and usually can be bootstrapped by compiling themselves to C, and then compiling the C code.
Every programmer worth his salt, should still learn ANSI C, because not knowing it leads to lack of good understanding of computer architectures and portable programming that is bound to lead to inefficient code, and improper use of any programming language. I wouldn't recommend learning ANSI C as the first programming language (another link to an article of mine), but it's still an essential skill.
We have two eyes and ten fingers so we will type five times as much as we read. http://www.shlomifish.org/
which measures the popularity of programming languages by monitoring their web presence
Web presence doesn't equal much; it certainly doesn't equate to popularity. Nor do these numbers bear much resemblance to the mix of programming openings I see on job boards. C is number two? Really? Or are they just counting the number of times C shows up in the meaningless expression C/C++ ? Outside of the DSP and embedded devices niche, the appearance of "C/C++" in a job listing means they're looking for a C++ programmer, and it's generally followed by a list of C++ APIs that the successful candidate will be familiar with. And please, C fans, keep your flames low. C is my favorite language, but if it was really the second most popular programming language, I wouldn't spend eight to ten hours a day programming in C++ and PHP.
Anyway, the bit about the lack of garbage collection in C++ is a crock. There are a number of easy to learn and use GC libraries available for C++, and a number of them can be used in most cases with little to no code changes simply by linking them in. If the popularity of C++ is declining over GC, it's because people have gotten too lazy to type "c++ garbage collector" into Google. There are plenty of reasons to dislike C++, but that's just not one of them.
Proud member of the Weirdo-American community.
There's nothing good to program in. This is a serious problem.
We have C. C isn't a bad language, but the "pointer=array" concept, while it provided some performance gains in the PDP-11 days, continues to cause millions of crashes and intrusions every day. The fundamental problem is that you can't even express the size of an array in the language. Given that, the odds of consistently getting subscripts right is low. This could be fixed, but it will never happen.
There's C++. C++ has lost its way, as I've pointed out before. The C++ committee is off in template la-la land, putting in features that few will use and fewer still will use correctly. (Coming soon: "concepts"). The real problem with C++ is that it's no safer than C, but hides more.
There were once better languages. Delphi is better, but it's Borland. Modula 3 was a good systems programming language, but it died with DEC. Various attempts at improvement, from Ada to Eiffel to Sather, have almost died off. Amazingly, "D", which is Walter Bright's successor to C++, has a measurable market share.
Some progress is being made on numeric issues, like compiling Matlab to efficient code for parallel hardwware. But that doesn't help systems programming much. Hard-compiled Python would have potential, if Guido wasn't against it. (Python has a speed penalty of about 10x to 60x over C/C++. Maybe at some point Google management will decide that a hard-compiled Python system would be cheaper than building additional data centers at former aluminum-smelter sites.)
As for garbage collection, it's a headache. "Finalizer" and "destructor" semantics get weird. (See "Managed C++") Reference counting leads to saner semantics and repeatable timing, but is inefficient unless the compiler knows how to hoist reference count updates out of loops. (Incidentally, about 90% of subscript checks can be hoisted out of loops, and you can almost always hoist them out of inner FOR loops. So subscript checking is almost free if done right.) Note that Perl is reference-counted, and Perl programmers don't spend much attention on memory management. If you have strong and weak pointers, reference counting, and treat cycles as errors, you don't really need garbage collection.
I have news for you however. Statistically and historically, CS-related work was mostly a big trail of failures. Virtually no project, aside a select few with insane ressources backing em, and a couple of lucky shots, actually ended up giving out more value than they required.
In this day and age, maybe its inefficient, maybe its not quite CS, maybe its not "cool", but it gets the job done, it saves money, it makes things work, its enabling. Its still not good enough in its current state, but its going in the right direction. We're leaving the "how" behind, and changing it with the "what". People have ideas, and they make those ideas a reality, and it "works".
It may not be as badass to implement an enterprise management system, as opposed to the first ethernet network, but you don't spend 3 years on a project to be left empty ended 90% of the time either.
Saying that C++ is losing ground because it lacks garbage collection makes me fear for the future of the "general programmer". If you use C++ for any length of time beyond a week it becomes second nature to manage your memory. Hell, I programmed in C++ for 2 days and caught on to situations in which a memory leak would even be possible. It's scary how easy it is to do... it's even scarier to think that people would drop a language because they may have to be mindful of memory when they code.
Those who know, do not speak. Those who speak, do not know. ~Lao Tzu
I work at a very large telecom on their enterprise level network routers. Our code base is almost entirely C. I, and a few others, have been moving parts over to C++ mostly for what C++ and Boost can offer. There is a standard Red-Black binary tree library in VxWorks(probably all Unixes: rbtLib.h). Needing two or more sets of ordering on the same data is a hack. You create two binary trees and cast different structs before dereferencing it. I've done it. I then tried the multi index set in Boost and you know what? Each entry takes up EXACTLY the same amount of data as when I hand coded it in C. What's great about C++ is you can use it as a better C. Define all your types and use the implicit constructor calls to range check all with assert() when you develop.
I've also interviewed at Redback and they are entirely a C shop. Some of it is old entrenchment, but some of it is needing to know exactly what happens in their code. I have mixed feelings about that.
On the other hand, C is the lowest you can get across processor architectures. You have complete confidence knowing exactly how much memory a structure will take up, with knowledge of boundary alignemnt of course. Saving it to disk and loading it back is straight forward. Have one virtual function in a C++ class or structure and doing that will cause trouble as the compiler will put a pointer to a vtable at the beginning. From a simple debug shell I've had to debug a chip vendor's function by calling malloc and passing the address back to the API function to DMA a hardware table into memory. Have you seen what function overloading causes the compiler to do with the entries in the symbol table? My whole point is that abstraction leaks will always occur, and when someone has to go to the lower level to debug, these higher level constructs cause more confusion.
C isn't going anywhere, at least not in the some what niche area of network software programming.
From http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9020942&pageNumber=1 "ColdFusion. This once-popular Web programming language -- released in the mid-1990s by Allaire Corp. (which was later purchased by Macromedia Inc., which itself was acquired by Adobe Systems Inc.) -- has since been superseded by other development platforms, including Microsoft Corp.'s Active Server Pages and .Net, as well as Java, Ruby on Rails, Python, PHP and other open-source languages. Debates continue over whether ColdFusion is as robust and scalable as its competitors, but nevertheless, premiums paid for ColdFusion programmers have dropped way off, according to Foote. "It was really popular at one time, but the market is now crowded with other products," he says"
So, it is counterintuitive with these new stats!
Who should one believe?
As for NBL - I think the NBL will provide support/semantics for development methodologies and components - Abstractions built in for defining components, instantiating them from repositories, support for testing .. I think all the current focus on things like dynamic vs static typing, closures, functional languages, dsl, are all things that are at too low a level - it is analogous to assembly language programmers arguing over instruction set design when out of left field comes compiled high level languages (ie. fortran ) So I think the guy saying he doesn't see any new paradigms showing up is correct if your "domain" is limited to what we know so far.. I mean take C vs Ruby - how much do their paradigms differ ? Compare the difference in paradigms between assembly and fortran - that is big difference. I think the NBL will be the NBL exactly because it will force us to think about programming in an entirely new way - in my opinion it will need to address the fundamental problem that alot of software engineering (despite 20 years of OO) involves re-inventing the wheel. .. I think Parnas in the 70s or something delivered a speech on this...so the NBL will enable components ...Software development is hard (re Brooks - mythical man month - essential vs accidental complexity) that is true..but it doesn't follow that we are doomed to repeating the essential (hard parts) ad infinitum....okay sorry for rambling... good night.
Take the hottest web dev framework - Ruby on Rails...what is pathetic is how much functionality each web dev team is duplicating all over the world...user management, logging, session management, on and on, not to mention higher level domain stuff like shopping carts.. so there is lots of re-inventing the wheel going on. Software needs components - this is not a new idea
It's unbelievable this company get's any attention with this index. Just some quick and easy points which have been glaring mistakes for years now: Vb is a combination of Basic, VB.NET, Visual Basic.NET, Visual Basic .NET, Visual Basic 2005, VB 2005, Visual Basic 2003, VB 2003, Visual Basic 2002, VB 2002.
Some of these, especially the .net variants are totally different languages with only superficial similarities with the rest. Including this in the index is nonsense. Secondly one has to wonder why .net in general is so underrepresented versus java. This can be explained an their data gathering method. They google for terms like +c# programming. This ommits an entire group of articles only targetting .NET This is because of the language independant nature of the platform. Some numbers to put this 'index' in some much needed perspective:
+java programming 8.320.000
+.net programming 13.500.000
+c# programming 1.260.000
+vb programming 618.000
+vb +.net programming 664.000
This is the only meaningful way to look at the relative popularity of java & .net. Java is not only a language but also a platform, so is .net. Furthermore the majority of programming (judging from these numbers i'd say about double) in .net is done in c#. You'd have to conclude that c# should at least be up there with java.
That is if you think counting the number of search engine results is a meaningful way to get an index, which I don't.
The problem is that you can't tell the system when to collect garbage. So you may find that during a critical section your VM stops everything and starts collecting up the garbage and throwing it out.
That is completely false. Even with a regular garbage collector, you can disable the garbage collector when you want/need to. Concurrent garbage collectors don't stop the system at all. And real-time garbage collectors give you precise upper limits for every memory allocation.
If you manage memory yourself, you can prove that your system will not do this.
That, too, is false, in two ways.
First, having a garbage collector doesn't prevent you from doing manual storage management.
Second, malloc/free and new/delete can have arbitrarily high latencies, and they do in practice.