4 ms·

> It simply provides no training wheels or safety harness - meaning one needs to know what they are doing Meaning that if you are human you will make mistakes.

> It simply provides no training wheels or safety harness - meaning one needs to know what they are doing Meaning that if you are human you will make mistakes. My point is that people who do know what they're doing still make mistakes. Clearly the tool does not match the reality of human cognition.

geezerjay 9y ago
> Meaning that if you are human you will make mistakes. You can make mistakes in any language, and they will bite you in the backside any way. Just because some people prefer to live in padded rooms that doesn't mean they can't or won't get hurt if they decide to pull stunts. Padded rooms just provide them with a false notion of safety that ends up making matters worse.
- deleted 9y ago
  [deleted]
- TheDong 9y ago
  > You can make mistakes in any language, and they will bite you in the backside any way. This is a false equivalency.. It's akin to saying "you can hit your thumb putting in a nail with any tool, so you might as well use a rock not a hammer since they're both bad". Yes, you can make mistakes in any language, but that's not a reason to ignore modern tooling and advances and continue. Other languages allow us to build abstractions and solve mistakes in ways which are just impossible with C... and without those abstractions, it's just needlessly difficult to keep all the state in your head and write correct code. An easy example of this is locking and ownership. In C, mutexes are managed manually and what they hold is by convention. It's easy to write races or accidentally deadlock (again as evidenced by such a bug in the kernel existing every few weeks). In languages with RAII, python's "with", etc, you can't forget to unlock the lock. It's one less thing to think about. In languages like rust, it's possible to model in the type system that a given resource can only be accessed while a mutex is locked. Again, one less way to make a mistake. C has no ability to provide or build abstractions that are this robust. Using C is, more often than not, like using a rock to hammer in a nail. > Just because some people prefer to live in padded rooms With C, people are living in a room where the floor is lava and nails coat most surfaces. I'll take my room that's carpeted, and if I need to pull a stunt and rip up the carpet, sure, I can do that, but at least I can walk normally most of the time.
  - amag 9y ago
    > It's one less thing to think about. I've been a professional C++ programmer for almost two decades (and a C++ amateur for almost a decade before that). I've written large amounts of fairly advanced C++ using the latest standards. My current job however, is all plain C. One of the interesting (and, for a C++ fan like me, disturbing) things I've found is that the cognitive load is much lower when writing plain well-structured C. Sure, you need to remember to release that lock and free that memory but this you can do in a very structured way. What you win over C++ is that you don't need to view each line of code with suspicion ("What happens if this line throws an exception?", "I wonder what this line will cost in terms of performance?", "Could this operation cause a cascading destruction of objects I'm going to access further down?"). I love RAII, yet I've debugged enough crashes where "seemingly innocuous operation destructs some local object that has an owning reference to an object that shouldn't be destructed just yet and BAM!", that I'm beginning to doubt its usefulness outside of an exception-generating language (in C++ it's essential for proper exception-handling).
    - falcolas 9y ago
      > Sure, you need to remember to release that lock and free that memory It's always bothered me how complex of an operation people seem to think this is. errno = pthread_mutex_lock(&m); if (errno == 0) { do_something(); pthread_mutex_unlock(&m); } Short of a segfault or 'do_something' doing something really, unusually stupid, you can't avoid freeing the mutex.
      - aidenn0 9y ago
        Something really unusually stupid like returning from the function (assuming do_something() is a standin for arbitrary code, not specifically a function call)? This is not even remotely the worst thing about mutexes though, so it wouldn't be why I would suggest avoiding them.
        falcolas 9y ago
        Honestly, to help avoid mistakes, I would keep it as a function call. Sure, it adds to the stack depth, but it also ensures a separate return doesn't cause the lock to be lost. There's also the goto pattern, but anytime you separate a lock from an unlock by more than a screen's worth of text, they're forgotten.

geezerjay 9y ago

> Meaning that if you are human you will make mistakes. You can make mistakes in any language, and they will bite you in the backside any way. Just because some people prefer to live in padded rooms that doesn't mean they can't or won't get hurt if they decide to pull stunts. Padded rooms just provide them with a false notion of safety that ends up making matters worse.

deleted 9y ago
[deleted]
TheDong 9y ago
> You can make mistakes in any language, and they will bite you in the backside any way. This is a false equivalency.. It's akin to saying "you can hit your thumb putting in a nail with any tool, so you might as well use a rock not a hammer since they're both bad". Yes, you can make mistakes in any language, but that's not a reason to ignore modern tooling and advances and continue. Other languages allow us to build abstractions and solve mistakes in ways which are just impossible with C... and without those abstractions, it's just needlessly difficult to keep all the state in your head and write correct code. An easy example of this is locking and ownership. In C, mutexes are managed manually and what they hold is by convention. It's easy to write races or accidentally deadlock (again as evidenced by such a bug in the kernel existing every few weeks). In languages with RAII, python's "with", etc, you can't forget to unlock the lock. It's one less thing to think about. In languages like rust, it's possible to model in the type system that a given resource can only be accessed while a mutex is locked. Again, one less way to make a mistake. C has no ability to provide or build abstractions that are this robust. Using C is, more often than not, like using a rock to hammer in a nail. > Just because some people prefer to live in padded rooms With C, people are living in a room where the floor is lava and nails coat most surfaces. I'll take my room that's carpeted, and if I need to pull a stunt and rip up the carpet, sure, I can do that, but at least I can walk normally most of the time.
- amag 9y ago
  > It's one less thing to think about. I've been a professional C++ programmer for almost two decades (and a C++ amateur for almost a decade before that). I've written large amounts of fairly advanced C++ using the latest standards. My current job however, is all plain C. One of the interesting (and, for a C++ fan like me, disturbing) things I've found is that the cognitive load is much lower when writing plain well-structured C. Sure, you need to remember to release that lock and free that memory but this you can do in a very structured way. What you win over C++ is that you don't need to view each line of code with suspicion ("What happens if this line throws an exception?", "I wonder what this line will cost in terms of performance?", "Could this operation cause a cascading destruction of objects I'm going to access further down?"). I love RAII, yet I've debugged enough crashes where "seemingly innocuous operation destructs some local object that has an owning reference to an object that shouldn't be destructed just yet and BAM!", that I'm beginning to doubt its usefulness outside of an exception-generating language (in C++ it's essential for proper exception-handling).
  - falcolas 9y ago
    > Sure, you need to remember to release that lock and free that memory It's always bothered me how complex of an operation people seem to think this is. errno = pthread_mutex_lock(&m); if (errno == 0) { do_something(); pthread_mutex_unlock(&m); } Short of a segfault or 'do_something' doing something really, unusually stupid, you can't avoid freeing the mutex.
    - aidenn0 9y ago
      Something really unusually stupid like returning from the function (assuming do_something() is a standin for arbitrary code, not specifically a function call)? This is not even remotely the worst thing about mutexes though, so it wouldn't be why I would suggest avoiding them.
      - falcolas 9y ago
        Honestly, to help avoid mistakes, I would keep it as a function call. Sure, it adds to the stack depth, but it also ensures a separate return doesn't cause the lock to be lost. There's also the goto pattern, but anytime you separate a lock from an unlock by more than a screen's worth of text, they're forgotten.