Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Trying to Understand Copilot's Type Spaghetti

rtpg.co

Post reply on HN
Print view View original

81–89 of 89 posts

Re: Trying to Understand Copilot's Type Spaghetti

#81

Post by dartos »

david-gpu wrote: post #79
mumblemumble wrote: post #71

So, that code gets me thinking about premature optimization. In the "verschlimmbessern born of optimizing the wrong thing because you didn't use measurement to guide your efforts" sense. The rule of thumb I hear is that, in a mature product, reading and maintaining code takes about 10 times as much effort as writing it in the first place. I've never tried to measure this myself, but it doesn't seem to be wildly off f…

Can you elaborate on this part? I am trying to understand. > in a mature product, reading and maintaining code takes about 10 times as much effort as writing it in the first place Wouldn't that imply that rewriting a mature codebase from scratch would take ten times less effort than reading and maintaining it? I only saw two instances where (different) management approved a complete rewrite of a working product and i…

OP said “writing it in the first place” not “rewriting”

But I agree that their numbers don’t really make sense. Software dev is hard to quantify like that.

Re: Trying to Understand Copilot's Type Spaghetti

#82

Post by david-gpu »

dartos wrote: post #81
david-gpu wrote: post #79

Earlier quoted context omitted.

Can you elaborate on this part? I am trying to understand. > in a mature product, reading and maintaining code takes about 10 times as much effort as writing it in the first place Wouldn't that imply that rewriting a mature codebase from scratch would take ten times less effort than reading and maintaining it? I only saw two instances where (different) management approved a complete rewrite of a working product and i…

OP said “writing it in the first place” not “rewriting” But I agree that their numbers don’t really make sense. Software dev is hard to quantify like that.

> OP said “writing it in the first place” not “rewriting”

They did, but how is that significantly different?

Re: Trying to Understand Copilot's Type Spaghetti

#83

Post by ozim »

rezonant wrote: post #69
ozim wrote: post #68

Earlier quoted context omitted.

What if I told you that one can write code again from scratch instead of fixing broken one? Writing replaceable code instead of maintainable code seems to be already working for a lot of projects. With LLMs and all that fast computing we have it seems it will be more of replaceable code in the future. Of course there are always projects where it will never work. It already works for infrastructure as nowadays servers…

> Writing replaceable code instead of maintainable code seems to be already working for a lot of projects. I contend that these two concepts aren't different. If you have the ability to easily replace a small part of the code and have everything still work, then that's very maintainable. Unless you are talking about throwing out the whole codebase and replacing it, which for sufficiently complex codebases will inevit…

> If replacing the whole thing is easy, it was probably not that valuable or complex to begin with, but that's not the kind of code where maintainability is paramount.

Yes I think even as far as 70%-80% of code - IMHO - is not complex/valuable.

Most of code is replaceable CRUD not controls systems for flying and landing Falcon 9. So it is people problem not a technical problem, people pretend that they need "button more to the left and different shade" just to feel more important. Where we end up with loads of systems that do slightly different thing.

Re: Trying to Understand Copilot's Type Spaghetti

#84

Post by zare_st »

david-gpu wrote: post #79
mumblemumble wrote: post #71

So, that code gets me thinking about premature optimization. In the "verschlimmbessern born of optimizing the wrong thing because you didn't use measurement to guide your efforts" sense. The rule of thumb I hear is that, in a mature product, reading and maintaining code takes about 10 times as much effort as writing it in the first place. I've never tried to measure this myself, but it doesn't seem to be wildly off f…

Can you elaborate on this part? I am trying to understand. > in a mature product, reading and maintaining code takes about 10 times as much effort as writing it in the first place Wouldn't that imply that rewriting a mature codebase from scratch would take ten times less effort than reading and maintaining it? I only saw two instances where (different) management approved a complete rewrite of a working product and i…

Absolutely no.

If a line of code belongs in a project with one file and a main() function, the presumption of impact of that code line on overall code paths is trivial.

If that line of code belongs in a library procedure used by a million LOC project, presumption cannot be done if you don't the project internals and tooling.

Rewriting entire systems or frameworks because one thinks that it's hard to implement a certain class of features is almost always a recipe for disaster.

Re: Trying to Understand Copilot's Type Spaghetti

#85

Post by addaon »

david-gpu wrote: post #82
dartos wrote: post #81

Earlier quoted context omitted.

OP said “writing it in the first place” not “rewriting” But I agree that their numbers don’t really make sense. Software dev is hard to quantify like that.

