Announcement

Collapse
No announcement yet.

GCC Is Still Months Away From Transitioning To Git, Reposurgeon Being Ported To Golang

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by AndyChow View Post
    Currently: C, C++, Objective-C, Objective-C++, Java, Fortran, Ada, and Go. That's 8. And they have variants in the standards (ex C89, C99, C11, C18). For the architectures, I'll let you do the research.
    You do realize that C/C++ and Objective-C/C++ are really just base languages with an extended variant? They don't count as two separate languages. Also, the developers finished completely nuking GCJ (Java) from the codebase over two years ago, which kind of questions on your research on the subject.

    Good code doesn't rot. Banks still run the same Fortran code that they did in the 80's, just on larger mainframes.
    At what point did I claim anything to the contrary? Because the issue here was a major project sticking to a bad tool because they want to keep in a decade and a half of version history for the very rare occasions they need to go back more than a couple of years to track down bugs.

    Also, the reason why you still see banks running their old mainframes with Fortran code is the cost of not only moving to something more maintainable, but also the rather extreme consequences of potential business interruptions as they move to something more maintainable. However the reality is that these systems will all have to simple be retired or moved to something more modern for the simple reason that most of the people with the skills necessary to maintain them have retired years ago.

    It really doesn't matter how well you document your code when there's nobody with the specific skills necessary to pick up where you left...
    Last edited by L_A_G; 12-19-2018, 05:48 AM.
    "Why should I want to make anything up? Life's bad enough as it is without wanting to invent any more of it."

    Comment


    • #22
      Originally posted by jntesteves View Post
      By the time he finishes, git itself will have been superseded by something with a much superior design. Possibly pijul.
      git will be around for decades due to the network effect.

      Plus, even though people in tech love to mock mom and dad and grandpa and cousin Jane for refusing to learn Linux, shell, etc... the truth is that far too many people inside the tech industry fought like hell against the move from CVS to SVN, fought like hell against the move from SVN to git, and will fight again when git is superseded. It doesn't matter whether the replacement is an improvement, they just don't wish to learn something new when they're comfortable with something they already know.

      Comment


      • #23
        Originally posted by AndyChow View Post
        Good code doesn't rot. Banks still run the same Fortran code that they did in the 80's, just on larger mainframes.

        I maintain my original comments about reposurgeon. It's worth the wait.
        Have you seen reposurgeon code? https://gitlab.com/esr/reposurgeon/b...er/reposurgeon A cursory look shows:

        * The entire thing rests in a single 14K LOC file. Very hard to navigate.
        * 8-10 levels of nested ifs and fors.
        * Variable names such as "r" and "v" that give you no clue wtf they are.
        * Wheel reinvention such as "class Date(object):"

        This code is _nasty_, it is write only, hardly "worth the wait" IMO.

        Comment


        • #24
          Yeah, why aren't they just tossing out 20+ years of commit history, what a mystery.... Perhaps it's because GCC isn't just some fly-by-night toy project, and they care about being able to properly bisect issues later on? I also reject this idea that "rarely updated portion of GCC" means "unimportant part of GCC to users".

          Comment


          • #25
            Originally posted by paulpach View Post

            Have you seen reposurgeon code? https://gitlab.com/esr/reposurgeon/b...er/reposurgeon A cursory look shows:

            * The entire thing rests in a single 14K LOC file. Very hard to navigate.
            * 8-10 levels of nested ifs and fors.
            * Variable names such as "r" and "v" that give you no clue wtf they are.
            * Wheel reinvention such as "class Date(object):"
            You're looking at the old Python one. The new one has 21K LOC.

            But yes, I've looked at some of the code, and see no issue.

            Comment


            • #26
              Originally posted by AndyChow View Post

              You're looking at the old Python one. The new one has 21K LOC.

              But yes, I've looked at some of the code, and see no issue.
              Here is the go version
              https://gitlab.com/esr/reposurgeon/b...reposurgeon.go

              * 21K LOC in single file. Why not split this into multiple files? having files larger than 500 LOC is already a smell, 21K is very hard to navigate.
              * very high cognitive complexity. There are functions there that go 8-10 levels of nested ifs and fors. Should be refactored into multiple functions

              That said, the code does look better. He no longer have such massive functions and he names his variables better.

              Comment

              Working...
              X