The concurrency.cc logo

I am excited to announce the release of Plumbing, software and documentation to support artists and makers in the programming of low-cost, open-hardware
platforms like the Arduino. The Plumbing libraries are a collection of parallel components written in occam-pi , a small language with a long history.

Last summer, we decided that it was time to bring six years of work regarding runtimes for parallel languages to the Arduino, a popular open platform for exploring the of art, electronics, and computing. In doing so, we decided that documentation would be critical in this effort. Documentation became a focus because we decided as a team that users matter. In designing and documenting Plumbing, we kept our focus on the students, artists, and makers who might do something amazing with our tools.

I think we’ve taken some substantial risks. Many people have contributed many thousands of hours of development time in our software (to say nothing of the years invested in occam-pi), and we will soon be releasing hardware as part of this effort as well. For me, the most substantial is the commitment to publishing our book, Plumbing for the Arduino, under a Creative Commons BY-SA license. That means that anyone can modify, distribute, and sell our work, as long as you give us credit.

Giving our book away is substantial because publishing is part of how academics are evaluated and keep their jobs. By giving away our book, we must now convince our respective institutions that publishing under the Creative Commons will force us to produce a better product (on an ongoing basis) than editorial review would, as well as reach more readers than if we found a publisher (who would then claim copyright over our creation). Or, we must find a publisher who is interested in helping develop and market our text while allowing it to continue to be available under a free and open license. (If you know one, please have them drop me a note to me at matt at concurrency dot cc.)

concurrency.cc and the materials made available from that site have been in development for years. I’m glad to finally see everything settling in place so people can easily download and explore the tools we have spent so many years working on. If you do, let me know how things go. (We’ll have mailing lists up soon, I promise… but for now my job as a professor calls, and it’s going to be a busy few days…)

Thanks to Dave Humphrey, GDK, and the rest of the POSSE crew. For months the encouragement to just release! has been kicking around my head. That message helped keep us on track as we reworked build systems, wrote text, built websites, and generally did all that stuff that no one thinks about when bringing a project together.

And we’ll get a Fedora RPM done as soon as we can. (In the meantime, you can build from source like the rest of us.)

I gave an introduction in Technology and Activism the other day to the Creative Commons. In that introduction, we (briefly) explored two thought problems:

[ music ] How long until you can own every song ever written? My first question had to do with music. If $60 buys a 500GB hard drive, you can put one year of non-repeating music on it. (I’m using the song Seasons of Love from the musical Rent to drive my calculation regarding the number of minutes in a year.) How long until hard drives can casually/affordably hold all music ever recorded? I put it to the students that they will likely see that day come within the next 10 years, at which point the way we consume music will certainly change.

The second though problem is much more interesting to me, however.

[ textbooks ] How much do you spend per semester on books? A quick poll of the class showed that the majority of the students spend between $250 and $300 per semester. Lets look at this picture:

201001280707.jpg

A publisher gives me a book for free. I like it. I assign it to all of my students. They then buy it, sometimes paying $120 or more for a single text (Physics, Math, Psychology, Biology, Chemistry, Computer Science… we all have runaway textbook prices that are crushing our students.) They send $300 every semester to the publishers. It is simple to see why publishers want DRM: they don’t want kill the cow that lays geese that lay golden eggs.

At a college of 2000 students, that means students are spending

$1,200,000

per semester on books. The college has no direct control over this cost, and there is no incentive for faculty to keep costs low for the students. I managed to offer both of my courses this semester using only Creative Commons licensed texts… but there aren’t a lot of those I can choose from.

The thought game became this: why haven’t small colleges come together and established a free press? They could hire an editor or two, some typesetters and indexers, and then commission books and short monographs and release them into the Creative Commons. Authors taking part could be rewarded better than any publisher could ever pay for this kind of material, and the impact on the educational world would be huge.

the ipad arrives

201001280716.jpg

The iPad isn’t a revolutionary game-changer, but no doubt Apple did some things right with its design. It does web and video well, and it is possible to pay on a month-by-month basis for connectivity to 3G networks. (Nice if you’re going on a trip and just want roaming wireless for a month.) And while $500 sounds expensive, think about it this way:

$500 is $50/semester for device and insurance.

If an institution commits to ebooks—meaning, all the faculty agree that they will commit to finding electronic texts to teach their subjects—we can slash student book fees drastically. We raise the floor, meaning they have a mandatory $50/semester technology fee. However, we then have 2000 students with a wireless slate that can display video, play audio, surf the web (campus WiFi), display PDF, Google Docs, read email… the list goes on and on. To me, it seems like a very compelling vision.

