Carnap Ten Years Later: Lessons Learned and Next Steps

Imagine you're trying to teach a class of 45,000 students how to solve logic puzzles. You want them to practice every day, but grading thousands of handwritten proofs by hand is a nightmare. So, you build a robot teacher.

That's exactly what Graham Leach-Krouse did with Carnap, a web-based tool that has graded over four million logic problems for students worldwide over the last decade. But after ten years of running this robot, the author realized the robot was getting a bit clumsy, and it's time to build a brand-new, super-sleek version.

Here's the story of what went right, what went wrong, and the shiny new tools being built to fix it.

The Original Robot: A Bit of a Messy Genius

The original Carnap was built like a giant, all-in-one Swiss Army knife. It was written in a very fancy programming language called Haskell. The author wanted it to be free (no cost for students), web-based (no annoying software installations), and flexible (able to teach any kind of logic, from simple math to complex philosophy).

What worked:

• The Web: Putting it on a website was a huge win. Students didn't have to fight with installation screens; they just clicked a link.
• The Feedback Loop: The best part was the "instant feedback." As a student typed a proof, the robot checked it line-by-line. If they made a mistake, it said "Nope, try again" immediately. This kept students in a "flow state," where they felt like they were playing a game rather than doing homework.
• The Flexibility: The author used a clever trick (called Huet's algorithm) to let the robot understand dozens of different logic textbooks. It was like having a translator that could speak every dialect of logic instantly.

What didn't work:

• The "All-in-One" Trap: The author tried to do everything in one big block of code. The part that drew the pictures, the part that checked the math, and the part that saved the grades were all tangled together. If you wanted to fix a tiny bug in the math checker, you might accidentally break the grade-saving system. It was like trying to fix the engine of a car while the wheels were still spinning.
• The "Bus Factor": Because the code was so tangled and used a very specific, hard-to-install setup, it was almost impossible for other people to help. If the main builder got hit by a bus (a classic programmer joke about losing the only person who knows how the system works), the project might have died.
• The Trust Issue: Students need to trust the robot. If the robot glitches, gives a confusing error message, or acts weird, students stop trusting the logic itself. They start thinking, "The robot is broken," instead of "I made a mistake." The original system had too many little glitches that broke this trust.

The Diagnosis: Why the Old Robot Needs Retirement

The author looked at the old system and realized it was built on a "dual-monolith" architecture. Think of it like a house where the kitchen, the bedroom, and the bathroom are all one giant room with no walls. You can't renovate the kitchen without knocking down the bathroom.

The specific trouble was the technology used to run it in the browser. The author used a tool called GHCJS to turn the fancy code into web code. But that tool is now "deprecated" (basically, it's been retired by its creators). Trying to update the old system would be like trying to replace the engine of a car with a part that doesn't fit anymore. It would be painful, expensive, and likely to fail.

The New Design: The "Modular" Dream

The paper proposes a complete redesign, splitting the giant robot into three specialized, tiny robots that talk to each other.

1. The Tiny Verifier (mm0-zig): This is the "brain" that checks if a proof is actually correct. It's written in a new language called Zig and is incredibly small—only about 4,500 lines of code. Because it's so small, a human can read the whole thing and say, "Yep, this is trustworthy." It's designed to check proofs in a flash (under 200 milliseconds for a huge library of math).
2. The Compiler (Aufbau Bytecode Compiler or abc): This is the "translator." It takes the messy, complex way a student types their proof (maybe using a fancy visual editor) and turns it into a clean, binary certificate. It doesn't care how the student wrote it; it just makes sure the final result is valid.
3. The Server: This is just the "filing cabinet." It stores the assignments and grades. It doesn't do any heavy thinking; it just manages data.

The Magic of the New System:

• No More Tangled Wires: If you want to add a new type of logic (like a new textbook), you don't have to rewrite the brain or the filing cabinet. You just give the compiler a new set of rules.
• Trustworthy: The "brain" (mm0-zig) is so small and simple that it can be audited by a single person. Once it's checked, it never needs to change.
• Fast: The new verifier is almost as fast as the original C-based version, running at about 7.1 milliseconds on average for a specific test case (compared to 6.1 milliseconds for the old one), which is fast enough to feel instant to a human.

The Future: What's Next?

The author admits that the new system isn't finished yet. Right now, the "translator" (abc) works best with a text editor, which might still be too scary for a beginner in their first logic class. The plan is to build richer visual interfaces (like drag-and-drop proof trees) that talk to the translator.

The big lesson here isn't just about code; it's about trust. Whether you are a student, a teacher, or a coder, you need to trust the tool you are using. The old Carnap was a hero that got the job done, but it was messy. The new Carnap is being built to be lean, mean, and transparent, so that students can focus on the logic, not on fighting the software.

In short: The old robot was a brilliant but messy genius. The new robot is a team of specialized, trustworthy experts, ready to help the next generation of thinkers escape the gravity of confusion and reach "escape velocity" in their own reasoning.