From: Heinz Lycklama <heinz@osta.com>
To: tuhs@minnie.tuhs.org
Subject: Re: [TUHS] Book Recommendation
Date: Tue, 16 Nov 2021 10:44:04 -0800 [thread overview]
Message-ID: <c281bc22-1b63-a1f1-12b3-72770fb92cf9@osta.com> (raw)
In-Reply-To: <202111161827.1AGIRU1l930653@darkstar.fourwinds.com>
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
next prev parent reply other threads:[~2021-11-16 19:16 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-16 3:16 Douglas McIlroy
2021-11-16 4:08 ` G. Branden Robinson
2021-11-16 14:56 ` Clem Cole
2021-11-16 15:37 ` Richard Salz
2021-11-16 15:50 ` Adam Thornton
2021-11-16 16:02 ` [TUHS] BASIC, RSTS, and UNIX Ron Natalie
[not found] ` <CAC20D2OT6ZcFOqnNCkqDUfAKy87wYu7mp7xx0ozzAT0eN1wr8g@mail.gmail.com>
2021-11-16 16:43 ` [TUHS] Speaking of groups: JHU Ownership Ron Natalie
2021-11-16 17:02 ` [TUHS] Book Recommendation Will Senn
2021-11-16 21:38 ` John Cowan
2021-11-16 21:46 ` Will Senn
2021-11-16 18:27 ` Jon Steinhart
2021-11-16 18:44 ` Heinz Lycklama [this message]
-- strict thread matches above, loose matches on Subject: below --
2021-12-03 2:50 Douglas McIlroy
2021-12-06 4:25 ` Adam Thornton
2021-12-06 4:42 ` Dan Halbert
2021-12-06 5:18 ` Charles H. Sauer
2021-11-24 15:50 Norman Wilson
2021-11-16 19:49 Douglas McIlroy
2021-11-16 20:02 ` Dan Cross
2021-11-16 23:16 ` Douglas McIlroy
2021-11-16 17:00 Douglas McIlroy
[not found] ` <CAKH6PiXinxBQGRqoeGMcG9CwTA5BNeU-LY164f-ZLYA4obsyuA@mail.g mail.com>
2021-11-16 18:47 ` John Foust via TUHS
2021-11-16 20:35 ` Bakul Shah
2021-12-02 21:35 ` Duncan Mak
2021-12-02 22:32 ` Bakul Shah
2021-12-02 22:34 ` Rob Pike
2021-11-16 14:57 Douglas McIlroy
2021-11-16 15:22 ` Richard Salz
2021-11-16 15:52 ` Ron Natalie
2021-11-23 2:28 ` Mary Ann Horton
2021-11-23 7:57 ` Henry Bent
2021-11-23 8:10 ` arnold
2021-11-23 8:28 ` Henry Bent
2021-11-23 17:26 ` Adam Thornton
2021-11-23 18:54 ` Ron Natalie
2021-11-23 19:04 ` Al Kossow
2021-11-23 19:39 ` Lawrence Stewart
2021-11-23 19:08 ` Ron Natalie
2021-11-23 21:54 ` Thomas Paulsen
2021-11-24 15:18 ` Richard Salz
2021-11-24 15:45 ` Larry McVoy
2021-11-24 18:34 ` Rich Morin
2021-11-24 18:40 ` Larry McVoy
2021-11-24 19:39 ` Clem Cole
2021-11-24 20:02 ` Larry McVoy
2021-11-25 10:26 ` Tom Ivar Helbekkmo via TUHS
2021-11-24 20:13 ` arnold
2021-11-24 20:18 ` Will Senn
2021-11-25 7:22 ` arnold
2021-11-24 20:15 ` Rob Pike
2021-11-24 20:21 ` joe mcguckin
2021-11-24 20:27 ` Rob Pike
2021-11-24 21:27 ` Richard Salz
2021-11-24 22:19 ` Charles Anthony
2021-11-14 14:37 Clem Cole
2021-11-14 14:55 ` Dennis Boone
2021-11-14 16:35 ` Ralph Corderoy
2021-11-14 18:20 ` Larry McVoy
2021-11-14 18:44 ` Clem Cole
2021-11-14 18:52 ` Ralph Corderoy
2021-11-14 19:27 ` Clem Cole
2021-11-15 9:49 ` Ralph Corderoy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c281bc22-1b63-a1f1-12b3-72770fb92cf9@osta.com \
--to=heinz@osta.com \
--cc=tuhs@minnie.tuhs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).