Learnable Programming: Thinking about Programming Languages and Systems in a New Way

Bret Victor has written a stunningly interesting essay on how to make programming more learnable, and how to draw on more of the great ideas of what it means to think with computing.  I love that he ends with: “This essay was an immune response, triggered by hearing too many times that Inventing on Principle was “about live coding”, and seeing too many attempts to “teach programming” by adorning a JavaScript editor with badges and mascots. Please read Mindstorms. Okay?”  The essay is explicitly a response to the Khan Academy’s new CS learning supports, and includes many ideas from his demo/video on making programming systems more visible and reactive for the programmer, but goes beyond that video in elaborating a careful argument for what programming ought to be.

There’s so much in his essay that I strongly agree with.  He’s absolutely right that we teach programming systems that have been designed for purposes other than learnability, and we need to build new ones that have a different emphasis.  He uses HyperTalk as an example of a more readable, better designed programming language for learning, which I think is spot-on.  His video examples are beautiful and brilliant.  I love his list of characteristics that we must require in a good programming language for learners.

I see a border to Bret’s ideas.  There are things that we want to teach about computing where his methods won’t help us.  I recognize that this is just an essay, and maybe Bret’s vision does cover these additional learning objectives, too.  The learning objectives I’m struggling with are not made easier with his visual approach.

Let me give two examples — one as a teacher, and the other as a researcher.

As a teacher: I’m currently teaching a graduate course on prototyping interactive systems.  My students have all had at least one course in computer programming, but it might have been a long time ago.  They’re mostly novices.  I’m teaching them how to create high-fidelity prototypes — quite literally, programming artifacts to think with.  The major project of the course is building a chat system.

• The first assignment involved implementing the GUI (in Jython with Swing).  The tough part was not the visual part, laying out the GUI.  The tough part was linking the widgets to the behaviors, i.e., the callbacks, the MVC part.  It’s not visible, and it’s hard to imagine making visible the process of dealing with whatever-input-the-user-might-provide and connecting it to some part of your code which gets executed non-linearly.  (“This handler here, then later, that handler over there.”)  My students struggled with understanding and debugging the connections between user events (which occur sometime in the future) with code that they’re writing now.
• They’re working on the second assignment now: Connecting the GUI to the Server.  You can’t see the network, and you certainly can’t see all the things that can go wrong in a network connection.  But you have to program for it.

As a researcher: I’ve written before about the measures that we have that show how badly we do at computing education, and about how important it is to make progress on those measures: like the rainfall problem, and what an IP address is and whether it’s okay to have Wikipedia record yours.  What makes the rainfall problem hard is not just the logic of it, but not knowing what the input might be.  It’s the invisible future.

I disagree with a claim that Bret makes (quoted below), that the programmer doesn’t have to understand the machine.  The programmer does have to understand the notional machine (maybe not the silicon one), and that’s critical to really understanding computing. A program is a specification of future behavior of some notional machine in response to indeterminate input.  We can make it possible to see all the programs execution, only if we limit the scope of what it is to be a program.  To really understand programming, you have to imagine the future.

It’s possible for people to learn things which are invisible.  Quantum mechanics, theology, and the plains of Mordor (pre-Jackson) are all examples of people learning about the invisible.  It’s hard to do.  One way we teach that is with forms of cognitive apprenticeship: modeling, coaching, reflection, and eliciting articulation.

Bret is absolutely right that we need to think about designing programming languages to be learnable, and he points out a great set of characteristics that help us get there.  I don’t think his set gets us all the way to where we need to be, but it would get us much further than we are now.  I’d love to have his systems, then lay teaching approaches like cognitive apprenticeship on top of them.

Thus, the goals of a programming system should be:

to support and encourage powerful ways of thinking

to enable programmers to see and understand the execution of their programs

A live-coding Processing environment addresses neither of these goals. JavaScript and Processing are poorly-designed languages that support weak ways of thinking, and ignore decades of learning about learning. And live coding, as a standalone feature, is worthless.

Alan Perlis wrote, “To understand a program, you must become both the machine and the program.” This view is a mistake, and it is this widespread and virulent mistake that keeps programming a difficult and obscure art. A person is not a machine, and should not be forced to think like one.

via Learnable Programming.

Typography to describe iteration

One of the complaints about Python is the use of indentation to define blocks.  A quote from Don Knuth is often used to defend that use:

We will perhaps eventually be writing only small modules which are identified by name as they are used to build larger ones, so that devices like indentation, rather than delimiters, might become feasible for expressing local structure in the source language.

Is it natural to use typography to indicate local structure?  Is it more accessible than curly brace ({}) notation, or BEGIN/END blocks?  Do we understand it easily?

I thought about this Sunday morning when I was at services, using a songbook I’d never seen before. The verses and refrain were indicated like this:

You sing the refrain (the “How great thou art” part) twice, indicated by “(2)” — which is pretty obvious, since it’s clear you wouldn’t sing “(2).”  What’s the “scope” of the repeat?  Well, the refrain is italicized, and so is the “(2).”  So you sing twice the part in italics.

I thought it was interesting to use typography to convey to the general population how to “iterate.” If we could count on the general population to know musical notation, and if the music was provided, there’s a different notation for indicating “iteration.”  The use of typography for defining iteration is meant to be more understandable, more generally accessible.

MATLAB and APL: Meeting Cleve Moler

I have often described MATLAB as “APL with a normal character set,” but I didn’t actually know anything about how MATLAB came to be or if there was any relationship.  Last night, I got to ask the man who invented MATLAB, Cleve Moler, at the IEEE Computer Society Awards Dinner, where Cleve was named a “Computer Society Pioneer.”  When I introduced myself as coming from Georgia Tech, he took notice.  ”Georgia Tech is a big MATLAB user!”  We teach 1200 Engineering students a semester in MATLAB.

Cleve developed MATLAB (in Fortran) as a Matrix Calculator (explicitly, a “MATrix LABoratory”) for his students.  There was no explicit tie to APL, but he saw the connections.  He said that he’s always seen MATLAB as “portable APL” because he used a traditional character set.

It’s not just the character set though.  ”Iverson showed me J.  I wanted MATLAB to be understandable by normal people.”  He said that someone once converted a program he’d written in MATLAB into APL.  ”I asked what that was.  They told me, ‘That’s your program!’ I couldn’t recognize it.”  APL is about being uniform about everything, but MATLAB “is a mishmosh of all kinds of things.”

Others joined in the conversation.  ”What do you think about Mathematica?”  Cleve responded, “Mathematica is APL for the 21st century.  Mathematica has a uniformity about it.”

Cleve’s ideas about what make a language usable “by normal people” are interesting.  The success of MATLAB in terms of its use by so many people in so many different contexts, domains, and application areas give him real authority for making such claims.  He sees a “mishmosh” as being easier for people to understand than uniformity.  Marvin Minsky famously said that the brain is likely a “kluge.”  Do we actually prefer messy languages, with less uniformity, perhaps as a reflection of our “kluge” nature?

Designing a language for programming with musical collaborators in front of an audience

If you were going to build a programming language explicitly for musicians to use when programming live with collaborators and in front of an audience, what would you build into it?  What should  musicians have to learn about computer science in order to use this language? There’s a special issue of Computer Music Journal coming out, focused on these themes. What a fascinating set of design constraints, and how different from most programming languages!

We are excited to announce a call for papers for a special issue of
Computer Music Journal, with a deadline of 21st January 2013, for
publication in Spring of the following year. The issue will be guest
edited by Alex McLean, Julian Rohrhuber and Nick Collins, and will
address themes surrounding live coding practice.

Live coding focuses on a computer musician’s relationship with their
computer. It includes programming a computer as an explicit onstage
act, as a musical prototyping tool with immediate feedback, and also
as a method of collaborative programming. Live coding’s tension
between immediacy and indirectness brings about a mediating role for
computer language within musical interaction. At the same time, it
implies the rewriting of algorithms, as descriptions which concern the
future; live coding may well be the missing link between composition
and improvisation. The proliferation of interpreted and just-in-time
compiled languages for music and the increasing computer literacy of
artists has made such programming interactions a new hotbed of musical
practice and theory. Many musicians have begun to design their own
particular representational extensions to existing general-purpose
languages, or even to design their own live coding languages from
scratch. They have also brought fresh energy to visual programming
language design, and new insights to interactive computation, pushing
at the boundaries through practice-based research. Live coding also
extends out beyond pure music and sound to the general digital arts,
including audiovisual systems, linked by shared abstractions.

