As great as this looks, I think it should heavily emphasize moving on to using GCC (or maybe LLVM).
I learned C in the mid nineties using a copy of Visual C++ 1.0 that a friend had gotten from his father (and probably he got it from work). It was the only compiler I knew of and once I was ready to move beyond toy programs, I was seriously hampered by the fact that this compiler couldn't produce text mode executables (any call to printf opened its own new window that definitely wasn't cmd.exe) and it couldn't set the graphics mode for blitting pixels. It was heavily oriented around this new fangled MFC thing but I was a teenager so I wanted to program games not business apps or whatever. That meant I wanted text mode or graphics mode.
My high school CS class had Borland C++ and I could set mode 0x13 with that in DOS. But I had no way of obtaining this compiler as a kid. And it probably didn't work on Windows 95 anyway.
Anyways, it wasn't until the early 2000s that I finally learned about GCC, a free as in beer and freedom compiler and the simplicity of it would have been amazing for learning.. If only I had known.
But as mesmerized as I was by C++ at the time, Borland Pascal was a lot more fun to play around with. I remember unsuccessfully trying to wrap my head around the different kinds of pointers, and the humble beginnings of std.
Same here. Highschool programming class was a lot of fun, learning all the basics for the first time, but I too thought the first step of being a programmer was to obtain a Microsoft product.
Probably same years… whenever we got a new computer I was removing OS shipped and installing a previous MS OS. Win3.1? Nah I want DOS, win95 nah… I want 3.1. That’s where my tools were.
funny how much the tools you first get comfortable with shape everything after. even today, setting up a simple clean c environment is way harder than it should be for beginners. tutorials like this help, but eventually pointing people toward gcc or clang early on makes a huge difference long term.
Skimming through the pages, there is some things that aren't really accurate.
> Integers - whole numbers which can be either positive or negative. Defined using char, int, short, long or long long
char is either signed or unsigned depending on the platform/implementation. Use signed char if you want signed integers.
Telling people who are new to C to define booleans with macros is not a good idea, as they have had a proper implementation since c99.
It also feels weird to treat structs and pointers as advanced topics. They are basically required to be productive in the language.
stdint.h was introduced in c99, not c11.
Explaining bitwise operators as "bitmasks" is also quite weird. Bitmasking is just one of the few things you can do with them.
> In C, functions must be first defined before they are used in the code. They can be either declared first and then implemented later on using a header file or in the beginning of the C file, or they can be implemented in the order they are used (less preferable).
This paragraph reads weird. I haven't found any place where the tutorial mentions how to properly write header files. It might be because of the interactive part, but if that is the case then this tutorial doesn't really teach you how to program in C because the tooling around it is an important part of actually using the language.
It is also fairly common to declare functions in order of use. Discouraging that is like telling people they need to use tabs over spaces instead of actually focussing on language semantics.
Ironic that you've drawn the eye to the thing that needs to be front and center of any C tutorial, and also the thing that makes C so tricky to work with.
When somebody says "This program is written in C", my initial thought is "Which C?". There is no one, single C.
I don't write C daily. Heck, I don't write it monthly any more. And so my grey cells are struggling with which versions introduced what, and you've spotted something I would have missed on a first read.
And this is a problem.
Can you list all the undefined behaviours, and which language features came into which version across ANSI, C99, C11, C17 and C23? The last one feels a little brighter in my mind, but I definitely can't, and if I was writing a C tutorial - like many that have been written - I'd probably be explicit about choosing a version and sticking with it, and good luck and godspeed to everything outside that version.
Of course this is one of the reasons learning C is harder than other languages, and why languages like Zig and Odin have a decent chance: ergonomically simpler than Rust, all the power and flexibility, (much) less of the head scratching.
I think you will always have this sort of thing for anything that's primarily driven by a standard (e.g. C, but also most web stuff) versus anything that's primarily driven by one specific implementation (most other languages).
Things are a lot better today than they used to be though: compilers that don't support modern features are rarer, and the compilers give much better errors on things like UD.
What is wrong with versioning a language like c89, c99 etc.? I think it is a lot easier to keep track of the 7 versions of C than the 14 that are available for zig and the however many there are for rust.
I do agree that some of the UB is a problem though.
This is mostly an issue with MSVC which refuses to become compliant with c99 standard. Their support for c11 and c17 also has some gaps around features that were introduced in c99.
You could also just use the newest C standard. I would personally trust that C23 code written today still works in ten years and still has excelelnt support in compilers a lot more than that this is the case for any code written in Zig, Odin, or Rust.
Ah, but then you have potential interop and portability issues. C11 isn't yet universally adopted, and there are some dark corners out there where even ANSI (C89/C90) is not quite embraced and original K&R is holding out.
I think the jury is out on Zig and Odin (but I like Zig a lot, in particular), but I feel Rust has hit a tipping point - like Go, Python and Java - where there's too much production code out there for it to disappear in the next ten years.
If you were to ask me about languages where that might not be the case in ten years, I'd point to where usage is not very production oriented (R, Julia), or where people have had a good try and decided they want to pull back investment (anecdotally, Ruby and Scala seem to be on that curve right now).
Nothing really disappears, the question is how strong the ecosystem is in ten years and how good the support for the code you write today. Rust will not go away but I doubt that the code written today still works without hassle or that all the 1000 crates it depends on still exist. That there are dark corners using C89 or K&R is not a weakness, it demonstrates how strong the C ecosystem is. If you write something in Zig or Rust now, you need to realize that in 10 years it might also be considered ugly legacy code, even if you think it is shiny modern code today. The question is then if it is as easy as using "gcc -std=c89" to work with it.
C is a great language to learn if you want understand the fundamentals of computer. Personally, C was on of the first language that I learned, and until today help me if I want to learn a new language!
I'd say it's a bit crufty/quirky. Zig seems to be a good modern alternative. Basically a very similar language in the core, with a much more pleasant syntax.
Wondering how long it will take before Linux can be ported to Zig by LLMs. Supposedly subset of it already builds with the Zig compiler (which also compiles C), with some minimal adjustments.
Interactive tutorials are great for lowering the entry barrier, but technical accuracy is crucial for beginners. It's suggested to stick to a single C standard (like C99), properly cover essential topics like structs and pointers, and prefer _Bool over macros for booleans. Overall, the effort is appreciated.
I need to brush up on C for my dissertation. How does this compare to Head First C?
I read the first chapter of that book and loved it! Very unlike other books on C which dedicate an entire chapter to `for` loop for instance. How do other programmers even read a book like that? Isn't it tiring to read through how a `for` loop works for the 70th time.
Had a bunch of inconsistencies last time i checked. Not quite comprehensive nor does it have much clarity. I also could hardly see when I disabled my ad block momentarily.
Moral of the story: books are better for learning when it comes to C.
The issue I always find with these tutorials that they never seem explain the finer details.
On the Array Page:
/* print the 7th number from the array, which has an index of 6 */
printf("The 7th number in the array is %d", numbers[6]);
There is no mention of what %d is or does. Once you know, it's fine, it's the display placeholder for the variable but that's what throws me off on tutorials.
Good luck to the author with the tutorial. I'm really beginning to accept that despite all of the new languages, like Rust and Zig being available, they won't be able to displace C for the next couple of decades at least. A good programmer will need to learn all the techniques for working with C code safely, efficiently and reliably, with all the inconveniences that implies.
Most older C developers I've spoken to find Go and Python as a fresh breath of air and refuse to head back.
The younger generations totally sideline C completely.
Myself a non-coder but experienced SysAdmin who can write cool Perl, TCL scripts, C almost feels almost natural when reading it. I just haven't had the time available to dive in.
It could be that I was exposed to it at 14 (2003) but chose perl because MSN/Y!M/AOL messenger bots were the discord bots of today. Still, eager to dive in. Some reason Java too.
We should call things free software if they're free software and open source if they're not. Also, what's this cookie consent dialog about? Are those 999 business partners open source?
As great as this looks, I think it should heavily emphasize moving on to using GCC (or maybe LLVM).
I learned C in the mid nineties using a copy of Visual C++ 1.0 that a friend had gotten from his father (and probably he got it from work). It was the only compiler I knew of and once I was ready to move beyond toy programs, I was seriously hampered by the fact that this compiler couldn't produce text mode executables (any call to printf opened its own new window that definitely wasn't cmd.exe) and it couldn't set the graphics mode for blitting pixels. It was heavily oriented around this new fangled MFC thing but I was a teenager so I wanted to program games not business apps or whatever. That meant I wanted text mode or graphics mode.
My high school CS class had Borland C++ and I could set mode 0x13 with that in DOS. But I had no way of obtaining this compiler as a kid. And it probably didn't work on Windows 95 anyway.
Anyways, it wasn't until the early 2000s that I finally learned about GCC, a free as in beer and freedom compiler and the simplicity of it would have been amazing for learning.. If only I had known.
I stole my copy of Borland C++ from school.
But as mesmerized as I was by C++ at the time, Borland Pascal was a lot more fun to play around with. I remember unsuccessfully trying to wrap my head around the different kinds of pointers, and the humble beginnings of std.
Same here. Highschool programming class was a lot of fun, learning all the basics for the first time, but I too thought the first step of being a programmer was to obtain a Microsoft product.
Probably same years… whenever we got a new computer I was removing OS shipped and installing a previous MS OS. Win3.1? Nah I want DOS, win95 nah… I want 3.1. That’s where my tools were.
Funny thing I still use win10.
funny how much the tools you first get comfortable with shape everything after. even today, setting up a simple clean c environment is way harder than it should be for beginners. tutorials like this help, but eventually pointing people toward gcc or clang early on makes a huge difference long term.
Saw this mentioned in a HN comment and thought it deserved more attention: https://news.ycombinator.com/item?id=34106174
Skimming through the pages, there is some things that aren't really accurate.
> Integers - whole numbers which can be either positive or negative. Defined using char, int, short, long or long long
char is either signed or unsigned depending on the platform/implementation. Use signed char if you want signed integers.
Telling people who are new to C to define booleans with macros is not a good idea, as they have had a proper implementation since c99.
It also feels weird to treat structs and pointers as advanced topics. They are basically required to be productive in the language.
stdint.h was introduced in c99, not c11.
Explaining bitwise operators as "bitmasks" is also quite weird. Bitmasking is just one of the few things you can do with them.
> In C, functions must be first defined before they are used in the code. They can be either declared first and then implemented later on using a header file or in the beginning of the C file, or they can be implemented in the order they are used (less preferable).
This paragraph reads weird. I haven't found any place where the tutorial mentions how to properly write header files. It might be because of the interactive part, but if that is the case then this tutorial doesn't really teach you how to program in C because the tooling around it is an important part of actually using the language. It is also fairly common to declare functions in order of use. Discouraging that is like telling people they need to use tabs over spaces instead of actually focussing on language semantics.
> Defined using char, int, short, long or long long
> Note that C does not have a boolean type
`_Bool` and `long long` are both introduced in C99, this is mixed up info.
Edit: probably tailor-made for old MSVC, which didn't support _Bool until VS2013.
Ironic that you've drawn the eye to the thing that needs to be front and center of any C tutorial, and also the thing that makes C so tricky to work with.
When somebody says "This program is written in C", my initial thought is "Which C?". There is no one, single C.
I don't write C daily. Heck, I don't write it monthly any more. And so my grey cells are struggling with which versions introduced what, and you've spotted something I would have missed on a first read.
And this is a problem.
Can you list all the undefined behaviours, and which language features came into which version across ANSI, C99, C11, C17 and C23? The last one feels a little brighter in my mind, but I definitely can't, and if I was writing a C tutorial - like many that have been written - I'd probably be explicit about choosing a version and sticking with it, and good luck and godspeed to everything outside that version.
Of course this is one of the reasons learning C is harder than other languages, and why languages like Zig and Odin have a decent chance: ergonomically simpler than Rust, all the power and flexibility, (much) less of the head scratching.
I think you will always have this sort of thing for anything that's primarily driven by a standard (e.g. C, but also most web stuff) versus anything that's primarily driven by one specific implementation (most other languages).
Things are a lot better today than they used to be though: compilers that don't support modern features are rarer, and the compilers give much better errors on things like UD.
Because Zig et al won't have future versions with new features?
Sure, but C predates semantic versioning and is rammed with undefined behaviour that a lot of people depend on.
Modern languages - even those that have high levels of C interop like Zig - can (and do) avoid those problems.
What is wrong with versioning a language like c89, c99 etc.? I think it is a lot easier to keep track of the 7 versions of C than the 14 that are available for zig and the however many there are for rust.
I do agree that some of the UB is a problem though.
The problem (as mentioned above) is that c99 is not the same everywhere.
This is mostly an issue with MSVC which refuses to become compliant with c99 standard. Their support for c11 and c17 also has some gaps around features that were introduced in c99.
Of course. But they are starting with 40 years less baggage. And can reasonably assume a modern hardware architecture, for example.
You could also just use the newest C standard. I would personally trust that C23 code written today still works in ten years and still has excelelnt support in compilers a lot more than that this is the case for any code written in Zig, Odin, or Rust.
Ah, but then you have potential interop and portability issues. C11 isn't yet universally adopted, and there are some dark corners out there where even ANSI (C89/C90) is not quite embraced and original K&R is holding out.
I think the jury is out on Zig and Odin (but I like Zig a lot, in particular), but I feel Rust has hit a tipping point - like Go, Python and Java - where there's too much production code out there for it to disappear in the next ten years.
If you were to ask me about languages where that might not be the case in ten years, I'd point to where usage is not very production oriented (R, Julia), or where people have had a good try and decided they want to pull back investment (anecdotally, Ruby and Scala seem to be on that curve right now).
Nothing really disappears, the question is how strong the ecosystem is in ten years and how good the support for the code you write today. Rust will not go away but I doubt that the code written today still works without hassle or that all the 1000 crates it depends on still exist. That there are dark corners using C89 or K&R is not a weakness, it demonstrates how strong the C ecosystem is. If you write something in Zig or Rust now, you need to realize that in 10 years it might also be considered ugly legacy code, even if you think it is shiny modern code today. The question is then if it is as easy as using "gcc -std=c89" to work with it.
A piece of anecdata: my Rust code from 8 years ago still compiles fine, though compiler complains about not having the defined edition set.
News such as this one do not build confidence though: https://internals.rust-lang.org/t/type-inference-breakage-in...
Ah. Apparently I didn’t use that crate, so happily missed that footgun, thanks for the info! That is an unfortunate case.
Though I suspect it’s fair to say the entire settlement is built of glass houses here :-)
https://news.ycombinator.com/item?id=43798312
I suppose if one wants absolutely no surprises, they will need to lock the entire toolchain as well, regardless of the language…
Maybe, but this GCC change would affect only code that is already broken and then there is even a compiler flag to fix it.
C is a great language to learn if you want understand the fundamentals of computer. Personally, C was on of the first language that I learned, and until today help me if I want to learn a new language!
I loved the interactive tutorial!!!
I'd say it's a bit crufty/quirky. Zig seems to be a good modern alternative. Basically a very similar language in the core, with a much more pleasant syntax.
Wondering how long it will take before Linux can be ported to Zig by LLMs. Supposedly subset of it already builds with the Zig compiler (which also compiles C), with some minimal adjustments.
The more, the merrier, here is another one I've been working on lately:
https://github.com/codr7/hacktical-c
When I see a page filled with junky ads like that, I instantly close it. On mobile especially, it’s unusable.
I’m amazed something like this gets traction here.
Most of the users of this website probably run ad blockers, thus the traction. Bu I agree.
I didn't see any ads. Thanks for letting me know
Interactive tutorials are great for lowering the entry barrier, but technical accuracy is crucial for beginners. It's suggested to stick to a single C standard (like C99), properly cover essential topics like structs and pointers, and prefer _Bool over macros for booleans. Overall, the effort is appreciated.
I need to brush up on C for my dissertation. How does this compare to Head First C?
I read the first chapter of that book and loved it! Very unlike other books on C which dedicate an entire chapter to `for` loop for instance. How do other programmers even read a book like that? Isn't it tiring to read through how a `for` loop works for the 70th time.
Had a bunch of inconsistencies last time i checked. Not quite comprehensive nor does it have much clarity. I also could hardly see when I disabled my ad block momentarily.
Moral of the story: books are better for learning when it comes to C.
Unbearable with ads all around.
Surprising that there are still people without ad-blockers. Just install uBlock Origin.
The interactive editor seems to only use a quarter of the screen space and isn't resizable. Quite vexing to use.
They host lots of other languages as I see. https://www.learnshell.org/ https://www.learnjavaonline.org/ ...
The issue I always find with these tutorials that they never seem explain the finer details.
On the Array Page:
/* print the 7th number from the array, which has an index of 6 */
printf("The 7th number in the array is %d", numbers[6]);
There is no mention of what %d is or does. Once you know, it's fine, it's the display placeholder for the variable but that's what throws me off on tutorials.
Good luck to the author with the tutorial. I'm really beginning to accept that despite all of the new languages, like Rust and Zig being available, they won't be able to displace C for the next couple of decades at least. A good programmer will need to learn all the techniques for working with C code safely, efficiently and reliably, with all the inconveniences that implies.
Most older C developers I've spoken to find Go and Python as a fresh breath of air and refuse to head back.
The younger generations totally sideline C completely.
Myself a non-coder but experienced SysAdmin who can write cool Perl, TCL scripts, C almost feels almost natural when reading it. I just haven't had the time available to dive in.
It could be that I was exposed to it at 14 (2003) but chose perl because MSN/Y!M/AOL messenger bots were the discord bots of today. Still, eager to dive in. Some reason Java too.
We need more resources like this. Thank you.
[flagged]
no thanks
We should call things free software if they're free software and open source if they're not. Also, what's this cookie consent dialog about? Are those 999 business partners open source?