Thread: Why C Matters

Originally Posted by Prelude

>I would still like to see C go away. At the very least, C89. Ridiculously unsafe.
If you think C89 is ridiculously unsafe, how would you claim that C99 is any better? I mean, C99 doesn't add any features that make the language significantly safer, so if C89 is "ridiculously" unsafe then C99 must be as well. Then again, I would argue that the language is perfectly safe if you use it intelligently.

Now, I don't know exact details about the C99 standard, but in C89, it's perfectly valid to call a function which hasn't been declared! How safe is that?
Of course, any language is safe is you use it correctly, but how many will use it correctly? We've all seen esbo and his/her/its bad practices. Of course, we can't make esbo avoid bad practices completely, but a safe language would at least make esbo introduce lesser bad practices.

>But the worst of everything is that a lot of newbies are writing C
When I learned C, I was told the same thing that you've been saying: "C is a crusty old language that was replaced by C++; learn C++ because you're not going to be writing code for toasters anytime soon". But I wanted to learn C, and to this day I don't regret it because C gave me a lot of low level understanding that has made me a better programmer all around.

I could argue that you should learn the low-level details anyway, even if it is C++, because it builds upon C.

>so they should be taught C++ instead.
Most newbies won't be doing anything that C++ is best suited for either. They'll end up writing business applications or web applications that would be better implemented in something like Java or VB or PHP. Your argument doesn't match your logic, because if you continue to the logical conclusion, you're extremely unlikely to end up at "so they should be taught C++".

I can't really say I agree with that.
I'm sometimes a typical one language for everything type of someone, so using C++ for typical desktop applications instead of VB is perfectly alright, 100% of the time.
But for web, neither VB nor C++ nor Java might just be the the right approach. Perhaps PHP/Perl is. I've never written an application to be executed on a server, so I don't know...
But anyway, the argument is that if they're going to write applications that can be written with C/C++, they should learn C++, not C. That's what it all comes down to in my arguments.

I have been programming C for about 15 years now. C doesn't have a lot of "protection" for the user. But I don't, even for a second, think that C++ (as a language) is noticeably safer.

Yes, if you use STL, it's got further safety built in to prevent for example out of range array accesses.

--
Mats

Originally Posted by Elysia

Now, I don't know exact details about the C99 standard, but in C89, it's perfectly valid to call a function which hasn't been declared! How safe is that?

valid perhaps, but most compilers bawk at this and refuse to compile.

As for using the STL to prevent out of range array access, no thanks. Sure it might be more painful in the beginning to learn to manage your own memory effectively, but ultimately it gives you more power and flexibility. If you get used to using a crutch, you will always need that crutch.

>but how many will use it correctly?
I suppose that depends on how many teachers follow your advice of not teaching C.

>We've all seen esbo and his/her/its bad practices.
In my experience, psychotic programmers are in the minority. In my years on this and other forums, I can only recall about 5 or 6 out of thousands that were exceptionally insane. And that's taking into account my theory that I release some undiscovered pheromone in mass quantities that attracts nutters.

>I could argue that you should learn the low-level details
>anyway, even if it is C++, because it builds upon C.
I could retort that the C++ mindset (correctly) tries to abstract away those low level details. If you learn C++ correctly, they'll be a quaint and amusing thought experiment until you get to the point where you need to learn them for practical purposes. C, on the other hand, forces you to learn low level details because the language won't work for you otherwise.

>so using C++ for typical desktop applications instead
>of VB is perfectly alright, 100% of the time.
Well, if you're advocating using a language less suitable than another for the task at hand, why not C? Hell, why not assembly for that matter? It seems like you're saying that C++ is more suitable than C, then you go and suggest that suitability doesn't matter in choosing a language.

>if they're going to write applications that can be
>written with C/C++, they should learn C++, not C.
Why? Wait, let me answer that one for you:

[impression=Elysia]
Why not? C++ is built on C. Everything you can do with C can be done with C++. There's no reason to use C when C++ is everything C is and more.
[/impression]

Here's why not. C++ is a beast of a language. Typically when you give someone a lot of tools, they'll be tempted to use them all for some irrational fear of not using them to their fullest. The result is often disgusting and overcomplicated inheritance hierarchies, templates that not even the author can understand after ten minutes, and a messy tangle of unnecessary clutter.

