Programming, Simple.

Simple is often misunderstood.

Being Simple

Think of being simple of something as “how intuitive and easy it is to understand”.

When they designed the first iPhone, could they have added a “back button” next to the home button? Of course, they could. It could come quite handy. Developers would not have to think about where to place it, and users would always know where it is.

Ask: “does this make it more intuitive and easier to understand”?

It sounds simple, but it is not. Then there would always be a back button, and developers and users had to always think of “what does back mean here?” at each view.

Building complex, is easy. Growing complex is exponentially hard.

But what if they removed the Home Button as well? At each time and users need to have access to the Home Screen. Home Button solves that problem. And moreover, it does not depend on the context.

Again, ask “does this make it more intuitive and easier to understand”?

If it is essential and helps it to be understandable easily, keep it. Otherwise, cut it.

What does simple mean in programming?

There are many principles for better programming; they all aim to answer this in different, and yet similar ways:

They all aim it at making a piece of code have the fewest responsibilities.

The S in SOLID (Object-Oriented Programming) stands for Single Responsibility.

In Functional Programming, a “pure” function’s job is to get input from you and return you an output.

In Protocol Oriented Programming, a protocol should consist of the least amount of methods. Then you can add extensions, conform to multiple protocols to build more complex objects.

Think of LEGO, the basic pieces do only two things: 1) accept another piece on top of them and 2) attach on top of another piece. That’s what makes them great.

They all aim at making the code predictable.

The “pure” functions in Functional Programming must always return the same value for a particular object.
Declarative Programming (SwiftUI, for example) you can already see what will happen if state changes.

In Object-Oriented Programming, and Protocol Oriented Programming, before we receive an object if we know the class they inherit from, or the Protocol they conform to, we already know many things about it.

They aim at making the code replaceable.

In SOLID, and Protocol Oriented Programming, we can replace objects that inherit a particular class or conform to the particular protocol and expect things to work.

Think of the charger and MacBook. You change the country, you change the charger, your MacBook already knows what it will get from the charger, without even seeing it.

They aim at helping you write less code.

The DRY principle, “Don’t Reinvent the Wheel”, “Avoid Premature Optimisation”, and many others are helping you to write less code.

Writing less code means fewer things for you and your program to do.

Why should we program simple?

It is an investment for the future.

Writing a simple code means less uncertainty, ambiguity, and fewer decisions to make.

It saves time and mental energy of the coders who will use the code.
Usually, a compiler understands a simple code better, can compile it quickly and efficiently. And the binary product runs better on the machine as well.

You might find it easier to start writing the code without putting energy and time for making it simple, but simplicity is an investment that will yield in the future.

Now it's time to go on and start coding. And at each moment, think about how to cut things to essentials your code more intuitive and better understandable.

And let me know about what you think. You can find in Twitter @Hamoonist https://twitter.com/Hamoonist