3 ms·

Cynicism rarely wins points on Hacker News.

by jhrmnn 7y ago

mojuba 7y ago
I was replying to: > When good developers work on something it should get better over time. Which is obviously wrong as a generalization. Again, I have nothing against GCC and its team, but codebases in general do tend to get worse over time or at least between complete rewrites, especially when it's a collective effort and especially if it's voluntary open source work, no matter how important it can be.
- cycloptic 7y ago
  That has not been my experience. If it's important the bugs tend to get fixed quickly. The developers can't fix bugs they don't know about. If you find people to be unresponsive, feel free to help chip in by fixing bugs yourself or sponsoring someone else to do so. Or just stick to an old version. This isn't some mysterious process that you have no insight into. You can go the GCC/Audacity/Inkscape bug trackers now and see what is actually happening.
  - mojuba 7y ago
    You know I want to be very honest about this (since I've already got a lot of downvotes in this post, no harm in getting more :) Having been in this industry for 30 years I firmly believe that bugs should be fixed by those who introduced them. This: GCC 7.5 is a bug-fix release from the GCC 7 branch containing important fixes for regressions and serious bugs in GCC 7.4 with more than 215 bugs fixed since the previous release. is not normal (215 bugs!) and no, I'm not going to go and pick a bug to fix in this source code. I'd rather contribute to LLVM which seems much cleaner and higher quality overall.
    - cycloptic 7y ago
      Then you should know that sometimes the best person is not available. If you want to fix bugs in LLVM then I'm sure you will be welcomed.
      - mojuba 7y ago
        Sure, but I'm talking about the style of programming where people throw code left and right with the expectation that others (users, QA) will find bugs, catalog them nicely, assign numbers, and then hopefully someone else will fix all of it. This is the attitude in both commercial and open/free worlds. Whereas the way it should be is: you are responsible for testing your own code and changes, not users, not your QA department. You are personally responsible. Of course you will make mistakes, but not 200 at a time. You might have multiple issues in your code, but it is fine as long as you have tested as much as you could before committing/pushing.
        cycloptic 7y ago
        That might sound good when you write it but is not at all how anything ever works out practically.
- tremon 7y ago
  Why is that "obviously wrong"? To me it sounds more like a truism (or a circular argument, since the definition of "good developer" includes whether they improve the products they work on). In other words, if that statement is false, it follows that software products can only improve if left to languish (i.e. bitrot must have a positive effect), or if the product is worked on by bad developers. And why would they be called bad developers if they succeed in improving the product they work on?

Cynicism rarely wins points on Hacker News.

by jhrmnn 7y ago

Cynicism rarely wins points on Hacker News.

I was replying to: > When good developers work on something it should get better over time. Which is obviously wrong as a generalization. Again, I have nothing against GCC and its team, but codebases in general do tend to get worse over time or at least between complete rewrites, especially when it's a collective effort and especially if it's voluntary open source work, no matter how important it can be.

cycloptic 7y ago
That has not been my experience. If it's important the bugs tend to get fixed quickly. The developers can't fix bugs they don't know about. If you find people to be unresponsive, feel free to help chip in by fixing bugs yourself or sponsoring someone else to do so. Or just stick to an old version. This isn't some mysterious process that you have no insight into. You can go the GCC/Audacity/Inkscape bug trackers now and see what is actually happening.
- mojuba 7y ago
  You know I want to be very honest about this (since I've already got a lot of downvotes in this post, no harm in getting more :) Having been in this industry for 30 years I firmly believe that bugs should be fixed by those who introduced them. This: GCC 7.5 is a bug-fix release from the GCC 7 branch containing important fixes for regressions and serious bugs in GCC 7.4 with more than 215 bugs fixed since the previous release. is not normal (215 bugs!) and no, I'm not going to go and pick a bug to fix in this source code. I'd rather contribute to LLVM which seems much cleaner and higher quality overall.
  - cycloptic 7y ago
    Then you should know that sometimes the best person is not available. If you want to fix bugs in LLVM then I'm sure you will be welcomed.
    - mojuba 7y ago
      Sure, but I'm talking about the style of programming where people throw code left and right with the expectation that others (users, QA) will find bugs, catalog them nicely, assign numbers, and then hopefully someone else will fix all of it. This is the attitude in both commercial and open/free worlds. Whereas the way it should be is: you are responsible for testing your own code and changes, not users, not your QA department. You are personally responsible. Of course you will make mistakes, but not 200 at a time. You might have multiple issues in your code, but it is fine as long as you have tested as much as you could before committing/pushing.
      - cycloptic 7y ago
        That might sound good when you write it but is not at all how anything ever works out practically.
tremon 7y ago
Why is that "obviously wrong"? To me it sounds more like a truism (or a circular argument, since the definition of "good developer" includes whether they improve the products they work on). In other words, if that statement is false, it follows that software products can only improve if left to languish (i.e. bitrot must have a positive effect), or if the product is worked on by bad developers. And why would they be called bad developers if they succeed in improving the product they work on?