What I learned from taking a MOOC: Live Object Programming in Pharo

I wrote this post a month ago, before COVID-19 changed how a great many of us teach in higher education. It feels so long ago now. I thought about writing a different post for this week, one about how I’m managing my large (260+) Senior-level User Interface Development class with projects. But I realize — I have a ton of those kinds of posts in my to-read queue now. We’re all being bombarded with advice on how to take our classes on-line. I can’t read it all. I’m sure that you can’t either.

So instead, I decided to move this post up in the queue. It’s about taking the students’ perspective. I worry about what’s going to happen to students as we all move into on-line modes. I wrote my Blog@CACM post this week about how the lowest-performing students are the ones who will be most hurt by the move to on-line — you can find that post here. This is a related story: What I learned about MOOCs by taking a MOOC.

I received in February my certificate of success for the MOOC I took on Pharo. I have not, in general, been a big fan of MOOCs (among many other posts, here’s one I wrote in 2018 about MOOCs and ethics). This MOOC was perfect for what I needed and wanted. But I’m still not generally a MOOC fan.

I’m a long-time Smalltalk programmer and have written or edited a couple of books about Squeak. I’m building software again at the University of Michigan (see the task-specific programming environments I’ve posted about). Pharo is a terrific, modern Smalltalk that I’d like to use.

A MOOC on Pharo matched what I needed. I fit the demographics of a student who succeeds at a MOOC — I already know a lot about the material, and I’m looking for specific pieces of information. Pharo has a test-driven development model that is remarkable. You define your classes, then start writing tests, and then you execute them. You can then build your system from the Debugger! You get prompts like, “You’re referencing the instance variable window here, but it doesn’t exist. Shall I create it for you?” I’ve never programmed like that before, and it was great to learn all the support Pharo has for that style of programming.

Yes, it was in French. They provide versions of the videos dubbed in English, and the French version can display English captions. I preferred the latter. I had French in undergraduate, which means that I didn’t understand everything, but I understood occasional words which was enough to be able to synchronize between the video and the captions to figure out what was going on.

My favorite part of the MOOC was just watching the videos of Stéphane Ducasse programming. He’s a very expert Smalltalk programmer. It’s great seeing how he works and hearing him think aloud while he’s programming. But he’s very, very expert — there were things he did that I had to re-watch in slow motion to figure out, “Okay, how did he do that?”

The MOOC was better than just a set of videos. The exercises made sure I actually tried to think about what the videos were saying. But it’s clear that the exercises were not developed by assessment experts. There were lots of fill in the blanks like “Name the class that does X.” Who cares? I can always look that up. It’s a problem that the exercises were developed by Smalltalk experts. Some of the problems were of a form that would be simple, if you knew the right tool or the right option (e.g., “Which of the below is not a message that instances of the class Y understand?”), but I often couldn’t remember or find the right tool. Tools can fall into the experts’ blind spot. Good assessments should scaffold me in figuring out the answer (e.g., worked examples or subgoal labels).

I ran into one of the problems that MOOCs suffer — they’re really expensive to make and update. The Pharo MOOC was written for Pharo 6.0. Pharo 8.0 was just released. Not all the packages in the MOOC still work in 8.0, or there are updated versions that aren’t exactly the same as in the videos. There were things in the MOOC that I couldn’t do in modern Pharo. It’s hard and costly to keep a MOOC updated over time.

My opinions about MOOCs haven’t changed. They’re a great way for experienced people to get a bit more knowledge. That’s where the Georgia Tech OMSCS works. But I still they that they are a terrible way to help people who need initial knowledge, and they don’t help to broaden participation in computing.

Higher Ed and the Role of a Computing Culture: Interview on No Such Thing Podcast

