Teaching & Learning

ACM Classic Books Series

Paul McJones alerts us that the ACM posted PDF versions of some books in its Classic Books Series, which are available to anyone who creates a free ACM Web Account.

Among the currently available books, LtU readers are likely to be particularly interested in Hoare and Jones's Essays in computing science, Adele Goldberg and David Robson's Smalltalk-80: the language and its implementation, and Dahl, Dijkstra, and Hoare's Structured programming.

Long time readers will also know that I highly recommend Papert's Mindstorms: children, computers, and powerful ideas to anyone interested with the effect computers might have on education. Papert's Logo remains to this day the best children oriented programming language, but even if you disagree with me about this, his book is a must read.

Computer Science Education: Where Are the Software Engineers of Tomorrow?

A short article by Robert Dewar and Edmond Schonberg. The authors claim that Computer Science (CS) education is neglecting basic skills, in particular in the areas of programming and formal methods. We consider that the general adoption of Java as a first programming language is in part responsible for this decline, but also explain why - in their opinion - C, C++, Lisp, Ada and even Java are all crucial for the education of software engineers.

CUFP write-up

A write-up of the Commercial Users of Functional Programming meeting held this October is available, for those of us who didn't attend. The write-up is well written and thought provoking (it was written by Jeremy Gibbons, so that's not a surprise).

The goal of the Commercial Users of Functional Programming series of workshops is to build a community for users of functional programming languages and technology. This, the fourth workshop in the series, drew 104 registered participants (and apparently more than a handful of casual observers).

