Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The only really 'hard' thing I ever did in C was write an OS with interrupt handlers that passed control to user space.

Debugging that took me more time than I care to remember, I hung that box so often that I hooked the reset switch up to a foot pedal :)

Other than that C has been pretty good to me in terms of showing where the bugs are. Post mortem debugging would usually give you the location of your crash and that plus a little bit of deduction will tell you what you're doing wrong.

Memory overwrites (and stack overwrites) are things that belong to a certain phase of coding where you are still learning the ropes and you have not yet mastered the idiomatic solutions that people will use to avoid such problems. Setjmp and longjmp are also an excellent source of hard to find bugs, as well as multi-threading (the multi-threading problems are not unique to C, some languages are simply better at doing that sort of thing, occam for instance).

I've heard C compared to a race car, it's great as long as you stay between the lines, take a turn too fast and you're heading straight for trouble. Experience (as in bumping your head a couple of times) will make sure that you know how far you can push it.

C is like any other powertool (think chainsaw or plasmacutter), you can easily get hurt but once you've mastered the tool it is quite amazing what you can do with it.

I got in to C after a long period of writing almost nothing but assembly language (x86, 68K and a bunch of 8 bitters) and I remember thinking of C as a very 'high level language'. My perspective has changed a bit since then...



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: