This is the eternal debate, but man, I wouldn’t start somebody off with a C programming course as #1. Especially if there’s a Python course coming up shorty anyway. And then a C++ course to learn “OOP”, which is much easier to learn in Python. Ouch.
I suggest just starting with Python, learning C at some point because it’s universal, and never learning C++ without a specific reason.
I started with C, and if you don't dive to deep into it, you can get a pretty good concept of program structure, what a function is, what a pointer is and all sorts of concepts that extrapolate easily in other languages.
I'm grateful to have learned on a strongly typed language first, the thing about students is that sometimes they're easily demotivated, my University switched to python after teaching C first, after learning python there were a lot of student complaints asking why C was so complicated and why did they need to have static typing, and it wasn't natural to them to think about compiling as a normal step in software development.
This sounds like a survivorship bias. I'm willing to bet that if someone such as yourself (who is motivated to learn C) started with a weak/duck typed language, you would have maintained motivation, and later moved onto something like C, feeling grateful to be learning C. i.e. who you fundamentally are is not altered by the language you first start learning.
Now take the reverse. If someone who is not motivated to learn C started out in Python, they're more likely to stay motivated, perhaps never learning strong typing. If you start them on C, they lose interest and the field loses a valuable addition.
Not everybody has to learn C or static typing or pointers. It's okay for people to have a narrow programming/comp sci scope and still enjoy the field.
I learned C as my first language and suggest it as first language. And I think it is relatively small language, (discounting all the different details open to implementation not covered in the spec).
One thing I would miss as a beginner is repl. Because, that is how I later learned bash with constant feedback and constantly tweaking the input code until the computer stops swearing at you. Also, it was really fun way to learn language, one small piece at a time. Other than that, I do not consider C to be a particularly hard language.
But, if your goal is to learn a language with modern OOP design, then you should go for python or ruby IMHO. It is much better than Java, (even to do anything you have to create a class with main with so many modifiers). I think that would the reason to learn python, because structuring the code is archaic or at least different from how other mainstream languages in C and can be a hurdle for newbie who want to scale up their programs.
I think good about python is being simple and also having features that are mainstream that translates various other mainstream languages. But, should I care about that as a newbie is an entirely different thing.
Why would they lose motivation with C? Its really not that difficult. At least not compared to something like haskell or even something like python at times (are dictionary comprehensions actually that easy from a syntax POV? What about how copying a dictionary isn't an element by element copy, but a reference/ptr copy?)
Even with undefined behavior (which a newbie won't really have to care about at the beginning IMO) C is relatively simple from a flow and structural point of view. If you are saying you can do cooler things in python than C at the beginning, that's probably true, but its unclear how many people drop CS because the language they are using doesn't enable easily making cool things.
> Why would they lose motivation with C? Its really not that difficult.
This is the confusion right here. You're underestimating what is difficult to other people.
As a friendly internet stranger with modest leadership experience, I would very gently suggest to be cautious of this pitfall. When we think like this, even if it's just coming from a place of logic, we can very easily send the wrong signal. We can make people feel stupid, and wonder why we're being critical of them.
I think it helps motivate beginners if you pick a stack that allows them to create a modern UI, even if the functionality is something as useless as a vuvuzela app.
No, it isn't. There isn't consensus on what weakly/strongly typed actually means, but C is strongly typed (with some unfortunate loopholes) by most definitions.
I always feel like people who suggest python over c as the de-facto thing to start with, are probably people who started with something like c over something like python themselves, but forget all about how all that experience and understanding helped them make sense of python in an instant, and thus consider the 'easy' language a no-brainer.
To an absolute beginner, however, python is not only an incredibly complex system (except for extremely trivial things), but because it goes out of its way to hide its internals, it cripples users for years before they can figure out what's actually going on under the hood.
I'm fully on the "start with c, move to python" camp. The lessons just need to not suck, which I concede may be easier to do with c ... but it should still be c.
> it cripples users for years before they can figure out what's actually going on under the hood.
it doesn't - python hides the unimportant aspect of the computer; namely, it abstracts the memory allocation and resource process. You treat the computer, under python, as an abstract machine which has unlimited memory, and don't worry about its use. you focus on algorithmic understanding and fundamental data structures.
Once you grasped the computer science fundamentals, then you tear open the box and learn the underlying impl. of a computer - such as memory allocation, and assembly, etc (ostensibly, by making your own operating system using C, and/or writing a compiler using C).
you can replace python with haskell, which imho, does an even better job as a first language.
To be fair, python has many robust features beyond gc. For example, dicts, which are bread and butter for python abstract away 1000s of lines of C, which leads to very confused students when they first see errors like 'unhashable type: list'. Encountering leaky abstractions always made me uncomfortable when I took my first classes, but for a very first class its still probably better than dealing with memory allocation in C depending on what one expects from an intro class.
But when you start using dicts at the beginning, you would be learning about hash maps and what hashing is, etc. This is basically computer science 101 stuff, with which python makes an environment much easier to learn with.
I think this depends on the student. I do not have a CS degree. I dabbled in Python, but the first programming course that I took was Harvard's CS50 MOOC. I really appreciated learning C because it taught me about the underlying system through concepts like memory management. I agree that Python is friendlier, but I feel like C trains a particular mindset. Python may be more suitable for those who want to get off the ground quickly.
The thing about languages like C is that they will teach students to do many things by rote that they aren’t equipped to understand until later. I’m talking about things like includes, using a compiler, << and other facets of basic I/O, defining a main function.
Python allows students to hit the ground running much faster. Once they learn the very basics, then it can make sense to introduce something like C, but not require them to temporarily ignore magic incantations with the promise they’ll understand them later.
When teaching new students Java, the first step is "type these exact lines character for character, you won't understand what they mean for the next year, but you need to type them at the start of every new program.", which can be a little rough.
You have to create a class with main method, just to start. And you need to know, what are access specifiers, what are classes and static methods. Of course, you can just ignore them as something you just have to do, but I think buy design OOP is not an additional requirement but starting point in Java.
But, it is not like you have to use them, in that case why start with a complex language as a beginner anyway? It will either be too much of details or too much of magic to remember.
(Digression : in my beginner days I was using C as a glorified assembly language with control flow redirection only through, (wait for it) goto. Even after grew up to 700 lines. Only while doing a java port I got used to using methods because java does not have goto)
Well, I am not sure about Java 11. It took 25 years, yes and organization I work has just entered the java 8 world completely. It was originally written in Java 7 and it took 5 long years to completely transition to Java 8. Even then (Java got a repl now!!!), I am skeptical of the language in terms of beginner friendliness.
So, if you are going to read some code from the world you should be familiar with the archaic notations anyway. Even in frameworks, which java shops in neighborhood is mostly about, has intro docs with terms from almost 15 years ago and assumes people who read are aware of it. The thing that really bothers me (not that it is bad in an objective way) is how much old java platform has OOP encoded to its DNA. And it is great at it.
It is a language meant to be used by people who are familiar with writing such code. The FP is really enjoyable, but kind of ugly and seems retrofitted into the OOP. In general, I like opinionated crisp languages, but Java is getting away from that. In nutshell, it is disorienting for me now a days.
no it's not. The language _requires_ those incantations, but to explain it all to a beginner requires a lot of time and effort which, to the student, doesn't look like any payoff (until they have internalized it completely, and understands their meaning).
It's the same as human learning natural languages - you have specific grammar and rules you _just_ follow, without understanding their etymology or how it evolved to be this way (and their uses).
And python requires its own boilerplate incantation. One is neither considerably less verbose than the other, nor any less cryptic. Both take exactly two lines. The python incantation simply "feels" simpler to you, because you as a seasoned programmer comprehend the 'intent' behind it as being simpler. But this is more likely to relate to our inability to perceive from a point of ignorance that which we already understand.
A good lesson could start by explaining what these do by way of dissection and for the purpose of orientation, without going down the rabbit hole.
This resonates with me. When I was an undergrad about 25 years ago most intro to programming classes were taught in C. There were a lot of concepts I struggled with at the time that now I find trivial. In retrospect, what I was really struggling with was some of the lower level gnarly bits C exposes to the programmer.
While it's good that I know how those things work, I did not need to understand them to just get a basic understanding of strings, data structures, etc. For instance it wasn't that I couldn't grok linked lists, I couldn't grok pointer manipulation at the time. But that still meant my code didn't work.
it's really a big-endian vs little-endian matter, if you think about it.
Starting with C means sitting down, thinking hard and taking the time to understand how the basic model of a computer works, along with all the issues and annoiances that come with it.
Starting with python really means leaving out the details and just getting into programming and maybe one day you'll wonder ow stuff actually work underneat.
I TA'd an introductory computer architecture course (basically, start with a MOSFET transistor and end up with "here's how you write malloc/free"), which was students' first introduction to both assembly and C. That experience helps solidify that you really want to students' first experience with programming to be a high-level language.
One of the problems with teaching is a phase-ordering problem: what order do you teach the concepts in? As GP notes, C starts you off with a lot of boilerplate that isn't going to become relevant until a month or two down the line. Concepts like functions, libraries, the insanity that is the C preprocessor are distractions when your first challenge is just getting people to understand the mental model of how a procedural program works (i.e., understanding what x = 5 really means!). On top of that, C imposes a mental burden of understanding the stack versus the heap and the relevant memory management concerns. And then you get into C's string handling...
I suspect many of the people commenting here are in the class of people for whom programming was obvious and easy, and never struggled with any of the concepts. This class of people will do fine with any language being used to introduce the concepts, because they're not really learning the concepts. Where the language matters most is for those for whom programming is not obvious, and they need help identifying which parts of the material is more fundamental than others. Giving these people a language that is more forgiving of mistakes is going to go a longer way to democratizing CS education than insisting people start by learning how computers really work.
That isn't to say that this isn't something that should be taught pretty early on: far from it, I think a computer architecture class should be the second or third class you take on the topic. Delaying the introduction of C until computer architecture means that you can use C as a vehicle to introduce all the other parts about computers that are important, such as 2's complement arithmetic, ASCII, what the stack and heap are, etc.
>Starting with C means sitting down, thinking hard and taking the time to understand how the basic model of a computer works, along with all the issues and annoiances that come with it.
Then perhaps ASM would be an even better starting point?
Personally, I dislike all the 're-learning' process. However, by 'Python', I had to re-learn quite a few concepts when I touched C ground. Of course, it was a 'A-Ha' moment to put in positive way.
In C, you learn to modify a letter to upper or lower case, by finding its ascii number, and adding to it, or subtracting from it, a magic number.
In Python, you just use the .lower() or .upper() function.
One and done. Move onto your next problem.
In C, you hope to not trigger an array-index-out-of-bounds error, resulting in a segmentation fault. Then, not understanding what you did wrong, and then having to fire up the debugger to find your needle in the haystack.
Hours later, you’re just like, I just want to modify a string. Why is it so difficult?
This is a silly argument. You have to do the exact same thing in python if you don't want to use a standard method/function. There's nothing stopping you from using a standard function in c either.
Your rant should be about bad teaching of bad habits instead
What I’m trying to point out, is that C has a lot of compromised and poor design decisions made, as a programming language.
Maybe it was because it was designed in the 1970s, when computers were more primitive. But better alternative languages were designed back then that didn’t have the failings of C.
But these designs permeates throughout the language. So eventually errors keep coming up.
Totally agree you need to learn C before getting too far, but it can make intro programming more challenging than it needs to be. Since this is supposed to be an ML-targeted curriculum it seems like Python is a better start. However, as I said, it’s an eternal debate. At least we have choices!
you learn Python to get the basics: what are variables, what are values, what is control flow, what are functions, what are modules, how does it fit together as code to perform tasks. Worrying about the memory and the underlying machine can come later. The biggest problem with Python as a beginning CS course is that it´s not a great language to learn about types (meaning it's more difficult to learn the cluster of related concepts expression, value, type, variable).
I guess I have different thoughts about what the basics are. I would advocate to start with assembly, but I’m biased because I started with assembly. Things like what is memory? What is a register? What is the Program Counter? What (really) is the call stack and how does it work in memory? Fetch-decode-execute? Jumps, conditional branches, loops. Address modes.
If you know these things, then you know how the computer actually works, and a lot of the mystery of C is behind you already.
Then you can start introducing stuff that’s built on top of it all like types, if statements, pointers... build the building from foundation up, don’t start on the second floor and tell the student not to go downstairs yet.
That's not a good way to teach someone to code and there's a reason why absolutely no curriculum on the planet does it that way. If you're teaching someone how to operate a car you start by showing them which pedal is the gas and which is the brake, not by explaining to them how a differential works. The pedagogical basics and the lowest level system primitives are not the same thing.
Bottom up vs top down. A lot of people benefit from a top down approach, especially those who haven't already decided they want to heavily invest in the subject.
I think C doesn't have to be the first language you learn but I do think it should come fairly early, because otherwise you don't have an appreciation for a lot of the things the computer is actually doing when you're writing your code. Try explaining the concept of "stack vs heap" to someone who's only done python programming, for example.
My brother went through a coding bootcamp that focused on Python and JS and then he started to get into Golang on his own and one day he asked me what the point of pointers is. We ended down a rabbithole that kind of blew his mind. Stack vs heap, the structure of the call stack, manual memory management, etc.
It's the fundamental debate of "are you training to be a software engineer or a computer scientist?"
SWE's can get away without understanding many underlying concepts if they are going to be writing "business code", that is, handling strings, ints and interacting with databases and APIs.
Computer Scientists and those programming on embedded systems or designing systems/OS/theory themselves, need to delve into the math, algebra, and lower understandings of computers.
I think it's the other way around - computer scientists can get away without understanding the underlying hardware, and do their research based on a basic/abstract machine. Because they are doing research on computer science - how different algorithms can be improved or new data structures (or ML techniques etc).
Software engineers are more likely to need to know the underlying machine and write code suitable for such - because they need to write working/production ready code. It's like applied science, vs pure research science.
Yeah, I think the same. If I started today, I would love to being with python or even Java/Kotlin as it's better to show the good things about OOP.
C it's great to learn the barebones experience with memory, and as a lang that runs in everything.
The modern use I could see for C++ it's usually too specific for a random learner. I would only recommended for people who like to work in game engines, simulations, networking, embedded systems or migration of legacy systems, and other edge cases.
But for learning, I think it's better to learn with a modern lang, as you will be less distracted learning the quirks of vitange language, and use that time to learn in parallel a lot of concepts outside the lang, like algorithms, devops, soft skills with teams, prioritizing requirements, etc.
Out of curiosity, is there anything in particular that makes C++ preferable for simulations? I’ve been trying to get into the topic lately - for now I’ve stuck to python and Julia for the visualizations that are more familiar to me.
C++ is really nice for low-level OOP, and compared with C it adds generics and classes. Compared to Python, C++ is lower-level and can have significant performance gains with a well written program. With regard to Julia, if you write your code in "the right way", it is also compiled and low-level.
Makes sense, I can see some benefits in having more control of what happens with the memory, rather than trying to fit the model I have in mind into the datatypes python.
Found this post [0] fitting:
> The best thing you can do when dealing with lower-level languages like C and C++ is understand that things like lists, strings, integers, floating point numbers, objects, etc. do not actually exist. They are simply abstractions. There are only the CPU and memory.
Until teachers understand that learning programming and learning a programming language can actually be done separately, the debate will go on. There's this mindset that by teaching c early on you expose students to a whole range of useful concepts. That may be true, but you also distract them with useless language idiosyncrasies that have nothing to do with programming, strictly speaking.
I think starting with a language with static typing would be better. With Python or Javascript you still need to know how the types work otherwise you can run into unexpected "defined behavior". Something like Golang makes a fair compromise between C and Python: it is statically typed, compiled, and has a garbage collector.
I think the way Harvard's CS50 course approaches this is really good. It used to be entirely in C but in more recent years they start with C for the first few weeks and then move on to Python and expose you to a bunch of other tools as well.
The computer science classic of all time (by Knuth) uses an assembly language to teach analysis of algorithms. Using Python (or Scheme, for that matter, as is done in SICP) will only take you so far. C is a good middle ground.
Sure, and that distance is far enough for 95% of developers these days. If they feel the need to go even further, they could learn C at a later time. No need to scare possible developers away right off the bat.
A programmer should not be scared by the (still) most popular programming language. What's there to be scared by, anyway? For learning, C is just like Algol, very straightforward. Well, there's pointers: very useful for linked lists and such.
Assembly without registers is absolutely pointless since the only thing that matters in any flavor of assembly is how to get data into registers when you need it and then remove it before you override it.
The point isn’t to learn assembly, it’s to learn that all programs are just a series of instructions, operating in order, transforming memory. The loading and storing of registers is an implementation detail that’s not relevant in this context.
The advantage over C is having an even more limited instruction set and using descriptive names for each instruction.
They don't transform memory, they load memory into registers, transform the registers and (maybe) store the registers values back into the memory. The difference is profound and until you code in assembly you have no idea why (or that) string operations are so expensive.
Again, the point is not to have an real language for any efficient real world usage. The point is to have a simplified language that represents a series of commands operating on a bank of memory. Like this:
SET 1 100 # Set memory[1] = 100
SET 2 500 # Set memory[2] = 500
ADD 3 1 2 # Set memory[3] = memory[1] + memory[2]
It's easy to explain what each individual step is meant to do and you can build up to more complicated instructions. It allows children to see the persistent effects of running the program, mutating the state of the memory, eventually introducing the instruction counter itself as a state variable.
>eventually introducing the instruction counter itself as a state variable.
If you're going to be talking about the IP register than you need to talk about the IR register. So we should avoid talking about registers by talking about registers?
You're not selling this registerless assembly very well.
I suggest just starting with Python, learning C at some point because it’s universal, and never learning C++ without a specific reason.