When I visited the To Code and Beyond workshop last month (as mentioned in this podcast), I was interviewed by Marc Lesser for the No Such Thing podcast, which he just released.  (My keynote is also in his podcast series here.) It’s a wide ranging interview, from woodworking to the work I’ve started with History professors Bob Bain and Tamara Shreiner, from how I began teaching computing in 1980 to how I’ve been inspired by (to name a few) Alan Kay, Yasmin Kafai, E. Paul Goldenberg, Brian Harvey, and Bob Kozma.  Marc’s framing for the podcast is interesting (pasted below): How do we “bottle” me? In other words: How do we create more computing educators who care about CS for All, especially at the higher education level? The episode can be found here.

At the top of the last episode you learned about Mark Guzdial. Mark is a Professor in the College of Engineering at the University of Michigan. After his talk at Cornell Tech’s “To Code and Beyond” I had a chance to sit down with Mark and ask what questions had bubbled up while I listened to his talk live. Probably my most pressing question: what you’re saying is great, but we’ve all seen professors like you on youtube – Mark is a brilliant, animated, ukulele playing Computer Science professor, who, from my time with him, seems as passionate about you learning about his passion topic, as he is about the topic itself. He’s a rare mix, and what I’m sure many in the audience wondered – what the country is wondering right now – is how do we bottle some of that, and help thousands of teachers in every state offer young people the experience that surely the students in Mark’s class have each semester. For what it’s worth, out-of-state tuition at his school is $43,476 with a 26% acceptance rate. A wicked problem, indeed.

Why do so few schools try LiveCode? We let industry dictate our tools

I’m an old HyperCard programmer, so I like LiveCode.  LiveCode does very well on the five principles I suggest for picking an educational programming language. The language is highly readable, and was actually designed drawing on research on how novices best understand programming. It’s easy to put together something that looks authentic and that runs on virtually any platform — much easier than Python, Java, Scratch, Blockly, or any of the other top five most popular teaching languages. Authenticity is often engaging for students.

The LiveCode folks have just put together a web page (linked below) describing some of the reasons why teachers should consider LiveCode.  But in general, we don’t.  Why not?  I have two guesses:

1. There is no community of practice. There isn’t a visible community of teachers using LiveCode. There isn’t an obvious industry call for more LiveCode programmers.
2. We in computing education are mostly driven by surface-level interpretations of industry needs.  It isn’t obvious that it must be so, or even that it should be so.  But the same forces that killed Pascal and promoted Python, Java, and C++ as our intro languages prevent LiveCode from getting adopted.

I think LiveCode, Smalltalk, and Lisp are all excellent pedagogical programming languages, but our teaching decisions in secondary and post-secondary CS education are rarely based on what will engage students, be easier to learn, or lead to transferable knowledge.  Instead, we tend to make decisions on what obviously looks like what current professionals do.  It binds us to normative practices. We’re stuck in apprenticeship as our teaching perspective, and can’t consider social reform or developmental perspectives.

Better Exam Results, Better Real Life Outcomes, More Fun!

Over a third of Scottish schools are now teaching using LiveCode. They are doing this because they have proven results showing that using LiveCode results in more students remaining engaged, reaching good grades, and continuing in the direction of a coding career.

Source: Education | LiveCode

Introducing GP: A General Purpose Block Language

GP is a new blocks-based programming language being developed by John Maloney (most well-known for developing Scratch), Jens Mönig (developer of Snap!), and Yoshiki Ohshima (one of the developers of Squeak EToys) in Alan Kay’s group. They are all part of the new partnership between Alan Kay and Y-Combinator Research: HARC (Human Advancement Research Community). GP started in the SAP-funded CDG (Communications Design Group).

GP is not yet released, and there’s not much publicly available on it yet. The GP Team published a paper and poster in the Blocks and Beyond Workshop at last year’s VL/HCC on GP. The best introductory article on GP so-far is on the Scratch Wiki at MIT based on John’s presentation at the Scratch conference last year.

