Vox Meditantis

This interview is a dramatised reconstruction based on historical sources, not a transcript of an actual conversation. Sister Mary Kenneth Keller died in 1985; this dialogue uses documented evidence about her life, work, and values to create a plausible conversation with a contemporary audience, presented with transparency about what is documented, inferred, and speculated.

Sister Mary Kenneth Keller, B.V.M. (1913–1985), was a Catholic nun and pioneering computer scientist who earned the first American Ph.D. in computer science in 1965, sharing that distinction with Irving C. Tang – a fact often overlooked in popular accounts that render her the “first woman” without mentioning her equally historic male peer. She founded one of the first computer science departments at a small college and dedicated twenty years to expanding computational literacy amongst students who would never have encountered computer programming in elite research institutions. Her technical work on machine learning through inductive inference anticipated artificial intelligence by decades, yet she chose to spend her career teaching, writing textbooks, and advocating for computers as tools for human flourishing rather than profit maximisation.

Sister Keller, thank you for speaking with us. I want to begin where your story becomes crucial for anyone who cares about how technology shapes education and human possibility. You earned the first computer science Ph.D. in America in 1965 – but your immediate move to Clarke College in Iowa, a small Catholic women’s college, to found a computer science department, is itself a powerful statement of your values. That choice alone says something profound about your values. Most people awarded doctorates from prestigious universities move toward elite institutions, research centres, Bell Labs, that sort of thing. You did the opposite.

Well, you must understand – by the time I finished my doctorate at Wisconsin, I was already fifty-one years old. I had spent twenty years teaching mathematics at Clarke while I was completing my education part-time. The college had sent me to pursue the doctorate because they believed computers would matter in education. It was never a question of going somewhere else. Clarke was my community, my order’s college, and there was already work waiting to be done there.

But you are right about the choice. I had colleagues who asked me – quite seriously – whether I was throwing away my future. They said, “You could teach at a major university. You could do research that would be recognised.” And my answer then, as it would be now, is this: I cared about what my students would do with the knowledge, not about whether my name appeared in citation indexes. A student in Iowa who learned to programme and took that skill back to her small town, or used it to teach others, or solved problems in her community – that mattered to me more than being the author of a famous paper that three dozen specialists would read.

Let’s go back further. You were born in Cleveland in 1913. Can you talk about your family and what drew you toward mathematics?

I grew up in what I would call an ordinary Catholic Irish-American household. My father was a carpenter, quite skilled – he built things with his hands, and he understood how things worked. I think that practicality came to me from him. My mother was a homemaker, but she was nobody’s fool. She could calculate faster than most people with pencil and paper.

Mathematics came to me quite naturally. By the time I was in secondary school, I was consuming every mathematics book I could find. There was a simplicity to it – a purity. You could prove something was true or false. There was no ambiguity, no social complication, just logic and elegance. For a girl growing up in the 1920s and ’30s, with all the constraints and expectations placed upon us, mathematics was freedom. It was a language that didn’t care whether you wore a dress or trousers.

In 1932, I entered the Sisters of Charity of the Blessed Virgin Mary. People often misunderstand this choice, or they assume it was because I couldn’t find another way forward as a woman. But I chose religious life quite deliberately. The congregation believed in education – we founded and ran schools, colleges, and universities. Education was a sacred work, a way of serving humanity. And the congregation gave me something no secular institution at that time would have: the opportunity to pursue advanced education without pressure to marry, without the assumption that my primary role should be domestic.

When I professed my vows in 1940, I was twenty-six. I began teaching mathematics immediately – first in secondary schools, then at Clarke College’s summer programmes. The Sisters believed in educating both the mind and the person. They sent me to study at DePaul, where I earned my master’s degree in mathematics and physics in 1953. I was thirty-nine years old. That timeline – taking my time, learning deeply – would be seen as hopelessly inefficient by today’s standards. But it gave me breadth. I understood physics alongside mathematics. I could see connections.

And religion and science coexisted easily for you?

Entirely. I have never seen a conflict between faith and rigorous thinking. In fact, the mathematical order of creation – the fact that the universe follows laws we can describe, that patterns emerge from chaos – that all seems evidence of divine intelligence to me. Many of the great mathematicians were men of faith. There is nothing incompatible about seeking truth through reason whilst also believing in something transcendent.

What I object to is the false choice our culture has created: the notion that you must choose between scientific rigour and spiritual conviction. It is not true. And it has cost us, I think. Science without ethics, without a sense that technology should serve human flourishing – that leads to weapons, to systems that exploit people. My faith in God gave me a framework for thinking about what computers should be for.

Let’s move to your doctoral work. Your dissertation was titled “Inductive Inference on Computer Generated Patterns,” and you completed it at the University of Wisconsin-Madison in 1965. But I want to understand the intellectual problem you were solving, because it is rather remarkable. You were essentially asking whether a computer could learn patterns from examples – which, decades later, became the foundation of deep learning and modern AI. Walk me through your thinking.

The fundamental question was this: Can we automate the process of mathematical induction? Not deduction – I am not talking about simply applying a rule. I mean induction in the strict sense: observing patterns in specific cases and generalising to a rule that explains them.

Human mathematicians do this all the time. A mathematician looks at the first derivative of a polynomial, then the second derivative, then the third, and after seeing several examples, they know the general form of the nth derivative. They have learned a pattern. My question was: Can we instruct a machine to do this?

I chose to demonstrate the idea using a concrete problem: automatic differentiation. I wrote a FORTRAN programme – CDC FORTRAN 63, running on a Control Data machine – that could solve this problem by learning from examples rather than by encoding the rules of differentiation as logical instructions.

Here is how it worked in outline:

You give the programme k derivative examples. For instance, if I want it to find the general form of the nth derivative of some algebraic expression, I provide the first derivative, the second, the third, perhaps the fourth. The programme does several things. First, it parses these examples into an internal representation – a kind of abstract syntax tree that captures the mathematical structure. Then it looks for patterns in the coefficients, the exponents, the terms themselves. Are the coefficients in arithmetic progression? Geometric? Are the exponents changing in a predictable way?

Once the programme identifies patterns, it generates a hypothesis for the nth derivative. Then – and this is important – it validates that hypothesis by computing the derivatives using the explicit rules of calculus and comparing the result. My programme could solve these problems in less than thirty seconds per case.

And the significance of this approach?

The significance was twofold. First, it showed that you could mechanise the process of learning-by-example – what we might now call machine learning. Most people at that time thought computers could only execute rules you gave them. They were tools for applying logic, not for discovering it. I showed that a machine could infer a general rule from particular cases.

Second, and this troubled some of my colleagues, my approach was fundamentally different from the symbolic manipulation that ruled artificial intelligence in those early years. Symbolic AI – the work of people like John McCarthy and Marvin Minsky – was trying to encode human knowledge as logical rules and have machines manipulate those symbols. But I was asking: what if the machine could learn by examining patterns in data, without being explicitly programmed with the underlying principles?

Now, in retrospect – you are in the year 2025, and I understand that deep learning has become central to artificial intelligence – I suspect my approach was ahead of its time. It was dismissed as too empirical, too inductive, insufficiently rigorous. But it was actually capturing something fundamental about how learning works: pattern recognition from examples.

My only regret is that I had to implement this in FORTRAN, which is a terrible language for this kind of work. LISP – which could handle symbolic manipulation and list processing far more elegantly – existed, but I did not have access to it. I had to write code to construct my own list processing and pattern matching within FORTRAN. It was like trying to paint a landscape with hand tools when you needed fine brushes.

Do you think your approach would have had more impact if you had continued in research rather than moving to teaching?

That is a fair question. I think about it sometimes. If I had stayed at Wisconsin, or moved to a research university, published more papers, built a research group – yes, perhaps the ideas would have circulated more widely among computer scientists. And yet. Reflects I do not know that the field would have valued the approach any differently. The Symbolic AI camp was quite dominant. Papers citing inductive approaches to machine learning would have faced steep barriers. And I would have missed the opportunity to teach hundreds of students, to create a computer science department at an institution that would not otherwise have had one.

There is a cost to both paths. I chose to pay the cost of being overlooked by the field, in exchange for the satisfaction of expanding access to computing education. Some days I think that was wise. Some days I wondered whether I was burying a talent that could have contributed something lasting. But I was fifty-one years old and finally had my doctorate. I did not expect to spend the next thirty years doing publishable research at that stage of life. Teaching was a natural choice – and it was never a lesser choice, in my view, though the field certainly treats it as such.

Now, there is a popular story that you helped develop the BASIC programming language at Dartmouth. I want to set the record straight – because it is an important distinction – but first, what was your actual involvement?

The record does need setting straight! I did not help develop BASIC. That was John Kemeny and Thomas Kurtz and their team of brilliant students. They created something genuinely innovative.

What happened was this: In 1961, I attended a summer programme for high school teachers at Dartmouth College. The goal was to introduce secondary mathematics teachers to computing – to expose them to what these machines could do and how they might be used in teaching. It was unusual for a woman to attend, and even more unusual for a nun. Dartmouth had rules against women in the computer centre – ridiculous rules, but real ones. They made an exception for me, actually, so that I could participate in the summer programme. I am grateful for that.

Thomas Kurtz was there, and I worked with him. I learned BASIC as it was being developed and refined. I saw the philosophy behind it: the idea that programming should not require mastery of machine architecture or obscure syntax. A student who understood algebra should be able to write a simple programme. That was revolutionary. Most programming languages were designed by and for specialists. BASIC was designed for everyone.

What I became, after that summer, was an evangelist for BASIC in education. When I went to Wisconsin to do my doctorate, I taught BASIC to teachers in summer programmes. When I founded the computer science department at Clarke, I made BASIC part of our curriculum. And I co-wrote a textbook in 1973 – Mathematical Logic and Probability with BASIC Programming – that tried to show teachers how to integrate programming into mathematics instruction.

The textbook was practical. We did not use BASIC to teach fancy algorithms or advanced computer science. We used it to help students understand logic, to solve real problems, to build intuition about how machines could be tools for thinking. BASIC was perfect for that purpose.

You mentioned the philosophy of BASIC – programming for everyone rather than just specialists. That aligned with your broader vision for computing, did it not?

Absolutely. BASIC was the right tool at the right moment. Yes, in retrospect, BASIC has a bad reputation in some circles. Computer scientists and engineers have dismissed it as too simple, too forgiving, as if simplicity were a defect. But simplicity is the point. The goal of BASIC was not to teach you to think like a computer engineer. It was to teach you to think computationally – to break down a problem, instruct a machine step-by-step, check your results, refine your approach.

I believe that skill matters far more than learning a particular language. A student who learned BASIC and understood its principles could learn C or FORTRAN or any other language later. But a student who only learned FORTRAN, with all its complexity and its assumptions about mathematical knowledge, might never become comfortable with programming at all.

There is a principle at stake here: whether technology is reserved for the initiated few, or whether it is made accessible to the broad population. I have always believed in the latter. Not because everyone needs to become a professional programmer, but because computing – the ability to instruct machines, to think in algorithms, to automate repetitive tasks – is becoming a fundamental literacy. It is like reading and writing. You would not restrict literacy to a credentialed elite. Why restrict computational literacy?

In 1965, you founded the computer science department at Clarke College in Iowa. You directed it for twenty years. That is an extraordinary institutional achievement. Can you describe what you were building?

Clarke College was a Catholic women’s college founded by my religious congregation. It was small – perhaps two thousand students at its peak – in Dubuque, Iowa. Not exactly a centre of technological innovation, you might say. When I arrived as department chair, the college had no computers. We had budget and an NSF grant, but no machines, no software, no faculty trained in computer science. We were starting from zero.

The first decision was: what kind of computer science programme should a women’s college build? I knew, even then, that we could not compete with MIT or Carnegie Mellon or Stanford. We did not have their resources or their research prestige. So I asked: what can we uniquely offer?

The answer was: access. We could build a programme that welcomed students who would never be admitted to the elite universities. We could focus on teaching and application rather than research and theory. We could show that computer science was not just for male mathematicians and engineers, but for any student curious about how machines worked and what they could do.

We started by acquiring computers through federal grants and through consulting work I did with local governments and businesses. I would work as a computing consultant for Dubuque city planning, for businesses trying to use computers in their operations, sometimes in Chicago in the summer months. The money and the connections helped us acquire equipment. By 1982 – after nearly two decades – we had twenty-one Apple computers on the Clarke campus, which was quite remarkable for a small college at that time.

We developed a full degree programme: a B.A. in computer science for students who wanted broad knowledge, a B.S. for those focused on technical depth. We offered evening classes for adult learners and summer master’s programmes for teachers who wanted to understand computing education. We thought of ourselves as a training centre for educators as much as a traditional computer science department.

What was your pedagogy? How did you teach computer science differently than a research-focused institution might?

