solution = f(problem, architecture)

[Silver]

After reading the many articles re: D-scussion, Langauges vs. Machines
(actually, architecures), etc, I thought that instead of referencing
and replying to each-n-every nit that I want to pick, I'll simply add
my fuel and let ashes be ashes.

Programmers should be taught:
  (a) to think and solve in terms of the concepts of the problem
  (b) to know which architectural paradigm lends itself best to the
      most efficient solutions
  (c) to solve in such a way that as many of the architecture-
      -dependent details of a solution are abstracted as far away
      from the implementation of the solution as possible

Whilst in the middle of (c), a programmers's solutions should rely
(writing as appropriate/necessary) libraries and other standard
thingies as much as possible.

As a practical example, when I program in C, I don't directly use
arrays.  Choosing between an array (random access, memory abusive when
sparse, hard to restructure) and lists (sequential access, memory
abusive when full, easy to restructure) is often a difficult decision,
and sometimes I'll flip-flop mid-solution between the two.  This
shift, to me, is implemented by changing one definition in some
global.h:

  #define vector_implementation sparse

When I want to use a vector, I include the preprocessor file vector.h,
and let my (admittedly smartsy) cpp file do the rest.
			      ___
		      Cheers, \o/ Silver
	201-932-2443 (mostly)  V  (dots)  gaynor at rutgers.edu
	201-545-0458 (rarely) _|_ (bangs) ...!rutgers!gaynor