[TUHS] Book Recommendation

[Jon Steinhart]

Clem Cole writes:
> Unfortunately, because the hobbyist and much of the press for entry-level
> of the same, touted BASIC, many did not know better.   The fact is I'm
> still now sure the HS and JHS are a lot better than they were.
>
> I'll let Steinhart reply, but he wrote an excellent book recently targeted
> to just those same students that what to know more, but frankly their HS
> teachers really are not in a position to teach them properly.

Well thanks Clem :-)

I didn't actually hit BASIC until college where freshmen had to learn it
on the PDP-8.  Took me all of about 5 minutes to learn the language and
about a half a day to do the entire semester of coursework.  Got me off
to a good start on annoying my professors.

I think that my first programming language was SNAP running on a PDP8-E in
the (I don't remember the exact name) Princeton computer barn.  Because my
dad worked at IBM I remember going over to his VP's house to learn APL on
his home terminal.  FORTRAN on I think an IBM 1620 was next.  After that
was Heinz's FSNAP on the Honeywell DDP-516 at BTL.  Never thought to
ask before, Heinz - was FSNAP based on SNAP?  Assembler came after that,
followed by C.  I know, what's the difference?  Then Pascal in college
which was dreadful after C.  I asked my professor to give me a few pointers
on how to program with fixed length arrays but he couldn't give me any :-)

It's my opinion that BASIC was a good thing in its day but that that time
has passed.  Part of what made it the goto language was its simplicity;
there wasn't much to learn and there was no complex toolchain so time was
spend on figuring out how to structure a problem so that it could be solved
on a computer.  In my not very humble opinion, this is the fundamental
(or should I say basic) problem with CS education today; the effort is
focused on learning the language and the toolchain, not how to think and
solve problems.  Somehow many of us learned to program in BASIC without a
"Hello World" tutorial.

Another big factor in those days was that the consequences for getting
something wrong were pretty much nonexistent.  What was the worst that
could happen, you'd accidentally output an obscenity?  Give what computers
were used for back then, getting the math wrong was more likely than having
a logic error.  I didn't have to worry about buggy code destroying anything
until a project where I modified FSNAP to control semiconductor test
equipment.

I have tried when mentoring to get people to start with simple
character oriented programs but of course everyone (especially boys)
want to start with a video game.  This immediately means having to deal
with multithreaded code (even if it's somewhat hidden) and complex APIs.
All of this is a distraction from learning how to think and solve problems.
As a result, we're producing a lot of "programmers" who can wrangle this
stuff while having no idea how to solve a problem.  I think that a glance
at stackoverflow backs me up here.  It's extremely frustrating: "I want to
write a video game where I can shoot something."  "Cool.  Let's learn
some physics."  "I don't want to learn physics, I want to shoot something."

As an aside, I saw an article recently where someone was lauding the
github "AI" code writing thing.  The author wrote something like "Wow.
I asked it to replace spaces in a string with underscores and it just
gave me the code."  Arrrrggggghhhh!!!  IMNVHO this person should never be
allowed near a computer.  If you can't do this without help you shouldn't
be programming.

Like usual, I'm rambling, but one more related thing.  I'm mentoring a CS
student who has to do a project this year.  My advice was that I didn't
care what the project actually did, but that it should be based on an
Arduino and written in C and assembler without any of the sketch library
stuff.  The goal being to learn to read a data sheet, program I/O devices,
and handle interrupts.  All on a processor that's not too complicated.

Jon