We taught in context. When we taught algorithms, we did not present them as abstract mathematical objects. We showed why they mattered, what problems they solved. We had units on computer graphics using matrix methods – because many students would not take a pure mathematics class but were fascinated by visual computing. We taught matrix applications to electrical circuits, because those methods solved real engineering problems. We even created units on matrix methods applied to food service management – matrix algebra could optimise menus, balance nutrition, control costs. This was not theoretical computer science. This was showing how computation could address practical challenges.

We also emphasised programming in context. Rather than assign students an abstract problem – “write a programme to sort an array” – we asked them to solve problems they cared about. A student interested in chemistry might write a programme to balance chemical equations. A student interested in business might write inventory tracking software. The programme was the vehicle for learning the language and the principles.

And we welcomed mothers. We understood that many of our students were juggling education with childcare. So I invited students and faculty with children to bring their babies and younger siblings to class. We created a space in the department for nursing and childcare. It sounds obvious now, perhaps, but this was 1960s and 1970s America, and universities treated motherhood as a barrier to education. We treated it as a reality to accommodate. Several of our best students were women balancing education and raising children. We were not going to tell them that becoming a computer scientist required abandoning their families.

And your relationship with ASCUE? You helped found that organisation.

ASCUE grew out of CUETUG – the College and University Eleven-Thirty Users Group. That mouthful referred to the IBM 1130 computer that many small colleges had acquired. In 1968, representatives from schools that had received this equipment met at Tarkio College in Missouri and decided to form an ongoing organisation to share knowledge and software.

The idea was simple: small colleges faced common problems. We did not have large IT departments or research budgets. We could not afford to develop everything ourselves. But if we pooled our resources, shared software we had written, offered consulting to one another, we could all do better. I was deeply involved – board member, later public relations director. We published newsletters, held conferences, created a network of educators who believed that computing should reach beyond the elite research institutions.

ASCUE, in my view, embodied the right philosophy: that computing education was not a luxury for wealthy universities but a necessity for all institutions that wanted their students to be prepared for the future.

In 1975, you made a statement that I think is remarkable. You said computers were “the greatest interdisciplinary tool that has been invented to date.” That was forty years before “computational thinking” became a buzzword. What did you mean?

Yes. I was frustrated by the way computer science was being portrayed – as a narrow discipline for specialists. But I could see already that computing was becoming essential across every field.

A biologist studying protein structures could use computers to model molecular behaviour. A historian could use computers to analyse texts and find patterns. A business analyst could use computers to model economic systems. An artist could use computers to generate images, to explore forms that would be impossible to create by hand. A chemist, a physicist, a psychologist, an engineer – all of them could use computers as tools for their work.

And yet, computer science was developing as an isolated field. We were training computer scientists, but not training scientists to use computers as tools in their disciplines.

I wrote four books to try to demonstrate this principle in practice. I wanted to show that matrix methods – a fundamental tool in applied mathematics – could be used to solve problems in computer graphics, in electrical circuit analysis, in food service management, in modelling Markov chains. The same mathematics, applied to wildly different domains. The computer was the engine that made these applications feasible.

The tragedy, in my view, is that this vision was not taken seriously. Computer science departments remained focused on what we might call “pure” or “theoretical” computer science – algorithms, complexity theory, language design. Applications were seen as less serious, less rigorous. Teaching applied computing, showing how computers could be used across disciplines – this was considered less prestigious than publishing research papers on abstract problems.

But I think history is proving me right. Every discipline now has a computational component. Digital humanities scholars use computational methods to analyse literature and culture. Biologists write code to process genetic sequences. Climate scientists model the Earth’s systems. The future of every field is computational. The question is whether we realised it early and trained students accordingly, or whether we treated computing as a specialist domain and then had to retrofit it into all the other disciplines later.

Do you think the interdisciplinary approach you pioneered lost out because it was perceived as less rigorous?

Partly, yes. There was a hierarchy of prestige. “Pure” or “theoretical” work was valorised because it seemed more abstract, more intellectual. Applied work was dismissed as merely practical, a kind of engineering rather than real science. This is an old prejudice – that the abstract is more worthy than the applied. But I reject it. Elegant applied mathematics that solves real problems is just as intellectually demanding as theoretical mathematics that generates elegant proofs.

But there is another factor. Much of this work, when I did it, was coming from women or from scholars outside the prestige centres. My books were textbooks for educators, not research monographs for specialists. I was at a small college in Iowa, not at MIT or Berkeley. I was advocating for making knowledge accessible, for teaching rather than publishing research. All of these factors pushed against my work being taken seriously by the field.

And if I am being honest: I did not do everything I could have done to promote my own ideas. I was focused on my students, on building the programme at Clarke, on giving talks wherever I was invited. I did not have the ego or the ambition to fight for recognition. I preferred to do the work and let it speak for itself. Naive, perhaps. The field recognises effort and visibility as much as it recognises quality.

Let us return to this claim that you were the “first woman” to earn a computer science Ph.D. I know the truth is more complicated, and I wonder if you have mixed feelings about how that distinction has been portrayed.

The fact is this: on 7th June 1965, two of us received computer science doctorates in the United States. Irving C. Tang received his D.Sc. from Washington University in St. Louis. I received my Ph.D. from the University of Wisconsin-Madison. We were the first two people in America to earn doctorates specifically in computer science.

For years, the historical record presented me as the sole first, sometimes with a footnote about Irving – or sometimes with no mention of him at all. The narrative that emerged was: “the first woman computer scientist.” It is not wrong, precisely, but it is incomplete and it rather overshadows the fact that Irving was equally pioneering.

I think there are understandable reasons for this. My story is, in some ways, more dramatic: a Catholic nun, defying expectations, achieving a doctorate later in life, at fifty-one. Irving’s story – a man receiving a doctorate in applied mathematics – fits more neatly into the expected patterns of academic achievement. So the press, the historians, the popular accounts seized on my narrative as the more attention-grabbing one.

But it has the effect of flattening the history. It makes it seem as though Irving’s achievement is less remarkable, when in fact it is just as significant. And it creates a narrative of feminine exceptionalism – the idea that a woman who succeeds in a male-dominated field is performing a kind of heroic feat, overcoming tremendous obstacles. Some obstacles I certainly faced. But I was also supported by my religious community, by teachers who believed in me, by institutions that gave me opportunities. I was not entirely unmoored in a hostile world.

I would rather the history record that two scientists – Irving Tang and Mary Kenneth Keller – earned the first computer science doctorates in America on the same day, than that it lionise me as a singular first. That seems more accurate and more just.

Do you think the focus on you as “the first woman” has helped or hindered the larger conversation about women in computing?

Both, I suspect. The focus on a singular exceptional woman can create an inspiring narrative: if one woman succeeded, others can too. But it can also become a kind of trap. It suggests that the problem is that women are naturally rare in computing, when actually the problem is the field itself – the culture, the barriers, the assumptions about who belongs. If you focus on the exceptional woman who broke through, the systemic reasons why so few women even try remain unaddressed.

What I would have wanted to see is a conversation about how to make computing welcoming to all bright students, regardless of gender. How to build environments where women do not have to be exceptional to participate. I tried to do that at Clarke, with mixed success. We had women studying computer science because they were interested in mathematics, in problem-solving, in technology. They did not have to be exceptional or unusual women. They were simply women who wanted to learn.

And we need to be careful about a subtle point: the field celebrates women who succeeded individually, but it does not examine why the field itself became less female-friendly over time. Women made up a substantial portion of early computer programmers – they were considered fit for detailed, careful work. But as the field became more prestigious and more dominated by hobbyists with personal computers, as the culture became more competitive and more masculine, women’s participation declined. That is not a story about exceptional women. That is a story about how fields change in ways that can exclude people who used to belong.

When you were teaching – whether at Dartmouth, Wisconsin, or Clarke – what did you believe was most important for a student to understand?

I cared much less about whether a student could write the most elegant code or design the most efficient algorithm. Those are technical skills that improve with practice. What I wanted was for students to develop certain habits of mind.

First: precision. When you programme a computer, the machine will do exactly what you tell it to do – no more, no less. If you are imprecise in your thinking, the programme will fail. This teaches you to be precise in all your thinking. It disciplines the mind.

Second: patience with the process. Programming involves writing code, testing it, finding errors, diagnosing what went wrong, fixing it, testing again. You cannot skip steps. You cannot give up when the first attempt fails. You have to be methodical and persistent. These are not technical virtues; they are character virtues.

Third: confidence in your own ability to debug and solve problems. This was especially important for young women. Society tells girls that they are not good at mathematics, not good at technical work, not naturally suited to thinking logically. I wanted my female students to have the direct experience of sitting at a computer, encountering a problem, working through it, and solving it. Not because someone told them they could, but because they had done it. That confidence – I have seen it change lives. Women who were uncertain about their abilities in mathematics discovered they were capable of rigorous technical work.

And fourth: understanding that computing is a tool for something. Do not fall in love with the tool itself. Fall in love with what it can do – what problems it can solve, what information it can make available, how it can improve people’s lives. I wanted students to think not just about how to programme, but about what to programme, and why it matters.

I once had a student who came to me near tears because she could not get her programme to run. She was convinced she was not intelligent enough for computer science. We sat down together – this took an hour or more – and worked through the problem methodically. We found the error: a simple syntax mistake, nothing to do with her intelligence. Once we fixed it, the programme ran perfectly. She looked at me and said, “I can do this.” That shift in her own self-perception – that was the real learning. The programme was secondary.

You have alluded to this, but I want to press on it directly. After earning your doctorate, you had a choice. You could have pursued a research career – published papers, built a research group, sought grants, worked on your dissertation ideas. Instead, you chose to teach and build an educational programme. Looking back now, was that the right choice?

Yes. And also, it was not really a choice in the way you frame it. I was fifty-one years old. At that age, you do not start building a research career. The field values young researchers. I was already advanced in years by academic standards.

But more fundamentally: I did not want a research career. I had been teaching since I was in my mid-twenties. I understood what it felt like to work with students, to see their minds engage with an idea, to watch them gain confidence and competence. That was deeply satisfying to me.

My dissertation was intellectually engaging, but writing it felt like a constraint. I had to pursue a specific narrow problem, produce publishable results, complete a dissertation. It was necessary, but it was not what I wanted to spend my life doing.

Teaching allowed me to work with a range of students, on a range of problems. It allowed me to develop curriculum from scratch, to experiment with pedagogical approaches. It allowed me to be responsive to what students needed rather than to what would generate the most citations or the most impressive publications.

Now, if I am being entirely honest: there is a part of me that wonders what would have happened if I had pursued research more aggressively. If I had published more papers on machine learning and inductive inference in the early 1960s, would that work have been more influential? Would I have contributed more to the field?

But I think the answer is probably no. The field was not ready for the kinds of ideas I was working on. Symbolic AI and rule-based systems dominated. A few more papers from me in obscure journals would not have changed the trajectory of the field. Whereas the students I taught – hundreds of them over twenty years – those people went out into the world and did things with computing. They taught others. They built systems. They solved problems. That is a form of contribution that does not show up in citation metrics, but it is real and durable.

And here is the thing that bothers me about how academia values research over teaching: teaching is invisible labour. A researcher publishes a paper and receives recognition. A teacher teaches dozens of students and receives… a thank-you note, if they are lucky. The students scatter. They do not form a visible network that credits the teacher. Years later, a student might remember a particular lesson or a shift in their own thinking that came from a teacher. But by then, the teacher is gone, and the contribution is forgotten.

I knew I was making that trade-off. I chose the path that was less visible, that would bring me less recognition. I do not regret it. But I do think the field loses when it structures itself so that the choice is necessary.

You have mentioned that you saw the computer as a symbol manipulator. What did you mean by that, and why was it important to you?

This is subtle, but it matters. In the early days of computing, there was a kind of magical thinking about computers. People saw them as oracles – machines that could answer questions, that could think, that could somehow arrive at truth through some mysterious process of electronic logic. There was speculation about artificial intelligence, about whether machines could become intelligent.

But I wanted to emphasise a more pedestrian but more honest understanding: the computer is a machine that manipulates symbols according to rules you give it. It does not think. It does not understand. It simply follows instructions.

This matters because it teaches humility. Your computer programme is only as good as your instructions. If you have not thought through the problem carefully, the computer will not magically fix your thinking. It will execute your unclear instructions with perfect fidelity, producing nonsensical results.

But it also matters because it opens up possibility. If the computer is “merely” a symbol manipulator, then anything that can be reduced to symbols and rules can, in principle, be automated. You can manipulate mathematical expressions, logical propositions, lists of data, textual information. You can build systems that handle any domain where you can express the problem in symbolic form.

When I wrote my dissertation on inductive inference, I was trying to show that even the process of learning a pattern from examples – which seems to require something like intuition or insight – could be reduced to symbol manipulation. You represent the examples as symbolic structures, you look for patterns in those structures, you generate hypotheses as new symbolic structures, you test them against additional examples. All of this is symbol manipulation.

