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