I did not read this as gatekeeping, rather I read it as an opinion on the suitability of C for kinds of project. If vim + make isn't enough, then C is probably not the appropriate language. Not that you shouldn't use C if you don't use vim + make.
We always talk about how good engineers "choose the right tool for the job". I don't think expressing an opinion on what the right kind of job is for a particular tool should be out of bounds. (Setting aside whether the opinion is correct or not.)
Editor preference was not intended to be the focus of my comment, it was more me being incredulous that someone would build something in C which necessitated Docker.
If someone wants to do that anyway, I am going to be perplexed that C was the language choice rather than golang or rust, and perhaps worried about C being a footgun WRT security, but whatever.
Yeah, the Docker part makes sense. You don't need it, but it can be nice. Don't want mundane differences between devs' setups to get in the way, especially when they're not all the same OS.
That's usually not the case. You work on existing code base and you want your editor to be able to explore it efficiently. Changing language is rarely an option unless you happen to enter a project at the very start.
It is gatekeeping. The poster was not offering advice, they were being actively discouraging. You can argue shades of grey, but at the end of the day this is an unsolicited discouragement, and an arbitrary out-grouping.
The fact that you don't see this as problematic, is problematic.
There is no gatekeeping. There is a suggestion that C is best used for projects that have builds no more complex than a Makefile configuration. There is explicitly no ~judgement~ limit on what ~kink~ text editor one may use to edit the files.
the fact that they don't see it as problematic means that they didn't misinterpret the comment the way you did, which is because they know things you don't
thus hegemonic institutions reinscribe the kyriarchy generation after generation by perpetuating a hierarchical opposition between "knowledge" and so-called "ignorance", which is socially constructed to be inferior, less than, but which serves the purpose of distinguishing the graduates of elite institutions (to which access is mediated by the financial privilege of the bourgeoisie) from the subaltern underclass; thus "knowledge" serves the interests of capitalism by reproducing oppressive class divisions, enabling the continued exploitation of the working class
what could be more problematic than that?
but if you're interested in learning something and not just playing word games to gain status by putting others down, i problematically mansplained what you're missing in https://news.ycombinator.com/item?id=37083233
The proposed solution of a text editor and makefile is a lot easier to setup than the what's proposed in the blog post, I would call this the opposite of gatekeeping.
I get that, but even figuratively, it's a relatively harmless opinion that can only achieve as much by way of influence or control as readers are willing to allow the anonymous commenter to hold over them. There's more to learn if we confront the opinion by its premises (as shown by other responses to the comment) than by subjective moral grounds.
The term has become common on the web to refer to enthusiasts trying to control how people enjoy/use a term or participate in an activity - for instance "real fans only like the stuff from before $album" or "only filthy casuals play the game that way" (or "you shouldn't use C if you want modern, good tooling"). This might be worth reading through:
If vim and make are spooking somebody, they need to turn tail and run the fuck away from C. I love it to death, but it's a frustrating experience from another era. vim and make are the least of your worries when dealing with it.
> but it's a frustrating experience from another era
Are you using C99 features? I find the "new" features extremely enjoyable, it feels like a different language compared to C89 or the common C/C++ subset.
Started coding in 1986, used my first UNIX (Xenix) in 1993, the only thing I care about vi, is knowing enough to rescue me when there isn't anything else installed to edit files.
Yep, plenty of really good windows/macos programmers have never touched vi or emacs. I'm not sure why users of those are so elitist. I tend to prefer vim editor keystrokes in my editors but that's just because I got used to it from college and terminal editing.
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 not
of course you need a testing framework
if (!strcmp(argv[1], "--run-tests")) return run_tests();
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 fuck
what 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
I'm not a he (some other folks used "they" which is fine), but this is otherwise a pretty good interpretation - it absolutely was a dig at C, not elitism.
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.
oops, i'm sorry i misgendered you. i think i have fixed it now, but now the editing window has closed
on your other points i mostly agree, except that if i write a library in any popular 'modern' language, it can only be called from that language, which seems like a missed opportunity
and when i went back and compared development time logs, the development speed advantages of modern languages seem to be only a factor of 2 or 3 over c, once i get beyond a few hundred lines
which i guess is why linux, firefox, cpython, gcc, apache, poppler, libvte, and so on are written in c or occasionally c++. it's not because the authors didn't know about common lisp, scheme, ml, smalltalk, and so on, or couldn't figure out how to write a garbage collector
rust and some other unpopular modern languages look like they might change that situation (nim, zig, koka, a couple of others i can't think of right now)
You can write C how ever you want, doesn't mean it's the right language for the project. My team uses C++ a lot like Java, and turns out Java was the better tool for our use case.
They don't, cause the speed at which we have to implement new features means cutting corners. We write backends, none of which are performance-critical. A lot of faster algos that would take too long to implement in C++ get skipped, so in the end it's slower than partner teams' Java code that does similar things, but again it doesn't matter as long as nobody notices the latency.
This is not a matter of taste. VSCode is an alien in the C world. It's clumsy, demanding and offers plenty of useless features, whereas the simple stuff is hard / impossible to get to work.
If you work on a C project, you need to be ready to have to edit source code, at least minimally, from an environment that doesn't have GUI. You will have to interact with pagers, man readers, readline a lot -- it's a lot more convenient if your editor works in the same way as those tool.
You are just creating unnecessary problems when you use VSCode or a similar editor. And I cannot think about a single benefit that would come from using it. Beside other things, it's just a crappy text editor... the only thing that's going on for it is that it's a Web browser application... which is kinda worthless when it comes to a typical C project.
If you're using vsc then C is absolutely not the right language. If your code can't fit in your head when you're writing it then you have no hope of debugging it. Vsc very much encourages your code to grow as large as the machine you're wiring it in can handle.
This is called gatekeeping and it’s not helpful.
It’s fine to write C in vim/emacs/nano if you want.
It’s fine to write C in Visual Studio Code if you want.
It’s fine to write C in CLion if you want.
There is nothing wrong with any approach and no need to gatekeeper an entire programming language based on editor preference.