Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C for high level programmers (slides)

charliethe.ninja

Post reply on HN
Print view View original

111–120 of 129 posts

Re: C for high level programmers (slides)

#111

Post by Flimm »

benwaffle wrote: post #101
TheAceOfHearts wrote: post #27

I think the problem with learning C is that you need to learn stuff like make, autoconf, how the compiler + preprocessors work (what do all those flags even mean!?), how making "cross-platform" stuff works, how to pull in and use "libraries", C-isms, how to test, etc. C itself is a very small and simple language, but the tooling and patterns are old and mysterious. In college I learned how to program embedded systems…

21st century c http://shop.oreilly.com/product/0636920033677.do

I agree. I think tools like Valgrind and GCC debugger should really be introduced to the beginner from the get-go.

Re: C for high level programmers (slides)

#112

Post by bnolsen »

charlesL wrote: post #98
TheAceOfHearts wrote: post #27

I think the problem with learning C is that you need to learn stuff like make, autoconf, how the compiler + preprocessors work (what do all those flags even mean!?), how making "cross-platform" stuff works, how to pull in and use "libraries", C-isms, how to test, etc. C itself is a very small and simple language, but the tooling and patterns are old and mysterious. In college I learned how to program embedded systems…

Frankly, I don't use a lot of crazy libs or IDEs when writing C code. Most of my projects consist of one or two external libs and a few simple makefiles. I use Vim and clang/gcc for compiling and lldb/gdb for debugging. As for compiler flags, the only ones I ever worry about are `-O`, `-g`, `-c`, CFLAGS and LDFLAGS. What I've learned is that the way C includes other files/libs is extremely simple. The header files ar…

Adding -Wall would be a very good addition that would help with fixing a few things as well.

Re: C for high level programmers (slides)

#113

Post by bnolsen »

Flimm wrote: post #111
benwaffle wrote: post #101

Earlier quoted context omitted.

21st century c http://shop.oreilly.com/product/0636920033677.do

I agree. I think tools like Valgrind and GCC debugger should really be introduced to the beginner from the get-go.

unit tests are more effective than using a debugger. I use a debugger a couple times a month and unit tests with sprinkled asserts and debug prints in the code.

Re: C for high level programmers (slides)

#114

Post by GnarfGnarf »

gshrikant wrote: post #59

As someone who occasionally dabbles in C code, I am interested in knowing what is the modern take on `goto`s. I know they are "harmful" but I often come across code riddled with goto statements [1] and I personally feel that as long as it makes the code readable without significantly obfuscating the logic, goto is a perfectly fine way of doing things (although popular opinion and consideration for best practices have…

Never ever ever use goto's. If you have to use a goto, rewrite the code.

Re: C for high level programmers (slides)

#115

Post by eru »

kgabis wrote: post #93
eru wrote: post #68

C is a horrible language to write a compiler in. The other reasons for `Why you should learn C' are better, though.

Why? Compilation times are quite important, and writing a fast compiler is easier to achieve in C than in most other languages.

Premature optimization. Write correct first, profile then optimize later.

Re: C for high level programmers (slides)

#116

Post by iyn »

ndesaulniers wrote: post #82
TheAceOfHearts wrote: post #27

I think the problem with learning C is that you need to learn stuff like make, autoconf, how the compiler + preprocessors work (what do all those flags even mean!?), how making "cross-platform" stuff works, how to pull in and use "libraries", C-isms, how to test, etc. C itself is a very small and simple language, but the tooling and patterns are old and mysterious. In college I learned how to program embedded systems…

My recommendations (I've read a lot of C books), I think you can get away with just these two: * Head First C - David Griffiths * Expert C Programming: Deep C Secrets - Peter Van Der Linden

Thanks for recommendations.

BTW: just want to say that you have a fascinating blog! I've just spent last hour only skimming through some of the articles and bookmarking them for later. (Link for the lazy: https://nickdesaulniers.github.io/)

Re: C for high level programmers (slides)

#117

Post by nemo »

Sacho wrote: post #97
nemo wrote: post #95

Earlier quoted context omitted.

Compiled vs. interpreted is intended there to mean something a little different than runtime behaviors. Compiled - source files are run through a compiler which produce some output file that's then run. With C or Java you run the .c or .java file. C compiles to an executable, Java compiles to byte code. Interpreted - source is fed to an interpreter which typically turns it into some kind of representation that's imme…

I think the parent was correct. In your explanation you even state "an interpreter which typically...". You talk about compilers and interpreters, which aren't part of the language. The way you describe it, compiled or interpreted is a transitive property of a language, based on a popular way to utilize it. If the definitions are "inherently a little muddy", then they're not very useful. Javascript and compile-to-JS…

I think the slide was correct in expressing the idea it wanted to express using terms that are commonly used in the sense they used, while the parent was being pointlessly pedantic in wishing the terms had some strict sense that was the only true definition.

Sometimes terms do have very strict definitions that are only correctly used in a limited sense. In the case of compiled vs. interpreted that's not the way things are and criticizing an introductory doc. for not adhering to an arbitrarily selected strict definition is pedantic and counter-productive.

Re: C for high level programmers (slides)

#118

Post by clarry »

pjc50 wrote: post #107
charlesL wrote: post #100

Earlier quoted context omitted.

> Make is fairly easy to learn, at least in its basic form. Autoconf is horrendous. I completely agree. Make is extremely flexible on it's own. I don't understand the need to abstract the build system to generate thousand-line makefiles that are impossible to hand edit.

As benwaffle says in adjacent comment, make is the 80% solution that works most of the time. Autoconf is the 100% solution that's supposed to work everywhere , no matter how weird or long-dead your UNIX is. In order to do that it does a vast number of compatibility tests. The result is complex enough that simple substitution of makefiles doesn't quite cut it. Of course, that imposes the cost of 100% compatibility on…

> Autoconf is the 100% solution that's supposed to work everywhere

> Of course, that imposes the cost of 100% compatibility on every developer, when most would be happy to just build on today's Linux and call it a day.

The reality is that when you use programs built with autotools on systems that aren't mainstream, you'll have troubles. Because the scripts aren't right and were only tested by Linux developers on Linux.

And much of the time, I find it faster and easier to fix a broken makefile than to fix broken autohell.

Re: C for high level programmers (slides)

#120

Post by kgabis »

eru wrote: post #115
kgabis wrote: post #93

Earlier quoted context omitted.

Why? Compilation times are quite important, and writing a fast compiler is easier to achieve in C than in most other languages.

Premature optimization. Write correct first, profile then optimize later.

Why is writing a compiler in C a premature optimization? Ignoring performance is just bad approach to writing software. And "premature optimization" phrase is overused, even when it's not relevant to the discussion.
Post reply on HN