Granite Wo-Mon 2016

:: granitemon

Hey, today was the day! The day of the annual swim from Long Island to the mouth of Blue Hill Harbor, the current incarnation of the Granite Wo-Mon Challenge.

Before the swim:

pre-swim

pre-swim

Thanks to Chris Guinness for this excellent shot.

After the swim:

post-swim

post-swim

Charlotte Clews posted this picture, although she’s in the picture so I suspect she didn’t hit the button. Was this Henry?

Low tide was at 8:47 AM today, so by rights we should have started the swim at about 11:00 AM, but no one wanted to wait quite that long. We gathered at the KYC at 9:00 (or 9:10… or 9:15) and headed out to Long Island. I think we managed to start swimming at about 10:00.

Let me just say: choppy. Not end-of-the-world choppy but still chopping pretty good. Which is to say: bad. I think we all swallowed quite a bit of seawater.

My strava log suggests that the swim took about 1:38, which is quite a bit more than last year.

A special thanks this year to Tricia Sawyer, who pretty much organized the event, and didn’t get to swim. (N.B.: “Organized” = “sent an email to the rest of the slackers”.) It wouldn’t have happened without you!

For those of you completely confused: Granite Wo-Mon Summary Page

So! The swimmers! (In alphabetical order. I love it because Clementses go first. Unless Sara starts swimming.)

  • Alice Clements
  • John Clements
  • Mary Clews
  • Amanda Herman
  • Charlotte Clews Lawther

Amazing chase boat crew and welcoming committee:

  • Sara Ardrey
  • Henry Becton
  • Jeannie Becton
  • Anika Clements
  • Kitty Clements
  • Tom Clements
  • Henry Clews
  • Hal Clews
  • Chris Guinness
  • Sean Guinness
  • Stephen Labrum
  • Jerome Lawther
  • Jenney Wilder
  • Eliza Wilmerding
  • Renee (last name ?)
  • Others?

Finally, I note with mild dismay the absence of any first-time swimmers. Maybe Lucas will swim next year?

The Many Uses of the AR–15

:: Guns

  • July 20, 2012 - Aurora, CO – 12 people dead - Smith & Wesson AR–151
  • December 14, 2012 - Sandy Hook elementary school, Newtown, CT – 20 people dead - Bushmaster AR–152
  • December 2, 2015 - San Bernardino, CA – 14 people dead - Smith & Wesson AR–153
  • June 12, 2016 - Orlando, FL – 49 people dead - Sig Sauer AR–154

time spent on CPE430, Spring 2016

:: CPE 430, Teaching

Earlier this year, I was talking to Kurt Mammen, who’s teaching 357, and he mentioned that he’d surveyed his students to see how much time they were putting into the course. I think that’s an excellent idea, so I did it too.

Specifically, I conducted a quick end-of-course survey in CPE 430, asking students to estimate the number of weekly hours they spent on the class, outside of lab and lecture.

Here are some pictures of the results. For students that specified a range, I simply took the mean of the endpoints of the range as their response.

Density of responses

Density of responses

Then, for those who will complain that a simple histogram is easier to read, a simple histogram of rounded-to-the-nearest-hour responses:

Histogram of responses

Histogram of responses

Finally, in an attempt to squish the results into something more accurately describable as a parameterizable normal curve, I plotted the density of the natural log of the responses. Here it is:

Density of logs of responses

Density of logs of responses

Sure enough, it looks much more normal, with no fat tail to the right. This may just be data hacking, of course. For what it’s worth, the mean of this curve is 2.13, with a standard deviation of 0.49.

(All graphs generated with Racket.)

things I already dislike about Python

:: Programming Languages, Teaching

I’m just getting started, but already Python is looking like a terrible teaching language, relative to Racket.

  • Testing framework involves hideous boilerplate.
  • Testing framework has standard problems with floating-point numbers.
  • Scoping was clearly designed by someone who’d never taken (or failed to pay attention in) a programming languages course.
  • The vile ‘return’ appears everywhere.

programs are not sequences of instructions

:: Programming Languages

Oh mainstream programmers, how I hate thee. Let me count the ways.

The following is a question taken from the “AP Computer Science Principles Course and Exam Description,” from the College Board:

  1. A programmer completes the user manual for a video game she has developed and realizes she has reversed the roles of goats and sheep throughout the text. Consider the programmer’s goal of changing all occurences of “goats” to “sheep” and all occurrences of “sheep” to “goats.” The programmer will use the fact that the word “foxes” does not appear anywhere in the original text.

Which of the following algorithms can be used to accomplish the programmer’s goal?

a)

  • First, change all occurrences of “goats” to “sheep.”
  • Then, charge all occurrences of “sheep” to “goats.”

b)

  • First, change all occurrences of “goats” to “sheep.”
  • Then, charge all occurrences of “sheep” to “goats.”
  • Last, charge all occurrences of “foxes” to “sheep.”

c)

  • First, change all occurrences of “goats” to “foxes.”
  • Then, charge all occurrences of “sheep” to “goats.”
  • Last, charge all occurrences of “foxes” to “sheep.”

d)

  • First, change all occurrences of “goats” to “foxes.”
  • Then, charge all occurrences of “foxes” to “sheep.”
  • Last, charge all occurrences of “sheep” to “goats.”

