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

Write code that is easy to delete, not easy to extend (2016)

programmingisterrible.com

Post reply on HN
Print view View original

91–100 of 102 posts

Re: Write code that is easy to delete, not easy to extend (2016)

#91

Post by cryptonector »

Powdering7082 wrote: post #73

Pretty wild that none of this talks about testing or observability. Tests are also something that you need to pay to maintain, but they give the ability of reducing the risk that you broke something when you removed it. Additionally when you've exposed your service to potential external callers you need to both have a robust way of marking some calls as deprecated, to be deleted as well as observing whether they are…

If you write so many lines of code then you can expect some other number of lines of tests. If you delete some of the code, you may be able to delete some of the tests. The point is that you can talk about just the code like TFA does and assume related impact on tests. TFA not saying anything about tests does not let us assume that TFA means that one should not write tests.

Re: Write code that is easy to delete, not easy to extend (2016)

#92

Post by 392 »

cedws wrote: post #54
jumploops wrote: post #12

My favorite saying: “simple is robust” Similar in spirit to Lehman’s Law of Continuing Change[0], the idea is that the less complexity a system has, the easier it is to change. Rather than plan for the future with extensible code, plan for the future with straightforward code. E.g. only abstract when the situation requires it, encourage simple duplication, use monoliths up front, scale vertically before horizontally,…

Can’t upvote enough. Too much dogshit in software is caused by solving imaginary problems. Just write the damn code to do the thing. Stop making up imaginary scaling problems. Stop coming up with clever abstractions to show how smart you are. Write the code as a monolith. Put it on a VM. You are ready to go to production. Then when you have problems, you can start to solve them, hopefully once you are cash positive.…

I am not sure on that. But I am certain the article Amazon published on cutting AWS bill by 90% by simplifying juvenile microservices to a dead simple monolith was deleted on accident.

Re: Write code that is easy to delete, not easy to extend (2016)

#93

Post by immibis »

vacuity wrote: post #90
immibis wrote: post #89

Earlier quoted context omitted.

X11 has plenty of warts, but Wayland has more. Example: screenshot. X11: "please tell me the pixels in the root window". Wayland: "please tell me the extension number of the portals extension so I can open a portal to pipewire so I can get the pipewire connection string so I can connect to the pipewire server so I can ..." Example: get window position on screen. Example: set window title. X11 is a protocol about mana…

X11 is far more inclined towards the idea of clean separation of policy and mechanism, which I think is becoming more and more evidently correct across the board of programming. When you start talking about libraries and layers, a policy/mechanism split is part of how to write layered code correctly: base mechanisms that interpret the raw problem correctly (e.g. pixels on a screen, mouse position) -> some policy that…

X11's separation of policy and mechanism was a mistake. Maybe it made sense at the time - I don't know. GUIs were new at the time. Now that we know how they're supposed to work, the flag should really be called "I am a window manager" rather than "root window substructure redirect", and "I am a special window" (e.g. combobox drop-down) rather than "ignore substructure redirect" for example. (Even better, define some kind of window class flag so the window manager CAN see it and knows it's a combo box drop-down).

Re: Write code that is easy to delete, not easy to extend (2016)

#94

Post by arkh »

pmg101 wrote: post #81
arkh wrote: post #19

Earlier quoted context omitted.

> encourage simple duplication A rule I like to follow: - first time: write it - second time: copy it - third time: maybe refactor it

All such rules seem designed for a person not engaging their brain. Is this "the same" thing? If so - extract and reference. Or is it "a different" thing which is superficially similar? Then don't. Knowing when two things are one thing or one thing is two things is most of our job, right?

> Knowing when two things are one thing or one thing is two things is most of our job, right?

Yes, but often we don't know the domain enough but "this feature must be available yesterday". So add tests, copy, release. And when you have to either do it again or have to update this code and its original you should know more and be able to refactor and give good names to everything.

Re: Write code that is easy to delete, not easy to extend (2016)

#95

Post by gwbas1c »

mherrmann wrote: post #48

Glaring mistake in the first paragraph: > The problem with code re-use is that it gets in the way of changing your mind later on. This is simply incorrect, especially in the generality in which it is stated. If you change your mind and the code was copy-pasted to ten places, then you have to change ten places. On the other hand, if the code is in a function, then you only need to change it once. And if you do find th…

> If you change your mind and the code was copy-pasted to ten places

The author would probably argue that you should have moved that code to a module / function.

Superficially, they contradict themselves on the topic. When read slowly, they use copy-paste as a way to indicate what code should be abstracted, and what really is a pattern to follow.

