However, no one will only use one language to make all the tasks
done. And every languages has its strong and relatively weak side. So,
what about C?
C's strength, IMO, is that it is close to the machine. It is usually a
short step from what you write in C to what the compiler generates by
way of actual machine instructions. This makes C an excellent language
for people with control issues, or for problems in which close control
over the machine is useful. One of the biggies is operating systems
(although at least one excellent, but commercially unsuccessful OS was
written in C++: BeOS). Another is applications that need to be small
and portable: embedded programming is a good field here.
Because C doesn't expand your source code in unexpected ways, there's
usually a pretty direct corralary between what you write, the size of
your binary, and the performance of your application. That doesn't
mean C is faster, or smaller -- that's in the programmer's hands. But
if you intend to write small, efficient code, C doesn't get in your
way.
C is suitable for projects of any size; many people will tell you that
for large applications, or distributed processing environments, C is
the wrong choice. This may be true, but it's not the fault of C: it's
a problem with the way people use C.
In practical or professional terms, C may be the wrong language to
study if you are aiming for those kinds of fields.
Perhaps more significant than the OO features, one difference that
distinguishes C from C++ or Java is the standard libraries that are
part of the language. Java and C++ both come with large, robust, and
(usually) efficient libraries; C does not. For rapid development,
someone familiar with the language and the libraries and starting from
scratch will often get more done more quickly in Java or C++ than in
C. Many C shops will have their own in-house suite of libraries
suitable to the kind of work the location undertakes. Others will have
third party libraries. It's usually not much work to get up to speed
with these libraries, especially for an expert, but it's an extra
step. And if you're starting a major project, you have to make the
call: buy or build your libraries.
As for the OOD: you *can* do anything in C that you can do in C++ or
Java, but it's not necessarily easy, or appropriate. (In fact, it is
arguable whether some of the stuff that's hard or ugly in C ever
really makes much sense in other languages anyway, but a professional
is better off not getting religious about this, and learning how to
read, maintain, and apply OOD in a clean, efficient manner.)
Another area is memory management: C offers ample opportunity for
inexperienced programmers to wreak havoc and destruction, and even
experienced programmers will manage to shoot themselves in the foot
now and then. Maybe I should only speak for myself here, but even
after 10 years of C programming, a careless typo on a late-night
session can create a bug that takes me hours to track down. Java is
substantially better in this regard, at a pretty big performance
penalty. C++, the "everything to everyone" language, is most often
used in ways that diminish this likelihood, but doesn't actually
prevent it.
In short: theoretically, there's rarely a case in which C is a bad
choice. Practically, I've come to the conclusion that it's more about
the culture of the shop than the project at hand. Professionally, I
think it's a poor strategy to declare a "favorite" language. The good
strategy is to maintain your curiosity about new languages,
techniques, technologies, algorithms, design patterns, and to throw
yourself into any new project open to the possibility that the best
tool for the job *might* be one that you're not familiar with.
Remember: languages are tools, and the professional wants to equip
himself or herself with all the right tools.
