4 ms·

What is something such a person should know but doesn’t? I don’t write C but the language is fairly small so I can imagine a professional keeping 99% of it in t

What is something such a person should know but doesn’t? I don’t write C but the language is fairly small so I can imagine a professional keeping 99% of it in their head at all time.

remexre 1y ago
Idiomatic design would be a big one; there are a lot of ways to design a program in a higher-level OO language that, if followed in C, will lead to a program with lots of bugs around error handling and resource cleanup. This kind of ties into the argument made by some in the Rust community that "the ownership was there the whole time" -- in a language without automatic memory management, you really do need to be aware of the life-cycle of an object in memory. Rust's specific rules aren't fundamental, but "even when an error occurs, I know what cleans up this object / this state" is.
layer8 1y ago
They should know what the C abstract machine does and doesn’t guarantee, for one.
anthk 1y ago
C it's highly machine dependant. Something like Scheme, CL or even Forth would be preferable. At least with some bare metal Forth you can inspect the machine from high level to ASM levels.
- codr7 1y ago
  I agree Forth could make a more optimal first language to learn. I often recommend beginners to learn all of Forth, C, Lisp & SmallTalk. Because they're all conceptually clean local maximums in the language design space.
  - anthk 1y ago
    With Forth (Starting Forth and Thinking Forth) and Lisp (especially CLOS or Scheme with SICP) you cover them all. Even Subleq+Eforth it's fine, you'll learn EForth (it can be set at muxleq.fth/subleq.ftj with some compatibility with do...loop and floats) and Subleq as a VM. It's highly documented and it even has a book to play with. EDIT: as a nice example, I had some pas.f example with a Pascal triangle. In order to get it working under eforth, I just had to define .r as u.r on top like: : .r u.r ; and that was it. It ran on both PForth and EForth. Eforth on a subleq (muxleq for performance) under an n270 Atom netbook.
codr7 1y ago
As others said, just because you know the syntax that doesn't mean you understand how to use it effectively. C is very different from most other languages, I would say the closest one is actually Assembly. I've been working on a book for a while now to try and share some of the ideas I've picked up over the years: https://github.com/codr7/hacktical-c https://github.com/codr7/hacktical-c
bqmjjx0kac 1y ago
C looks friendly enough, but it has many nooks and crannies filled with undefined behavior (UB). If your program accidentally does something like overflow a signed integer, you're toast. Raymond Chen has the best write up on UB that I've seen: <https://devblogs.microsoft.com/oldnewthing/20140627-00/?p=633 https://devblogs.microsoft.com/oldnewthing/20140627-00/?p=63...>. In addition to the "obvious" undefined behavior, strict aliasing is subtle and poorly understood in my experience. Consider the following: Foo ReadFooFromBytes(const char* data, size_t len) { Foo foo; assert(len == sizeof(Foo)); foo = *(const Foo*)(data); return foo; } Foo ConvertToFoo(Bar bar) { return ReadFromBytes((const char*)&bar, sizeof(bar)); } The `ReadFooFromBytes()` function could exhibit undefined behavior, depending on the provenance of its pointer parameter. If you gave it a pointer to a true array of chars, it's fine. If you use `ConvertToFoo()`, big bada boom. Truly baffling stuff, the first time you encounter it.

What is something such a person should know but doesn’t? I don’t write C but the language is fairly small so I can imagine a professional keeping 99% of it in their head at all time.

remexre 1y ago

Idiomatic design would be a big one; there are a lot of ways to design a program in a higher-level OO language that, if followed in C, will lead to a program with lots of bugs around error handling and resource cleanup. This kind of ties into the argument made by some in the Rust community that "the ownership was there the whole time" -- in a language without automatic memory management, you really do need to be aware of the life-cycle of an object in memory. Rust's specific rules aren't fundamental, but "even when an error occurs, I know what cleans up this object / this state" is.

layer8 1y ago

They should know what the C abstract machine does and doesn’t guarantee, for one.

anthk 1y ago

C it's highly machine dependant. Something like Scheme, CL or even Forth would be preferable. At least with some bare metal Forth you can inspect the machine from high level to ASM levels.

codr7 1y ago
I agree Forth could make a more optimal first language to learn. I often recommend beginners to learn all of Forth, C, Lisp & SmallTalk. Because they're all conceptually clean local maximums in the language design space.
- anthk 1y ago
  With Forth (Starting Forth and Thinking Forth) and Lisp (especially CLOS or Scheme with SICP) you cover them all. Even Subleq+Eforth it's fine, you'll learn EForth (it can be set at muxleq.fth/subleq.ftj with some compatibility with do...loop and floats) and Subleq as a VM. It's highly documented and it even has a book to play with. EDIT: as a nice example, I had some pas.f example with a Pascal triangle. In order to get it working under eforth, I just had to define .r as u.r on top like: : .r u.r ; and that was it. It ran on both PForth and EForth. Eforth on a subleq (muxleq for performance) under an n270 Atom netbook.

codr7 1y ago

As others said, just because you know the syntax that doesn't mean you understand how to use it effectively. C is very different from most other languages, I would say the closest one is actually Assembly. I've been working on a book for a while now to try and share some of the ideas I've picked up over the years: https://github.com/codr7/hacktical-c https://github.com/codr7/hacktical-c

bqmjjx0kac 1y ago

C looks friendly enough, but it has many nooks and crannies filled with undefined behavior (UB). If your program accidentally does something like overflow a signed integer, you're toast. Raymond Chen has the best write up on UB that I've seen: <https://devblogs.microsoft.com/oldnewthing/20140627-00/?p=633 https://devblogs.microsoft.com/oldnewthing/20140627-00/?p=63...>. In addition to the "obvious" undefined behavior, strict aliasing is subtle and poorly understood in my experience. Consider the following: Foo ReadFooFromBytes(const char* data, size_t len) { Foo foo; assert(len == sizeof(Foo)); foo = *(const Foo*)(data); return foo; } Foo ConvertToFoo(Bar bar) { return ReadFromBytes((const char*)&bar, sizeof(bar)); } The `ReadFooFromBytes()` function could exhibit undefined behavior, depending on the provenance of its pointer parameter. If you gave it a pointer to a true array of chars, it's fine. If you use `ConvertToFoo()`, big bada boom. Truly baffling stuff, the first time you encounter it.