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.'"
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...
"I was in love with a beautiful blonde once, dear. She drove me to drink. It's the one thing I am indebted to her for."
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.
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
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
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).
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
I thought the joke went: There are 10 kinds of coders...
Tic-Tac-Toe, Global Thermonuclear War, and relationships all have the same winning move.
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.)
Just a note -- Ericsson developed the Erlang 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.
Cretin - a powerful and flexible CD reencoder
Just a friendly bit of advice.
Javascript + Nintendo DSi = DSiCade
The methodology page is here.
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.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
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.
C99 fixed that: #include <stdint.h>, then use either uint32_t or int32_t.
http://outcampaign.org/
You can also write "cmdlets" for PowerShell in any
Beware: In C++, your friends can see your privates!
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.
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.
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.
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
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.
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.
"Open Source?" - Press any key to continue
Java introduced many more sophisticated tools with the java.util.concurrent 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, 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.
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/
>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.
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?
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.
boldly going forward, 'cause we can't find reverse
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++.
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.
I am TheRaven on Soylent News
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.