What makes GP remarkable is that it aims to be a general purpose language. John’s vision for GP is to be the language that students might move to after Scratch, with the highest possible ceilings. Think about GP as Python or Smalltalk in blocks — and even more the latter than the former. From the virtual machine (VM) on which it runs to the class browser, GP feels like a blocks-based form of Smalltalk. Because GP is VM-based, it’s portable — there are versions for Mac, Windows, iOS, and even a JavaScript implementation of the VM so that GP runs in the browser.

GP is an exploration of the question, “How far can we go with a blocks-based programming language? Do we have to move students to a textual programming language to let them develop everything from data analyses to real applications?”

GP users can do a lot with GP’s built-in blocks. However, as they grow in mastery, some users may wish to add new blocks to GP (e.g. to manipulate images), or even to extend the GP programming environment itself (e.g. by adding an image editor). GP is designed to be extended in itself using the same blocks language that users already know. However, unlike Smalltalk or Snap!, the GP language itself cannot be extended (e.g. to add a new control structure) without modifying the virtual machine. Keeping the GP language simple and fixed is intended to ease the learning path for beginners.

A brief tour of Smalltalk-like features of GP

When you first start up GP, it looks like Scratch. The blocks palette is different, because it’s covering a larger space of blocks. GP includes blocks for dealing with data (e.g., JSON, comma-separated values), media generation and manipulation, connections to the network and external devices, and the ability to create and coordinate multiple objects.

There are even blocks in there for manipulating pixels in an image and samples in a sound. GP is the first blocks-based language in which I’ve been able to do both sound and pixel Media Computation examples. I built the first version of MediaComp blocks for GP, then John figured out which ones were actually useful and then re-implemented them in GP much more efficiently than what I did.

I’m introducing GP here with the GP Team’s permission in order to show you a prototype ebook I’ve been building the last few months. You can play with GP at http://home.cc.gatech.edu/GPBlocks. This is the browser-based version which is offered with no guarantees — the browser version will likely change dramatically as GP is still being developed, and even the examples in the ebook may break over time. (Note: These browser-based examples are best viewed in Firefox on a desktop or laptop computer; they do not yet work on iOS or Android tablets.)

Here’s a brief series of snapshots to give you a sense of what makes GP so interesting and powerful compared to most other blocks-based languages. In the stage area (upper right-hand corner) right-click (control-click on a Mac) to bring up the stage menu.

The menu options for a workspace and to browse will elicit warm feelings of recognition for Smalltalk and Self programmers. Go ahead and click on the browse menu item.

Scanning the classes along the left hand side you realize that this is a full Smalltalk-like language. All the pieces are there and inspectable. The middle panes show the instance variables in the class (top) and the methods for the class (bottom). The rightmost pane shows the code for the method — in blocks!

One of the big goals of GP is that all of GP is written in GP. Even the lowest levels of GP (e.g., how bitmaps and blocks are constructed) can be manipulated in GP, all in blocks. Those methods are real code and “live.” Change them and you change how GP is working immediately. Right now, that’s super dangerous — there is no “editing” mode. Move a block out of place, and the method is changed at that moment. Beware of re-defining how Integers work! The GP team is currently working to complete this part of GP, allowing the GP programming system to be used to modify itself, like Smalltalk.

The GP team is also exploring the stages between blocks and text. At the top right hand corner of GP is a slider between blocks and text. Switch it to text, and all of GP is presented and usable in a textual form. (There’s even an interesting middle stage between blocks and text.)

I’ve been using GP for about nine months. During the Spring semester, I’ve been using GP with an undergraduate research assistant, David Tran, to build a prototype of a new kind of ebook structure. Play around (muck/MOHQ around) in the GPBlocks MOHQ, and in the next blog post, I’ll explain what it is and what we’re exploring in it.

---

My thanks to the GP team for review and comments on drafts of this post.

The best Bret Victor video yet: “We don’t know anything about computing.”

The punchline for computing education comes in the last 5 minutes, but the previous 27 minutes are well worth watching.  Bret is critiquing the same mindset I was reporting on when I said that Lisp and Smalltalk are now dead in undergraduate computer science.  “We don’t know what we’re doing” is the most important phrase for computer scientists to say to ourselves and to our students.  I enjoy the flash and style of Bret’s previous videos, but I love the message of this video. The details (with copious references) can be found on his website.

