6 ms·
I don't quite understand the sentiment. So, let's say we have a project. For whatever technical (or social, historical, religious...) reason, C is chosen as th
by heisenzombie 3y ago
I don't quite understand the sentiment.
So, let's say we have a project. For whatever technical (or social, historical, religious...) reason, C is chosen as the right language.
Why does that imply that the programmers on that project should therefore write that C code in a terminal, with no linter, code formatter, static analysis, test runner, etc.?
- isaacremuant 3y agoWeird strawman. Those tools all run on terminals. IDEs use tools that run on terminals. Teams can use a combination of different IDEs and run the tools at different levels or their pipelines, which necessitate that they be automatable (and not GUI only).
- circuit10 3y agoYou're missing the point, they aren't saying "your development process should never involve a terminal" but rather "you don't necessarily have to use this bare-bones setup which happens to be terminal based"
- icedchai 3y ago20 years ago, I worked on a C and C++ project that supported a billion dollar business. Almost everyone used vi. They used none of those other tools, and there were maybe a half dozen unit tests in the whole project. I sure hope times have changed.
- haggy102 3y agoWhy not advocate for better testing? What was preventing you from spending more time unit testing code running a billion dollar business?
- post-it 3y agoA project manager, probably. "Advocating for XYZ" costs emotional capital that I'm not necessarily willing to devote to a particular project, or to my employer at all.
- frutiger 3y ago> What was preventing you from spending more time unit testing code running a billion dollar business? Presumably they were busy generating billions of dollars of revenue.
- icedchai 3y agoAt the time, I was a junior engineer, barely out of school. This company was run, technically, by people with 30+ years of experience. They preferred manual testing. Also, I'll add that automated testing was definitely not as much of a thing in 2003 as it is in 2023.
- nerdponx 3y agoThe point that I think everyone else is missing is that C is actually hard to work with and write correctly. If your project is sophisticated enough that you can't get by with basic tools, then maybe C isn't the best language for your project.
- dotnet00 3y agoI think this idea of "basic tools" is highly debatable, especially with developers who are young enough for heavy IDEs like visual studio to have been their intro to coding (or similarly for people who enjoy programming but aren't so invested in the entire computer software stack to really care about knowing their environment particularly well). Eg while I enjoy understanding all the layers of software in a computer and am perfectly comfortable with vim and a makefile (although I prefer vscode and cmake), most of the other developers I work with are just as competent with C, but can't really function if they can't use visual studio. To them visual studio is the basic tool and vim+make are advanced tools.
- nerdponx 3y agoI meant "basic" in the sense that it does not have a lot of helpful features for developing complicated applications. Whether or not that's easy or hard for any individual to use isn't really relevant. That said, Vim has some IDE-like features, moreso for C (by default) than some other languages. Again, the point is that C is complicated and hard to work with as you scale up into a bigger project, not that my tools are better than your tools.
- stjohnswarts 3y agomore gatekeeping. If I'm using C I want to use modern tools like every other language. If my environment doesn't have a debugger, tools like valgrind, linter, etc I don't have any use for it.
- nerdponx 3y agoPlease see my reply to the sibling comment. It's not gatekeeping, it's meant to be a criticism of the C language itself.
- ryan-c 3y agoThe only intended implication was "C is generally not appropriate for complex projects". There are, of course, always exceptions.