Why should children program? A review of Seymour Papert's Mindstorms

With respect to using paper and pencil for math there is still no contest between doing math on paper and doing it with your finger on an iPad.

And even if it is superficial awareness, those kinds of games exercise the fantasy-making faculties that make history itself interesting to learn about, even later as an adult.

Another example. There was this flop of a game in the early 90s, called SimEarth, that I have very fond memories of. It taught me about the Gaia hypothesis and the carbon cycle and stuff. Gameplay was pretty wacky though.

I blame the thin font, not the low contrast, for the readability problem.

Sorry for the inconvenience. I'm an embedded developer and know nothing about web design. The jekyll theme was copy-pasted from one of the default styles provided by github.

Next step: Learn some css to make the design acceptable.

:)

There is an obvious reason to oppose such things: opportunity cost. learning anything takes time, and the curriculum is full. If you want to teach a new topic, you will have to remove something else. This might not be worth it.

(That said, I still support basic programming and basic computational reasoning at school. I propose we take away some of the math away, though I don't know which math exactly.)

Up to a certain age, the mental models just aren't there yet to make it worthwhile. It's not that useful trying to teach a child programming when they are only learning to make out different letters or numbers or their concept of time (or any abstract thought for that matter) is very rudimentary.

That leaves you only able to teach them very basic things, which end up looking more like a game than something that you would regard as programming.

By the time a child is say 10, things start to change. At that point though, their personality and the general direction of their interests is going to drive itself.

Better to get them interested in building things, tinkering, abstract thought and games, etc. and help them develop mental models which make it easy to pick up programming later.

Codemancer has variables and conditionals, and uses them for various things. Some of the game is very tactical, so conditionals are used to deal with enemies who have semi-random behaviour. There are also levels that take place "in the dark" (with a limited field of view).

Yes, "code your way to the target" games have become somewhat of a genre. I think the story is one source of differentiation, as is the programming interface -- Codemancer has no numbers greater than 5 (arithmetic is mod 6), to keep the game from getting math-heavy. All the functions are symbolic, so there's no reading required.

In Codemancer user-defined functions are "pages" in your spell book. Players can call other pages, and even the page they're on (this is much later in the game). You can also Cast a page onto an enemy who has been weakened. We've seen that kids are pretty comfortable with the idiom of "Pages."

I think there will be a shift in how we design software. Right now, software is mostly organized into monolithic packages which are about the maximum size a professional developer can make sense of in 40 hours per week. For the most part, all corners of the codebase are written with the expectation that they will be read by an expert in the language who understands the whole codebase. Lots of side effects, advanced control structures, etc. In order for programming literacy to take off, we will first have to start organizing some of our software for widespread human understanding.

Instead of one giant pro-level repository, you will have a toplevel layer which is mostly configuration code, but which is written in very domain-relevant language, using only simple programming primitives: functions and literals. It will be boxed into small, understandable modules, and editable in a browser like any simple document.

The next layer down will be generic algorithms and data structures, also written using simple programming primitives, and designed with very forgiving APIs, again using as much domain-specific language as possible and pushing non-domain specific implementation details down into libraries.

The third layer will be implementation-specific code, highly optimized, using the full spectrum of language tools and programming constructs. Only the domain of professional programmers.

Everyone, including children and executives will dabble in the top layer. Domain professionals (everyone in your organization who is not a full-time programmer) will work in the second layer, only in the part of the software that they specifically interact with in their work. Full-time coders will maintain the third layer, and will think of their role more as a support role, building tools to support the organization, rather than maintaining total control over the codebase.

I don't believe that will happen in our childrens' lifetimes for arbitrary programs. You are only thinking about half of the problem: the AI understanding code and available libraries. But the other half of what a "common dev" does is understand the person who is telling them what needs to be done. Half of the work of the programmer is to understand what their community actually wants despite their ability to articulate it deterministically. An AI being able to do that for all 6 billion people on the planet is not even theoretically possible at this time. We don't even have the anthropology, sociology, and psychology to model, let alone the computing resources and programmers to do it.

> don't need to solve by hand their equations, for them it is much more important to be able to use modeling and simulation tools.

Having an algorithm available in tool form doesn't remove the need to understand the algorithm. You need to know how it works to know when to use it and what the results mean. There are widespread problems in the scientific community with people using analyses that they don't understand and publishing false conclusions.

The only tools which are used widely and correctly are the ones which are designed well and taught well through widespread cultural practices, which is a tiny subset. Programming literacy will unlock orders of magnitude more algorithms than would ever be refined to that level by the software industry.

Ha, I did that as well with Mindstorms RCX in like 11th grade or so! Later, in university, Mindstorms NXT was used: Our first assignment was to follow a track on the ground and the team I was the only one had two programs, one for recording the track with the sensors and another for following the previously recorded track in high speed without using sensors at all.

Of course you don't think that, it was just me being a passive-aggressive dickhead, but putting aside me deserving a punch in the face, mathematics is about patterns and flow and repetition and singularities and mappings and transforms and logic and states and abstraction. Every program written is an expression of mathematical thought.

Kludging around with numbers is to mathematics what paint-by-numbers is to art.

* There were always word problems. I had to take a few sentences or even a paragraph, and turn it into a representation that allowed me to get the answer. In later years this representation included variables that let me change some details and still get the right answer. Many of these had useless information included in the description, or were confusingly written, and I had to puzzle out the deeper model. This is not very different than taking a spec and making it into software. Particularly if you work directly with end users, who may include lots of unnecessary details. Sure the thing I build uses code rather than algebra equations, but that is not a huge leap - they are both mechanical rules that when applied to a problem give great, accurate answers.

* Speaking of variables - just learning variables and internalizing them is pretty damn useful for coding. This is not necessarily an easy thing to internalize - tutor some kids at basic algebra sometime. The idea that X holds a value seems pretty easy to grasp, but reasoning about X being any value[0] is pretty hard to grasp (until you do, then people say "i don't know why that was hard").

* Order of operations is another thing that was super important in k-12 math. Understanding that doing things in different orders gets different results is another big concept. It also leads to other operation ordering things - like doing things in a different order may be easier, and it's ok because they are equivalent (this is a huge chung of algorithms - do the steps in a different, equivalent order, and it's less work)