Improve Computing Education: Take the More-than-Java Pledge

I have a sure-fire way of improving computing education.  Everyone reading this, post this to your blogs and Facebook status and every other way that you make public, digital statement these days:

I promise to no longer teach Java to anyone at the undergraduate Freshman level or earlier.

I am teaching Java in my Media Computation Data Structures class this semester, the first time I’ve taught first year students in four years.  I had forgotten how bad Java is for beginning students!

My students are almost all non-CS majors.  This is all their second semester CS course, but for the most part, last semester was the first time any of them had ever programmed.  Their first course was in Python (robots), Python (MediaComp), or MATLAB.  It’s a small enough class that students actually do come to my office hours, and that lets me see the aggravating errors that they are facing.

Here’s a common error — it’s a faulty method declaration.

public void foo();  
{    
    // blah, blah blah
  }

The error you get is: missing method body, or declare abstract.  Sure, that message makes sense if you understand about semi-colons and blocks, but if you don’t…”What’s abstract?!?  I have a method body there — why doesn’t it see it?”

Here’s the one that I saw multiple times (both versions), which I find just infuriating.

while (a < 4);
{
    // do something in here, and probably change "a"
}
if (sometest());
{
   // do something if true
}

These are infuriating because there is no error — the first generates an infinite loop, and the third one just always executes the body, ignoring the result of the test.  Programs don’t work, and the compiler gives no clue that the students did something that only experts can handle correctly.

I’ve read Kernighan and Ritchie.  I know that, with magical side-effects and complex C-magic, one doesn’t actually need to have a body on loops and IF’s.  Everything can be done in the IF or WHILE test, or in the body of the overly-complex and macro-like FOR loop.  But why allow that in a language for beginners?  We’d never want to teach that to first year students, and by allowing these experts-only practices in Java, we lay land-mines for them!

I completely believe that students should learn C-based languages, and Java is a powerful tool that most CS students should learn.  But not to start.  It’s a lousy language to wrestle with when you are still trying to understand what commanding a computer is all about.  My students are trying to understand object interactions and creating dynamic data structures, and errant semi-colons are eating into all of their programming time.  Seriously — a bad semi-colon may cost a starting student 30 minutes of programming time (as Matt Jadud’s ICER 2006 paper showed).  If you can only afford two hours of programming time for an assignment, one wrong semi-colon now means you only have 90 minutes.  If you can’t complete the assignment, you never get the motivation boost of success and your grade suffers.  I really believe that semi-colon errors correlate with our retention problems.

So why do we teach Java so early?  Because it has become the language of CS education.  We have to teach Java to prepare students for what comes next.  This is particularly salient for me because, as of this semester, we no longer teach Smalltalk to students at Georgia Tech.  Lisp died from our curriculum about a dozen years ago.  Now, the required courses teach (in order): Python, Java, Java, C, Java, and options in upper-level courses between C, C++, C#, and Java.  If students want, they can take a specialty course where they might see some ML.  I don’t think GT undergraduates can even take a class where they’ll use Lisp anymore.  C has won.  This is a learning problem because I worry that students won’t develop cognitive flexibility without these other language approaches. Forget about transfer, forget about vocational training — let’s focus on being able to think about problems and representations in different ways. Here’s our goal in Rand Spiro’s words (which weren’t about programming, but fit perfectly): “Cognitive flexibility theory suggests that learners grasp the nature of complexity more readily by being presented with multiple representations of the same information in different contexts.”

The real tragedy here is that few of us can take the pledge.  I can’t take the pledge, either.  We live in an educational ecology, and none of us can act alone. If I did, then I would be doing my students a disservice — they would be unprepared for their later courses.  If high school teachers took the pledge, then they couldn’t teach AP CS, and there would be even less high school in CS.  And no, that wouldn’t be a good thing — by every study we have, students without a CS course emerge from high school with extremely ill-informed and negative views of CS, and any high school CS makes things better.  High school students with CS have a better understanding of what CS is, and are more likely to pursue later studies.

