By small, I meant that you can hold every little part of the syntax and normal behavior in your head pretty easily. Yeah, there are edge cases (important ones even) and you can build god-awful complicated expressions if you want. But look a the K&R books -- they are slim. It just not that big.
By not-doing-stuff-behind-your-back, I mean that you can map the code you write into machine instructions in many cases. An optimizer will move stuff around on you but it is typically local(-ish) manipulations. That's much less black magic that garbage collection. You have to manage memory yourself.
By being-ballet, I mean that it is hard. I am a swing dancer. The best dancers I know all took ballet classes as kids. None of them dance ballet today. It is probably coincidence/age but the best programmers I know all spent a decade or more working in C. I think working in C gives you a level of understanding about what a computer does that a higher level language doesn't. That said -- if you want to get stuff done, use a higher level language. I'm really good at C coding but I'm x2-10 faster when in C#.
>By small, I meant that you can hold every little part of the syntax and normal behavior in your head pretty easily
Well I think that is where we disagree. I don't find it easy to hold all the rules of C in my head. It's plenty large enough that there are things I hardly ever use. Even the common parts of the language like arithmetic on integer types can get complicated very quickly if you want to be sure your code contains no undefined behaviour or works correctly for INT_MAX etc. Often you have to understand not just what the standard says but also what your compiler/target architecture does for the many implementation defined things.
>Yeah, there are edge cases (important ones even) and you can build god-awful complicated expressions if you want.
You don't have to write long or complicated expressions for things to get tricky. That was the point of this example: http://blog.regehr.org/archives/482 It's a simple function yet mainstream compilers got it wrong for years.
I don't consider these things as edge cases because they come up all the time and have caused countless serious bugs in real world C code.
>By not-doing-stuff-behind-your-back, I mean that you can map the code you write into machine instructions in many cases.
That is becoming less and less true with modern compilers. Vectorizers will kick in at different optimisation levels and depending on various heuristics that I'm not sure even the compiler authors would be confident in predicting for more complex code. They can perform a lot of complicated transforms. Undefined behaviour means lots of code can be modified in fairly unintuitive ways.
>An optimizer will move stuff around on you but it is typically local(-ish) manipulations
By not-doing-stuff-behind-your-back, I mean that you can map the code you write into machine instructions in many cases. An optimizer will move stuff around on you but it is typically local(-ish) manipulations. That's much less black magic that garbage collection. You have to manage memory yourself.
By being-ballet, I mean that it is hard. I am a swing dancer. The best dancers I know all took ballet classes as kids. None of them dance ballet today. It is probably coincidence/age but the best programmers I know all spent a decade or more working in C. I think working in C gives you a level of understanding about what a computer does that a higher level language doesn't. That said -- if you want to get stuff done, use a higher level language. I'm really good at C coding but I'm x2-10 faster when in C#.