I wish I could like this book, but after reviewing the first chapter I can only imagine the confusion of students. I support very much the idea of breaking the book into levels, but it attempts to cover far too much, far too quickly and I don't believe this book would be useful for those who are not already familiar with the language.
I've been writing C since the late 1980s, moved to mostly C++ by the mid 90s, C# in the 2000s, and now I've come back to C. Most recently built some realtime components and drivers, having to drop back to C77. I mention this as I've taught many colleagues along the way and I'm sensitive to the places where beginners tend to get hung up with problems and I've come to anticipate many of the questions along the way. Let me take a moment to illustrate the base of the problems i see:
"Too much, too fast." The best example is right on page 2: a program which demonstrates a complex printf format string, along with arrays and loops. I can't help but sarcastically ask "Are you sure that is how you want to introduce someone to the language?" A beginner's eyes will glaze over.
Seriously, the way to introduce the language is simple examples. Explain the main is the entry point where all programs begin running, and that main returns it's success or failure to the operating system (or other program that called it). 3 lines of code.
Then add a SIMPLE print, if you wish, or a variable declaration. Int. Float. char. again, it MUST be simple.
Introduce loops.
Then show how to move some functionality out of main into a subroutine/a new method/new function, how to call that function, and return results. Talk about header files, etc.
From there, dive into the rest of the base language... talk up arrays, memory management, heap/stack, pointers, libraries, exceptions, etc.
But this is only my experience, and I'm sure that it is different for others. Kind regards.
This has always been my problem with websites like codeacademy, and I started my entire career by learning through that website.
Take the Javascript course - a fantastic way to get introduced to the syntax of the language, and I highly recommend it for total noobies. But then you come out of it with no understanding whatsoever about what javascript is. If I asked someone who just finished the course to make an "app" that console.log'd to the console, they wouldn't understand where to start. They wouldn't know that JS is a language run in the browser, that they need an HTML file with a script tag or a node file that they can run in the terminal. They wouldn't know about DOM manipulation, etc.
This reminds me of the Java class I took in highschool - the teacher was going on about ints and floats and loops, and the only questioned I wanted answered, and never got an answer for, was "what does `public static void main` mean?" I think the fact that I never got an answer to questions like that are why it took me nearly 3 years into my career to figure out I should be a developer.
The problem with this question is that there is a ton of stuff you need to understand before you can really answer that question fully. To know what public means, you need to understand classes, and visibility rules for classes. To understand static fully, you kind of need to know how c++ works, since it's equivalent to a bare function in a namespace. Void is the type of the return, which means it doesn't have so that's pretty straight-forward. Main is the name of the function that gets run when you run the program, which kind of requires knowledge of program entry points (assembly) either that or the understanding of what a library is. The simplest thing you can say is that it's boilerplate to signify what function gets run when the program starts, but that doesn't really explain any of the pieces.
Then why start teaching programming with Java in the first place when understanding those concepts involves an at least mediocre understanding of object orientation?
There are many more languages that implement a "Hello, world!" with one line of code. If explaining "public static void main" is too hard, maybe one is using the wrong tool.
This is an idea that many people resist. I think they mistakenly believe that programming languages are genuinely difficult to learn, and students must start on one that is marketable.
It's hard to teach an introduction to programming without teaching a particular language. If you have to pick a particular language, it makes sense to choose something the student is likely to use in the future. This is not hard to understand.
That's silly. If you can reasonably claim to know how to program, the choice of language largely doesn't matter. Someone who knows how to program in [first language] should be able to pick up how to program in any language one is likely to encounter in an industry position.
So the first language should be one that gives the student a firm foundation from which one can become that competent.
I've personally seen excellent introductions to programming using C (CS50x), Python (Think Python, MIT 6.001), and Scheme (SICP).
My point is that you likely learned programming by learning the basics of file I/O in C or Python or something similar. You didn't sit down and learn all about automata theory etc. first. You need the context of what C.S. is used for before these things make sense to you, so you start by learning a bit of programming. Since you must be definition have A first language, why not pick one that is most likely to be used?
I don't really approve of this view. CS students are going to be programming in current-gen languages like Java, Python, C/C++ and JS in industry anyway (C is perhaps last-gen...). I think academia should lie a couple steps ahead and introduce students to stuff that will help them advance the industry. Next-gen and maybe experimental/academic languages and tools. Teaching students current industry languages/tools is good for the individual student but bad for the industry as a whole because it causes stagnation. Universities are big enough that they ought to be able to rise above this tragedy of the commons and do something for the greater good rather than think narrowly of the individual student.
Because it's stuff the will teach eventually and don't want to force students to learn a different syntax a few weeks in. I'm not sure if students can handle the syntax switch or not though.
For me and probably many others having it go unexplained was like dangling carrot in front of me. I went home and read more about it.
Java is a terrible first language. Python is even worse. They both require a good understanding of a ton of different topics to understand them as anything but magic incantations.
It was the first object-oriented language that I learned, and some of my classmates' first language. It wasn't too bad to be told "Just type it for now; we'll get into object orientation next week and explain it then." From my own experience, I don't think it's a big issue if it's introduced correctly.
I held onto the promise of a forthcoming explanation (and read ahead in the book, anyhow). Honestly, someone who can't deal with a little ambiguity when starting out on a new technology isn't going to last long in the field anyhow, especially with the amount of self-learning that you end up doing.
Agreed, for a number of students the promise to explain it later will suffice. Others - when given magic boilerplate that does strange, intended things - will recognize it for the black magic it is and will want to wield it as well.
They will dissect, examine and research it on their own and their learning will be much deeper.
Well, that's me in a nutshell though. If I don't get the answers I need soon, I get frustrated and it becomes nearly impossible to stay focused or motivated. With web development, I was lucky in that I had teachers that were willing to humor my curiosity, and I could also hop on the internet and IRC channels.
Self learning is the opposite of the classroom issues I had. I can start a webpack tutorial, it'll mention Make, and I can click links and chase down information, and just keep my stupidly ADHD brain entertained with more and more new new new things. This is how I have to learn things, apparently.
That sounds more like a problem with incoming student's expectations than with the teaching method. Almost every interesting (i.e., sufficiently complex) subject isn't arranged in a pedagogical hierarchy. You can't explain history from the first day, because you'd have to explain where that knowledge came from. You can't explain math without pushing things for later because students are not prepared for generality on day 1. You can't explain human biology by describing various cells. Etc..
If a student is going to 'check out' because they didn't get a question answered, then they're probably just going to fail. See your teacher after class, ask a friend, look it up online... If are a 'curious student' doesn't see these very obvious methods of satisfying their curiosity, then they're probably not worth a teacher's efforts.
I've always thought Java was an awful introductory language. It's a decent teaching language but in order to actually understand what's going on and why, you need to already be familiar with huge swathes of modern computer science.
Python is even worse, because it's so high level and so much happens 'by magic'. Don't get me wrong, it's a great teaching language because it does cover so much ground, but it's terrible as a first introduction for a new programmer.
They need to start with something simple and fairly concrete. Maybe even start with a simulated 'toy' assembler (first semester CS101 = Zachtronics games?) then something like Pascal to teach the basics of control flow and sequential processing.
Once students understand primitive data types, control structures, functions, and compound user-defined data types, they're probably ready to learn some OO.
No matter what you are teaching, whether it is fundamental like reading, physical like a sport, or technical like programming, it is critical to teach ONE THING at a time. Teaching multiple concepts at once muddles the exercise and slows down learning. Breaking large concepts into discrete blocks lets the student focus and then build on that concept as they continue.
That's certainly how I work, and how I've heard experienced teachers explain it.
I learned C from Kernihan & Richie (K&R) under supervision of experienced developers. I was really lost for a few days, the book is kind of terse. I had been developing in assembly for several years, so C felt like a really high level language. I still recall being baffled by pointers and handles, dealing with segmented memory (this was 386 days, Turbo C on the PC, MPW on the Mac for C & Pascal) It was about a month before things "clicked" and pointers made sense.
I think the follow-up C book I read after that was "Learning C". I don't recall the author's name(s) but I think it was from two brothers. Dan, something? (I'll check my bookshelf when I get home tonight and update here...).
I learned C++ initially as just 'C with Classes'. It was informal, by joining a C++ project already underway, and following the senior developer's guidelines. Instruction was informal, and under supervision of others, yet I hadn't made a complete mindshift to OO until probably six months to a year after using it.
I liked "Thinking in C++" (Bruce Eckel @ http://mindview.net/Books/TICPP/ThinkingInCPP2e.html ) quite a lot -- in fact I re-read it several times about six months apart and it seems I always pick up some new nugget of knowledge every time through. That or I forget what I don't use. Possible.
Keep in mind the newest of these is a decade old, at best. Surely not "modern" C. But after completing a basic tour of K&R C, a reader should be ready for the book at the top of this discussion. And that will transport them into this century.
Is that still relevant to how c looks and acts nowadays? I know you will learn a lot from it and it's an excellent book, but surely there is a better reference that is more up to date. Maybe not though.
I think it's still really helpful to learn C and as a reference, but the code has a very terse and difficult to read style that I wouldn't recommend actually coding in, for example this is introduced in the first chapter, before anything is even studied in depth: https://www.dropbox.com/s/4hbwyid5jwen43t/Screenshot%202016-...
CS:App book, from 15-213 at CMU goes well with K&R to teach unsigned/TMIN/Float/pointers at the asm level, gdb, Valgrind to check for mem leaks, compilation gotchas and more. http://csapp.cs.cmu.edu/
If you're new to programming, Harvard's CS50x on edx is probably the best introduction to programming online and uses C. You'll learn enough to breeze through K&R and then some.
I've been writing C since the late 1980s, moved to mostly C++ by the mid 90s, C# in the 2000s, and now I've come back to C. Most recently built some realtime components and drivers, having to drop back to C77. I mention this as I've taught many colleagues along the way and I'm sensitive to the places where beginners tend to get hung up with problems and I've come to anticipate many of the questions along the way. Let me take a moment to illustrate the base of the problems i see:
"Too much, too fast." The best example is right on page 2: a program which demonstrates a complex printf format string, along with arrays and loops. I can't help but sarcastically ask "Are you sure that is how you want to introduce someone to the language?" A beginner's eyes will glaze over.
Seriously, the way to introduce the language is simple examples. Explain the main is the entry point where all programs begin running, and that main returns it's success or failure to the operating system (or other program that called it). 3 lines of code.
Then add a SIMPLE print, if you wish, or a variable declaration. Int. Float. char. again, it MUST be simple. Introduce loops. Then show how to move some functionality out of main into a subroutine/a new method/new function, how to call that function, and return results. Talk about header files, etc.
From there, dive into the rest of the base language... talk up arrays, memory management, heap/stack, pointers, libraries, exceptions, etc.
But this is only my experience, and I'm sure that it is different for others. Kind regards.