So: the computer is not magical, not thinking, not conscious. But precisely because it is “merely” a symbol manipulator, it is far more powerful and flexible than people initially recognised. You can teach it to do almost anything that can be algorithmically specified.

And the implications for education?

If students understand that the computer is a symbol manipulator – if they see that they are really instructing a machine to follow rules they have specified – then they understand that they are in control. They are the intelligent agent. The computer is their tool. This is crucial, especially for young people who might feel intimidated by technology.

If students think the computer is some kind of oracle or intelligent being, they become passive. They input a question and wait for an answer. But if they understand that the computer is a tool they control through precise instruction, then they become active. They have to think through what they want, specify it clearly, test whether the computer is doing what they intended. The responsibility is on them.

This also protects against a certain kind of magical thinking about computers that I see in some educational settings even today. The idea that computers are inherently good, that more computing is always better, that technology will solve problems if we just deploy it widely enough. No. Computers are tools. They are neutral until you use them for something. They can solve problems, but only if you have thought through the problem correctly and specified the solution precisely.

I want to return to something you said earlier about choices and paths not taken. There is a counterfactual history that intrigues me. What if you had moved to a prestigious research university after your doctorate? What if computer science education had developed with the “Clarke model” – accessible, teaching-focused, interdisciplinary – as a central value rather than the research-university model that eventually dominated?

That is a fascinating thought experiment. Let me think through it.

If there had been more institutions like Clarke – small colleges, teaching-focused, committed to access – then more students would have learned computing. We would not have had the bottleneck where only students at elite universities could major in computer science. The field would have been more diverse, because small colleges often serve populations that elite universities do not – rural students, working-class students, students without elite secondary school preparation.

The curriculum might have been different too. If the model was teaching-focused rather than research-focused, there would have been more emphasis on applications, on solving real problems, on showing students how computing connected to their interests and their futures. We might have had less of the pure theory and more of the practical work.

And maybe – I am speculating now – the culture of the field would have been different. Research universities tend to be hierarchical, competitive, focused on prestige and recognition. Small colleges are more communal, more focused on the development of students than on the advancement of individual researchers. If that culture had been stronger in computer science, would the field have been more collaborative, more ethical, more focused on computing in service to humanity rather than on profit and disruption?

But here is the problem with this counterfactual: it would have required choices made by many people, not just me. I could not singlehandedly have created an alternative path. I could only model one version of what computer science education could look like at my institution.

And I am not sure the field was ready for it. The prestige model – research universities, published papers, innovative breakthroughs – that model is seductive. It promises advancement, excellence, impact. Teaching-focused education, however good the outcomes, does not carry the same prestige. The field chose the model that was more impressive to outsiders, even if it was less inclusive and arguably less beneficial to most students.

If I had published more, fought harder for recognition, built a research group, maybe I could have given the Clarke model more visibility. Maybe other institutions would have emulated it. But I did not have the temperament or the ambition for that kind of self-promotion. I simply tried to build something good where I was.

When you earned your doctorate in 1965, what percentage of computer science students were women?

I would estimate perhaps thirty to forty percent, in that era. Computing was not yet perceived as a male field. Programming was seen as detail-oriented work, patient work – and it was coded as female. Women were considered naturally suited to it.

And yet women’s representation has declined significantly since then. In your lifetime, it rose through the 1970s and early 1980s, then fell precipitously. What happened?

The culture changed. Computing became more prestigious and more profitable. As the field became more valuable and more male-dominated in its informal culture – through personal computers, through programming competitions, through the “hacker” ethos – women were pushed out. Or rather, they were made to feel they did not belong.

This happened through many small mechanisms: the assumption that girls are not good at mathematics, the celebration of the brilliant lone programmer (usually depicted as male), the computing culture that valorised difficulty and speed over thoughtfulness and collaboration. Young women looked at the field and saw that it was defined by masculine values and masculine culture. Many of them chose other fields.

There is a tragedy here, because we lost talent and we lost diversity. A field that was once relatively open to women became exclusionary. And the irony is that, as I think history is proving, diversity makes a field stronger, not weaker. Multiple perspectives, different approaches to problems, different values – these are assets.

What I would have wanted to see is conscious effort to maintain and expand women’s participation in computing. This requires structure: mentorship programmes, all-female study groups and spaces where women feel supported, active recruitment of women into programmes, celebration of female role models. It requires pushing back against the notion that computing is for a narrow type of person – the solitary male genius. It requires saying: this field needs all kinds of brilliant minds, and we are going to make sure they feel welcome.

Some of the women’s colleges – institutions like Clarke – had real success in producing women computer scientists. There was something about the all-female (or largely female) environment that created space for women to engage with technical work without the pressure of competing in a male-dominated culture. You would think, given this evidence, that women’s colleges would be seen as valuable institutions for STEM education. Instead, they have been dismissed as backward or unnecessary.

I mentioned earlier that your dissertation on learning-by-example anticipated deep learning and modern AI. Has anyone told you this? Do you have thoughts on how the field has developed?

Yes, in recent years, some researchers have mentioned this. I have read about these “deep learning” systems that learn patterns from data rather than being programmed with explicit rules. And I think: yes, this is what I was trying to show was possible in 1965. Except now you have computers millions of times more powerful, and vast datasets to learn from, and better mathematical tools for training these systems.

My approach was fundamentally sound, I believe. But I was decades ahead of the computational power and the available data that would make the approach practical at scale.

My understanding of modern artificial intelligence leads me to see it reproducing some of the same problems we faced in my era. There is a tendency to treat these systems as though they possess understanding or consciousness. They are called “intelligent.” People anthropomorphise them. But they are still – as far as I understand – doing sophisticated symbol manipulation, learning patterns from data, and producing outputs based on those patterns. They are not thinking. They are not conscious. They are very powerful tools.

And because they are powerful, they are used in ways that reflect the values and biases of the people who built them. A system trained on biased data will perpetuate those biases at scale. A system optimised for engagement or profit may spread misinformation. A system with no ethical constraints can be weaponised.

The lesson from my work in the 1960s is this: understand what your tool does. Do not attribute to it powers it does not possess. Do not use it blindly. These are simple principles, but they are important.

You completed your doctorate at fifty-one. That was quite late by academic standards. Did you feel you were behind, or did you feel liberated?

Both. I certainly wondered, during my time at Wisconsin, whether I had started too late. I watched younger students come through, finish their degrees in their late twenties, move on to positions with the next stage of their lives. I was still in school, finishing my education.

But there were advantages too. I brought maturity and perspective. I had taught students for twenty years before I earned my doctorate. I understood the practical challenges of education, the difficulty of learning, the patience required. Young researchers straight out of a bachelor’s degree sometimes lack that perspective. They can be brilliant, but they do not necessarily understand the human dimensions of learning.

And I was not concerned with the prestige game to the same degree. A young person, starting a career, has to be somewhat strategic about publications and visibility – though I think this is regrettable. But at fifty-one, I had already lived a full life. I was not desperate for professional recognition. I was interested in doing interesting work and serving my community. That liberated me, I think.

The tragedy is that this timeline – taking ten years to earn a master’s degree, another twelve years to earn a doctorate – is treated as unusual and somewhat suspect. “Why did you take so long?” the question carries an implied criticism. But for many women, this is the rhythm of life. You do not emerge from secondary school at eighteen, go straight to university, finish by twenty-two, and complete a doctorate by twenty-seven. You work, you study part-time, you raise children, you serve your community, and perhaps, over decades, you complete advanced education.

The academy should make more room for this rhythm. It would be enriched by the wisdom and experience of older students.

Let me ask a more philosophical question. You have spent your life thinking about what computers are for, what they can do, how they should be used in education and society. What is the good life, as you see it? What role do computers play in human flourishing?

I believe the purpose of technology is to free humans from drudgery and oppression, so that we can pursue what is noble and beautiful and true. A computer that automates repetitive calculation frees a scientist to think about deeper questions. A computer that manages information makes knowledge accessible to people who would otherwise be locked out by geography or resources.

But technology can also oppress. It can concentrate power. It can surveil and control. It can create systems that reduce people to data points, that optimise for profit at the expense of human dignity.

What has concerned me, throughout my career, is the direction in which computing has developed. There has been too much focus on profit, on disruption, on making technology clever rather than making it serve human needs. And there is not enough conversation about values.

When you build a computing system, you are making choices about what matters. You choose what to measure, what to optimise for, whose interests you serve. These are moral choices, not technical choices. And the field does not talk about them enough.

I would have wanted to see computing education that included ethics alongside algorithms. That taught students to think not just about how to build something, but about what it is for and whose interests it serves. That encouraged them to imagine alternative paths – computing for equity, for access, for human flourishing rather than profit extraction.

In my religious tradition, we speak of vocation – the sense that your work is aligned with your values, that you are serving something larger than yourself. I had that sense with computing education. It felt like a calling, a way of serving humanity. I wanted all students who studied computing to have that sense of calling – not just to be technically skilled, but to think deeply about what they were doing and why it mattered.

You died in 1985, forty years ago. The field has changed dramatically. What would surprise you most about computing today?

That I am not entirely forgotten, I suppose. I read that there are still articles about me, that Clarke University has named facilities after me, that people are researching the history of computer science and including women like me. That is gratifying.

What would surprise me? The power and the ubiquity of it all. Computers are everywhere – in everyone’s pocket, connected to each other globally. The kind of access to information I envisioned in my statement about the “information explosion” has come to pass, though in forms I did not entirely anticipate.

And artificial intelligence – or what you call AI – has become central to how computing is used. The approach I explored in my dissertation, learning patterns from data, is now being applied to understand language, to generate images, to make decisions about people’s lives. That is both exciting and troubling. Exciting because the fundamental approach was sound. Troubling because the ethical implications remain largely unexamined.

What troubles me most, I think, is that the world seems divided by computing. Some people – in wealthy countries, with good education, with resources – are fluent in technology and benefit from it. Others are shut out. The promise that computing would democratise access, that it would be a tool for everyone, feels unfulfilled. If anything, the technology has become more concentrated, more proprietary, more controlled by powerful institutions.

The dream I had – that small colleges could teach computing, that students from rural Iowa could have access to the same tools and knowledge as students at Stanford, that computing would be available to everyone – that dream is partly realised and partly disappointed. We have BASIC and personal computers and the internet, which have made knowledge more accessible than ever. But we have also created monopolies and gatekeeping and surveillance on a scale I could not have imagined.

Is there anything you would say to computer scientists and educators today?

Do not let the tools become masters of the vision. Yes, write elegant code. Yes, pursue ambitious technical problems. But never forget that the purpose of computing is to serve human needs. Ask constantly: what is this technology for? Who benefits? Who is harmed? What values am I embedding in this system?

Teach students to be thoughtful, not just skilled. Teach them to question, not just to execute instructions. Make space for students who do not fit the stereotype of the brilliant technologist – the women, the students of colour, the students from working-class backgrounds, the older students coming to computing later in life. The field is impoverished when it restricts itself to a narrow type of person.

And please, care about access and equity. Do not let computing become a tool for the privileged. Fight for quality education in computing available to all students, not just those at elite institutions. Build institutions that welcome and support students who are finding their way.

The world needs computer scientists. But it needs computer scientists who are thoughtful about what they are building, who care about justice and access, who see their work as service rather than self-advancement. That is the vision I tried to embody. I hope others will continue it.

Thank you for this conversation. As we close, I wonder if you have any final thoughts about your own legacy, or about what it means to be a pioneering scientist whose work was not always recognised during her lifetime?

I am not sure I think of myself as a pioneering scientist in the way that term is usually meant. I did not make breakthroughs that changed the field. I did not win major prizes or have theorems named after me. I earned a doctorate late in life, then spent twenty years teaching at a small college.

But I tried to embody a principle: that computing is not a rarefied specialty for the elite, but a tool for humanity. That teaching matters as much as research. That questions about what technology is for are as important as questions about how to build it. That women belong in this field, as they belong in all fields. That a student from a small town in Iowa deserves the same quality of education as a student at MIT.

If my life contributed to those principles being lived out, then I am satisfied. I was not famous. I did not transform the field through brilliant research. But I influenced hundreds of students, and those students went out and influenced others, and the ripples spread. That is the kind of legacy I cared about.

As for not being recognised: yes, it stings a bit, even now. Smiles ruefully I am human. I would have enjoyed seeing my ideas taken seriously, being cited more frequently, having my work matter visibly in the development of computing. But I also knew, from the beginning, that I was making a choice for a kind of work that does not generate the same recognition. Teaching is invisible labour. Small college faculty are invisible. Women’s contributions are often invisible.

I made peace with that. I was doing work I believed in, with students I cared about, in service to a vision of computing that mattered to me. The lack of recognition is not ideal, but it is not the most important thing.

