Hacker News Reader

Comment by throwawaaarrgh | Hacker News Reader

You should learn C because it's a gateway to deeper knowledge. The kernel uses it, about a thousand programs shipped with Linux use it, embedded programming uses it. It helps you understand how lower level network protocols have been designed, how to efficiently use memory, how to design algorithms and why they're harder than you think. There's a crapton of libraries in C, most higher level languages have some extensions to take advantage of them. Sensitive security software will use it, due to various attack vectors that are slightly easier to deal with at a lower level. It's handy and expands your brain. And it's not going away anytime soon.

View on HN

I can't say I learned much by programming in C, if I even learned anything at all. Mostly I just grumble at the needlessly verbose and complex way of doing some things (e.g. anything with strings) and get annoyed by the syntax and quirks of the language and surrounding toolchain.

It is of course useful for a whole bunch of reasons, including being able to figure out "why does this do X?", but that's not really "deeper knowledge", IMO.

Compared to writing code in assembly language it is a dream, though!

I think C lets you think about low-level details of how systems work, strings being arrays of characters with an explicit terminating NUL character, for example. Although again assembly language gives you _real_ lower-level understanding and insights if you use it.

It's useful to know how things like strings and arrays work and that they're not just "magic", but I don't think you really need to learn C to do that. I understood that kind of stuff long before I did any serious C programming, and knowing C didn't really add much to that. The thing is that I don't want to think about it every time.

I "just" want to do X, but instead I need to write a whole bunch of code to handle it all manually. It's useful that this is possible, but a lot of times you don't need it, and some other languages still keep the "common case" easy while still enabling the high-performance stuff C can do.

I wish we had C+: C + a few niceties (and not C ++ everything). There's a whole bunch of newer languages aiming at the space C is sitting in, but with a few additions C could be much more ergonomic without having to invent an entire new language.

> I wish we had C+: C + a few niceties (and not C ++ everything). There's a whole bunch of newer languages aiming at the space C is sitting in, but with a few additions C could be much more ergonomic without having to invent an entire new language.

I’ve made a pre-processor for C to add some things I miss, although it is currently limited to what can be done without type information and has to keep compatibility with existing C syntax: https://sentido-labs.com/en/library/cedro/202106171400/

There is another language called C3 that “is a C-like language striving to be an evolution of C, rather than a completely new language”: https://github.com/c3lang/c3c

If you have the time, I’d like to hear which things you miss in C. There might be something I did not imagine that could be added to Cedro.

> Compared to writing code in assembly language it is a dream, though

C is a something of a high-level assembly language. Of course we could write literal assembly language in C, pretty much.

   r1 = 0
   r2 = 1
   r3 = r1 + r2
   mem[1000] = r3

Except that C targets the C abstract machine, which can't do a lot of stuff that is perfectly acceptable in assembly. Such as reading uninitialized memory, padding, overflowing signed integers, forging a pointer (e.g. for memory mapped I/O) out of thin air, dereferencing null...

By the way, null-terminated strings are not the only way to express strings, it’s a legacy of C that many low-level programmers dislike but need to stick to it because of legacy reasons (every major OS is written in C).

All the low-level languages aiming to replace C basically abandoned this approach, and opted for slices instead (ptr + size pair, used in Rust, Zig, etc.) This has the benefit of easier and faster string manipulation (strlen can be O(1) instead of O(n)), as well as better memory safety (can do bounds checking with the size information). The primary reason we are still using and teaching null terminators is because we still have to live with POSIX/Win32 and many low-level libraries written on this platform.

Indeed, I remember Turbo Pascal, running under CP/M, used the scheme where strings where prefixed with their length rather than being NUL terminated.

I thought zig has null terminated string literals. What's the difference?

String literals are constant single-item Pointers to null-terminated byte arrays. The type of string literals encodes both the length, and the fact that they are null-terminated, and thus they can be coerced to both Slices and Null-Terminated Pointers

