Is C a 'good' programming language?

[RichardCranium]

This is just a quick off-the-top-of-my-head rant 'cos I was prompted so to do.


Executive Summary
I believe C is an abortion of a language. It has no beauty, no elegance. It is assembler with big tits and a collagen arse. I am appalled the world chose to adopt a language with no memory management and an ambiguous syntax; it should never have left academia.



I have only used about six proper programming languages (in about 10 different incarnations across various platforms) plus a handful of scripting languages, macro languages and similar tools. Hence, I cannot claim to be a computer scientist nor a very broad experience but I think I do have a feel for what makes a good programming language. I do not think C is such a language.


Defensive programming
Not all programmers are perfect. One of the techniques developed decades ago to counter this problem was 'defensive programming'. This entails certain behaviour by the programmer (e.g. inline documentation, meaningful variable names, checking returned values) and certain activities by the compiler and runtime environment.

The philosophy of C seems to be the opposite. Obfuscated code is revered. Single letter variable names are all but recommended by K&R and whether a function is a procedure or vice versa is considered immaterial. The latter is a particular crime as it discourages proper (Pascal-like) structured programming.


GOTO
The BREAK command is a GOTO. It is common practice in C to simply do direct jump out of loops an conditions. The language encourages it. This makes for spaghetti code.

Hardware independence
Big-endian or little-endian? Word length varies by processor. I need say no more: the code is not transportable. Of course, those who have never worked on anything other than a Windows PC will neither know nor care about this. Sadly, that is most programmers.


Memory management
Most of the problems encountered with DOS & Windows PC for the last couple of decades have been down to vulnerabilities and memory leaks. C is the cause of both of these.

A decent programming language helps the programmer by undertaking memory management. Having the programmer do it rather defeats the object of having a computer involved. By using a proper program structure, the compiled program should be taking and releasing memory as required automagically. No leaks, guaranteed.

Also, a decent programming language would prevent the accidental scribbling over of RAM that C seems to expect. It is even considered a 'power' of the language that one can address any element of an array regardless of the array size. Ridiculous. The compiled program should not be allowing an incorrectly set variable to be used as an index to a list that is outside the bounds of the list.

It is by allowing lists to be exceeded that many vulnerabilities exist: C is the source of weakness that allows the computer to be taken over by rogue code.


String handling
Yes, strings. We humans make a lot of use of text streams in our lives. WTF is the string data type?


Use of libraries
If you actually want to do anything of any use, it is necessary to choose some libraries of functions to do them. There are so many of these that going from client site to client site frequently requires the programmer to learn different ones. Many of these functions would have been included in a more complete language. Even the most trivial: basic mathematics, screen, keyboard and file handling are not present. That is not the mark of a 3GL. It is a 2.5GL.


Ambiguous syntax
There are instances of syntax where it is at the compiler's discretion how to handle it. That is, it is not possible to predict what the compiled code will do without setting up a test bed and seeing how this version of this compiler behaves on this hardware.

That is shoddy and unsafe.


Philosophy
I believe the philosophy of the language makes it unsuitable for serious business use. Obfuscated, ambiguous code is hard to debug and fix which makes maintenance inefficient. As a weakly-typed language, typographical errors are more likely. Being able to not specify all the fields for functions and procedures also increases the likelihood of errors.

It is a language designed to be compilation error free, compounded with runtime errors occurring silently.

It promotes invisible bugs.

Sadly, this also makes it fun and easy to use so programmers cling to it in preference over more fastidious programming languages, hence its popularity. But its choice as a programming language from a business perspective is poor.


Other stuff
I used to be able to rattle off about 30 criticisms off the top of my head. Thankfully most did not stick. But this list above will do as a starter.

[Shimano105]

Use .NET intead. Simples.

[d000hg]

Um, what? C is a systems programming language designed to be small, easy to implement and with very low overheads. It's elegant in a way due to it's simplicity, not its features.
C was also written at a time when computers were a million times slower than today, I don't know memory management and so on would have been possible while keeping the apps fast enough... also bear in mind that garbage collection STILL makes modern languages unsuitable for some tasks.

Seems like a rant over nothing.

Also, LOL @

Most of the problems encountered with DOS & Windows PC for the last couple of decades have been down to vulnerabilities and memory leaks. C is the cause of both of these.

What language exactly do you think Linux was written in?

C IS assembly language wrapped in a more user-friendly set of clothes. It doesn't pretend to be anything else.

[voodooflux]

Can I just answer *yes* to the original question for now, and elucidate when I'm sober

[VectraMan]

I had to do some C at my last gig, and what really suprised me was something that I'd completely forgotten about C was just how much you needed to think about memory usage. With no ability to wrap resources up in container types, you had to think about every possible exit to a function and how it had to deallocate anything that had been allocated in that function.