Now let's look at C for a moment. If you have to implement such things before being able to use them, you'll be much more judicious in deploying your tools. I think a smaller language promotes better design because rather than throwing components at your problem, you actually end up thinking about the problem and applying just as much as necessary to solve it.

Even if you don't actually use C, learning it will give you insight into properly using the tools that a bigger language provides.

Originally Posted by abachler

valid perhaps, but most compilers bawk at this and refuse to compile.

Visual Studio will just give a warning and AFAIK, so will just Dev-C++/g++.

As for using the STL to prevent out of range array access, no thanks. Sure it might be more painful in the beginning to learn to manage your own memory effectively, but ultimately it gives you more power and flexibility. If you get used to using a crutch, you will always need that crutch.

Indeed. Good thing you have a choice then, isn't it? Out-of-bounds checking might be good for debug builds too.

Originally Posted by Prelude

>but how many will use it correctly?
I suppose that depends on how many teachers follow your advice of not teaching C.

Oh yeah, there's also the argument of all those bad teachers out there. The safer the language, the less a mess those poor teachers can do! Because we can never get rid of poor teachers...

>We've all seen esbo and his/her/its bad practices.
In my experience, psychotic programmers are in the minority. In my years on this and other forums, I can only recall about 5 or 6 out of thousands that were exceptionally insane. And that's taking into account my theory that I release some undiscovered pheromone in mass quantities that attracts nutters.

Well, the argument was that it restricts "psychotic" and other programmers who never was taught the right way or didn't understand the ability to less unsafe mistakes.

>I could argue that you should learn the low-level details
>anyway, even if it is C++, because it builds upon C.
I could retort that the C++ mindset (correctly) tries to abstract away those low level details. If you learn C++ correctly, they'll be a quaint and amusing thought experiment until you get to the point where you need to learn them for practical purposes. C, on the other hand, forces you to learn low level details because the language won't work for you otherwise.

However, even if this is true, it comes a time in any C++ developer's time when he or she must be forced to use more low-level approaches. And, of course, it all depends on what kind of applications you want to create. Emulators are very complex beasts that require very intimate low-level knowledge.
It is a good thing that these libraries exist because they can take away complexity and work for you, the programmer, to make safer applications and make them faster. It takes away the error-prone matters of mistakes and debugging time to use higher level interfaces which are tested and tried. You don't have to think about the lower level things. It makes life easier, so to speak, when you don't need the lower level. If you need the lower level, you don't need to use the higher interface, so it's the best of both worlds!

>so using C++ for typical desktop applications instead
>of VB is perfectly alright, 100% of the time.
Well, if you're advocating using a language less suitable than another for the task at hand, why not C? Hell, why not assembly for that matter? It seems like you're saying that C++ is more suitable than C, then you go and suggest that suitability doesn't matter in choosing a language.

But the thing is that C++ is C! So if you use C++, you can write C and C++! So there's no need for two languages - there's just the need for one.

>if they're going to write applications that can be
>written with C/C++, they should learn C++, not C.
Why? Wait, let me answer that one for you:

[impression=Elysia]
Why not? C++ is built on C. Everything you can do with C can be done with C++. There's no reason to use C when C++ is everything C is and more.
[/impression]

Here's why not. C++ is a beast of a language. Typically when you give someone a lot of tools, they'll be tempted to use them all for some irrational fear of not using them to their fullest. The result is often disgusting and overcomplicated inheritance hierarchies, templates that not even the author can understand after ten minutes, and a messy tangle of unnecessary clutter.

Now let's look at C for a moment. If you have to implement such things before being able to use them, you'll be much more judicious in deploying your tools. I think a smaller language promotes better design because rather than throwing components at your problem, you actually end up thinking about the problem and applying just as much as necessary to solve it.

Even if you don't actually use C, learning it will give you insight into properly using the tools that a bigger language provides.

