I’m not sure that this matters much in terms of solving actual problems though ...
That is certainly correct. But The Industry hasn't successfully abstracted things such that pure problem solving is all there is to software creation. Current abstractions create a reliance on (probably inefficient, likely costly) infrastructure. One needs to understand how so much of a system works so that changes can be made to improve performance and/or reduce costs.
I took a look at EndBASIC and I find it rather awesome. But I also think it's limited to folks who have experience a perspective similar to my own. When looking this from my 7yo's POV, she would have no idea where to start. I could guide her, but it would be nothing like how I learned, alone, on an Apple //c. I'm certainly biased in thinking "how I learned was a pretty good process," and I wouldn't want to assume anyone else learns like that, but exposure to a simple (but complete) system and the ability to program it seems like a phenomenal way to learn.
----
I was thinking recently that it would be beneficial to teach the last century of technological advancement at a slow-ish pace. Kids spend a few months getting to know/understand how early telephone systems routed calls by using the same equipment from the day. Advance up through rotary dial, touch tone dialing, cordless phones, mobile phones ... over the course of a couple years. Parallel to that, the same kind of thing with computers and programming - switches, punch cards, tape, disk; mainframe, mini-, micro-computers; ...
Why start at rotary phones? Why not start them out on Morse code? Semaphore? Naval flags moved data faster than horses for centuries. Should kids learn how to cut pens out of quills?
Comments
That is certainly correct. But The Industry hasn't successfully abstracted things such that pure problem solving is all there is to software creation. Current abstractions create a reliance on (probably inefficient, likely costly) infrastructure. One needs to understand how so much of a system works so that changes can be made to improve performance and/or reduce costs.
I took a look at EndBASIC and I find it rather awesome. But I also think it's limited to folks who have experience a perspective similar to my own. When looking this from my 7yo's POV, she would have no idea where to start. I could guide her, but it would be nothing like how I learned, alone, on an Apple //c. I'm certainly biased in thinking "how I learned was a pretty good process," and I wouldn't want to assume anyone else learns like that, but exposure to a simple (but complete) system and the ability to program it seems like a phenomenal way to learn.
----
I was thinking recently that it would be beneficial to teach the last century of technological advancement at a slow-ish pace. Kids spend a few months getting to know/understand how early telephone systems routed calls by using the same equipment from the day. Advance up through rotary dial, touch tone dialing, cordless phones, mobile phones ... over the course of a couple years. Parallel to that, the same kind of thing with computers and programming - switches, punch cards, tape, disk; mainframe, mini-, micro-computers; ...
It'd be pretty expensive though... :(
Why start at rotary phones? Why not start them out on Morse code? Semaphore? Naval flags moved data faster than horses for centuries. Should kids learn how to cut pens out of quills?
It’s been a few years but the book Code by Charles Petzold covers a number of those topics which I found interesting to learn about (but not study).
https://www.codehiddenlanguage.com/
We should absolutely include the telegraph, wired and wireless. Which leads into radio…
I just picked an arbitrary starting point to illustrate the hands-on approach I would like to see.
We made and used quills in primary school, in a sort of arts and crafts/history crossover, I suppose. Didn't hold us back any, hopefully.