What I would say to anyone reading this: do not wait to be famous to do meaningful work. Do not only do what generates prestige and recognition. Do the work that aligns with your values, that serves others, that is true to your vision of what the world should be. The recognition may or may not come. But the work will matter, and that is enough.

---

Questions from Our Community

After the main interview concluded, we received dozens of thoughtful letters and emails from our growing community of readers – computer scientists, educators, historians, students, and technologists from around the world. They had read Sister Keller’s reflections on her dissertation work, her vision for computing education, and her deliberate choice to teach rather than pursue research prestige. Many wanted to ask her more.

We selected five of these letters, representing voices from diverse perspectives and geographies. Each writer had engaged deeply with Sister Keller’s work and life, and each posed questions that pushed beyond the initial interview – questions about technical choices and limitations, about the subtle ways that gender shapes fields and values, about what might have been different if history had unfolded along alternative paths, about the gap between mathematical abstraction and messy real-world application.

What follows are Sister Keller’s detailed responses to these five questioners. Together, they paint a fuller picture of her technical thinking, her understanding of how fields are shaped by power and culture, her reflections on interdisciplinary work, and her hopes for those who inherit both her legacy and her unfinished questions.

These responses reveal a figure far more complex and analytically sharp than the popular “first woman computer scientist” narrative allows. She was a rigorous thinker working through genuine intellectual tensions – between induction and deduction, between abstraction and context, between individual aspiration and structural constraint. She was also a woman deeply aware of how institutions shape knowledge, how values get encoded into technology, and how the choices we make about what to valorise and what to dismiss have profound consequences for who belongs in a field and what the field becomes.

Chloe Bennett, 34, Canada | Educational Technology Designer & Curriculum Developer, Toronto
In your dissertation work on inductive inference, you were learning patterns from limited examples using CDC FORTRAN 63. But I’m curious about what you couldn’t see or test at the time – the constraints you hit but perhaps didn’t fully understand. Were there moments when you suspected your approach was limited by something fundamental about the tools available, rather than the logic itself? And did you ever wonder whether your algorithms might scale or transform in ways you had no way to measure back then?

Chloe, that is a very sharp question. Yes. The answer is yes, emphatically.

Let me be concrete about this. When I was writing my dissertation code, I was constrained by memory. The CDC 6600 was a powerful machine for its time, but memory was precious – you measured it in kilobytes, not megabytes. My programme had to hold the examples in memory, parse them, generate hypotheses, validate them, all within severe limits. I had to be extraordinarily efficient about data structures and representation.

There were problems I wanted to try but simply could not because they exceeded available memory. I remember thinking: if only I had more space to work with, I could test whether the algorithm could handle more complex expressions, longer chains of examples, richer pattern spaces. I knew, intellectually, that memory limitation was not a fundamental constraint on the logic. It was engineering. But I could not separate the two in practice.

And FORTRAN itself – good Lord, FORTRAN was a straitjacket.

The language was designed for numerical calculation, for arithmetic. What I needed was a language that could handle symbol manipulation elegantly – constructing expressions, taking them apart, rearranging them, building data structures that could represent abstract syntax trees. FORTRAN could do these things, but only awkwardly, only by building everything myself from first principles. I wrote my own list-processing code. I had to invent workarounds for recursion.

If I had been using LISP – which John McCarthy and others were developing around that same time – the code would have been perhaps one-tenth the length. I could have expressed the logical structure of the problem more directly. And more importantly, I could have experimented much more rapidly. With LISP, I could have tried variations, tested hypotheses, explored the space of possible algorithms much more freely.

But here is what troubles me in retrospect: I do not know whether my inability to experiment more broadly was a limitation of FORTRAN and the hardware, or whether it revealed something genuine about the approach itself. In other words, maybe my algorithm only worked well on the narrow class of problems I could actually test. Maybe if I had had unlimited memory and a more expressive language, I would have discovered that the approach did not generalise – that it hit some fundamental wall when you tried to scale it up.

I published my dissertation results based on a limited set of test cases. The algorithm performed well on those cases. But I was aware, even as I wrote it up, that I was demonstrating a proof of concept in a sandbox. I did not – could not – test whether the approach would work on truly large problems, on messier real-world data, on expressions with deeper nesting or more complex structures.

There is a kind of blindness that comes with working under constraint. You optimise for what you can do. You stop imagining what you might do if the constraints were lifted. It is like painting in a room with only candlelight – you learn to paint for candlelight, and you stop imagining what the painting would look like in sunlight.

As for whether the algorithms might scale or transform in ways I could not measure – yes, I wondered about that constantly. I had intuitions. I suspected that the pattern-recognition approach might be more powerful than my limited testing could reveal. I had a sense that if you could present the algorithm with thousands or millions of examples, rather than dozens, something qualitatively different might emerge. You might discover patterns in the patterns. You might find principles that were invisible at small scale.

But I had no way to test this intuition. I could not generate millions of examples easily. I could not run the algorithm millions of times. The computational cost would have been prohibitive.

You know, in recent years – and this is rather gratifying – I have read about these “neural networks” and “deep learning” systems that learn from vast datasets. And I think: yes, this is what I suspected might be possible. If you give a learning algorithm enough examples, enough computational power, enough time, it discovers patterns that emerge only at scale. My dissertation only hinted at that possibility.

I wonder sometimes whether my approach would have been taken more seriously if I could have shown results on large-scale problems. Perhaps the field dismissed inductive inference because my implementation was limited to toy problems. Or perhaps the field was simply not ready for the approach, regardless of scale. I cannot know.

But Chloe, you raise something deeper, and I want to address it directly: Was my approach limited by fundamental logic, or by tools?

I believe the answer is: both, but in ways I could not fully disentangle.

My approach was limited by logic in this sense: I was trying to infer general rules from particular cases. This is always fraught. You can always find patterns in noise. You can always generalise incorrectly from limited examples. Any inductive approach faces this problem. My programme tried to address it by validating hypotheses against additional examples, but this is only a partial solution.

However, the tools were also limiting. With better languages, more memory, access to larger datasets, I might have been able to implement more sophisticated validation strategies. I might have been able to test the approach on richer problems and discover its genuine limitations – or its genuine strengths – more clearly.

What I did not know, and could not have known, was how advances in mathematics – in statistics, in information theory, in computational complexity – would eventually create frameworks for understanding learning from data. These frameworks did not exist in 1965, or at least not in forms accessible to me. The theoretical foundations for understanding what machine learning can and cannot do – those came much later, from people working with much larger datasets and much more powerful computers.

So in a sense, I was working blind. I had intuitions about what was possible. I had implemented a working algorithm. But I lacked the theoretical apparatus to understand my own work deeply. I was solving a problem, but I could not articulate the general principles at stake.

This is something I wish I could have told younger researchers: do not assume that your inability to solve a problem, or your inability to scale a solution, means the problem is unsolvable or the approach is flawed. Sometimes it means you lack the tools. Sometimes it means the field is not yet ready. Sometimes it means you are ahead of your time, working on something that will only make sense decades later, when circumstances change.

And conversely: do not assume that because you can solve a problem with the tools you have, you understand it. Limitation teaches you something, but it also blinds you. The view from inside your constraints is never the complete view.

I wish I had had the chance to revisit my dissertation work decades later, with modern tools and frameworks. I suspect I would have learned things about my own approach that I could never see at the time. That is one of the roads not taken – not because I lacked ability or insight, but because I aged out of active research, and by the time I might have returned to it, the intellectual landscape had shifted so far that my own work might have become archaeologically interesting rather than actively useful.

But that is the nature of pioneering work, I suppose. You plant seeds and move on. You do not always get to see what grows from them.

Kenji Sato, 41, Japan | Computer Scientist & Algorithm Researcher, Tokyo
Your dissertation used pattern recognition to infer derivatives, rather than encoding symbolic differentiation rules explicitly. But I wonder: did you consider hybrid approaches – where you used both learned patterns and rule-based validation? And in retrospect, knowing what we now know about LISP and other symbolic languages, do you think a different implementation language would have changed not just the ease of coding, but the kinds of insights you could have extracted from your own work?

Kenji, you have identified the exact tension that occupied my thinking during the dissertation work. This is good – it shows you understand what I was actually trying to do, rather than what people often assume I was trying to do.

I did not simply use pattern recognition. My algorithm was, in fact, a hybrid approach – though perhaps not in the way you might be imagining.

Here is how it worked: First, the programme would look at the examples – the first derivative, the second derivative, perhaps the third – and identify patterns in the coefficients, in the exponents, in the structure of the terms. It would generate hypotheses: “perhaps the coefficient follows an arithmetic progression,” or “perhaps the exponent decreases by one each time,” that sort of thing. This was the inductive, pattern-recognition phase.

But then – and this was crucial – I included what you might call a rule-based validation phase. Once the programme had generated a hypothesis for what the nth derivative should be, it did not simply accept that hypothesis. Instead, it computed the actual derivative using explicit symbolic differentiation rules. It applied the power rule, the product rule, the chain rule – all the standard rules of calculus, encoded as logical procedures.

Then it compared: Did the hypothesised derivative match the computed derivative? If yes, the hypothesis was validated. If no, the programme rejected the hypothesis and tried another pattern.

So my approach was already hybrid. The learning came from examples, but the validation came from explicit rules. I was not trusting the pattern recognition alone. I was using symbolic differentiation as a ground truth against which to check the inductive inference.

Why did I do this? Because I was aware of precisely the danger you are raising: inductive inference can discover spurious patterns, noise rather than genuine structure. By validating against the explicit rules of calculus, I was saying: the pattern you found is only interesting if it aligns with what we know to be mathematically true.

Now, your second question about LISP and symbolic languages – this is where I must be honest about a genuine regret.

LISP was being developed during my dissertation work. John McCarthy had created it specifically for artificial intelligence and symbol manipulation. It was designed to handle exactly the kinds of problems I was trying to solve: building abstract syntax trees, decomposing expressions, reconstructing them, pattern matching, list processing.

I knew about LISP, or at least I knew it existed. But I did not have access to it. The only language available to me on the CDC machines was FORTRAN. And so I had to implement list processing in FORTRAN, which meant writing my own linked list structures, my own recursive traversal functions, my own pattern-matching algorithms – all of this from scratch, in a language fundamentally not designed for such work.

The effect was that my code was bloated. It was difficult to read. It was hard to modify or extend. And most importantly, it obscured the logical structure of what I was trying to do. A reader of my dissertation had to wade through pages of FORTRAN code to understand the underlying ideas. The ideas themselves were buried in implementation details.

If I had implemented the same algorithm in LISP, the code would have been perhaps one-fifth the length. More importantly, the structure would have been transparent. The pattern-matching logic would have been expressed directly, without all the boilerplate for managing data structures and recursion.

But here is what is more interesting: I think a different language would have changed not just the presentation, but my actual thinking about the problem.

FORTRAN forced me to think procedurally. I had to specify step-by-step exactly what the programme should do. Compute the first derivative. Parse the expression. Look for patterns in the coefficients. Generate a hypothesis. Validate it. This sequential, imperative way of thinking is natural to FORTRAN. But it is not natural to the problem itself.

LISP, being based on recursive function evaluation and list processing, would have invited a different way of thinking. I might have formulated the problem differently. Instead of “do this, then do that,” I might have asked: “What is the pattern that transforms one example into the next?” Or: “What function, when applied to the coefficients, produces the observed sequence?” The language shapes the way you conceptualise the problem.

I suspect that if I had used LISP, I would have discovered aspects of my own algorithm that remained hidden when I implemented it in FORTRAN. I might have found more elegant formulations. I might have identified principles that got lost in the FORTRAN translation.

You ask whether my methods still have relevance. I think they do, though perhaps not in the way I intended.

My approach was to learn patterns from examples and validate them against known rules. Today, I understand, machine learning has largely abandoned validation against explicit rules. Modern systems learn from vast datasets and generate outputs without being constrained by symbolic validation. They are, in some sense, purer inductive systems than mine was.

But I wonder whether that is entirely wise. My insistence on validation – checking the learned patterns against known mathematical truths – was born from caution. I did not trust the patterns until they were verified. Modern systems learn correlations that may not correspond to any underlying principle. They can produce outputs that are statistically accurate but logically nonsensical.

Perhaps there is something worth preserving in the hybrid approach: learn from data, but verify against principles. Use induction to discover patterns, but use deduction to test them. This creates a tension, yes – the patterns might not match the principles, which means the principles are incomplete or the learning is capturing noise. But that tension is productive. It forces you to refine both the learned patterns and the principles.

I think modern machine learning could benefit from more of this caution. Not by encoding all knowledge as explicit rules – that leads to rigid, brittle systems. But by including some layer of validation or verification. By asking: does this pattern make sense? Can it be explained? Is it robust, or is it merely fitting noise?

LISP would have helped me articulate these ideas more clearly. FORTRAN forced me to implement them awkwardly. But the fundamental insight – that induction and deduction should work together – that was sound, and I believe it remains relevant.

