3 ms·

For the record - There is no evidence what-so-ever that “performance trades with developer time”. 99% of the time, reasonable performance is a skill issue, not

• deleted 3y ago
  [deleted]
• Capricorn2481 3y ago
  > There is no evidence what-so-ever that “performance trades with developer time”. 99% of the time, reasonable performance is a skill issue, not a developer time issue. I think this is reductive. There are lots of things people can do in Python that would be slower to write in C, and no amount of skill is gonna close that gap. > In actual fact, if you look at “clean abstractions” and other nonsense, you can see that higher developer time actually seems to equate to lower performance. As we all also know, the best indicator of bug count is lines of code, so adding in all these abstractions that adds lines of code not only make code slower, but also results in more bugs. I understand the argument against bad abstractions, but what abstraction is adding lines of code? I think we can agree that most of the time abstractions are to reduce lines of code, even if they may make the code harder to read. > Higher dev time = lower performance and more bugs (assuming higher dev time is coming from trying to abstract) I'm sure there are lots of projects that are buggy with little abstractions.
  • wredue 3y ago
    >I think this is reductive. There are lots of things people can do in Python that would be slower to write in C, and no amount of skill is gonna close that gap. Write python without import statements and then try to make this claim again. C using libraries is often as easy, or easier than python with imports. You don’t get to let python use someone else’s prewritten code while C has to do it from scratch and then say “see”. It’s a false equivalence. >I understand the argument against bad abstractions, but what abstraction is adding lines of code? I think we can agree that most of the time abstractions are to reduce lines of code, even if they may make the code harder to read. I don’t agree with this claim. I’d say go check out YouTube video from people like Muratori who tackle this claim. We have no measurements one way or another, but if I was putting money down, I would bet that nearly all abstraction that occurs ends up adding lines instead of saving them. >I'm sure there are lots of projects that are buggy with little abstractions. I’d tend to agree that the evidence shows this, given that the vast majority (and it’s not even close) of bugs are measurably logic errors.
    • Capricorn2481 3y ago
      But we're not talking about Python using libraries and C using libraries. We're talking about pythons basic language features and what C patches in with libraries. Which makes a huge difference to me. > I don’t agree with this claim. I’d say go check out YouTube video from people like Muratori who tackle this claim. We have no measurements one way or another, but if I was putting money down, I would bet that nearly all abstraction that occurs ends up adding lines instead of saving them. We may not have measurements of the trend, but we can measure it on each abstraction fine. How many lines of code is your abstraction and how many lines would you have to duplicate if it wasn't for your abstraction? If you're not saving that much, don't make the abstraction. Again, this isn't talking about maintainability. I still question the claim that less lines of code means less bugs, but I know it's a popular one. In my experience, it's the terse code that's doing a lot that winds up being buggy. I prefer things to be longer and explicit, so you're talking to someone that doesn't even like abstractions that much unless they're necessary. > I’d tend to agree that the evidence shows this, given that the vast majority (and it’s not even close) of bugs are measurably logic errors. I don't think this premise you propose is obviously false, but we have lots of evidence that memory bugs are the cause of most bugs.
      • wredue 3y ago
        >pythons language features The standard library is still a library. Python doesn’t provide very much as a language feature. There are pros and cons to standard libraries. If we were talking about brand new C with not a massive community of quality libraries, then yeah. But we’re not. We are talking about a language with a half century of great libraries and frameworks being provided. >memory bugs cause most bugs Yeah no. Not even close. You’re thinking of Microsoft’s citation that 50% of their security bugs are memory safety, but that’s not 50% of all bugs. Basic standard logic bugs are far and away the largest contributor to bugs. The way we know this is that language choice virtually doesn’t matter. On the whole, developers write 20-30 bugs per 1,000 lines of code regardless of language, so memory errors simply cannot be the largest contributor to bugs.
        • Capricorn2481 3y ago
• Xeamek 3y ago
  I kinda agree, but skill issue can be easily extended to time issue. Because it takes time to skill up. And also, if you put higher bar on require skill level, you inherently get less developers, which means more work per developer which then converts to time issue. Obviously it's not a one to one, because great dev will spend less time doing good job then a clueless one making a mess, but still
• kayodelycaon 3y ago
  If that was true, we should all use assembly because C is too inefficient. Abstraction layers are necessary.