Live data from Hacker News

On becoming an expert C programmer

isthe.com

41–50 of 80 posts

Re: On becoming an expert C programmer

#41
post #12

There's nothing magic about learning C versus any other language. - Read an authoritative source (K&R is good; there are better ones) - Read a bunch of good code (I mostly read tools and kernel sources) - Write crappy code and get better Generally I want to write 10K lines of code in a new language before I probably don't suck at it. Varies on the language and paradigm, going to C++ from C took like five years (figur…

Before learning Haskell, try learning lisp through SICP. Haskell is wonderful but it's mostly (not really but bear with me) syntactic sugar over lazy application, which is explained in SICP (as opposed to eager evaluation used almost everywhere else). Syntactic sugar makes the whole thing appear like dark magic but it's not. It's a few minimalistic rules applied over and over (at both language and meta levels).

I've been programming (dabbling, to be honest) in LISP since about 1980, I've never shipped any products in it. I wrote a couple of toy interpreters in college (after reading Allan's Anatomy of LISP) and some small projects, but nothing massive.

I read SICP when it first came out and did most of the exercises. Yet Scheme was a terrible language to ship software in (commercial implementations were basically toys). I assume that Common LISP was a lot better, but the real packages were expensive.

I guess the real problem is that I didn't have cow-orkers who understood my obsession with LISP, nor did I work on any projects that I could really use it for. Could have switched companies, I suppose, but I liked working on operating systems . . .

Re: On becoming an expert C programmer

#42
post #41

Earlier quoted context omitted.

Before learning Haskell, try learning lisp through SICP. Haskell is wonderful but it's mostly (not really but bear with me) syntactic sugar over lazy application, which is explained in SICP (as opposed to eager evaluation used almost everywhere else). Syntactic sugar makes the whole thing appear like dark magic but it's not. It's a few minimalistic rules applied over and over (at both language and meta levels).

I've been programming (dabbling, to be honest) in LISP since about 1980, I've never shipped any products in it. I wrote a couple of toy interpreters in college (after reading Allan's Anatomy of LISP ) and some small projects, but nothing massive. I read SICP when it first came out and did most of the exercises. Yet Scheme was a terrible language to ship software in (commercial implementations were basically toys). I…

Aight, to each his own, a lot of Haskell mystery vanished when I saw it explained in terms of simpler languages (pattern matching, lazy evaluation, curryfication etc etc) but apparently that's not what's bothering you.

Re: On becoming an expert C programmer

#44
post #19

Earlier quoted context omitted.

"Not mentionned, about being an expert C programmer, is knowing the pitfalls of C, (cf. undefined behaviors)" I am an expert in C, I had been decades writing on it and other languages, and managing teams of coders. We created a company that used it a lot. I can't understand what undefined behaviors C has, because it is the most simple and defined language I do know of. I have lots of experience writing assembler,fort…

>If you understand how computers work it is extremely reliable bar none. On my processor, INT64_MAX + 1 will be INT64_MIN, a negative value. But the compiler is free to turn for (int64_t i = 1; i > 0; i++) { f(i); } into an infinite loop. Understanding how the computer works without reading about undefined behavior will make you fall into these kinds of traps.

[deleted]

Re: On becoming an expert C programmer

#45

Earlier quoted context omitted.

Id's Quake and Doom sources are a classic in this matter. I looked a bit at wsw, a fork of Quake 2. Now, my code is full of structs with function pointers. It's like I just internalized the more elaborate syntax and now it's all Hammers and Nails. I mean, function pointers to functions returning function pointers, for example. typedef int (*foo) (); foo * bar (); foo * p = bar; not rocket science, but ambiguous at fi…

http://ideone.com/ZOvq0n You probably meant this: http://ideone.com/wuZI2o

thanks. welp, I'm still learning

Re: On becoming an expert C programmer

#46
post #40

"DBell is one of the best programmers on the planet." How would one verify this? I tried a couple of his sample C programs. One of them was one source and one header file and compiled easily and quickly. A+. But then I looked at what the program did and realized I had written several iterations of the same utility myself years ago, using only the shell, sed, tr and ed or vi. I guess maybe his point of writing this in…

It would be good if you could mention precisely what programs have you tested and perhaps provide some links.

Re: On becoming an expert C programmer

#48

C is a cakewalk compared to C++ but a lot harder to do right, even when experienced, because of its more low level constructs

Sure. Climbing a mountain is a cakewalk compared to descending an erupting volcano as well.

The analogy being that C++ appears to make things simpler (descending) but the destination is filled with peril.

Re: On becoming an expert C programmer

#49
post #10

Whenever I've looked at an open source C programs, they go well beyond what I've learned in K&R. Learning C these days means mastering Make, autotools, macros, POSIX and Glib. Knowing these is the difference between your contrived linked-list example and creating software that can actually be deployed and is useful.

You make an excellent point. Perhaps more so than with other languages, getting to grips with making C actually useful relies a lot on quite extensive knowledge of the build environment.

You also have to know about how computers work, how they represent numbers, how and where they store memory, how computers process information, you have to know about interrupts low level os stuff, networking protocols, physical hardware limitations, debugging low level byzantine failures. You have to know a lot more than just C syntax. I haven't even mentioned computer science, best practices, working with others, architecture and UI topics.

Re: On becoming an expert C programmer

#50
post #10

Whenever I've looked at an open source C programs, they go well beyond what I've learned in K&R. Learning C these days means mastering Make, autotools, macros, POSIX and Glib. Knowing these is the difference between your contrived linked-list example and creating software that can actually be deployed and is useful.

You make an excellent point. Perhaps more so than with other languages, getting to grips with making C actually useful relies a lot on quite extensive knowledge of the build environment.

It's not only the build environment. Mastering C goes way beyond the superficial level of just learning the language and the libraries. Being a very thin abstraction over the machine, you will inevitably encounter some quirks which can only be explained from the perspective of a compiler writer or a hardware designer. Also, POSIX is not just another library, it's the interface between your program and the operating system. Knowing what to call and how to call it ultimately requires a good foundation in OS theory.
Post reply on HN