3 ms·

Code is much harder to maintain than to write. You'll save 6 hours writing it, only to spend many more maintaining it. Of course, eventually the AI will be sma

Code is much harder to maintain than to write. You'll save 6 hours writing it, only to spend many more maintaining it. Of course, eventually the AI will be smart enough to do maintenance, but at that point it'll basically take the job of anyone who does their job entirely on a computer.

KingOfCoders 3y ago
I do think, as soon as you stop caring about the code, this goes away. Just like with garbage collection, "we need to have proper malloc and free". The moment we gave this to a JVM, the problem went away. It means giving up control and don't care about the internals (0.1% of developers today care about the detailed internals and performance of GCs.)
- goatlover 3y ago
  Except that the JVM didn't take over all of programming (as some predicted back in the late 90s/early 2000s). C, C++ and Rust are popular programming languages today. Probably because Java isn't a good systems language, or the ideal for all embedded tasks. And that tons of widely used code is written in C/C++.
  - szundi 3y ago
    Let’s assume then that there is no GC for parts of the code. It’ll be constantly regenerated
    - xboxnolifes 3y ago
      > It’ll be constantly regenerated What do you mean by this?
      - vrighter 3y ago
        probably a misunderstanding of what the GC is and does. The GC works on data, not code.
        staunton 3y ago
        I think the generous meaning would be an experience like Rust (handles memory allocations/deallocations, doesn't mess up unless you really mess up) except that it doesn't complain all the time when you're doing "ok things" and maybe even makes it impossible in practice to mess up. It could even dynamically decide between using a GC for a given program or not, depending on what makes more sense (thus "constantly generating it").
  - pjmlp 3y ago
    Mostly because Java did the mistake to gate AOT behind commercial licenses, thus C and C++ kept being relevant for many tasks requiring AOT workloads. Had Java shipped a AOT compiler in the box for free, Go would not happened, nor many of the workloads that Go has been taking away from C and C++ on the distributed computing space and devops. C and C++ would have their use cases reduced to kernel programming, embedded, games and like else.
- philipswood 3y ago
  The problem didn't go away. It got better, but memory leaks are a thing in Java too.
dontupvoteme 3y ago
Besides the fact that they're actually fairly good at maintaining code/building tests, they don't get bored maintaining code like people do I'd say that's a far easier task than development (from the POV of a machine) because you already have a known "standard" to aim for, and there's much less need for 'lateral thinking'. Anytime you have a delta you can initiate responses (even incredibly minor ones) And you could send a proverbial army of them at any small regression or complaint for almost no cost.

KingOfCoders 3y ago

I do think, as soon as you stop caring about the code, this goes away. Just like with garbage collection, "we need to have proper malloc and free". The moment we gave this to a JVM, the problem went away. It means giving up control and don't care about the internals (0.1% of developers today care about the detailed internals and performance of GCs.)

goatlover 3y ago
Except that the JVM didn't take over all of programming (as some predicted back in the late 90s/early 2000s). C, C++ and Rust are popular programming languages today. Probably because Java isn't a good systems language, or the ideal for all embedded tasks. And that tons of widely used code is written in C/C++.
- szundi 3y ago
  Let’s assume then that there is no GC for parts of the code. It’ll be constantly regenerated
  - xboxnolifes 3y ago
    > It’ll be constantly regenerated What do you mean by this?
    - vrighter 3y ago
      probably a misunderstanding of what the GC is and does. The GC works on data, not code.
      - staunton 3y ago
        I think the generous meaning would be an experience like Rust (handles memory allocations/deallocations, doesn't mess up unless you really mess up) except that it doesn't complain all the time when you're doing "ok things" and maybe even makes it impossible in practice to mess up. It could even dynamically decide between using a GC for a given program or not, depending on what makes more sense (thus "constantly generating it").
- pjmlp 3y ago
  Mostly because Java did the mistake to gate AOT behind commercial licenses, thus C and C++ kept being relevant for many tasks requiring AOT workloads. Had Java shipped a AOT compiler in the box for free, Go would not happened, nor many of the workloads that Go has been taking away from C and C++ on the distributed computing space and devops. C and C++ would have their use cases reduced to kernel programming, embedded, games and like else.
philipswood 3y ago
The problem didn't go away. It got better, but memory leaks are a thing in Java too.

dontupvoteme 3y ago

Besides the fact that they're actually fairly good at maintaining code/building tests, they don't get bored maintaining code like people do I'd say that's a far easier task than development (from the POV of a machine) because you already have a known "standard" to aim for, and there's much less need for 'lateral thinking'. Anytime you have a delta you can initiate responses (even incredibly minor ones) And you could send a proverbial army of them at any small regression or complaint for almost no cost.