https://ziglang.org/documentation/master/#String-Literals-an...

Hmm... after some research it seems that I've misunderstood Zig's situation a bit. Zig has introduced null-terminated string types a couple of years ago, but still encourages you to do most string operations with slices instead. Let me explain:

Zig's string literals (which you create with parenthesis like "Hello world!") are null-terminated byte arrays, expressed as the type *const [N:0]u8 (where the :0 tells you that it's null-terminated), whereas the more typical array might be written as *const [N]u8. The reason for this feature is not because the language wants you to use null-terminated strings, but because these static strings need to be stored in the global data section of the ELF executable, and these require you to use null-termination. But if you want to do any mutable operation with this string, you need to convert this into a proper slice (ptr + size). And it seems like Zig developers don't really use null-terminated types that much at the API level, but use it for things like C interop or cases where you really need it for special optimizations.

Noting that from the PR that introduced this feature, Andrew Kelley writes [0]:

> I think you will find that the Zig community in general (and especially myself) agrees with you on this [null-terminated strings being fragile], and APIs in general should prefer slices to null terminated pointers. Even if you are using Zig to create a C library, and even in actual C libraries, I would recommend pointer and length arguments rather than null terminated pointers, like this: https://github.com/andrewrk/libsoundio/blob/1.1.0/soundio/so...

> That being said, I want to repeat what I said earlier about null terminated pointers: A null terminated array is not inherently an evil C concept that is intruding in the Zig language. It's a general data storage technique that is valid for some memory constrained use cases. I also stumbled on a Real Actual Use Case inside LLVM. The bottom line for me is that null terminated pointers exist in the real world, and especially in systems programming. You can see this in interfaces with the operating system in the standard library...

So he acknowledges null-terminated strings can certainly be useful in certain situations outside of legacy reasons, which is good to know. And Zig creating a special type for this shows that a good systems language needs to be designed to accommodate the needs of the outside world.

[0] https://github.com/ziglang/zig/issues/265#issuecomment-46337...

Thanks for this nice writeup!

Small correction regarding the ELF object file format: any kind of data whatsoever can be stored in the data section, including strings in the form of ptr + length without null termination. Zig string literals are null terminated in addition to having the length not because of an object file limitation but because it is useful to pass string literals to APIs that require null-termination, such as most C libraries. In practice, this simplifies the experience of using the language.

Ah, thanks for the correction.

Imo the string thing is a bad example, as they don't really have to work that way. Storing length is another solution, but because C is C, the NUL method is quite prominent, if annoying

even assembly is essentially bytecode on the modern processors.

I think you can eck out more performance, but the time investment is much more.

Time is finite. Learning C is not necessarily aligned with everyone's goals or path. For example, if I care more about building products than low level software it's probably not worth learning C unless I happen to be interested in it.

To me that seem akin to saying "if you just care about running it's probably not worth learning to walk"

It is always "worth it" to understand the machine you are manipulating, and no matter what you think about the C virtuel machine, the very real machine in front of me has been shaped by its relationship to C.

The difference is that you could go your whole career without needing to touch C, whereas to run you must walk.

> It is always "worth it" to understand the machine you are manipulating

Why is it always worth it? If I want to be a product/creative developer how does learning C specifically help me?

C confers an understanding of pointers that will cause reference types in other languages to make a lot more sense. It'll also give you a good feel for what kinds of operations are costly and what kinds are not.

It's like knowing how your car works will make you a better driver. You'll be able to get more out of the car, it will last longer, and when it breaks you'll know if you can't move another inch or you'll know how to nurse it home.

> C confers an understanding of pointers that will cause reference types in other languages to make a lot more sense

I'm not sure what you mean by this. I know what pointers are and I have not written C before. What understanding will C specifically give me which will help me understand reference types better?

> It'll also give you a good feel for what kinds of operations are costly and what kinds are not

Does this matter though? For most applications you don't need to understand what kind of operations are costly.

