Why is C good??? any experts?

[Neil Kurzman]

First

Like any other tool make sure it is the right tool for the job.
My Job 8 and 16 bit battery chargers.
I can see the code as I step though it with the emulator.
I need to know what gets pushed on my tiny stack.
I need to know what is going to call a library and push all the
registers during an interrupt.
On a PC who cares, the memory and power are there.
I need to know that the clocks I pulse out to to get serial data are the
right size each time.
In VB you wound need a C DLL to direct access Hardware registers.
Bit banging works better in C. C can directly access register arrays
without special libraries. Is easier to link to ASM.
C still works on 8 and 16 bit stuff. I try to not to write it all in
ASM. It takes too long and is more tedious.

Managed code has real time limits. C is more predictable. It also
allows you to do play with types. Peek and Poke memory that is not yours
and other hideous stuff. More control, but more ability to screw stuff
up.

So it is far from dead. But it is not the right tool for every job.
There is not 1 perfect tool for all jobs.
You write Windows program in assembler. I would not recommend it.
There are a lot of thing that you can do in C, but is easier in other
languages.
I tend to talk to the chargers in VB 6. It is much quicker and easier
to debug. ( It is also obsolete)
When ask to write a program to reflash them. that " must fit on a
floppy, and does not have to be installed"
only C and C++ jumped out. C++ would have been over kill.

Learning C will not hurt a programmer. Nor would learning ASM. Someone
fresh out of school has a high chance of tripping over it.

The electric screw driver did not make the regular one obsolete. All
the new stuff has not made C obsolete yet.
BTW try this Is assume JPL has a few programmers. On a board write all
the languages all have programed in. Note the number of dead or almost
dead ones.

No I can not believe I wrote so much on this topic.

Neil

 

[Kevin Bagust]

Xenos wrote:

According to the Free OnLine Dictionary Of Computing

Assembly Language

<Snip>

Where as from the same place:

http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?query=Assembler

<programming> A program which converts assembly language into machine
code.

(1996-03-25)

and

http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?assembly+language

<language> (Or "assembly code") A symbolic representation of the machine
language of a specific processor. Assembly language is converted to
machine code by an assembler. Usually, each line of assembly code
produces one machine instruction, though the use of macros is common.

Programming in assembly language is slow and error-prone but is the only
way to squeeze every last bit of performance out of the hardware.

Filename extension: .s (Unix), .asm (CP/M and others).

See also second generation language.

(1996-09-17)

 

[RoSsIaCrIiLoIA]

C effectively the next step above Assembly.
It gives more control over memory usage and hardware access.
You pay for the control with more responsibility. More code to do the
same task.
And you get to watch for buffer overruns and memory leaks.

and if
it is defined a function that in the end of prog free all dynamic
allocated memory with malloc or realloc? (there will no memory leak)

and if
there were library functions that doesn't allow buffer overrun?

 

[Erik de Castro Lopo]

and if
it is defined a function that in the end of prog free all dynamic
allocated memory with malloc or realloc? (there will no memory leak)

That is not the problem. What if you have a program that needs to run continuously
for weeks or months, like a mail or web server, database? If this program has a
memory leak, it can run out of memory. Releasing memory when the progam
terminates is not a solution.

and if
there were library functions that doesn't allow buffer overrun?

