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".

Earlier this week, someone boosted Dan Vanderkam's After 20 Years, the Globally Optimal Boggle Board into my Mastodon feed. Thank you to whoever did. (*)

This article makes me happy. I have not played Boggle all that often, but it's a fun game, and I certainly understand the obsession. Vanderkam has spent a couple of decades studying a pet problem, applying any tool from CS that would help, including ideas from data structures, algorithms, and parallel computation, to finally answer the question that has been propelling him forward.

Even better, he has been blogging about his efforts all these years, keeping his readers informed of the fits and starts he faced along the way. I only wish I had discovered his blog sooner so that I could have been one those those readers sooner!

Even though I'm not much of a Boggle player, I love pretty much all such games. They are fun for personal diversion when I encounter them in the wild, and they make for great source material when teaching. Games like Boggle are great projects in an OO programming class, especially one that includes simple graphics. The technical elements of the author's project offer fun ways to introduce concepts and challenges in courses on data structures, algorithms, and classical AI.

The article also inspires me as a computer scientist. Now I want to go back to some work I did on progressive chess with a student a few years ago. Progressive chess is a variant in which players make increasing sequences of moves: White moves once, then Black moves twice, then White moves three times, etc. One would think that, as each player's turn gets longer, it would become increasingly easy to deliver checkmate. However, a player can also use their sequence of moves to weaken the opponent's forces and to defend their own king.

I have all kinds of questions about the game, including the first question researcher usually have about two-person adversarial games: Is there a forced win for either side? Techniques from state space search offer a starting point for trying to answer the question, but how much will they have to be adapted in order to the scale the depth and breadth of the search tree?

Reading Vanderkam's article has me wanting to revisit the topic. I'll also be reading some of his older posts to see what other lessons he learned along the way.

~~~~

(*) I really have to do a better job keeping track of where I get the articles I write about, so that I can properly thank the person responsible for me seeing them. That would be easier if I knew immediately which articles I want to write about — or if I kept track of the source of every link I set aside for later!

In the notes for my class Tuesday, I made a reference to Jean-Luc Picard, commander of the Enterprise in Star Trek: The Next Generation.

I described a function that I would like to have. "Make it so", says Picard from the flight deck.

Then it struck me. Star Trek: The Next Generation is nearly two decades older for my students than the original Star Trek was for me and my classmates.

Sigh.

My only hope for not sounding to my students like a dinosaur walking the Earth is that the Star Trek universe is still reasonably popular in American culture. Young people today may think of Paul Wesley or Chris Pine when they think Captain Kirk, rather than William Shatner (*), but if they think of Picard, they think of Patrick Stewart.

(*) the one true Kirk, with no disrespect to Messrs. Wesley or Pine

Time moves on.

I'm not the only one these days noticing the disjunction between how we perceive time and age. Daniel Steinberg reminisced in a recent essay about a job he held whe he was 24 years old:

One of my closest friends was an older woman named Rachel (actually it's funny, she was thirty years older than me but I'm now more than ten years older than she was then and I always thought of her a nice old lady).

Daniel and I are now the nice old people that twenty-somethings know and like today. Back then, I never considered what it would feel like when I was that age.

To be honest, now that I am that age, I feel pretty much the same as I did then. And I'm okay with that.

Zena Hitz, in Socratic Wisdom for a Lonely Age:

To be taken seriously is the quickest way to become serious. In my own teaching, I find no sight more splendid than the face of a student who has been taken seriously as a thinker for the first time.

+1 from this CS prof. Students are often itching to be thinkers but are not certain they can be. Maybe they spent their high school years frivolously; maybe they've always aspired to more but never found conditions in which they could take a serious step forward, doing something that matters to them.

It really is splendid to see the eyes of a student who has been taken seriously as a thinker for the first time, who realizes just then that they, too, can think serious thoughts.

One of the great joys of being a teacher is to constantly be in contact with people, young mostly, but of any age, ready to have this experience &mdash, whether they realize they it yet or not.

When writer Tom Wolfe died in 2018, The Paris Review republished excerpts of its 1991 interview with him. When the interviewer asked Is there any mnemonic device to get you going?, Wolfe gave a decidedly pragmatic answer:

I always have a clock in front of me. Sometimes, if things are going badly, I will force myself to write a page in a half an hour. I find that can be done. I find that what I write when I force myself is generally just as good as what I write when I'm feeling inspired. It's mainly a matter of forcing yourself to write. There's a marvelous essay that Sinclair Lewis wrote on how to write. He said most writers don't understand that the process begins by actually sitting down.

Or standing up. But you do whatever it is you do to start writing.

A lot of folks are using LLMs to help them write code these days. David Chisnall, for one, is unimpressed. He has, however, found LLMs "vaguely useful" in one way while programming, a way that made me smile:

The one place Copilot was vaguely useful was hinting at missing abstractions (if it can autocomplete big chunks then my APIs required too much boilerplate and needed better abstractions).

I love it! An LLM identifies a missing abstraction by showing where it needs to be. It does that by writing the sort of code that the abstraction should hide away.

This makes me think about the role of negative space in software design, from one of the early posts on this blog. LLMs generate the code we can see when we look head-on at a problem we understand well. If we instead turn the problem upside down, or inside out, we may have a better view of the code we really need. The LLM's code points to that new view.

Following Chisnall's idea, we might set out to create abstractions until the LLM can't auto-fill our code for us. How is this for an LLM-driven design algorithm of sorts:

1. design a program
2. while (an LLM can fill in substantial boilerplate)
   1. create a new abstraction
   2. revise the program

Personally, I'm still not all that excited about using LLMs to help me write code. I like to write code, and need more opportunities to do so, not fewer. But if I decide to give them more of a try, I might well use this approach. It tickles my curiosity enough to make the outcome of real interest.

3⁵ · 1482 · 9760 = 3514829760

This is known as a printer's error. If the typesetter misses the superscripts in a printer's error, the value printed is still correct.

This page lists all kinds of printer's errors, including generalizations across bases, shifting digits, and the like. Much fun.

Hat tip to Futility Closet, which I am happy to have active again in my newsreader after a one-year hiatus back in 2022-2023.

Someone on Mastodon posted a link to They see your photos. According to the site, Your photos reveal a lot of private information. To demonstrate this, the author uses the Google Vision API to describe the content of any photo you upload.

I was curious. I uploaded the professional headshot I use on my relatively new home page (*). There doesn't seem to be any negative implication in using this photo for an experiment, as it is already out on the public web and available for anyone, or any program, to see.

Here's the image:

What do you see when you look at that image? Here's what Google Vision had to say:

The image shows a headshot of a person against a plain white background. The foreground is dominated by the individual, who is the clear focal point. The background is simple and uncluttered, drawing all attention to the subject. The overall setting appears to be a professional portrait studio or a similar controlled environment.

The person in the image is a middle-aged man with light skin, appearing to be of European descent. He wears glasses and a light blue polo shirt. He seems friendly and approachable, with a gentle smile. His expression suggests confidence and approachability. The image seems to be taken in the daytime judging by the lighting, likely for professional purposes such as a LinkedIn profile picture or corporate directory. The camera used appears to be a high-quality DSLR or professional-grade camera, considering the sharp focus and detail.

The slight greying at the temples of his hair and fine lines around his eyes subtly indicate his age and perhaps his professional experience. The simple yet neat background and his attire are consistent with someone who holds a professional position, suggesting a stable economic status and a mature, possibly traditional lifestyle. The image shows no additional objects or accessories, keeping the focus entirely on the person.

Wow. It is not wrong.

I would be happy for someone who sees that image, or who meets me in person, to think "He seems friendly and approachable, with a gentle smile. His expression suggests confidence and approachability." Friendly and approachable are certainly attributes I would like for others to see in me, both professionally and personally. I'd also like to project a humble confidence.

Is it wrong for me to feel flattered by the assessment of a piece of software? I can only hope that people see me the way Google's image processor says they might.

~~~~~

(*) I created this home page last summer while preparing for my second offering of our web development course. Four months old isn't particularly new, but it seems quite new when compared to the thirty-year run of my previous home page, which had changed only in dribbles over its lifetime.