Re: [TUHS] Book Recommendation

Clem Cole writes: 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