Now this may be a problem for any tool. They may contain a lot of functionality, which btw, is there for a purpose - to make life easier for those who know how to use it, but no one says you are forced to use everything.
I think this comes down to education. But there's a problem here. C is obviously a lot harder with all the low-level stuff than C++, so one could argue that you should learn C++ rather than C. Yet C++ is bigger and has more functionality and is thus more complex, but easier to use.
Either way I see it, there's a problem. So the advice would be, take is slow, learn it properly and don't use functionality you have no idea how to use. When used right, the right tool will simplify the job and not the other way around. We just need to ensure we teach how to use the tools properly.
That's how I see it.

Interestingly, I still cannot access the website linked to in the first post. With ping, I get:
"Ping request could not find host http://www.stsc.hill.af.mil. Please check the name and try again."

What were the arguments it put forward?

The full article was as follows:

Computer Science Education: Where Are the Software Engineers of Tomorrow?
Dr. Robert B.K. Dewar, AdaCore Inc.
Dr. Edmond Schonberg, AdaCore Inc.

It is our view that Computer Science (CS) education is neglecting basic skills, in particular in the areas of programming and formal methods. We consider that the general adoption of Java as a first programming language is in part responsible for this decline. We examine briefly the set of programming skills that should be part of every software professional’s repertoire.

It is all about programming! Over the last few years we have noticed worrisome trends in CS education. The following represents a summary of those trends:

1. Mathematics requirements in CS programs are shrinking.
2. The development of programming skills in several languages is giving way to cookbook approaches using large libraries and special-purpose packages.
3. The resulting set of skills is insufficient for today’s software industry (in particular for safety and security purposes) and, unfortunately, matches well what the outsourcing industry can offer. We are training easily replaceable professionals.

These trends are visible in the latest curriculum recommendations from the Association for Computing Machinery (ACM). Curriculum 2005 does not mention mathematical prerequisites at all, and it mentions only one course in the theory of programming languages [1].

We have seen these developments from both sides: As faculty members at New York University for decades, we have regretted the introduction of Java as a first language of instruction for most computer science majors. We have seen how this choice has weakened the formation of our students, as reflected in their performance in systems and architecture courses. As founders of a company that specializes in Ada programming tools for mission-critical systems, we find it harder to recruit qualified applicants who have the right foundational skills. We want to advocate a more rigorous formation, in which formal methods are introduced early on, and programming languages play a central role in CS education.

Formal Methods and Software Construction

Formal techniques for proving the correctness of programs were an extremely active subject of research 20 years ago. However, the methods (and the hardware) of the time prevented these techniques from becoming widespread, and as a result they are more or less ignored by most CS programs. This is unfortunate because the techniques have evolved to the point that they can be used in large-scale systems and can contribute substantially to the reliability of these systems. A case in point is the use of SPARK in the re-engineering of the ground-based air traffic control system in the United Kingdom (see a description of iFACTS – Interim Future Area Control Tools Support, at <www.nats.co.uk/article/90>). SPARK is a subset of Ada augmented with assertions that allow the designer to prove important properties of a program: termination, absence of run-time exceptions, finite memory usage, etc. [2]. It is obvious that this kind of design and analysis methodology (dubbed Correctness by Construction) will add substantially to the reliability of a system whose design has involved SPARK from the beginning. However, PRAXIS, the company that developed SPARK and which is designing iFACTS, finds it hard to recruit people with the required mathematical competence (and this is present even in the United Kingdom, where formal methods are more widely taught and used than in the United States).

Another formal approach to which CS students need exposure is model checking and linear temporal logic for the design of concurrent systems. For a modern discussion of the topic, which is central to mission-critical software, see [3].

Another area of computer science which we find neglected is the study of floating-point computations. At New York University, a course in numerical methods and floating-point computing used to be required, but this requirement was dropped many years ago, and now very few students take this course. The topic is vital to all scientific and engineering software and is semantically delicate. One would imagine that it would be a required part of all courses in scientific computing, but these often take MatLab to be the universal programming tool and ignore the topic altogether.

The Pitfalls of Java as a First Programming Language

Because of its popularity in the context of Web applications and the ease with which beginners can produce graphical programs, Java has become the most widely used language in introductory programming courses. We consider this to be a misguided attempt to make programming more fun, perhaps in reaction to the drop in CS enrollments that followed the dot-com bust. What we observed at New York University is that the Java programming courses did not prepare our students for the first course in systems, much less for more advanced ones. Students found it hard to write programs that did not have a graphic interface, had no feeling for the relationship between the source program and what the hardware would actually do, and (most damaging) did not understand the semantics of pointers at all, which made the use of C in systems programming very challenging.

