Ok, now [Jack has] explained that languages are tools best fit for some jobs.
Maybe answering for what job C is best would be in order? I mean, it's a lot
easier to determine what you need with a hammer and a screwdriver than it is
with prog languages and this knowledge does not come by itself.
Well, perhaps. But when do you use a belt sander vs. an orbital
sander vs. a sanding block? When do you want a rasp and when do
you want a file? How about a miter saw, a keyhole saw, a jigsaw,
a backsaw, a hacksaw, and a coping saw? (Or if you're in the
construction biz you probably just use a sawzall for everything,
including filing and sanding.
)
Seriously, the differences between "closely related" languages like
C, Pascal, and C++ are small enough to be like the situation with
the various saws. In many cases, *any* of them will serve. But
a program best written in Prolog is probably not well-served by
being written in C.
So when are procedure-oriented (even C++ is rather procedure-oriented,
for a language that claims to be object-oriented; compare with
Smalltalk for instance), imperative, normally-compiled,
not-too-far-from-the-machine-instruction-set languages appropriate?
I would say that some indictators include having a problem that
requires large amounts of "compute time" spent in small amounts of
code -- hence "compilation" and "close to the metal" become desirable
-- and you have a fair amount of "human time" to throw into
programming the solution. Another indictator is when you and your
team are already familiar with the procedure-oriented language you
choose. If *no* portability is required, however, you might consider
coding even "closer to the metal" (in assembly) under similar
conditions. This generally greatly increases the amount of "human
time" required, of course.