Question: Looking back to your days at Xerox PARC, and from from your current vantage point at Apple, what do you find most surprising about the way technology is being used in the classroom?
Kay: I think the thing that surprised me is that computers are treated much more like toasters, with predefined functions mainly having to do with word processing and spreadsheets or running packaged software, and less as a material to be shaped by students and teachers.
Question: What's the matter with predefined functions?
Kay: Put a prosthetic on a healthy limb and it withers. Using the logic of current day education, we could say that since students are going to be drivers as adults, at age two we should put them in a little motorized vehicle and they will just stay there and learn how to be much better drivers. Now, we would think that was pretty horrible. But what if we gave the same person a bike? We're not going to feel so badly because the bike allows that person to go flat out with his body and it amplifies that. The bike is one of the great force amplifiers of all time because it doesn't detract from us--it takes everything we've got and amplifies it. Most computers today are sold like cars, where as many things as possible are done for you. You don't have to understand how it works and, in fact, you don't have to understand how to think because the most popular stuff is prepackaged solutions for this and that. When you put a person into a car, their muscles wither. You put a person into an information car, and their thinking ability withers. I wouldn't put a person within 15 yards of a computer unless I was absolutely sure that it was a kind of a bike for them.
Question: What would make a computer a kind of bike?
Kay: Well, it's complicated. When we start asking questions about how students are thinking and what they're doing, we have to realize that--and this is sort of an extreme generalization, but it's not a bad one--most things that need to be done with students are not particularly user friendly. They require work on the student's part. Like when they're learning to ride a bike, it's not easy. Think how many students might reject a bike today if it were a new product because it's hard to learn. Today, computer systems are rejected unless they're easy to learn. But with young students, it's absolutely important to challenge their internals--challenge their internal musculature, their internal ability to make images, their internal ability to think about things and to make representations of things.
Question: How do educators ensure that happens with computers?
Kay: They have to learn how to ask extremely hard questions about whether there's any content there. A lot of technology is just what I call inverse vandalism, which is people making machinery just because they can. When educating, the first thing you need is ideas that you want to have the student learn. There has to be some resetting of what content actually is. If you have the ideas, you can do a lot without machinery. Once you have those ideas, the machinery starts working for you. Paradoxically, the most profound ideas I know about computers are easily done on an Apple II. Most ideas you can do pretty darn well with a stick in the sand.
the actual "Dynabook" idea came a few months later in the Fall of 1968 after I had visited Seymour Papert and Cynthia Solomon's first LOGO classrooms. This changed my view of computers and personal computers from just "vehicles" and "tools" to "meta-media" and "for children in important ways also".
In other words, what got added to the simple idea was "cosmic purpose", "service", "curricula", etc. The big hit from Papert and Solomon was that careful use and design of interactive computing could make a qualitative difference in the higher-level shaping of children's thinking — not just learning important things earlier, but in taking on a much more powerful "epistemological stance" towards the world they were growing up in — to the point where they should be able to think much better than most adults do today (not a big feat, but desperately needed), and be stronger shapers of the future (really desperately needed).
Most of the college students that NSF and I talked to had "learned science" - as isolated cases, stories that would be retrieved to deal with a similar situation, not as a system of inter related arguments about what we think we know and how well we think we know it. (...) Claude Levi-Strauss and Seymour Papert have called this incremental isolated "natural" learning "bricolage" - which means making something by "tinkering around." This is one of the reasons that engineering predates science by thousands of years; some constructions can be accomplished gradually by trial and error without needing any grand explanations for why things work.
— Powerful Ideas Need Love Too! - Alan Kay
make tools (for learning, not for thought exactly), publish them, observe their use, distill insights, share
— Robert Cobb
- Understanding Through Building makes the most sense long term, if it impacts the next thing that will be built
In Mindstorms I made the claim that children can learn to program and that learning to program can affect the way they learn everything else. I had in mind something like the process of re-empowerment of probability: the ability to program would allow a student to learn and use powerful forms of probabilistic ideas. It did not occur to me that anyone could possibly take my statement to mean that learning to program would in itself have consequences for how children learn and think
— Seymour Papert - What’s the big idea? Toward a pedagogy of idea power
Consider the typical trajectory of Emacs power users. They start by downloading Emacs, and learning enough of it for their editing needs. At some point, they want to do some basic customization. Then some less basic customization, which is likely to be the first contact with Emacs Lisp, even if it's only a copy-paste of a small function found on the Emacs Stack Exchange. With the confidence gained from such minor tweaking, they move on to more ambitious tasks. Some end up developing and maintaining major Emacs Lisp packages, but most don't, and that's perfectly fine.
many children are held back in their learning because they have a model of learning in which you have either "got it" or "got it wrong." But when you learn to program a computer you almost never get it right the first time. Learning to be a master programmer is learning to become highly skilled at isolating and correcting "bugs," the parts that keep the program from working. The question to ask about the program is not whether it is right or wrong° but if it is fixable. If this way of looking at intellectual products were generalized to how the larger culture thinks about knowledge and its acquisition, we all might be less intimidated by our fears of "being wrong."
— Seymour Papert - Mindstorms
I think it is a platitude that learning to code gives you agency over computers and lets you solve problems in your life, and it's not actually that true
— Omar Rizwan - https://twitter.com/rsnous/status/1269736402578632704
Visibility is everything. In many cases the most effective person isn't the smartest or even the most qualified, it's the person who has visibility into the problem. Learning to make things visible gives you a superpower.
The one thing I do try to follow is to go on streaks of reading a lot of books on a particular topic around the same time. Doing this is useful because it means I don't have to just trust one author's perspective on a particular topic - and helps me connect a lot of facts together, so I can understand things better.
On Processing side, we started with introduction to programming, explored functions, and later classes. Once we got good foundation for how objects work, we used Minim for making sounds, OpenCV for interacting with camera, and even some Machine Learning with Wekinator.
This project was simpler than January's SDF-UI, and took 6 hours less to make (totaling in almost 24 hours of development time). There was a lot to figure out, and I ended up learning about webworkers, and implementing my first evolutionary algorithm after I finished college.
I enjoyed this month's exploration and learning a new language as nice break from tool-making research.
The program was divided into week long workshops: body interactions, no screens allowed and city data. Each week was 2-3 days of heads down — learning technology and programming, and then 1-2 days of student projects. Each of the groups had one week of P5 and Arduino introduction, so they had some basic knowledge of programming.
Learning Haskell was one of my one-project-a-month projects in 2017. I can't say I'm anywhere near fluent in the language, but it's been an interesting journey, and I've learned a lot of new concepts.
Next time, I would probably aim for either fully research/learning related residency, or one where I know almost everything, and produce artwork. I've tried to combine both, and ended up only building the tools, without ever actually making anything bigger with them.
I'd definitely want to go for another residency. As usual, working on one thing brings up ten new ideas, and my notebook is only getting bigger. There's something really nice about being able to set aside everything, and allow myself to work around the clock while exploring and learning.
First week was full of learning in the most frustrating way — trying and failing over and over again. I still didn't know what exactly I wanted to do, and was exploring different techniques. I finally settled on using SDFs (signed distance fields) after short research on meshing isosurfaces.