Is C a 'good' programming language?

[d000hg]

Hmm, 2 things:

1)break is not evil. It doesn't allow arbitrary code jumps like goto (which IS part of C). Neither does continue. break is used extensively in C/C++ apps and it's very limited... you can't even break out of a nested loop it's that weedy.

2)Memory management... old-school coders frequently mistrust GC in modern languages and in nearly every case they're just wrong to do so. You don't normally need to care when something is deallocated/destroyed.
However, there are exceptions. Code that has to be timed very precisely sometimes needs to know the GC won't jump in and interrupt processing. But, these are not normal applications we're talking about.

[swamp]

In my experience C and C++ers get very defensive and look down on anyone who uses 'managed' languages like Java, C# et al. They seem to believe they have some superior 'skill' in being able to write super optimised code. IMO they forget two things:

1. In the server environment you need memory protection; you cannot let the entire application crash because of some errant request.
2. Java (and the like) is often actually faster on the server side than C++ (and even C in some situations.)

But at the end of the day each to their own. What really matters is the rate you can charge.

[d000hg]

In my experience C and C++ers get very defensive and look down on anyone who uses 'managed' languages like Java, C# et al.

Yeah it's quite common. I think anyone in software development needs to tread a fine line between getting too attached to technologies they 'grew up' with, and being too keen to always use the newest tools.
I really got to grips with coding through C & C++ and while I enjoy coming back to that every now and then, it leaves me appreciating how much easier C#/Java make most areas of development.

[VectraMan]

It doesn't allow arbitrary code jumps like goto (which IS part of C).

Incidentally I used to work with someone who was adamant that returning in the middle of a function was terrible, and every function had to have one exit point at the end. Not so bad, but instead of returning in the middle, he used to use goto to jump to the end.

2)Memory management... old-school coders frequently mistrust GC in modern languages and in nearly every case they're just wrong to do so. You don't normally need to care when something is deallocated/destroyed.

Guilty, which is why one of the first things I did in C# was to try to verify that it worked. Which I couldn't, really, apart from verifying that the object was destroyed when the program shutdown.

What I was saying is that one of the most powerful things that C++ has over C is the ability to create an object on the stack that manages something, be it memory, a file, access to data, whatever, and you know that its destructor will be called and when, because the compiler guarantees it. C#/Java doesn't have that (except for "using" in C# which is similar), and whilst it's okay for GC to take care of memory, you wouldn't want to wait for GC to take care of closing a file that you can't keep open, for example, because you don't know when it will happen.

Of course there are other solutions, just like there are in C, but it's a technique I use a lot in C++ that I couldn't use in C#. In that respect, I found programming for C# was more like programming for C than C++. Java/C#'ers probably don't miss it, because they never have it, and you can say the same for the inexplicable lack of const types in Java and C#, not to mention friends and multiple inheritance (both of which are a little contentious I agree). But overall I felt in my 6 months as a C# programmer the language forced me to write code to a lower standard than I could have done in C++ (although writing for .NET is much better than Win32/MFC as I mostly did in C++).

It's a shame really because there are a lot of good things about C# and Java that improve on C++, and I'm not talking about low level access to memory and pointers or anything like that. But I think they did throw part of the baby out with the bath water.

1. In the server environment you need memory protection; you cannot let the entire application crash because of some errant request.

I think most "managed" language advocates have a somewhat outdated view of C++. It's not all casting to void* pointers and running amok over the address space (although quite a bit of the legacy code I have to work on is like that). If you're using the proper container types, then there shouldn't be any issues like this, and if you do use a null pointer for example, you can trap the access violation and throw a C++ exception - exactly the same as happens in C#/Java in fact. You don't exit the entire application because of one errant request.

[tim123]

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

break is an unconditional jump to 'somewhere'. .

Not in the case of a switch.

It's the only way of ending each "case" and always jumps to a defined place.

tim

[tim123]

In my experience C and C++ers get very defensive and look down on anyone who uses 'managed' languages like Java, C# et al. They seem to believe they have some superior 'skill' in being able to write super optimised code. IMO they forget two things:
:

This is not my experience

tim

[d000hg]