I am unusually curious so I'll probably learn about Assembly and low level operations out of curiosity at some point, but it's easy to imagine that I may not work on something where this would be useful knowledge or I would use this knowledge so rarely that the opportunity cost is not worth it.

For the vast majority of developers the opportunity cost for learning C seems quite high.

> I know what pointers are and I have not written C before

Actually working with them confers a lot more understanding of them.

> For most applications you don't need to understand what kind of operations are costly.

I've often been given the task to fix severe performance problems in other peoples' code who simply did not know what kinds of operations were costly. Having performant code is a significant competitive advantage.

> For the vast majority of developers the opportunity cost for learning C seems quite high.

Not if you understand pointers. That's what usually trips up people new to C.

> it's easy to imagine that I may not work on something where this would be useful knowledge

This may be hard to explain, but you don't know what you don't know. You won't be able to see an opportunity to exploit your knowledge gained from using C. To go back to the car analogy, most people drive a car with zero knowledge of how it works. This winds up being expensive for them, when it's time to deal with problems with the car.

For example, the alternator shorted out in my car. I took it to the dealer for a repair, and they quoted me a fantastic sum including 2 hours of labor. I happen to know how the alternator works, and I've replaced alternators multiple times. I gave the service manager the step-by-step procedure to replace the alternator, and said it could be done in 15 minutes tops. The labor price quote dropped by more than half. It also turned out that they could get me a refurbished one for far less money, and since I understand what a refurbished alternator was, I was comfortable with installing a refurbished one.

Anyone not knowing how cars work would have had no ability to bargain or understand the tradeoffs.

Many languages other than C have pointers though. It sounds like you are recommending understanding pointers moreso than learning C.

> I've often been given the task to fix severe performance problems in other peoples' code who simply did not know what kinds of operations were costly

What kind of application was this? I completely believe having this knowledge is valuable, but not for all developers.

> This may be hard to explain, but you don't know what you don't know. You won't be able to see an opportunity to exploit your knowledge gained from using C

This comes back to opportunity cost. You are stating this as though C is the only avenue to gain knowledge which can be exploited at a later date. For many developers there is probably other knowledge which is going to be far more useful and exploitable.

Your story about the alternator feels like a good example of this. If I was in your shoes I would have paid the original sum and been happy. You've saved money, but you've also had to learn how an alternator works and replace them multiple times. I'm happy to pay a premium and use that time for other things.

C is a small and straightforward language. It's easy to learn. It's the lingua franca of the programming languages (in that the foreign language interface of other languages is usually C). You're possibly expending more effort justifying not learning C than it would take to learn it :-) And once you learn it, as a professional programmer you'll garner a career's worth of benefit from it.

Take the plunge. Learn how to swim, how to touch-type, how compound interest works, how to read a balance sheet, how to tie various knots, how to drive a stick shift, how to integrate and differentiate, how to unclog a drain, how to jump start a car, how to change a tire, how to write a program in C.

As an old guy, I know these simple skills pay off in various and unexpected ways.

The alternator is a specific item example, a stand-in for a tax on everything in life 100 times a day every day.

The arguments against learning fundamentals exist, but are weaker than the arguments for.

There are languages that have pointers and don't require understanding a bunch of random arcane rules just to declare a variable.

C's problems stem from its simplicity, not its complexity.

They stem from both.

> Why is it always worth it? If I want to be a product/creative developer how does learning C specifically help me?

I am going answer you with some questions!

What is a product for you?

Are a dishwater, a car, a keyboard, a smart LED lightbulb some kind of product a human can build? A product with some sort of microcontroller?

How many products like that there are in your room, house and office right now?

What about in the whole world for the past 20 years?

In all of those products there is probably C running!

I thought it was obvious from context that I was talking about software products.

This is what I mean by a product developer: https://blog.pragmaticengineer.com/the-product-minded-engine...

