Richard Stallman Announces GNU C Language Reference Manual

[DavidBrown]

Pointers in general they thought it was crazy that we could do array[n] and then do *(array + n), but I would also say that it was hard to teach that arrays of variable size could be allocated with malloc and then dynamically grown. In my personal opinion we taught what I thought should be CS 1 and CS 2 as part of CS1, my small country regional university stopped CS 1 with arrays, regular arrays, pointers and such were saved for CS 2. We didn't learn about data structures until CS 3 / Data Structures. I was teaching these poor kids about linked lists the last week of class!

When I was doing my CS PhD / masters I was doing research in CS education and what the best first language is, it was some fascinating stuff, I left before I got anything published though.

Ask for your money back from the university - if they taught you C in your first year, it was a C coding class, not a computer science degree.

[DavidBrown]

That's a good point and a good reason to not start with C(++) but with Python or similar where you can have a shell which directly interprets your code and gives you direct results. However one should still know about memory allocation and lifetime. You don't have to know the difference between heap and stack when you start programming, but that every allocation reserves memory which needs to be freed afterwards is something that should be know early on - my opinion (and I used Java for many years).

Control of memory allocations is important, but I think its importance is often overrated in programming. After all, it is only one type of resource - there are a great many resources that need to be handled carefully in programming. Garbage collection and reference counting can do a pretty good job of tracking memory for you, and even if you leak, many kinds of programs can still run fine. (Indeed, for some kinds of programs there is no point in freeing memory at all - just let the OS clear it up when the program ends - its more efficient.) Leak a semaphore, mutex or a file handle, or other kinds of resource, and you could be in far more trouble. So when learning programming, learn to take care of your resources, and then memory management is peanuts and you won't get it wrong even when handling it manually (baring bugs - programmers are still mere humans).

I think that people who worry a lot about memory management have a somewhat myopic view of programming. That's not an insult - it's an observation, and applies to many people whose programming experience is limited to general-purpose imperative languages such as Java and C. Try a pure functional programming language like Haskell - the concept of memory management or leaks doesn't even make sense there, as there are no such things as references, allocations, arrays, etc. Everything is a value. Or try high reliability small systems embedded programming. It is typically done in C, sometimes C++ or Ada. There's no need to think about memory management because dynamic memory is generally banned.

[kylew77]

I'd say don't confuse students with pointer arithmetic and array operator notation, straight away. Just getting their heads around a variable that addresses another variable, and then how it enables heap allocation should be enough for one or two lessons, at least (depending on how far you want to go with heap). Pointer arithmetic should be a separate lesson.

Unfortunately, I didn't have much say in the lesson material or when it would get taught. I was responsible for the homework assignment creation and grading and running the programing labs which also had material against my wishes. Heck the first week alone was conditionals, if , if else, case. Most of these students had never seen a command line before or knew how to run commands. I spent half of the first session explaining why the password doesn't echo when you type it in and how to use nano and gcc from the command line. Then you have students who want to use their own mac's and those of course that come with LLVM so explaining a few differences there was always fun. But yeah in my personal opinion we needed a week just to get around how to use putty and ssh and the first weeks program should have been printf("hello world"); but it was not! Loved the job and the rewardingness of it but hated that the department had so much control. The teacher I was running the labs for hatted how the department was run too. He was a good man. But yeah throwing assignment like x = 5; and conditions, and basic scanf and printf functions and preprocessor directives all into week 1 is way too much in my opinion! Of course you get questions like why variables need a "&" sign with scanf and not printf but you really can't explain it week one with the knowledge they have. What haunts me to this day is we had a woman take the class 3 times and try her hardest and not pass each time and she had to have the class for her engineering degree. She was in mechanical or civil or something like that, someone unlikely to ever need to code in C, but the university insisted that she learn to code in C. It bothered me that they kept on putting her in this class when she could probably pass a python course or java course had it been offered because she only started struggling when we got to pointers. This is all ancient history now 2016 and 2017.

[coder]

Pointers in general they thought it was crazy that we could do array[n] and then do *(array + n),

I'd say don't confuse students with pointer arithmetic and array operator notation, straight away. Just getting their heads around a variable that addresses another variable, and then how it enables heap allocation should be enough for one or two lessons, at least (depending on how far you want to go with heap). Pointer arithmetic should be a separate lesson.

[coder]

If you really want to be good at efficient programming, write some assembly code.

Not sure I agree that assembly is necessary for learning "efficient programming". C is good enough, for that.

