Notes on Programming in C (1989)
doc.cat-v.org
doc.cat-v.org
This is my favorite sentence. He's hinting at functional programming!
> I tend to err on the side of eliminating comments. [...] A misleading comment can be very confusing.
I can't even keep track of how many times I've tried to read code and comments I wrote from more than 6 months ago, and thought to myself "this doesn't make sense" or "how can this possibly work?" Or "this is impenetrable, I wish the idiot who wrote this would have used a little self-constraint and tried to simplify rather than show off and make everything complicated."
I'm getting more and more aware every year of how insanely hard it is to write or say things that are both clear and unambiguous. Every time I think I'm being clear and unambiguous, I find out later I was neither by a mile.
> Fancy algorithms are slow when n is small, and n is usually small.
I learned this fairly well working in games, where it's frequently faster to do a linear search or to use a linked list. The really basic stuff I was taught to avoid in school. But even now I have a hard time not using a hash table or tree or something at first, even when I know the data set will probably be small.
The biggest (perhaps the only) way that C was actually ahead of its time was its support for "functional" programming: pass-by-value, higher-order functions,[1] macros[2] and even having functions at all.[3]
[1] 40 years before Java, and before any other mainstream non-Lisp.[1b]
[1b] Algol 68 supported function pointers first, but it was, famously, too ahead-of-its-time to implement. Pascal had limited support for function parameters but didn't support returning them or specifying their parameter types or arity.
[2] An advanced feature for the time.
[3] Fortran, Cobol, PL/I, etc still only supported procedures, which were themselves considered a somewhat advanced feature at the time.
To be a bit of a quibbler, a dynamic array is almost always going to be faster than a linked list, especially when N is small, and unless you're writing C (or, for somewhat different reasons, a FP lang) the code will be simpler too.
But of course, with small Ns, outside of the tightest of inner loops or the most resource-constrained embedded targets, most any halfway-reasonable data structure is going to be (and has been for 20+ years) easily fast enough. So it is a bit of a tomato tomahto thing.
Nope, you're assuming that you're allocating in order to create the list. That's not always the case! :) It's very common in games and embedded systems to have the nodes in memory, pre-allocated, pre-loaded, baked into executable or game data, etc. If space for list pointers is baked in advance, you can use linked lists without the separate allocation costs of a dynamic array or other container class.
Also, a dynamic array can be slower than a linked list because you realloc larger chunks than 1 node. You pay larger costs for larger allocations, and it can also cause more fragmentation in a custom size-pooled allocator.
It's also common to forget that a dynamic array of pointers is two allocations per node (one of them potentially amortized... except for small N). It's a single allocation if you're storing the node struct directly in the array. But that's less common than people creating a dynamic array of pointers.
I guess I'm an outlier-- while I have read misleading/wrong comments in C code, I can't think of a single time where I've had my time significantly wasted by a misleading comment in C code.
I can think of several times where I've been slapped by a wrongly named function. Oops, turns out "check_width" doesn't merely return an int but instead mutates something deep in the bowels of the program.
This never occured to me, but makes perfect sense, I usually know what I want a function to return, no need to make the name more generic than it needs to be.
I both agree and disagree with this... C is a small language, and it shouldn't take a huge amount of time to parse the source code to find out what's going on if variables / function names are self-documenting etc.
However, if you're dealing with a large code base and trying to track down where a variable is declared (and subsequently defined) for the purposes of maintenance or updating legacy code, comments hinting the what the structure underneath that label represents are incredibly useful (and more importantly, time and energy saving)
I generally comment when I'm doing something really goofy because the 'obvious' method has some subtle flaw. A documentation for the next guy (who has a chance of being me, having forgotten some of the context six months form now) as a "I know you want to refactor this, but it's more complex than you think" warning.
I'm just scared at what's coming down the pike that makes Javascript a "low level language."
I think that this might be an early hint at Go's interface system and its lack of of "complete" OOP support.
edit-001: this was previously discussed here as well. ref: https://news.ycombinator.com/item?id=9018247
I never understood the phrase compiled language in the context of C and also in general. C interpreters exist. I happen to have an official copy of the ISO/IEC 9899:1999 standard. The word "compiler" appears only once in a footnote. Other languages have both compilers and interpreters (e.g. Common Lisp, OCaml).
* The semantics is simple. For instance, local variables vaporize when a block terminates; compiling a lexical scope in C means not even having to know what "closure" means, and thus not having to deal with a whole class of code generation problems like treating optimizing trivial closures, and non-escaping ones.
* A correct binary call to a C function can be generated if we just parse and analyze a simple prototype declaration. Very little information is needed to generate the calls to functions in a separately compiled file.
* The declaration of any complete data type specifies how it is laid out in memory and accessed.
* In general, anything which would make compiling difficult is either off limits to the programmer entirely, or "undefined behavior". For instance, functions aren't objects and cannot be manipulated at run time in any portable way. There are almost no introspective features whatsoever. A C interpreter can easily have all sorts of introspection features as extensions, but those are kept out of the language because they would interfere with the concept of it being a "compiled language".
* The type system is static and supports type erasure: most C implementations throw away all type info (except as part of "debug info") when translating C programs. No requirement in the standard requires any type info to be retained. Even though anything can be interpreted, static typing with erasure tends to make languages geared toward compiling.
IIRC those tools (of which similar ones exist for Java, Python, Ruby, Node.js, Lua and so on) just package together the sources (precompiled to bytecode) and an instance of the Perl[5] interpreter.
$ cat FortyTwo.java
public class FortyTwo
{
public static int fortytwo(int x) {
return x + 42;
}
}
$ gcj-4.9 -c FortyTwo.java
FortyTwo.o: file format elf64-x86-64
Disassembly of section .text:
<snip>
0000000000000022 <_ZN8FortyTwo8fortytwoEJii>:
{
public static int fortytwo(int x) {
return x + 42;
22: 55 push %rbp
23: 48 89 e5 mov %rsp,%rbp
26: 48 83 ec 20 sub $0x20,%rsp
2a: 89 7d ec mov %edi,-0x14(%rbp)
2d: b8 00 00 00 00 mov $0x0,%eax
32: 48 89 c7 mov %rax,%rdi
35: b8 00 00 00 00 mov $0x0,%eax
3a: e8 00 00 00 00 callq 3f <_ZN8FortyTwo8fortytwoEJii+0x1d>
3f: 8b 45 ec mov -0x14(%rbp),%eax
42: 89 45 fc mov %eax,-0x4(%rbp)
45: 8b 45 fc mov -0x4(%rbp),%eax
48: ba 2a 00 00 00 mov $0x2a,%edx
4d: 01 d0 add %edx,%eax
4f: c9 leaveq
50: c3 retq