I'm sure that type of developer exists for the kinds of products you are talking about, deep tech products, etc but that seems a lot less common.

But those developers write software just like you! These products are also "software" to some degree!

The link you've posted also applies to those who build smart lightbulbs.

> seems a lot less common

I guess the problem is that the world is bigger than you may think. I don't know what you build, but let's pretend it's some kind of web service.

Consider how many brands of microcontroller-based products there are in the world, with their many variants. For the sake of the discussion consider just the "commercial" products you can purchase on Amazon. My guess is that they surpass the quantity of web projects out there.

Add to the mix the custom/industrial devices, special tools and computers, etc. that many small companies are building right now (like the one I work for).

Remember that someone is writing code for these products. Given the quantity of product, they can't be "a lot less common".

To answer your question, and if you do web services, let's say you want to know how Redis works internally. You need C.

To me this demonstrates why it's not always worth learning C. Like you said, the world is bigger than we think. There are areas of software where knowing C is not that helpful.

Even in the web world, most devs are not going to be poking around in Redis internals. If you go higher up the stack to things like accessibility or CSS animations then knowing C is literally useless.

Why do you feel like C is so fundamental that every developer must know it regardless of what they work on?

> Why do you feel like C is so fundamental that every developer must know it regardless of what they work on?

I never said so. I was answering specifically to "If I want to be a product/creative developer how does learning C specifically help me?"

Since you didn't mention what you do, I was talking about "product" and the definition you have, and if you want to build "product" there is a whole "product" industry, that is bigger than you think, that requires C.

If you do web development you can completely skip it if you want, but C is a nice tool to have around to understand why there is a bottleneck in Redis, Sqlite, a driver or a stack. Maybe find a workaround or a fix, but waiting for someone else to fix it is also valid if you don't want to fiddle with C.

It happens all the time: high level developer points finger and says "there is something wrong with the filesystem, my app crashes". They cross their arms and wait for me to go in a crazy debug session so I can explain them later why their app is slow and/or crashes.

It sounds like we have no disagreement then?

I'm well aware there are a lot of places C is used. My point is mostly that "waiting for someone else to fix it ... if you don't want to fiddle with C" is probably a better strategy than becoming competent enough with C to fix your own problems.

Becoming competent enough with C to diagnose and fix problems in production C codebases seems like it would be quite time consuming.

Also, I work with SREs that debug problems with MySQL and Redis without knowing C or looking at C code. Unless you are actively contributing to those codebases it seems unlikely you need to know C.

c helps one understand the limits of what is possible. those limits change over time. without good intuition of those limits, you can’t see the whole solution space that you are creating within, and can’t reason about tradeoffs of different solutions.

also c is fun!

I mean, if that's going to be your justification for learning C, then shouldn't you be learning how to create 16 bit adders from flip-flops, learning about the importance of mux and demux chips, and then building an ALU and FPU in verilog and testing them in a simulator?

I would argue that assembly language and hence C has been shaped that way it has because of the underlying structures of the processor and the way binary numbers are manipulated and stored. C and for that matter assembly, becomes quite trivial if you know enough to make your own simple CPU with decoder, instruction set, memory, ALU, FPU, etc.

I tend to think (agree with you?) that understanding computer architecture will make you a better system designer and developer. That's probably why many CS programs (and systems concentrations in particular) require a computer architecture course.

Verilog is of course C-like (much as VHDL is Ada-like.)

This comment is far from reality. It's difficult to measure what a "good" programmer is, but regardless of decision I am confident that it will have no correlation with whether you learned Verilog or what a D Flip Flop is.

Missing the forest for the trees. Computer architecture courses often expose you to things like: caches, memory and storage hierarchies, I/O, software/hardware interface, parallelism, Amdahl's law, pipelining, vector processing, prefetching, speculation, synchronization, clocking, interrupts, vector processing, data encoding, stream processing, virtual memory, general virtualization, isolation etc., etc..

