Learning C

  • I think Steve should have added, "If you have ever programed in Assembler, of any kind, you know what you are doing and are except".

    As someone who started with BBC BASIC, and migrated via Pascal to Visual Basic, and now several other languages, I can honestly say that the best short course I have ever done was a 12 week course in C/C++ about 10 years ago, not because it is a great language but because it doesn't have the layers of obfuscation that other languages have. I finally understood why VB and VBScript needed the Set keyword to assign objects to a variable, while before it all seemed rather arbitrary. I wince now when I read books on .NET languages that try to explain Pointers, without using the term Pointer.

    I wouldn't recommend C as a starting language, but once you can program it is always good to learn what your compiler is doing behind the scenes, or to continue someone else's analogy, once you can drive learn how a car really works.

  • Alex Gay (8/16/2012)


    I wouldn't recommend C as a starting language, but once you can program it is always good to learn what your compiler is doing behind the scenes, or to continue someone else's analogy, once you can drive learn how a car really works.

    The worst software designs I have ever seen (and still see) are created by VB programmers. Now in recent years M$ has added object oriented capabilities to the VB language and constructs that allow for strong type consistency, but the problem is the legacy of programs and the programmers who conceived them from a language where everything is an object and you can add apples to oranges without a complaint from the compiler (or in the case of VBscript, the interpreter).

    If you learn to think in clean object oriented mentality (which is C# & C++) you are well on your way to thinking outside the box and applying this thinking to the very design itself, not just the classes and methods that you write to implement it.

    The probability of survival is inversely proportional to the angle of arrival.

  • I like this idea. Before I even started down an IT path and degree, I taught myself what I could about C to see if I would really enjoy programming or not (although I did learn BASIC on an Apple II when I was 14 but that doesn't count). I think having started out on a functional language has helped me be a more concise/efficient programmer.

    Does it have to be C? Probably not, but nothing make me roll my eyes faster then when I start reading all these comments about "Oh this language is better than that language" and I start having flashbacks to kindergarten. The fact is, a language is a tool and if you think one of the major languages is inferior to another it perhaps may be in a particular problem space like when using a screwdriver on a nail, but 9 times out 10 the 'deficiencies' can be lain at the feet of the programmer.

  • Eric M Russell (8/15/2012)


    If you teach them C, they'll spend weeks learning how print "Hello World" on a console, will never use it, and will forget everything three months.

    Ah, you are referring to the people that are usually the ones that get promoted to chief architect. 😛

    The probability of survival is inversely proportional to the angle of arrival.

  • sturner (8/16/2012)


    Alex Gay (8/16/2012)


    I wouldn't recommend C as a starting language, but once you can program it is always good to learn what your compiler is doing behind the scenes, or to continue someone else's analogy, once you can drive learn how a car really works.

    The worst software designs I have ever seen (and still see) are created by VB programmers. Now in recent years M$ has added object oriented capabilities to the VB language and constructs that allow for strong type consistency, but the problem is the legacy of programs and the programmers who conceived them from a language where everything is an object and you can add apples to oranges without a complaint from the compiler (or in the case of VBscript, the interpreter).

    If you learn to think in clean object oriented mentality (which is C# & C++) you are well on your way to thinking outside the box and applying this thinking to the very design itself, not just the classes and methods that you write to implement it.

    Seems to me you are blaming the language (VB) for the lack of skill on the part of the programmer. The problem isn't the language, it is the person and the lack of formal training and/or mentoring. Yes, the language made it easier to write poorly designed software but it still isn't the fault of the language.

  • sturner (8/16/2012)


    Alex Gay (8/16/2012)


    I wouldn't recommend C as a starting language, but once you can program it is always good to learn what your compiler is doing behind the scenes, or to continue someone else's analogy, once you can drive learn how a car really works.

    The worst software designs I have ever seen (and still see) are created by VB programmers. Now in recent years M$ has added object oriented capabilities to the VB language and constructs that allow for strong type consistency, but the problem is the legacy of programs and the programmers who conceived them from a language where everything is an object and you can add apples to oranges without a complaint from the compiler (or in the case of VBscript, the interpreter).

    If you learn to think in clean object oriented mentality (which is C# & C++) you are well on your way to thinking outside the box and applying this thinking to the very design itself, not just the classes and methods that you write to implement it.

    But we aren't talking about C# or C++, we're talking about C, which is NOT an object oriented language. VB.Net *is*, however, just like C#.

    Much of my objection to C comes from the sheer grunt work of memory management. C is notorious for memory leaks and buffer overflows. While VB dialects before VB.Net had other issues (some quite bad, agreed) memory leaks and buffer overflows weren't part of them.

    My other objection to c-family languages is simpy the syntax, the actual notation used to write the language. Basic-family languages (including FORTRAN and Pascal) tend to be easier to read and scan, without a lot of syntax-sugar that's easier for compilers but harder on the eye. I also object to arbitrary use of white space, which both c-family and SQL-family languages abuse horribly.

    As for software design 🙂 that's entirely up to the programmer. Good habits are good habits, regardless of language. However I would point out there's a *reason* c-family languages are used for obfuscation contests. (chuckle).

  • roger.plowman (8/16/2012)


    Much of my objection to C comes from the sheer grunt work of memory management. C is notorious for memory leaks and buffer overflows. While VB dialects before VB.Net had other issues (some quite bad, agreed) memory leaks and buffer overflows weren't part of them.

    C has always been a language requiring more discipline than a lot of VB programmers have patience for: declaring variables for type consistency and data integrity, properly managing use of all system resources (not just memory). Take COM for example: so deceptively easy to build the objects in VB and thus lose sight of the heavy performance penalty paid in marshalling data across the interface. C & C++ programmers undertand this from the get go and would avoid this mechanism wherever possible because they would have had to build them from the inside out. I can't tell you how many performance and scalability issues I have dealt with over the years because of COM and DCOM. Thankfully it is slowly fading away.

    SQL server is written in C & C++ as is windows and UNIX and Linux. Those having the competency and discipline to program in C and C++ have the capability to develop very powerful applications that are capable of getting very close to the OS for performance reasons. Its not for everybody, as you state, and for those folks they should stick with VB and VBA.

    The probability of survival is inversely proportional to the angle of arrival.

  • sturner (8/16/2012)


    roger.plowman (8/16/2012)


    Much of my objection to C comes from the sheer grunt work of memory management. C is notorious for memory leaks and buffer overflows. While VB dialects before VB.Net had other issues (some quite bad, agreed) memory leaks and buffer overflows weren't part of them.

    C has always been a language requiring more discipline than a lot of VB programmers have patience for: declaring variables for type consistency and data integrity, properly managing use of all system resources (not just memory). Take COM for example: so deceptively easy to build the objects in VB and thus lose sight of the heavy performance penalty paid in marshalling data across the interface. C & C++ programmers undertand this from the get go and would avoid this mechanism wherever possible because they would have had to build them from the inside out. I can't tell you how many performance and scalability issues I have dealt with over the years because of COM and DCOM. Thankfully it is slowly fading away.

    SQL server is written in C & C++ as is windows and UNIX and Linux. Those having the competency and discipline to program in C and C++ have the capability to develop very powerful applications that are capable of getting very close to the OS for performance reasons. Its not for everybody, as you state, and for those folks they should stick with VB and VBA.

    I have to disagree with you. First, C & C++ programmers don't know things from the get go, they had to learn about the penalties for using things like COM and DCOM just like anyone else. This learning could be from college course work, OJT, or mentoring from other more experienced developers. Many VB programmers learned what they know on there own with little mentoring or formal training.

    Discipline in writing good code doesn't come from the language, it comes from having the proper training and mentoring. I am sure that there are C & C++ programmers that are just as inefficient as the VB programmers you disparage as I am sure that there are VB programmers out there that can write better code than many C & C++ programmers.

    Bottom line, it isn't the language that makes the programmer.

  • Lynn Pettis (8/16/2012)


    I have to disagree with you. First, C & C++ programmers don't know things from the get go, they had to learn about the penalties for using things like COM and DCOM just like anyone else. This learning could be from college course work, OJT, or mentoring from other more experienced developers. Many VB programmers learned what they know on there own with little mentoring or formal training.

    No they don't... or didn't (have to learn about COM and DCOM) because all they needed to do to create and use these things was basically click a button in VS. You don't learn anything significant from dragging and dropping things then hitting the "compile" button. You couldn't really get away with that using C or C++ (though you basically can now with C#).

    The point that I'm trying to make is that providing too simplistic an interface, or a eliminating the requirement for higher levels of skill to start building and using complex software and database designs have often led to very poor and non-scalable systems, this includes database designs as well. I know because I've had to fix enough of them.

    The probability of survival is inversely proportional to the angle of arrival.

  • sturner (8/16/2012)


    Lynn Pettis (8/16/2012)


    I have to disagree with you. First, C & C++ programmers don't know things from the get go, they had to learn about the penalties for using things like COM and DCOM just like anyone else. This learning could be from college course work, OJT, or mentoring from other more experienced developers. Many VB programmers learned what they know on there own with little mentoring or formal training.

    No they don't... or didn't (have to learn about COM and DCOM) because all they needed to do to create and use these things was basically click a button in VS. You don't learn anything significant from dragging and dropping things then hitting the "compile" button. You couldn't really get away with that using C or C++ (though you basically can now with C#).

    You are still blaming the language. It is the person. Yes, in VB you can do things without knowing what they are doing behind the scenes. Unfortunately, not everyone works that way. there are programmers (developers) out there that have never touched C or C++ who actually do understand what is happening behind the scenes because 1) they researched it and learned about what was happening, 2) were mentored by someone who understood these things and based on this knowledge.

    And yes, you can do that now in VS in ANY .net language, but it isn't the language or the tool that should take the blame for poorly designed or implemented code.

  • Lynn Pettis (8/16/2012)And yes, you can do that now in VS in ANY .net language, but it isn't the language or the tool that should take the blame for poorly designed or implemented code.

    Gotta agree with you there Lynn. One cannot blame the car for their poor driving skills.:-D

    "Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"

  • Mike Austin-398977 (8/15/2012)


    By your reasoning, all of us should be required to take a course in transmission repair before we're allowed to drive a car.

    Not quite a good analogy. Programmers, even analysts that program, are more like mechanics or builders of cars than drivers.

  • TravisDBA (8/16/2012)


    One cannot blame the car for their poor driving skills.:-D

    Ever hear of the Yugo? :hehe:

    The probability of survival is inversely proportional to the angle of arrival.

  • Alex Gay (8/16/2012)


    I think Steve should have added, "If you have ever programed in Assembler, of any kind, you know what you are doing and are except".

    I wouldn't recommend C as a starting language, but once you can program it is always good to learn what your compiler is doing behind the scenes, or to continue someone else's analogy, once you can drive learn how a car really works.

    I think Assembler is too hard. The concepts there are unlike anything else, but lots of stuff builds on C. I started with BASIC and some PEEK/POKEs with minor assembler routines on AppleIIs, but I really learned programming and structures on PASCAL. That was good, but when I went to C, I found bad habits from PASCAL that didn't fly in C.

    I think C really is a good place to get early because it makes you be very careful.

  • sturner (8/16/2012)


    If you learn to think in clean object oriented mentality (which is C# & C++) you are well on your way to thinking outside the box and applying this thinking to the very design itself, not just the classes and methods that you write to implement it.

    I agree. Those (or Java) should come right after C. However C gets you going a little quicker with basic structures. Understanding variables, loops, sorts, minor stuff. A semester, or 6 weeks of C just gets you moving, then go to OOP stuff.

Viewing 15 posts - 31 through 45 (of 52 total)

You must be logged in to reply to this topic. Login to reply