This Looks Wonky

Seymour Papert passed away yesterday. I have written about him in the past. I am not a scholar of Papert, so I do not have anything profound to say. Audrey Watters, however, posted a great series of tweets last night. Here is what she had to say about Papert, his influence on her and education, and what we can do to help his legacy live on.

A few thoughts about Seymour:

— Audrey Watters (@audreywatters) August 2, 2016

1st time I ever read anything by Seymour Papert was in a Women’s Studies class (“Epistemological Pluralism,” co-written with @STurkle)

— Audrey Watters (@audreywatters) August 2, 2016

Epistemological Pluralism and the Revaluation of the Concrete by Sherry Turkle and Seymour Papert https://t.co/ZvLABuqCHF

— Audrey Watters (@audreywatters) August 2, 2016

I'd be quite proud to say that that was my first exposure to Papert -- thru feminist epistemology — and not thru “ed-tech” or “tech”

— Audrey Watters (@audreywatters) August 2, 2016

if I didn't realize later that I'd been exposed to LOGO as a kid in the 80s pic.twitter.com/rMrlKzveZF

— Audrey Watters (@audreywatters) August 2, 2016

For those who care about the history of ed-tech, here are a few of the stories I've written that touch in his influence:

— Audrey Watters (@audreywatters) August 2, 2016

(25 Years Ago) The First School One-to-One Laptop Program https://t.co/Xz0SXRo3as

— Audrey Watters (@audreywatters) August 2, 2016

From Lunchboxes to Laptops: How Maine Went One-to-One https://t.co/k1vecO0Niq

— Audrey Watters (@audreywatters) August 2, 2016

Lego Mindstorms: A History of Educational Robots https://t.co/JKaI7AbFGg

— Audrey Watters (@audreywatters) August 2, 2016

That barely scratches the surface —> https://t.co/1jSlm8irpb

— Audrey Watters (@audreywatters) August 2, 2016

Me, I'm thankful that I got to spend time with Seymour, even though it was after his accident pic.twitter.com/OlmCBFrfW1

— Audrey Watters (@audreywatters) August 2, 2016

1st time I met him, we talked about Skinner and self-driving cars https://t.co/11xkwA4jcZ

— Audrey Watters (@audreywatters) August 2, 2016

Last time I saw him, I told him was prepping for my first trip to South Africa. He said he’d take me to Jo’burg <3 <3

— Audrey Watters (@audreywatters) August 2, 2016

I am so grateful for everything Seymour gave us. A vision in which students are the subjects not the objects of learning, of tech

— Audrey Watters (@audreywatters) August 2, 2016

Technologists: please read Mindstorms. Teachers: please read The Children’s Machine. Then swap copies

— Audrey Watters (@audreywatters) August 2, 2016

Many things hurt tonight. My heart can’t take much more of 2016. But know this:

— Audrey Watters (@audreywatters) August 2, 2016

I'm watching those who want to grab on to Seymour’s legacy - control, re-tell, reframe - as we fight forward, associate their BS w his name

— Audrey Watters (@audreywatters) August 2, 2016

I am watching. I am fighting. I am questioning. As Seymour would want of all of us

— Audrey Watters (@audreywatters) August 2, 2016

End. Pen up

Pyret is a programming language for beginners. In many ways, Pyret shares the same goals as Racket. More specifically, Pyret shares a similar look and feel (in terms of development environment) to WeScheme. Bootstrap World, the team behind WeScheme, is adopting Pyret as the language for their Bootstrap II curriculum. Since I am such a fan of Bootstrap World and hope to use their curriculum this upcoming school year, I thought I would look into Pyret.

I began programming in earnest yesterday. I decided to make a tool that graphs a user generated function. I finished the tool yesterday evening. Today, I was able to turn the tool into a module that anybody could import and use. It is a simple tool; one that required far less work than I anticipated. The hardest part is wrapping my head around functional programming concepts like map and fold. The mailing list was fast and friendly. I could not have done this without their help.

So if you are interested, here is a sample program. All a user needs to do is copy the “import” statement at the top and the “P.make-graph” statement at the bottom. The user then writes the function they want to graph, and then pass that function to the “P.make-graph” function. If you want to see the code that creates the graph, click here. It is not a perfect tool. For instance, graphing the square root of X throws an error message because it will use negative numbers. The graph is also comprised of dots not lines, so some graphs are not as easy to read as others. Finally, (though I am sure there are other areas that need improvement) only the numbers from -50 to 50 (using 0.1 increments) are used as the domain of the function graphed.