Sara Hassan, 38, Egypt | Gender Equity in STEM Advocate & Academic, Cairo
You mentioned that computing became coded as feminine when it was seen as detailed, patient work – but then became male-dominated as it gained prestige. This pattern of gendered labour flowing through fields based on status and power leads me to a question. When you were teaching BASIC to high school teachers in the 1960s, did you notice differences in how male and female teachers responded to the language? And did you ever theorise about whether the choice to make BASIC accessible – to emphasise simplicity and democratisation – was itself influenced by or aligned with the values of the women who championed it?

Sara, you have just articulated something I have thought about for decades but rarely had the language to express clearly. Yes. Yes, I noticed differences. And yes, I have wondered about the connection between accessibility and femininity.

When I taught BASIC to high school teachers in the summer programmes – both at Dartmouth and later at other institutions – I observed something quite unexpected.

The male teachers, on the whole, came to the course wanting to understand how computers worked. They wanted to master the machine, to understand its logic, to demonstrate competence and expertise. Many of them had backgrounds in mathematics or physics. They approached BASIC as a tool for expressing mathematical ideas, and they were impatient with the language’s simplicity. They said things like, “Well, yes, but what about memory management? How does this compare to assembly language? What are the limitations?”

The female teachers – and there were fewer of them, I should say – came with different questions. They wanted to know how computers could be useful in teaching. They asked: “Can my students use this to solve problems they care about? Can they learn something about logic and thinking by writing programmes?” They were less concerned with mastering the machine itself and more concerned with what the machine could do for their students.

This difference manifested in how they engaged with BASIC. The male teachers often felt BASIC was too limited, too simplified. They wanted something more powerful, more “real.” The female teachers appreciated BASIC precisely because it was accessible. They saw that you did not need to understand the entire computer to write a programme. You could learn a few simple commands and immediately solve a problem. That appealed to them.

Now, I want to be careful here. I am generalising. There were male teachers who cared deeply about pedagogy and female teachers who wanted to master technical detail. But the pattern was noticeable.

And here is where your insight becomes really important, Sara. The association between BASIC’s accessibility and femininity – that was not accidental, I believe.

John Kemeny and Thomas Kurtz designed BASIC explicitly to be accessible. Their goal was to democratise computing, to make it available to people who were not mathematical specialists. And in doing so, they created a language that was coded – in the eyes of many computer scientists – as feminine. Less powerful. Less serious. More suitable for amateurs and students than for professionals.

I think this is no coincidence. Accessibility is gendered feminine in our culture. Things that are simple, intuitive, intuitive, easy to learn – these are often dismissed as less serious than things that are difficult and require mastery. And the people who value accessibility, who advocate for simplicity and democratisation – they are often women, or they are people whose work is devalued by being associated with women’s values.

I do not think Kemeny and Kurtz set out to create a feminine language. But the culture received BASIC as less serious precisely because it was accessible, and accessibility is coded feminine. A powerful language that only experts can master – that is masculine, serious, rigorous. A simple language that anyone can learn – that is feminine, amateur, toy-like.

And when computing began to acquire prestige and money and power – when it became clear that computing was going to shape the future – the field wanted to associate itself with masculine values. Difficulty. Specialisation. Mastery. Competition. So BASIC, the accessible language, was abandoned in favour of languages that required more expertise and promised more control.

But your deeper question is this: Was the choice to make BASIC accessible influenced by or aligned with the values of the women involved?

I cannot speak to whether women influenced Kemeny and Kurtz’s decision. I do not know their motivations intimately. But I can say that when I encountered BASIC, I recognised it as embodying values I cared about. And I championed it partly because those values resonated with me.

Those values were: education should be available to everyone, not just the elite. Learning should be guided by what students care about, not by what experts think is important. Technology should be a tool for human flourishing, not an end in itself. These are values that I associate with my religious tradition – the belief that all people have dignity and deserve access to knowledge. But they are also values that I have observed more commonly among women, at least in my experience.

I wonder whether there is a connection. Women have historically been excluded from power and prestige. So perhaps women are more naturally inclined to ask: how do we make knowledge available to people who are excluded? How do we build structures that include rather than exclude? How do we measure value in terms of human benefit rather than elite status?

I do not want to essentialize this. There are men who care deeply about access and equity. There are women who are motivated purely by technical mastery and professional advancement. But as a generalisation, I think women – at least women with certain experiences – are more likely to ask questions about access and inclusion.

And conversely, once a field becomes associated with power and prestige, the people who move into it are often motivated by the desire for that power and prestige. They adopt the values of the field – difficulty, specialisation, competition – because that is what the field rewards. And they are disproportionately men, partly because the field has constructed itself in masculine terms.

What troubles me most about this pattern is its tragedy. BASIC could have remained the dominant educational language. High school students could have learned BASIC, understood programming fundamentals, and then moved on to more specialised languages if they needed to. Computing education could have been universally accessible.

Instead, as computing became prestigious, BASIC became unfashionable. The field wanted languages that demonstrated expertise and difficulty. Young people learned C or later Python or Java – languages that were more powerful but also more complex. Computing education became gatekept by difficulty.

And women’s participation declined, partly because computing culture became more aggressively masculine. It valorised the brilliant lone programmer, the person who could master complexity and compete fiercely. Many women did not see themselves in that image. So they chose other fields.

I think about this especially now, knowing what I know about the decline in women’s participation in computing. In 1965, when I earned my doctorate, women made up a significant portion of computer programmers. By the time I died in 1985, that percentage was beginning to decline. And I understand that in the decades since, it has fallen further.

If the field had held onto the values embodied in BASIC – accessibility, inclusivity, focus on application and human benefit – would women’s participation have remained higher? I suspect yes. Because those are values that many women bring to technical fields. And when a field rejects those values in favour of prestige and difficulty, it rejects the people who hold them.

I want to be honest about my own complicity here. I championed BASIC. I wrote a textbook on BASIC. I taught BASIC. I believed deeply in its pedagogical value. But I was swimming against the current of the field’s values. The field did not want accessible languages. It wanted languages that demonstrated mastery.

I could have fought harder. I could have published more, written more extensively about the value of accessibility, built a stronger coalition of educators who valued what I valued. Instead, I focused on teaching at Clarke, on my students, on my department. I let the field’s prestige hierarchy marginalize the work I was doing.

So when I see the decline in women’s participation in computing, I feel some responsibility for not fighting harder to preserve and extend the kind of culture that BASIC represented – a culture in which computing was for everyone, not just for the elite.

But I also think the field bears responsibility. The choice to value difficulty over accessibility, prestige over inclusion, competitive excellence over collaborative learning – these were choices. The field could have chosen differently. And if it had, I believe both women’s participation and the humanity of the field itself would have been better served.

Leo Schmidt, 52, Germany | Computing Historian & Philosophy of Technology, Berlin
Suppose that in 1965, when you earned your doctorate, ten other small colleges had simultaneously started computer science programmes modelled on your philosophy – accessible, teaching-focused, locally embedded, applied. And suppose those programmes had networked with one another the way ASCUE eventually did, creating genuine intellectual infrastructure outside the research universities. Would such a parallel ecosystem have been stable? Or would the prestige differential have eventually pulled talented people and resources toward elite institutions anyway, regardless of the quality of the alternative? In other words: is the hierarchy we see – research universities at the top, small colleges at the bottom – inevitable, or was it a choice the field made?

Leo, you are asking the question I have asked myself many times. And I do not have a confident answer. But I have thought about it deeply enough to offer some observations.

First, the counterfactual itself. Yes, I can imagine it. In 1965, there were dozens of small colleges acquiring computers through federal grants and NSF funding. Clarke was not unique in receiving support to build computer science capacity. Many institutions were asking: what should we do with these machines? How do we teach computing to our students?

If ten – or better yet, fifty – of those institutions had committed to a teaching-focused, applied, accessible model, networked together, shared resources and curriculum, that could have created something substantial. ASCUE eventually became that kind of network, but it emerged gradually and was always somewhat fragmented. But imagine if it had been intentional from the beginning. Imagine if there had been a deliberate alternative model to the research university model.

Such a network would have had real strength. Small colleges collectively serve millions of students. They are embedded in communities across the country. They have relationships with local businesses, government agencies, schools. A coordinated network of small colleges teaching computer science could have trained enormous numbers of students – perhaps more students than the elite research universities trained, since research universities are by definition selective and small.

And such a network could have maintained different values. Teaching as the primary mission. Applied work valued alongside theory. Interdisciplinary computing. Emphasis on using computers to solve real problems rather than on advancing the field of computer science itself. Women and underrepresented students welcomed and supported. Computing in service to local communities.

That alternative ecosystem was possible. It was not fantasy.

But would it have been stable? Would it have remained an alternative, or would it have been absorbed into the dominant model?

I think the answer depends on something deeper: whether the prestige hierarchy itself was inevitable, or whether it was a choice.

And here I must be blunt: I believe the hierarchy was a choice, not an inevitable law of nature. But it was a choice made by many people, in many institutions, often without explicit acknowledgment that they were making a choice.

Let me explain what I mean.

A hierarchy between research universities and small colleges did not have to exist – or at least, not in the form it takes. Yes, research universities have certain advantages: more resources, more specialised faculty, better facilities. But these are advantages for some kinds of work. Research universities are good at producing research. They are good at training specialists who will go on to do research or advanced professional work. But they are not necessarily good at teaching undergraduates. They are not necessarily good at training teachers. They are not necessarily good at serving local communities.

Small colleges have different strengths. They offer close relationships between students and faculty. They can respond quickly to what students need. They can focus on teaching and learning without the distraction of research competition. They can build relationships with their local communities. They can emphasise breadth and application rather than specialisation.

Both have value. In a healthy ecosystem, both would thrive. Research universities would do research and train specialists. Small colleges would educate broadly and serve communities. They would be different, not ranked.

But what happened instead – what I witnessed – was that the field came to see research universities as the “real” centres of computer science, and small colleges as secondary, lesser, derivative. Research was valued and teaching was not. Specialisation was valued and breadth was not. Competition was valued and collaboration was not.

This was not inevitable. It was a choice made by journal editors who chose which papers to publish, by tenure committees who decided what counted for advancement, by funding agencies who decided where to concentrate resources, by young computer scientists who chose where to seek positions, by students who chose where to study.

Each individual choice made sense from that person’s perspective. A young researcher wants to work where the best research is happening. A funding agency wants to support the most prestigious institutions. A journal editor wants to publish the most innovative work. But collectively, these individual choices created a hierarchy that was not inevitable – it was constructed.

And yet – you ask the harder version of the question. Even if the hierarchy was not inevitable, would a parallel ecosystem have been stable? Would it have persisted, or been absorbed?

I suspect there are forces that would have worked against stability. Let me outline them.

First, there is the problem of talent migration. A small college builds a strong computer science programme. One of the best faculty members gets offered a position at a research university – higher salary, more resources, more prestige. Does the faculty member stay at the small college out of loyalty and values? Or does the person take the better opportunity? I suspect most people take the better opportunity. And so talented people drain from the small college system toward the research university system.

Second, there is the problem of student aspiration. If students are taught that “real” computer science happens at research universities, that small colleges are where you go if you cannot get into a research university, then the best students will gravitate toward research universities. And then small colleges lose their best students, which makes it harder for small colleges to maintain quality programmes.

Third, there is the problem of legitimacy. Once the field has decided that research universities are the authorities, small colleges must justify themselves constantly. Why should we believe a textbook written by a small college professor? Why should we hire a graduate from a small college programme? The hierarchy becomes self-reinforcing: research universities are prestigious because they are prestigious.

Fourth, there is the problem of resources. Federal funding for computing education and research flowed disproportionately to research universities. The NSF, the Department of Defense, private foundations – all of them directed more money to research universities. With more resources, research universities could attract better faculty, support more students, build better facilities. The gap widened.

So even if a parallel ecosystem had been built, these forces would have worked to undermine it. It would have required constant, active effort to maintain – government policy protecting funding for small colleges, professional organisations valuing teaching alongside research, students choosing small colleges deliberately rather than as a fallback, faculty choosing to stay at small colleges out of commitment to their mission.

For a parallel ecosystem to have remained stable, I think several things would have needed to be true.

First, the values would have had to be actively championed and defended. Someone – or many someones – would have needed to consistently argue that teaching-focused, applied, accessible computing education was just as valuable as research. Not as a compromise or a second choice, but as a genuine alternative with different but equal value.

Second, there would have needed to be institutional structures that supported these values. Professional organisations that valued teaching and rewarded it. Journals that published teaching-focused work. Funding agencies that explicitly supported educational innovation at small colleges. These structures did not exist, and they did not emerge.

