4 ms·

for, while, do...while, recursion, goto: is not a sign of "pragmatic minimalism" unless one choses to define it tautologically as "what C has".

hedora 9y ago
Pragmatic == close enough to all of the popular and contemporary assembler flow control constructs.
jstimpfle 9y ago
"recursion" is not a concept in C. Just function calls. "for" and "while" are very simple concepts and basically the same. They are very simple and well known idioms and not C specific. Most languages have both - not a big deal. I use "for" mostly for iterating over arrays, and I have otherwise mostly while loops and while(1) loops with manual breaking. Goto, you just can't do without it. Also not saying that in some cases even C is too much abstraction. But in general, its memory abstractions and its function call abstraction have proved to be very effective helping humans develop in a modular fashion.
- pjmlp 9y ago
  > Goto, you just can't do without it. Strange, the last time I used it I was still doing Basic in the early 90's, or when I do some Assembly programming. So yeah, we can do without it, as long as the languages are powerful enough.
  - vardump 9y ago
    I do find forward gotos useful in C. For error handling and breaking out of nested scopes. But only when goto is simpler and easier to understand than the alternative. Not saying there's no use for backward gotos, just don't remember ever needing them. Maybe they could be useful for some C code generation cases or perhaps for retrying some operation? What really annoys me are C++ exceptions used for flow control. Surprise gotos. I loved exceptions long ago at first, but over time the feeling has shifted more and more towards hate. Exceptions make code bases so much harder to understand. Especially when combined with inheritance.
- vardump 9y ago
  > "recursion" is not a concept in C. Just function calls. There are indeed C compilers that don't support recursion (or function re-entrancy). What does the standard say about stacks?
  - jstimpfle 9y ago
    I'm not a standards guy, so I might be wrong, but this is the only reference to recursive calls that I could find from the C11 draft [1], Section 6.5.2.2 item 11: Recursive function calls shall be permitted, both directly and indirectly through any chain of other functions. Stacks, I don't know. I only care about the concept (and semantics) of function calls. The call stack is an implementation detail. I wouldn't be surprised if the concept of a call stack was not part of the standard. [1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
    - comex 9y ago
      Indeed, it's not. In the case of what we'd usually call stack-allocated variables, the C standard just uses the phrase "automatic storage duration", and defines their lifetime without explicitly referencing a stack: > For such an object that does not have a variable length array type, its lifetime extends from entry into the block with which it is associated until execution of that block ends in any way. (Entering an enclosed block or calling a function suspends, but does not end, execution of the current block.) If the block is entered recursively, a new instance of the object is created each time. The initial value of the object is indeterminate.

hedora 9y ago

Pragmatic == close enough to all of the popular and contemporary assembler flow control constructs.

jstimpfle 9y ago

"recursion" is not a concept in C. Just function calls. "for" and "while" are very simple concepts and basically the same. They are very simple and well known idioms and not C specific. Most languages have both - not a big deal. I use "for" mostly for iterating over arrays, and I have otherwise mostly while loops and while(1) loops with manual breaking. Goto, you just can't do without it. Also not saying that in some cases even C is too much abstraction. But in general, its memory abstractions and its function call abstraction have proved to be very effective helping humans develop in a modular fashion.

pjmlp 9y ago
> Goto, you just can't do without it. Strange, the last time I used it I was still doing Basic in the early 90's, or when I do some Assembly programming. So yeah, we can do without it, as long as the languages are powerful enough.
- vardump 9y ago
  I do find forward gotos useful in C. For error handling and breaking out of nested scopes. But only when goto is simpler and easier to understand than the alternative. Not saying there's no use for backward gotos, just don't remember ever needing them. Maybe they could be useful for some C code generation cases or perhaps for retrying some operation? What really annoys me are C++ exceptions used for flow control. Surprise gotos. I loved exceptions long ago at first, but over time the feeling has shifted more and more towards hate. Exceptions make code bases so much harder to understand. Especially when combined with inheritance.
vardump 9y ago
> "recursion" is not a concept in C. Just function calls. There are indeed C compilers that don't support recursion (or function re-entrancy). What does the standard say about stacks?
- jstimpfle 9y ago
  I'm not a standards guy, so I might be wrong, but this is the only reference to recursive calls that I could find from the C11 draft [1], Section 6.5.2.2 item 11: Recursive function calls shall be permitted, both directly and indirectly through any chain of other functions. Stacks, I don't know. I only care about the concept (and semantics) of function calls. The call stack is an implementation detail. I wouldn't be surprised if the concept of a call stack was not part of the standard. [1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
  - comex 9y ago
    Indeed, it's not. In the case of what we'd usually call stack-allocated variables, the C standard just uses the phrase "automatic storage duration", and defines their lifetime without explicitly referencing a stack: > For such an object that does not have a variable length array type, its lifetime extends from entry into the block with which it is associated until execution of that block ends in any way. (Entering an enclosed block or calling a function suspends, but does not end, execution of the current block.) If the block is entered recursively, a new instance of the object is created each time. The initial value of the object is indeterminate.