Some said: "A piece of art is only finished, when there is nothing left, that can be taken away."
The art in computer programming is, to find ways to bring the problem to the point, to find out what is really necessary to solve the problem (and not more). This reduces (often, not always) the runtime, the amount of memory needed -- and (most importantly!) the amount of maintenance that is needed. The maintenance of a program is directly dependent on the number of code lines.
Many companies start fast with a superior product, but than comes the time of growth and growing demand, new employees are rushing in ... and the number of lines explode. That is the point of danger. The company is about to strangle itself. The number of errors are rising.
I remember an old, but once famous database product. The first 2 or 3 versions where great and the company grew out of 4 developers to a horde. The next version came out much much later than expected and was first a bug ridden chaos. The problem: The number of employees and the number of code lines grew faster than the company could manage them.
It is also said: "Adding new members to a late project, makes it later" That's because of the overhead of managing those peoples and the added code does not always add to project speed.
More seriously, of these two implementation for Python's str.lower(), which is "minimal"?:
for (i = 0; i < n; i++) {
int c = Py_CHARMASK(s[i]);
if (isupper(c))
s[i] = _tolower(c);
}
for (i = 0; i < n; i++) {
int c = Py_CHARMASK(s[i]);
s[i] = _tolower(c);
}
I suspect most would say the second is minimal, but the first is what Python uses, because it's measurably and distinctly faster than the second, and that extra performance is worth the extra maintenance overhead.
That's one reason I believe that programming-as-art metaphors don't really apply. Minimalism as an art form not the same as minimizing the cost function of different uncertain factors.
There was once a programmer who was attached to the court of the warlord of Wu. The warlord asked the programmer: ``Which is easier to design: an accounting package or an operating system?''
``An operating system,'' replied the programmer.
The warlord uttered an exclamation of disbelief. ``Surely an accounting package is trivial next to the complexity of an operating system,'' he said.
``Not so,'' said the programmer, ``when designing an accounting package, the programmer operates as a mediator between people having different ideas: how it must operate, how its reports must appear, and how it must conform to the tax laws. By contrast, an operating system is not limited by outside appearances. When designing an operating system, the programmer seeks the simplest harmony between machine and ideas. This is why an operating system is easier to design.''
The warlord of Wu nodded and smiled. ``That is all good and well, but which is easier to debug?''
Or, as Einstein put it, "It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience."
Rephrasing for the software world: "...without having to make appreciable sacrifices in user experience."
Some said: "A piece of art is only finished, when there is nothing left, that can be taken away."
The art in computer programming is, to find ways to bring the problem to the point, to find out what is really necessary to solve the problem (and not more). This reduces (often, not always) the runtime, the amount of memory needed -- and (most importantly!) the amount of maintenance that is needed. The maintenance of a program is directly dependent on the number of code lines.
Many companies start fast with a superior product, but than comes the time of growth and growing demand, new employees are rushing in ... and the number of lines explode. That is the point of danger. The company is about to strangle itself. The number of errors are rising.
I remember an old, but once famous database product. The first 2 or 3 versions where great and the company grew out of 4 developers to a horde. The next version came out much much later than expected and was first a bug ridden chaos. The problem: The number of employees and the number of code lines grew faster than the company could manage them.
It is also said: "Adding new members to a late project, makes it later" That's because of the overhead of managing those peoples and the added code does not always add to project speed.