Forgot your password?
typodupeerror
Programming

Are C and C++ Losing Ground? 961

Posted by Soulskill
from the lots-of-ground-to-lose dept.
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.'"
This discussion has been archived. No new comments can be posted.

Are C and C++ Losing Ground?

Comments Filter:
  • by kitgerrits (1034262) * on Thursday April 24, 2008 @04:41PM (#23189062)

    This might have something to do with this PowerShell thing: ccontrolling the O/S through the use of VB scripts.
    It's not exactly the Bourne Shell, but it does show promise.
    As Windows admins look at scripting the boring stuff, they will need to learn VB...
  • Fortran! (Score:4, Informative)

    by frogzilla (1229188) on Thursday April 24, 2008 @04:57PM (#23189330)
    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.
  • Re:C/C++ is dying! (Score:5, Informative)

    by SatanicPuppy (611928) * <Satanicpuppy@@@gmail...com> on Thursday April 24, 2008 @05:01PM (#23189376) Journal
    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
  • by sconeu (64226) on Thursday April 24, 2008 @05:03PM (#23189406) Homepage Journal
    Not to mention that scoped_ptr and shared_ptr are in the next iteration of the Standard (well, shared_ptr for sure, can't remember about scoped_ptr).
  • by oodaloop (1229816) on Thursday April 24, 2008 @05:03PM (#23189412)

    OK, kidding aside.

    I thought the joke went: There are 10 kinds of coders...
  • Re:I Hope so Too (Score:1, Informative)

    by Anonymous Coward on Thursday April 24, 2008 @05:04PM (#23189422)

    C++ isn't all it's cracked up to be.

    It isn't? Let me give a little example of what you can do in C++. The task is this: 1. Transform all the strings in a vector of strings to uppercase. 2. Remove all the strings whose length is a multiple of 3. 3. Sort the resulting vector. 4. Print the strings on the screen.

    Here's how I do it:

    (cat(stringvec) | transform(strupper) | grep(bind(size, _1) % 3 != 0) | sort() | print())();

    Yes, that is actual C++ code, using a powerful generics language implemented with metaprogramming techniques. Now imagine writing entire systems like this. Looks kind of like shell code, doesn't it? Except with the total efficiency of C++.

    Don't care for this little language? Invent your own. C++ has the capacity to express an infinite number of such "little languages." Metaprogramming is not a joke. It is probably the most powerful feature of C++. The problem is, few people are genuinely good at it. The boost project collects most of the experts in one place, so we can all make use of their techniques.

    But, I suppose, this insanely powerful ability is not "progress." Hrm.

    (In case you are wondering, the assembler code generated by the compiler from that single line is very similar to the code I would have written, had I written in assembler myself.)

  • by krog (25663) on Thursday April 24, 2008 @05:04PM (#23189434) Homepage
    Just a note -- Ericsson developed the Erlang [erlang.org] language with telecom-style reliability in mind, and using it they have brought to market products like ATM switches with 99.9999999% uptime (that's nine nines, under 40ms of downtime per year). Telecom isn't just C's domain anymore.
  • Re:Finally (Score:2, Informative)

    by AKAImBatman (238306) <akaimbatman@gmail.cFREEBSDom minus bsd> on Thursday April 24, 2008 @05:04PM (#23189436) Homepage Journal

    Java (which is slow as hell)
    Stop repeating this. If you want to say that Java is slower than C/C++, that's at least a defensible position. (Though not by much. All the benchmarks are showing Java exceeding C++ performance and giving C a run for its money.) But anyone who states that Java is "slow as hell" is painting a big, fat target on his forehead.

    Just a friendly bit of advice.
  • by SatanicPuppy (611928) * <Satanicpuppy@@@gmail...com> on Thursday April 24, 2008 @05:18PM (#23189606) Journal
    The methodology page is here [tiobe.com].

    I don't know. A lot of it depends on what applications businesses are using; a few big companies pushing large Delphi projects could make a big difference.

    I think Javascript is also hampered by the fact that there aren't all that many different apps, and that a lot of people do view it as a semi-essential skill, so it gets less play. You don't see HTML up there anywhere.
  • by wmshub (25291) on Thursday April 24, 2008 @05:21PM (#23189684) Homepage Journal
    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.
  • by Schraegstrichpunkt (931443) on Thursday April 24, 2008 @05:51PM (#23190218) Homepage

    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.

  • by Jugalator (259273) on Thursday April 24, 2008 @06:00PM (#23190380) Journal

    This might have something to do with this PowerShell thing: ccontrolling the O/S through the use of VB scripts.
    Please correct me if I'm wrong, but isn't VBScript (or JScript at the user's choice) used for the Windows Script Host [wikipedia.org] whereas PowerShell uses its own scripting language that integrates with the .NET platform?

    You can also write "cmdlets" for PowerShell in any .NET language such as C# or Visual Basic, but that's seems more about writing commands for the shell than writing shell scripts.
  • by Chris Burke (6130) on Thursday April 24, 2008 @06:12PM (#23190566) Homepage
    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.

  • by pclminion (145572) on Thursday April 24, 2008 @06:16PM (#23190642)

    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.

  • Re:not so.. (Score:5, Informative)

    by andersbergh (884714) * on Thursday April 24, 2008 @06:32PM (#23190904)
    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.
  • Mods on crack (Score:5, Informative)

    by Nursie (632944) on Thursday April 24, 2008 @07:05PM (#23191390)
    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.
  • Re:Objective C (Score:5, Informative)

    by jeremyp (130771) on Thursday April 24, 2008 @07:09PM (#23191454) Homepage Journal
    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++.
  • Re:C/C++ is dying! (Score:5, Informative)

    by leenks (906881) on Thursday April 24, 2008 @07:14PM (#23191524)
    Lots of us (in enterprises at least) are realising (or rather, we are able to convince the project managers now) that webapps aren't the solution for everything, and that overall development time is often increased by the difficulties when developing in javascript / html.
  • by NovaX (37364) on Thursday April 24, 2008 @09:54PM (#23193060)
    There are a number of differences, if I understand Python's giant lock approach correctly. They have basically adopted the threading model used in most early, single-processor operating systems (e.g. Linux, FreeBSD) where the system calls are protected by a shared lock. This works fine for single-processors, since multiple processes are implicitly serialized by task switching. However, as multiple processes run concurrently in hardware this immediately shows performance issues.

    Java's synchronized keyword is a user-level mutex and not a single shared lock across the entire JVM. This means that data structures like HashMaps can use lock-splitting across buckets, or that threads executing independant code flows are not serialized across a single mutex boundary. With Java-5's support for CAS operations, more powerful locks and concurrency data structures are available. I have executed thousands of threads in a distributed master-worker fashion and, due to elegant lock semantics, have not suffered any performance issues due to synchronization. This means that Java is quite strong at both multi-core systems (where there are only a few CPUs) and distributed systems (where there are many).

    I am personally a fan of an actor model (e.g. Erlang) for application developers and a lock model (e.g. C, Java) for infrastructure developers. I do not believe that the actor model works efficently enough to be used at the guts of a system, such as caches, where performance is critical. These are special areas that need a skilled hand, meaning that a lock model should be used sparingly in favor of an actor approach. This has been adopted for quite a long time, as message-based (queues) models are fairly standard in most large, distributed service-based applications.
  • by Gracenotes (1001843) <wikigracenotes@gma i l . com> on Thursday April 24, 2008 @10:00PM (#23193104)

    They both try to solve the same problem of shared data management across threads in a similar way, and I think neither will really scale to huge multi-core systems so long as the lock-and-key mechanisms remain in place.

    Java introduced many more sophisticated tools with the java.util.concurrent [sun.com] package (and subpackages) that allow for programs with high CPU thoroughput and scalability. These include synchronization primitives such as a count-down latch, cyclic barrier, semaphore, an exchanger, and so on. Several concurrent collections were introduced, notably a variety of queues that serve a variety of unique purposes. An executor framework was introduced to replace Timer/TimerTask, and includes all sorts of thread pools, rejected execution policies, delayed executors... you get the idea.

    java.util.concurrent.atomic has several atomic value holders, some of them reflection-based, all of which use compare-and-swap [wikipedia.org], a low-level algorithm, for lock-free access/modification. java.util.concurrent.lock contains locking utilities, including a ReentrantLock. (This class was so much faster than synchronized, btw, than synchronized was changed to use ReentrantLock's algorithm in Java 6.) Finally, there's the AbstractQueuedSynchronizer, a robust class for building synchronizers, that (again) uses compare-and-swap to maintain state.

    There's no doubt that less data shared between processes, and increased parallelization, is good for any concurrent application. In terms of concurrency, though, Java offers quite a bit of flexibility and sophistication, though sacrificing some of the simplicity of functional programming languages. In my opinion, anyway.

  • by Shlomi Fish (3362) <shlomif@shlomifish.org> on Thursday April 24, 2008 @10:48PM (#23193484) Homepage

    As Sterling Hanenkamp notes the TIOBE index is a bit flawed [perlbuzz.com]. 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 [shlomifish.org] (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 [shlomifish.org] (another link to an article of mine), but it's still an essential skill.

  • Re:Yes it is (Score:2, Informative)

    by gstamp (99104) on Friday April 25, 2008 @12:02AM (#23193930) Homepage
    >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 <i>multiplied by awesome.

    Been done.

    http://jikesrvm.org/

    You do know that Java hasn't been interpreted for a long long time right?

    Hotspot JIT compilers are pretty cool. You should check them out sometime.
  • Nah. (Score:2, Informative)

    by fozzy1015 (264592) on Friday April 25, 2008 @12:31AM (#23194080)
    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.
  • by G3ckoG33k (647276) on Friday April 25, 2008 @02:01AM (#23194524)
    From http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9020942&pageNumber=1 [computerworld.com] "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?
  • Re:Yes it is (Score:3, Informative)

    by enos (627034) on Friday April 25, 2008 @03:34AM (#23194956)
    Most of the JVM is written in Java. Only a small bit to bootstrap things is written in C. The compiler (bytecode->native), garbage collector(s) (you can write your own, btw), class loader, class verifier, etc, are written in Java.

    C isn't faster than Java, of course, unless your program finishes before the JVM's overhead can be amortized. Anything that needs a long time to run will probably be faster in Java.

  • by jrumney (197329) on Friday April 25, 2008 @05:20AM (#23195406) Homepage

    In java I can create two objects which point to each other, but with nothing else pointing to each object, and that memory will be lost for ever, but the garbage collector won't free them because it works by counting references.

    Nonsense. GC in Java has never worked by counting references, and bugs due to circular references have been a thing of the past since Java 1.3 or so. Perhaps you're thinking of some of the psuedo garbage collection libraries available for C++.

  • Re:C/C++ is dying! (Score:3, Informative)

    by Haeleth (414428) on Friday April 25, 2008 @07:41AM (#23196056) Journal

    $ cat > hello.java
    System.out.println("Hello world");
    $ javac hello.java
    hello.java:1: class, interface, or enum expected
    System.out.println("Hello world");
    ^
    1 error
  • by TheRaven64 (641858) on Friday April 25, 2008 @08:22AM (#23196312) Journal
    Why? The Java compiler is written in Java, most Lisp compilers are written in Lisp and Smalltalk compilers are written in Smalltalk. I believe most ML and Haskell compilers are also written in their target languages. It's very rare to find a compiler that can't compile itself - this is one of the common tests of an implementation.

    As to low-level libraries, again, why? There are operating systems written in high-level languages, apart from a tiny bit of machine-specific assembly language they are written in assembly. Something like SqueakNOS has assembly code to install the interrupt handlers and then everything above that is written in Smalltalk. No C anywhere.

  • Re:Not myth (Score:3, Informative)

    by nguy (1207026) on Friday April 25, 2008 @02:59PM (#23201336)
    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.

The Force is what holds everything together. It has its dark side, and it has its light side. It's sort of like cosmic duct tape.

Working...