SoylentNews is people
SoylentNews
The other thing is that in order to learn, children need to have fun. But they have fun by really being pushed to explore and create and make new things that are personally meaningful. So you need open-ended environments that allow children to explore and express themselves.
(This Inventor Is Molding Tomorrow's Inventors, IEEE Spectrum)
IEEE Spectrum has a (short) sit-down with Marina Umaschi Bers, co-creator of the ScratchJr programming language and the KIBO robotics kits. Both tools are aimed at teaching kids to code and develop STEAM skills from a very young age. Other examples of such tools are the mTiny robot toy and the Micro:bit computer.
Being able to code is a new literacy, remarks Professor Bers, and like with reading and writing, we need to adapt our learning tools to children's developmental ages. One idea here is that of a "coding playground" where it's not about following step-by-step plans, but about inventing games, pretend play and creating anything children can imagine. She is currently working on a project to bring such a playground outside: integrating motors, sensors and other devices in physical playgrounds, "to bolster computational thinking through play".
Given how fast complicated toys are being thrown aside by young children, in contrast to a simple ball -- or a meccano set, for the engineering types -- I have my doubts.
At least one of the tools mentioned above is aimed at toddlers. So put aside your model steam locomotive, oh fellow 'lentil, and advice me: from what age do you think we should try to steer kids into "coding" or "developing", and which tools should or could be used for this?
Feel free to wax nostalgic about toys of days past, of course, in this, one of your favorite playgrounds: the soylentnews comment editor.
(Score: 2) by JoeMerchant on Friday November 01 2024, @03:54PM
Well, the "empty box app" in Creator was less than 10 lines of code... all the windowing stuff comes along for the basic project setup as a GUI app. That was the point of drawing the box for them, so they already had the graphics object all set up and line draw examples to "draw on." We were already in Qt4 by then.
>part of the test was seeing if they'll try to define the problem clearly before starting work, always a good idea.
Absolutely. If I were designing the test today, I'd probably include a user input of some sort and see if they sanitize the input or not, or at least ask about input sanitization.
I don't know if I have 15 minutes of patience, but: "10 cycles of a sine wave" - I think I asked: "just to be sure, that's 10 up and 10 down?"
So:
I think during my test the include of math.h didn't work on whatever environment they had me in, possibly a tweaked Turbo C?, so I just replaced 10 with 62.83185
As you said, debugging goes pretty quick when things don't look like you expect.
🌻🌻🌻 [google.com]