Are C and C++ Losing Ground? 961
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.'"
Re:Visual Basic at #3? (Score:3, Informative)
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)
Re:C/C++ is dying! (Score:5, Informative)
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:Managed code is the way to go (Score:3, Informative)
Re:There are two kinds of coders... (Score:2, Informative)
I thought the joke went: There are 10 kinds of coders...
Re:I Hope so Too (Score:1, Informative)
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.)
Re:Different markets - different requirements (Score:4, Informative)
Re:Finally (Score:2, Informative)
Just a friendly bit of advice.
Re:Visual Basic at #3? (Score:4, Informative)
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.
Re:That's a broken way to think of it (Score:5, Informative)
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 (Score:5, Informative)
C99 fixed that: #include <stdint.h>, then use either uint32_t or int32_t.
Re:Visual Basic at #3? (Score:3, Informative)
You can also write "cmdlets" for PowerShell in any
Re:C++ is as good as C# _if_ used correctly. (Score:3, Informative)
True, but your program is pretty trivial if it never needs to dynamically allocate a memory resource.
Re:C++ is as good as C# _if_ used correctly. (Score:5, Informative)
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)
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)
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)
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)
Re:Python+Fortran or JAVA+Groovy (Score:5, Informative)
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.
Re:Python+Fortran or JAVA+Groovy (Score:3, Informative)
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.
The TIOBE Index is a Bit Flawed (Score:2, Informative)
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)
>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)
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.
ComputerWorld: ColdFusion is dying (Score:3, Informative)
Re:Yes it is (Score:3, Informative)
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.
Re:Managed code is the way to go (Score:3, Informative)
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)
Re:That's a broken way to think of it (Score:3, Informative)
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)
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.