If you care about execution time, responsiveness, efficiency, or reliability, these things matter.

If you're doing systems programming, they are essential.

I actually agree that moving in that direction is useful. I happen to have started from a quite high level (C# and VB.net), but I've been steadily moving down the stack towards embedded devices. I've been surprised many times by how many problems we've created for ourselves, and how much easier they become once you simplify.

This doesn't make sense in my point of view, since C is itself an abstraction. Why not do everything in assembler? Most of the early C compilers featured inline assembly.

Do you learn how to fly when you book a flight? Do you learn how to build cars when you get your driving license? Do you learn how water is cleaned when you drink? There is infinite regress.

In the end it is about trust and abstractions. Most algorithms have nothing to do with C. They are implemented in C.

C is a great language, but as someone said here, there is only so much time.

Learning to program in C taught me to appreciate how amazingly powerful modern computers are, even off-the-shelf commodity hardware. It helped me realise that if I code something and it isn't blindingly fast, I'm probably doing something wrong.

And how many people who can't even be bothered to learn C will dive even deeper into assembly?

And yes, I would think anyone who books flights/drives/drinks water for a living would be well served by learning something of the tools of their trade.

We are not booking flights or taking driving lessons. We are (hopefully) engineers and scientists. I find it perfectly acceptable that you chose to accept the abstraction of the machine. You may benefit from knowing electrical engineering, but I believe the benefit is slight. Knowing the history of the field is non negotiable however.

You don't need to know how to heel-toe to drive to the market, but pretending that it's not a useful skill to master driving is ridiculous.

Are you driving to the market, or are you a serious professional?

I was able to learn that deeper knowledge without learning C, via Sinclair Basic, Turbo Basic, Turbo Pascal, Z80 and 80x86 Assembly, before eventually learning C.

And it wasn't even proper C, it was RatC at the time.

There are plenty of alternatives to expand our brain in systems programming, and even better they show we don't need to compromise on security to do it.

However, yes one needs to learn C, because it has snuck everywhere and as the COBOL of systems programming languages (ruffly 10 years younger), it isn't going anywhere.

Agreed, it helps you understand what’s been abstracted away from you in many higher level languages. From a security perspective I think you learn to avoid C wherever possible.

Isn’t that the same argument we used to use with Latin? It would be nice if we could all stop time and learn the fundamentals better. However, in the reality we actually live in, most of my coworkers don’t even have time to truly learn SQL, let alone C.

I never happen across works written in Latin. I come across a lot of C code.

Lorem ipsum?

From the wikipedia entry[1]:

Lorem ipsum is typically a corrupted version of De finibus bonorum et malorum, a 1st-century BC text by the Roman statesman and philosopher Cicero, with words altered, added, and removed to make it nonsensical and improper Latin.

I don't think that really counts as "latin", any more than hackertyper[2] counts as C code.

[1] https://en.wikipedia.org/wiki/Lorem_ipsum [2] https://hackertyper.net/

Yeesh, is nothing sacred?

Chick-pea must be rolling in his grave.

On behalf of the poster I'd like to say mea culpa. It was kind of an ad hoc example though, and perhaps they didn't mean that specific example per se but more the large number of Latin phrases one comes across daily without really thinking about it.

I guess we could continue this thread ad infinitum because there are plenty more examples but I'll leave this as de facto proof that Latin remains used: Et cetera.

veni, vidi, exempli gratia

... AD, et al, ibid, n.b., i.e., e.g., etc.

To be fair, I've encountered Latin the most in philosophical texts which I can't say are read all that often

It isn't necessary to learn Latin in order to be familiar with words that are de facto English words.

I would posit that for Latin words and phrases to have become “de facto” English is ex post facto the historical prevalence of people having learned Latin.

Yes. If you use e. g. numerical libraries, and wonder what really does this algo do often you look at C. If you dig too deep then you look at fortran though...

Reply on news.ycombinator.com