The development curve of software engineering is very similar to the learning curve of Emacs.

It’s embarrassing, it’s not funny, it’s depressing. (Ten thousand hearts…)

How is an inner volume created?

The procedural approach to programming is the original sin of invoking

The process approach requires that we step through every corner of a software project to get a glimpse of the whole project. The larger the scale of the project, the more code, the more complex the logical process, the more serious the entwining, so that people can not extricate themselves in it.

Logical processes are called involumes.

So, inside volumes, which accompany every line of code, are a dangerous side effect of every process and step. It can’t be eliminated.

Inwinding is a sign of danger

There are two main signs that coiling has become serious and dangerous:

  1. Look not to understand
  2. To change the fixed

When it starts to fail to understand, it means that the power of the inner coil begins to highlight. At this time, the impact is not very big, and the effort can also be understood. When it’s really hard to understand, it means that the inner volume has started to take over, and the developer is in a passive position.

When it does not change, it means that the damage of the scroll is already strong enough to hurt the developer. When it doesn’t change, it means the developer is killed by the internal roll, and the developer can run with the curse words.

How to see “get” understand, change “get” move

If you want to understand and change, you need to avoid the complexity of the logical process and the inner volume. Because the program organized according to the logical process is bound to go through all the processes step by step by ourselves, and the connections and jumps between the processes will aggravate the internal coiling, and finally be unable to move and wait for collapse.

So how do you do that? To avoid involumes, avoid logical procedures. For us humans, all the micro-processes are not necessary; we really only care about inputs and outcomes (i.e., inputs and outputs). It’s like customizing a product with a factory, but not caring about how it was produced, but only about the final product. All you have to do is describe the requirements clearly. Otherwise, to build a rocket, you have to understand the process of making all the parts involved? This is obviously not the case. But actually that’s the approach used in software engineering where coiling becomes dangerous (say job building rockets, job turning screws, you’re actually building rockets, you know what).

We only care about the inputs and outputs, not the details. A clear description of the requirements is enough. It would be nice if there were a way to get past the program by simply describing the inputs and outputs. There is such a thing as data structured programming.

Data structured programming

The link is here (very hardcore) :
https://github.com/rainforest…

This approach requires us to describe clearly the data structure of the expected input and output, and then populate the input data (i.e., make the input ready) to automatically obtain the expected results. So we care about what we care about and ignore what we don’t care about.

The core idea is that when the expected data is ready, the expected results should be achieved. This is really, really in line with human habits.

Why does it have this effect?

One of the secret reasons is that we explicitly describe the expected data structure from the very beginning. From here, you can get a complete picture of the program without having to go into it. What we see is the expected result.

Another reason is that the data structure is self-consistent, it contains inputs and outputs, and it’s great, and it describes itself. It explains its intention by itself, and we don’t have to go through complicated logical processes to infer intention.

The next reason is that the data structure is hierarchical, and it is self-consistent, so the intent can be understood at each level.

There is also a big, magical reason that the whole idea is different from what it used to be, both cognitively and in usage more in line with human habits. There are many reasons which can be discussed one by one, but space is limited to list a few briefly.

More in line with human habits

  • New understanding: Programming is no longer about deriving results, but about filling in data for inputs that are not yet ready.
  • New concept: programming that automatically executes the expected rules and obtains the expected output when the input data is ready.
  • New thinking: focus on data structure description, ignore the complex logical process.
  • Order-independent: If multiple inputs are expected, it doesn’t matter which one is ready first, as long as they are all ready at the end. (It’s great, it’s just fun to get started; Team work is more friendly and friendly.
  • Anticipation in advance: Instead of waiting for the data to go through a logical process, the result can be derived. Instead, the expectation rules can be defined in advance, and the result can be obtained when the data is ready. (Imagine a harmonious picture of teamwork)
  • Elastic planning: if someone has too many tasks, the data structure can be planned again. Large tasks can be divided layer by layer into sub-tasks as input data, and multiple people can develop in parallel. (This is almost infinitely separable.)
  • Parallel development: Yes!
  • Automation: a return to new knowledge, new concepts, as soon as the expected data is ready, the expected results will be automatically obtained. You don’t have to actively drive the data.