Why C Matters

This is a discussion on Why C Matters within the A Brief History of Cprogramming.com forums, part of the Community Boards category; Originally Posted by Prelude >I would still like to see C go away. At the very least, C89. Ridiculously unsafe. ...

  1. #61
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,663
    Quote Originally Posted by Prelude View Post
    >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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  2. #62
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  3. #63
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    Quote Originally Posted by Elysia View Post
    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.
    Last edited by abachler; 01-11-2008 at 08:13 AM.
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

  4. #64
    Code Goddess Prelude's Avatar
    Join Date
    Sep 2001
    Posts
    9,796
    >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.
    My best code is written with the delete key.

  5. #65
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    I could retort that the C++ mindset (correctly) tries to abstract away those low level details.
    Thats more the fanatic OOP mindset. They want to make everything a class. Instructors don't help when they give ........ poor analogies like 'it treats data like objects which is how humans think'. If they woudl explain it for what it is, rather than try to make it seems like a trivial notion to learn, I think it would make for better programmers.
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

  6. #66
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,663
    Quote Originally Posted by abachler View Post
    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.

    Quote Originally Posted by Prelude View Post
    >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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  7. #67
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,794
    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?
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  8. #68
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,663
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  9. #69
    Code Goddess Prelude's Avatar
    Join Date
    Sep 2001
    Posts
    9,796
    >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?
    My best code is written with the delete key.

  10. #70
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    Quote Originally Posted by Prelude View Post
    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?
    rather than teach C or C++ we should teach C/C++ as a single entity, rather than artificially seperate the two. Personally, most of my code is C written in C++ style, i.e. using typecasting etc. I find it useful to know what wont work in pure C only because as an EE I actually program thingslike PLC's that only have C compilers, but I dont find it particularly useful to restrict myself to either dialect in computer based applications. I will often drift from one to the other even within the same function, whatever is appropriate.

    I think they should teach strong typecasting in C courses, as it is good programming style, even though C doesnt require it. It also makes porting from C to C++ easier.
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

  11. #71
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,794
    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.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  12. #72
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,714
    > rather than teach C or C++ we should teach C/C++ as a single entity, rather than
    >artificially seperate the two.

    I think most of us will agree that C and C++ have similarities but there is no hinderance to discovering this on your own. We should consider the consequences in your rather narrow educational approach (that is geared toward a cog of the industry).

    >I think they should teach strong typecasting in C courses, as it is good programming style,
    > even though C doesnt require it. It also makes porting from C to C++ easier.

    A great example is mentioned here when students learn to reach for archaic tools that have been rebuilt to be more expressive, and not understand the difference between the new and the old.

  13. #73
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,663
    Quote Originally Posted by Prelude View Post
    >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.

    Quote Originally Posted by laserlight View Post
    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.
    Last edited by Elysia; 01-11-2008 at 09:56 AM.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  14. #74
    Code Goddess Prelude's Avatar
    Join Date
    Sep 2001
    Posts
    9,796
    >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.
    My best code is written with the delete key.

  15. #75
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,663
    Quote Originally Posted by Prelude View Post
    >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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Speed of C++
    By bobthebullet990 in forum A Brief History of Cprogramming.com
    Replies: 64
    Last Post: 01-12-2007, 01:39 AM
  2. Replies: 2
    Last Post: 09-28-2006, 01:06 PM
  3. C++ tests.
    By VirtualAce in forum A Brief History of Cprogramming.com
    Replies: 38
    Last Post: 06-30-2006, 06:51 AM
  4. Confuted/Blackrat: quaternion question
    By Silvercord in forum Game Programming
    Replies: 12
    Last Post: 08-18-2003, 06:02 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21