* Factoring in algebra and factoring in code are literally the same thing. Here is a list of variables and operations. Rearrange them into a different list of variables and operations using different functions.

* Substitution and systems of equations are pretty much the same thing. If y = x + 1, I can replace any Y with (x+1) and get correct answers. In coding we call this inlining and loop unrolling. Or even just replacing

  $thing = func();
  other_func($thing);

   other_func(func())

* Cartesian coordinates are very helpful when doing any kind of page layout - like say HTML/CSS.

* Simple set theory is useful all the time too. Heck I even use Venn diagrams (something I learned in 2nd grade) all the time. Set theory comes up obviously in databases (and other data stores) join is just a method of computing intersections. But it also comes up in other places when defining things. A huge problem when designing systems is what I call the "square/rectangle" problem - all squares are rectangles but not all rectangles are squares. This is fundamentally a set definition problem - figuring out what set we are talking about based on certain properties applies to (but is not limited to): database schema design, object hierarchy, program scope, filter creation, and so on.

Looking at your comment again makes me wonder if you are questioning the Parent's semantics of "useful functionality" and "simple" vs "trivial". I'm not going to dive into that, but I will say I used many of the above concepts daily in simple shell pipelines (opening the semantic argument of what a program is, but going as broad as possible, a shell pipeline is a one off program that can be turned into a stored program by putting it in a file).

I regularly want to find something in a logfile. Logs have a lot of data. Oh, I can find the subset with grep.

   cat log | grep thing

This is a trivial example of using composition, substitution and set thinking. I can extend it with "thats a useful search, maybe use a variable" and so on. Can this be learned, and done without having known the stuff taught in k-12 math? Maybe I don't know, but the place I first encountered and internalized those concepts is math class.

Even more controversial (from the is this a program point of view) is that these things are all useful in doing excel formulas and vba scripts.

[0] I know that's not strictly true, particularly with types in a computer language. But they taught me about domains, and things like "this is true when X is not 0" and so on. This translates well to code too - checking that values are acceptable in tests and input sanitization, or conversely, finding weird values by fuzzing are all applications of domains.

I learned basic trigonometry early (with a textbook and some advice from a school mathematics teacher) for the purpose of rotating vector graphics in BASIC to make a Spacewar clone. I expect there are many people who learned about complex numbers because they wanted to draw fractals. And linear algebra can sound boring until you realize how useful transformation matrices are in graphics programming. Programming is a great motivation for learning mathematics because it's so much more fun when you have mathematics skills.

I'd also say that programming is a mathematical endeavor by nature; logical manipulation is a branch of mathematics. If you're working at a level of abstraction where you aren't specifying logical manipulations, then you're filling out a template, not what I'd call "programming".

Seriously, though - I appreciate the suggestion - I was thinking of triangles drawing triangles, and turtles drawing turtles - but it didn't occur to me to mix the two. Great idea!

I wasn't aware that the site was blocking zooming, I had just copy-pasted an old jekyll theme.

I've removed the references to viewport and a scale_fix.js file, hope that helps.

You might be right about the tinkering view, and to be honest, I know that sometimes procedural thinking is a must-have ability that kids should posses.

But then again, programming is not just coding, and kids getting used to imperative-style would probably miss the whole point, which is finding challenge.

Anyway, you know how hard it is for a person who is used to imperative to get it out of his system and program functionally. I have found the other way around much easier. Just a thought.