What I was saying is that one of the most powerful things that C++ has over C is the ability to create an object on the stack that manages something, be it memory, a file, access to data, whatever, and you know that its destructor will be called and when, because the compiler guarantees it. C#/Java doesn't have that (except for "using" in C# which is similar), and whilst it's okay for GC to take care of memory, you wouldn't want to wait for GC to take care of closing a file that you can't keep open, for example, because you don't know when it will happen.

Oh, yes that is a very cool feature. I see it used a lot for locks in multi-threaded code...

void myFunction()
{
 mutex m;
.
.
.
}//m automatically destroyed, we make it's ctor establish a lock
//and dtor free it

[crabfoot]

In defence of C

I do very little programming these days - but twenty years ago I did a lot.

The original concept of C was to make a few small powerful functions which would be building blocks for more functions. The original objective was to give a powerful language to simplify writing Unix, which minimised explicit knowledge for assembler. The advantages of C as a cross-platform language were obvious, which is one reason why it became popular.

C code can be elegant and clean, or dirty spaghetti, depending on how you write it and how well the compiler was written. Having learned C on VAX and A400 platforms, I quickly learned to despise the team that built the original Turbo C compiler (and actively hate the Econet 88 team) when I moved to using C on a PC.

C+, C++, C# and Java are not separate languages - they are all adaptations of C, written with the objective of producing clean, understandable, and reliable structured code.
The problems with using C outlined above are all ascribable to the way the language is being used by programmers - too often, they take the easy way around their own inability to turn out the formal answer.

If you make a top grade kitchen knife, it might end up in the hands of a master chef, or a kid cooking Big Macs, or a murderer. It is still a good knife ,,,

[NickFitz]

What I was saying is that one of the most powerful things that C++ has over C is the ability to create an object on the stack that manages something, be it memory, a file, access to data, whatever, and you know that its destructor will be called and when, because the compiler guarantees it. C#/Java doesn't have that (except for "using" in C# which is similar), and whilst it's okay for GC to take care of memory, you wouldn't want to wait for GC to take care of closing a file that you can't keep open, for example, because you don't know when it will happen.

Maybe it's just me but that seems to conflict with:

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.

In the case you describe you are trusting that the compiler will take care of your problems for you.

What you are really describing is the situation where you want to grab a reference to a resource (as opposed to allocating memory, which is merely a side effect of what you are doing) and be certain that the resource will be released (and, as a side effect, so will the memory) when you implicitly release that resource by ending the code block within which the reference to that resource was in scope. I would argue that relying on some aspect of the language definition to offer a guarantee that this process will automagically happen is trusting that something else will take care of your problems for you. (I am not arguing that this is a bad thing, per se.)

In a managed language like Java or C#, you have to adopt a different style, for they are built on a different paradigm where the memory management aspect of resource acquisition and release is no longer something you should be thinking about. Instead, you should explicitly release resources once you no longer have any need of them; the associated memory allocation and release will happen behind the scenes. This paradigm gives you something extra to think about in the case you describe, but it gives you a lot less to think about in many other common cases. Many people believe the tradeoff to be worthwhile.

I would also suggest that the C++ approach conflates two separate concerns; this may lead to efficient code, but it also tends towards obscurity and diminished maintainability, IMHO.

It seems to me that one of the most common reasons for somebody familiar with one language's way of doing things to decry another language's way of doing things is due to being so bound to the paradigms underpinning the first language that they see the fact that the second language is built on a different set of paradigms as a failure rather than a difference. Sometimes you have to unlearn one way of doing things to get the benefit of a different way of doing things.

One sees this a lot in the criticisms thrown at XSLT. Every moan about XSLT that I've ever seen has been based on one fallacy: that the principles of procedural programming can be applied to declarative programming. They can't.

In the same way, the distinction between the C++ paradigm for resource acquisition and release cannot be said to be better than the managed languages' paradigm. They are different, and what seems better to you only seems so because it is what you are used to. At the end of the day they both get the job done. You are right, and so are they. "Different but equal" as it were

If it's Turing-complete, it's good enough for me

[Platypus]

"C" is fast and tight - perfect for many applications.

Not a good business language.

But excellent for "systems" programming.

It's my first love