My 8 year old is asking if he can learn how to program.
He has asked specifically if I could set him up with a ‘programming kit with lessons’ for a Christmas present.
I’d like to support this, and it seems like it’s not a transient interest as he’s been all over scratch, and using things like minecraft commands for the last year.
I have an old (pre 2017) MacBook Air I can set up for this.
How do I / what would you advise I set up for him, to a) keep him safe online (he’s 8!) and b) give him the tools he needs in a structured way.
I am not a programmer. I know enough bash/shell and basic unix stuff to be dangerous and I was a front end dev a very long time ago, but I wouldn’t call myself a programmer and don’t know what concepts he needs to learn first.
Hugely appreciate any advice, thanks.
Edit: So I posted this then had a busy family day and came back to so many comments! I will methodically go through these all, thanks so much.
A couple of things on resources: he has expressed interest in 3D worlds and I noticed comments on engines, but wonder if that’s too advanced?
Totally agree with the short feedback loop rather than projects that take days.
He has an iPad 6 and I’m happy to pop a Linux distro on the Air, so certainly open to that.
Get them a copy of Factorio, it’s a game, but it’s all about computer science fundamentals, architecture, pipelining, busing, data integrity, etc. It’s a visual game, but it’ll scratch the itch of programming. It’ll get them to think.
Buy the hardware projects, the little ones with either a pic, an Arduino, something that does something physical. A little bit of programming. To make a thing happen. So they can experiment.
Look at the software robot competitions, there’s a couple on steam, there’s couple elsewhere, you can do it as a family project, whiteboard out the logic of what your robot will do, and you can write it together. And see how it acts.
Just make sure anything you get, has a very small feedback loop, so they can iterate very quickly. That’ll keep them engaged and exploring. You don’t want to get a daunting project that’s going to take weeks to see any output. You want things on the order of minutes, or even seconds to see what happens
Get a breadboard. Get a bunch of wire for it. And do small projects with the breadboard in a controller. It’s fun to move the wires around. You can even build a tiny 8-bit computer with a breadboard. And have a do things like output of display. It’s very tactile and hands-on. Excellent visual. There’s excellent YouTube tutorials up there for breadboard projects.
I wrote this a while back… I still think it’s true (though I don’t think its “finished”)
Factorio
So there’s this game I play… just a little bit. Factorio.
In playing this game, I’ve realized that there are several parts of the
game play that are directly applicable to software design. The idea of
Patterns becomes more clear on how to explain them and how to use them
in regular software when one can point to something a bit more concrete
(all be it a construct in a virtual world). A visual example of
reasonable design and problems of scale are also software
design issues that become more apparent with factorio.
Patterns
Patterns are a favorite rant of mine - that developers are
asking for a pattern to do something and you take a Something and a
SomethingElse and link them together and you’ve got a working application.
Factorio gives me a better way to explain what a Pattern is.
One of the problems that I’ve had in factorio is a pump that flickers
on and off rather quickly. This made a mess of the power display
(a very high frequency sine wave was evident - determining the actual
overall power consumption over time became more challenging) and
lights that were hooked up to it to indicate that the pump was on
were flickering at a high frequency (a rather annoying strobe).
The cause was that the pump (and light) were connected to a tank
containing refined oil. The pump was to pump off excess when
it got to 24,000 units. If the tank was at 24,100 units the pump
would pump off 200 units putting it at 23,900 and shutting off.
One sixtieth of a second later, something would push another 200 units
of refined oil into the tank and the pump would trigger on and off
for a sixtieth of a second - the flickering and the high frequency
showing up in the power.
The solution to this is to use what is known as a
Schmitt trigger. This is a circuit that feeds back to
itself with a positive feedback loop. When the trigger turns on
at a given threshold it will remain on until the value drops below
a different threshold. The way that the trigger
was set up was so that when the material reached 24,000 units, it
would turn the pump on until the level was at 22,000 units.
The way this was implemented was to use a decider combinator which
takes a signal as input (the amount of material in the tank) and
sends a signal as output (the value 1 in a given channel) based on
some logic (the amount of material in the tank is greater than 24,000).
Then a second combinator - an arithmetic combinator - would take that
signal of 1 and then multiply it by 2,000 and send that result into
the input of the decider combinator. The result would be that the
signal is now 26,000 and it would run until the material drops to 24,000
in which case the signal from the decider would switch from 1 to 0 and
the arithmetic combinator would stop sending the additional 2000 units
as a signal… and we would see the real value of the tank at 22,000.
The Schmitt trigger is a Pattern.
It is silly to be suggesting that one would design something based
on the answers to “what are useful Patterns when creating an oil
processing area?” One doesn’t add something unless its necessary
to solve a problem. And one doesn’t go looking for places to use
a Schmitt trigger or other Pattern - they are tools for solving
specific problems.
Reasonable design
The first base that a person builds is often what is known as
a spaghetti base. The layout is ad-hoc. As you need something from
somewhere (some iron plates) to get to somewhere else you split off
from a convenient, nearby belt with some iron on it and run it over
to the place it is needed. It sounds ok at first, but doing this
a few dozen times the layout becomes more and more convoluted.
Enter the main bus.
The main bus is a design where there is a large number of belts
running down the center of the base and things tap off of it
perpendicular for specific factories that build a given item.
The taps off are well researched designs that have a specific
fraction of the items shunted off to the factory. Instead of
trying to figure out where the iron came from and how to get
more iron down to that place maybe a few hundred tiles away, one
can look at the main bus and see a dozen tiles and understand
what that sub factory is making and how many resources it needs.
The reasonable design allows one to more quickly fix issues of
resource starvation and allocation along with refactoring of specific
areas of the overall system without worry about impact to things
downstream. The base is reasonable.
Problems of scale
After playing a bit and winning the game a time or two, one gets
the urge to build BIG. Not these little “launch a rocket every
couple of minutes” but rather “launch a rocket every second.”
The design for the one rocket every few minutes is fundamentally different
than the design for one rocket every second. The layout of the base for
a simple mainline works well - but it doesn’t have the throughput for
materials that would enable the launch a rocket every second goal.
For this, one starts building outpost factories that do one thing,
and one thing well. This outpost takes iron ore and produces
iron plates. That outpost takes iron plates and copper plates and
produces green circuits. So on and so forth.
This is a very different design - switching from a main bus to
train logistics (trains become the way to move massive amounts of
material). The very structure of the base for a megabase vs a
regular base shows differences at every level.
Many times one reads about developers having difficulties
with microservices and trying to build something to scale to
1000 users per second. And then comes the moment when they
are asked how many users per second they’re currently getting
and the answer is something along the lines of “Um, we’re getting
maybe 5 a second on a good day… but we’re getting ready for
being Amazon or Twitter scale.”
Design for what works. It is often easier to redesign a working system
up than it is to try to start out with the megabase or amazon scale
system and fight all those little problems of outpost base train
networks and microservices that you haven’t encountered before in
a working system.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
Everyone else’s suggestions are great.
Get them a copy of Factorio, it’s a game, but it’s all about computer science fundamentals, architecture, pipelining, busing, data integrity, etc. It’s a visual game, but it’ll scratch the itch of programming. It’ll get them to think.
Buy the hardware projects, the little ones with either a pic, an Arduino, something that does something physical. A little bit of programming. To make a thing happen. So they can experiment.
Look at the software robot competitions, there’s a couple on steam, there’s couple elsewhere, you can do it as a family project, whiteboard out the logic of what your robot will do, and you can write it together. And see how it acts.
Just make sure anything you get, has a very small feedback loop, so they can iterate very quickly. That’ll keep them engaged and exploring. You don’t want to get a daunting project that’s going to take weeks to see any output. You want things on the order of minutes, or even seconds to see what happens
Also, remember Human Resources Machine. Its a puzzle game thats actually a progamming language
Get a breadboard. Get a bunch of wire for it. And do small projects with the breadboard in a controller. It’s fun to move the wires around. You can even build a tiny 8-bit computer with a breadboard. And have a do things like output of display. It’s very tactile and hands-on. Excellent visual. There’s excellent YouTube tutorials up there for breadboard projects.
https://www.youtube.com/channel/UCS0N5baNlQWJCUrhCEo8WlA
This guy has some excellent breadboard projects. Find an easy one. And do it together with your child
deleted by creator
Ah, haven’t thought about factorio. On that matter 7 Billion Humans is a cool game that can teach the basic logic behind programming.
“send me your favorite base” is probably a better programming interview than most
Seconding all of the above. Also tis 100 and exabots. All games by that developer actually.
I love Zachtronics, but I think their games are very ambitious for 8 years old. Maybe teenager with some discreet logic skills under the belt.
You are absolutely right, I overlooked the age.
If you get them factorio then they’ll just play that all day instead of learning programming
factorio is programming
I wrote this a while back… I still think it’s true (though I don’t think its “finished”)
Factorio
So there’s this game I play… just a little bit. Factorio.
In playing this game, I’ve realized that there are several parts of the game play that are directly applicable to software design. The idea of Patterns becomes more clear on how to explain them and how to use them in regular software when one can point to something a bit more concrete (all be it a construct in a virtual world). A visual example of reasonable design and problems of scale are also software design issues that become more apparent with factorio.
Patterns
Patterns are a favorite rant of mine - that developers are asking for a pattern to do something and you take a Something and a SomethingElse and link them together and you’ve got a working application.
Factorio gives me a better way to explain what a Pattern is.
One of the problems that I’ve had in factorio is a pump that flickers on and off rather quickly. This made a mess of the power display (a very high frequency sine wave was evident - determining the actual overall power consumption over time became more challenging) and lights that were hooked up to it to indicate that the pump was on were flickering at a high frequency (a rather annoying strobe).
The cause was that the pump (and light) were connected to a tank containing refined oil. The pump was to pump off excess when it got to 24,000 units. If the tank was at 24,100 units the pump would pump off 200 units putting it at 23,900 and shutting off. One sixtieth of a second later, something would push another 200 units of refined oil into the tank and the pump would trigger on and off for a sixtieth of a second - the flickering and the high frequency showing up in the power.
The solution to this is to use what is known as a Schmitt trigger. This is a circuit that feeds back to itself with a positive feedback loop. When the trigger turns on at a given threshold it will remain on until the value drops below a different threshold. The way that the trigger was set up was so that when the material reached 24,000 units, it would turn the pump on until the level was at 22,000 units.
The way this was implemented was to use a decider combinator which takes a signal as input (the amount of material in the tank) and sends a signal as output (the value 1 in a given channel) based on some logic (the amount of material in the tank is greater than 24,000). Then a second combinator - an arithmetic combinator - would take that signal of 1 and then multiply it by 2,000 and send that result into the input of the decider combinator. The result would be that the signal is now 26,000 and it would run until the material drops to 24,000 in which case the signal from the decider would switch from 1 to 0 and the arithmetic combinator would stop sending the additional 2000 units as a signal… and we would see the real value of the tank at 22,000.
The Schmitt trigger is a Pattern.
It is silly to be suggesting that one would design something based on the answers to “what are useful Patterns when creating an oil processing area?” One doesn’t add something unless its necessary to solve a problem. And one doesn’t go looking for places to use a Schmitt trigger or other Pattern - they are tools for solving specific problems.
Reasonable design
The first base that a person builds is often what is known as a spaghetti base. The layout is ad-hoc. As you need something from somewhere (some iron plates) to get to somewhere else you split off from a convenient, nearby belt with some iron on it and run it over to the place it is needed. It sounds ok at first, but doing this a few dozen times the layout becomes more and more convoluted.
Enter the main bus.
The main bus is a design where there is a large number of belts running down the center of the base and things tap off of it perpendicular for specific factories that build a given item.
The taps off are well researched designs that have a specific fraction of the items shunted off to the factory. Instead of trying to figure out where the iron came from and how to get more iron down to that place maybe a few hundred tiles away, one can look at the main bus and see a dozen tiles and understand what that sub factory is making and how many resources it needs.
The reasonable design allows one to more quickly fix issues of resource starvation and allocation along with refactoring of specific areas of the overall system without worry about impact to things downstream. The base is reasonable.
Problems of scale
After playing a bit and winning the game a time or two, one gets the urge to build BIG. Not these little “launch a rocket every couple of minutes” but rather “launch a rocket every second.”
The design for the one rocket every few minutes is fundamentally different than the design for one rocket every second. The layout of the base for a simple mainline works well - but it doesn’t have the throughput for materials that would enable the launch a rocket every second goal.
For this, one starts building outpost factories that do one thing, and one thing well. This outpost takes iron ore and produces iron plates. That outpost takes iron plates and copper plates and produces green circuits. So on and so forth.
This is a very different design - switching from a main bus to train logistics (trains become the way to move massive amounts of material). The very structure of the base for a megabase vs a regular base shows differences at every level.
Many times one reads about developers having difficulties with microservices and trying to build something to scale to 1000 users per second. And then comes the moment when they are asked how many users per second they’re currently getting and the answer is something along the lines of “Um, we’re getting maybe 5 a second on a good day… but we’re getting ready for being Amazon or Twitter scale.”
Design for what works. It is often easier to redesign a working system up than it is to try to start out with the megabase or amazon scale system and fight all those little problems of outpost base train networks and microservices that you haven’t encountered before in a working system.