Are there reasons for beginner programmers to learn C ?

[biop codeproject]

When I first started out, I did learn Pascal. Then moved onto C. Then Perl. Then C++. Start off with Perl? No because there are those strange UNIX syntax. To keep it clean, Pascal but yes I don't think it has much real use in business. Start off with C?　I think that is ok.

[Lost User]

Yes - C is simpler and a much smaller language than C++. C is great for learning about functions, pointers, memory management and calling operating system libraries. C is a beautiful language that allows you to program efficient algorithms. You can learn about how different data types are stored and represented in memory. C will give you the power to implement classic computer science structures and algorithms: arrays, trees, sorting and linked lists. If you 'get' C, you will know that you have what it takes to be a real programmer. C will give you small, lightweight and fast executables. With C, you will have a very good foundation that will complement what you learn with other higher level languages; and the lower level assembly language. Once you know C, it will stand apart from all other languages that you learn.

[Vivi Chellappa]

If the idea of a high-level programming language is to hide hardware details from the programmer, there should never have been any commands associated with memory management in the language.

[WhaleyTim]

There are two questions here: (1) The title of the thread "

Quote:

Are there reasons for beginner programmers to learn C

" (2) The first line of the question: "

Quote:

Are there reasons for beginner programmers to be taught C instead of C++?

" There is a difference. Now, if you were wanting to learn about programming, I would not recommend C as a starting point. However if you were being taught programming as part of, say, a course in microprocessor systems engineering then C and assembler would be highly appropriate.

[pchinery]

I think learning C (and maybe also assembler) is a very good way to understand what really happens. Personally, I find it quite painful to program in these languages, as I prefer a higher order of thinking that does not distract me from doing algorithms and a good software design. But to understand what really happens and why XY now behaves just the way it does, I find it very useful that I have learned ANSI C and i386 Assembler.

[jsc42]

It depends on what the beginner's aim is. What is the purpose of programming? Ideally, it is the means of communicating a process for performing some goal. If you want someone to fetch something from the kitchen, you don't describe to them how to fire neurons to cause nerve impulses to raise a foot, etc; you start with the high level - walk to the kitchen (if necessary, tell them where the kitchen is), get (whatever), walk back. Same with programming; if there are no quick hits, (i.e. getting programs to do what you want) then the beginner will lose interest (Stage 1). However, once he / she has got some quick hits then, if they are serious about programming rather than just wanting an appreciation, lift the lid (UK) / hood (USA) and show what the instructions really do. Learning C is a very good exercise but can scare off new programmers. It should be stage 2. Only once the understanding of what happens under the lid / hood has been obtained can you use abstractions with impunity (Stage 3). It stops the programmer having surprises. I am sure that any programmer that can mentally visualise what the underlying C / assembler code would be doing will be a far more proficient programmer in any language than one who has not got that understanding. The fear is that they will continue writing C in the syntax of whatever language they are using, not appreciating the simplicity and elegance of the higher level constructs. That is why the Stage 1 is so important - it gets the concept of algorithms (the what) in place before the understanding of what the steps do (the why).

[PIEBALDconsult]

biop.codeproject wrote:

those strange UNIX syntax

What?

[Thornik]

> features that are so prone to errors "Learning C" is not a "learning your tool", it's rather "learn computer insides". Definitely worth it! Having "C" in mind never make you fool when you see at "interesting features" of another languages - you'll always know what costs what. Pointers, limited memory, I/O ports, float registers, MMX, all this gives you real knowledge. Even if you'll program on C#, its every operator will map on "hardware" in your head and you'll never ask "Why my program is so slow?".

[Buzzby 0]

I think it comes down to whether you want to teach top-down or bottom up.I think for every serious developer it's a good thing to know about. Bottom Up - bits, machine code, Assembly, C, C++, [C# | Java], [functional language] && scripting [Ruby | JavaScript | Python | etc] The Bottom up wants to impart fundamentals about computers early on (what's a processor, execution cycle, registers, memory, stack, etc.] then proceed to abstract out the details. I think this makes you hungrier to learn the abstractions and make life easier - if you haven't wondered off in another direction like marketing] The Top Down basically reverses the order, get's you involved with making things happen right away then takes you down to the basement to show you how it works. I think a lot of people stop at the top of the stairs and never learn to consider memory management, optimization, etc. since there stuff already works.