I have written a few times about Swift Playgrounds, but today I finally installed iOS 10 beta to get access to Swift Playgrounds and try it for myself. Over the next few days I will be sharing some short posts with some thoughts on the coding environment.

Playgrounds does not come with any lessons installed. The beginner and intermediate lessons are offered to the user. You can also start a new project with a template, or start with a blank document. I like how this isn’t just about lessons. Users are given the opportunity to experiment on their own.

Like other begin-to-code programs, users start off with some computational thinking puzzles. Playgrounds gives users a block-like experience (pre-made code the user taps on to add to their program). This is good because it reduces the amount of syntactical errors. This would also fulfill (though there are some who may take objection to this) the CSTA coding standard of using a block-based language. Never underestimate the power of preexisting curriculum; if Playgrounds required you to type all code there may be people who don’t use it because it does not fulfill the aforementioned standard. Swift is not a block-based language, and the goal of Playgrounds is to give Swift an easy learning curve (tapping on commands instead of typing them, like dragging blocks) but to quickly foster a transition to typing the language.

Users are introduced to debugging in the fifth lesson. Functions are taught in the second unit (eighth lesson overall). Unlike some other popular coding environments, Swift Playgrounds wants to move beyond just computational thinking. This addresses some concerns engineers have when looking at coding curriculum. I like the speed at which Playgrounds gets into more depth.

Swift Playgrounds is a beta, and there are some moments that remind me of this. There can be a lag or a stutter when entering in commands by tapping on the pre-made blocks of code. The main character Byte is slow to restart the instructions when you made a mistake in your commands.

A quick note before I begin: if you are interested in Playgrounds as an educational tool, get yourself a copy of the Swift Playgrounds Teacher Guide.

There is not much you can say about a piece of software that does not yet exist for public consumption. I eagerly await the release of Swift Playgrounds. Apple lists several interesting features of the program, and while it is tempting to compare Playgrounds with other products currently on the market this would be foolish. Nobody has enough information to definitively critique or praise Playgrounds. That being said, I will praise Apple in this post, and in subsequent posts I will take a more critical look at Playgrounds. I will try to be measured in both, but my excitement is compelling me to put some of my thoughts on this site.

Apple's recent marketing campaigns are top notch. They are so compelling not because Apple’s technology is so much better than everybody else. Rather, Apple sells us the experience of using their products and services, and they are doing a hell of a job. Sure, you can find fault here and there. The “Onions” ad just does not touch me the way their ads around the holidays do. Does Apple really need to serve those massive images from their website? It seems like a waste data for mobile users, and it could slow down a user’s browsing experience if their connection is bad.  In the end, these are all  minor things at best.

As an educator, however, I am much more cautious about how learning tools are marketed. Educational technology is prone to an abundance of passing off buzz words and catch phrases as a solid pedagogical foundation. Since moving to Silicon Valley, I have researched companies who offer little substance and a lot of fluff. They expect to be paid handsomely as well. Wrapt that up in some technological determinism, and some schools feel pressure to adopt more technology. After all, if the schools do not introduce more technology (specifically coding), then the technology will leave the students behind. So you have some schools eagerly looking for more coding, but who lack the understanding of what to do or how to do it. To be fair, my cynical take on Silicon Valley education technology culture is a caricature. I have met startups who, I think, are more serious about the substance they offer. More over, all of these people have their hearts in the right place; they want to provide a better education for students.

When I looked over the Playgrounds’ website, it is surprisingly devoid of those pesky buzz words I loathe. Apple, true to form, is selling the experience. The heartwarming video they showed at WWDC makes you feel the power of teaching people to code. There lies, however, a large gap between the lofty language of a marketing campaign and actual learning. Again, I have to reiterate that nobody can answer if Playgrounds bridges that divide. Apple quietly released the Swift Playgrounds Teacher Guide. Much like Playgrounds, the book is not yet finished; it is just a preview. The guide, however, gives a pretty good idea as to how Apple sees Playgrounds being used. Here is an overview of how each lesson is structured:

Introduction - Overview of the lesson and how it relates to an everyday situation

Activity - This expands on the aforementioned discussion

Practice - Students apply their coding skills

Reflection - Suggested questions and prompts to help students reaffirm what that learned

Journal - Portfolio of student work and their reflections

Rubric & Gradebook - Tools to help teachers assess their students

So, I have been meaning to get something some ideas on this site about recent news from Apple’s WWDC event. Specifically, the Swift Playgrounds app is very interesting. Most articles summed up the announcement along these lines, “Apple made a learn-to-code app for the iPad called Swift Playgrounds. Kids learn to write Swift code while solving programming puzzles.” This s an oversimplification. I was a bit surprised to see a follow-up article the next day from The Verge. In it, they say:

But most importantly, Swift Playgrounds fits into Apple's proprietary business efforts as it has a vested interest in teaching kids to code in Swift; apps built in Swift only work on iOS devices. With Swift Playgrounds, Apple is hoping its programming language will be the gateway to coding that will encourage a new generation of App Store developers.

Locking people into its ecosystem is kind of Apple’s thing (Ehm, iMessage). "Because Swift is so easy to learn, it has the potential to bring more people into coding," Cook said. The more, the better. And what’s more enticing to young people and parents than a free app?

Yes, many of the interesting features announced at WWDC work among other Apple products and services. Vendor lock-in is nothing new, and you could make a good argument that Apple is the biggest perpetrator of vendor lock-in. The above complaint, though, seems to be more of a thoughtless, knee-jerk reaction. Apple is known to be a closed and tightly controlled ecosystem, but Swift has been a surprisingly open endeavor. After its announcement, Apple and the Swift community openly develop the language on GitHub. Moreover, Apple has big plans for the language. That means it needs to work across a variety of hardware and operating systems (still no official compiler for Windows however). From Swift’s about page:

The goal of the Swift project is to create the best available language for uses ranging from systems programming, to mobile and desktop apps, scaling up to cloud services

…

We can’t wait to see the new places we can bring Swift—together. We truly believe that this language that we love can make software safer, faster, and easier to maintain. We’d love your help to bring Swift to even more computing platforms.

It is early days for Swift, so right now all of the momentum is around Apple, its apps, and their third-party developers. If Swift evolves as Apple envisions, then it will be used for a variety of reasons on a variety of hardware and operating systems. In fact, IBM has been hosting a sandbox running atop Ubuntu GNU/Linux for some time now.

To be honest, I was never really a fan of Code.org. In fact, I would hate that week in December when all of the tech teachers I follow on Twitter would talk about Hour of Code. The work of Code.org, after all, isn’t “real” programming (it should also be noted that I am not a real programmer either). How can there be so much excitement over something that isn’t what it purports to be? I just dismissed it out of hand. It seemed like Scratch, but with a pop culture veneer (Plants vs. Zombie, Star Wars, etc.). I watched all the videos that popped up in Twitter. What do Will.I.Am, Chris Bosh, et al have to do with programming? I assumed nothing since learning is serious, and appealing to pop culture is not serious. So I just wrote Code.org off.

This year, I am working on a project with some third grade students. As kids finish up their project, I needed something they could do with little to no teacher intervention so I could help the other students. I had to work with each student individually to put the finishing touches on their project, so I did not have the time to go over some supplemental work. I chose Code.org because there have been some hints from the powers that be that there should be a greater emphasis on STEM. The only instructions that I gave to the students was that there were some videos, so be sure to wear the headphones. Off the students went. To my surprise, very few needed any type of instruction. Those that did were because they were on the last puzzle of the session. It was an open-ended, create-a-game type of a situation. I was surprised how quickly they took to the puzzles. Boy or girl, it did not matter. There was something there for seemingly everybody.

What I have learned since this project is that Code.org is not about programming per se. It is about engaging students, it is about making them think, and it is about making a computer do what the student wants. “Real” programming has nothing to do with this. Code.org is about engaging students, and showing them that they can control what computers do. The thing is, Code.org was never written for people like me. It was created for kids, and kids really like it. They like the themes. Between Frozen, Minecraft, and Star Wars there is something for everyone, and there are more theme for those looking to do more. They like the videos. My students did not seem all that excited when I pulled up the website and said I would not teach them what to do. However, when I told them to put on the headphones for the videos, they eagerly went to their computer to get started. They like the challenge. Even though the puzzles of Code.org are hard for students, not one gave up. They would ask their neighbors, they would ask me, they would ask their classroom teacher. Some students will not be so resourceful when learning becomes difficult. To my surprise, all of the students were engaged with the Code.org lessons. They were so proud when they finished a set of puzzles.

Overall, there is much to like about Ruby Wizardry. The book reads as a story rather than an instruction manual. The story is whimsical, silly, has some mystery, and above all is easy to understand. When teaching something, it does not have be boring. Often, education is looked upon as being “right” when it is rigorous, dry, and not enjoyable. If you want kids to learn, then having an enjoyable approach to the subject is a good start. Ruby Wizardry does this very well.

