4 ms·

Safety has value it just doesn't imply overhead. Abstractions are a negative, they make reasoning burdensome.

cbd1984 12y ago
Abstractions are what make it possible to reason about complex systems. Being able to ignore parts of your codebase is the only way to make changes to it once it gets beyond a trivial size. The whole of the Unix philosophy is enforcing this policy of strong abstractions by making each part of a complex overall system its own binary, such that they can only communicate using the file I/O abstraction, possibly via pipes. C was therefore designed for a system which promotes abstractions.
- deleted 12y ago
  [deleted]
  - cbd1984 12y ago
    Even if your comment both made sense and was factually accurate, it wouldn't have much relevance to the kind of C programming I'm talking about: For example, mmap(2) isn't defined in the C standard but in POSIX, but it's universal in the Unix and Unix-like OS world to the extent programs can safely rely on it. Standards are good and useful things, but they're only fully written down in retrospect.
  - tedunangst 12y ago
    Section 7.19.3.
    - function_seven 12y ago
      I'm getting 7.21.3, reading here[1], but that's the draft spec for C11. I couldn't find the official one anyhere. [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
      - tedunangst 12y ago
        Oh, I'm still bumming around with a copy of C99. Now that I'm here, I'll add the definition of streams in the previous section is probably the more interesting part, since that's the term used for the idea of abstracting tapes and terminals.
- rab_oof 12y ago
  Lifting up constants into defines/consts and DRYing up C code makes for shorter, less error-prone and easier-to-understand codebases. Eg there's no reason to continue writing code like it's 1960's because we can steal good software eng and maintainability lessons from everything that has come since. (If one must maintain absolute portability.) PS: I would like to see a toolchain for Go that emits portable C instead of statically linking in a giant runtime... Lightweight camping vs. YAGNI hoarding. Seriously, the weight of runtimes would be the biggest barrier to serious systems deployment, outshining the slowdown, productivity and safety tradeoffs. (Eg Go would need to play nice with embedded constraints including memory usage as well.).
  - nwmcsween 12y ago
    It's not "writing like 1960's programming' gratuitous abstraction just creates a burden for the programmer to dig through, it makes reasoning a pain.
    - rab_oof 12y ago
      That's taking things literally too far. Common sense says take some giant unsigned long long constant used in multiple places that cannot be vertically aligned and give it the semantic meaning it deserves. The goal of reducing LoC is to not obscure meaning but to write less code that states its behavior more clearly. Abstractions are garbage if they are confusing / hide meaning, but abstractions are immensely valuable if they perform complex operations in a clear manner (say an well-designed http client lib in C.)

cbd1984 12y ago

Abstractions are what make it possible to reason about complex systems. Being able to ignore parts of your codebase is the only way to make changes to it once it gets beyond a trivial size. The whole of the Unix philosophy is enforcing this policy of strong abstractions by making each part of a complex overall system its own binary, such that they can only communicate using the file I/O abstraction, possibly via pipes. C was therefore designed for a system which promotes abstractions.

deleted 12y ago
[deleted]
- cbd1984 12y ago
  Even if your comment both made sense and was factually accurate, it wouldn't have much relevance to the kind of C programming I'm talking about: For example, mmap(2) isn't defined in the C standard but in POSIX, but it's universal in the Unix and Unix-like OS world to the extent programs can safely rely on it. Standards are good and useful things, but they're only fully written down in retrospect.
- tedunangst 12y ago
  Section 7.19.3.
  - function_seven 12y ago
    I'm getting 7.21.3, reading here[1], but that's the draft spec for C11. I couldn't find the official one anyhere. [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
    - tedunangst 12y ago
      Oh, I'm still bumming around with a copy of C99. Now that I'm here, I'll add the definition of streams in the previous section is probably the more interesting part, since that's the term used for the idea of abstracting tapes and terminals.
rab_oof 12y ago
Lifting up constants into defines/consts and DRYing up C code makes for shorter, less error-prone and easier-to-understand codebases. Eg there's no reason to continue writing code like it's 1960's because we can steal good software eng and maintainability lessons from everything that has come since. (If one must maintain absolute portability.) PS: I would like to see a toolchain for Go that emits portable C instead of statically linking in a giant runtime... Lightweight camping vs. YAGNI hoarding. Seriously, the weight of runtimes would be the biggest barrier to serious systems deployment, outshining the slowdown, productivity and safety tradeoffs. (Eg Go would need to play nice with embedded constraints including memory usage as well.).
- nwmcsween 12y ago
  It's not "writing like 1960's programming' gratuitous abstraction just creates a burden for the programmer to dig through, it makes reasoning a pain.
  - rab_oof 12y ago
    That's taking things literally too far. Common sense says take some giant unsigned long long constant used in multiple places that cannot be vertically aligned and give it the semantic meaning it deserves. The goal of reducing LoC is to not obscure meaning but to write less code that states its behavior more clearly. Abstractions are garbage if they are confusing / hide meaning, but abstractions are immensely valuable if they perform complex operations in a clear manner (say an well-designed http client lib in C.)