No matter where you go, there you are.

[Buzzby 0]

Sure, they were to prevent you from having to deal with registers and offsets for pointing to memory. And in an embedded world there are many time when you need to get to the data that's at location X in RAM.

No matter where you go, there you are.

[Rob Ford 2]

C should not be inflicted upon anyone. It is clumsy, slow to code and inelegant, and is a source of the World's most inefficient and buggy programs. It is only due to inertia and legacy that it still survives, mostly within failing companies.

[Fabio Franco]

bigbadben wrote:

Yes - C is simpler and a much smaller language than C++

Exactly. This way students are focused on the important stuff when they are learning programming instead of being distracted from the hugeness of C++. I believe the most important thing to learn is about pointers. Pointers knowledge will be useful even when the student is learning languages that does not require pointer manipulation. They will anticipate many of the managed programming pitfalls if they are familiar of how pointers work and how it differs from stack allocated types.

"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson

[Alan Balkany]

Yes: 1. C forms the basis for many other languages: e.g. C++, C#, and Java. 2. C is good for learning core, low-level programming skills. After these are learned, you can approach object-oriented programming without being distracted by low-level programming issues. 3. C is good for learning function-oriented programming, which complements object-oriented programming. (People who only know object-oriented programming create classes with unmaintainable 300-line methods.) 4. C can be used as a kind of "assembly language", i.e. for low-level modules that have to be the most efficient, without the overhead of C++. 5. C is a small simple language that won't overwhelm a beginner with the complexity of C++. 6. The time spent studying C isn't wasted, since C++ is a superset of C.

"Microsoft -- Adding unnecessary complexity to your work since 1987!"

[Stefan_Lang]

Depends on what you want to teach: Do you want them to understand computers, or do you want them to understand programming? For the former, start at boolean logic, continue with gates, assembler, and work your way up through C and C++. For the latter start at UML business diagrams, continue with requirements diagrams, component diagrams, class diagrams, maybe state or sequential diagrams. Then use an actual language like C++. Alternately use something else instead of UML, there are plenty of other diagram types, I know when I learned I was using Flowcharts and Gant diagrams mostly, there was no UML at that time. Most likely you'll want a bit of both worlds though: a bit about program flow and a bit about computer logic. Personally I think neither C nor C++ is useful for that purpose: both suffer from the pitfalls of various C programming language elements. My first language was Pascal, and I still think that was quite reasonable. It is much less prone to problems, is close enough to the computer to stay in touch with how it works, but still got a decent selection of commands to control the program flow. I suppose the same can be said about a number of other languages too. But my personal experience was with Pascal, and I'm convinced that was a very good choice.

[Russell Ranshaw]