This question makes me angry. Why? Because the obvious lesson from this example is that YOU SHOULD NOT BE MODELING COMPUTATION AS A SEQUENCE OF MUTATIONS.

In other words, the correct answer is this:

e) For each word in the document, replace it using this function: * if the word is “goats”, return “sheep” * if the word is “sheep”, return “goats” * otherwise, return the word unchanged.

Voila. Problem solved. No resorting to nasty swap ideas.

At a lower level, I think the core problem may be the inability of the English language to handle this kind of abstraction. Notice that in my proposed solution (e), I tread dangerously close to mathematical notation; it’s not really purely English any more.

123 dramatically improves first-year retention

:: First-Year Data, Department Data

Okay, here’s a nice picture:

first-year retention pre- and post-change

first-year retention pre- and post-change

This compares the outcomes in the years 2005 through 2009, before we instituted 123, with the outcomes in the years since. This is a cumulative graph, showing for a number of classes how many students finished by taking that many classes or fewer, and whether they succeeded or failed. Success is defined as having gotten a grade of C- or better in 103 (that is, the condition that allows them to continue with higher-level classes in the major).

So, for instance, we see that in the years before 123 was added, more than 90% of students took four classes or fewer, and that about 38% of those students did not successfully finish. In the years after 123 was added, slightly less than 90% of students took four classes or fewer, and of those, only about 23% left without finishing.

The big picture here is the post-change years have a much lower dropout rate; our first-year retention has improved from 63% to 77%, a dramatic increase.

first-year outcomes by # of classes taken

:: First-Year Data, Department Data

Here’s a pair of pictures showing the distribution of # of classes taken in the first-year curriculum. There are only four classes, so this is really a picture of students repeating classes, and how many times they repeat them. So, for instance, we see that about 8% of students take exactly five courses (most likely repeating one), and that in this group, approximately 85% are then finished successfully.

first-year student outcomes

first-year student outcomes

This graph shows the cumulative distribution; it’s just the discrete integral of the prior picture.

cumulative first-year student outcomes

cumulative first-year student outcomes

Note that a lot of people come in with AP credit, and skip one or more classes, which is why we see a lot of people finished after one or two classes.

It’s also interesting how many people stop after one or two classes. You can look at that either as bad news or good, depending on whether you see these students as promising ones that we squandered, or students that quickly discovered that computer science was not for them.

Also note that since these pictures span 2005 to 2015, they cover the period from 2005–2010 when the course sequence was only three courses long. The obvious next step is to split these graphs into two graphs, to see whether the addition of 123 to the curriculum had a major effect.

All analysis done in racket, naturally.

All analysis code (though not the source data) available as part of this github repo.

First-year Animations

:: First-Year Data, Department Data

First, a disclaimer: I can’t imagine this will be interesting to anyone not at Cal Poly. I’m using these blog posts as a way of dumping a bunch of interesting-to-me graphs and visualizations of the behavior of students in our first-year sequence here at Cal Poly.

First, an animation:

path of students through the first year

Using racket and OpenGL, I generated movies showing individual students (each one represented as a blue square) moving through our first-year sequence. This data is based on information about grades earned by students in our courses from Winter 2005 through Winter 2016.

The four columns represent the courses in our first-year sequence: CPE 123, CPE 101, CPE 102, and CPE 103. Note that CPE 123 was not offered before Fall 2010.

Time is represented as time in the animation. That is, the first thing you’ll see is a bunch of students entering the program in 2005. The vertical placement of the dot represents the grade they got in the course (with some noise added to prevent all students from landing on top of each other).

Notice that the reduced size (480p) makes the animation run smoother. You can full-screen it to see it better. There’s also a higher-resolution version that I made, but it looks to me like it doesn’t actually convey any more information.

Finally, I really should figure out how to slap text on the screen as part of an OpenGL animation, so that I can label the thing.

Racket Sucks, Don’t Try It

:: Racket, Programming Languages

I’ve done a lot of programming in Racket. A lot. And people often ask me: “What do you think of Racket? Should I try it?”

The answer is simple: No. No, you should not.

You’re the kind of person who would do very badly with Racket. Here’s why:

  • All those parentheses! Good Lord, the language is swimming in parentheses. It’s not uncommon for a line to end with ten or twelve parentheses.

  • Almost no mutation! Idiomatic Racket code doesn’t set the values of variables in loops, and it doesn’t set the values of result variables in if branches, and you can’t declare variables without giving them values, and Racket programmers hardly ever use classes with mutable fields. There’s no return at all. It’s totally not like Java or C. It’s very strange and unsettling.

  • Library support. Yes, there are lots of libraries available for Racket, but there are many more in, say, Python. I think there are currently fifty-five thousand packages available for Python.

  • Racket is an experimental language: when the Racket team decides that the language should change, it does. Typed Racket is evolving rapidly, and even core Racket is getting fixes and new functionality every day.

  • Racket is not a popular language. You’re not going to be able to search for code snippets on line with anything like the success rate that you’d have for JavaScript or Python or Java.

  • Racket will ruin you for life as a Java developer. You will be agonizingly aware of how much boilerplate you’re cranking out, and after every hour of shoveling Java, you will sneak off to the bathroom and write a tiny beautiful macro that no one will ever be allowed to see or use.

If none of these succeed in scaring you off, well, then, go ahead and give it a try. Just remember: I warned you.