Live data from Hacker News

Ask HN: Learning C

news.ycombinator.com

51–60 of 66 posts

Re: Ask HN: Learning C

#51

I learned C a while back, and don't regret the time spent doing so at all. This is how I'd recommend going about it: * Everyone is going to recommend K&R, which is fine. Find a copy of C Interfaces and Implementations as well--very good implementations with explanations of standard high-level structures. * Read source. SQLite's source, for example, is very well written and documented, and they actually have a version…

Hi avinashv, I'm interested to learn SQLite. I noticed you mention that there is a "recommended for reading" version of SQLite. Would you mind pointing out where I can find it? I browsed the website and haven't had any luck to find such information. Thanks!

Re: Ask HN: Learning C

#52
First, congratulations. You're making the right decision. Programmers who are ignorant of C leave certain roles and problem domains closed off to them. Even if your primary language is something else, not being afraid to roll up your sleeves and fix performance and correctness problems in the compilers and runtimes themselves makes you more valuable, more confident, and better able to reason about how the runtime will map your input to the machine. And proficiency with system-building languages and tools is a prerequisite if you ever aspire to be a "head surgeon," "10x programmer", "ninja", or whatever the heck the kids are calling it these days :).

K&R et al. are fine, but I'm a particular fan of two slightly oddball, but great, books about C:

1. van der Linden's Deep C Secrets. Short of implementing a C compiler yourself, reading this book is the surest path to completely understanding some aspects of the C linkage model, and the distinction between arrays and pointers. It's also entertainingly written, which always helps.

2. The Lions Book, an annotated source listing for the Unix v6 kernel. The subject matter is one of the most beautiful and influential programs ever written. This ~10k-line program is completely understandable in six weeks' study, a couple months' tops, yet it staked out almost all of the abstractions that still underly modern operating systems. It is also C's native environment: C was literally invented to write this program. And while it's dated in some of its peculiarities ("=+" where we'd write "+=", identifiers only being significant in the first 8 characters, no typedef yet, a lot more reliance on the register keyword, etc.), it's damned fine code, by any standard. Each page brims over with good, informed engineering trade-offs; the sweet spot may have shifted since the days of 128k core and 16-bit CPUs, but the thinking that goes into those trade-offs is mostly unchanged.

Re: Ask HN: Learning C

#53
I've only found two books on C worth the money. One is K&R, the other one (which I haven't seen mentioned here) is "The Standard C Library" by P.J. Plauger. It not only presents the ISO standard for the library, but Plauger's commentary on the standard, how to implement the standard C library, along with his implementation. It explains some of the murkier aspects of the C library, along with how to go about writing portable code.

Re: Ask HN: Learning C

#54
post #35

1. In Which I Join The Choir You should definitely learn C: * You'll learn the memory hierarchy, which is probably the most important thing to know about performant software. * You'll get 100x better at debugging --- both because you'll have practice, and because most of the tools you use to debug C code work for higher-level languages (gdb is still a better Ruby debugger than Ruby's own debugger). * You'll be able t…

I violently disagree with not learning assembly. Absolutely learn assembly. Just pick anything else other than x86 assembly. After learning the basics of assembly you will never have any trouble understanding pointers or any of the "hard" concepts in C.

x86 is a convoluted horror. A lot of it makes no sense except in the context of backwards compatibility, which the documentation won't necessarily point out. I highly recommend picking up a microcontroller to learn on instead of a microprocessor. Microcontrollers are mostly self-contained systems, while microprocessors are just a small piece of the picture and have complicated interfaces to the rest of the system components.

I recommend picking something in the Freescale 68HC* family. The addressing modes and instruction set are fairly clean and the architecture is simple. Something based on ARM would probably also be straightforward to learn. Don't worry about choosing a 32 bit chip, 8 or 16 bit is fine. 8 and 16 bit chips are typically simpler and will still teach you the important concepts.

Spend a couple of weeks on this and your understanding of C will be easier to come by and more thorough.

