Knowing and Doing

From a Robin Sloan newsletter:

I wonder, finally, if one of the key markers of human-ness, and human intelligence, is: the experiment.

All of these activities are points on the same continuum:

• troubleshooting a car
• debugging a computer program
• devising a science experiment

In all those cases, there's a particular kind of creativity at work: engineering these lenses, these filters, these ... tweezers? to isolate new, reliable knowledge about the world.

Many people, including prospective CS majors and their parents, ask me what it takes to succeed in computer science. How will I know if computer science is right for me?

One of things I talk about is curiosity: a desire to figure out why something isn't working (or is), a desire to change a system to make it work in a desired way, a desire to learn new tools and techniques. Whatever other skills and attributes a person brings with them, the curiosity to tinker and experiment goes a long way in our discipline.

We have students with a lot of different career goals. This answer applies to all of them. Curiosity is part of the mindset of all CS majors whatever there role ends up being after they graduate: software developer, sysadmin, database administrator, someone working in cybersecurity...

I'm guessing physicist Chad Orzel might agree. He wrote Eureka, an entire book about how almost everyone, even someone who thinks they don't like science, is doing science all the time. A big part of that unspoken process is testing our mental models by comparing them to reality. For computer science students and grads, this mindset is front and center every day.

Summer orientation starts next week, so I'm getting into the mode of reviewing the backgrounds of incoming students and preparing to advise them. I imagine I'll be discussing curiosity and experiment in my conversations over the coming weeks with a few new majors who are excited to dive into CS this fall.

I am teaching compilers again this fall for the first time since 2022. After turning my grades for spring in last week, I started to feel the old buzz... How could I tell?

Everywhere I look I find ideas and images that trigger thoughts of the course.

I am starting to notice new languages that inspire the syntax for a source language my students might write a compiler for, such as Lil, the scripting language for Decker (a browser-based environment inspired by HyperCard).

I'm starting to notice ideas for integer-oriented programs to write in whatever source language we end up working with, such as Leyland numbers (x^y + y^x for integers x > 1 and y > 1) and left-truncatable primes (a number where you get a prime number no matter how many leading digits are omitted).

I'm starting to notice ideas that inspire my desire to create a fun and valuable experience for my students, such as Austin Henley's post on group projects.

That post introduced me to a great line from Russ Cox:

Software engineering is what happens to programming when you add time and other programmers.

I recently ran across Cox's wonderful article on regular expression matching again and stashed it away in my exuberance to improve the lexical analysis unit of my course.

Henley's post echoes one of my goals for the course:

... for students to have experience using "modern" tools in as "real world" of a setting that we can possibly emulate in a course, giving them a significant project for their portfolio.

I approach this goal from the perspective of a "compiler writing for everyone" course, a project course that appeals to and benefits undergrads with all sorts of career goals.

Doesn't this mean that my students will be reinventing the wheel? Maybe, but there are many good reasons to reinvent the wheel.

Did I mention that I currently have fifteen students enrolled in the course? Maybe the students are as excited to revive the course as I am.

This will be the first time I've taught the course since the explosion of LLMs in coding. What will I do with or about these new tools? What should I want my students to do?

I'll admit, this is a dark cloud on the horizon for me.

Fortunately, I'm also starting to notice articles other folks are writing about how they are incorporating the ubiquity of this new technology into their teaching. This slide deck from the Educational Summit at 2025 PyCon, for example, gave me a few ideas to consider.

There is much to do. Let the summer begin!

Matt Webb learned something when he ran a marathon last month:

What this says to me is that when you go to extremes, new things happen?

There are new experiences to be found, when you go past your limits, which aren't like the old ones scaled up. They're something distinct. Unanticipated and unanticipatable.

I don't know how to explain it better than that! It seems to me that this is true of so many things. The only way to know what it's like to run mile 22 is to run 21 miles first, you can't shortcut your way there.

The last sentence is so incisive that I almost paraphrased only it: "The only way to know what it's like to run mile 22 is to run 21 miles first. You can't shortcut your way there."

I remember that feeling as a runner, pushing past different limits. The one I remember most was fifteen miles. For some reason, the first time I ran mile 16, it was a completely new something for me. I seemed to revisit that barrier each time I tried to bump my speed up to a new level. Running mile 16 at the new pace was harder than any mile before it, or after. Even in my last couple of marathons [ 1 | 2 ], Mile 16 was the challenge that ultimately determined what my day was like. (*)

I'd love to have had one more chance to break on through to the other side...

A lot of CS students learn that there are new experiences waiting for them when they push past what they thought were their limits. One of my Programming Languages students took the time to tell me so last week.

On Friday, students submitted Part 3 of a three-part assignment in which they implemented an interpreter for a simple arithmetic language containing numbers, unary and binary operators, local variables, and blocks with assignment statements. They implemented abstract syntax, a preprocessor for the syntactic sugar, and an evaluator. To support variables and assignment statements, they implemented simple data structures for the environment and mutable cells.

This is the biggest program many of them have every written. To further the challenge, they were writing code in functional style using Racket, a language they had started learning only fifteen weeks prior.

One student included a comment block of several lines in his final project submission to tell me how much he had learned beyond the stated goals of the project and the course. It turns out that writing a much larger program is different than writing small programs for a class. Structure matters. Names matter. You have to revisit decisions, learn new language primitives, and change how you think about software. He hadn't expected to have these experiences at the start of the project.

Some experiences aren't like the old ones scaled up.

The only way to know what it's like to run mile 22 is to run 21 miles first.

~~~~~

The latter of those two posts has one of my all-time favorite blog post titles: "Because 26.3 Miles Would Be Crazy".