2014 happens to be the ten-year anniversary of the live coding
organisation TOPLAP (toplap.org). However, we do not wish to restrict
the remit of the issue to this, and we encourage submissions across a
sweep of emerging practices in computer music performance, creation,
and theory. Live coding research is more broadly about grounding
computation at the verge of human experience, so that work from
computer system design to exposition of live coding concert work is
equally eligible.

Topic suggestions include, but are not limited by:

- Programming as a new form of musical exploration
- Embodiment and linguistic abstraction
- Symbology in music interaction
- Uniting liveness and abstraction in live music
- Bricolage programming in music composition
- Human-Computer Interaction study of live coding
- The psychology of computer music programming
- Measuring live coding and metrics for live performance
- The live coding audience, or live coding without audience
- Visual programming environments for music
- Alternative models of computation in music
- Representing time in interactive programming
- Representing and manipulating history in live performance
- Freedoms, constraints and affordances in live coding environments

Authors should follow all CMJ author guidelines
(http://www.mitpressjournals.org/page/sub/comj), paying particular
attention to the maximum length of 25 double-spaced pages.

Submissions should be received by 21st January 2013.  All submissions
and queries should be addressed to Alex McLean
<alex.mclean@icsrim.org.uk>.

Modern HyperCard for Today’s Schools: But Where’s the Community of Practice?

I’ve talked about RunRev/LiveCode here before.  It’s 90% HyperCard, updated to be cross-platform and with enhanced abilities.  I mostly agree with the comments below (but not with the critique of Scratch or Logo): It really does seem like an excellent tool for the needs in today’s schools.  It’s real programming, you can build things quickly, you can build for desktop or Web or mobile devices, it’s cross platform, and it’s designed to be easily learned.  The language is English-like and builds on what we know about how people naively think about programming.

I proposed using this next Fall in a course I’m teaching for graduate students to introduce them to programming. I got shot down.  The faculty argued that they didn’t want a “boutique” language.  They wanted a “real” language.  I do see the point.  Audrey Watters and I talked about this a few weeks ago.  Students don’t just want knowledge — they want to join a community of practice.  The students see or imagine people who do what they want to do, and the students want to learn what they know.  Students want to grow to be at the center of some community of practice.  Where’s the community of practice for HyperCard-like programming today?  Do you see lots of experts who are doing the cool things that you want to do — with HyperCard?  The power and expressivity of a language is not enough.  Languages today have cultures and communities.  To learn a language is to express interest in joining or defining a culture or community.  Alan Perlis said, “A language that doesn’t affect the way you think about programming, is not worth knowing.”  Today, a language that doesn’t reflect who you want to be, is not worth knowing.

Pascal is still available for modern computers.  So is Logo.  We know how to teach both of them to novices far better than we know how to teach Java or C++ to novices.  These languages were not abandoned for pedagogical or cognitive grounds — they work for teaching computing.  So why don’t we use them?  It’s because of the perceptions, the expectations, and the culture/community that grew up around those.  I’ll bet that some teacher who doesn’t know anything about Logo could discover it, not know about its past, and use it really well to teach K-12 kids about computer science.

Let’s go one step beyond the discussion that Audrey and I had, and I’ll use something that I always warn my students about: introspection.

I use LiveCode, and love it.  I don’t have much time to program these days.  So when I need a tool for data analysis, or need to remove student names from thousands of Swiki pages, or want to build a prototype, I use LiveCode because I can code more quickly and easily in that than anything else I know these days.  The code is not well structured or beautiful, but after I write it and use it, nobody (including me) ever looks at it again.  There is a community of LiveCode developers, but I don’t really participate in it much.  When I have wanted to create code that I share with others, I have used Python or Squeak.  Currently, I’m interested in investing some time in learning JavaScript, because of its Lisp/Smalltalk-like internals and because of the platforms that it opens up for me.  I’m not particularly interested in joining the JavaScript community. Yesterday, I took some time off to just play, and I downloaded some new languages that I’m interested in for computer music: Impromptu and Field.  I do choose languages based on what I want to be, but not for the community. I choose languages for the language features, the task needs, the task constraints, and my facility with the language.

I don’t know why I’m not particularly drawn to any language community these days.  Maybe I am choosing languages based on community, but I’m not aware of it. Maybe I am at the center of my community of practice, which frees me to make choices and go in new directions.  I want to be a computing education researcher who can express his ideas in code and can build his own tools.  There aren’t many of us, and there isn’t a language central to that community.  Maybe, in this community of practice, the tool is incidental and not integral to the community.

I do think (perhaps naively) that it’s important for us in computing to be willing to invent a community of practice, not just join an existing one.  If you want to change the way people think about computing, you don’t just join an existing community.  The existing communities were created within and support the existing values.  We should also be about inventing communities that support different values.

I spoke to dozens of teachers who all told me a similar story. There is a sea change in the air. After thirty years of teaching powerpoint and excel spreadsheets, schools are finally returning to the idea that we really need to teach the next generation how to program – but where are the tools to do it? Suddenly ICT teachers up and down the country are being told, “from next year you must teach programming principles” but they have been given no training, tools or guidance on how to achieve this. With little time to learn and a very limited range of choices, these teachers were delighted to discover LiveCode. It seems to be exactly what they are looking for. Easy to learn for both teachers and students, real programming without the limitations of “snap together” tools like scratch or logo, no arcane or hard to understand syntax or symbols, and best of all, it lets the students deploy the end results on their iPad, iPhone or Android device.

via Education, Education | revUp 131.

A nice definition of computational thinking, including risks and cyber-security

GasStationWithoutPumps did a blog piece on the newspaper articles that I mentioned earlier this week, and he pointed out something important that I missed.  The Guardian’s John Naughton provided a really nice definition of computational thinking:

… computer science involves a new way of thinking about problem-solving: it’s called computational thinking, and it’s about understanding the difference between human and artificial intelligence, as well as about thinking recursively, being alert to the need for prevention, detection and protection against risks, using abstraction and decomposition when tackling large tasks, and deploying heuristic reasoning, iteration and search to discover solutions to complex problems.

I like this one.  It’s more succinct than others that I’ve seen, and still does a good job of hitting the key points.

Naughton’s definition includes issues of cyber-security and risk.  I don’t see that often in “Computational Thinking” definitions.  I was reminded of a list that Greg Wilson generated recently in his Software Carpentry blog about what researchers need to know about programming the Web.

Here’s what (I think) I’ve figured out so far:

1. People want to solve real problems with real tools.
2. Styling HTML5 pages with CSS and making them interactive with Javascript aren’t core needs for researchers.
3. All we can teach people about server-side programming in a few hours is how to create security holes, even if we use modern frameworks.
4. People must be able to debug what they build. If they can’t, they won’t be able to apply their knowledge to similar problems on their own.

Greg’s list surprised me, because it was the first time that I’d thought risk and cyber-security as critical to end-user programmers.  Yes, cyber-security plays a prominent role in the CS:Principles framework (as part of Big Idea VI, on the Internet), but I’d thought of that (cynically, I admit) as being a nod to the software development firms who want everyone to be concerned about safe programming practices.  Is it really key to understanding the role of computing in our everyday lives?  Maybe — the risks and needs for security may be the necessary consequent of teaching end-users about the power and beauty of computing.

Greg’s last point is one that I’ve been thinking a lot about lately.  I’ve agreed to serve on the review committee for Juha Sorva’s thesis, which focuses on his excellent program visualization tool, UUhistle.  I’m enjoying Juha’s document very much, and I’m not even up to the technology part yet.  He has terrific coverage of the existing literature in computing education research, cognitive science, and learning sciences, and the connections he draws between disparate areas is fascinating.  One of the arguments that he’s making is that the ability to understand computing in a transferable way requires the development of a mental model — an executable understanding of how the pieces of a program fit together in order to achieve some function.  For example, you can’t debug without a mental model of how the program works (to connect to Greg’s list).  Juha’s dissertation is making the argument (implicitly, so far in my reading) that you can’t develop a mental model of computing without learning to program.  You have to have a notation, some representation of the context-free executable pieces of the program, in order to recognize that these are decontextualized pieces that work in the same way in any program.  A WHILE loop has the same structure and behavior, regardless of the context, regardless of the function that any particular WHILE loop plays in any particular program. Without the notation, you don’t have names or representations for the pieces that is necessary for transfer.

Juha is making an argument like Alan Perlis’s argument in 1961: Perlis wasn’t arguing that everyone needed to understand programming for its own sake.  Rather, he felt that the systems thinking was the critical need, and that the best way to get to systems thinking was through programming.  The cognitive science literature that Juha is drawing on is saying something stronger: That we can’t get to systems thinking (or computational thinking) without programming.  I’ll say more about Juha’s thesis as I finish reviewing it.

It’s interesting that there are some similar threads about risk and cyber-security appearing in different definitions of computational thinking (Naughton and Wilson discussed here), and those thinking about how to teach computational thinking (Sorva and Perlis here) are suggesting that we need programming to get there.

This is CS in K-12: Career & Technical Education

Computer science in most states in K-12 is classified as “Career and Technical Education” (according to the Running on Empty report).  ”Maybe that’s okay. Computing is important for many careers,” say some who hear this tidbit.  Maybe they don’t realize what “Career and Technical Education” is.

I’m now on a mailing list for career and technical education.  (CS in Georgia is in Career, Technical, and Agricultural Education.)  Yesterday, I got a catalog from a company that specializes in career and technical education.  Here’s what it looks like.  The people who pick the drills for your local high school may also be the ones who pick what programming languages are taught (if any). Computer science is in shop class.  There’s nothing wrong with shop class.  I’m not convinced that the preparation that makes you great at picking drills also makes you great at picking attributes of CS classes.

InfoWorld Programming trends: Education matters less, more JVM/JavaScript-target languages

I found this piece at Infoworld really interesting.  Originally, I was going to blog on it because of the growing trend of languages that target the JVM or JavaScript — what are the implications about Java and JavaScript when there’s so much interest in creating specialized languages on top of them?  But then I got to Programming Trend #8 and realized that this was really a piece for us to talk about — does traditional computing education matter anymore?

Ask any project manager and they’ll say there’s not enough talent from top-tier computer science departments. They may go so far as to say they would hire a new CS major from a top school without reading the résumé. But ask this same desperate project manager about a middle-aged programmer with a degree from the same school, and they’ll hesitate and start mumbling about getting back to you later.

Indeed, it isn’t unheard of to find major technology companies complaining to Congress that they can’t find Americans capable of programming, all while defending themselves in age-discrimination lawsuits from older programmers with stellar résumés and degrees from top universities.

Some of this may suggest that education doesn’t have the same value it used to hold. Older workers with degrees that used to be valuable are saying companies want only young, unfettered bodies that will work long hours. It leaves you to wonder whether it’s the age and implied lower pay expectations, not the knowledge that makes fresh college graduates so desirable.

via 11 programming trends to watch.

Is 2011 the year of Scripting? 11 hot skills for 2011

Interesting that prototyping and rapid development is predicted to make a comeback.  Maybe this is the year when scripting becomes more important than more traditional, compiled languages that have a main() in them?  Many of us already think scripting is pretty important, and much easier to learn.  Yet, C++ is still taught in an awful lot of CS1 classes.

About 47% of the survey respondents who said they plan to hire IT professionals in the next year will be looking for people with programming or application development skills. Moreover, Monster.com reports that three quarters of 245 HR managers and recruiters it surveyed in May plan to hire IT staffers with applications expertise by the end of this year.

“Those skills are separate from enterprise business applications,” says David Foote, CEO and chief research officer at Foote Partners LLC in Vero Beach, Fla. In this volatile market, companies need to quickly reposition, as well as use IT to grow the business through new products and innovation. So “RAD, rapid programming and agile programming seem to be coming back. Companies are starting to increase some of their pay [in these areas], which means they’re looking for more capabilities in their companies,” he says.

via 11 hot skills for 2011 – Computerworld.

Computers are Systems, not Languages – Ian Bogost

I find this whole idea bizarre — that degree-granting programs would really believe that learning a programming language as being at all comparable to learning a natural language.  Ian does a good job addressing the issues.  I wonder if we in CS made a mistake when we called our notations “languages.”  They’re notations.  They are not used for the same purposes as natural languages.  They describe different things.  Maybe we led people astray by calling them languages.

Last year I learned about a rumor swirling around the comparative literature department at UCLA, where I did my PhD. Supposedly I had managed to get C++ to count as one of the three languages required for the degree. It’s not true, for the record, but it is a topic that comes up from time to time—substituting programming languages for natural languages. Many of us who work in computing and the humanities claim that knowledge of computation is essential background for all discussions that hope to bridge the two, not just for those who intend to make things for computers.

via Ian Bogost – Computers are Systems, not Languages.

Notation And Thinking at Dick Lipton’s Blog

My colleague Dick Lipton writes wonderful blog posts, and he just wrote one this last week on the role of notation in our thinking, a mathematical/computational take on the Whorfian Hypothesis.  The below quote (attributed to Alfred North Whitehead) is actually from the commentary on the post, and captures the issues succinctly.

An important issue that Dick left unconsidered in his piece (but is raised in the commentary) is the up-take cost of a new notation.  There is a learning cost in developing the abstraction and learning the mapping that this symbol stands for that.  Much of Dick’s post is on APL which is a wonderful example of exactly this point.  APL is very compact and powerful — but it uses an unusual symbol set, and requires the newbie to learn vector operations as a way of describing computations.  That’s a valuable perspective to learn, but it comes with a cost.  In the end, all educational decisions are economic: Is the power and brevity in notation worth the cost to learn?

It is a profoundly erroneous truism, repeated by all copy-books and by eminent people when they are making speeches, that we should cultivate the habit of thinking of what we are doing. The precise opposite is the case. Civilisation advances by extending the number of important operations which we can perform without thinking about them. Operations of thought are like cavalry charges in a battle — they are strictly limited in number, they require fresh horses, and must only be made at decisive moments.

via Notation And Thinking « Gödel’s Lost Letter and P=NP.

Making Software: TDD doesn’t work; Architecting is mixed; scripting is great

I got my copy of Making Software by Oram and Wilson on Friday, and have read just over half of it already.  I’m really enjoying it!  I’ve always enjoyed empirical data on programming (Whoa! My teenagers would be rolling their eyes at such a geeky statement!), and this book is chockfull of it.  Some of the most interesting chapters for me so-far:

• Herraiz and Hassan have a great study comparing all the various complexity metrics to plain ole counting lines of code.  The correlation is astounding.  Sure, sure — counting lines of code is a rough measure.  But when the correlation with McCabe’s or Halstead’s metrics are 0.97, why go to all that trouble?
• Barry Boehm does an even-handed (even if technically WAY complicated) analysis of whether up-front architecting is really worth it, or are agile methods (with architecting distributed across) good enough?  The tradeoff is between having to do rework later, and spending way too much expensive effort up front than is worthwhile.  His answer is that it depends on the size of the code and the riskiness of the effort. The cost of NOT architecting is between 18% and 92% of the total cost, depending on the project.  I think he’s trying to make the case that agile methods are too expensive and that Kent Beck’s arguments for agile methods are wrong.
• The chapter on “How effective is Test-Driven Development?” was really enlightening for me.  There are just no convincing data that building tests before building code is worth it!  There aren’t measurable benefits in quality, for a variety of measures.
• Whitecraft and Williams’ chapter on “Why aren’t more women in computer science?” is terrific, even-handed and sobering.  They take seriously the question, “Is there value in getting more women into computing?”  They come up with the answer that it’s worth trying to get more women in, but the claims about the value of diversity just aren’t supported yet.  In 2003, Norway passed a law that all public firms had to have at least 40% women on their board.  A 2009 analysis showed that the companies’ value dropped, but because they brought on lots of younger and inexperienced women to meet the requirement.  Will it help in the long run?  Still to be determined.  A really interesting datum on why women left computing: Unlike men, women who excel in math also tend to excel verbally, thus have more options available to them than men who are great at math but can’t string two words together.  And if you have more choices, why take one that has less social value?
• The chapter I was most excited about reading, and which was ultimately most disappointing, was McConnell’s on “What does 10x mean? Measuring variations in programmer productivity.”  Is there really a magnitude difference between the best and worst programmers?  He goes through a bunch of studies (some of individuals, some of teams; some on initial code writing, some on debugging), but in not enough detail to feel convincing or enlightening to me.  In the end, there’s evidence for a 10-fold difference, but some of the results are as high as 25:1 and as low as 3.5:1.  What’s most interesting for me is what’s not there: There’s no evidence supporting a three or five magnitude difference, that I’ve heard talk about.  The data says 10:1 is about the most we can argue.
• Prechelt’s chapter on comparing programming languages was fascinating.  In general, scripting languages won big, but he points out that a good programmer in a non-scripting language can often beat out a mediocre programmer in a scripting language.  Choose for the programmer, not the language, he argues.  But if you consider this result with the complexity and Boehm results earlier, there’s a strong argument for teaching scripting languages.  Scripting languages have fewer lines-of-code per solution, which leads to fewer errors and less complexity.  Start students in scripting languages, and they have a leg up for using those languages later.

I can’t take the big book with me to China, so I won’t get to finish it for a few weeks, but I can already recommend it.  Really fascinating to see where there’s real data, and where there’s not.

 

(How to Write a (Lisp) Interpreter (in Python))

It’s not really computing education, but it’s totally geeky fun and could make for a cool project to dissect for a student in a programming language’s class.

This page has two purposes: to describe how to implement computer language interpreters in general, and in particular to show how to implement a subset of the Scheme dialect of Lisp using Python. I call my interpreter Lispy (lis.py). Years ago, I showed how to write a Scheme interpreter in Java as well as one in Common Lisp. This time around the goal is to demonstrate, as concisely and accessibly as possible, what Alan Kay called “Maxwell’s Equations of Software.”

via (How to Write a (Lisp) Interpreter (in Python)).

Proving and Improving Teaching Programming Languages

SIGPLAN Education Board has produced a report “Why undergraduates should learn the principles of programming languages”  which was presented at the ACM Education Council meeting.  It makes four claims for why students should study programming languages:

• Students learn widely-applicable design and implementation techniques.
• Many students will need to create new domain specific languages or virtual machines, so it’s useful for them to study what’s known about languages.
• By learning programming languages, students learn new computational models and speed learning of new languages.  ”The best preparation for quickly learning and effectively using new languages is understanding the fundamentals underlying all programming languages and to have some prior experience with a variety of computational models.”
• Students learn how to choose the right programming language for a task.

The problem is that we have empirical support for none of these claims.  People are amazingly bad at transferring knowledge.  People tend to learn about a specific situation and not recognize when the same idea applies in a new situation — or worse, they transfer negatively, mistaking the similarity and using older knowledge in an incorrect way.

One of the few treatments of transfer of programming knowledge is The Transfer of Cognitive Skill by Mark Singley and John Anderson.  Transfer between programming languages, even between skills in the same language, is surprisingly small.  For example, there is evidence that students don’t even transfer (“vertically” as they describe it) between knowledge of how to write programs and how to debug those programs.

This doesn’t mean that the SIGPLAN folks are wrong or that those claims are wrong.  It’s simply that they haven’t been shown yet.

• We need studies showing students learning design and implementation techniques from programming languages, then applying them in new contexts.
• We need to show that students can usefully draw on older languages when designing new languages.
• We need to show that knowing one set of languages improves learning of a later set.  (Ben Shneiderman argued in the late 70′s that learning a second language can be even harder than learning a first language.)
• We need to show that we can teach students rubrics or guides by which they can choose new languages effectively.

My guess is: We can do all these things.  The real trick is how we teach such that these things happen.  There are these great examples in How People Learn showing that highlighting foundational knowledge, so that students recognize it and can use it in new contexts, can improve performance.  It is possible to teach for transfer.  No, transfer doesn’t occur automatically.  That doesn’t mean it can’t happen.

The SIGPLAN Education Board is planning to produce curricula to support the goals they’ve outlined.  I hope that they also create learning guides, recommendations on how to teach programming languages, and studies showing that these guides and recommendations work.  I believe that we can prove that learning programming languages can be very useful, but it may involve improving on current practice, which may not be informed by what learning scientists know about teaching for transfer.

The Right to Hack, not to Flash

Ian Bogost wrote a really interesting blog piece about the whining of developers over the loss of Flash on the iPhone/iPad platform.  Most of the respondents are going on and on about how Ian got it wrong and Apple is evil.  That’s entirely separate from Ian’s real point which is that complaining about Flash in indicative of the state of computational literacy today — learn a new platform!

But what does it say about the state of programming practice writ large when so many developers believe that their “rights” are trampled because they cannot write programs for a particular device in a particular language? Or that their “freedom” as creators is squelched for the same reason?

I wonder if it doesn’t amount to an indictment of the state of computational literacy.

via Ian Bogost – Flash is not a Right.

Developers today can only work in Flash?  They can’t learn Objective-C?  Nobody can build tools that compile to Objective-C, so that the developer has powerful tools but the app is built to Apple’s specs? I thought that good programmers built tools and learned new languages and platforms.

Programmers have a right to program, to “hack.”  As Ian points out, they don’t have a right to Flash.  More to Ian’s point, good programmers are flexible, can learn new tools, and when necessary, build new tools.

Apple may be making a big mistake here, and may be in the wrong.  I really don’t understand those issues well enough.  I do recognize Ian’s point, which is really about computing education: Stop whining and learn another way!