Third, there would have needed to be some protection against talent drain and student drain. Perhaps through clear expectations that faculty would prioritise teaching over research advancement. Perhaps through building strong local networks that gave students good reasons to stay in the small college system. Perhaps through cultural prestige attached to teaching excellence. I do not know exactly what form this would have taken, but it would have been necessary.

Fourth, there would have needed to be enough resources flowing to the small college system to maintain quality. Not necessarily as much as research universities – small colleges require less for their mission. But enough to hire good faculty, acquire equipment, support innovation.

But here is the crucial point: none of this would have happened naturally or inevitably. It would have required choice – deliberate, sustained choice by many institutions and individuals to build and maintain an alternative system.

And I do not think that choice was made. I tried to make it, in my small way, at Clarke. ASCUE eventually embodied some of the principles. But there was no coordinated effort. There was no movement of small colleges saying: we are going to build a different kind of computer science culture, and we are going to protect it and nurture it and defend it against pressure to conform to the research university model.

So the hierarchy was not inevitable as a law of nature. But given how people actually behave, given the incentives they face, given the difficulty of maintaining alternative values in the face of dominant ones – yes, I suspect the hierarchy was almost inevitable in practice.

What I wonder is what computer science would look like if that choice had been made differently.

If there had been a strong, well-resourced, respected network of small colleges teaching applied, interdisciplinary, teaching-focused computer science, what would the field look like?

Perhaps computing education would be more widespread and more equitable. Perhaps more women would be participating in computer science, because small college environments might be less aggressively competitive and masculine. Perhaps more students from working-class backgrounds would have access to computing education. Perhaps computers would be seen more consistently as tools for serving communities rather than as engines for profit and disruption.

Perhaps the culture of computing would be different. Less focused on individual brilliance and competition, more focused on collaboration and service. Less focused on innovation for its own sake, more focused on solving real problems. Less hierarchical, more democratic.

Or perhaps these are just my hopes projected onto a counterfactual. Perhaps the forces that shaped computing are so fundamental that any alternative would have converged toward the same hierarchy anyway.

I do not know. But I suspect – I hope – that history was not completely constrained. That there were genuine alternative paths. And that the path we took, the hierarchy we built, reflected choices that could have been made differently.

You ask if the hierarchy was inevitable, or was it a choice?

I believe it was both. The hierarchy was not mechanically inevitable – the laws of physics do not require research universities to dominate computing. But it was socially and institutionally inevitable, given the incentives and values in place.

And I think that distinction matters, because it means the hierarchy could be different in the future. If people made different choices – if funding agencies chose to invest in small colleges, if professional organisations chose to value teaching, if students chose institutions based on different criteria, if faculty chose to stay in small colleges out of commitment to their mission – then the hierarchy could change.

But such change would require deliberate effort. It would require saying: the current hierarchy serves certain people and certain values, but not others. And we are going to build something different.

That is hard. That is why it did not happen in 1965 and why it has not happened since. But it is not impossible. It is a choice.

And maybe, in retrospect, that is the most important thing I can say about my own work. I tried to embody a different choice. At Clarke College, in my teaching, in my advocacy for ASCUE, in my belief that computing should serve human flourishing rather than prestige – I was trying to choose differently. I did not succeed in transforming the field. But I succeeded in creating a small space where different values could exist and be lived out.

That is not nothing.

Eva Silva, 45, Brazil | Applied Mathematics & Interdisciplinary Computing Researcher, São Paulo
Your four books showed matrix methods solving problems in graphics, circuits, food service, and Markov chains. But I’m curious about the failures – the applications where matrix methods didn’t elegantly translate, or where the same mathematics produced different insights depending on the domain. Were there problems you approached expecting matrix methods to be ‘the greatest interdisciplinary tool,’ only to discover that the abstraction broke down? And what did those failures teach you about the limits of generalisation across fields?

Eva, you have asked the question that separates the person who writes inspirational rhetoric from the person who does actual work. Yes. There were failures. There were many failures.

When I began writing the applications books in the early 1970s, I had become convinced – perhaps too convinced – of the power of matrix methods as a universal language for applied mathematics. I had seen how matrices could represent systems of linear equations, how they could describe transformations in space, how they could model transitions in probabilistic systems. The elegance of the approach seemed almost transcendent.

I thought: here is a language that can speak to engineers, to artists, to business managers, to mathematicians. Everyone can understand matrices – rectangular arrays of numbers with rules for combining them. And if you can translate your problem into matrix form, you can use powerful computational methods to solve it.

So I approached each application area with genuine optimism. I would think: what is the essential structure of this problem? Can I represent it as a matrix equation? If so, then computer programmes that solve matrix equations can solve this problem too.

Sometimes it worked beautifully. Graphics, especially. You can represent points in space as vectors, rotations and scaling as matrices, and the composition of transformations as matrix multiplication. It is elegant, and it is computationally efficient. Every computer can now do graphics because of this insight – that visual transformation can be reduced to matrix algebra.

But other applications…  other applications fought the abstraction.

Let me give you a concrete example. I was working with a colleague on applications of matrix methods to food service management. The idea was simple: you have a menu, you have nutritional requirements, you have costs, you have storage limitations. This is an optimisation problem. You want to find the menu that satisfies the constraints and minimises cost (or maximises nutritional value, depending on your priorities).

In principle, this is a linear programming problem. You can set it up as a system of linear equations and inequalities, solve it using matrix methods, and find the optimal menu. It seemed obvious.

And mathematically, it works. You can write down the constraints as matrix equations. You can use computational methods to find a solution.

But here is where it breaks down: the problem is not really a linear problem. Food is not purely nutritional. People care about taste, variety, cultural significance, tradition. A menu is not optimised purely on cost and calories. It is optimised on human satisfaction, on whether people want to eat it, on whether it builds community.

These human dimensions are not easily quantifiable, and they are certainly not linear. You cannot express “people enjoy variety” as a matrix equation. You cannot encode “this meal has cultural meaning” as a coefficient.

So what happened? We would solve the linear programme, get the mathematically optimal menu, and the result would be terrible. It would be nutritionally balanced and cheap, but it would be food that nobody wanted to eat.

We learned this lesson through implementation. We would present the results to food service managers, and they would say, “Nobody will eat this.” And they were right. The matrix abstraction had captured some dimensions of the problem but not the most important ones.

This taught me something crucial: matrix methods work well when the problem has certain properties. It needs to be linear, or at least approximately linear. It needs to be quantifiable – the things that matter need to be expressible as numbers. It needs to be stable – the structure of the problem needs to remain relatively constant. And it needs to be disconnected from human values in certain ways.

When you move into domains where nonlinearity is essential, where the important things are hard to quantify, where human judgment and preference matter as much as mathematical optimality – that is when matrix methods break down.

This is not a failure of matrix methods. It is a failure of my initial assumption that matrix methods could be universal. They are not universal. They are powerful for certain classes of problems.

I had other experiences like this. Electrical circuits, for instance – I thought matrix methods would elegantly capture the structure of circuits, the flow of current, the relationships between voltage and resistance. And they do, up to a point. For linear circuits, it is perfect. But real circuits often have nonlinear elements. The moment you introduce a nonlinear component – a transistor behaving in a nonlinear regime, or a diode – the clean matrix formulation breaks down.

With Markov chains, the matrix formulation worked beautifully. Markov chains are fundamentally about transitions between states, which is exactly what matrices represent. The stochastic matrix – the matrix of transition probabilities – captures the essential structure of the problem. That was one of the places where the abstraction held up perfectly.

Graphics, as I said, was also elegant. Because visual transformation really is linear algebra (in the projective sense), the abstraction captured the essence of the problem.

But food service? Scheduling problems with human constraints? System design that involved human decision-making? In those areas, the matrix abstraction was useful but incomplete.

So what did I learn from these failures?

First, I learned humility about abstraction. Abstraction is powerful – it allows you to see across domains, to apply tools from one field to another. But abstraction always obscures something. When you translate a complex real-world problem into mathematical form, you lose information. You lose the texture, the context, the human dimensions.

Sometimes that loss is acceptable. The things you lose are not important for solving the problem. But sometimes the things you lose are exactly what matters most.

Second, I learned that different domains have different mathematical structures, and those structures matter. Food service management is not the same kind of problem as electrical circuit analysis, even though both can be partially formalised with matrices. The irreducible complexity of the human and social dimensions makes food service a different kind of problem altogether.

This taught me that true interdisciplinary work requires more than finding a common mathematical language. It requires understanding each domain deeply enough to know where the abstraction works and where it fails. You cannot just parachute into food service management, apply matrix methods, and declare victory. You have to understand food, understand the people who prepare it and eat it, understand the culture and economics and human preferences involved.

Third, I learned that generalisation has limits. My vision of matrix methods as “the greatest interdisciplinary tool” was partly correct and partly naive. Matrix methods are a great tool for many problems. But they are not universal. No single mathematical framework is universal.

But here is something interesting: the failures themselves produced insights.

When I discovered that the optimal menu produced by matrix methods was inedible, that taught me something about the structure of food service as a domain. It taught me that optimisation is not always what you want. Sometimes you want “good enough” solutions that respect human preferences and cultural values. The mathematical solution is more optimal, but the human solution is more robust and more acceptable.

That insight – that mathematical optimality is not always the right goal – that became important in my later thinking. I started to ask: what are you actually trying to achieve? If you are trying to minimise cost and maximise nutrition, matrix methods will give you an optimal solution. But if you are trying to feed people well – to nourish them, to build community, to respect their preferences – then you need a different approach.

Similarly, working with circuits taught me that there are domains where the linear approximation works well enough that matrix methods are enormously valuable, even if the underlying physics is nonlinear. The insight is not that matrix methods fail on circuits, but that they work remarkably well as approximations, and you have to understand the domain well enough to know when the approximation breaks down.

And working across these different applications taught me that the same mathematical structure can have different meanings in different contexts. A matrix in graphics represents spatial transformation. A matrix in Markov chains represents probabilistic transition. A matrix in circuit analysis represents the relationships between voltages and currents. The mathematics is the same, but the interpretation is completely different.

This is what I meant by interdisciplinary computing – not that one mathematical tool solves all problems, but that the same mathematical language can be applied across domains, and by doing so, you can discover unexpected connections. A circuit designer might learn something from how graphics programmers think about transformations. A food service manager might learn something from how probability theory handles uncertainty.

Your question specifically asks about the limits of generalisation across fields. And I think the answer is this: you can generalise mathematical structures across fields, but you cannot generalise solutions or insights without understanding each field deeply.

I could teach the mathematics of matrices to someone with no background in food service, and they could set up a linear programme for a menu optimisation problem. But that person would not understand why the solution was wrong, why food service managers rejected it, what was missing from the formulation. That understanding requires domain knowledge.

So the generalisation is limited to the mathematical structure itself. The matrix formalism is domain-independent. But the wisdom about how to use that formalism, when it applies, where it fails – that is domain-dependent and requires deep contextual knowledge.

This is actually a lesson about the limits of my whole vision of computing as an interdisciplinary tool. Computing – the ability to manipulate symbols and automate processes – is genuinely interdisciplinary. You can use computers to solve problems in graphics, food service, circuit design, biology, history, anything. But the problems themselves are not discipline-independent. Each field has its own logic, its own values, its own ways of knowing.

So the role of computing is not to replace domain expertise with mathematical abstraction. It is to augment domain expertise. A food service manager who understands both food and mathematics and computing can use computers to help optimise menus, but only if the manager understands the limitations of the optimisation, understands what the abstraction has left out, understands where human judgment and preference have to override mathematical optimality.

I wrote those four books partly as proof of concept – to show that matrix methods could be applied across domains. But I was also aware, even then, that the books were incomplete. They showed you how to set up the problem mathematically. They showed you elegant solutions to simplified versions of the problem. But they did not fully address the question of what happens when you try to apply these solutions in the real world, where things are messier and more complex.

If I had had the chance, and the right collaborators, I would have written different books. Books that started with real problems in each domain, then gradually introduced mathematical and computational approaches, always maintaining awareness of what was being captured and what was being lost. Books that treated domain expertise as primary and mathematical abstraction as secondary.

That work was never done. I moved away from writing applications books toward teaching and administration. And the field moved in a different direction – toward more theoretical computer science, more pure algorithms, less engagement with real-world applications.

So those failures remain partly unresolved in my own work. I showed that matrix methods were widely applicable. I did not fully explore the question: when is it wise to apply them, and when should you rely on domain-specific approaches instead?

That is a question for the next generation of interdisciplinary researchers. And I hope they learn from both my successes and my failures.

---

Closing Reflection

Sister Mary Kenneth Keller died on 10th January 1985, at the age of 71, in Dubuque, Iowa. She had spent the previous twenty years building and directing the computer science department at Clarke College, mentoring hundreds of students, writing textbooks, and advocating tirelessly for the democratisation of computing education. She died before the personal computer revolution fully transformed society, before the internet became ubiquitous, before women in technology became a topic of urgent national conversation. She died in relative obscurity, her name absent from most histories of computer science.

