Thread: the three mutually exclusive goals of programming

Originally Posted by Mario F.

I don't understand what you mean by "no hardware". But does it matter if I don't? What can possibly exist in every software development project ever written that makes it true that no code can be both simple, fast and quick to write? If we are ready to accept this, we need to identify the causes. Otherwise we are dealing with an unproven statement.

Laserlight makes an interesting point about trade-offs. It's a well known problem in programming. But these don't exist everywhere, or are always relevant if they do (in which case the terms "fast", "simple" and "quick" assume different meanings). So the simple matter of fact is that the way the saying on your OP is constructed makes it very easy to write it off as being false.

At one time almost everything was done in software. There were no graphics accelerators or sound chips.
Machines were so slow and small, that some things could only be done in assemby language.

Also, it wouln't apply to every program, of course.

I imagine it applied to projects where all three considerations were either critical or very important.

No, but that does looks like the same type thing. One was likely derived from the other.

Just something the software guys at one place I worked used to talk about.
Their projects were fairly large, and the "triangle" seemed to be a constant consideration.

Then, quite frankly, they were worried about all the wrong stuff.

Code:

#include <stdio.h>

int main(void)
{
    puts("Hello world!");
    return 0;
}

It's small (4 lines of code plus two lines with brackets).
It's fast. You won't find anything too much quicker at outputting text than the stdio functions.
It was quick to develop. It took much well under a minute to type.

Originally Posted by megafiddle

Indeed.

How much incredibly sluggish code might be out there, and no one notices?

Quite literally ... tons of it.

What passes for efficient code today --especially with 3rd party abstractions and object oriented programming-- isn't efficient at all. Software overhead (also called "bloat") has become an accepted fact of life, especially in "managed" languages like C# and Java... There was a time when people were refusing to install Visual Basic code because of all the DLLs that came with it, essentially duplicating functions already on their systems. These days we install monstrosities like .NET and Java runtimes that are 10 times as big without a second thought. Every CPU cycle uses time, but that's not even a consideration these days...

Fast machines do free up a programmer to concentrate on things other than speed.
Sometimes.

Yes they do... but they also lead to "stuff we couldn't do before" which can be a good thing. Consider things like high definition video, multi-channel audio and enormously complex scientific code. But just as often they lead to crap like Borland's Delphi wich sucked up a full megabyte of memory just to play a single midi file in MCI... Bloatware is no joke, but we seem increasingly unlikely to even care how big our code gets. What the heck... memory is cheap and CPUs are fast, just pound it out and get it working in the shortest time possible.

This triangle of yours is a balancing act...
The goal is to get working code that is reasonably stable into the hands of users as quickly as possible...

Yes, there new challanges with the new possibilities.

Now if the programmers had to work within size and speed constraints,
how quickly could they have delivered that stuff?

What does it matter?

The entire programming industry is a whole different animal than it was in the 1980s... there have been large changes, even in the past 5 years we've seen new operating systems, 64 bit code becoming the norm, and even some talk of 128 bit processors on the drawing boards... 5 years from now it will be different again... The challenge is to keep up.

I understand what everyone is saying, I just don't think that's what the "triangle" was originally
intended to mean.

Of course a tiny program can meet all three requirements. That was always true. Just as a large
complex program can meet all three on a huge superfast computer.

A question I should have asked first is, "what does it actually mean"? My interpretation is apparently
different from many.

If you use a large lookup table to reach an execution speed goal, I would say that you have not met
the small size requirement, even if it fits on a typical machine. Now that itself is arguable, but I also
think that it was part of the original thinking concerning the "triangle".

The memory in an operating system like windows can shrink pretty fast if you are using other programs
simultaneously. As can the effective processor speed.

Originally Posted by grumpy

There is actually a 4th goal or factor being traded off in your code: it does little of use.

It is of great use if the goal is to write a hello world application, which is a very common goal that almost every C programmer has had at least once in their life. Besides, usefulness is not in the OP's 3 criteria, and it's just as relative as small code size, fast code and short development time. Oh, and I was joking

Originally Posted by grumpy

There is actually a 4th goal or factor being traded off in your code: it does little of use.

Oh I don't know... Hello World comes in pretty handy for testing new compiler installations... It means it works at least well enough to successfully compile code.

I would agree that any standards are arbitrary.

But I think the important point with the large lookup table example, is that small code size
had to be sacrificed for speed.

It does assume that faster code could have been written, given enough time. And that may or may not
be true, depending on the program. But it is also usually unknown. So it is assumed that it could have
been written smaller and faster.

Hope that makes sense.