Knowing and Doing

I went to this blog post by Jordan Ellenberg for the baseball (well, that's not quite true — I read all his posts) and left feeling a kinship with him in this regard:

Wikipedia is really an incredible triumph of human cooperation. Why does it work so well? How is it so unpolluted? How is it that when some very weird niche question like "which pitchers have beaten all 30 teams?" comes to my mind, some human being has already compiled this and put it there? I don’t know. But I'm glad it exists.

I remember back when Wikipedia first began, how so many people were convinced that it could not work. Having been active on Ward Cunningham's C2 wiki in the 1990s, I knew that it could, but I wasn't sure how the idea would scale to include anyone and everyone with net access.

I grew up reading the encyclopedias on the basement shelves in our family home, trying to soak up everything under the sun. How could a collaboratively built website with no authoritative gatekeeper match those volumes?

Nearly twenty-five years later, I can say that Wikipedia has succeeded beyond my imagination. Sure, it faces challenges with some contentious topics. However, for almost anything I might want to learn something about — even weird niche questions like "Which pitchers have beaten all 30 teams?" — I usually count on Wikipedia for an answer. People love to build and share knowledge.

This passage from an interview with Lesley Carhart was a shot in the arm I needed:

You've spoken about the risk of younger generations relying too heavily on tools and AI without learning the basics. Are you worried we're losing critical knowledge?

I struggle sometimes with how to convey this without sounding like the "old person" in the room. But there really is a problem. Since I started in this field, universities everywhere have launched cybersecurity degrees, and many of them are fundamentally flawed because they don't teach the foundations of computing.

We now have a generation that hasn't been exposed to the inner workings of computers. Everything is point-and-click, tablets, and touchscreens, so they don't learn at home how computers actually work. Then they enroll in cybersecurity programs, but those programs also don't teach fundamentals. Instead, they teach how to use tools—EDR, Metasploit, whatever's current. And tools change constantly. In cybersecurity, tools and techniques are outdated within a few years. Without foundations, students can't adapt, and they can't work with legacy systems. That's a big problem.

I am not a specialist in cybersecurity, so it's heartening for me to hear someone with Carhart's experience and expertise say this about cybersecurity curriculum.

My department has offered a degree program called Networking and System Administration (NaSA) for over twenty years. With the rapid growth of cybersecurity programs at community colleges, and increasing interest from high school students, there is a strong desire among admissions staff and upper administrators for us to offer a cybersecurity program. The NaSA major has long taught some of the essential skills of cybersecurity, so we are evolving it to focus more directly on cybersecurity.

However, our program will continue to teach the fundamentals that Carhart says are important. It will have a small intro CS core, plus standard courses in operating systems and networks — and statistics, knowledge of which is essential for studying system behavior and machine learning.

This focus on fundamentals creates challenges. It's hard to make room for all the tools and techniques that students need to know now. But, as Carhart says, many of those tools and techniques will be outdated within a few years. We are preparing students for long careers, and to be contributors and citizens in a complex social world. Even if we approach the task from a purely technological perspective, though, without foundations, students would struggle to adapt to the changes we know are coming.

A foundations-centered program also creates practical challenges in the world of university admissions, because it makes it harder for community college students to parlay their CC degrees into immediate university credits. That's a big deal in a world where enrollment drives university budgets and CC students are a primary audience.

We're working on all of these challenges. We are slowly figuring things out. But it's encouraging to know that an expert such as Carhart appreciates the need for cybersecurity students to learn the foundations of computing. We think they are important, too.

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.