Note that [IMO] one of the main values of learning C in 2023 is that it's small and simple enough to learn the precise semantics of almost all of its parts.
Ask HN: Learn C in 2023?
141–150 of 220 posts
Re: Ask HN: Learn C in 2023?
#142Earlier quoted context omitted.
Don't bother with this stuff (or with "modern C") if you're just beginning to learn the language. You don't need it for small programs. No one is going to yell at you if your first effort isn't perfect. And no one is going to yell at you if you read the "wrong" book, or try things out in the "wrong" order. Pick any learning resource and get started now. You'll probably get distracted and move on to something else. Co…
Well C was my second language. I learned it on an amiga 500. But I quickly transitioned to a 386 (yes i know, a downgrade) but my dad put turbo c++ on it and I never wrote much ansi c after that. A bit for odd embedded targets, but mostly c++ my whole career. So I can write old fashioned c, and I don't start new projects in c, but writing c abi shims for c++ libraries or reading modern c is something I do with some f…
My comment is for the OP, not for you. Go nuts learning C tooling and have fun.
Re: Ask HN: Learn C in 2023?
#143Great language to learn data structures and algorithms. If you still like the language itself after going through a course like that, awesome.
Re: Ask HN: Learn C in 2023?
#144Earlier quoted context omitted.
This is incorrect on multiple levels: there is no organization that has "exclusive" control over Go, much less Rust. There's a company (Google) that made Go, but they have no control over the source code itself beyond the terms of the non-proprietary license they provide it under[1]. Even the things that Google does w/r/t Go are not even remotely controversial in the context of the definition of proprietary software,…
Your position that not having a standard is irrelevant for languages that don't have a standard is circular and bizarre. The fact that you keep focusing on whether compilers are proprietary instead of whether Rust and Go are proprietary is starting to seem deliberately evasive. You're free to extol the virtues of open source software, and I agree with you, but it's utterly beside the point. .rs is analogous to .doc.…
Where's the circularity? This is the claim: you can't claim that a nonexistent thing is proprietary. Rust and Go do not (to my knowledge) have any sort of standard other than the living standard of the reference implementation, which is itself not proprietary. Anybody is welcome to copy or modify that living standard, per the terms of the permissive license.
This is the overwhelmingly common state of affairs for programming languages: Python, PHP, Go, Rust, etc. do not have formal standards in the sense of C, but instead of a living standard in the form of their reference implementation. The reference implementation is permissively licensed, so the "standard," insofar as it can be said to exist, is also permissively licensed.
Edit: Again: this is just not what the definition of "proprietary" is, in the context of open source. There is a legitimate grievance that you're expressing about software standards and implementation diversity, but it has absolutely no bearing on whether the reference implementation is proprietary or not.
By analogy: I, an open source developer, create a new file format $FOO and release my reference implementation of a $FOO parser under a permissive software license. Am I somehow compelled to spend time writing a formal specification of $FOO to make it non-proprietary? It might be nice for me to do, and nothing stops anybody else from converting my living standard into a formal one, but I am absolutely not compelled to do it.
Re: Ask HN: Learn C in 2023?
#145Earlier quoted context omitted.
> or how to mitigate some of the security downfalls. I think I'd go further, there are places where it advocates downright unsafe practices. Eg. It's been a long time, but I thought I remember it introducing gets() unironically, without any caveat. For those that do not know, there is no safe use of that interface possible.
If you're just beginning with C, it doesn't matter. If anything, it's better to be exposed to these unsafe practices and make mistakes with them in the very safe environment of your own home, where absolutely no one cares what you're doing. K&R C is an excellent learning resource primarily because it's extremely strong pedagogically. Read K&R and then move onto something else later when you're done with it. If you ev…
C is one of those things that unless you have proper testing, tooling and linting you don't know if you code is incorrect. It may have subtle memory bugs, rely on undefined behavior or crumple in exploitable ways under bad input. Having a feedback loop is really important in learning and improving. Undefined behavior helps subvert it.
For the exact example of above, how would a developer learn not to use gets? The best place would be a section on red flags in API design in the book. If you don't have that you need to find it through experience. Lints, fuzzing, sanitizers can help, but once again, none of this is covered in K&R. Some of it just didn't exist at the time or if it did, it was very primitive compared to what we have today.
Developers could pick up bad habits and be productive for years with them before they get bit by them. I know I did. I look back at some of the practices I picked up when first learning and cringe a bit. Especially since I think a fair amount of that code is still in production.
Re: Ask HN: Learn C in 2023?
#146A main issue with learning C is getting the architecture right (header and source files), and figuring out the tooling for compiling and debugging and building (gcc and gdb and make/cmake for example). I like C in a Nutshell 2nd ed (Prinz/Crawford) 2016 as a reference for any questions about that: https://www.oreilly.com/library/view/c-in-a/9781491924174/ As far as code examples, I find there's a lot of simple C grap…
I've been using GPT this way. "Write the header file for a function that does X." Now write the implementation. Does a great job when prompted with a header file.
Re: Ask HN: Learn C in 2023?
#147Earlier quoted context omitted.
Not exactly your question, but valgrind is an amazing tool. It does execution-time analysis of your code and provides an in-depth report on memory usage. It will find and report memory leaks, use of uninitialized variables, bad memory references, etc. I love programming in C, but there are a lot of ways to corrupt memory, get segfaults, etc. valgrind is a useful and powerful way to guard against many of these kinds o…
I haven't used valgrind in years, more used to asan, but I've been told it can do things asan can't? Edit: to stretch the metaphor, modern c++ is like a thick rubber pad on the bed of nails, but often on the job you are hot bunking and you don't know which c++ your predecessor used to make the bed... Or you are in a hurry and you aren't sure which one you grabbed.
If you're used to ASAN, think of Valgrind like ASAN, TSAN, MSAN, and UBSAN all at once at the same time, and then has other facilities like profiling.
In any situation where I have control of how the code is built, I personally prefer to run those various SANs instead of Valgrind, usually three parallel builds: one with -fsanitize=address,integer,undefined, one -fsanitize=thread if more than one thread is involved in the project, and one -fsanitize=memory too if Linux is available. That gets you almost all the benefits of Valgrind faster than Valgrind.
But Valgrind is still an exceptionally powerful tool to learn and use. Its chief advantage to me is to be able to work with an unmodified binary. Its chief downside is it can be slow, and occasionally you may run into issues with support for more obscure instructions like vcvtps2ph.
MSAN is really the star of the sanitizer world, and is worth spinning up a Linux VM for. It tracks the initialized-ness of all your data and catches any use (really, branch) on anything uninitialized. I like to think of ASAN as "did I get my pointers right?" and MSAN as "did I get everything else right?".
If you're not familiar with integer sanitizer, it's like UBSAN except it checks for things that are often mistakes rather than things that are actually undefined. The most common situation I've found is code that's hashing data will often pop up a warning about unsigned integer overflow, which I choose to suppress as finely grained as possible with something like __attribute__((no_sanitize("unsigned-integer-overflow", "unsigned-shift-base"))). That way you can still find unintentional unsigned integer problems (e.g. with size_t).
Re: Ask HN: Learn C in 2023?
#148Note that [IMO] one of the main values of learning C in 2023 is that it's small and simple enough to learn the precise semantics of almost all of its parts.
The 2018 ISO standard [1] is 520 pages. Not what I would consider small. Nor is it simple. The integer promotion rules and undefined behaviours will trip up even experienced C programmers.
Something like R5RS for Scheme (50 pages or so) is what I think of when I hear small and simple.
Re: Ask HN: Learn C in 2023?
#149I'm not a C engineer, but I think I have an interesting recommendation to consider. Since you are already familiar with other languages, you obviously don't need to know the basics of C. The basics are the same everywhere. Instead, you'd likely want to build that mindset on how to build good software with C. I suggest you read other people's code and try to deep dive into the whys. I heard Redis is a well-written sof…
Fully agree with the principle but maybe let's not call Redis "well-written" :)
Redis is a great piece of software because of how much it impacted the "evolution" of Internet not because of the code quality, Redis's code resemble spaghetti code, a lot.
I will push myself and say that nowadays people would get fired for writing code like that!
And before someone start to throw stones (just for the sake of it), here a few examples: - Redis source code is FULL of GIANT files with thousands and thousands of lines of code, decoupling and separation of concerns are basic things! A few examples -- https://github.com/redis/redis/blob/unstable/src/module.c -- https://github.com/redis/redis/blob/unstable/src/cluster.c -- https://github.com/redis/redis/blob/unstable/src/redis-cli.c -- https://github.com/redis/redis/blob/unstable/src/networking....
- talking about auto generated, the repo contains commited auto generated code, a valid reason though really slips my mind (yes, of course I can think of a few, but ... really? :)))
- https://github.com/redis/redis/blob/9c7c6924a019b902996fc4b6... ... that struct feels like an "Italian minestrone", basically a kind of soup where you throw in, literally, all the vegetables you have around and it's great for a soup, a bit less for software engineering though :)
- the naming structure is a bit random at times, there is a mix of camel case, camel case mixed with underscores from time to time, pascal case
This kind of staff might be alright for a 0.3 or 0.4, maybe even for a 1.0, definitely not for a 7.x that has had 15 years to evolve :/ Even in cachegrand, that hasn't got to a v0.2 yet, I tried to avoid these kinda of dramas, in C is quick and easy to get there if you are not careful.
There are plenty of other small things but most of the big dramas should be there.
Re: Ask HN: Learn C in 2023?
#150I like firearms as an analogy here. Rust is like a modern rifle, unloaded, with six safeties and three locked triggers in a gun safe. The ammunition will harmlessly self-destruct if you don’t focus properly before firing. C is sort of like Rust except the rifle is on the couch, loaded, one in the chamber, all the safeties are off, the numerous open triggers are held by RNGs, and the business end is pointed right at y…
This analogy is really more like dogmatic Rustacean-ism than actual truth. Rust has it's merits. However, it's a tired language. It doesn't maintain very good stability due to it's ever-evolving compiler which makes it almost unusable in anything but a "move fast and break things" environment. It's too particular, making development a burden and interrupting flow. Most importantly, the community is absolutely exhaust…
I don’t even prefer Rust to C personally, and I’m not a dogmatic sort. My analogy wasn’t particularly complimentary to either language.
If some people are too sensitive to take a little caricaturization of C in stride, maybe those people should examine those sensitivities.
Edit because I didn’t read your comment all the way through: uninitialized memory is RNG, functionally.