Hacker News new | ask | show | jobs
by pritovido 2297 days ago
C is a very simple language. I have used just the official old book to create a compiler for it:

https://www.amazon.com/Programming-Language-2nd-Brian-Kernig...

The best thing you can do is finding some open source code that interest you, read it and write it.

For example, I write my own controllers for CNCs, and there are lots of code for controlling stepper motors out there. I also learned OpenGL and sockets this way long time ago.

On the other hand, C is a terrible language for any big project unless you automate it some way.

I use mostly lisp in order to write C code automatically. C is too low level for writing any substantial code. Lisp has things like Macros(nothing to do with c macros) that can make you write code 10x, to 50x faster easily.

3 comments

> C is too low level for writing any substantial code.

Do people not realize that projects like Linux and pretty much every car's ECU software (pretty "substantial" in my opinion) is written in C before claiming this? I'm not saying these software are 100% bug free, but this claim isn't accurate either. You _can_ write substantial C code when you have a good understanding of the tooling around it. Mere learning the syntax isn't enough.

I'm so tired of hearing about what you can't do in C and the "only thing" it's good for. You can't write big systems. It's only for embedded.

It's such a crackup, because the number of developers who haven't got the memo on this is really staggering. How many lines of code is GTK? Or Postgres? Or Nginx? Never mind languages and operating systems.

I suppose Vim (~335,000 lines) or git (in the 200,000 range) is not "large" in comparison to some things, but I suspect that's actually the kind of number people think is "too big for C."

People also seem not to realize that the reason that Python library is so fast, is because it's actually wrapping C code. And that code is very often not doing some frighteningly low-level thing, but just doing ordinary stuff.

As someone who works on a significant C codebase (IOS-XR), my 2 cents:

1. Most of the large userspace C codebases that still exist today didn’t have many alternatives when they were started.

2. Any non-trivial C codebase relies much more on runtime testing than other languages. In other words, with other languages, you can get away with fewer tests while achieving the same level of quality.

Note that you should be striving for comprehensive tests regardless of language; this is just an observation.

The "steel man" version of this argument is that, if you're embarking on a new codebase which you have good reason to expect will grow to be large, have a very good reason to write it in C, or use a more appropriate language.

There some reasons to do it, but fewer than there were when most of the projects you've name-checked were started.

I'll skip the part where we review what the other options are, this is HN, we've all seen that thread before.

I take your point about the age of some of these projects (though it's not like there weren't any "more appropriate" languages around when most of them started). And I'll also admit to agreeing with the idea that choice of language is nearly always a sociological matter before it's a technical one.

But I'm not really arguing that C is the best choice for large projects. I'm just pointing out the fact that many, many people just completely ignore that advice. They are ignoring that advice today -- right now. With new projects. And they've "seen that thread before" too. It's not just legacy, or lack of awareness, or whatever.

Maybe it comes down to what the "very good" reason actually is. Because given the amount of C hacking going on, I wonder if the "good reasons" we hear about nearly every day on HN aren't the most important ones for the quite vast number of people merrily hacking away in a language that is now decades old.

Knowing how some big software systems lived through more than a decade each, I'd claim that the less they used C++ and the more used C++ compilers to write a C-like code they were better. The worst parts of the project were exactly those that used the "cool" C++ features.

C is much better for really long-lived projects than C++ is. C++ is a maintenance nightmare in comparison.

Linux kernel is also a good and famous big long-lived project which I claim would have never even survived had it been written in C++. Linus seems to have believed the same.

> C++ is a maintenance nightmare in comparison.

c'mon, all the super large projects - adobe software, ableton live, blender, autodesk, 3DS max, maya... all the major game engines (UE, CryEngine, Frostbite, etc), are written in C++, not in C. LLVM & clang are C++, and GCC is all C++ in new code with a fair amount of old code ported from C. All the major web browsers are C++ - and I'd wager most minor too.

If what you said was true we'd see much more massive projects in C and much less in C++ yet here we are.

I think you might be missing the main point of what this person is saying, which is:

"I'd claim that the less they used C++ and the more used C++ compilers to write a C-like code"

And I bet that's true. I doubt there's layers and layers of template metaprogramming in Ableton Live, or that Maya is a study in inheritance. Game engines, certainly, are C++ written as so-called "better C."

"Yet here we are" -- a place where people reinvent C and call it "data-oriented programming." /s

As the CVE database proves, just because one can do it, doesn't mean one should do it.

Liability can't come soon enough.

That, and I dislike the low-level vs high-level differentiation. It is relative, and more of a spectrum, IMO, and not that it is particularly useful anyway.
> The best thing you can do is finding some open source code that interest you, read it and write it.

Has reading source code in a language that’s unfamiliar to you shown to be of any real benefit to learning? It seems you need at least a little bit of foundational experience with it before your brain can even parse what you’re seeing in a beneficial way.

> Has reading source code in a language that’s unfamiliar to you shown to be of any real benefit to learning?

Absolutely! You start finding idiomatic patterns and "oh, so that's how they do it" kind of things. Find library functions you never knew about but now you do. Find weird things, and look them up in a manual/reference/SO/chatroom. Things that you might find in a book, but a book that covers all the idioms and practice and weird things is gonna be as thick as the bible, and it'll get outdated (it doesn't help that most books are focused on teaching the basics rather than showing off how to architect your application well). Things that you can learn the hard way by why not look and see and learn?

> It seems you need at least a little bit of foundational experience with it before your brain can even parse what you’re seeing in a beneficial way.

Nah, you just need programming experience (in a similar paradigm) in general. A lot of what you learned from languages before will translate.

Also OP mentioned that "I can write C" and "I've started reading 'Modern C'", so it's not like they're looking for their first Hello World snippet.

OP said they've got 15+ years of programming experience. At that point, picking up a new language is all about learning the vocabulary and idioms, plus the few unique or tricky or quirky things that don't show up in other languages (or that aren't obvious from looking at code). The fastest way to get to that vocabulary is to look at real code.

>Has reading source code in a language that’s unfamiliar to you shown to be of any real benefit to learning?

Yes, I think so. The parent has experience with other languages, like python, javascript and go. C has a very similar paradigm. If it were clojure it would be different.

I find exposition to new languages real usage the best way to learn them. I went to the UK to learn english, Germany to learn German, could be painful at first, but works, specially if you know a little about what is all about.

Your brain makes sense of everything by itself in a magical way. That is the way you learn your native language.

I'd tend to agree here also. I didn't start reading source code until a couple years in because I couldn't really put it to use. It becomes 10x more valuable when I was deep into my career learning from the big shots.

It _can_ help no doubt but not sure that's the best way to start. Especially with a language like C. It's not so straight forward without some training or CS education.

> It becomes 10x more valuable when I was deep into my career learning from the big shots.

Yeah well OP said they've 15+ years of experience so..

> Especially with a language like C. It's not so straight forward without some training or CS education.

I agree with pritovido, when they say C is a very simple language. Sure, it has grown its quirks and gotchas along with some cruft (the kind of things you wouldn't learn about in a CS curriculum anyway), but at its core it really is very simple.

For me there's almost no wisdom to assimilate when reading source code until I've given a fair shot at using the language and experiencing its obstacles. Then seeing other people overcome them is where almost all of the a-ha moments are.
You use Lisp to write C (on Microcontrollers)? Would appreciate more info on that.
You could consider this. https://ferret-lang.org/
Not the OP, but as I understand it NASA's JPL has been doing this for decades for space missions.
That a horrific mistake that MIT nitwhits used to teach students at the end of 6.001 - how to write opaque, horrible lisp programs in languages such as "C".