It is often observed that functional programming is most widely used for language related projects (DSLs, static analysis tools and the like). Part of the reason is surely cultural. People working on projects of this type are more familiar with functional programming than people working in other domains. But it seems that it may be worthwhile to discuss the other reasons that make functional languages suitable for this type of work. There are plenty of reasons, many of them previously discussed here (e.g., Scheme's uniform syntax, hygiene, DSELs), but perhaps the issue is worth revisiting, seeing as this remains the killer application for functional programming, even taking into account the other types of project described in the workshop.

Idioms for Composing Games with Etoys

Markus Gaelli, Oscar Nierstrasz, Serge Stinckwich. Idioms for Composing Games with Etoys. C5'06.

Creating one’s own games has been the main motivation for many people to learn programming. But the barrier to learn a general purpose programming language is very high, especially if some positive results can only be expected after having manually written more than 100 lines of code. With this paper we first motivate potential users by showing that one can create classic board- and arcade games like Lights Out, TicTacToe, or Pacman within the playful and constructivist visual learning environment EToys dragging together only a few lines of code. Then we present recurring idioms which helped to develop these games with only a few lines of code.

Learning to program with Etoys is very mind-stretching. Beyond the drag-and-drop syntax there's a world where programs are created by directly manipulating tangible objects on the screen. The objects expose a varied collection of primitives and it's a real journey of discovery to learn how to compose simple and beautiful programs. This paper documents some of the "aha!" discoveries that make Etoys programming lots of fun.

Squeaky Tales

The Etoys end-user programming environment is becoming tremendously important because of its inclusion with the One Laptop Per Child XO. Etoys was invented by Alan Kay's research group and is in continuous development and use as an integrated feature of Squeak Smalltalk. The Squeak/Etoys community includes lots of researchers, programmers, teachers, and kids around the world.

Squeaky Tales is a series of short tutorial screencasts designed to each people to program with Etoys. I'm very excited that this may be what's needed to make Etoys programming easy to learn for people at home. My experience has been that it's easy and fun to teach Etoys programming face-to-face with everybody using their own laptop, but that it's very slow and frustrating to try and learn Etoys by yourself just by installing it and clicking around. If Squeaky Tales makes it easy and fun to learn Etoys all by yourself at home then it's quite a contribution to the world!

If you try learning Etoys with Squeaky Tales then do leave a comment to say how you get along!

Engineering Software Correctness

Rex Page, Engineering software correctness, Proceedings of the ACMS,PLAN 2005 Workshop on Functional and Declarative Programming in Education, September 25, 2005.

Software engineering courses offer one of many opportunities for
providing students with a significant experience in declarative
programming. This report discusses some results from taking
advantage of this opportunity in a two-semester sequence of
software engineering courses for students in their final year of
baccalaureate studies in computer science. The sequence is based
on functional programming using ACL2, a purely functional
subset of Common Lisp with a built-in, computational logic
developed by J Strother Moore and his colleagues over the past
three decades...

A JFP educational pearl with the same title and a similar abstract appears in Journal of Functional Programming (2007), 17: 675-68, but I haven't managed to access it yet.


I am still in the process of finding furniture etc. But at least I have an apartment now... Thanks for all the help and tips, guys!

It's Time to Stop Calling Circuits "Hardware"

F. Vahid. It's Time to Stop Calling Circuits "Hardware". IEEE Computer Magazine, September 2007.

The advent of field-programmable gate arrays requires that we stop calling circuits “hardware”
and, more generally, that we broaden our concept of what constitutes “software.” ...
Developing modern embedded software capable of executing on multiprocessor and FPGA platforms requires expertise not just in temporally oriented modeling (W comes after X) like writing sequential code but also in spatially oriented modeling (Y connects with Z) like creating circuits.
An interesting take on where programming should be heading in the future -- and consequently, where programming languages should also be heading. This article is somewhat related to the recent discussion here on LtU about FPGA CPUs. As the excerpt above illustrates, Vahid draws a distinction between what he calls "temporally-oriented" computing, which focuses on sequence, and "spatially-oriented" computing, which focuses on connectivity of components. His basic argument is that traditional programming languages (and traditional programming education) focus on temporally-oriented computing, but that the growing use of FPGAs as an integral part of many systems (particularly embedded systems) necessitates a greater emphasis on programming in a spatially-oriented mode. We don't tend to talk too much about "hardware description" languages like VHDL and Verilog here on LtU, but perhaps they are the answer (or at least part of the answer) to Ehud's recent question about which languages we should be discussing to "stay ahead the curve".

Escape from Zurg: An Exercise in Logic Programming

Escape from Zurg: An Exercise in Logic Programming by Martin Erwig. Journal of Functional Programming, Vol. 14, No. 3, 253-261, 2004

In this article we will illustrate with an example that modern functional programming languages like Haskell can be used effectively for programming search problems, in contrast to the widespread belief that Prolog is much better suited for tasks like these.

...

The example that we want to consider is a homework problem that we have given in a graduate level course on programming languages. The problem was one of several exercises to practice programming in Prolog. After observing that many students had problems manipulating term structures in Prolog (after already having learned to use data types in Haskell) and spending a lot of time on debugging, the question arose whether it would be as difficult to develop a solution for this problem in Haskell. This programming exercise worked well, and we report the result in this paper.

(Haskell source code)

VamOz: Visual Abstract Machine for Oz

VamOz: Visual Abstract Machine for Oz

VamOz is a visual abstract machine executing kernel language programs as defined in the book Concepts, Techniques and Models of Computer Programming by Peter Van Roy and Seif Haridi.

VamOz has been developed by Frej Drejhammar and Dragan Havelka with contributions from Christian Schulte. The idea is to give students a tool with which they can increase their understanding of how the abstract machine computes. VamOz has been used successfully in 2003 in the Datalogi II course taught by Christian Schulte at KTH.

PLAI in print

Shriram Krishnamurthi's excellent book, Programming Languages: Application and Interpretation (PLAI), long available in PDF form, is now available in paperback.

There's also a paid download available, "in case you want to reward the author in kind". A free PDF of the latest version is still available, which "really is the entire book, with no strings attached." The book is now licensed under a Creative Commons license which allows it to be adapted ("remixed") to fit a course.

Here's an overview of the book's approach:

This book unites two approaches to teaching programming languages, one based on a survey of languages and the other on writing definitional interpreters.

Each approach has significant advantages but also huge drawbacks. The interpreter method writes programs to learn concepts, and has at its heart the fundamental belief that by teaching the computer to execute a concept we more thoroughly learn it ourselves. While this reasoning is internally consistent, it fails to recognize that understanding definitions does not imply we understand the consequences of those definitions. For instance, the difference between strict and lazy evaluation, or between static and dynamic scope, is only a few lines of interpreter code, but the consequences of these choices is enormous. The survey of languages school is better suited to understand these consequences.

The book is used as the textbook for the programming languages course at Brown University, taken primarily by 3rd and 4th year undergraduates and beginning graduate (both MS and PhD) students. It seems very accessible to smart 2nd year students too. The book has been used as a textbook at over a dozen other universities as a primary or secondary text.

XML feed