[TUHS] Book Recommendation

[Heinz Lycklama]

Jon, regarding FSNAP - wrote it from scratch.
Did not know about SNAP at the time.

Heinz

On 11/16/2021 10:27 AM, Jon Steinhart wrote:
> 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