| i think that's the opposite of the intent they're saying that you don't need to be comfortable with ides and fancy debuggers and cmake and language servers and game development engines and ci pipelines and all kinds of complicated stuff to write c successfully a bare-bones text editor and the most minimal build system are plenty and if they aren't plenty, they're not saying that's a problem with you, but with c i don't agree (ctags, valgrind, git, and gdb go a long way towards making c usable, and evidently c is the best language for a lot of things even ctags and gdb struggle with, like linux kernel drivers, and cmake evidently helps a lot if you care about ms-windows) but that's what they said, and you totally misunderstood them because you somehow got the idea that vim and make are some kind of super advanced tools rather than relics from the 01980s they're maybe a bit unprepossessing at first glance but mostly what they are is simple and primitive think of using a hammer rather than a cam-driven turret lathe you can go lower tech than make too now that cpus and c compilers are so fast while sleep 1; do # ci pipeline
gcc -Wall -funny -mtune=i69 *.c -lm -liberty -letmypeoplego -o proggie && # build system
./proggie --run-tests # test runner
done
c compiles fast enough that this scales to several thousand lines of code, c++ very much does notof course you need a testing framework if (!strcmp(argv[1], "--run-tests")) return run_tests();
... three seconds latair ... int run_tests()
{
return test_ui() ||
test_network() ||
test_parsing();
}
int test_parsing()
{
assert(trees_equal(parse("3+4"),
parse("3 + 4")));
assert(!trees_equal(parse("3+4"),
parse("3 + 5")));
...
}
now i'm not saying you shouldn't write a test runner in unity and distribute your ci pipeline with zmq and mqtt and whatever the fuck. better ux is worth my weight in gold, and i have programmer gut. also zmq is metal as fuckwhat i am saying is that the difference between no test runner and an infinite loop in bash is much bigger than the difference between the bash loop and circleci or gitlab pipelines. so don't be intimidated by articles like this which make it sound like you need a team of phds to set up a test runner. writing tests and running them is what helps, not so much stylishness except for version control. a build script in shell is a serviceable alternative to make, but cp -a proggie/src snapshot.$(date +%Y-%m-%d) is not a serviceable alternative to git also if 3d test runners with inotify and particle systems with custom shaders mean that people write more tests and see the tests fail sooner after they break shit, that could make a real difference |
If you're going to learn a bunch of modern tooling and start a green field project that justifies that complexity, C is generally a poor choice. Learn a modern language.
I use C somewhat regularly, including for kernel stuff, embedded, and legacy code.
Mostly, though, when I use C, it's because I'm doing a small thing that I need to be very fast, and I haven't yet bothered to get comfortable with Rust.