Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uakari.primate.wisc.edu!uflorida!beach.cis.ufl.edu!bp
From: bp@beach.cis.ufl.edu (Brian Pane)
Newsgroups: comp.os.minix
Subject: Re: Efficiency vs Effectiveness
Message-ID: <23505@uflorida.cis.ufl.EDU>
Date: 11 Jun 90 11:17:17 GMT
References: <21640@nigel.udel.EDU>
Sender: news@uflorida.cis.ufl.EDU
Reply-To: bp@beach.cis.ufl.edu ()
Organization: UF CIS Department
Lines: 69

In article <21640@nigel.udel.EDU> V2057A%TEMPLEVM.BITNET@cornellc.cit.cornell.edu (Juan Jose Noyles) writes:
>That's a nice rendition of a popular saying, but that's not it, buddy.
>
>Efficiency is a subjective thing.  What may be efficient on one level can also
>be seen as a total waste of time on another.  It's built around conflicting
>views of what's right, another subjective term.  Ever hear the story of the
>blind men describing an elephant?
>
>Effectiveness, however, is straightforward.  If you've taken linear algebra,
>you're familiar with the concept of a kernel, right?  That's the thing upon
>which you base an algebra (or a concept if you keep your analogies straight,)
>because its the smallest set you can use to describe the algebra (concept).
>That is what effectiveness is based on.  That's also what efficiency is based
>upon before it is abused.  The correct expression of a digital solution to a
>problem is the kernel solution, and the pursuit of that seems to be what you
>are railing against.

I think we are all in agreement that programs should be written well.  That
is, they should use as little time and space as possible and should be
easy to read and maintain.  These conditions are not mutually exclusive.

I "rail against" the purist approach to writing effective software because
I view programming from the perspective of an engineer, rather than a
mathematician.  An optimal solution to a programming problem is of little
use if it is completed two weeks (or months, or years) after the deadline.
It may also be of limited use if it is too architecture-dependent to port
to other machines.  Just as fast hardware and the need to produce programs
quickly do not justify stupid code, the pursuit of perfection in programming
does not justify slow development.  Fortunately, as has been mentioned
frequently in postings on this thread, writing good (though not optimal)
code is often easy if one makes a habit of conserving time and space.
Extremism in defense of efficiency or maintainability or ease of
implementation appears to be the major concern here.

>In a kernel solution, there is no waste of time or storage.  The only data
>present in the bounds of the program are those that are necessary.  I include
>code in my specification of data, as well as the proper architecture for the
>implementation of the program, because all computers are not created equal.
>Obviously, this means that there will be different kernels for different arch-
>itectures.
Certainly, but unfortunately software is often only a minor criterion in
selecting an architecture.  The hardware used in a project might be chosen
for its low cost, for the ease of connecting the CPU to memory and I/O
devices without a lot of glue logic, or for its reputation of reliability.
The optimal hardware for the EE's to build or administrators to buy may
not provide the optimal kernel on which to build your application.
This problem is circumvented, albeit with a loss of performance, by
the many layers above the hardware which simulate the environment in
which you want your program to run.  Operating systems and compilers
slow down fast computers and fast software, but programming for a virtual
machine is much easier than programming for a kernel based only upon the
underlying architecture.  Smalltalk may be very wasteful of computer
resources, for example, but Smalltalk programmers can develop impressive
graphical applications rather quickly.

> [...]
>ABSOLUTE Bottom Line:  all programming languages become machine code.
Note that machine code is slow.  Reading instructions from memory and
parsing them takes a lot of time.  Our programs would run much faster
if we transformed them into state machines and implemented them with
custom hardware.  Nobody does this (Well, some people do, but then it's called
electrical engineering rather than programming.) because it's a waste of
time and money.  This is a nice example of my final point:
	Code should be written well, but the pursuit of efficiency
	(or effectiveness) in software should not progress to such
	extremes that it compromises efficiency in the production
	of software.

-Brian F. Pane