Write some small programs in assembly. Do some maths, some string processing, and some data structures in the code. And then don't bother programming in assembly ever again, outside extremely niche situations - but remember what it was like when you are coding at a higher level.

Yeah, the main thing assembly language programming teaches you is how much even a C compiler does for you. Register allocation is a huge headache, if you have to do it by hand. Something with lots of general purpose registers, like ARM, should be good for dabbling. That way, you shouldn't have to redo register allocation every time you make a little code change.

And keep https://gotbolt.org bookmarked, so that you can see the assembly generated by compilers (of many languages, not just C).

When I was writing SSE code, I used the C intrinsics but I'd check the compiler output, to make sure it wasn't generating lots of extraneous instructions. I did find a few surprises, that way! In the end, I got reasonably close to the efficiency of hand-coded assembly, if not better, and with a lot fewer headaches.

[baka0815]

IMHO, the most important aspect of learning your first language, is that you should enjoy it. And that means having results quickly - it means being able to write a program that does something, knowing only a small part of the language.

That's a good point and a good reason to not start with C(++) but with Python or similar where you can have a shell which directly interprets your code and gives you direct results. However one should still know about memory allocation and lifetime. You don't have to know the difference between heap and stack when you start programming, but that every allocation reserves memory which needs to be freed afterwards is something that should be know early on - my opinion (and I used Java for many years).

[kylew77]

Was it pointers or heap allocation that people really struggled with?

Pointers in general they thought it was crazy that we could do array[n] and then do *(array + n), but I would also say that it was hard to teach that arrays of variable size could be allocated with malloc and then dynamically grown. In my personal opinion we taught what I thought should be CS 1 and CS 2 as part of CS1, my small country regional university stopped CS 1 with arrays, regular arrays, pointers and such were saved for CS 2. We didn't learn about data structures until CS 3 / Data Structures. I was teaching these poor kids about linked lists the last week of class!

When I was doing my CS PhD / masters I was doing research in CS education and what the best first language is, it was some fascinating stuff, I left before I got anything published though.

[DavidBrown]

Eh, I'd venture as far as to say that C is good starting point for understanding computers and how they work. If you really just want to learn about algorithms and data structures, then C is probably too low level. I feel like there's been pretty broad consensus on this, for a while now.

I agree about the algorithms and data structures - with C, you're likely to spend more time getting the manual details right, instead of focusing on the algorithms.

With C, you will learn more about how the computer actually works than with other languages, but you will not learn as much as you might think - and you can quickly "learn" things that are not true. People will often say that C is "close to the metal", and that with C you get exactly what you ask for. This is not true - C is specified in terms of an abstract machine, not the target processor, and the generated object code does not have to match the literal source code except at certain specific points (the "observable behaviour"). This leads people to misunderstandings such as thinking that signed integer overflow is two's complement wrapping because that's what the processor does, or that they can mess with pointer casts and get the results they think are "obvious". So yes, you learn a lot about the machine from programming in C, at least compared to most other languages, but don't take that concept too far.

If you really want to be good at efficient programming, write some assembly code. I'd recommend a small processor - get an Arduino kit or something like that - rather than the monstrosity that is the x86 world. Write some small programs in assembly. Do some maths, some string processing, and some data structures in the code. And then don't bother programming in assembly ever again, outside extremely niche situations - but remember what it was like when you are coding at a higher level.

And keep https://gotbolt.org bookmarked, so that you can see the assembly generated by compilers (of many languages, not just C).

[DavidBrown]

Really? I wrote a bunch of Postscript, at one point, and I seem to recall that all the stack stuff was automatic. I'm not sure it had any heap memory, but it seemed like Forth was entirely stack-based. At least the version used in Postscript.

Postscript and Forth are both considered "stack-based" languages, but are otherwise rather different. In particular, Forth has two stacks - the data stack, and the return stack. The return stack is mostly managed for you, as you call "words" (functions, in other languages) and return from them. The data stack is up to you. It is up to you, manually, to take as many parameters as you want from the stack, and return as many values back on the stack. You can leave the stack longer or shorter when the function ends - you can also leave it different lengths at different calls to the same function. (Disclaimer - my experience of Postcript coding is extremely limited and very outdated.)

[Volta]

Let me guess, Hurd is also de facto kernel and emacs the de facto text editor (or operative system, depending how you look at it)

Stop kidding. Hurd is nowhere near GCC when comes to popularity. You should said: Linux is de facto kernel and that would be great analogy. GCC was very innovative and its inventions are visible in future standards.