Carefuly programming with functions already in the standard library can
prevent buffer overflows.

Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo (e-mail address removed) (Yes it's valid)
+-----------------------------------------------------------+
"The day Microsoft makes something that doesn't suck is probably the
day they start making vacuum cleaners." -- Ernst Jan Plugge

 

[E. Robert Tisdale]

http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?assembly+language

<language> (Or "assembly code") A symbolic representation of the machine
language of a specific processor. Assembly language is converted to
machine code by an assembler. Usually, each line of assembly code
produces one machine instruction, though the use of macros is common.

Programming in assembly language is slow and error-prone but is the only
way to squeeze every last bit of performance out of the hardware.

Filename extension: .s (Unix), .asm (CP/M and others).

See also second generation language.

(1996-09-17)

I used Google

http://www.google.com/

to search for

+"assembler language"

and I found lots of stuff including

http://search390.techtarget.com/sDefinition/0,,sid10_gci211604,00.html



The *correct* name for the language accepted by an assembler
is assembler.

The term "assembly language" is an anachronism used by the "unwashed".

 

[Michael Wojcik]

Legacy code is a big reason why COBOL is still around.

New applications are also a big reason why COBOL is still around.

Once a programming language comes into widespread use, it tends to
stick around. In the case of COBOL, there's a very large workforce
of COBOL programmers, and development managers who are used to
running COBOL projects, and company officers who are comfortable with
the idea of COBOL-based applications - factors which prevent COBOL
from becoming a "maintenance" language. (I imagine the situation
with Fortran is similar.)

Which is fine with me, since COBOL pays my salary.

Getting back on topic: C has even more momentum than COBOL, in part
because it's also a popular hobbyist language; free implementations
are readily available, as is source code to examine and modify; the
runtime is generally preinstalled, which simplifies packaging and
distribution of programs.

--
Michael Wojcik (e-mail address removed)

[After the lynching of George "Big Nose" Parrot, Dr. John] Osborne
had the skin tanned and made into a pair of shoes and a medical bag.
Osborne, who became governor, frequently wore the shoes.
-- _Lincoln [Nebraska] Journal Star_

 

[Darrell Grainger]

The correct term is *assembler*.

Go to www.dictionary.com ans search for "assembly language". Or you could
try going to IEEE and get a copy of 610.12. From the IEEE:

assembly language. A programming language that corresponds
closely to the instruction set of a given computer, allows
symbolic naming of operations and addresses, and usually
results in a one-to-one translation of program instructions
into machine instruction. Syn: assembler language; low
level language; second generation language.

How could you not be aware of this? You have lost a great deal of
credibility and so far you have only made one statement. By the way, an
assembler is the computer program that translates programs expressed in
ASSEMBLY LANGUAGE into their machine language equivalents.

Compare C language to assembly language. It is nonsense to compare C
language to an assembler.

Here are the first five lines of an assembler listing:

.file "main.c"
.text
.align 2
.globl loop
.type loop,@function

Please tell us
which machine language instructions correspond to these lines.

Proof by example. NOTE: 'close to' or 'similar'. To prove that assembly
language is not 'close to' machine language you must show how there is a
notable difference between *ALL* assembly listings and machine language.

How is C "similar" to assembler?

The C programming language is not similar to an assembler. I never claimed
that it was.

I don't dispute that
assembler *instructions* correspond to machine instructions.

You seem to be stuck on semantics here. If you cannot understand that
assembler instructions and assembly language (or assembly code or
assembler code) are the same thing then you are too thick to talk to.

I have noticed that certain statements in C language
will *not* always produce the same machine language on a given machine.

Okay, so C language is not EXACTLY machine language. There is not a hard
one-to-one correspondence. Thus it has been said that C is 'close to' the
machine language.

Generally, the emitted code depends upon context.
Different compilers emit different machine code
for the same C language statements.
Different options can cause the compiler to emit different machine code
for the same C language statements.


How, then, can C language code be "close" to machine language code
on each of these different architectures?

For any given architecture it is 'close to' that architecture. If I was to
write a loop that counted from zero to 100 in PDP-11 assembly language,
same thing for a MC68000 assembly language and again for ARM9 assembly
language there will be similarities between them. Even if I never
programmed ARM9 assembly language, I could look at the code and figure out
it is a loop that counts from 0 to 100. If I compiled:

for(i = 0; i <= 100; i++)
/* do something */

The machine code generated by this code snippet would be similar on
PDP-11, MC68000, ARM9 just like the assembly language on those three
processors would be similar. They will never be exact but the general idea
will be the same. This is what 'close to' means.

I have a hardware design background.


Most of us don't do this anymore.
We use good optimizing compilers instead/

You took a survey? Or asked all the embedded programmers in the world? I
can believe that there are embedded programmers who don't know assembly
language but I would never say that 'most of them' don't do this anymore.
My experience has been that they do. I have seen certain groups of
embedded programmers that don't know what is happening at the machine
level but my experience has been that the majority of them do.

You need read the assembler listing emitted by you C compiler
to know exactly what your C program is doing.

Or you load the program in to a debugger and do a disasssembly of it. This
is how most the people I work with know what the C compiler is doing.
Actually, the debugger I have will display the C code with the assembly
language interlaced.

The assembler will depend upon

1. the machine architecture,
2. the compiler and
3. the options that you chose to compile your program.

C programmers are notoriously bad at predicting
what assembler code will be emitted
when they port their programs from one platform to another.

How have you come to this conclusion?

I guess the bottom line is that my experiences are different from your.
You seem to be exposed to a different group of programmers than myself.
Additionally, the fact that you are so hung up on semantics makes me
wonder if there is any point discussing this any further.

This will most likely be the last posting from me on the topic. I see no
reason for beating a dead horse.

 

[Darrell Grainger]

I used Google

http://www.google.com/

to search for

+"assembler language"

and I found lots of stuff including

http://search390.techtarget.com/sDefinition/0,,sid10_gci211604,00.html

Went there.

The *correct* name for the language accepted by an assembler
is assembler.

Searched the page for "correct". Found no reference.

The term "assembly language" is an anachronism used by the "unwashed".

Searched for "assembly language". Found 1 occurence:

Some people call these instructions assembler language
and others use the term assembly language.

Nothing about whether it is correct or not. No reference to "unwashed". It
seems to me that this is your opinion. I choose to disagree with your
opinion.

<Plonk>

 

[Joona I Palaste]

Go to www.dictionary.com ans search for "assembly language". Or you could
try going to IEEE and get a copy of 610.12. From the IEEE:

assembly language. A programming language that corresponds
closely to the instruction set of a given computer, allows
symbolic naming of operations and addresses, and usually
results in a one-to-one translation of program instructions
into machine instruction. Syn: assembler language; low
level language; second generation language.

How could you not be aware of this? You have lost a great deal of
credibility and so far you have only made one statement. By the way, an
assembler is the computer program that translates programs expressed in
ASSEMBLY LANGUAGE into their machine language equivalents.

Compare C language to assembly language. It is nonsense to compare C
language to an assembler.

Proof by example. NOTE: 'close to' or 'similar'. To prove that assembly
language is not 'close to' machine language you must show how there is a
notable difference between *ALL* assembly listings and machine language.

The C programming language is not similar to an assembler. I never claimed
that it was.

You seem to be stuck on semantics here. If you cannot understand that
assembler instructions and assembly language (or assembly code or
assembler code) are the same thing then you are too thick to talk to.

Either E.Robert Tisdale is a patent idiot or he does a very good job at
pretending to be one. Trying to get your point across to him is a lost
cause. Arguing with him is futile. I suggest all comp.lang.c
participatns killfile him.

 

[Ben Pfaff]

The correct term is *assembler*.

[...]
How could you not be aware of this? You have lost a great deal of
credibility and so far you have only made one statement. [...]

ERT had credibility? That's news to me. You're best off just
ignoring his articles; he rarely has useful information to
impart.

 

[Richard Bos]

On Fri, 30 Apr 2004, E. Robert Tisdale wrote:

You have lost a great deal of credibility
Amazing.


Okay, so C language is not EXACTLY machine language. There is not a hard
one-to-one correspondence. Thus it has been said that C is 'close to' the
machine language.

Then again, that _is_ a vast overstatement.

For any given architecture it is 'close to' that architecture.

Oh, bull. C is the same on each architecture; the machine languages
differ, sometimes greatly. C can be interpreted; what does an
interpreter have to do with machine code?

If I was to
write a loop that counted from zero to 100 in PDP-11 assembly language,
same thing for a MC68000 assembly language and again for ARM9 assembly
language there will be similarities between them. Even if I never
programmed ARM9 assembly language, I could look at the code and figure out
it is a loop that counts from 0 to 100. If I compiled:

for(i = 0; i <= 100; i++)

Yes, but this says absolutely _nothing_ about C. Lots and lots of
programming languages have very similar constructs. Basic has FOR ...
NEXT; Pascal has for ... do; Icon has foreach.
If anything, the for statement seems to prove that C is _less_ close to
machine language than Basic and Pascal, and about as close as Icon,
because while all Basic and Pascal have is the normal, assembly-alike,
count up or down, C allows for loops like

for (ptr=list_head, total=0; ptr; total+=amount(ptr), ptr=ptr->next)
modify_list_element(ptr);

which does not have a similarly close equivalent in assembler language
(and Icon allows similar things with hand-written generators).

Richard

 

[-wombat-]

I don't know what that means.
Which "machine" is C "close to"?
Is C "farther" from machines that are not "close to"
the machine that C is "close to".
What sort of topology allows this sort of reasoning?

Oh, come on, Robert. You embarrass the rest of us UCLA Ph.D's and soon-to-be
Ph.Ds. Walter is probably spinning in his grave.

It's a fundamental tenet in languages that there is a hypothetical, perfect
virtual machine that models the implementation and runtime semantics of a
language. C is no exception.

And yes, C is a portable assembler for lack of a better phrase. It seems to
grow like a weed on many different platforms because the processor model of
most platforms maps well to the hypothetical VM that maps to the language.

 

[Paul Hsieh]

I am new to C and curious to know some basic questions about C.
Why C is good? In what way its better than any other languages?

Of course, some would argue that its not.

But in any event, C is usually implemented very close to the latest
ANSI and ISO standards prior to C99, and its implemented for just
about every platform in existence. For example, there are basically
no (or very few) C++ compilers that are totally standards compliant,
while very few C compilers are not. C has a long history, is fairly
stable, and has good functionality. There are more generally
applicable books and tools written for C than any other language.

If it is no longer a choice of programming language...why people still study
it?

Knowing C is kind of a prerequisite for learning C++.

And also its not an OO language either...is there any advantages in being
not an OO language?

OO introduces more complications to programming languages that have
nothing to do with general computation. Like Perl, OO makes programs
easier to write, but harder to maintain. More people know and
understand basic C, than the OO features of C++ -- this means that
moving to OO will necessarily reduce the set of programmers that will
be equipped to deal with it.

OO also has no feature which can improve the performance of programs
that cannot be duplicated with non-OO mechanisms. At the same time OO
hides lots of implementation details which *CAN* drastically impact
performance in a negative way. One typically needs a lot of expertise
to know when these cases occurr and to know how to avoid them.

 

[August Derleth]

Of course, some would argue that its not.

But in any event, C is usually implemented very close to the latest
ANSI and ISO standards prior to C99, and its implemented for just
about every platform in existence. For example, there are basically
no (or very few) C++ compilers that are totally standards compliant,
while very few C compilers are not. C has a long history, is fairly
stable, and has good functionality. There are more generally
applicable books and tools written for C than any other language.

All of this true to a surprisingly large extent, but it can be difficult
to make some compilers conform to /only/ C89. For example, gcc requires a
small clutch of command-line options (-ansi -pedantic -Wall) to /not/
compile its set of extensions /and/ to generate all of the warnings it
needs to.

Knowing C is kind of a prerequisite for learning C++.

False. C++ can be learned as a standalone language, and even as a /first/
language. (Although beginning with Python might be better, that's a matter
of pedagogical taste.)

In fact, learning about C and C++ as two very different languages (as
different as, say, Algol-68 and Pascal) is the best, in terms of code
hygiene (should malloc() be cast?) and conceptual modeling (the C++ STL,
for example, allows much different approaches to problems than the C
standard library).

OO introduces more complications to programming languages that have
nothing to do with general computation. Like Perl, OO makes programs
easier to write, but harder to maintain. More people know and
understand basic C, than the OO features of C++ -- this means that
moving to OO will necessarily reduce the set of programmers that will
be equipped to deal with it.

Now, this is simply ignorant. OO can improve the organization and
maintainability of the code by orders of magnitude when used by skilled
professionals, as opposed to inept fools. OO allows a programmer to
enforce a single unified interface to his solutions, as opposed to a
hodge-podge of exported subroutines and messy global variables.

OO also has no feature which can improve the performance of programs
that cannot be duplicated with non-OO mechanisms. At the same time OO
hides lots of implementation details which *CAN* drastically impact
performance in a negative way. One typically needs a lot of expertise
to know when these cases occurr and to know how to avoid them.

OO does nothing of the sort. Compilers and, to a lesser extent, languages
do. The take-home lesson here is that languages aren't inefficient,
programs are: Either the OO code you write is absolutely hideous cruft
(likely) or your tools are badly-written.

 

[Paul Hsieh]

False. C++ can be learned as a standalone language, and even as a /first/
language. (Although beginning with Python might be better, that's a matter
of pedagogical taste.)

But if you try to learn C++ by itself, you end up learning basic C as
a result. You may learn something different about NULL, the way
structures can be declared, and how sizeof works, but these are
details that even C programmers are often not very clear on.

My point is that if you can't learn C for whatever reason, you aren't
really going to be able to learn C++.

In fact, learning about C and C++ as two very different languages (as
different as, say, Algol-68 and Pascal) is the best, in terms of code
hygiene (should malloc() be cast?)

Should malloc be cast in C is a paranoia that I believe exists
strictly in CLC. I believe people outside CLC will cast it or not as
it suits them or, in C++'s case, as its required. Knowing this or
not, is not what I would seriously consider "knowledge" about C. Of
course malloc isn't used much in C++ at all.

Now, this is simply ignorant. OO can improve the organization and
maintainability of the code by orders of magnitude when used by skilled
professionals, as opposed to inept fools.

You don't see the inherent contradiction in the statement you just
wrote? The bar for dealing with C++ is simply higher. You only point
out the extremes, but one cannot maintain what one does not
understand. The C++ standard is apparently > 1000 pages -- meaning
that even if you understand C++ for your own purposes, understanding
it to maintain someone else's code is a completely different matter.

[...] OO allows a programmer to
enforce a single unified interface to his solutions, as opposed to a
hodge-podge of exported subroutines and messy global variables.

C doesn't require or encourage a hodgepodge of exported subroutines or
messy global variables. Minimizing or completely eliminating the use
of global variables is a good habit that has nothing to do with
anything about C or C++. The "static" keyword and function pointers
were also introduced in C, not C++.

OO does nothing of the sort. Compilers and, to a lesser extent, languages
do.

This is just an assertion, and you don't understand that its wrong.
For example, to compute any algebraic expression, a compiler will
model the computation with temporary variables. However, whether or
not the compiler can eliminate some of the temporaries may be beyond
even the theoretical capabilities of any compiler -- and its usually
not clear unless the programmer goes through the same work as the
compiler by hand.

C++ introduces the concept of contructors/destructors which
necessitates built-in memory management for objects. This is fine
except that if you create an array of objects, raw performance of this
memory management and the fragmentation of the heap itself could be
improved if a group of objects (related by their use, not their type)
were allocated in a single allocation call. A C programmer has no
problem seeing and doing this -- I know of no C++ compiler capable of
this.

STL's vectors, for another example, have a surprising implementation
that requires that the default constructor be present for your object.
The reason is that in order to append an entry, its going to create
the default one, then copy the one you are passing via "=". That's
all very interesting, except that depending on your object design, the
"class A1(A0)" initialization idea (if implemented as basically a
copy) can skip this extra construction step (which can be arbitrarily
expensive -- your object could launch a thread on construction, for
example.) STL can't see this because of its implementation, and what
the language C++ specifies (the compiler can't know that class A1(A0)
is going to implement copying, even if the programmer does.)

[...] The take-home lesson here is that languages aren't inefficient,
programs are:

Ok now who's talking about ignorance. Look at Fortran, the "volatile"
keyword addition to C in C99, and any benchmarks of Java, C and Lisp.
There are serious differences in languages with respect to
performance, that go beyond the different capabilities of compilers.

People who follow these things on Windows like to hail the Intel C
compiler as being somewhat miraculous for being able to maintain a 20%
edge over MSVC or gcc, however I would be surprised if there is any
program in either Java of Fortran that stays pretty much within 20% of
C. You could at best make this argument between C and Pascal perhaps
-- but one could argue that these languages are very close in what
they implement beyond their syntactical differences.

 

[Guillaume]

Now, this is simply ignorant. OO can improve the organization and

maintainability of the code by orders of magnitude when used by skilled
professionals, as opposed to inept fools. OO allows a programmer to
enforce a single unified interface to his solutions, as opposed to a
hodge-podge of exported subroutines and messy global variables.

True (when properly used), but you can write C in an OO manner.
I've been using C in this way for years. And have still good
reasons to do so instead of using C++.

OO does nothing of the sort. Compilers and, to a lesser extent, languages
do. The take-home lesson here is that languages aren't inefficient,
programs are: Either the OO code you write is absolutely hideous cruft
(likely) or your tools are badly-written.

True in an abstract environment, but not true in the real world.
If you take the example of C vs. C++: there is no way you can make the
same piece of software use less resources and memory space with C++
compared to a C solution. Some people have been claiming the opposite
for ages, but I have yet to see a single proof of it.

 

[CBFalconer]

.... snip ...

[...] OO allows a programmer to enforce a single unified
interface to his solutions, as opposed to a hodge-podge of
exported subroutines and messy global variables.

C doesn't require or encourage a hodgepodge of exported
subroutines or messy global variables. Minimizing or
completely eliminating the use of global variables is a good
habit that has nothing to do with anything about C or C++.
The "static" keyword and function pointers were also introduced
in C, not C++.

For an example of OO design in pure C, see my hashlib (URL
below). It is designed so that the user can only get his hands on
objects he designs himself (barring futzing with the hashlib
source code). All this is done through the normal C abilities,
with the exception that the user is told not to alter the portion
of the data object on which the hash depends. The use of static,
void *, and incomplete structures is essential. The user, in
turn, can define his objects as he likes, but must define a
specified set of operations on them. This is really no more than
an exercise in information hiding.

See <http://cbfalconer.home.att.net/download/hashlib.zip>

 

[Vivek Mohan]

Hi,
I am new to C and curious to know some basic questions about C.
Why C is good?

Well, Yes and No. Its very good for the kind of programming task where
you need to be closer to the hardware, directly access the memory, and
need speed/effeciency. But when you are out to solve generic problems
where hardware is not a matter of concern, C would probably be a
not-so-good choice.

A 10 line program in C can be converted to a single line program in
Python. But that takes away speed. So its your choice.

In what way its better than any other languages?

Well, most(!) other languages are written in C (eg. Python, Perl, PHP,
Ruby etc.) And IMHO its foolish to compare languages like this to C as
much as its foolish to compare a high level language with assembler or
uP opcodes, so to speak. I know a lot of "programmers" who complain
about the way strings are handled in C and the poor support for them;
and then they brag about how easy it is to do so in perl/php.

If it is no longer a choice of programming language...why people still study
it?

Frankly speaking, its because no other language has been able to
replace it and it still is the choice of programming language. Check
out the source code for any of the BSDs/Linux'es, they all use C. I
know people who develop operating systems in C++ but I don't think its
worth the effort. Even GNU prefers that all its official software be
written in C. I know there will be 1000s of anti-C advocates to refute
me, but they've been around since C was born.

And also its not an OO language either...is there any advantages in being
not an OO language?

OO is not everything. Oh yeah, if you really understood OO, to some
level it can be acheived in C also, although it could get ugly, thats
all.

http://ldeniau.home.cern.ch/ldeniau/html/oopc/oopc.html

I know one reason is that, IT started with C and so they are still using
them rather than changing it into new language.

Oh no, C is not as ubiquitous as everybody thinks. Check this out and
drive your myths away -

http://www.cobolwebler.com/cobolfacts.htm

Peace.
Vivek

 

[Vivek Mohan]

Hi,
I am new to C and curious to know some basic questions about C.
Why C is good?

Well, Yes and No. Its very good for the kind of programming task where
you need to be closer to the hardware, directly access the memory, and
need speed/effeciency. But when you are out to solve generic problems
where hardware is not a matter of concern, C would probably be a
not-so-good choice.

A 10 line program in C can be converted to a single line program in
Python. But that takes away speed. So its your choice.

In what way its better than any other languages?

Well, most(!) other languages are written in C (eg. Python, Perl, PHP,
Ruby etc.) And IMHO its foolish to compare languages like this to C as
much as its foolish to compare a high level language with assembler or
uP opcodes, so to speak. I know a lot of "programmers" who complain
about the way strings are handled in C and the poor support for them;
and then they brag about how easy it is to do so in perl/php.

If it is no longer a choice of programming language...why people still study
it?

Frankly speaking, its because no other language has been able to
replace it and it still is the choice of programming language. Check
out the source code for any of the BSDs/Linux'es, they all use C. I
know people who develop operating systems in C++ but I don't think its
worth the effort. Even GNU prefers that all its official software be
written in C. I know there will be 1000s of anti-C advocates to refute
me, but they've been around since C was born.

And also its not an OO language either...is there any advantages in being
not an OO language?

OO is not everything. Oh yeah, if you really understood OO, to some
level it can be acheived in C also, although it could get ugly, thats
all.

http://ldeniau.home.cern.ch/ldeniau/html/oopc/oopc.html

I know one reason is that, IT started with C and so they are still using
them rather than changing it into new language.

Oh no, C is not as ubiquitous as everybody thinks. Check this out and
drive your myths away -

http://www.cobolwebler.com/cobolfacts.htm

Peace.
Vivek