It's interesting that you mention "assembly". The very history of C as a programming language speaks loudly. Long ago and long ago (as the Native Americans would say), Bell Laboratories purchased a DEC PDP-7 computer. That machine was quite primitive, more or less a "minimal" computer. It had either 4k or 8k memory of 18 bit words, 16 op-codes, no multiply or divide instructions, no index registers, and primitive indirect addressing. It did have a set of memory locations that were "auto-increment" that simulated very primitive index registers, but were not terribly useful over all. The principle I/O were paper tape and a model 33 teletype. In fact, a bare-bones PDP-7 only had a teletype, in which case it would have been a model 35 ASR, which had paper tape read and write included. VERY slow! Bell Labs wrote a language called BPL (for Bell Programming Language, I think) which they used as an alternative to the assembly language supplied by DEC. I've never seen any details on BPL. However, Bell Labs used BPL to write a FORTRAN compiler for the PDP-7, as odd at that might sound. When DEC came out with the PDP-11, Bell Labs bought one and jumped on it like a duck on a June bug! They wrote a translator that converted the BPL translator (probably other programs as well) to run on the PDP-11. Using the translated BPL, they developed a new language, C. From rags to riches in terms of machine language capability, the C designers included features in the language to utilize many of the newly available features of the PDP-11. In particular, the auto-increment/decrement and to-memory instruction modifiers were incorporated in the ++/--/+=/-= operators. The indirection modifiers gave rise to the pointer operators. The above information I learned from a Bell Labs programmer/developer at at DECUS (Digital Equipment Computer User's Society) meeting. He was one of the original creators of C, but unfortunately I forget his name. He told me that when they developed C, they had in mind a "portable assembler" that would allow them to port code to any architecture by merely writing a translator for C for that new machine. Good C programmers, he said, visualized assembly code as they wrote in C. For anyone interested, here is a link to the PDP-11 "card": [^] Given the .NET availability these days, it ma

[Matt McGuire]

Actually I agree with this. Normally I build control systems when VB.net (yes the whole control, serial comms.... all in VB). But I've found knowing C really makes you think about how you code and how it will impact the final product. I only find C fun when working on small embedded boards (Tern, Arduino), it's great to flex your skills in figuring out how to do something with almost no resources. I used to be down on C thinking of it as an outdated language, but I've since come around to realize that every language has its niche. C is for low level - embedded & kernel level, where higher languages work well for leveraging the power of the lower stack. But knowing how the lower stack basically works will help your decisions when coding in high level. One side note; I like C & VB.net, but I still can't stand C# for some reason.

[Stefan_Lang]

I agree with all but item 3 in your list: my experience is quite the contrary of what you claim: it used to be the old C-style programmers wgo produced the unmaintainable 300 lines of code functions, not the OO programmers who normally recognized repetitive parts and refactored them into seperate functions. And it's the same C-programmers that used copy/paste programming to implement an alternate branch in a function, needlessly bloating them to several 1000 lines during the lifetime of an application. However, in truth this may be less connected to being C or C++ programmers, but rather to being good programmers! ;)

[svella]

For a beginner, if the choice was between C and C++, I'd definitely start with C. Why? because C++ has too many voodoo automatic behaviors that bite even experienced C++ developers in the ass. C, by comparison is relatively straightforward to understand the complete behavior of the language. But I wouldn't pick either one as a first language. My first language was APL, but I wouldn't recommend that either. I'd probably start with one of the current crop of dynamic languages. -Shon

[patbob]

Maximilien wrote:

I know there are lot of legacy code out there and it should still be maintained, but old code "ways" should not be the emphasis of the education.

Emphasis? Certainly not. However, all of software is made up of layers upon layers of leaky abstractions. Sooner or later, quirks from the lower levels leak through to the upper levels. If you already have a working understanding of the lower level, then what's happening makes sense and you already have an idea of what to do about it. If not, you sit there dumbfounded, without a clue where to start debugging the problem. You will absolutely need to know how the next layer down works to deal with bugs that appear in the layer you're working at.

Maximilien wrote:

Are there reasons for beginner programmers to be taught C instead of C++?

I can't think of any. In fact, I wouldn't recommend either language for beginner programmers. Beginner programmers are learning basic concepts, like if statements, boolean logic, loops, variables, functions, etc. Any language that allows them to learn those concepts without having to worry about other details is the best one to start with. In fact, it shouldn't be a language they might use for real work, because they'll also be learning lots of bad habits that the rest of us don't want them to be bringing into our production code. Sometimes a student has to start learning with the language they'll be using for production code, but that just makes it harder for them because they'll have to unlearn a lot of bad habits without really understanding what's going on, why those habits are bad, and what to replace them with. Its actually easier to take concepts forward into another language, learning good habits as you learn the language, than unlearn bad habits.

We can program with only 1's, but if all you've got are zeros, you've got nothing.

[spotsknight]

I had some initial introduction to Basic in high school - way back in trash-80 (TRS-80) days. But my first and I feel MOST beneficial college class I EVER took was programming logic with pseudo-code and flow charting. After that my first language was C then later C++. If I had tried to learn C++ first I'm not sure I would have understood what was actually happening. When I'm writing code I want to make sure I understand what exact is happening. There is a lot in C++ that was much easier to learn knowing the basic C language.