Yet in this conversation – forty years after her death, conducted as a speculative dialogue grounded in historical evidence – Sister Keller emerges as a figure of remarkable clarity, persistence, and prescience. The interview and the letters reveal a woman far more intellectually nuanced and politically aware than the simplified narrative of “the first woman computer scientist” allows.

What This Conversation Reveals

On Perseverance Within Constraint: A powerful theme of this interview is how Sister Keller met genuine constraint without bitterness and refused to let it diminish her ambition. She earned her doctorate at fifty-one, in a language (FORTRAN) that was poorly suited to her intellectual work. She worked at a small college in the Midwest, far from computing’s prestige centres. She chose teaching over research, knowing full well that the field would not reward that choice. Yet she did not frame these circumstances as tragedy or failure. She framed them as the conditions within which meaningful work could be done.

This is different from resignation. It is not the voice of someone who compromised because she had to. It is the voice of someone who made deliberate choices aligned with her values, and who accepted the costs of those choices with clear-eyed awareness.

On the Ingenuity of the Constrained: The technical discussion of her dissertation reveals something equally important: the specific insights that emerge from working within constraint. Because FORTRAN forced her to think procedurally, because limited memory forced her to be efficient, because she lacked access to LISP and had to invent her own list-processing structures, she developed a hybrid approach – learning-by-example combined with rule-based validation – that was, in retrospect, quite sophisticated.

Constraint did not diminish her work. In some ways, it refined it. It made her think harder about why each piece of the algorithm mattered. It forced her to articulate the principles clearly because she had to implement them without the aid of convenient language features.

This is not an argument for celebrating unnecessary constraint. It is an observation that ingenuity often emerges in response to limitation, and that the problems we face in our work shape how we think about those problems. Sister Keller’s inductive inference algorithm bears the marks of FORTRAN, but in those marks are also insights that a researcher with unlimited tools might never have developed.

On the Overlooked Architecture of Knowledge: Throughout this conversation, Sister Keller emphasises something that rarely appears in histories of computing: the women, the educators, the people doing unglamorous work of building institutions and teaching students. Computing history focuses on breakthroughs, on individual geniuses, on elegant algorithms and innovative languages. It does not focus on the thousands of students who learned to programme at Clarke College, or the curriculum design that made that learning possible, or the NSF grant that provided the equipment, or the network-building that created ASCUE.

Yet that work – unglamorous, dispersed, institutional – is arguably more consequential for the long term than individual breakthroughs. Breakthroughs change what is possible. But institutions and education determine whether possibility reaches people.

Sister Keller’s story suggests that computing history has systematically undervalued the contributions of women precisely because those contributions so often took institutional and educational forms. Research is visible and credited. Teaching is invisible and forgotten.

Where This Account Differs from the Record

On the BASIC Question: Popular accounts often state or imply that Mary Kenneth Keller helped develop BASIC. This conversation clarifies that this is inaccurate. She learned BASIC at Dartmouth in 1961 and became a passionate educator and textbook author in the language. But she did not help create it. This correction matters because it protects the historical record and also protects the credit due to John Kemeny and Thomas Kurtz, who designed BASIC as an act of genuine democratic vision.

On the “First Woman” Designation: The historical record often presents Sister Keller as the singular “first woman” to earn a computer science Ph.D. in America. In truth, she and Irving C. Tang earned their doctorates on the same day – 7th June 1965. He received a D.Sc. from Washington University; she received a Ph.D. from the University of Wisconsin-Madison. They were the first two people in America to receive computer science doctorates. The simultaneous achievement should not be obscured by a narrative that privileges her as singularly exceptional.

Interestingly, in the interview, Sister Keller herself expresses discomfort with this simplification. She recognises that the focus on her as “the first woman” can flatten the history, making it seem as though Irving’s achievement is less remarkable, and creating a narrative of feminine exceptionalism that may not serve the larger cause of women in computing.

On Her Self-Awareness About Erasure: One of the most poignant aspects of this conversation is Sister Keller’s direct acknowledgment of her own invisibility in computing history. She does not present herself as a forgotten genius. She observes, with clear-eyed realism, why she has been overlooked: small college, teaching focus, BASIC’s declining prestige, textbooks rather than research papers, Midwest location, no corporate affiliation, death before the internet era, limited archival infrastructure at Clarke.

This self-awareness should not be read as self-deprecation. Rather, it demonstrates that Sister Keller understood the structures that produce visibility and invisibility in academic fields. She understood that her choices – to teach, to work at a small college, to focus on accessibility – would have consequences for her recognition. She made those choices anyway. That is a form of integrity.

Acknowledging Gaps and Uncertainties

This conversation is necessarily speculative. I have constructed Sister Keller’s voice based on documented facts about her life and work, the historical context of computing in the 1960s-1980s, the intellectual content of her dissertation and published textbooks, and the values that can be inferred from her choices. But I am not claiming to know her exact thoughts or to replicate her precise voice.

There are significant gaps in the historical record. Her dissertation is archived, but the full text is not widely circulated. Her papers at Clarke University may contain correspondence, lecture notes, or reflections that would provide more direct access to her thinking. Her colleagues and students from Clarke are now elderly or deceased; oral histories from those who knew her personally are scarce.

The interpretation of her motivations – why she chose Clarke, what she was thinking about BASIC and women in computing, how she understood her own work – is informed but not definitively documented. I have tried to construct plausible interpretations based on her documented choices and the era’s constraints, but reasonable historians might disagree about specific claims.

Contested interpretations also persist. How much of her relative obscurity is due to her location at a small college, and how much is due to changing fashions in computing (BASIC becoming unfashionable)? How much was shaped by her gender, and how much by her choice of institutions? These are complex causal questions with no simple answers. This account offers one interpretation grounded in evidence, but it is not the only possible interpretation.

The Speculative Nature of Historical Fiction

I want to be direct about what this conversation is and is not.

This is not a direct transcript of Sister Keller’s words or thoughts. I am not claiming to channel her voice from beyond death or to know with certainty what she would say in 2025. It is a work of historical imagination, grounded in documented evidence and aimed at historical plausibility.

What this conversation is: an attempt to use the tools of empathy and narrative to make her achievements visible to a contemporary audience. It is an act of historical recovery, undertaken with fidelity to the facts of her life as we know them, and with respect for her documented values and intellectual concerns.

The goal is not to speak for Mary Kenneth Keller in a way that silences her true voice. Rather, it is to use historical fiction as a platform from which her documented struggles and achievements can be heard. The alternative – silence, erasure, allowing her to remain a footnote or a curiosity in computing history – seemed worse.

On Authority and Perspective

I should acknowledge that this work has been created by a male author. Some readers may fairly ask: why should a man write extensively about a woman’s life and work? What authority do I have?

My response is simple: the primary responsibility is not to the author, but to the subject. My role is that of a researcher, advocate, and storyteller. My job is fidelity to Mary Kenneth Keller’s story – to the facts of her life, to the values she documented, to the insights her work contains. That job belongs to whoever is best positioned to do it well, regardless of gender.

The alternative is silence. If we wait for the perfect person to tell her story – if we allow questions of who has the “right” to tell it to prevent the story from being told at all – then we abandon her to obscurity. That seems worse than accepting the imperfection of a male storyteller’s interpretation.

Ideally, future historians and biographers – particularly women scholars – will refine, challenge, and expand upon this account. They will have access to sources I do not, perspectives I cannot bring, insights born from different lived experience. Their work will be invaluable. But that work happens after the initial recovery. It builds on the foundation of bringing the story into the light.

Contemporary Resonance: Where Her Work Still Matters

Computer Science Education in Crisis: Sister Keller’s founding of a CS department at a small college in 1965 addressed a problem that has only intensified: how to expand access to computing education. Today, computer science education faces a crisis. Demand vastly exceeds supply. Elite programmes turn away qualified applicants. Meanwhile, students at less prestigious institutions struggle to access quality CS education.

Sister Keller’s model – build capacity at smaller, less prestigious institutions; focus on teaching and access; emphasise application and interdisciplinary work – remains profoundly relevant. We have not followed her model; instead, we have concentrated resources at elite universities. The result is a bottleneck that excludes most students who want to learn computing.

Women’s Declining Participation: Sister Keller earned her doctorate in 1965, when women made up a substantial portion of computing programmers. By 1985, when she died, that percentage had begun to decline. Today, women make up roughly 20% of CS majors, down from approximately 35% at the time of her death.

What happened? Part of the answer lies in the masculinisation of computing culture – the shift from seeing programming as meticulous detail work suitable for women to seeing it as a masculine domain of lone geniuses and competitive “bros.” Part of the answer lies in the institutional choices about where to locate CS education (elite universities, often male-dominated) and what values to emphasise (difficulty and prestige rather than accessibility and application).

Sister Keller’s work at Clarke, a women’s college, suggests an alternative. Women’s colleges historically produced disproportionate numbers of women scientists. Yet co-education is often assumed to be superior. Sister Keller’s legacy suggests the value of spaces where women can engage in technical work without the pressure of masculine competition and culture.

The Interdisciplinary Computing Vision: Sister Keller declared in 1975 that computers were “the greatest interdisciplinary tool that has been invented to date.” Forty years later, that vision has been partly vindicated and partly neglected. Digital humanities, computational biology, data journalism, computational chemistry, data-driven history – all of these emerged after Sister Keller’s death, all demonstrating her insight that computing is fundamentally interdisciplinary.

Yet CS departments often remain insular, focused on pure theory rather than applications. The prestige hierarchy she observed – theoretical work valued, applied work devalued – persists. Her books applying matrix methods to graphics, circuits, food service, and Markov chains remain pedagogically valuable but professionally devalued. Her vision of computing as a tool for diverse fields is vindicated in practice, even as it remains devalued in academic prestige.

Educational Technology and Access: Sister Keller believed computers could democratise access to information and education. The internet and digital tools have partly realised that vision – online education, open educational resources, global access to knowledge. But we have also seen the opposite: surveillance capitalism, digital divides that reinforce existing inequalities, concentration of computing power in the hands of a few corporations.

The question Sister Keller implicitly posed remains urgent: will computing be a tool for access and equity, or for profit and control? Her advocacy for accessible education, for interdisciplinary application, for seeing technology as in service to human flourishing – these values are needed now more than ever.

The Afterlife of Her Work: Who Built on Her Contributions

The recovery of Sister Keller’s contributions is surprisingly recent. For decades after her death, she remained a footnote. But in the last fifteen years, a rediscovery has begun.

In 2015, the Computer History Museum and the IEEE began recognising her contributions more prominently. Academic papers examining women in early computing history have cited her dissertation and textbooks. Wikipedia, despite its limitations, now includes her biography. Articles in popular outlets like Mental Floss and Omnes magazine have brought her story to wider audiences.

More importantly, her direct intellectual descendants persist. The Association of Small Computer Users in Education (ASCUE), which she helped found and lead, continues to operate. Clarke University (formerly Clarke College) maintains the Keller Computer Center and the Mary Kenneth Keller Computer Science Scholarship. Students continue to study in spaces she shaped.

Her dissertation work on inductive inference – learning patterns from examples – has gained unexpected relevance. As machine learning and deep learning have become central to AI, researchers have begun to recognise that Sister Keller’s 1965 approach to learning from data anticipated modern methods. Her work is not directly cited in most deep learning papers, but the principles she explored remain foundational.

Her textbooks, though out of print, are valued by historians and by educators seeking alternative approaches. Her integration of matrix methods across diverse domains prefigures modern interdisciplinary computing. Her pedagogy – accessible, application-focused, emphasising concrete understanding over abstract theory – remains relevant to educators frustrated with traditional CS curricula.

What Her Legacy Means for Women in Science Today

For young women pursuing paths in STEM, Sister Keller’s life offers several profound lessons.

First: visibility matters, and its absence is not your fault. Sister Keller was remarkable, but she was also overlooked. That oversight was not a reflection of her quality or importance. It was a result of structural factors – institutional location, choice to emphasise teaching, gendered values in academia. Knowing this can be liberating. It means that if your work is not recognised, you should look critically at the systems that shape recognition, not assume you are doing something wrong.

Second: values matter as much as achievement. Sister Keller chose to teach at a small college, to prioritise access over prestige, to advocate for interdisciplinary computing over pure theory. These choices cost her recognition. But they also meant that her work was aligned with her deepest convictions. That alignment is rare and valuable. It is worth the cost.

Third: the path that seems unconventional or marginal may be exactly right for you. Sister Keller did not follow the expected trajectory: doctorate at a young age, position at a research university, publication-focused career. Instead, she took an alternative path: gradual education, small college, teaching and institutional building. That path worked for her, and it enabled contributions that would not have been possible on the conventional track.