Ruby Wizardry has two kids act as the “heroes” of the the story. Adults like the King can be rather clueless and are in need of the kids’ programming skills. I think that students can find this more relatable, or the very least more interesting that kids are not portrayed as helpless or in need of adult supervision. Though there are adults like the Queen who have superior knowledge of Ruby than either of the kids, it is the kids who take that knowledge and put it to use to solve the mystery. While the King appears absentminded, acts as an instrument to reinforce the Ruby lessons. After leaning something new, the King says something along the lines of, “Interesting, but could you tell me again how that works.” The author then goes about teaching the same thing but in a slightly different way. There is constant little reinforcements of ideas and connections to previous topics from the book. The book is also full of little example code that you can type into IRB to see for yourself how the code works. The book even tells you what the output should be so you can always follow along. At the end of every chapter, it is time for the reader to write a Ruby file that covers the subject of the chapter. This invitation to code helps to solidify  how to write Ruby. They even offer a few suggestions on other things (bonus work) you can do with the code. This offers more of a challenge for those who pick up quickly on how to write Ruby. However, there is no provided code for this extra work. Should the reader get stuck on this extra work, they may become frustrated. The final part of the chapter is a formal review of the subject matter. 

As an aside, I like how Ruby Wizardry addresses some of the implicit biases we have. When one of the protagonists, Ruben, met a knight and a dragon, he was surprised that the knight and dragon were female. Ruben referred to them as a “lady dragon” and a “lady knight.” Both the knight and the dragon thought this was silly and responded with, “You wouldn’t say a ‘man knight’ would you?"

The story takes the reader along a journey that introduces some of the aspects of writing Ruby. Since the book is written to use a simple Ruby installation, the reader works with text. In 2015, you can make a good argument that kids will not find text manipulation to be all that engaging. Think of all of the high quality games, apps, websites, and videos that are readily available on their computer or tablet. Putting text in the console just really doesn’t compare. Ruby Wizardry is just a book, not a complete educational system. That is, Ruby Wizardry approaches Ruby as it is, not as it could be in an ideal form for beginners. Ruby is capable of manipulating the internet, images, sound, etc. However, Ruby does not come like this by default. The tradeoff of a quick and easy install for a beginner is a limited interaction with the language at first. The same critique could be levied at most popular programming languages.

I did appreciate that the final two chapters dealt with file I/O and getting a web server running on a local host. This was a nice departure from text manipulation done up until this point. As this is a book written for beginners, not much time was spent on either of the two aforementioned subjects. I would make the argument that this was an opportunity lost to really grab the attention and imagination of the reader. These areas could be a real creative outlet. The downside of this is that the book was transition from a general introduction to the language (with a story) to a more focused and difficult instruction manual (without a story). Striking a balance between an accessible introduction and instructions for a specific task is harder than it looks. I think it was wise of Ruby Wizardry to err on the side of accessible introduction.

First of all, I need to say thank you to several people before I begin. Thank you to the folks behind Big Design. I appreciate the invitation to share my ideas with others. This was my first opportunity to speak at a conference. I am not sure what you saw in me, but I am glad that you gave me this opportunity. Thank you to those who came to my talk. With all of the great options available to you, it is humbling that you chose my session. Finally, thank you to my former professor Cassini Nazir. Without his encouragement I would not have submitted an application to Big Design. He was also influential in my capstone project. I appreciate you guidance and enthusiasm in my work.

If you are at all interested in kids, computers, and learning then I would recommend reading up on Seymour Papert. In particular, pick up a copy of his book Mindstorms. As I said in my talk, the book does not read as though it were written in 1980. The fact that many of his ideas seem so novel and interesting does not speak well to how computers in education have evolved.

Bret Victor’s Learnable Programming was a foundational document to my talk.  Not only is the article worth reading, but be sure to look at the examples of what his ideas would look like. Victor’s Inventing on Principle talk is also well worth your time; this talk set the stage for Learnable Programming and Elm’s time traveling debugger. As a bonus, take a look at Victor’s The Future of Programming. It is not really related to my talk, but I think it is great all the same.

For all things Elm, check out their website. I find their mailing list to be full of polite, responsive, and helpful people. If ever you are stuck with some Elm code, take a look at the mailing list. I would have never finished my capstone project if it were not for them. Elm has a great page to try out the language. There is nothing to install, and you get the benefit of all those great error messages I mentioned.

Finally, I would like to bring Bootstrap to your attention. While my talk mostly mentioned Elm, I think Bootstrap is doing fantastic work. This is my language of choice for the year. I cannot tell you how impressed I am with what they have done. Here are some thoughts I had after attending one of their professional development sessions this summer. I would like to also mention Pyret, which aims to recreate the work of Bootstrap and Racket with a similar curriculum and metaphor but with a more Python-like syntax. It is definitely a project worth watching.