Let us propose the following principle: The irresistible beauty of programming consists in the reduction of complex formal processes to a very small set of primitive operations. Java, instead of exposing this beauty, encourages the programmer to approach problem-solving like a plumber in a hardware store: by rummaging through a multitude of drawers (i.e. packages) we will end up finding some gadget (i.e. class) that does roughly what we want. How it does it is not interesting! The result is a student who knows how to put a simple program together, but does not know how to program. A further pitfall of the early use of Java libraries and frameworks is that it is impossible for the student to develop a sense of the run-time cost of what is written because it is extremely hard to know what any method call will eventually execute. A lucid analysis of the problem is presented in [4].

We are seeing some backlash to this approach. For example, Bjarne Stroustrup reports from Texas A & M University that the industry is showing increasing unhappiness with the results of this approach. Specifically, he notes the following:

I have had a lot of complaints about that [the use of Java as a first programming language] from industry, specifically from AT&T, IBM, Intel, Bloomberg, NI, Microsoft, Lockheed-Martin, and more. [5]

He noted in a private discussion on this topic, reporting the following:

It [Texas A&M] did [teach Java as the first language]. Then I started teaching C++ to the electrical engineers and when the EE students started to out-program the CS students, the CS department switched to C++. [5]

It will be interesting to see how many departments follow this trend. At AdaCore, we are certainly aware of many universities that have adopted Ada as a first language because of similar concerns.

A Real Programmer Can Write in Any Language (C, Java, Lisp, Ada)

Software professionals of a certain age will remember the slogan of old-timers from two generations ago when structured programming became the rage: Real programmers can write Fortran in any language. The slogan is a reminder of how thinking habits of programmers are influenced by the first language they learn and how hard it is to shake these habits if you do all your programming in a single language. Conversely, we want to say that a competent programmer is comfortable with a number of different languages and that the programmer must be able to use the mental tools favored by one of them, even when programming in another. For example, the user of an imperative language such as Ada or C++ must be able to write in a functional style, acquired through practice with Lisp and ML1, when manipulating recursive structures. This is one indication of the importance of learning in-depth a number of different programming languages. What follows summarizes what we think are the critical contributions that well-established languages make to the mental tool-set of real programmers. For example, a real programmer should be able to program inheritance and dynamic dispatching in C, information hiding in Lisp, tree manipulation libraries in Ada, and garbage collection in anything but Java. The study of a wide variety of languages is, thus, indispensable to the well-rounded programmer.
Why C Matters

C is the low-level language that everyone must know. It can be seen as a portable assembly language, and as such it exposes the underlying machine and forces the student to understand clearly the relationship between software and hardware. Performance analysis is more straightforward, because the cost of every software statement is clear. Finally, compilers (GCC for example) make it easy to examine the generated assembly code, which is an excellent tool for understanding machine language and architecture.
Why C++ Matters

C++ brings to C the fundamental concepts of modern software engineering: encapsulation with classes and namespaces, information hiding through protected and private data and operations, programming by extension through virtual methods and derived classes, etc. C++ also pushes storage management as far as it can go without full-blown garbage collection, with constructors and destructors.
Why Lisp Matters

Every programmer must be comfortable with functional programming and with the important notion of referential transparency. Even though most programmers find imperative programming more intuitive, they must recognize that in many contexts that a functional, stateless style is clear, natural, easy to understand, and efficient to boot.

An additional benefit of the practice of Lisp is that the program is written in what amounts to abstract syntax, namely the internal representation that most compilers use between parsing and code generation. Knowing Lisp is thus an excellent preparation for any software work that involves language processing.

Finally, Lisp (at least in its lean Scheme incarnation) is amenable to a very compact self-definition. Seeing a complete Lisp interpreter written in Lisp is an intellectual revelation that all computer scientists should experience.
Why Java Matters

Despite our comments on Java as a first or only language, we think that Java has an important role to play in CS instruction. We will mention only two aspects of the language that must be part of the real programmer’s skill set:

1. An understanding of concurrent programming (for which threads provide a basic low-level model).
2. Reflection, namely the understanding that a program can be instrumented to examine its own state and to determine its own behavior in a dynamically changing environment.

Why Ada Matters

Ada is the language of software engineering par excellence. Even when it is not the language of instruction in programming courses, it is the language chosen to teach courses in software engineering. This is because the notions of strong typing, encapsulation, information hiding, concurrency, generic programming, inheritance, and so on, are embodied in specific features of the language. From our experience and that of our customers, we can say that a real programmer writes Ada in any language. For example, an Ada programmer accustomed to Ada’s package model, which strongly separates specification from implementation, will tend to write C in a style where well-commented header files act in somewhat the same way as package specs in Ada. The programmer will include bounds checking and consistency checks when passing mutable structures between subprograms to mimic the strong-typing checks that Ada mandates [6]. She will organize concurrent programs into tasks and protected objects, with well-defined synchronization and communication mechanisms.

The concurrency features of Ada are particularly important in our age of multi-core architectures. We find it surprising that these architectures should be presented as a novel challenge to software design when Ada had well-designed mechanisms for writing safe, concurrent software 30 years ago.
Programming Languages Are Not the Whole Story

A well-rounded CS curriculum will include an advanced course in programming languages that covers a wide variety of languages, chosen to broaden the understanding of the programming process, rather than to build a résumé in perceived hot languages. We are somewhat dismayed to see the popularity of scripting languages in introductory programming courses. Such languages (Javascript, PHP, Atlas) are indeed popular tools of today for Web applications. Such languages have all the pedagogical defaults that we ascribe to Java and provide no opportunity to learn algorithms and performance analysis. Their absence of strong typing leads to a trial-and-error programming style and prevents students from acquiring the discipline of separating design of interfaces from specifications.

However, teaching the right languages alone is not enough. Students need to be exposed to the tools to construct large-scale reliable programs, as we discussed at the start of this article. Topics of relevance are studying formal specification methods and formal proof methodologies, as well as gaining an understanding of how high-reliability code is certified in the real world. When you step into a plane, you are putting your life in the hands of software which had better be totally reliable. As a computer scientist, you should have some knowledge of how this level of reliability is achieved. In this day and age, the fear of terrorist cyber attacks have given a new urgency to the building of software that is not only bug free, but is also immune from malicious attack. Such high-security software relies even more extensively on formal methodologies, and our students need to be prepared for this new world.

>Thats more the fanatic OOP mindset.
No, that's a basic guideline for writing good programs. Abstract away what you can into classes, or functions, or modules, or whatever the language provides for abstraction so you don't have to worry about it. It's not a guideline specific to OOP, OOP simply encourages an existing good practice. Structured programming does the same thing, for example.

>Well, the argument was that it restricts "psychotic" and other programmers
>who never was taught the right way or didn't understand the ability to less unsafe mistakes.
Bad programmers will do stupid things regardless of the safety of a language. And of course, if your language is safe enough to stop bad programmers from doing stupid things, it's also safe enough to be damn near useless for everyone else.

>If you need the lower level, you don't need to use the higher interface, so it's the best of both worlds!
Ah, but the question isn't about using C, it's about why one should learn C. The best of both worlds is pointless if you learn the lessons of one, but ignore the valuable lessons of the other for however many years it takes to need it in practice.

>So there's no need for two languages - there's just the need for one.
You didn't answer my question, so I'll rephrase it to take away your loophole. If C++ instead of VB is perfectly alright 100% of the time, is assembly instead of C++ perfectly alright 100% of the time?

If your answer is yes, then C instead of C++ is also perfectly alright 100% of the time because the question of suitability is moot. It doesn't matter if C++ is C.

If your answer is no, then you're saying VB is more suitable than assembly. Since VB may also be more suitable than C++, your statement is inaccurate, and thus can't be used for logically advocating C++.

>We just need to ensure we teach how to use the tools properly.
So why are you suggesting we stop teaching C again? Wouldn't it be better to teach C properly so that students are in a better position to choose C++ based on education rather than some guy's opinion on what they should learn and use?

The safer the language, the less a mess those poor teachers can do! Because we can never get rid of poor teachers...

But the thing is that C++ is C! So if you use C++, you can write C and C++!

