Sub Ubi

Last semester, I introduced my students to structured data (including how to traverse self-referential structures), transitioned into classes and objects, and the basics of constructing GUIs in the object-oriented paradigm. A number of them mastered Model-View-Controller in this transition. This isn’t entirely remarkable—it’s actually a simple pattern, when the language itself doesn’t get in the way.

A Java program that produces this:

Comes from code that looks like this:

Of course, the output from the Scheme version looks the same:

But the difference is in the amount of code the student has to write:

What do I like about this?

• There’s less preamble (#lang scheme/gui vs multiple imports).
• The syntax is consistent with what has come before in the student’s experience.
• There aren’t any mystery calls (frame.pack()?).
• new is analogous to make-, which students have seen many times before.
• Callback functions follow naturally from previous work; event handlers are confusing.

I could probably make the list go on and on. At some point, I have to spend more time with JavaME, as it has a much simpler GUI model. And, given that the vast majority of the computers—those would be mobile phones—run JavaME (and not the full Java stack), it would be good to ask around and find out whether we’ll ever see a native version of BlueJ for programming against the ME classes.

Or, it could just be I prefer introducing students to simple languages, and then moving them on to more complex languages as necessary. But this is an old and tired rant, at best.

I will probably end up writing about this again.

Java textbooks are painful things.

I did a quick survey of a number of popular titles in the introductory Java textbook space. I considered the title “popular” if I had seen it on the shelves at SIGCSE on a consistent basis over the last several years. By-and-large, there are a lot of textbooks I consider crap, and I consider them crap for a variety of reasons. Sometimes it is because the writing is dry and unappealing to me (let alone a novice). Sometimes it is because the book does a horrific job of structuring/pacing material. Generally, I consider them all too expensive.

I threw together twelve books and ran some numbers on them:

The numbers to the right of each blob are the number of pages a student would have to read in order to get through the entire textbook in a 13-week semester. (I’m counting a week as lost to startup, and there is time lost to exams and the like as well.) The most expensive, and largest texts come in at over $120 and 1500 pages; this implies that students will read 120 pages per week while working exercises. Of course, no first-year computing student is going to read 120 pages of a mind-numbing textbook and do homework besides… not for just one of their four courses.

The smallest and cheapest text is not actually a CS textbook; at $10 and roughly 200 pages we have The Magus of Java, which has nothing to do with learning to program, but looks kinda neat. It is likely many introductory students would learn more from it than from the 1500-page beast at the other end of the spectrum…

The book in red is Objects First with Java. I’ve taught with it before, and as can be seen, it prices out well; it is expensive at $75 or so, but isn’t too large…. the student has less reading to do (per week) than many other books in that price range. That, and I’ve taught with the text more than once, and consider it to be a quality piece of work. In green is Java Programming for the Absolute Beginner, which has some reviews that make me think it would be a horrible choice for novices. The author would probably disagree, but the comments on that text set off warning bells.

I tend to agree with many of the philosophies of Allen Downey (whom I’ve had the pleasure of working with this past year) with respect to textbooks. He has published How To Think Like a Computer Scientist as a freely available text. What I particularly like is that he strives to keep each chapter short, so that a teacher can reasonably expect that students might read the material. It may be that I’ll have to write my own text this coming semester, focusing on basic mastery of syntax as well as concepts, utilizing both repetition (for mastery) as well as more open-ended problems (to encourage creativity and collaboration), all while keeping each chapter/learning unit as short as possible (for digestability).

We’ll see what happens; for now, this is just a long-winded rant-ish. But it is a problem/question/situation I need to deal with over the course of the next month.

Michael opens up on ICT education in the UK in PC Pro:

It’s like giving children a calculator but never explaining the underlying principles of multiplication. “Teaching children office-automation skills borders on child abuse,” says Dr Michael Kölling, the University of Kent academic, who’s attempting to get the Greenfoot software we’re using for our tutorial into schools across the country. “The main problem for us is they call it computing. Kids think that’s computer science. It isn’t productive, it doesn’t stimulate interest. Children should be creative, they should get the joy and satisfaction that comes from seeing their ideas take shape.”

His point is that Greenfoot is a much more engaging environment for students to be programming in then, say, doing spreadsheets in Excel. He’s right: forcing 13-year-old students to learn Excel macros is a form of child abuse.

Continuing on from my previous post, I continue to wonder about conversational (or dialogic) forms of course evaluation. A cursory search of a few online databases doesn’t yield anything in this area, which means a more serious, systematic literature search is required. While it is true I’ve never seen anyone take a conversational approach to course evaluation, that doesn’t mean that it hasn’t been done or investigated.

Some papers I’d like to investigate, however:

• A Longitudinal Study of Student Feedback: Self-Assessment, Course Evaluation and Teacher Evaluation
• Evidence for a Student-Centered Course Evaluation Form
• A Student-Centered Course Evaluation Form (same authors as previous)
• From Feedback to Reciprocity
• Student centered evaluation (webpage)

What is interesting was how enriching and valuable a conversational approach to course evaluation turned out to be. And, after receiving the college-issued anonymous course evals, I cannot even begin to imagine how I could evolve and refine my course based on the (blunt) instrument they employ. As I investigate these ideas further, I’ll make note of them on this blag.

When my younger brother was… younger, he once stuck a pussy willow bud up his nose. I mean, he didn’t just sorta stick the thing in his nose… he crammed it up deep somewhere in his nasal cavity. I’m surprised he didn’t loose the finger to the finger-biting monster that Shel Silverstein claims lives up there.

Inside everybody’s nose
There lives a sharp-toothed snail.
So if you stick your finger in,
He may bite off your nail.
Stick it farther up inside,
And he may bite your ring off.
Stick it all the way, and he
May bite the whole darn thing off.
(Shel Silverstein, Where the Sidewalk Ends)

Alas, no such biting happened. I do remember him screaming like the end was coming, however, when four adults held him down (one to each arm, one to his legs, and one to his head) while someone gingerly reached up and extracted the pussy willow with a pair of tweezers.

I figure he was around three years old. I would have been seven.

Good times, good times…

Of Pussy willows and Subversion

You see, this comes to mind because my students are using Subversion repositories for all of their coursework. They check things in, I check them out, and comment on their work. I then do a checkin, and they can read my comments right in their code. There’s no complex web-based system, no complex emailing of documents back-and-forth. It works reasonably well, I think.

Now, what should go in a repository? This is a reasonably tricky question.

1. Code. When you’re working on programs, the source code goes in the repository.
2. Documentation. Documentation (preferably written in plain text or LaTeX) should be in the repository. If you’re keen on using closed, proprietary tools, then Word Documents might end up in the repository.
3. Required blobs. A “blob” is a binary document. JPEG images are binary. PDFs are binary in nature. It is a “required” blob if something else needs it to be generated (like a LaTeX document that has an image in it; the PNG or JPEG should be included in the repos).

That’s about it. That still isn’t very specific, so I’ll itemize one or two things that might not go in the repository, and why.

1. PDFs. Generally, PDFs do not belong in the repository. That is, if you found an article that both you and your colleague are collaborating on, the repository is not where the PDF belongs. Why? Because the PDF is never going to change. You should just use a networked drive for this kind of “static” or “unchanging” data.
2. Executables. Programs that you need as part of the process of building or manipulating your software should not, generally speaking, be part of the repository. If you have an EXE that, say, processes one of your files… it should also be in a shared drive. While it might be necessary, it (like the PDFs) will never change. Therefore, you should put it on a shared drive, and let people copy it from there.
3. (By-)Products of a build process. Many programming environments generate many temporary files while building a piece of software. These temporary files that are generated in-between your source and executing on hardware should not be part of the repository. Only the source documents (the C files, and any project configuration files that are part of the IDE) should be in the repos. Temporary log files generated by the compiler should not be in the repos.

In short, only the files that you edit go in the repository. Any files that a program generates should not be in the repository.

Why?

Because your repository grows every time a file changes. If you store big, binary files (like executables produced by a compiler) in your repository, then every time you compile your program, the repos thinks a critical file has changed. In truth, we only want the source code to be tracked… not the output from the compiler. We especially don’t want the log files from the compiler checked in. We simply don’t care how those change from one commit to another, and our colleagues generally don’t care, either.

Now, like all things, there are times when these rules might be violated. For example, I asked my students to put a PDF of their report in the repository. This is because I didn’t want to deal with Microsoft Word documents. I’ll mark things directly into a copy of the PDFs. That is preferable, given the workflow that we’re dealing with, and the fact that some students are using Word, and some are using LaTeX. (I should just require TeX.) So, that “rule” about “no PDFs” was violated for a very specific reason. Likewise, I put PDFs in the class repository so they can easily read and print the documentation on whatever machine they are sitting at… not because it is the “right” thing to do.

So, what goes in your repository? Probably not pussy willow buds.

I really have to say, version control can be a wonderful thing in the classroom context.

I’m 1/3rd of the way through marking my student’s homeworks. However, I didn’t struggle with some handin system, or having them send me email, or anything like that.

You see, every student has a repository.

They do their work, commit it into their repository, and when they’re done, they just walk away (after their final commit). This means that their HW is backed up from their laptop, and it is sitting safely on a remote server.

It also means that I can check out their repository. So, before I did the grading, I did an ‘update’ on each of their repositories, so I got the most recent version of their code. To make comments in their files, I used block comments:

#| 20070909 MCJ
... some comment here
|#

and then created a text file in their repos with any additional comments.

Now, they don’t all have commit lists, so they don’t automatically get an email when I’m done. In the future, I may set that up. Not today, though. I manually send each one an email to say I’m done, and they can do an ‘update’ to get the most recent changes.

All-in-all, it’s a great workflow. I can improve it in a few different ways, but overall, it’s efficient for me, they’re getting good practice using a repository as part of their programming practice, and it provides a good, hard-to-loose communications channel regarding their feedback.

I think it’s awesome, even if no one else does.

Poul and I are beating on our ITiCSE paper, which is due on the 15th at 5PM… in Hawaii.

What does that mean?

It means… it’s due Tuesday!

Peter, a friend from my time at IUB (and author of the most excellent Data Structures and Algorithms in Java, plug-plug), will be teaching his department’s CS0 next term. He was curious about the NXT, and more generally, about teaching with the LEGO Mindstorms. Here’s the email I sent back his way, with small edits.

The LEGO route is the path of mavericks and people who like to yell loud, incoherent things while leaping off high surfaces. There are not, I do not believe, a lot of materials pre-packaged to get you rolling. I haven’t looked lately, however. (I have a bunch of stuff, but it isn’t polished. It might even be rough around the edges.)

That said, there are a number of tools out there that you can reach for that have a lower startup cost, where “cost” isn’t measured in $, but instead in time/effort (by far, the more important metric).

1. Python/Alice

   Alice is a programming environment that I’ve not worked with much, but it provides an OO/actor-based approach to programming that lets students do experiments in a 3D world with all kinds of nifty objects. There’s a book available from Prentice Hall, which may make it appealing.

   I forget if Alice uses it’s own bogolanguage, or if it uses Python.

   http://www.alice.org/

   1b. Having just seen the Alice site, you could probably build a course around scripting within a game environment. For example, you could probably equip them all with The Sims, and teach them about programming through scripting the Sims universe. This, probably, involves few transferable skills, and lots of students letting their Sims burn to death in bitterness over the assignment you gave them last week.

2. NetLogo

   Another “simulation” environment, this exposes students to modelling (again) from an agent-based perspective. They work in a dialect of LOGO, and write the code for one agent (be it a turtle, or a person, sheep, whatever), and can easily release thousands of them into the world. I do not believe there is a supporting text, per se, but you’ll find a good deal of supporting material available from the website.

   http://ccl.northwestern.edu/netlogo/

3. Greenfoot

   Like NetLogo, but a bit more freeform, and in Java. I don’t know if it will be ready for primetime by next semester. From the creators of BlueJ, and as it turns out, my housemate. It should/will be cool, and personally, I look forward to teaching with it.

   http://www.greenfoot.org/

4. Scheme

   Just teach them Scheme. Oh, wait, sorry, I thought I was someone else for a moment…

   Then again, the second hit in a Google search for “CS0″ is this link:

   http://www.cs.brandeis.edu/~tim/Papers/sigcse-cs0.pdf

5. Squeak/Media computing

   You might look at the work Mark Guzdial is doing at Georgia Tech. I’m not sure if the media computing approach is too much or not, but I’ve heard him talk about it in the context of both CS0 and CS1.

   http://www.gvu.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html

   http://www.squeak.org/

6. You can search in the ACM DL for “CS0″, and get back oodles of hits. Pick and choose based on what looks interesting. I recommend most papers by “Jadud, M.”, as his writing is typically brilliant, witty, and self-aggrandizing.

---

I know I started off by suggesting that the LEGO route isn’t easy, but I think that’s true. However, it depends on how you sell it to the students, and whether you’re prepared for things to go wrong from time-to-time. If you treat it as an experiment, have a clear direction/goal (I can help with brainstorming based on previous experience there), and your department is cool with the experiment, you probably can’t go wrong. Or, put another way, the worst you can do is engage in an educational experiment with your students, and *all* of you will learn something along the way.

Hm. That didn’t sound very supportive/positive either. I guess my point is that you have to be prepared to let go. I wrote a bunch of stuff under the rubrick of “TeamStorms” a few years ago. It captures a lot of how I approached/felt/thought about teaching with the LEGO Mindstorms in the classroom. You might check that out.

http://www.jadud.com/people/mcj/files/2000-SMC-teamstorms.pdf

http://www.jadud.com/people/mcj/files/1999-R626-teamstorms.pdf

The first is a “short version,” which I presented at SMC2000 (they must let anyone in). The second is the R626 paper it was distilled from. I don’t claim either is great, but they were written at the time I was actively teaching A290 at IUB, and reflect my thoughts at the time.

That’s some material to kick you off, anyway.

It is frustrating watching all the Lego Mindstorms Developer Program weblogs. Many of them appear to be people who were randomly chosen to be in the program, and are now (apparently) maintaining weblogs about the robots they’re building.

So, I’ve realized that I could, after all, put my weblog to good use: I could write about some of the things I know, and are appropriate to the blog’s title. One is how students engage in the act of programming—I’ve written very little about my dissertation work over the past few years, and I might as well start serializing my research, results, and ideas out into this space. Certainly, it is a rare and hardy soul who would want to read my dissertation.

Likewise, I have spent years teaching with the LEGO Mindstorms in the classroom. I designed and taught my own course in the CS department at Indiana University Bloomington, and have continued using LEGO in my workings with students at the University of Kent in Canterbury, England. I’ve even helped write a massively concurrent runtime for the LEGO Mindstorms, and have been a judge at two First LEGO League competitions now, but never mind that we weren’t selected to be part of the developer program. I’m not bitter. Much.

…

So. Purpose. Direction. These are good things. And it will help keep me from blathering on about things that don’t matter in this space. Like, um, Peeps. Erhm… yeah.

(Actually, Peep research seems pretty important. But I’ll let that go for now.)

If I want to write about CS education and concurrency, I can write about it on the Transterpreter weblog.

If I want to write about things happening in the CS world “at large,” I can use the Untyping weblog.

Now, when I want to write about cool things in Greenfoot, I can use On Walkabout with Greenfoot.

I still dream of turning CS-ED.org into a collaborative, group weblog written by CS Educators.

The truth is, I actually like having these obvious contexts for writing; whether anyone reads these things is another matter entirely. However, I enjoy my work on the Transterpreter, and having a place to put that content (that makes sense) is great. Likewise, I’m very excited about On Walkabout; I think it’s a great way to explore a new piece of software, and perhaps come up with some good material for teaching and learning besides. And who knows—perhaps I can still make CS-ED.org work.

Eh, we’ll see. I was, in some ways, wondering if I wanted to let this weblog go. Then again, perhaps I shouldn’t; we’ll see. If nothing else, this is a roundabout way to encourage people who are interested in teaching, microworlds, and Java, to start reading Walkabout. And for everyone else, if you wonder where the words are going, it’s just that they’re usually not going here.