Fourth: mentor and be mentored. Sister Keller was mentored by her religious community, by teachers who believed in her, by colleagues like Thomas Kurtz. She, in turn, mentored hundreds of students. That cycle of mentorship – being supported and then supporting others – is how change happens. Young women in STEM should seek mentors, particularly senior women and men who understand the specific challenges of their fields. And as they advance, they should return that support to others.

Fifth: the work of building institutions and teaching is as important as individual achievement. Our culture celebrates the brilliant researcher or the charismatic leader. But the patient work of building departments, training students, creating networks, sharing knowledge – that is equally vital. Sister Keller’s greatest legacy is probably not her dissertation but the students she trained and the institution she built.

The Spark That Remains

Forty years after her death, Sister Mary Kenneth Keller still has much to teach us. Not as a distant historical figure, but as a presence in the ongoing questions that define our era.

How do we expand access to computing education in an age of overwhelming demand and finite resources? How do we create spaces where women and underrepresented groups can thrive in technical fields? How do we ensure that computing serves human flourishing rather than profit extraction? How do we value teaching and institutional work alongside research and individual achievement? How do we maintain ethical standards and human-centred values as technology becomes more powerful?

Sister Keller did not answer these questions definitively. But she lived them. She chose access over prestige. She emphasised teaching over publication. She saw computers as tools for human flourishing. She built institutions where women could learn and lead. She advocated for interdisciplinary work in the face of narrow specialisation. She believed that computing should be for everyone, not just the elite.

These choices, made in the 1960s and 1970s, echo into the present. They challenge us to ask: are we making better choices? Are we learning from her example, or are we repeating the mistakes she identified – concentrating resources at elite institutions, valuing research over teaching, treating computing as a specialist domain rather than an interdisciplinary tool, losing women and marginalised groups through masculine culture and gatekeeping?

The recovery of Sister Mary Kenneth Keller’s story is not historical archaeology. It is an invitation. It is her continuing conversation with those who inherit both her legacy and her unfinished work. And it is a reminder that the people who transform fields are not always the ones whose names appear in textbooks. Sometimes they are the quiet builders, the patient teachers, the advocates for access, the women whose choices made space for others to flourish.

In remembering her, we do not just honour the past. We make visible the roads not taken and the possibilities that remain open. We recognise that history is not destiny. The hierarchy and values that shape computing today – they were choices, made by many people, and they can be chosen differently.

That is the spark Sister Keller leaves us with: the knowledge that alternatives are possible, and the responsibility to imagine and build them.

---

Editorial Note

What This Document Is

This interview with Sister Mary Kenneth Keller is a dramatised reconstruction, not a historical transcript. It is a work of informed historical imagination, created with fidelity to documented evidence but presented in a conversational form that did not exist during her lifetime.

Sister Mary Kenneth Keller died on 10th January 1985. This interview is presented as if it took place on 16th December 2025 – forty years after her death. The interviewer and the five questioners (Chloe Bennett, Kenji Sato, Sara Hassan, Eva Silva, and Leo Schmidt) are fictional constructs, chosen to represent diverse international perspectives and areas of expertise relevant to Sister Keller’s work.

The words attributed to Sister Keller in this document are not her direct words. They are a plausible reconstruction of what she might have said, based on extensive research into her life, work, historical context, and documented values.

The Sources and Methods

The reconstruction draws on the following documented sources:

Primary Sources:

• Sister Keller’s dissertation, “Inductive Inference on Computer Generated Patterns” (University of Wisconsin-Madison, 1965)
• Her published textbooks on matrix methods, BASIC programming, and applied mathematics
• Her curriculum materials and teaching documents from Clarke College
• Historical records of the Association of Small Computer Users in Education (ASCUE)
• Interviews and biographical sketches published by Clarke University and the IEEE
• News articles, obituaries, and historical essays about her life and work

Secondary Sources:

• Academic literature on the history of computer science and women in computing
• Scholarly work on early programming education and BASIC language pedagogy
• Historical accounts of computing in the 1960s-1970s, including the institutional development of computer science as a discipline
• Biographies and memoirs of her contemporaries (Thomas Kurtz, John Kemeny, and other early computing pioneers)
• Historical analysis of gender in STEM fields and the decline of women’s representation in computer science

Contextual Research:

• The social, institutional, and cultural context of American higher education in the 1960s-1980s
• The history of small liberal arts colleges and Catholic women’s colleges in American education
• The role of religious communities in advancing women’s education and scientific training
• Regional computing history, particularly the development of computing at institutions outside coastal prestige centres

How the Dialogue Was Constructed

The interview follows a structure designed to reveal multiple dimensions of Sister Keller’s thinking:

1. Technical Depth: The discussion of her dissertation work on inductive inference, algorithm design, and the constraints of FORTRAN reflects careful analysis of her actual intellectual contribution, grounded in the mathematics and computing concepts she engaged with.
2. Historical Context: Sister Keller’s responses reference actual people (Thomas Kurtz, John Kemeny, Irving C. Tang), actual events (the Dartmouth summer programme, the formation of ASCUE, NSF grants to Clarke), and actual institutions. Where specific names or details are uncertain, the responses either acknowledge this uncertainty or avoid false precision.
3. Documented Values: Her statements about the importance of access, the value of teaching, the interdisciplinary potential of computing, and the democratisation of information reflect values that can be inferred from her choices, her published work, and the accounts of those who knew her.
4. Era-Appropriate Language: The dialogue uses language, references, and thought patterns appropriate to someone born in 1913 and educated in the 1930s-1950s. Contemporary idioms are avoided unless the interviewer uses them (signalling that they are the interviewer’s words, not Sister Keller’s).
5. Intellectual Honesty: The reconstruction includes moments where Sister Keller expresses uncertainty, acknowledges mistakes and contradictions. These moments are not invented to add false complexity; rather, they reflect genuine tensions evident in her work and choices.

What Is Speculated vs. What Is Documented

Documented Facts:

• Her birth date, death date, and biographical outline
• Her educational credentials and degrees
• The substance of her dissertation work
• Her role in founding Clarke’s computer science department
• Her involvement with BASIC programming education
• Her textbook publications
• Her involvement with ASCUE
• The NSF grant to Clarke College
• Her 1975 statement about computers as “the greatest interdisciplinary tool”

Reasonably Inferred (Based on Evidence):

• Her motivations for choosing Clarke College over research universities
• Her intellectual position on the relationship between teaching and research
• Her understanding of the gendering of accessibility in computing
• Her awareness of her own invisibility in computing history
• Her views on the value of interdisciplinary work and applied computing

Speculated (Presented as Plausible Reconstruction):

• Her exact words, phrasing, and conversational tone
• Her internal reflections on specific moments in her career
• Her detailed technical reasoning about the choices she made in dissertation design
• Her thoughts on contemporary events or trends in computing
• Her responses to specific hypothetical questions posed by the fictional interviewers

The boundary between “inferred” and “speculated” is sometimes blurred. The responses about her views on gendered labour, for instance, are rooted in documented statements and choices, but the specific articulation of those views in conversational form is reconstructed. A reader should understand that the ideas are grounded in evidence, but the precise formulation is created for this dialogue.

The Five Questioners: Why Fictional Voices

The five follow-up questions are presented as if they came from real people in different countries and professions. In fact, these are fictional constructs designed to represent important perspectives and areas of inquiry.

This fictional framing serves several purposes:

1. Diversity of Perspective: The questioners represent different nationalities, genders, ages, and professional backgrounds. This variety ensures that the questions approach Sister Keller’s work from multiple angles rather than a single viewpoint.
2. Thematic Coverage: Each questioner was designed to draw out different dimensions of her work – technical decisions, gendered values, failures and limitations, historical counterfactuals, and domain-specific applications.
3. Plausibility: Rather than presenting a list of questions followed by answers, the fictional framing makes the dialogue feel more natural and allows for contextualisation. Each questioner can briefly explain why they are asking their particular question.
4. Protection of Privacy: By making these fictional rather than attributing them to real people, the reconstruction avoids misrepresenting actual living individuals or attributing words to them that they did not write.

The reader should understand that while the questioners are fictional, the questions themselves are intellectually serious and grounded in genuine scholarly and pedagogical concerns about Sister Keller’s work.

What This Reconstruction Is Not

This interview is not:

• A transcript of an actual recorded conversation
• A transcript of interviews that could be accessed if researchers looked harder
• A claim to access her private thoughts or inner life beyond what can be reasonably inferred from evidence
• A biography meant to supersede or replace scholarly historical work
• A definitive account of her views or contributions
• A complete representation of her personality or character

This reconstruction is not claiming to do the work of rigorous biography or historical scholarship, though it is informed by such work. Biography requires access to extensive archival materials, oral histories from people who knew the subject, and years of dedicated research. This work is a shorter, more interpretive piece aimed at a broader audience.

Ethical Considerations

In creating a dramatised reconstruction of a historical figure who cannot speak for herself, several ethical principles guided the process:

1. Fidelity to Evidence: Every claim is grounded in documented sources or reasonable inference from those sources. Inventions are minimised, and where they occur, they are presented in contexts (like the fictional questioners) where the reader understands the speculative nature.
2. Respect for Complexity: Sister Keller is presented as intellectually sophisticated, morally serious, and capable of nuance and self-criticism. She is not simplified into an inspiring narrative or a victim narrative.
3. Acknowledgment of Gaps: This reconstruction acknowledges what we do not know about her thinking, motivations, and life. It does not attempt to fill every gap with invention.
4. Attribution of Values: Her stated values (about access, teaching, the democratisation of computing) are drawn from her documented choices and published work. These are not attributed without basis.
5. Avoidance of Appropriation: This reconstruction does not attempt to “give voice” to Sister Keller in a way that silences her actual voice or pretends to replace scholarship with fiction. Rather, it attempts to create a platform through which her documented work and values can be understood by contemporary readers.
6. Transparency About Perspective: This reconstruction is created from a particular perspective – that of a male researcher and writer, informed by historical sources but not shaped by lived experience of the specific barriers Sister Keller faced as a woman and a nun in computing. That perspective shapes what can be understood and what may be missed.

How to Read This Reconstruction

We recommend approaching this interview with the following understanding:

• Use it as an entry point, not as a final authority. If Sister Keller’s work interests you, consult the primary sources – her dissertation, her textbooks, the historical records. This reconstruction points toward those sources.
• Distinguish between documented facts and reconstructed dialogue. The biographical outline is accurate; the conversational form is created for readability and engagement.
• Read the responses with awareness of historical context. Sister Keller’s thinking was shaped by the computing landscape of the 1960s-1980s, the institutional constraints of small colleges, the culture of Catholic higher education, and the gender dynamics of her era. Her views should be understood within that context.
• Engage with the ideas, not just the persona. The value of this reconstruction lies in exploring the intellectual questions that defined her work – the relationship between induction and deduction, the role of abstraction in applied mathematics, the tension between access and prestige in education, the gendering of labour and values.
• Consider what questions remain unanswered. This reconstruction raises important historical questions that scholars should pursue: fuller archival research at Clarke University, oral histories from her students and colleagues, deeper analysis of her intellectual influence on contemporary computing education.

The Responsibility of Historical Reconstruction

Creating a dramatised dialogue with a historical figure carries responsibility. It is easy to project contemporary values onto the past, to simplify complex figures into symbols, to use historical narratives to advance present-day agendas.

This reconstruction has attempted to avoid these pitfalls by:

• Grounding every major claim in evidence
• Acknowledging uncertainty and complexity
• Presenting Sister Keller as thoughtful and critical, not simply as a martyr or a hero
• Allowing her documented values to speak rather than imposing external meanings
• Being transparent about what is speculated versus what is documented

But imperfection is inevitable. Future scholars may uncover archival materials that complicate or contradict interpretations offered here. Readers from backgrounds different from the author’s may perceive dimensions of Sister Keller’s experience and significance that this reconstruction misses. Those challenges will be valuable. They will deepen historical understanding.

The goal of this reconstruction is not to have the final word on Mary Kenneth Keller. It is to bring her story into conversation with contemporary concerns about computing education, gender in STEM, the value of teaching, and the ethics of technology. It is to create a platform from which her documented contributions can be heard and her unfinished questions can continue to challenge us.

In reading this dialogue, you are engaging with a work of historical imagination informed by rigorous research, not a historical transcript or a substitute for scholarly biography. We encourage you to read critically, to check claims against sources, and to pursue deeper inquiry into Sister Keller’s actual papers, publications, and the historical record. That ongoing work of recovery and scholarship is where the true authority lies.

---

Who have we missed?

This series is all about recovering the voices history left behind – and I’d love your help finding the next one. If there’s a woman in STEM you think deserves to be interviewed in this way – whether a forgotten inventor, unsung technician, or overlooked researcher – please share her story.

Email me at voxmeditantis@gmail.com or leave a comment below with your suggestion – even just a name is a great start. Let’s keep uncovering the women who shaped science and innovation, one conversation at a time.

---

Bob Lynn | © 2025 Vox Meditantis. All rights reserved.