How do we get to a better place from where we are now?  We who teach CS all have to decide that there’s more to programming computers than C, that 1973 was not when humans reached their peak in ability to communicate with a computer.  We have to recognize that other forms of programming are important, even if it doesn’t get students a job.  And by teaching those other languages, perhaps we create a seed to change industry, too.  We just can’t settle for what we have now.   We have to decide to teach other kinds of programming languages (somewhere!), and to create pathways so that we don’t doom students who don’t have Java in their first year.

Here’s a pledge that I hope that all computing faculty can make:

I pledge that I will work with my colleagues so that all of our computing undergraduates will learn a programming language that is not based on C, and we will build that into a required course within the next two years.

A Humiliation, er, Teachable Moment

I’ve been taking a piece of advice from Seymour Papert over the last couple weeks (and for the next couple months).  While I was never a student at MIT nor part of any of their Logo programs, I got some time with Seymour when we were both at the all-weekend design meetings for Logo Microworlds, back when I was a graduate student.  (One of my all-time most scary and intellectually challenging dinners was sitting next to Seymour and defending my thesis to him.)  One of his in-passing pieces of advice was that education researchers should regularly learn something new, to continually be reminded of what it’s like to be a learner.

I’m “Baron Elberfeld” in our church’s production of “Sound of Music.”  My wife (“Frau Schmidt”) and daughter (“Brigitta”) are also in the production.  All of the rest of my family have been in plays, and my wife and son have been in many.  This is my first play ever.  Not even in high school was I ever even working on the set.  This is totally new for me.

One of my first observations: I don’t know the severity of my mistakes.  I’m the eager-to-please newbie, and I make mistakes.  Are they “okay” mistakes?  Did I just make a serious faux pas? I make some of each, but I can’t tell at the time.  I figure it out 5, 10, 15 minutes later, judged in terms of later response to me.

Yesterday, we were at rehearsal all day long.  Since I only have two lines and am in only one scene (but have to dance two dances, and sing the final “Goodbye” with all the other party guests), I spent much of the time yesterday trying to help out with the set.  One of the people in charge gave me a task to do, which I worked at diligently.  Someone else came along and thanked me for doing it — it needed doing, and he was worried that nobody was doing it.  I went out to get more supplies.

When I came back, somebody else more senior (everybody is more senior to me) was doing my job.  As I walked up and he saw the supplies in my hand (more of what I’d already been using), he told me, “No, those are completely wrong.  You should never be using those.”  He explained why.  Then he pointed out the tools I was using, and told me how his tools were much more appropriate for the task.  He then turned away from me and went back to work, on the job that had been mine.

I felt humiliated.  I felt like I must have screwed things up, working for over an hour with the wrong supplies and wrong tools.  I strongly suspect that he felt that he reached out to me in a “teachable moment” — he explained to me how I was mistaken, and how his approach was much better.  He probably felt that he did me a favor.  I felt like quitting.  I packed up all the stuff I was using and put it away, then went and sat down until it was time for my scene.

Back when OOPLSA was in Atlanta, in 1997, I got to have lunch with Adele Goldberg.  At that time, she was working on a Smalltalk programming environment to be used in the UK Open University‘s introductory course.  She told me that the greatest benefit of distance education was for supporting working professionals in learning something new.  The issue wasn’t finding time in a day.  It was humiliation.  “You work in a field for 10, 20 years, and you get recognized for your expertise.  Now go into a classroom, and raise your hand to admit that you don’t know something.  It’s really hard!”  On the Internet, nobody can see you blush.

Seymour’s right — it is a good thing to be in these situations, to be reminded of what it’s like for our students. I’m sure that our students may also feel that they’re losing face when met with a “teachable moment.”  It’s a real challenge for us to teach it in a way that avoid humiliation, that allows the student to see the lesson but feel encouraged to keep going, to keep engaged.