C++ is about a thousand times better, but ironically, C#/Java can almost be said to be a step backwards to the bad old days of C because you can't use the C++ approach of creating objects on the stack and being certain of the compiler doing the work to make sure they're destroyed. In C#/Java you have to hope that the garbage collection probably will sometime deallocate your objects, but you can't be sure when and if you're quickly testing to verify the behaviour, you'll probably never see it happen.

That's why I'd say C++ > C#/Java > C.

[Addanc]

C tends to get used in embedded systems which are often based on bare hardware with a small memory foot prints i.e. where there isn't a gigabyte of OS and supporting stack on which you can run your Java machine/.NET framework.

GOTO
The BREAK command is a GOTO. It is common practice in C to simply do direct jump out of loops an conditions. The language encourages it. This makes for spaghetti code.

That's why we have MISRA.

Hardware independence
Big-endian or little-endian? Word length varies by processor. I need say no more: the code is not transportable. Of course, those who have never worked on anything other than a Windows PC will neither know nor care about this. Sadly, that is most programmers.

Neither is Jave/.NET until somebody writes an OS on which it can be hosted; elements of which are probably written in C

Memory management
Most of the problems encountered with DOS & Windows PC for the last couple of decades have been down to vulnerabilities and memory leaks. C is the cause of both of these.

A decent programming language helps the programmer by undertaking memory management. Having the programmer do it rather defeats the object of having a computer involved. By using a proper program structure, the compiled program should be taking and releasing memory as required automagically. No leaks, guaranteed.

Wouldn't surprise me one bit if parts of the Java machine where written in C.

Use of libraries
If you actually want to do anything of any use, it is necessary to choose some libraries of functions to do them. There are so many of these that going from client site to client site frequently requires the programmer to learn different ones. Many of these functions would have been included in a more complete language. Even the most trivial: basic mathematics, screen, keyboard and file handling are not present. That is not the mark of a 3GL. It is a 2.5GL.

If you need library routines the ANSI C library has sufficient for bare hardware; anyway if you feel the need to start using floating point mathematics you obviously don't understand the problem. WRT screen, keyboard and file handling you O/S provides the hardware abstraction for these; you 3GL just hooks into that hardware abstraction.

Ambiguous syntax
There are instances of syntax where it is at the compiler's discretion how to handle it. That is, it is not possible to predict what the compiled code will do without setting up a test bed and seeing how this version of this compiler behaves on this hardware.

That is shoddy and unsafe.

MISRA; don't use compiler dependent syntax.

Philosophy
I believe the philosophy of the language makes it unsuitable for serious business use. Obfuscated, ambiguous code is hard to debug and fix which makes maintenance inefficient. As a weakly-typed language, typographical errors are more likely. Being able to not specify all the fields for functions and procedures also increases the likelihood of errors.

...

Sadly, this also makes it fun and easy to use so programmers cling to it in preference over more fastidious programming languages, hence its popularity. But its choice as a programming language from a business perspective is poor.

All languages have their niche; C isn't suited to developing complex business systems; WRT embedded systems (which don't come with a pre-installed O/S) it better than Java/.NET. A lot of the problems with C can be prevented with suitable coding standards and development processes. Idiots can still produce rubbish systems with Java/.NET which either don't operate reliably, or don't do what the end-client wants, or both.

Summary:
WRT Embedded systems: C/C++ > ADA(prob need to port ADA runtime) > Java/.NET

Most importantly C keeps pound notes in my pockets, so bugger off slanging of this wonderful language.

[d000hg]

I see a few gigs asking for C++ but not pure C... maybe I should target these more as valuable legacy skills?

[MPwannadecentincome]

All languages have their niche; C isn't suited to developing complex business systems.

Unfortunately before Java came along and anyone who was not OOD trained and were not mainframe developers were most likely writing serious business systems in C, some of these will still be knocking around today.

[DSW]

I had to do some C at my last gig, and what really suprised me was something that I'd completely forgotten about C was just how much you needed to think about memory usage. With no ability to wrap resources up in container types, you had to think about every possible exit to a function and how it had to deallocate anything that had been allocated in that function.

C++ is about a thousand times better, but ironically, C#/Java can almost be said to be a step backwards to the bad old days of C because you can't use the C++ approach of creating objects on the stack and being certain of the compiler doing the work to make sure they're destroyed. In C#/Java you have to hope that the garbage collection probably will sometime deallocate your objects, but you can't be sure when and if you're quickly testing to verify the behaviour, you'll probably never see it happen.

That's why I'd say C++ > C#/Java > C.

I disagree with Java memory management being inferior. Its not about hoping it gc's it - the point is you don't have to care, you can ignore it. However, If you need real time deterministic memory management then you would need a real time version of Java. Most of the time devs don't need to worry about when memory is actually disposed though, esp in J2EE world. In fact with Spring/Java trends of singletons less memory management is done in the first place. Of course Java has its own problems including resource leaks that can be more subtle to locate/fix.

c++ is certainly more powerful, but pretty quickly I think you end up in the typed/untyped language debate...

[Sysman]

A Critique of C++ (HTML) and here's the PDF version