Live data from Hacker News

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

programmingisterrible.com

51–60 of 102 posts

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

#51
post #21
post #18

Earlier quoted context omitted.

Sure, but when applying "simple is robust" principle it is extremely important to understand also intrinsic complexity. Not handling edge-cases etc does not make for robust code, no matter how much simpler it is.

There will always be edge cases, and yes they will make the code more complicated, but what really helps is automatic testing to make sure those edge cases don't break when making changes.

Setting up automatic testing alone tends to add its own layer of complexity. At least it's worth it.

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

#52
post #43

Earlier quoted context omitted.

+1, but I'm not sure if the "simple is robust" saying is straightforward enough? It opens up to discussion about what "simple" means and how it applies to the system (which apparently is a complex enough question to warrant the attention of the brilliant Rich Hickey). Maybe "dumb is robust" or "straightforward is robust" capture the sentiment better?

Indeed, simple is not a good word to qualify something technical. I have a colleague and if he comes up with something new and simple it usually takes me down a rabbit hole of mind bending and head shaking. A matter of personal perspective?

Is my code simple if all it does is call one function (that's 50k lines long) hidden away in a dependency?

You can keep twisting this question until you realize that without the behemoths of complexity that are modern operating systems (let alone CPUs), we wouldn't be able to afford the privilege to write "simple" code. And that no code is ever "simple", and if it is it just means that you're sitting on an adequate abstraction layer.

So we're back at square one. Abstraction is how you simplify things. Programming languages themselves are abstractions. Everything in this discipline is an abstraction over binary logic. If you end up with a mess of spaghetti, you simply chose the wrong abstractions, which led to counter-productive usage patterns.

My goal as someone who writes library code is to produce a framework that's simple to use for the end user (another developer). That means I'm hiding TONS of complexity within the walls of the infrastructure. But the result is simple-looking code.

Think about DI in C#, it's all done via reflection. Is that simple? It depends on who you ask, is it the user or the library maintainer who needs to parametrize an untyped generic with 5 different type arguments?

Obviously, when all one does is write business logic, these considerations fall short. There's no point in writing elegant, modular, simple code if there's no one downstream to use it. Might as well just focus on ease of readability and maintainability at that point, while you wait for the project to become legacy and die. But that's just one particular case where you're essentially an end user from the perspective of everyone who wrote the code you're depending on.

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

#54

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.

Why is your “AirBnb for dogs” startup with zero users worrying about C100K? Did AWS convince you to pay for serverless shit because they have your interests in mind, or to extract money from you?

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

#56

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…

> On the other hand, if the code is in a function, then you only need to change it once. And if you do find that one of the ten invocations should not be changed, then you can still copy-paste - or make the function more general.

Ah yes, but what happens if you have to change 3 of the function invocations in one way, 5 in another, and the other two need to be completely rewritten because those aren't even using the same abstraction any more?

If it's all in one function, most developers will try to change that function to make all 10 cases work, when it should never have been one function in the first place.

It is much much easier to fix ten copy-paste places than to untangle a knot that should never have been tied, once it's holding pieces of your system together.

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

#57
post #37
post #18

Earlier quoted context omitted.

Sure, but when applying "simple is robust" principle it is extremely important to understand also intrinsic complexity. Not handling edge-cases etc does not make for robust code, no matter how much simpler it is.

Failing to account for this gives you Wayland (which at this time is more complex than X11)

Is it actually more complex?

I find it more understandable, it’s just that DEs need to write their own compositors.

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

#58

Why not both?

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, in my opinion.

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

#59

At the risk of turning a unison into a chord, here's my two cents. If: 1. You know where the 'creases' of orthogonality are. You've carved the turkey 1000 times and you never get it wrong anymore. 2. As a result, there is hardly any difference in complexity between code that is and isn't easy to extend. Then write code that is easy to extend, not delete. The question is whether your impression of the above is true. I…

Could you give an example of your point? Isn't writing orthogonal code the same as writing code that's easy to delete?

Here's an algebraic example to keep things theoretical. If the easy to delete version proposed by the article is:

   f(x) = 6x^2 - 5x + 1
The prospective extensible version is:

   g(x,a,b) = ax + b
   f(x,q()) = q(x,3,-1) q(x,2,-1)
   f(x,g)
It's the generalization for factorable polynomials. It's clearly harder to read than the easy to delete version. It's more complex to write, and so on.

However, it's algebraically orthogonal. It has advantages in some cases, for instance if you later add code for a 6th-order polynomial and need to use its zeroes for something else.

We know that it could be better in some cases. Is it a good bet to predict that it will be better overall? The problem domain can fracture across a thousand orthogonal "creases" like this one. The relevant skill is in making the right bets.

Here's an example that's not orthogonal. Let's say we think the 6 coefficient might be more likely to change in the future:

   g(x,a) = ax^2 - 5x - 1
   f(x,q()) = q(x,6)
   f(x,g)
This version is most likely just adding complexity. A single function is almost always a better bet.

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

#60
it's crazy how we keep going through all those injunctions (religions) about software, they all look amazing on paper, feel like common sense and yet 50 years in, software is garbage 90% of the time

yet, we keep bringing this stuff up like it's some sort of genius insight / silver bullet

Post reply on HN