Re: Write code that is easy to delete, not easy to extend (2016)

#96

Post by Izkata »

immibis wrote: post #93
vacuity wrote: post #90

Earlier quoted context omitted.

X11 is far more inclined towards the idea of clean separation of policy and mechanism, which I think is becoming more and more evidently correct across the board of programming. When you start talking about libraries and layers, a policy/mechanism split is part of how to write layered code correctly: base mechanisms that interpret the raw problem correctly (e.g. pixels on a screen, mouse position) -> some policy that…

X11's separation of policy and mechanism was a mistake. Maybe it made sense at the time - I don't know. GUIs were new at the time. Now that we know how they're supposed to work, the flag should really be called "I am a window manager" rather than "root window substructure redirect", and "I am a special window" (e.g. combobox drop-down) rather than "ignore substructure redirect" for example. (Even better, define some…

> and "I am a special window" (e.g. combobox drop-down) rather than "ignore substructure redirect" for example. (Even better, define some kind of window class flag so the window manager CAN see it and knows it's a combo box drop-down).

I think X11 has had that for a very long time. In the late 2000s when Beryl was still separate from Compiz, it was almost trivial to target things like dropdowns by a descriptive name and give them different effects than regular windows. Mine had an accordion effect while windows would burn up.

Re: Write code that is easy to delete, not easy to extend (2016)

#97

Post by vacuity »

immibis wrote: post #93
vacuity wrote: post #90

Earlier quoted context omitted.

X11 is far more inclined towards the idea of clean separation of policy and mechanism, which I think is becoming more and more evidently correct across the board of programming. When you start talking about libraries and layers, a policy/mechanism split is part of how to write layered code correctly: base mechanisms that interpret the raw problem correctly (e.g. pixels on a screen, mouse position) -> some policy that…

X11's separation of policy and mechanism was a mistake. Maybe it made sense at the time - I don't know. GUIs were new at the time. Now that we know how they're supposed to work, the flag should really be called "I am a window manager" rather than "root window substructure redirect", and "I am a special window" (e.g. combobox drop-down) rather than "ignore substructure redirect" for example. (Even better, define some…

My point is that X is in the right direction more than Wayland is, in the spirit of its design, and major pain points of X are largely due to its specific design/implementation. Perhaps an outgrowth of having a lot of tiny policy-mechanism components is lack of standardization, which did strike X, but I think that's an orthogonal concern and not better served by overly large, inflexible components.

Re: Write code that is easy to delete, not easy to extend (2016)

#98

Post by Powdering7082 »

sjducb wrote: post #85
Powdering7082 wrote: post #73

Pretty wild that none of this talks about testing or observability. Tests are also something that you need to pay to maintain, but they give the ability of reducing the risk that you broke something when you removed it. Additionally when you've exposed your service to potential external callers you need to both have a robust way of marking some calls as deprecated, to be deleted as well as observing whether they are…

Tests are great, but there’s more to programming than writing tests. People don’t have to mention tests in every article.

I agree, I am not a proponent of TDD or anything, but cleaning & restructuring large code bases without tests is a recipe for an outage/regression

Re: Write code that is easy to delete, not easy to extend (2016)

#99

Post by m0llusk »

qwertox wrote: post #10
ollysb wrote: post #8

Once you can load up a full codebase into an LLM I'm hoping the cost to update client code is significantly reduced. Then you could focus on evolving the design without all the grunt work.

I'm also betting on this, that one day I'll be able to dump a codebase into an LLM and it will clean up the code. Not rewrite it, not restructure it, just clean it up. Remove unused code and comment it sensibly. Maybe also suggest some tests for it and implement them separately.

I wonder if such an LLM will actually be cheaper than a graduate student.

Re: Write code that is easy to delete, not easy to extend (2016)

#100

Post by chikere232 »

ainiriand wrote: post #58
chikere232 wrote: post #55

Earlier quoted context omitted.

Because building for extensibility adds real complexity for a hypotetical need If you want the code to do something different later, change, replace or extend it then... when you actually know what it needs to do

I am not sure that is something that applies 100%, but I understand the concern. It is my understanding that we should try to build solutions to current problems, and be open to future use cases that could involve small additions in functionality. It would be stupid to design an unmodifiable system just because some parts can be deleted and we are not sure what future needs are. Code should always be easy to extend,…

It's not an absolute and there are occasional good design decisions made in the name of extensibility

But what is an unmodifiable system? If it's code in your control, it can be changed, right?

Post reply on HN