![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
chaourceIn a previous post I explained my view of "declarative programming". (In brief: A declarative program is an executable specification written in a human-understandable form. Declarative programming is always bound to a particular problem domain. If we have a declarative programming language for our problem domain, we can write programs that syntactically look like an obvious specification of what we want.)
Designing declarative languages is, of course, not easy. Now, suppose we have such a language for our problem domain. I claim that we will not need unit tests for our programs. We will still need acceptance tests - that is, we need to verify that we wrote the specification correctly, that it compiles and runs, and that it satisfies our overall expectations of performance, user experience, and so on. However, we will not need to write any unit tests for our code.
This is so because unit tests check that our implementation of each module conforms to the specification of that module. If the code is the same as the specification, this does not need to be checked.
A simple example is text editing. Consider text editing as a programming task where the programmer has to specify each character in the text. A non-declarative programming language for text editing would be concerned with allocating memory, assigning one character at a time, etc., and could look something like this:
In contrast with this, a declarative language for text editing would simply put text into the code:
We simply write the "specification", i.e. the text to be entered, and this is already a piece of executable code.
Now, according to modern norms of industrial software engineering, a program in a non-declarative language would require unit tests. The tests would check that enough memory was allocated, that the right characters were placed at the right points in the memory, that the unused memory was deallocated, etc. Programs are usually designed in a special way so that they can be more easily tested. For instance, memory allocations will be performed not directly but through a proxy, so that the each memory allocation can be monitored while testing; text would be put onto the screen not directly but through another proxy, etc.
Obviously, testing requires a significant amount of extra code to be written, and sometimes a significant effort of restructuring the program so that it can be tested more easily. A quotation:
"As of version 3.8.6, the SQLite library consists of approximately 89.9 KSLOC of C code. ... By comparison, the project has 1017 times as much test code and test scripts - 91493.0 KSLOC."
All this becomes obviously unnecessary if we can use a declarative language.
Designing declarative languages is, of course, not easy. Now, suppose we have such a language for our problem domain. I claim that we will not need unit tests for our programs. We will still need acceptance tests - that is, we need to verify that we wrote the specification correctly, that it compiles and runs, and that it satisfies our overall expectations of performance, user experience, and so on. However, we will not need to write any unit tests for our code.
This is so because unit tests check that our implementation of each module conforms to the specification of that module. If the code is the same as the specification, this does not need to be checked.
A simple example is text editing. Consider text editing as a programming task where the programmer has to specify each character in the text. A non-declarative programming language for text editing would be concerned with allocating memory, assigning one character at a time, etc., and could look something like this:
alloc 0x1A00, 0x9000, 0x100 loadTBL 0x9000, 0 /* load ASCII table */ pcr 0x48, 0x1A01 pcr 0x65, 0x1A02 pcr 0x6C, 0x1A03 ...
In contrast with this, a declarative language for text editing would simply put text into the code:
"Hello, world!"
We simply write the "specification", i.e. the text to be entered, and this is already a piece of executable code.
Now, according to modern norms of industrial software engineering, a program in a non-declarative language would require unit tests. The tests would check that enough memory was allocated, that the right characters were placed at the right points in the memory, that the unused memory was deallocated, etc. Programs are usually designed in a special way so that they can be more easily tested. For instance, memory allocations will be performed not directly but through a proxy, so that the each memory allocation can be monitored while testing; text would be put onto the screen not directly but through another proxy, etc.
Obviously, testing requires a significant amount of extra code to be written, and sometimes a significant effort of restructuring the program so that it can be tested more easily. A quotation:
"As of version 3.8.6, the SQLite library consists of approximately 89.9 KSLOC of C code. ... By comparison, the project has 1017 times as much test code and test scripts - 91493.0 KSLOC."
All this becomes obviously unnecessary if we can use a declarative language.
