|
Pshaw. I can do ancient BASIC on my MicroVAX -- in the interactive environment. (Yes, it is precisely why I bought a VAX.)
Unfortunately I have found that Turbo BASIC does not run on Win 10 x64. 
|
|
|
|
|
raddevus wrote: Maybe just use JavaScript in a browser to teach. It's much more relevant and has far fewer barriers to entry.
By "non-distracting environment", I'm assuming the author meant to avoid exactly the sort of thing you're proposing with JavaScript: Do you try teaching what'll work on all browsers, or only those from a certain generation forward? Do you bring in (or even mention) the plethora of frameworks? How are you going to teach basic file I/O when you can't escape the browser sandbox? Or are you going to do server-side JavaScript such as Node.JS where you can do these operations? How do you gently introduce (to newcomers) the distinction between server-side and client-side code, and debugging on each? Are you going to get into packages? So many questions to answer, and justify.
Perhaps the author's point is that because these older environments are much more limited in what they can do, you're forced to focus on the "common fundamentals" without all the other "distractions" (as he puts it)...
All of that said--and while I've learned on the C64 myself and might see his point--I have to think a Raspberry Pi might still be a better starting point, if only (as you suggested) in terms of relevance.
|
|
|
|
|
Yeah, those are good points. Every web browser is almost like it's own OS.
But you could even set out the rule that the reader could use FireFox, Chrome or Edge and then say, "ok, hit F12" (dev tools)
type: 2+2<enter>
Works in all 3 of those browsers.
After that, there's a lot you could teach directly from the console.
I think a lot of books that try to teach JavaScript do overwhelm with all the node.js, extra libraries (even jQuery) stuff.
If you're learning JavaScript you should learn the good old fashioned way.
document.getElementByID(), etc. 
|
|
|
|
|
The problem with that approach is, can you really make a "complete program" you can package and share with someone and use elsewhere ? You could with the author's original approach. How would that work with a browser? That would be clumsy at best.
|
|
|
|
|
dandy72 wrote: he problem with that approach is, can you really make a "complete program" you can package and share with someone and use elsewhere ?
I think so. I think it is even easier actually if you think about SPA (single page apps).
Here's some very basic and (possibly) interesting JavaScript I created to create a very small "game".
You can see it in your browser right now (without all the deployment challenges you'd have with Commodore BASIC) at :
Robot Dots - HTML5 / JavaScript sample[^]
The code to do that is only 271 lines long.
You can read the article that explains the code (and see an animated gif of it in action)at:
HTML5 Canvas : Clean JavaScript & Code Organization Allows Faster Dev, Easier Extensibility[^]
I'm not saying that is a completely introductory article -- because there are some slightly advanced topics -- but I think you could get the interested party there very quickly.
And, yes, JavaScript is limited in many ways (cannot write to file system, etc) but again I'm saying it is a nice language for getting new devs interested -- not as the final long-term goal. And if they are going to learn it as the long-term goal there are lot of caveats.
|
|
|
|
|
Well, I think the author wants his child to simply learn the basic imperative programming, at first.
And I agree, maybe because I ancient enough to start programming in 1984  on a ZX Spectrum in basic and then fallen in love with Assembler up to today; I still remember very well how satisfying it was to literally conquer & dominate a routine, to move an 8x8 pixels little shape in a rudimentary maze, respecting walls and obstacles!
Back to the book, it could be a good solution to start the hard way, especially if it contributes to create a special father-son link.
|
|
|
|
|
The thing to remember is that nowadays kids are used to playing amazing games on smartphones, so making them work hard to just move a few pixels on the screen may be difficult.
|
|
|
|
|
I have a child 6 years old, and he's fond of games so much, too.
Being my wife a primary teacher involved in [try to] teaching coding, too, we approached some tools, Scratch in primis, and we took some experiment with our son; but I found that these tools are somehow too... funny: just like the platform overloads young children, creating more distractions than focus.
My very personal experience is that less may be more at these ages, in terms of the challenge the child is asked to solve, even if you carefully follow them side by side.
However, we are in Italy, so we have nothing professionally helping in teaching coding, just the good will and deep personal motivation.
|
|
|
|
|
Hey Voracy I am Italian too and I had the same impression about Scratch and similar environments when some friends asked me to help their young sons experiment some coding.
I would be very interested if you could share yours and your wife's experience and some suggestions - next Monday a friend will visit with his young son to chat a bit since the boy seems interested in programming.
Thanks in advance. 
In theory, there is no difference between theory and practice, but not in practice. - Anonymous
A computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are, in short, a perfect match. - B. Bryson
|
|
|
|
|
voracy wrote: I still remember very well how satisfying it was to literally conquer & dominate a routine, to move an 8x8 pixels little shape in a rudimentary maze, respecting walls and obstacles!
Great memory. I understand what you are saying. I had a Coleco Adam[^] and would faithfully type BASIC programs from Family Computing magazine in...and ultimately hit some bug I couldn't figure out.
Since computing wasn't everywhere we knew we were part of something mysterious and fascinating and everything was simpler and more difficult then. All of us who were fortunate enough to experience it often want to get back to it.
|
|
|
|
|
I wonder if there are examples available on a 5 1/4 floppy so I can read them into my Commodore that is packed away in the loft?
Then I can see how I should have written my first program on a 'PET'.
|
|
|
|
|
My first programming experience was on a Commodore PET 8K.
As rudimentary as it was, that set my path in CS.
|
|
|
|
|
Likewise: I remember the fun I had using overlays - read from the cassette tape - because there wasn't enough space in that 8K.
|
|
|
|
|
I recall us discussing in class how the tape storage worked. Our math teacher was our budding CS teacher, and he had only slightly more of a clue than the students did. I'm not dinging the guy -- he was a great teacher, possibly the best I've ever had -- but this illustrates the early days of teaching CS in high schools.
|
|
|
|
|
|
This idea is actually brilliant. Read on for an explanation ...
It was mentioned previously that programming is not for the masses -- very true -- it's a distinct skill set enjoyed by a small minority of the population. When politicians talk about programming for all kids, the concept is ridiculous. But most ideas from politicians are (doesn't matter where, they're peas in a pod).
However, giving all children a chance to program enables the ones that will succeed to get that taste. Remove the expectation that all children should program -- presenting programming to all is a good idea. The ones that fit our mold will continue, the others will drop off and follow their own path.
JavaScript? I can't think of a better way to drive a child away from programming that JavaScript. Unless it's Java. Or C#. Or pretty much any modern language.
Ignoring the ridiculous complexity of "modern" languages and tools, if given visual tools children will focus on the visual aspects -- worry about the minutia of screen placement and appearance, not logic.
By using a basic language (pun intended) the student is focused on program logic and producing an expected result. That is the essence of programming -- not what looks pretty on the screen.
Teaching the children to think procedurally at first gets them into problem solving in a straightforward way. Teaching OO later on provides a more diverse skill set and opens their mind to the idea that multiple methodologies exist and each has its own place.
Yeah, this idea is brilliant.
|
|
|
|
|
BryanFazekas wrote: By using a basic language (pun intended) the student is focused on program logic and producing an expected result. That is the essence of programming -- not what looks pretty on the screen.
Agree 100%. That's part of the problem with the way most programming is taught now : they jump right into the complexities of UI etc which is meaningless until you really understand what you are doing.
And, yes, OOP should be taught later since it is only a way to organize your code. When you first start writing code you just want to see it do something.
This makes me think of the K&R C book. It's just a bunch of scripts really. They go through and show you how to do some simple things and since there was no GUI they concentrated on simple procedural programming. It was a simpler and more difficult time all together. You could do the simple quite easily but the complex was quite a bit harder to pull off due to memory and CPU limits.
|
|
|
|
|
I have K&C on my bookshelf -- I doubt I've touched it in 20+ years, which is how long since I've done C. I need to pull it off the shelf and leaf through it ...
|
|
|
|
|
With few words, you get straight to the core.
I fully agree.
|
|
|
|
|
I definitely learned one important lesson from the C64.
Fond memories of one sibling reading code out of a print magazine while the other typed the 4 page program into the C64...
Last statement entered and
RUN
system freezes.
Break key does nothing! nooo....
Type it in again.
Last statement entered and
RUN
system freezes again!
Break key does nothing! noooooooooooooo....
Type it in for a THIRD time!
LESSON LEARNED!
SAVE the program first!
RUN
system freezes. nooooo problem.
LOAD the program
Must debug before we can play the game!
This is back in the old school magazine type face days where a number 1 and a lower case L/l were identical glyphs!
Something with a FOR loop was typed with a 1 or an l switched.
After the fix was implemented,
RUN
Play Castle Dungeon and save the castle by disarming the bombs while avoiding lions and pits.
It was a great program to dissect as it included maze generation, sprite(graphic blob) usage, joystick input, and a few sound effects.
|
|
|
|
|
englebart wrote: RUN
system freezes again!
Break key does nothing! noooooooooooooo....
Yep, that is what we learned.
I remember typing numerous programs into my Coleco Adam [^] only to have them fail. I could never figure out if it was my typing or the program itself.
|
|
|
|
|
I saved some IBM punch cards for my kids. Need to work up a card reader and CPU.
|
|
|
|
|
Bruce Patin wrote: I saved some IBM punch cards for my kids. Need to work up a card reader and CPU.
 
|
|
|
|
|
Bruce Patin wrote: I saved some IBM punch cards for my kids.
<shudder>
I did punch cards my freshman year, then the school converted to terminals.
At the end of the first semester I recall seeing an upper classman carrying a large deck (probably 300+ cards) to drop off at the computer center. At that time we wrapped our deck with a couple of sturdy rubber bands and dropped them in a slot. At the beginning of the semester we could return in 1-2 hours to get our deck + printout. At the end of the semester it was 12 hours. This enforced reviewing the code and NOT making mistakes.
Anyway, the upper classman dropped his deck and the single rubber band he used broke. Cards scattered all down the hallway. He looked like he was going to cry, started to pick up his card, then turned and walked away.
The morals of this story? 1) use more than 1 rubber band. 2) use a wide marker to draw a diagonal stripe across the top of the deck to the cards can be re-ordered visually.
|
|
|
|
|
Javascript to teach an 8 year old programming? You just got to be kidding!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