By such reasoning, in the hands of poor teachers, the teaching of C++ is as problematic as the teaching of C. Teachers could well use the C subset of C++ for teaching, as they did when they taught me C++.

So there's no need for two languages - there's just the need for one.

The article's reason for saying that C matters is that "C ... can be seen as a portable assembly language". From their pedagogical perspective, this is useful because it helps students learn programming at a low-level and "forces the student to understand clearly the relationship between software and hardware".

But from an engineering perspective, this is useful because it means that engineers can use a higher level language for their low-level stuff, and the code has a better chance at being portable. Along these lines, C compilers are easier to implement than C++ compilers, so if more complex C++ features will not be used, it may well make sense to just implement a C compiler and program in C.

Of course, one could write a C++ compiler that implements the necessary subset of C++. If the evolution of C++ had been such that all the multi-paradigm aspects of C++ had evolved collectively and the subset we call C was regarded as just one C++ paradigm commonly used for say, embedded programming (but see the article in PDF format: Why Are You Still Using C?), then C and C++ would indeed be a single language. Unfortunately, history did not turn out that way, so instead of deciding what C++ features to include, such a compiler author may find it easier to just implement a C compiler. Coupled with the large amount of existing C code, eradicating C is not feasible.

Originally Posted by Prelude

>Well, the argument was that it restricts "psychotic" and other programmers
>who never was taught the right way or didn't understand the ability to less unsafe mistakes.
Bad programmers will do stupid things regardless of the safety of a language. And of course, if your language is safe enough to stop bad programmers from doing stupid things, it's also safe enough to be damn near useless for everyone else.

Oh, they will. But if the language is safe, they will make less mistakes.

>If you need the lower level, you don't need to use the higher interface, so it's the best of both worlds!
Ah, but the question isn't about using C, it's about why one should learn C. The best of both worlds is pointless if you learn the lessons of one, but ignore the valuable lessons of the other for however many years it takes to need it in practice.

But then again, who says that when you learn C++, you don't learn the low level? C++ can do both, so you should learn both. At least, that is, if you need to use low-level, typical C stuff, then you should learn low-level C++ stuff.

>So there's no need for two languages - there's just the need for one.
You didn't answer my question, so I'll rephrase it to take away your loophole. If C++ instead of VB is perfectly alright 100&#37; of the time, is assembly instead of C++ perfectly alright 100% of the time?

Well, it would work, because assembly isn't C or C++, but it would be damned difficult and a lot of resources to do less work.

If your answer is yes, then C instead of C++ is also perfectly alright 100% of the time because the question of suitability is moot. It doesn't matter if C++ is C.

If you wish to rephrase C as C++ C, then yes! It's a matter of style, but I would definitely not recommend it since it's more work for the same thing that takes less time in C++. And it's not as safe as C++ either (and security is such a problem these days...).

If your answer is no, then you're saying VB is more suitable than assembly. Since VB may also be more suitable than C++, your statement is inaccurate, and thus can't be used for logically advocating C++.

VB is a child's tool in my eyes

>We just need to ensure we teach how to use the tools properly.
So why are you suggesting we stop teaching C again? Wouldn't it be better to teach C properly so that students are in a better position to choose C++ based on education rather than some guy's opinion on what they should learn and use?

Because C++ can do everything C can and is typically a more safe language to boot.
Going to write low-level stuff? C++ can do that for you, catch your bad casts, catch your bad programming practices such as not returning a type or not returning anything from a function, etc.
Doing typical desktop applications? Good for you! You can have the full functionality of C++ available to you without the change of a language or compiler.

Of course, we'll have to teach C++ properly too.
I seems there are also advantages to a single language rather than two, as well: you don't need to be confused on what language to choose, for example. But another important thing is that backwards compability can be deprecated and the standards won't interefere with each other (as I seemingly learned thread support was dropped to be added at a later date due to compability concerns with C).
This doesn't mean that low-level ability should be removed, but backwards compability stuff to make C code compile with C++ should be removed.
Like a string literal must be const char* instead of char*:

Code:

char* my_str = "My string";

And many other things that are kept purely to make C++ compatible with C. What exactly everything that is, I don't know, but the point stands.

Originally Posted by laserlight

