At my age I can barely read the article's thin, small, low-contrast font, but I believe that I agree with the author. I read Mindstorms back when it was first published and thought it was reasonable. Now, I'm more skeptical. I see the early introduction of technology into schools as distractions.
I have the benefit of experiencing life before the impact of computers on society. Heck, my parents wouldn't even let me get toys that required batteries (too expensive to replace). So, I played with toy trucks and I read and I climbed trees and I drew. I drew pictures of locks, of circuits, of mazes, of buildings.
My own children grew up very differently. Playing video games, and their schools insisted on early introduction of laptops, convertible laptop/tablets, and iPads. At an age where I would be drawing complicated diagrams of electrical relays to play tick-tack-toe (which, because I was just a 13 year old kid with no training would have never worked) they played XBox.
I tried to get the schools to use paper and pencil for math lessons instead of iPads, but the forces at work in school systems end up encouraging many distracting technologies being introduced with no discernible benefit.
Furthermore, the development of abstract thinking, necessary for programming, happens over time in children. Is there any evidence that early programming instruction hastens it's development? Real research in education seems pretty weak.
Thank you for your suggestions, very much appreciated. I've updated my styles.css file.
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.
A fancy CNAME and Jekyll layout might make your "blog" look professional and polished but that is subjective to the readers, and they won't add much to the content.
A simple github repo + README.md is quick, flexible and easy to maintain for years in the future. We can leave the style to GitHub guys. :-)
As the author of content, I want my content to utilize best practices and publication standards so that it has the best chance of getting read and distributed.
A "simple" GitHub repo ReadMe isn't going to have any of the right tools for sharing or distributing content, it won't allow you to capture signups, or A/B/n test; doesn't even allow you to put in analytics to see if people are reading your content, you can't build domain authority for your other work... It's pretty much the modern equivalent of stapling your flyer to a telephone pole.
You'd be better off with a properly configured WordPress, or other CMS-based, site.
There have been a bunch of posts today about scanning content, but here's a great pre-launch checklist. Do as many of these as you can, as fast as you can. Ha.
Just as you most probably wouldn't be against a child learning a second language or learning to play music I see no reason why one would be against them learning programming.
Learning to program is like learning a language. The language spoken by most feedback mechanisms in the world, more than any individual national language.
The point is not to turn them into programmers but to make them comfortable and familiar with the construct of computer syntax.
Just like you don't need to learn Chinese you don't need to learn computer programming but just like learning chinese or playing an instrument will affect your thinking so will learning to program even if you don't end up a programmer.
We can't compare this with our own upbringing even though it's tempting just like our parents couldn't compare our upbringing with theirs.
> Just as you most probably wouldn't be against a child learning a second language or learning to play music
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.)
> There is an obvious reason to oppose such things: opportunity cost. learning anything takes time, and the curriculum is full.
The way I see it the bigger bottleneck is not time but motivation. You can fill a whole day with studies that a student isn't interested in and end up getting nowhere, or you can spend an hour on a topic that is able to hold a student's fascination--I would pick the latter any day. Engagement is simply a prerequisite for meaningful learning at scale; without it progress is slow and uneven at best.
Time and workload is certainly necessary to consider. However, removing parts of existing curriculum may not be the best way.
Considering the fact that computers have pervaded across domains, we could try integrating computational thinking with these domains. For example, you could teach Chemistry using simulations and modeling. It would deepen learning and, if the curriculum is well-structured, provide students the opportunity to learn computational thinking (within the context).
Integrating computational thinking in the existing curriculum has several benefits:
1. Deepen learning of the subject content: Enables active learning and knowledge construction
2. Learn programming concepts in the context: This is especially beneficial for students who have no prior programming experiences.
3. Not increase additional workload: Computational thinking (or as DiSessa puts it: "computational literacy") is a literacy skill like reading and writing. Here, we are proposing to use computers as a tool to think with.
This requires a lot of effort including providing professional development for teachers, restructuring curriculum, and supporting stakeholders through flexible implementation opportunities.
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.
I think you are missing what Papers writing is about (or maybe I am misunderstanding you)
Sure it depends on age I never said it wouldn't. Just like they need to be able to handle an instrument to learn to play it children of course needs to be able to have some basic skills to do programming.
Papers writing isn't about infants learning to program it's not even about toddlers. It's about children in school and how they can use programming as a tool for creating, tinkering and thinking by using the computer as a simulator to simulate things that they internalized (like playing ball, running down hill, throwing stones).
It's not about creating production ready code.
My oldest son who is now 7 has been doing something called number stories in math for some years it's not far from computer program construction. Last year he did some basic programming in the way of number solving.
I simply don't understand this weird obsession with keeping kids from being exposed to programming I don't see what it's based on.
I don't think we are disagreeing. I was referencing pure text-based programming. I think if you extend programming to being things like specialized puzzles, etc. it is applicable to a much wider group of people and ages.
> At my age I can barely read the article's thin, small, low-contrast font
I am 28 years old and find it hard to read as well. People who choose small font sizes and low contrast degrade usability a lot. Here is an article about the numerous failure modes of low-contrast designs: https://www.nngroup.com/articles/low-contrast/
Well when I was 13 I was creating video games and faux operating systems in Turbo Pascal. And I was also drawing and building model planes and thinking about how to best get girls' phone numbers on IRC then never dare call them.
It's not about not having computers, it's about how you use them.
I totally agree with this. Schools should train our kids for real life, slowly and gradually. It much more important how tools are used than what tools are used for training purposes. Later when they specialise then what tools are used will matter.
Perhaps it's time for another occasional comment about the hacky utility of bookmarklets. When I'm on the computer, as opposed to mobile device, I still use a few to compensate for such things.
The following site's been around "forever", and still provides a quick starting point. Note that web design has changed a lot; nonetheless, some of these still beat the majority of pages into a better appearance.
Yeah, I should be all "Read-a-page-ability-in-your-pocket" in my approach, and use some optimized, cloudified, designified nirvana.
Instead, I just leave some bookmarklets parked in my bookmarks bar, one click away.
That link doesn't actually work that way. It just redirects to the site. If you're in Firefox, Safari, or Edge, they already have Readability modes. It's a little book icon at the end of the address bar.
Distraction is the right word. Focus on harder to measure notions of systematic, analytic or creative thinking are happily exchanged for measurable educational innovations like iPads. If there are two schools: one where they use iPads and another where they build some weird touch device from technological scrap parts - which school would you rather send your child to?
That's too easy. Think of a game like Civilization. Granted, it's limited what you can learn from reading the in-game Civopedia, but probably thousands of kids have more awareness and interest in the historical progression of human civilization from playing that game.
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 think you're right. I didn't mean to make the implication that the problem was electrical vs paper. I eventually did get old enough to go to the hardware store to buy bell wire, knife switches and bulbs for my early experiments. I wish my kids had grow up more interested in building things. I feel like I failed in this.
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.
If you find this essay compelling, you might be interested in the game I'm working on, Codemancer ( http://codemancergame.com/ ). A game that teaches programming, with a compelling story about a girl on a journey to rescue her Father. Coming this Fall to Mac, PC and Tablets.
I tried to hew closely to the principles of Constructionism which were pioneered by Papert, and to make the game accessible to kids who wouldn't normally be interested in programming.
Love the look. And female protagonist is a huge plus - I've two daughters and it amazes me just how much they really want female characters. As a boy I didn't care but perhaps I was unusual.
My first question is how will this teach the use of variables and conditional logic? My daughter has been playing around with programming using Scratch and things like that. But she is stuck with just linear "programs", basically just creating animated stories.
There's other games that seem to have the same mechanics as yours: get the robot from A to B by entering sequential instructions. How do you differentiate? (I mean this as a positive question not a bad criticism.)
I've tried sitting down with her and doing some basics of functions, but it doesn't seem to go over well (she's 10). She _did_ love DragonBox, the algebra-instruction game. Even at 6 she was able to "solve for x" for simple equations. So I think it's possible to sneak stuff in, somehow.
Yes, I find that to be the case more often than not: boys don't care about the gender of their avatar. Girls do.
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."
Wow, this looks great! My older 9 and 8 year-old girls will love this. I agree with the comments below about variables and conditional logic, which might be tough for kids in the 3-4th grade range. Anyway, good luck. Looking forward to the release.
Preface: I'm going to use a really loose definition of AI here for a minute, which includes any computer agent that makes decisions a human might make. So, your alarm clock is an AI, the code that rejects your credit application is an AI, but the code that decides how exactly to paint this letter C is not. Now on to my comment:
I think children should learn to think about programs at a young age, because understanding AIs will be equally as important as understanding other humans in the coming century.
We will see more and more interaction with AIs who have powerful capabilities beyond what most humans can do. We will start to see AIs with emotional palettes and developmental trajectories that will allow them to integrate with us socially. But also, the little AIs like the alarm clock and the credit check are already more and more common gating structures in peoples' lives.
As long as the majority doesn't think about programs too much, you can ignore them too. But as more and more people program, like reading it will become more and more of a disability not to. Being able to think "natively" in software is going to be important. Not mandatory, but important.
Why isn't that employment AI you met finding any construction jobs for you? Does the physician AI really understand the probability that your Dad is NOT, zero probability, going to cut back his saturated fat? Your gardening AI (which is crossed with several other AIs that help you manage your household) says to plant corn, but your neighbors haven't yet, does it know something they don't?
If you can read code, those are questions you can ask.
I think you are severely underestimating difficulty of understanding non-trivial code. Even good programmers would need days if not weeks to understand how software like card processing AI works. And even when you understand the code behind it the AI like deep networks produce models that cannot tell to a human "how" it works.
So when a person uses a software component for real-life purposes I don't think there's a difference between someone who knows how to code and someone who doesn't - it's a black box.
> Even good programmers would need days if not weeks to understand how software like card processing AI works
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.
So far there were multiple approaches that looked something like what you described: component programming, visual programming, "4GL" languages. Heck, even Steve Jobs wanted to sell software components. But these things failed. "Coding" won.
Nothing I described is "not coding". I described using a subset of existing language constructs for certain parts of a codebase, and structuring some interfaces in a certain way.
I certainly didn't say anything about visual programming.
4GL... I think you meant something else there? Ruby and PHP are 4th generation languages and are obviously doing quite well.
As for component programming... I think that's the closest historical precedent for what I'm describing so I'll go deeper there...
Unlike "component people", I don't think there is any single interface for high level domain-specific libraries. Every domain will be different. Objects are certainly not a panacea. And I have no illusions that domain-specific libraries would ever be automatically compatible with one another. I have no illusions of some universe of easily integrated components. I'm just talking about an isolated, high-level API on top of a single, internally consistent codebase.
A simple example, instead of a repo with a bunch of configuration data and a "start" command, build a service as a library without any deployment specifics, and then have a separate repo that has a simple script that uses that library to set up a specific instance.
Or, build a site as a library without any content, and then have a separate repo that just binds in the content to the app, so that anyone could play around with the content without having to dig through the implementation details, and with a smaller chance of breaking something.
It's just about separating the part of the codebase that vaguely makes sense to non-engineers from the part of the codebase that makes zero sense. I'm not talking about any kind of radical technological shift.
> A simple example, instead of a repo with a bunch of configuration data and a "start" command, build a service as a library without any deployment specifics, and then have a separate repo that has a simple script that uses that library to set up a specific instance.
If the service does something useful then it must use things like databases and external APIs. So you need interfaces to abstract them - and they will be big and complex. It looks like you end with the "component problem"?
> Being able to think "natively" in software is going to be important.
We should not be working to prepare the people of tomorrow for solving the problems of today. When AI will be able to program as well as a common dev, then people will only need to guide it instead of doing the work by hand. People need to learn to work with AI, and current generations are very involved with its incarnations - AI game bots, web search, feed ranking, filtering, recommendations, auto-translation, voice commands, etc.
Current day aeronautical engineers 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. Similarly, in the future people will only need to function in relation to the AI of the day. Some aspects of how we used to do things will be lost, other will be gained. It will be a brave new world.
> When AI will be able to program as well as a common dev
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.
Ehh... Projecting how things will go in the "coming century" is in my view a silly endeavour. Modelling current policy based on those projections even more so. I say wait to see how this whole AI thing pans out before starting to teach kids about some hypothetical form of AI.
I used to play a lot with Lego when I was young, and programming is not much different from that.
Given a simple manual and a set of basic pieces you learn on your own the basics, and then move to higher order constructions by experimentation. I bet you can just give a child a basic black and white terminal and a "refined documentation", and they'll be okay just as much. Just remove everything unnecessary and sandbox the whole thing (you should expect the kids to break it to install games at some point, but that's okay).
... segue to the wonderful LEGO Mindstorms, named after Papert's book, which had a graphical programming language very similar to Squeak, which itself goes back to Kay's dynabook, influenced by Papert.
OT, but I'm very grateful to Mindstorms, it took me to the next level when I was a teen, from QBasic to C. Not because of its visual block language, which I hated as I could already code, but because I found out about a thing called NQC (Not Quite C).
NQC was a hobbled dialect of C that you could use instead of the LEGO's visual language to program the RCX (the main computer brick with batteries in it). I'd never tried C before, and it was a revelation.
And it unlocked wondrous hacks, like using the IrDA transceiver on the RCX as a psuedo-lidar so that your robot could stop short of walls, it could even estimate distance. At the time, it was so cool to me. From playing with my stumbling robot trying not to hit obstacles I got interested in Rodney Brooks and subsumption architectures. So it just inflamed my passions in AI and programming at a critical part of my adolescence.
Ironic, though, that a Papert-inspired graphical language was the antagonist in this story. The breakthrough came from wanting to scale the walls of the little garden LEGO had built.
> And it unlocked wondrous hacks, like using the IrDA transceiver on the RCX as a psuedo-lidar so that your robot could stop short of walls, it could even estimate distance.
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.
Cool hack. So you had to do multiple laps? It's interesting that dead reckoning actually worked, we had lacquered wooden floor in my house and the slip was quite bad, dead reckoning never worked.
We were allowed to do multiple laps. I stopped attending the (non-mandatory) course after I saw that the other teams were no challenge and some even had problems to just follow a line.
Reminds me of a hack we used in the First Lego League. One of the challenges was to unlock a gate, and we ran out of time for designing the necessary hardware/software. Instead, we just had a program that drove full speed in a set direction. About 1/10 times, it'd hit the gate just right and open it.
To write good programs that provide any useful functionality often a solid understanding of architecture and Mathematics is required. These skills are better understood in my opinion without focusing on software development as the end goal. A child is likely to be self motivated to write software if they have these skills and, most importantly, a desire to do so.
To write good programs that provide any useful functionality often a solid understanding of architecture and Mathematics is required.
Excuse me? Mathematics? I don't recall much of my K-12 math knowledge coming to play. You need to understand architecture to write simple programs that do useful things?
At risk of sounding like a passive-aggressive dickhead, is that what you think mathematics is?
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.
Also, the way you describe mathematics can sometimes look like contemporary art (here, I think to Fluxus for example).
For me saying programming is tied to maths mostly is not a good thing: you'll be a better programmer if you studied linguistics, art, sociology and gender studies around your math classes.
Historically, programing has mostly been teached to science students but as we are currently talking about it, it will change maybe.
I can't speak to your K-12 math education, but I used mine all the time.
* 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);
with
other_func(func())
And even more directly I was function composition (f(x), g(x), f(g(x)), f o g, etc) directly at least a couple times.
* 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
Oh, thats a lot of data. I can need to filter more, I don't want all these lines about session validation. I guess I could make a regex. Or I could just factor that into a `grep thing|grep -v session`. Ill do that, its equivalent.
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 think algebra actually hurts learning of programming, at least of the BASIC/FORTRAN/C style syntax. Programming variables don't work like algebra variables. I learned programming before algebra and had no problem with statements like "X=X+1". My brother on the other hand learned algebra before learning programming and a statement like that made no sense to him (what, 0 = 1?). Of course this was because in BASIC (as in many other languages) "=" is used both for assignment and comparison.
Programming and math could be learned together. Granted, math is not the only point of programming, but computation is actually how a lot of math is done. Also, within the confines of math, a program that does something useful (i.e., interesting) doesn't have to be a full-blown app with a GUI, so the programs can start out being much simpler. If the kids didn't become programmers, but came out more likely to use math in their lives, I'd still count it as a success.
I strongly disagree that there is any overall prerequisite relationship between the two fields. If you want to be a good writer, it's important to understand grammar, but telling children that they are not allowed to write at all until they've mastered a course in grammar is incredibly counterintuitive.
Learning needs to be holistic; you fill the gaps as you go.
Mathematical concepts are usually pretty intuitive. I think that the problem is more the notation that we teach than math itself being unintuitive and difficult.
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".
If all you're writing are CRUD apps then maybe you won't need it, but try doing graphics programming without mathematics. Which will be most interesting for children?
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.
To provide useful functionality in the end, you need a set of requirements produced by someone who understands the big picture: how the intended program fits into the world and solves a problem.
"Learning from Seymour Papert" - MIT Media Lab
Published on Aug 1, 2016
A panel from the Spring 2014 Member Event. Panelists: Mitch Resnick, Marvin Minsky, Alan Kay, and Nicholas Negroponte.
https://www.youtube.com/watch?v=Pvgef9ABDUc
I think children should program, and I think they should do it as early as possible. It's a form of mental calisthenics that when coupled with the right parent/mentor will prove invaluable in development and beyond.
In the same way that child gymnasts(or insert appropriate example) get the benefits of developing physical strength and range of motion I think child programmers can reap mental benefits.
I think most education is focused on data accumulation as opposed versatility. Usually, it is when you get to some level of advanced education that it starts to teach you how to think. I think that is backwards, but perhaps a different conversation. For example, my lawyer friends are quite proud that their law degree "taught them how to think."
What I find most exhilarating (yes, exhilarating) about programming is the problem solving aspect, which forces you to think differently. Finding comfort in patterns has a certain pleasantness to it, however, my experience is that you will eventually run in to situations that challenge your experience and expectations. For me, that's not just a benefit of programming, but a metaphor for life.
The more modes of thinking, or perspectives you possess the better you understand yourself, how you think, your strengths and weaknesses. Then you can hack yourself to improve or leverage each.
His conclusion, to "not try to make programmers out of kids, but rather enable kids to be makers", seems like the right idea. "Hacky coding", which would be an accurate description for the programming I've done outside of front-end dev, is comparable to "making". Making is more about creativity and trying than syntax and optimization.
It's not about encouraging mediocrity; it's about saying there's nothing wrong with failing.
This is a bit of a tangent, but you guys seem like the right crowd. Logo has been on my mind the past few days, as I'm rapidly approaching my 20th "codeversary" (ie. 20 years since my very first programming lesson, in what I believe was Berkeley Logo). To mark the occasion, I've been trying to figure out what a Logo tribute tattoo might look like - the "turtle" is the obvious thing that comes to mind, but in the version of Logo I learned on, the "turtle" was just a triangle. I'm trying to come up with an image that's aesthetically pleasing, doesn't actually include any code, and is recognizable as Logo. So maybe the "turtle" drawing something, but what? (No idea whether I'll actually muster the courage to get this inked on my body, but it's a fun thought exercise either way.) Any ideas?
Thanks! Or a turtle being drawn by a turtle being drawn by a turtle... turtles all the way down! ^_^
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!
Reminds me of a Sierpinski triangle[1]. Can you have a turtle infilled with the Sierpinski pattern, or maybe a Sierpinski triangle being drawn by a turtle?
Also, you could get a tattoo with something like:
to e :s :l
if :l>0[repeat 3[e :s/2 :l-1 fd :s rt 120]]
end
e 99 5
Which is Logo code to draw a Sierpinski triangle (main credit [2], you can demo at [3]).
If you liked this essay (which I did), you are probably going to be interested in Audrey Watters's Hack Education blog. [0]
In particular there is a big difference between the kinds of Papert-inspired computatiinal environments that provide microworlds for learning and a lot of what is being produced today (which Watters rightly calls out as a rediscovery of Skinner behaviorism and teaching machines). She has a lot of content and a couple of essay collections.
Thoughtful and clearly written. I also have a six-year-old daughter and many of the same concerns.
Even as a shameless Alan Kay fanboy, I'd managed to miss his 2007 TED talk until last night. It includes a kind of front-to-back demo of how they were using computers (and other means) to teach six-year-olds at that time, which I haven't seen in his longer talks for technical audiences.
they shouldn't. They will be subjected to a relentless digital world from age 10 onwards, and before that, they should at least be given the chance to fully bathe themselves in our intrinsically analogue reality, with all its subtle, unabstracted, and beautiful detail.
I think programming is for adults. Programming abstractions we use and ways of thinking are tailored to an adult's brain. I think that "programming" environments for children are SOMETHING DIFFERENT than real-world's programming. I don't see how what you learn in the former translates to the latter.
I remember actually not liking programming when introduced in a school. They didn't teach abstractions like functions, data types but rather long, math-oriented series of instructions which needed visualizing in a notebook to understand (I think environments like MIT's Scratch are something similar). I only started to love programming when I saw it consists mainly of things like functions, objects, different data types. But this kind of things is probably too abstract for a kid to understand.
> And when I watch her friends using the tablet in kindergarten, I see educational apps that introduces numbers, letters and simple logic. But couldn’t those subjects have been taught just as well without a computer?
Of course they could, but corporations couldn't earn millions in this case.
I think schools should teach only functional programming, because it's much more challenging and better suits the purpose of educating the students.
When it comes to FP, I suggest Haskell without second thought, because it's pure and forces children to think functionally. Haskell's clean syntax also makes it easier for children to read and write code.
On a side note, Haskell also resembles much of mathematical notations kids learn in school anyway, more so than any other language (guards, functions, etc.) Teaching it would not only help kids with programming, but also would serve as a tool to implement math lessons on a computer.
Contrast this with the tinkering view that students should be given devices that do things. Often described in very imperative languages. It is not shocking that many actually find imperative easier to get things done in.
This is not to say that I think functional is bad. But blind advocacy that ignores how you got to the spot you are is not helpful in getting others to the same spot.
Certainly imperative-style also has its own advantages, and I'm not saying FP is better or anything.
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.
Why not both? Progress is usually the important part. Offering both is expensive; but going all in on a single approach is dangerous in the failure case.
Teaching both would work for older kids, but a lot of Papert's work suggests that most kids under 12 haven't yet developed enough capability for abstract thought to use explicitly mathematical concepts to model the world, so teaching FP style at that point is just going to lead to frustration.
If you're going to teach kids at younger ages, you need to introduce it in a way that they can relate to physically, which is why Logo makes the turtle central; it has a heading and position just like a child's body, and it moves in a similar way to the way you think about moving yourself.
Anyway, you should read Mindstorms if you're interested in this topic; it does a great job explaining why the Logo approach is specifically grounded in a thorough understanding of childhood cognitive development.
I have the benefit of experiencing life before the impact of computers on society. Heck, my parents wouldn't even let me get toys that required batteries (too expensive to replace). So, I played with toy trucks and I read and I climbed trees and I drew. I drew pictures of locks, of circuits, of mazes, of buildings.
My own children grew up very differently. Playing video games, and their schools insisted on early introduction of laptops, convertible laptop/tablets, and iPads. At an age where I would be drawing complicated diagrams of electrical relays to play tick-tack-toe (which, because I was just a 13 year old kid with no training would have never worked) they played XBox.
I tried to get the schools to use paper and pencil for math lessons instead of iPads, but the forces at work in school systems end up encouraging many distracting technologies being introduced with no discernible benefit.
Furthermore, the development of abstract thinking, necessary for programming, happens over time in children. Is there any evidence that early programming instruction hastens it's development? Real research in education seems pretty weak.