[Tfug] Cheap Memory = Lardy Men.

[Bexley Hall]

--- Jude Nelson <judecn at gmail.com> wrote:

> I agree--coders should be forced to learn on low,
> low-end hardware
> (even if only in a VM) and earn the privilage of
> using faster, better

No, that's silly.  "Programmers" (the software
equivalent of "technicians"  :-/ ) should be taught
to *engineer* their code.  And, taught to understand
the consequences of different algorithms as well
as coding styles.

E.g.,

int array[MAXX][MAXY];

for (i = 0; i < MAXX; i++)
  for (j = 0; j < MAXY; j++)
    array[i][j] = 3;

and:

int array[MAXX][MAXY];

for (j = 0; j < MAXY; j++)
  for (i = 0; i < MAXX; i++)
    array[i][j] = 3;

yield identical results (at t = infinity) but have
very different intermediate characteristics and
execution times.

The problem is "programming" is taught in isolation.
The hardware it runs on is not considered.  Nor the
costs of execution, maintenance, etc.

When you design *devices* (i.e., tangible products
that aren't pure software), you are exposed to a
whole slew of "issues" that never come up in a
school-book setting.

E.g., if you are controlling a motorized mechanism,
you typically have some sort of sensor/limit-switch
to tell the software when you have reached the 
end-of-travel for the mechanism.  You can't usually
*wire* this switch into the motor drive circuit
as that would add cost *and* often result in a motor
that can't be moved *away* from that limit once it
has been reached!  :>

Give this problem to most "coders" and they'll
write something like:

move_left(int distance)
{
  while (distance-- > 0) {
    step_left();
    if (left_limit == TRUE)
      return;
  }
}

or, innumerable variations thereof.

They will fail to see two flaws in this algorithm
until some number of devices have been damaged (or
DESTROYED) in production:

- if the code repeatedly invokes move_left(), the
  mechanism will *still* end up ramming itself PAST
  the limit switch (since it step_left()'s at least
  once for each invocation, even if already at the
  limit!)
- the first time a device is built with the motor
  "wired backwards" (as it common if the motor
  connects to the PCB via a connector and that
  connector is put on backwards or *wired* backwards)
  the motor will merily move RIGHT each time it is
  told to move_left() until it has crushed the
  right_limit switch.  Of course, this is because
  the coder never *thought* to check the right limit
  switch since the code is trying to move left!  :>

The same sorts of problems arise in desktop
applications.  Though, their consequences are "not
important" because all that happens is the application
crashes, etc.

I have a delightful knack for walking up to a piece
of code and "doing something unexpected" which
results in the application crashing.  Of course,
the developer invariably tries to justify his
failure to safeguard against this condition by
making a comment like:  "Well, who would ever
want to do *that*?"

To which I reply, "<shrug>  *I* did..."

> systems.  That's how I learned--I started Basic and
> asssembler on a
> TI-83+ graphing calculator (23k RAM, 16 MHz Zilog
> z80 [8-bit], 1.5 MB

<grin>  My first commercial application was porting
i4040 code to the then BRAND NEW i8085.  Moving *up*
to a whopping 256 bytes of RAM!!  :>

> flash ROM), and moved to C on a TI-89 graphing
> calculator (191k RAM,
> 12 MHz Motorola 68k processor, 300k flash ROM, 32k
> code segments [the
> 68k has a 16-bit data bus but was 32-bit
> internally]), and moved to
> Palm OS devices (wow!  a whole megabyte of heap
> space!), and then finally to PCs.
> 
> And how does the U of A teach CS students to code? 
> With a 16 GB
> quad-core 64-bit server, with Java 5 of course! 
> Seriously, how do you
> even *use* that much horsepower?  My dual-core
> laptop with 2 GB RAM is
> only justified in that I need to be able to do my
> homework off-line
> (oh, and show Compiz Fusion to those foolish enough
> to think Vi$ta is the Second Coming).

There's nothing *wrong* with fancy hardware (besides
the fact that it burns lots of cycles doing nothing
and those cycles use a considerable amount of power).
The problem is that it insulates people from the
*costs* of their algorithms.  So, they never realize
how *crappy* their approach is.

The academia solution to this is to let folks
*develop* their code on *whatever*.  But, before
they can turn their assignments *in*, they have to
be run on some old klunky hardware and the "printout"
from that machine's printer being the only accepted
medium for submitting the finished work.

(then, the limits on that machine can be squeezed
by the TA/professor to emphasize just how bad a
particular approach may be  :> )

--don



      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