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.
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
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.
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.