[NTLUG:Discuss] Lego Robots. (Was Symbolic Links)

[Richard Cobbe]

Lo, on Friday, November 3, Steve Baker did write:

> Richard Cobbe wrote:
> 
> > Why is the concept of moving common code into a library or the kernel so
> > alien to these folks?  For that matter, why is the concept of moving common
> > code so far away as a separate *function* within the same module so alien
> > to so many of my co-workers?
> > 
> > Do these people *enjoy* fixing bugs 3 and 4 times over instead of just
> > once?
> > 
> > I know there are some CS teachers in the audience here.  We *do* still
> > teach the idea of abstracting common code out into a separate function,
> > right?  I know *I* learned that back in high school!
> 
> People who were brought up in the age of punched cards were better at this.

Probably true, but this isn't me.  I went through high school in the early
'90s.
 
> I blame the ease of doing 'cut and paste' in modern text editors.
> 
> Where I work we call this style "yyp" programming.  'vi' users know what
> I mean!

Yup.  We use Sparcs at work, with those oh-so-wonderful function keys down
the left-hand side of the keyboard, including copy, cut, and paste keys.  I
keep threatening to come in some weekend with a hacksaw and cut that part
of the keyboard off completely.  (Or just do it with xmodmap, but it works
out to the same thing.)

> > I'm wondering if it would be a good and useful thing to teach a class in
> > good software design from the other perspective: giving the students the
> > source to a medium-sized buggy project and having them fix the bugs.  Do
> > three or four:
> > 
> >   * one with no documentation and bad (formatting) style
> >   * one with documentation, but with buggy code repeated 4 and 5 times
> >     through the project.  Ideally, include some problems that are usually
> >     the result of cut-n-paste coding.
> >   * one with good documentation AND good use of abstraction.
> 
> * One with documentation that's so out of date that it refers to
>   completely different code.  :-(

Also a good idea.

> > This, I think, would drive home the value of documentation and abstraction
> > in a far more effective manner than a series of lectures.
> 
> Yes - certainly.
> 
> I've recently started playing with Lego Robotics.  I think that's an
> *EXCELLENT* training ground for programmers:
> 
>   1) There is no simple way to debug a program - you have to resort to
>      flashing a light when your code gets to a certain place - or beeping
>      some number of times to indicate the value of a variable....or
>      perhaps you learn to write code that works first time!

Well, good for teaching people the value of writing good code, but unless
you teach them HOW to write good code (i.e., derive programs mechanically
from your data definitions, and so forth), it doesn't do much except
provide frustration.

Also, most architectures these days, even some embedded systems, will
provide you with source-level debuggers.  If you've got powerful tools like
that, use them.  Teaching debugging-by-LED is, I think, far less important
than it used to be.

>   2) There is only a *tiny* amount of memory in a Lego Robot's computer.
>      You have to be efficient in space terms - 'yyp' programming is
>      definitely out of the question.

True--although space concerns are not the only problem with cut-n-paste.
(For that matter, C++ inline functions will create the same space bloat).
In addition, I hesitate to start people off with a very limited memory
space: while memory concerns are certainly an issue for an important class
of programs, primarily embedded systems, it's becoming less and less
critical in general.  I've seen far too much ugly code produced by people
who are overly concerned about memory and speed requirements.

(To avoid flames: this does NOT excuse memory bloat.  Whatever the
situation, you still need to use memory effectively.  Complicating code and
generally doing lousy design in the name of efficiency, however, is almost
never a good idea.)

>   3) It's **FUN**.

Always a plus, especially in beginning programming languages.  As silly as
the language is often perceived to be, this is one of the major benefits of
Logo---you get to draw Pretty Pictures(tm) without a huge amount of
graphical support code.

The key: ability to do interesting things early on, with immediate
feedback.

The electrical engineering department at Rice used to run a class which was
basically playing with Lego robotics.  I never took the class, so I'm a
little short on details, but they used an in-house language and supplies to
make it work.  The robots had to solve a particular task, and they had a
big competition at the end of the semester.  It was a very hard, very
time-consuming class, but it was extremely popular, and not just among EE
majors.  (The prof who ran the thing is now at the University of
Washington, I think, so I don't know if they're still continuing the
class.)

Richard