5 ms·
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
by jackhack 10y ago
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.
- pselbert 10y agoYour experience sounds spot on to me. 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.
- komali2 10y agoThis 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.
- fryguy 10y ago> "what does `public static void main` mean?" 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.
- Longhanks 10y agoThen 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.
- xenihn 10y agoDo you have any recommendations for books?
- pieterr 10y agoK&R: https://www.amazon.com/gp/aw/d/0131103628/ https://www.amazon.com/gp/aw/d/0131103628/
- weaksauce 10y agoIs 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.
- joeberon 10y agoI 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-11-28%2019.14.02.png?dl=0 https://www.dropbox.com/s/4hbwyid5jwen43t/Screenshot%202016-...
- joeberon 10y agoK&R is amazing, really makes you appreciate how simple C is as a language
- mynameisbahaa 10y agohttp://www.apress.com/us/book/9781590597354 http://www.apress.com/us/book/9781590597354
- jackhack 10y agoI 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 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. hope this is helpful.