Lisp and Smalltalk are dead: It’s C all the way down.

Georgia Tech’s College of Computing is now considering a proposal to remove Smalltalk from the required curriculum in favor of C++.  When I got here in 1993, we taught Pascal (mostly) and had required courses in C, Lisp, and Smalltalk.  The faculty explicitly valued that students see more than one school of programming thought. I took over the Smalltalk-using course from John Schilling and Richard LeBlanc, and moved it from ObjectWorks to Squeak. When we moved to semesters in 1999, Lisp got dropped, and we’d moved from Pascal to Java as our main teaching language.  When we drop Smalltalk (now using VisualWorks), we will have a first semester in Python, and the rest of the required curriculum will be Java, C, C++, and C#.  We will explicitly tell students “C and C-like languages are all that there is.”

Why drop Smalltalk?  Students and teachers view it as “a dead language, not worth learning.”  It is the case that there are concepts in Objects and Design (the name of the course) which can most easily be discussed in C++. C++ is wildly popular in industry, so it’s not surprising that some language-specific techniques have developed, techniques that our students should probably know.

It’s reasonable to teach a course on object-oriented analysis, design, and programming in C++ rather than Smalltalk.  I’m more disappointed that we will have a curriculum that is all about C.

Richard Gabriel has been thinking a lot about the C-ness of our discipline.  If you have not read Richard Gabriel’s articles on “Worse is Better,” I recommend them. Dan Weinreb has a nice overview, and there’s a list of all the various pieces in Gabriel’s debate (some of which was with himself!). Gabriel has been trying to understand why Lisp, despite its many measurable benefits over C (e.g., Lisp programmers are more productive and generate fewer bugs, Lisp environments are amazingly powerful, Lisp code is small and runs fast), has so clearly lost the battle over hearts and minds.

Gabriel contrasts two design philosophies, the MIT/Stanford philosophy (which he calls “the right thing“) and the “New Jersey” C/UNIX philosophy (which he calls “worse is better”).  In short form, the MIT/Stanford philosophy (which he associates with Lisp, and which I also associate with Smalltalk) is that correctness and consistency are the most important design quality. In Lisp and Smalltalk, we have S-expressions and objects consistently.  The C/UNIX philosophy places simplicity in interface and implementation as the most important design quality.

Python is a mishmash of the two design philosophies.  Yes, you get lambda and map/reduce and objects and classes.  But you lose the consistency and syntactic flexibility of Lisp and Smalltalk.  What’s interesting is that Python, being the least C-like of the popular languages in computing education today, is mostly seen as a language for the NON-computing major.  It’s like faculty are saying, “Oh sure, those simpler and more conceptual ways of programming are fine for people who won’t be real programmers.  For our students, it’s C all the way.”

I don’t dispute that Unix/C philosophy has won the marketplace. I worry about only teaching that to our students. I think it’s important for Computing  majors to understand Gabriel’s debate, to understand what’s valuable about Lisp, Smalltalk, APL, and other high-power, lots-done-in-few-lines-of-code, flexible languages and environments.  We want our students to be thought leaders, to think about possibilities that aren’t currently in vogue in the marketplace. They should know about lessons of history, to avoid repeating mistakes and to resurrect old ideas when technology and opportunities fit.

The political forces are lined up to make the Georgia Tech change likely.  In comparison with the departments that I had contact with this summer, we’re late.  The C-only train has left the station.  Few departments teach surveys of programming languages anymore, and I don’t know of any department that teaches a required course in history of computing. I worry about what this means for our discipline.  Are we really going to tell students that the peak of human expressibility for computation was in 1973?  That all programming language research from here on out is wasted energy?  That simplicity is all that we can ever hope for, and correctness and consistency just aren’t worth working on? Are we forever stuck with 30+ year old ideas and don’t even teach that anything else is possible?