1. Contracts in C0 bake preconditions, post conditions, and loop invariants right into the language. Contracts are only checked when in "dynamic recompilation" mode (basically debug mode). This allows you to check the correctness of your code more easily (and, importantly, in an easily gradable way).
2. The language is designed in such a way to introduce C to programmers that are used to other higher level languages. In the C0 phase of the course we introduce students to fundamental concepts like memory allocation, code reasoning and contracts, binary representations of numbers, and unit testing. Next we transition to C1 (included in the C0 install) which introduces typedefs and other features of C. At this point we focus on introducing data structures. Finally we make the final transition to C, where we talk about undefined behavior, gcc, stack vs heap, etc.
I've taken this course myself, and I would argue that this measured approach to learning C is far superior to throwing students (most of whom have no low-level programming experience) straight into C.
I agree that C0 on its own is overly simplistic, but the way it is used at CMU is as 'C with training wheels' - strict type checking, no potentially-unsafe pointers to the stack, dynamic array bounds checking, etc. Then, two thirds into the semester, students transition to real C, and learn how to correctly manage those potential pitfalls.
This is how students at CMU have been learning C since 2010, and graduates don't seem to be any worse off for it.
[Citation needed]
> C is overly permissive of these things unless you introduce additional tooling, e.g. valgrind, which can become very overwhelming for intro-to-CS students who are still feeling lost.
Sure, but isn't the the POINT of college? To push you into unfamiliar territory? To force you out of your comfort zone, and then hand you the tools to learn something new?
It may just be my arrogence speaking, having already taught myself C. But I taught myself C, when I had to fix a bug, I taught myself asan, and valgrind. None of that was very overwhelming. Complicated, very. Confusing, occasionally. But Once I learned them, they became easy, and intuitive, and helpful.
I think the problem I have with your argument, is; when you apply it to math, the argument becomes painful.
You don't want to learn algebra, it' too complicated; lets learn this subset of algebra, without irrational or imaginary numbers.
The problem with c is that the advanced things get in the way of the basics. You get students asking why their if statements didn't work and to answer you need to teach them GDB and valgrind and different compiler flags and how the stack works. This is a recipe for students that don't end up learning either thing. And it slows everything down so in the end of the year you can't cover everything properly and end up with mediocre C programmers you would never trust near a real C codebase
---
Another thing to remember is that we should be very careful about that drill sergeant mentality that intro to CS should be hard and painful. This advantages students that had the opportunity to program before university and often ends up turning away women and other minorities from the field
Although I am kind of miffed by the last sentence, I admit I'm one of the people who programmed WAY before college but in my experience most CS majors who didn't simply didn't choose to do so, as opposed to having lacked the opportunity to do so; you're dismissing the thousands of hours spent coding as a child (more than most CS majors invest in programming during college...) without the internet or anyone to teach me anything as "opportunity"
I have an issue with someone dismissing thousands of hours of invested effort as "having an opportunity". And the same is of course true for someone who went to the library and learned first year math.
I would gladly hand over some C code to someone who's really interested in programming, but has only ever written python. I can't say the same about someone who's only known Java. So experience with C, isn't really a good bar to judge programmers by, not by itself anyways. You don't need to know how the stack works for most issues in C, and after you can make you stuff compile, without asking questions, is the time to learn about compiler flags.
So if that's the only argument for using an obscure/broken version of C, then it's a crap argument. If you've been doing CTF for years, the school needs to offer you CBE, not force you into a class where you'll only break the curve, and still be bored.
Also, I'd gladly turn away women and minorities both. If you're handed a problem you know has a solution, and you give up because it's hard. Your skin color or sex is irrelevant, if you're the type that gives up when it's hard; you're worthless as a programmer. (But that might just be my obsessive need to solve any problem I don't understand, so I might not be the best judge)
>[Citation needed]
https://www.cmu.edu/career/about-us/salaries_and_destination...
But, that's why we have dedicated classes that challenge you. This language is meant for a course to try to bring everyone to the same level. Some students enter the course having done CTF's since middle school and others just took the AP exam. C0 is used only for one course, and the course that follows it uses C in depth.
The concept of pointers is simple, but their implementation has all sorts of subtle layers:
- interactions and apparent fungibility between pointers, arrays and strings
- how about: ( * (void( * )())0)();
- what about: * (p++) vs ( * p)++ or "++ * p", "* p++" and "* ++p" (Quotes for display reasons only)
- & vs * and various combinations of these
- pointers to pointers
- pointers to arrays of strings
- pointers to allocated memory that is/are not in scope anymore.
- Null pointer
- Many others!
Two types of files, compiler directives, pointers, malloc and friends, are you really sure about that? Any non-trivial C program will use these, on TOP of the basic syntax that first timers have to learn.
There is a reason it is usually not taught as a first language, and Java, Python, C# or even Assembly are.
Java is taught a lot, not because it's better. But because once you learn Java, all you know how to do, is teach Java. Python is taught early because it's fun/easy, not because it's the best.
No one teaches ASM first anymore, what did you mean by saying asm is one of the first taught languages. (Maybe in some embedded systems, but generally that's not first, not by any reasonable definition.)
I think thd more accurate sentence would be "know exactly what the computer is doing". Lots of languages have clear and simple semantics that let you understand what your program will do. This is not the case for C though. The only way to understand what a C program does is to have a very complete mental model of the low level computer architecture, memory layouts, call stack organization and so on (aka knowing what the computer does). That is actually lot to go through for a first introductory course (hence why they are making a restricted language to teach before jumping to full C)
Python has similar arguments. It's a clean but powerful language that gets out of the way of learning basic programming, data structures, and such.
> But because once you learn Java, all you know how to do, is teach Java.
Why is that true for Java or Python, but not for other languages?
It's true about a lot of languages. But C isn't one of them. You can do a lot with C, you can do almost as much with with python and a lot faster as well. I can enumerate more, but those are the only two relevant ones.
With Java, you can get a job where job performance is measured in LOC.
At the very least, you want something with friendlier behavior in the face of errors than what C gives you.
In fact, C0 is explicitly targeted at computer scientists rather than engineers.
Why is that?
I've tried to explain pointers to people who struggle with the very small number of pointer-related concepts, and I ... fail.
But I don't know why I am failing. These are not stupid people - and I speak the English language well enough - so those aren't the reasons...