By such reasoning, in the hands of poor teachers, the teaching of C++ is as problematic as the teaching of C. Teachers could well use the C subset of C++ for teaching, as they did when they taught me C++.

Well, I'll agree it's a problem. Typically we must separate C++ into two parts: High level and low level and classes should teach as such.

The article's reason for saying that C matters is that "C ... can be seen as a portable assembly language". From their pedagogical perspective, this is useful because it helps students learn programming at a low-level and "forces the student to understand clearly the relationship between software and hardware".

To follow up on the above, we must separate low and high level parts of C++ and teach the appropriate depending on what you need to do. There's no reason why you can't/shouldn't learn the low level C++ stuff just because you're using C++ instead of C.

But from an engineering perspective, this is useful because it means that engineers can use a higher level language for their low-level stuff, and the code has a better chance at being portable. Along these lines, C compilers are easier to implement than C++ compilers, so if more complex C++ features will not be used, it may well make sense to just implement a C compiler and program in C.

That just sounds to me like: "Hey, let's implement DivX (H263/MPEG4 ASP) instead of H264/MPEG4 AVC, just because it's easier!"
You're restricting the programmer to what he or she can do when writing code to a specific system and I find that just stupid. If C++ is better to write code with, and can do memory-efficient, fast code, then why are we stuck with plain old C!?
So if a C++ feature isn't supported, then restrict its use in the compiler or just make sure it works!

Of course, one could write a C++ compiler that implements the necessary subset of C++. If the evolution of C++ had been such that all the multi-paradigm aspects of C++ had evolved collectively and the subset we call C was regarded as just one C++ paradigm commonly used for say, embedded programming (but see the article in PDF format: Why Are You Still Using C?), then C and C++ would indeed be a single language. Unfortunately, history did not turn out that way, so instead of deciding what C++ features to include, such a compiler author may find it easier to just implement a C compiler. Coupled with the large amount of existing C code, eradicating C is not feasible.

Yes, unfortunately, C seems to remain separate.
However, it needs not be so and the damage can be repaired.
What you would do is deprecate C. No more updates to the standard, and encourage people to use C++ and universities to teach C++ and eventually, one day, C will go away.

>But if the language is safe, they will make less mistakes.
The problem with mistakes, is that it only takes one to royally screw a program.

>At least, that is, if you need to use low-level, typical C
>stuff, then you should learn low-level C++ stuff.
My point was that C forces you to learn the low level stuff that makes you a better programmer across the board, even if you don't actually use it. If you make that stuff optional, those who aren't going to use the low level stuff lose the benefit unless for some reason they decide to learn it anyway. The average programmer doesn't learn unnecessary things.

>VB is a child's tool in my eyes
Okay then.

>Because C++ can do everything C can and is typically a more safe language to boot.
But C isn't going anywhere. You can close your eyes, stick your fingers in your ears and yell "LALALALALA!", but that's not going to make C go away. You can try to phase out C, but that's only going to hurt the quality of C code for however many decades it takes people to stop using and maintaining C.

Originally Posted by Prelude

>But if the language is safe, they will make less mistakes.
The problem with mistakes, is that it only takes one to royally screw a program.

Then maybe we should start using languages that have no type-safety whatsoever, perhaps?

>At least, that is, if you need to use low-level, typical C
>stuff, then you should learn low-level C++ stuff.
My point was that C forces you to learn the low level stuff that makes you a better programmer across the board, even if you don't actually use it. If you make that stuff optional, those who aren't going to use the low level stuff lose the benefit unless for some reason they decide to learn it anyway. The average programmer doesn't learn unnecessary things.

So just toss in low-level C++ & high-level C++ in one package then. I don't see why that wouldn't be the same thing.
I do understand that just learning C++ won't necessarily teach you low-level C++, but that's something we'll have to live with, I guess. We have to sacrifice something for a better goal.
Otherwise we would be in the DOS era still and optimize like no tomorrow to fit everything inside a program and to fit everything inside the memory limits.

You can try to phase out C, but that's only going to hurt the quality of C code for however many decades it takes people to stop using and maintaining C.

It's time to move on and stop using the past! A lot of C code can be converted into C++ code with little effort. At when if you compare migrating between C/C++ and VB/Java/whatever other language you want to compare.