I would argue C is a difficult first language. It's even a difficult 2nd or 3rd language.
I would start people off programming at a higher level of abstraction and once they can do that dive into how things work. You could start the other way but it may be too theoretical and discouraging.
Pascal used to be the language of choice and IMO can still work well. Things got more complicated when we got all those competing paradigms and now you have a matrix of language/paradigm. Should you teach OO? Functional? Procedural?
I also think it's important to lay our some theoretical foundations as you're teaching the first language. You don't want to overdo it but you need to start building some basic ideas, notations, concepts. As long as it doesn't get in people's way in their ability to actually build something...
If you want to understand how computers work there's no substitute for programming in assembler, preferably, under different hardware architectures.
This debate about how to teach programming/CS/software engineering is endless. Different people and different schools have different goals and different capabilities. A well rounded software engineer definitely needs to have a good mix of theory and practice. A CS researcher needs a different perhaps mix.
IMO, C in a unix context is an excellent first language. It is useful in many contexts to learn to look for all the compiler warnings available :). Once you find them I don't think it is particularly hard. I agree about assembler, although I think just learning system calls and C is a good start. "See MIPS Run" is a great way to learn assembler IMO.
I first learned Pascal and was very relieved to move to C. I don't think such limited languages are good for much of anything. They just frustrate users.
I don't know Python but from what I know of it it seems like it would be a fine first language too. Anything else I know of seems like it has significantly wose issues than C IMO.
C is an excellent 2nd language. The language itself is obtuse, but the underlying model is fairly simple. C++ is a horrible one. These days, probably nobody should learn C++ and should probably pick up Go instead.
As a teenager, I picked up a book on C++ having already learned BASIC, Pascal, and MS-DOS but never got proficient in it. I should have picked C. The "++" lead me to believe that it was a better language than C and I didn't have any real programmers around to tell me otherwise.
C++ has many followers but it's a multi-headed beast and some of it can be much harder to grasp. I think it's easier to argue that it's better than C; all you need to do is to look at C code that tries to implement some patterns that are more naturally expressed in C++. Go isn't really a substitute for C++ but one might argue D is.
Sounds like C++ and you didn't quite work out. I'd still encourage trying to figure out how some pieces of C++ can improve your C code and use those. You're welcome to stick to C in the rest of your code. A lot of "real programmers" do use C++ successfully and a lot of software you use has C++ in it's DNA...
EDIT: (That said I would only expose new students to C++ after they've seen C and some higher level language so they can appreciate the niche that it fills)
Whoops, I didn't mean to give the impression that C++ guys weren't real programmers. Of course they are. I literally meant "real programmers" as in, anybody who had more experience than I did. I was completely self-taught.
I will probably never touch C++ again. I solve all my problems with Ruby and if I ever need to go lower-level, I'll break out C and maybe Lua.
Go was very much designed with the intent of being a better C-replacement than C++[1]. As to whether it's an actual viable replacement or not, well, that really depends on how dependent you are on libraries.
Back when I was getting into 'serious' coding, anybody with experience in both C and C++, whether they liked one or the other better, could have told me enough to make me realize I was better off learning C first.
I can count twenty (now) too, and I still won't touch it. By the time I was a teenager with that C++ book, I'd already been programming, whenever I could find hardware, and reading about programming for five or so years. I was kinda obsessed.
I would start people off programming at a higher level of abstraction and once they can do that dive into how things work. You could start the other way but it may be too theoretical and discouraging.
Pascal used to be the language of choice and IMO can still work well. Things got more complicated when we got all those competing paradigms and now you have a matrix of language/paradigm. Should you teach OO? Functional? Procedural?
I also think it's important to lay our some theoretical foundations as you're teaching the first language. You don't want to overdo it but you need to start building some basic ideas, notations, concepts. As long as it doesn't get in people's way in their ability to actually build something...
If you want to understand how computers work there's no substitute for programming in assembler, preferably, under different hardware architectures.
This debate about how to teach programming/CS/software engineering is endless. Different people and different schools have different goals and different capabilities. A well rounded software engineer definitely needs to have a good mix of theory and practice. A CS researcher needs a different perhaps mix.