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

21–30 of 32 posts

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

#21

Post by taeric »

dijksterhuis wrote: post #13

This is a pattern that's used in other fields too, e.g. electronic music: When Brian Eno lectured at RBMA in New York a couple of months back, he described [James] Blake as an artist who “works mostly by subtraction, he takes lots of stuff out and ends up with very skeletal pieces.” Blake watched the Eno lecture yesterday, and he nods avidly when I repeat this analysis of his working process back to him. “One part [o…

This is actually a different thing, though. This is pruning a working piece down to a smaller one. Kind of like gardening by only weeding. It works, but only if you have a full set of crops naturally.

This idea seems more to be about planting crops in such a way that you can remove them easily from a garden.

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

#22

Post by ChrisMarshallNY »

lucideer wrote: post #19
ChrisMarshallNY wrote: post #17

Earlier quoted context omitted.

:) Never even thought of that. Not necessarily a bad thing, if you are good at selecting dependencies. But it can be a very, very bad thing, if you are not so good at selecting dependencies.

I've seen both cases (people over-avoiding dependencies to detrimental levels, and people who are VERY bad, and very zealous, at selecting dependencies). While I think it varies per language community; overall, the latter seems more common. That said, the worst codebases I've worked with were examples of the former. So it's definitely a tricky balance.

My codebases can be difficult to maintain (I know, because I'm the one that has to maintain most of them).

It's not because the code is bad. Quite the opposite, really. It's well-structured, and incredibly well-documented.

It's because I tend to do some fairly ambitious things, and write in a modular, layered fashion that can distribute functionality throughout the stack.

I also tend to write in a fairly asynchronous fashion (would you call it "reactive"? I dunno. I've been writing code like that since long before "reactive" was an official buzzword).

Can be hard to grok.

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

#25

Post by hundchenkatze »

gruez wrote: post #8
cratermoon wrote: post #6

https://github.com/kelseyhightower/nocode

What's up with the issues page on that project? There's many that are just random chinese characters?

Seems more like random Chinese sentences, based on Google translate anyway. Which seems inline with all the other issues posted in English. I think people are just screwing around making jokes/memes on a joke/meme repo. Take this issue in English for example: "The cow has eaten the grass and gone, so there is nothing left" - https://github.com/kelseyhightower/nocode/issues/4201

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

#26

Post by hundchenkatze »

anuila wrote: post #16

I’d have another suggestion: Don’t break the back button on your CSS-free blog. This is arguably easy to avoid, yet people manage to do it.

In what way is it broken? I was able to follow several links on their site and then use the browser's back button to get back to HN.

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

#27

Post by Jtsummers »

hundchenkatze wrote: post #26
anuila wrote: post #16

I’d have another suggestion: Don’t break the back button on your CSS-free blog. This is arguably easy to avoid, yet people manage to do it.

In what way is it broken? I was able to follow several links on their site and then use the browser's back button to get back to HN.

In Safari (iPadOS), I couldn’t get out of the site using the back button (unless I hit it fast enough to get past whatever it was doing to the browser history).

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

#28

Post by aszen »

taeric wrote: post #20

I feel this is somewhat muddled in push. I agree with all of the items, but I don't agree with how folks often pursue it. My specific concern is where it pushes that a big ball of mud is easy to write, but hard to maintain. I agree, but oddly, a ball of mud is also somewhat easier to delete. Such that, it is best to grow your code from that core and only grow to reusable parts if needed. I encountered this at work re…

The problem with removing ball of mud code is that you don't know much of that mud is entangled with useful code. I do think oop design patterns bring a lot of indirection sometimes but atleast we can use small well thought out functions instead of connecting all things inside one giant one

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

#29

Post by taeric »

aszen wrote: post #28
taeric wrote: post #20

I feel this is somewhat muddled in push. I agree with all of the items, but I don't agree with how folks often pursue it. My specific concern is where it pushes that a big ball of mud is easy to write, but hard to maintain. I agree, but oddly, a ball of mud is also somewhat easier to delete. Such that, it is best to grow your code from that core and only grow to reusable parts if needed. I encountered this at work re…

The problem with removing ball of mud code is that you don't know much of that mud is entangled with useful code. I do think oop design patterns bring a lot of indirection sometimes but atleast we can use small well thought out functions instead of connecting all things inside one giant one

That is true of all code you delete. It had some use, or it would never have been added in the first place.

I'm not arguing for the entire thing to be a ball of mud. Just pushing that there are trade-offs. And, in general, less code is better code. Even if it is a larger method.

Granted, I think a lot of this is in strawmen. Breaking 5 lines out of a 40 line method so that you can be better abstracted is usually fighting the wrong things. Breaking it out of a 500 line function is different.

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

#30

Post by hundchenkatze »

Jtsummers wrote: post #27
hundchenkatze wrote: post #26

Earlier quoted context omitted.

In what way is it broken? I was able to follow several links on their site and then use the browser's back button to get back to HN.

In Safari (iPadOS), I couldn’t get out of the site using the back button (unless I hit it fast enough to get past whatever it was doing to the browser history).

Interesting, it works fine on Firefox. I was able to reproduce it using Safari. After poking around I noticed it's a tumblr blog, so I tried some other tumblr blogs with the same result. It seems Tumblr's nav code does not get along with Safari/Webkit.
Post reply on HN