In terms of the device, I don’t really care if it is the Apple iPad or not. If Steve wants to send me one to use and evaluate, he’s welcome to. I’m a Mac owner, have a Touch, and think this could be an excellent device. But I also know that Mary Lou Jensen has developed some incredible technology at Pixel Qi, and an Android- or Linux-based device could do everything I’m suggesting just as well. So, put simply, it is currently an exciting time for devices that are bridging the gap from laptop to slate.

In the preface to The Art of Computer Programming (1969), Knuth wrote the following:

100103-knuth-preface.png

I would posit that the vast majority of students who complete an introduction to Computer Science (often heavily focused on introducing the practice of programming) would not say that they felt they had been exposed to an aesthetic experience much like composing poetry or music.

This next term, I hope to work on developing a new course at Allegheny titled (tentatively) Digital Creativity. This course could serve as a pre-intro to the major, or introduce non-majors to the beauty of programming and computing, providing a collaborative, cross-disciplinary, and creative grounding in computational thinking using tangible, physical artifacts that students can relate to directly.

Omer passed on this picture:

P1000065.JPG

That is a concurrency.cc Arduino-compatible board fired up and ready to go. As you can see, the vias aren’t really lined up that well, which may account for some intermittent USB-to-serial weirdness that he is chasing down at the moment.

Awesome job, Omer! If all goes well, I think we’ll have around 40 to 50 students at Allegheny building their own computers next semester in courses I’m teaching or co-teaching, another handful at Kent, and who knows… perhaps I’ll find another place to bring these into my students’ experience next term.

I remain hopeful that our final boards will be purple, and that the ability to expressly direct parallel code for an affordable embedded platform like the Arduino will be of use to many. One step at a time, though: we need to get revisions done on our existing book chapters, write the next five we have outlined, get Windows and Linux distributions done… it seems like a lot, but we’ll get there.

I’ll have to write a longer reflection at some point, but the long and short is that I’m very excited to see our project coming together on multiple fronts for distribution: robust software, source-to-binary builds, hardware that showcases our tools, and a text that provides structure and guidance for non-programmers to get into hardware exploration one small step at a time. When you start a project like this, you want all of these things from the start… but sometimes, it takes lots of small steps, side explorations, and unsure starts to get you to where you want to go.

For years, my colleagues and I have been working on lightweight runtimes for parallel languages. To put our work in context, we’ve often targeted small robotics platforms like the LEGO Mindstorms for demonstrating the power of a parallel-safe language for real-time systems. This summer, we realized that the Arduino was a marvelous, open-source platform with an energetic community of developers and users, so we ported our language and tools to the Atmega328.

We have a Mac environment done, are working on Windows, and will have a Linux release by January. This, however, is quite exciting:

concurrencycc-prototype0.JPG

Omer (Vimeo, Twitter), a PhD student at the University of Kent and our resident hardware guru, did a modified Arduino design that includes more LEDs (along with a few other nice changes, like a mini-USB connector and a lower-profile power jack that will easily work with LiPoly batteries). The extra LEDs are important, because we wanted a board that made it easy to demonstrate the power of a parallel runtime right from the start without any additional/external components.

I’m especially excited about being able to buy these in bulk and sell them to students at cost for use in classes. Next semester, students in Programming Languages as well as my second-semester first-year seminar titled “Technology and Activism” will build and program their own computers. It will be awesome.

We currently have placeholder material up at concurrency.cc, but soon we’ll have binaries of all of the tools and documentation up that let you start writing parallel programs for your Arduino!

Operation: Stick Figure Army is a project that will provide tools for converting 2D imagery (as typically found in many introductory computing texts) into 2.5D representations: physical tiles with raised and textured surfaces that represent one or more diagrams from a text. This lets us explore, as a group, image processing, 3D printing, and the process of creating usable software for a target class of user.

The project is being carried out by two students at Allegheny and one student at TCNJ. Sara and Stephanie (Allegheny) have spent this semester learning Python and basics of image manipulation, recently posted their experiences while exploring Blender’s Python API (so we can automate the process of 3D object generation), and are beginning construction of their Cupcake CNC 3D printer. Cory (TCNJ) has also begun looking at Python, and is (at the moment) providing critical reflections on what it is like to be a blind student of computing.

His most recent post on the project blog, How to cope with the design phase?, explores the notion of visual representations in computing. I found his reflections interesting for two reasons. First, it reminded me of a paper by Marian Petre and Alan Blackwell titled Mental Imagery in Program Design and Visual Programming (PDF) (International Journal of Human-Computer Studies, 1999 (51) p7-30). They explore the role of visualization and visual language in expert programmers, and while the paper is too rich to summarize concisely, I’ll pull most of a paragraph from the conclusion here:

There has been a great deal of confusion in the visual languages community about the relationship between mental representations of a design and the programming notation. As noted by Green, Petre & Bellamy (1991), the superlativist position (claiming that visual languages always improve performance in programming tasks) is not justified by experimental evidence. Blackwell (1996a) has analysed the variety of beliefs among visual language researchers about the cognitive effects of using different notations. These tend to range far beyond the practical benefits of the notation or the programming paradigm, but their statements about mental representations bear little resemblance to our findings in the present studies.

Put simply, we tend to get all hot and bothered about visual tools, but research doesn’t imply that this is always a Good Thing.
The second aspect of Cory’s post that I thought was important to reflect back was the importance of verbal communication in software design and development. Whether it is aural or written, being able to express ideas about the design and implementation of software is critical to students of computing today. In some circles, this comes out in the context effective communication and collaboration in teams (Begel/Simon, Struggles of new college graduates in their first software development job (PDF), ACM SIGCSE 2008). Regardless of whether it is a software team at Microsoft or a distributed, community-driven effort surrounding open source software, the overwhelming majority of our communication and collaboration regarding software developing is written/verbal, not visual. That is, we’re not shipping pictures back-and-forth 24/7—we’re chatting on mailing lists, IRC, and blogs to get things done.
I think these ideas say a lot about where we are failing in terms of computing education today, but that will have to be the subject of another post. For now, I found Cory’s words thought-provoking, and wanted to reflect a little bit on what he had to say.

200910121702.jpg

How is a research group at a small, liberal arts college born? I think you get some students working on related things, and declare them a group. That, and have them over for dinner at least once.

Background (not so important)

My current research focuses on the behavior of novice programmers and the development of tools for parallel programming on small embedded systems. Long term, I am interested in the usability of programming languages—which lies at the intersection of my current lines of research inquiry.  

One reason I take a long view on my research because I am at the start of my career. Another is that I am committed to involving students at Allegheny College with diverse backgrounds in my research. For these reasons, I paint my research with a broad brush to better support more students with more interests. In doing so, I can productively move my research forward regardless of what interests my students might have in any given year. It also makes it easier to collaborate across disciplinary boundaries when you keep an open mind regarding where your work can be applied.

The Students (very important)

This semester, I am excited to be working with four students. Stephanie Cost and Sara Doan (both Allegheny ’11) have been learning the foundations of image manipulation using Python, with an eye towards image analysis and transformation. Their work is funded by the Collaborative Research Experiences for Undergraduates programme, and is titled Operation: Stick Figure Army. Their project explores the problem of transforming 2D images into 3D models suitable for printing on the Makerbot Cupcake CNC 3D printer (project overview). The goal is to produce an open source set of tools for supporting blind readers—images are the bane of a blind student’s existence, as they translate poorly using existing printing technologies. Our hope is that low-cost, personal fabrication technologies like the Cupcake CNC (along with usable, open software tools) will create new opportunities for blind readers in this space. Both Sara and Stephanie are doing excellent work, and I’m excited to have the entire year (both semesters plus the summer) to work with them on this project.

Although this is our Fall Break, I spent two hours today catching up with Radu Creanga (Allegheny ’11), who is helping our distributed group bring parallel programming to the Arduino platform. Using the occam-pi programming language and executing on the Transterpreter virtual machine, Radu has quickly learned the joys of checking out an open source project, cross-compiling it from source, and doing hardware-level additions to our library for safe, process-based parallel programming called Plumbing. You can follow his work online (project overview, more posts coming soon), and both his software and documentation will be part of our pending release at concurrency.cc.

Last, but not least, Drew Pirrone-Brusse (Allegheny ’10) is working on Verbing Stories. Drew is pursuing a self-designed major at the intersection of Communication Arts and Computer Science, and this semester we are exploring Kodu (and, time permitting, Scratch) as platforms for interactive storyboarding in the context of game design and creation. While Kodu is not an open platform, we hope that our work will provide inspiration for others interested in the use of novice programming environments for interactively exploring the role of story in game development.

In later posts, I’ll point out where some of our infrastructure (repositories, etc.) live. In the meantime, I wanted to introduce the exciting projects that these students are engaged in. If you’re so inclined, you can also follow their work at planet.baseplate.org; for lack of a better name, we’ve named ourselves the Open Group @ Allegheny College, because we’re open to working with students on a wide range of projects, and we strive to make our work open source wherever and whenever possible.

Blogs: Stephanie/Sara (Operation: Stick Figure Army), Radu (Plumbing for the Arduino), Drew (Verbing Stories)

Planet: planet.baseplate.org