> OP said “writing it in the first place” not “rewriting” They did, but how is that significantly different?

Every line of code in the first implementation is there for a reason -- it has an implicit history, and implements a requirement. If that requirement is not captured elsewhere, then the prerequisite for /re/writing a system is to read the first implementation, understand the implicit requirements in the code, capture those requirements (or explicitly eliminate them if incorrect), and /then/ start writing version two. So /re/writing a system is a strict superset of both reading a previous implementation and implementing, and is thus harder than either.

Re: Trying to Understand Copilot's Type Spaghetti

#86

Post by dartos »

addaon wrote: post #85
david-gpu wrote: post #82

Earlier quoted context omitted.

> OP said “writing it in the first place” not “rewriting” They did, but how is that significantly different?

Every line of code in the first implementation is there for a reason -- it has an implicit history, and implements a requirement. If that requirement is not captured elsewhere, then the prerequisite for /re/writing a system is to read the first implementation, understand the implicit requirements in the code, capture those requirements (or explicitly eliminate them if incorrect), and /then/ start writing version two.…

Very well put

Re: Trying to Understand Copilot's Type Spaghetti

#87

Post by mumblemumble »

addaon wrote: post #85
david-gpu wrote: post #82

Earlier quoted context omitted.

> OP said “writing it in the first place” not “rewriting” They did, but how is that significantly different?

Every line of code in the first implementation is there for a reason -- it has an implicit history, and implements a requirement. If that requirement is not captured elsewhere, then the prerequisite for /re/writing a system is to read the first implementation, understand the implicit requirements in the code, capture those requirements (or explicitly eliminate them if incorrect), and /then/ start writing version two.…

True.

That said in any non-trivial project, writing in the first place and rewriting aren't too different from each other in practice.

Assuming someone doesn't have the ability to maintain a consistent and always-accurate mental map of tens of thousands of lines of code, most of which they probably didn't write themself and some of which they might have never actually looked at before, they're going to very rapidly reach a point where most of the work involved in adding a new feature consists of reading existing code to understand how it behaves and how the new code needs to interact with it. So the expensive part of adding new code to a work in progress, and the expensive part of rewriting existing code, are more-or-less one and the same.

Re: Trying to Understand Copilot's Type Spaghetti

#88

Post by david-gpu »

addaon wrote: post #85
david-gpu wrote: post #82

Earlier quoted context omitted.

> OP said “writing it in the first place” not “rewriting” They did, but how is that significantly different?

Every line of code in the first implementation is there for a reason -- it has an implicit history, and implements a requirement. If that requirement is not captured elsewhere, then the prerequisite for /re/writing a system is to read the first implementation, understand the implicit requirements in the code, capture those requirements (or explicitly eliminate them if incorrect), and /then/ start writing version two.…

> So /re/writing a system is a strict superset of both reading a previous implementation and implementing, and is thus harder than either.

As you said, every line in the old product had a reason to be. You can learn that reason in two ways: the way it was done in the first place, or by analyzing the old code. My argument is that the amount of effort required in both cases is in the same ballpark -- it will depend on a number of factors such as the quality and quantity of the documentation and testing in the old product, the availability of people who worked on the first product, etc.

So, no, rewriting a system is not automatically more work than writing the original one. But it is certainly not automatically less work either, and many people make the incorrect assumption that rewriting a system is going to take much less work than fixing the existing one.

Re: Trying to Understand Copilot's Type Spaghetti

#89

Post by rezonant »

ozim wrote: post #83
rezonant wrote: post #69

Earlier quoted context omitted.

> Writing replaceable code instead of maintainable code seems to be already working for a lot of projects. I contend that these two concepts aren't different. If you have the ability to easily replace a small part of the code and have everything still work, then that's very maintainable. Unless you are talking about throwing out the whole codebase and replacing it, which for sufficiently complex codebases will inevit…

> If replacing the whole thing is easy, it was probably not that valuable or complex to begin with, but that's not the kind of code where maintainability is paramount. Yes I think even as far as 70%-80% of code - IMHO - is not complex/valuable. Most of code is replaceable CRUD not controls systems for flying and landing Falcon 9. So it is people problem not a technical problem, people pretend that they need "button m…

This is a very extreme take to something far more nuanced... It's possible for code to be complex and valuable without meeting the extremes of "is a literal rocket control system" and "is some buttons on a form".

When I say valuable, I mean provides value to a business. When I say complex, I mean not buttons on a form.

Post reply on HN