[UbrtrbNchDneRle]

As a student, I disagree on C.

C is fun for playing with pointers and doing raw memory things, but it becomes overwhelmingly painful and frustrating so quickly. And for the wrong reasons. Once you have to touch macros, or want to reuse code, it is just … old. Not hard, not minimalistic - just old. C can be fun the way bash can be fun, or baking without a recipe. It is fun to overcome an arcane mess, for the challenge. But you really learn little, or the wrong thing.

And C is not easy to look up online either. It took me so many hours figuring out some things are just not possible in C (without making it a new language via macro madness). Things that should be possible. Like „generics“. Kinda possible, but never satisfying. You constantly have to endure verbosity over abstraction. Not because that’s how computers work, but because how people did it 30 years ago, or because some industrial microcontroller needs it this way.

IMO whatever C can teach you, assembly can do better. Without tricking you into believing it’s a practical choice for most anything.

I think Rust is visually offputting for new students and it’s not really a good choice, but at least you learn something important, when things get hard. In C you are either trained to view programming as the most repetitive, joyless activity ever, or to indulge in hacking your way around broken shit, disregarding cooperation (with your future self), universal elegance and safety.

If there is „one language everyone needs to learn“ it’s some accessible and fun, which let’s enjoy computers and not tell you limits at every opportunity. There is no way to avoid C entirely, if you enjoy programming anyway; at some point you have to interface or tweak C, most likely.

[kazinator]

> IMO whatever C can teach you, assembly can do better.

Other than, oh, things like getting the same code to produce exactly the same result on two different machines, where the sizes of the types being used by the code are different.

[UbrtrbNchDneRle]

I already addressed this. IMO the portability mantra is something I disagree over „C for everyone“. It’s an annoying obstacle, but not exactly fundamental or hard to learn on the job.

[kazinator]

I would guess that it's hard to learn that on the job, if the job consists of assembly language programming.

[mrmuagi]

Hmm, unless I am mistaken, does not using portable types stdint.h u?int(8|16|32)_t fix this?

[kazinator]

Using the same int<whatever>_t on all the targets may fix it in terms of correct behavior, but doesn't meet the definition of using different types on the different machines in the same overall logic, while getting the same result.

[mrmuagi]

I mean, you're right that this is a problem and it gives people the ability to shoot themselvesin the foot but bytes and byte order is apart of a C programmers framework for better or worse. I want to argue it gives you incredible control of the data at the lowest level and that's the tradeoff. If you write non portable code, it seems like you have to go out of your way not using standard portability types. If you define your own struct types I can see where this goes awray, but I think " __attribute__((__packed__))" eliminates alignment spaces for that case.

BUT, if you are coming from a networking/file perspective I can emphathize with you. Byte ordering is a pain for data serialization, even that has chance to cause issues and is no doubt a source of bug and pain.

[kazinator]

I mean, I can write code that has, say, this somewhere at the top:

  typedef unsigned int whatever_t;
  #define WHATEVER_MAX UINT_MAX

I can write the code such that I can edit whatever_t and WHATEVER_MAX to whatever values I want, and it still works, without changing any of the rest of the code.

This is not very highly abstract, but higher than assembly language.

If you want to teach this sort of hardware independence, asm is probably not the best teaching tool.

[mrmuagi]

I never got too into C where I heavily used macros. I've seen some magic in C where you define function tables for objects and recreate object oriented programming but to be frank it's painful mimicry as well here. The best mixin I've seen is where you use function pointers to help de-duplicate code.

I would say C taught and learned correctly can teach you the memory model computers use and the concept of pointers. Other languages do other things better, like Java can teach you about memory management via garbage collection and references.