11 ms·
Genuinely asking: Why many programmers need tools to enforce something upon them? Why not they can't take slow, be mindful about what they write and add a coup
by bayindirh 3y ago
Genuinely asking:
Why many programmers need tools to enforce something upon them? Why not they can't take slow, be mindful about what they write and add a couple of layers as pre-commit hooks? Like a code formatter and maybe a linter?
This makes me sad. Programmers have the knowledge base to make some of the most sophisticated things bend to their will, and they tell a programming language is bad, because they can make mistakes with it. You can cut yourself while chopping onions, too, if you're not careful.
When I code C++, I generally select the structures/patterns I gonna use, use them, and refactor my code regularly to polish it. Nobody enforces this on me, but this is how I operate. I add a formatter to catch/fix the parts I botched on the formatting department, and regularly pass my code through valgrind to see whether it makes anything funny on the memory department.
- dale_glass 3y ago> Why many programmers need tools to enforce something upon them? Why not they can't take slow, be mindful about what they write and add a couple of layers as pre-commit hooks? Like a code formatter and maybe a linter? Why would I want to? Most of that is boring stuff that's hard to get consistently right and highly amenable to automation. Automation is what the computer is good at, it can have that job. Like, why would I want to spend more mental bandwidth on tracking down whether every new goes with every delete than strictly necessary? Yeah, once in a while something is highly performance sensitive and it pays to design it just right for the use case. But it still tends to be surrounded with hundreds of other things that will do just fine with a smart pointer.
- chris_wot 3y agoSo use RAII and smart pointers. I think that's the point.
- dale_glass 3y agoYes, exactly what I'm saying. Use tooling to do the boring parts of your job.
- chris_wot 3y agoIt’s not tooling, it’s the language.
- Novosell 3y agoLanguages are not tools?
- CyberDildonics 3y agoEvery programmer knows the difference the language and the tools surrounding it. This seems like you're trying to create a pointless semantic argument for no reason.
- bayindirh 3y ago> Automation is what the computer is good at, it can have that job. Pre-commit hook is automation. It formats the code and gives you linting notes the moment you write "git commit". > Like, why would I want to spend more mental bandwidth on tracking down whether every new goes with every delete than strictly necessary? It's not more mental bandwidth for me. Because I write the new, and directly delete at the point I need to, then I never think about it again. If I botch something, valgrind will tell me, even pinpointing it with line number. > ...other things that will do just fine with a smart pointer. If that works for you, use it. I have no objections.
- dale_glass 3y ago> Pre-commit hook is automation. It formats the code and gives you linting notes the moment you write "git commit". So isn't that a tool that enforces something upon the programmer? > If I botch something, valgrind will tell me, even pinpointing it with line number. What is the benefit of needing valgrind? Isn't it even better to have the task automated away so that the problem doesn't even come up?
- bayindirh 3y ago> So isn't that a tool that enforces something upon the programmer? It's a tool I voluntarily add to my workflow, which works the way I want, when I want, according to project needs. It's not a limitation put upon me by the language/compiler/whatnot. > What is the benefit of needing valgrind? Isn't it even better to have the task automated away so that the problem doesn't even come up? In most cases, performance (think of HPC levels of performance). If I don't need that kind of performance, I can just use the stack or smart pointers. If we're talking about moving to other programming languages, I'd rather not.
- dale_glass 3y ago> It's a tool I voluntarily add to my workflow, which works the way I want, when I want, according to project needs. It's not a limitation put upon me by the language/compiler/whatnot. I spent a lot of time maintaining a lot of Perl code. While it was generally very well written, it also made me a big fan of strict, demanding compilers. Perl is quick to write, but can have very high debugging costs since it'll let you get away with a lot that it shouldn't like having a function called with arguments but that completely forgets to retrieve them. Based on my experience, IMO any class of error that can be eliminated, should be. So my modern approach is -Wall, -Werrors, -Wextra, and anything else that can be had to that effect, all the time.
- belter 3y agoYou need to talk to Bjarne and Herb... "C++ Core Guidelines" - https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
- pjmlp 3y agoBecause not everyone has the same values, not everyone has an engineering background even though they like to call themselves engineers, most programming projects are delivered by external companies that don't care about quality unless it is required by law (aka liabilities).
- deleted 3y ago[deleted]
- johannes1234321 3y agoFirst of all: I am failable. I do make mistakes, even if I concentrate. Secondly I want to verify code others wrote. If a tool does the first pass quickly and automatically, I can quickly ensure some basic level of compliance and can focus on the relevant part. In the end it boils down to: Let the computer do what a computer does and do the things a computer can't. Doesn't say, one shouldn't think, but computers are there and are powerful, so use it. If the checker doesn't find anything: great. If it does: good it's there.
- Barrin92 3y agothe problem is of course that tools aren't particularly smart. When you create heavy handed restrictions in your language, you're not just eliminating mistakes, you're eliminating tons of potential programs that make perfect sense, that's to say you drastically reduce the expressiveness of a language. That's why Rust say, has an escape hatch. Unsafe Rust wouldn't exist if all you could write in it were mistakes. Async Rust is to put it plainly, a pain in the ass. These high level tools are more like chemotherapy. You hope that they kill more of the bad code before they kill you. They're not sophisticated, and it's fairly reasonable to prefer a language that let's you opt-in to stricter safety rather than opt out.
- ravenstine 3y agoSoftware development for at least the last 20 years has been about cranking out code.
- desdenova 3y agoThe fact that we now have languages enforcing safety makes them more desirable than a language that doesn't. If I'm writing a small toy project where I'm the only person messing with the code, I can totally do it in C, or even raw assembly if I feel like it. If anyone else will ever write to the same codebase, or the code is for a client/company, I want every automated static check I can possibly have.
- ModernMech 3y agoLook at it this way: every hour, people are coming across C++ for the first time. You can’t expect them to have the same discipline as seasoned programmers. The thing is that even if you teach them “the way”, there’s always a new batch who is clueless. You’re never going to get rid of them, and even the experts are going to make mistakes and take shortcuts. Better to have sane strict defaults with an escape hatch for experts rather than an open range filled with footguns for any newbie to pick up.
- deleted 3y ago[deleted]
- shadowgovt 3y agoThe biggest problem with C++ isn't that you can't write clean, structured code with it. It's that the language is so vast that the odds of any two developers working on two different projects agreeing on what that means are low. I programmed in C++ for a decade, then for a year or two at a second place, then picked it up again in a third... And all three places had nearly completely different best practice protocols. Pre-processor macros are banned, but deep template abstraction and CRTP abounds. Interface and implementation are separated even when templates demand they be in the same header chain, but here we do so by squirreling away the implementation in a separate file with a non-standard suffix instead of splitting it out but keeping it in the bottom of the same file. In my previous company, we used pointers to indicate the called function could mutate the data... In my new firm, pointers in interfaces are just about banned unless absolutely necessary and we indicate whether data could be mutated via const and documentation. The language is broad enough to let the developer change almost anything, but it is unfortunately broad enough to let competent developers build competing and equivalently (un-)safe styles.
- jeffreygoesto 3y agoEmbedded shop? MISRA? Sounds strangely familiar...
- cjfd 3y agoI agree with you. If those tool actually enforced good quality it would be one thing but what is actually being enforced is mediocrity and enforcing the power play of some individuals who have decided for all others what is good.
- e12e 3y ago> Why many programmers need tools to enforce something upon them? Why not they can't take slow, be mindful about what they write and add a couple of layers as pre-commit hooks? Like a code formatter and maybe a linter? Running a formatter and linter in a pre-commit hook is literally using tools to enforce things?
- bayindirh 3y agoI have noted elsewhere in the thread, but I think I was unable to express myself very clearly. What I really meant is enforced externally on the programmer, in the form of compiler, development environment setup (from elsewhere) or other guidelines, without any free will to tune or disable them. The layers I add are voluntary, just checks and balances I decided to add myself because I think they help me, and not enforced as part of the language or toolchain I'm forced to use. IOW, a self-respecting developer striving to do a good job can continuously sharpen themselves iteratively, tuning their processes and fixing the problems they see as they go along their journey. Perhaps pjmlp understood the gist of my comment, and his answer is a pretty nice hit on the head of the subject. Honestly, I'm coming from a point where programming is more of a passion which pays rather than work/job for me, hence I have an inner drive to do my best and improve continuously, and not everyone shares the same set of values or inner drive about programming, and want to be railroaded into an environment where they can do the absolute minimum to get things done.
- muststopmyths 3y agoThat is all well and good on a small team of senior people , but if your project has more than a handful, with mixed experience levels, you want tools to enforce a minimum standard before even getting to code review
- agentultra 3y agoBecause even the most careful C++ programmer still makes plenty of mistakes. Not the, "oops I cut my finger," kind. Those are usually found by linters and analyzers. More like, "there's a PCI breach and now we're liable for millions of dollars," kind: the semantics of C++ are hard to nail down and ensuring that private data doesn't leak to other threads is almost impossible to get right with only knowing C++ and being careful. You generally need to use higher-level tools for that kind of work: Coq + the Iris framework, for example, in order to prove that your system can freely share memory and not leak secrets so long as X, Y, and Z hold, etc. Or you need to run a ton of tools like Jepsen to find if your system behaves the way you think it does. What baking more of the specification language into the programming language does (ie: better type systems) is enable us to have more of these guarantees earlier in the development process when changes are cheaper and faster to make (at the expense of requiring more expertise to use them).
- marcosdumay 3y ago> Why many programmers need tools to enforce something upon them? You can always count on the threads about C or C++ to have somebody ask questions like this. As a hint, you won't see it asked on any other context. The answer is "all", no exceptions. It's widely known. For decades. In fact, C wasn't even universally used when people discovered this.