[the-printer]

Is it really gatekeeping? Does this opinion (that was valid and useful to me) carry any preventive force that the term suggests?

[Aurornis]

The colloquial definition of "gatekeeping" doesn't require literal preventative force.

See https://www.urbandictionary.com/define.php?term=Gatekeeping

[the-printer]

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.

[sophacles]

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:

https://www.urbandictionary.com/define.php?term=Gatekeeping

[bryancoxwell]

It dissuades people who aren’t comfortable with Makefiles and Vim from using C, so I’d agree it’s gatekeep-y.

[seabird]

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.

[vidarh]

I've used C since the 1980's, and vim most certainly "spooks" me. C and make does not

[flohofwoe]

> 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.

[seabird]

I am, but C99 doesn't fix the various sharp corners and gotchas that are littered throughout language.

I don't say any of this as a dig at C, but at ~50 years old, it definitely shows its age.

[pjmlp]

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.

[stjohnswarts]

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.

[kragen]

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 not

of 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 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

[ryan-c]

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.

[kragen]

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)

[ryan-c]

I'm sorry, I'm having trouble hearing over the sound of that poor load bearing "generally" creaking under the stress of the thread. ;-)

Yeah, the "C is the universal ABI" problem is... annoying. Hopefully something safer eventually replaces it in that niche.

Also, I think the main reason I use a lot of the tools I do is just "suck cost fallacy".

[kragen]

heh

what the fuck is it with these people that they flagged your comment upthread