Re: Ask HN: Learning C

#55

Earlier quoted context omitted.

Indeed, the problem with C is just that. Once you understand how it works, you'll realize it's just a thin abstraction layer over assembly language. It really is just that simple. My last job was almost purely C, and what made C "scary" at times were: 1. naming conventions. I don't know why C programmers use the strange names that they do. 2. macros. C macros are a pain to read and follow. I hope things will be easie…

They use the strange names that they do because a function declared in C is declared everywhere in the whole program. They use strange names to try to stay out of your way; i. e. it would be really bad if two functions had the same name.

You're right that C's lack of namespaces makes for funky names. However, note that "static" functions are visible only within their compilation unit, which can bring some order to the madness.

Re: Ask HN: Learning C

#56
post #54
post #35

1. In Which I Join The Choir You should definitely learn C: * You'll learn the memory hierarchy, which is probably the most important thing to know about performant software. * You'll get 100x better at debugging --- both because you'll have practice, and because most of the tools you use to debug C code work for higher-level languages (gdb is still a better Ruby debugger than Ruby's own debugger). * You'll be able t…

I violently disagree with not learning assembly. Absolutely learn assembly. Just pick anything else other than x86 assembly. After learning the basics of assembly you will never have any trouble understanding pointers or any of the "hard" concepts in C. x86 is a convoluted horror. A lot of it makes no sense except in the context of backwards compatibility, which the documentation won't necessarily point out. I highly…

I'd steer away from the really small microcontrollers, as they tend to be register-starved (and/or memory-starved!) enough that you have to make ugly compromises, particularly in the area of call stacks. :(

ARM, PowerPC, and MIPS are all good choices if you've got appropriate hardware to play with. All three are nice, clean RISC architectures with plenty of registers and sane addressing modes.

Re: Ask HN: Learning C

#58
post #16

Chances are you already know C, but don't realize it. Java and PHP have mostly C syntax. All you have to do is substract objects and add pointers. Like rsheridan6 said, assembly helps. It's not necessary though, as long as you realize a pointer is actually a memory address and not something abstract like a reference in Java or PHP.

... and figure out how to deal with allocating and freeing things. Taken together, pointers, and manual memory management are a big chunk to bite off. The syntax isn't the problem, in other words.

For sake of argument: How often is the syntax the primary problem in learning a new language?

The examples that come to mind are Forth and APL/K/J (all of which I've only dabbled in), but the reason they have such unconventional syntaxes is because they're conceptually very different.

Re: Ask HN: Learning C

#59
post #54

Earlier quoted context omitted.

I violently disagree with not learning assembly. Absolutely learn assembly. Just pick anything else other than x86 assembly. After learning the basics of assembly you will never have any trouble understanding pointers or any of the "hard" concepts in C. x86 is a convoluted horror. A lot of it makes no sense except in the context of backwards compatibility, which the documentation won't necessarily point out. I highly…

I'd steer away from the really small microcontrollers, as they tend to be register-starved (and/or memory-starved!) enough that you have to make ugly compromises, particularly in the area of call stacks. :( ARM, PowerPC, and MIPS are all good choices if you've got appropriate hardware to play with. All three are nice, clean RISC architectures with plenty of registers and sane addressing modes.

Or try your luck at Core Wars. There you write programs in a simple assembler (Red Code) to fight against each other i.e. make your opponents execute an illegal op-code.

Re: Ask HN: Learning C

#60

Earlier quoted context omitted.

They use the strange names that they do because a function declared in C is declared everywhere in the whole program. They use strange names to try to stay out of your way; i. e. it would be really bad if two functions had the same name.

You're right that C's lack of namespaces makes for funky names. However, note that "static" functions are visible only within their compilation unit, which can bring some order to the madness.

Yes, exactly. And yet people continued to use the unhelpful, oblique prefixes and suffixes they used for global symbols nonetheless.
Post reply on HN