🚀 go-pugleaf

Most of the discussion so far seems to be directed at retrieving
components, but there's been very little said about using them.

background: i haven't done any programming in ADA, so if there's a
definition of component that only applies to ADA, i don't it.  i'm
basing this on my "feel" of component -- namely a group of code that's
intended to for reuse.  

my experience so far has been that the more general a component is, the
slower it runs.  for example, given a routine to sort objects, you have
to give it a criteria.  somehow, the sorting routine has to make a
function call to compare two elements.  (in a recent article, someone
said that this is how they'd like to see a sorting routine
implemented.  that function call can DOUBLE the time it takes to
perform a sort!)

for another example, some languages have arrays as their basic data
unit. "+" becomes an array operator.  but if all you need to do is add
two scalar quantities, you're hit with a performance penalty.

so far, the trend has largely been towards larger and larger components:
software components have moved from machine language instructions to
assembly language instructions and macros to high-level-languages to
4th-generation languages; 

hardware trends have been similar: very simple machine instructions,
then simulating new features by subroutines, then hardware to perform
new features, continuing with complicated things like MMUs and so on.

but recently, the hardware trend has reversed -- use very simple
components, with a much more complicated "compile" phase; let the
compiler have access to all sorts of little details it didn't have
before. (i'm referring to RISC of course.)

there's still a lot of room for growth in compiler technology,
particularly with global optimization, but this is assuming a few
things: 

1) the compiler needs to have access to the source code for the
component you're using.  no problem if you built all the components
(although it might mean having to open several 1000 files to look at all
the components!) but if you're using components produced by someone else
and sold as a package, you won't have this option.  (it also impinges
on the abstraction level which the component is supposed to be hiding.)

2) the additional time required for the compile phase isn't a problem.

3) ability to recompile everything that uses a component if the
implementation of a component changes, even if the interface remains the
same.

with the current trends in hardware and software (backlog of software
applications, steady and fairly rapid growth in processing capability
per cost), saving time building the application is more important than
reducing the running time of the application.  

but my experience on applications has led to the conclusion that a lot
of performance is being sacrificed for the decrease in application
building time.  there is a lot of work being done in decreasing the
time required to build an application (object-oriented languages, CASE
systems, etc.).  what current work is being done towards increasing
program performance?  what sorts of things are *your* company doing
towards performance of programs?

(at my company, we've build a lot of systems using a fourth generation
language, Stratagem (currently sold by Computer Associates).  the long
term path i'm seeing is coding a prototype in stratagem, finishing it
and makin preliminary delivery in stratagem;  then, recoding critical
parts of the program in C, for rapid numerical calculations, etc.  so
far it's worked fairly well, but to get that performance there's the
penalty of having to write the same thing in two different languages,
plus testing/debugging it twice, etc...)

do others agree that this is a problem in the software industry, or it
is just me?  if it is a problem, how should we face it and fix it
before it becomes worse?

(sorry for the length of this)

-michael j zehr