Is C a 'good' programming language?

[VectraMan]

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.

...

Of course Java has its own problems including resource leaks that can be more subtle to locate/fix.

And therein is the issue. Maybe it's the C++ programmer in me, but just trusting that something else will take care of your problems for you feels irresponsible, maybe even reckless. And as you say, it's not like you can't possibly have resource leaks in Java/C#, and maybe it's the "not my problem" attitude that causes those issues.

You can ignore memory deallocation in C too, because ultimately the OS will take care of it when you close the program. It's only an issue if your software has to keep working over time.

[tim123]

GOTO
The BREAK command is a GOTO. It is common practice in C to simply do direct jump out of loops an conditions.

No it's not.

Never in 20 years have I used a "break command" and the number that I have seen used by other people can be counted on the fingers of one hand.

tim

[RichardCranium]

Never in 20 years have I used a "break command" and the number that I have seen used by other people can be counted on the fingers of one hand.

Do you not use switch?

[tim123]

Do you not use switch?

OK yes, but that's not a loop as per the example.

Lots of languages have a statement similar to a "c" switch. This isn't a structurally bad thing to do

tim

[RichardCranium]

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

No it's not.

Never in 20 years have I used a "break command" and the number that I have seen used by other people can be counted on the fingers of one hand.

OK yes, but that's not a loop as per the example.

Lots of languages have a statement similar to a "c" switch. This isn't a structurally bad thing to do

There is nothing wrong with switch, except that it requires the use of break.

break is an unconditional jump to 'somewhere'. The maintenance programmer, looking at the code at 'somewhere', has nothing to tell them it is the destination of an unconditional jump further up the code. That is not the mark of a self-documenting language; it is as bad as the poor programmer's use of GOTO but without even a label to give a clue that it might be a destination.

[VectraMan]

There is nothing wrong with switch, except that it requires the use of break.

Switch doesn't require the use of break, it's just a bit of syntax that K&R clearly got wrong. The meaning of break inside switch is totally different to break inside a loop, and indeed can cause a conflict when you actually want to jump out of a loop from within a switch.

break is an unconditional jump to 'somewhere'. The maintenance programmer, looking at the code at 'somewhere', has nothing to tell them it is the destination of an unconditional jump further up the code.

"Somewhere" being out of the loop, which isn't exactly hard to work out. The alternative to break involves setting a flag, testing the flag all through the rest of the loop and finally as part of the loop test, which isn't complicated but given the frequency that you have to write a loop which exits on a condition, is a bit overkill.

I'd suggest that the use of break is no more spaghettifying than the use of if.

[minestrone]

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.

Hope? You clearly have no idea what you are talking about.

If you walked into an interview and said that to me you would be sent out the door in a second.

[NickFitz]

...just trusting that something else will take care of your problems for you feels irresponsible, maybe even reckless

So when you output a character to the display, do you then call a function that examines the display memory and confirms that the correct values are at the correct locations? What about writing to a file on disk - do you have a low level routine to check that the MFM encoding (or whatever they use nowadays) was done correctly?

[VectraMan]

So when you output a character to the display, do you then call a function that examines the display memory and confirms that the correct values are at the correct locations? What about writing to a file on disk - do you have a low level routine to check that the MFM encoding (or whatever they use nowadays) was done correctly?

Yes.

Well no, but I would look at the screen to verify what I was expecting to be there actually was, and I would look at the file to verify in the same way. I wouldn't assume that whether the right thing that appeared on the screen was "somebody else's problem" and not bother to check (although it might be somebody else's problem to fix it).

If you wrote a Java application that leaked memory and crashed after a couple of hours, would you say to your client: "Not my problem. It's got garbage collection innit"?

[NickFitz]

If you wrote a Java application that leaked memory and crashed after a couple of hours, would you say to your client: "Not my problem. It's got garbage collection innit"?

If I wrote a Java application that leaked memory then I would clearly have done something wrong, and that would be my problem. If the client chose to use a JVM that had a buggy GC implementation then that would be their problem.