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

Why should non-CS majors learn functional programming?

In my research, I’m most interested in the non-CS majors, the ones who learn computing because it makes them more productive (see where I make that argument) or because they want to make themselves more marketable (see Eric Robert’s post) or because they will live and work (as I predict) in the fat line between programmers and users (see post here).  A recent article in the CACM suggests that all non-CS majors need to be learn (let’s not use the “be exposed” euphemism — there’s no sense in “exposing” someone to something unless you’d like them to learn from it) “functional programming languages [and] the declarative programming paradigm.”  I’m willing to consider that, but why?  The quote below says, “they allow programmers to do more with less and enable compilation to more efficient code across a wide range of runtime targets.”  I’ve been studying non-CS majors who program for a lot of years, and I’ve never heard any of them say even once that they want to “enable compilation to more efficient code across a wide range of runtime targets.”

So let’s consider the “more with less.”  Do we buy that what what non-CS majors is to be able to get more expressive power with fewer keystrokes?  I don’t see the argument for that.

• Brian Dorn studied graphic designers who program, and found that assignment was fairly hard for them to learn (see his CHI 2010 paper).  Surely, there’s not much that has fewer characters than that.
• Neil Brown has been mining the BlueJ Blackbox data for empirical data on what students get wrong most often (see his ICER paper).  I was surprised to learn that confusing & for && and | for || is pretty common.  Those are pretty easy to type, short, and seemingly error-prone expressions.
• We have Thomas Green’s fascinating result that that IF P THEN … END P; IF NOT P THEN … END NOT P. is not just better than IF P THEN…ELSE.…  It’s ten times better — novices do better by a magnitude if they avoid ELSE.

My suspicion is that non-CS major programmers value understandability and fewer errors, over fewer keystrokes and more power.

I like functional programming and would be interested in a good argument for it for non-CS majors.  I don’t see it here.

Second, would-be programmers (CS majors or non-majors) should be exposed as early as possible to functional programming languages to gain experience in the declarative programming paradigm. The value of functional/declarative language abstractions is clear: they allow programmers to do more with less and enable compilation to more efficient code across a wide range of runtime targets. We have seen such abstractions gain prominence in DSLs, as well as in imperative languages such as C#, Java, and Scala, not to mention modern functional languages such as F# and Haskell.

via Teach Foundational Language Principles | May 2015 | Communications of the ACM.

How do we make programming languages more usable and learnable?

Amy Ko made a fascinating claim recently, “Programming languages are the least usable, but most powerful human-computer interfaces ever invented” which she explained in a blog post.  It’s a great argument, and I followed it up with a Blog@CACM post, “Programming languages are the most powerful, and least usable and learnable user interfaces.”

How would we make them better?  I suggest at the end of the Blog@CACM post that the answer is to follow the HCI dictum, “Know thy users, for they are not you.”

We make programming languages today driven by theory — we aim to provide access to Turing/Von Neumann machines with a notation that has various features, e.g., type safety, security, provability, and so on.  Usability is one of the goals, but typically, in a theoretical sense.  Quorum is the only programming language that I know of that tested usability as part of the design process.

But what if we took Amy Ko’s argument seriously?  What if we designed programming languages like we defined good user interfaces — working with specific users on their tasks?  Value would become more obvious.  It would be more easily adopted by a community.  The languages might not be anything that the existing software development community even likes — I’ve noted before that the LiveCoders seem to really like Lisp-like languages, and as we all know, Lisp is dead.

What would our design process be?  How much more usable and learnable could our programming languages become?  How much easier would computing education be if the languages were more usable and learnable?  I’d love it if programming language designers could put me out of a job.

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.

The best-researched CS textbook ever

When I visited Carnegie Mellon University a few weeks ago, I got to spend some time talking with Ken Koedinger and Albert Corbett about the early cognitive tutors research on Lisp, Pascal, and Prolog.  Albert told me that, at one point, they tried to teach Lisp, Pascal, and Prolog, all in one class.  At first, they taught it for maximal transfer, i.e., teach the same/similar production rules close to one another.  So they’d teach assignment in Lisp, Pascal, and Prolog; then conditionals in Lisp, Pascal, then Prolog, then…you get the idea.  It was, as you might imagine, a disaster.  Then they taught the three languages in sequence, and it really worked!  Albert said that that’s when he realized how much programming novices bind their knowledge to surface-level features.

Ken told me that the way that they taught Lisp (which mirrored the order of material when taught Pascal and Prolog, to get the most possible transfer) was then put in the book Essential Lisp by John R. Anderson, Albert T. Corbett, and Brian J. Reiser.  I had to get myself a copy (less than $6 used, including shipping).

The introduction includes references to the six, now famous and often-cited, journal articles that describe the research that informs this book.  I realized that I was holding probably the best-researched CS textbook ever — not in the sense of evaluating it afterward, but in the sense of having a lot of really good evidence at the design stage that this was a good way to teach computer science.

Some of my immediate observations from flipping through the book.

Start out slow, and progress slowly.  Here is the first exercise in the book, from page 5. “Write a LISP function call that adds the numbers 3 and 2. You should call a particular LISP function with the arguments 3 and 2.” Second exercise: “Write a function call that will divide 6 by 2. Do this just as you did in the previous problem, but use the function that divides numbers.”  If you can’t do this, please re-read the first five pages of the book, which contains all these answers.

Mutable variables are no big deal.  I know that people worry a lot about mutable variables in functional languages these days.  I am told that that’s why Structure and Interpretation of Computer Programs avoids them for so long.  I know of no evidence that shows that mutable variables really are a problem for anyone. Setq is introduced on page 13 of Essential Lisp.  Parameters to functions are introduced on page 23.  That may be an accident — I don’t see any references to studies that show that that’s the best way to do it.

Iteration before Recursion.  Essential Lisp teaches iteration (with loop) on page 94. Recursion starts in the next chapter.  This is very purposeful.  The introduction references a 1986 paper by Kessler and Anderson (“Learning flow of control: Recursive and iterative procedures” from Human-Computer Interaction) where they explored recursion first, then iteration first.  I looked up and read that paper, then the follow-up paper by Susan Wiedenbeck (1989, International Journal of Man-Machine Studies).  Bottomline: If you are going to teach both, always start with iteration.   The explanation from the Kessler and Anderson was supported in Wiedenbeck’s studies.  It’s not that recursion is harder, it’s that iteration syntax is so complicated.  If you learn iteration well, the pieces of that syntax that you use in recursion are pretty obvious.  If you learn recursion first, it doesn’t really help in dealing with the more complex syntax of iteration structures, and knowing one way to repeat seems to conflict with learning a new way to repeat.

I’m having fun reading through the book, and then using that as a guide into the research literature.  I don’t believe that this is the best and only way to teach computer science.  But here’s a great example of using research to inform the design of education.

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.

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?