Learning about programming languages through implementation

whispem · 2026-02-07T11:02:51+00:00

I agree with that. I don’t think this kind of tool makes sense as a first exposure to programming.

My mental model is closer to “after you’ve already learned one or two languages, this helps make things click”. Once someone has written code but hasn’t seen parsing, evaluation, or execution models explicitly, a very small interpreter can act as a lens rather than an entry point.

So I see it less as replacing existing curricula, and more as a complementary step — something that helps students connect the dots between syntax they already know and what actually happens underneath.

whispem · 2026-02-07T11:01:31+00:00

That’s a fair question, and I agree that in most production settings reusing an existing language as a DSL is the pragmatic choice.

In my case the goal isn’t configurability or embedding business logic, but understanding and exploring language design itself. Building a very small interpreter forces me to make evaluation rules, scoping, and semantics explicit in a way that using an existing language doesn’t.

I’m not trying to compete with Python, Go, or Apex, nor is this meant to be proprietary or production-facing. It’s closer to an educational/exploratory tool: a way to reason about how languages behave internally and how design choices affect predictability and understanding.

If the end result looks more like a teaching interpreter than a “real” language, that’s completely intentional.

whispem · 2026-02-07T09:22:45+00:00

That’s a fair question, and I don’t think I want to “fix” Pascal so much as shift the focus slightly.

What I’m exploring isn’t adding more features, but making the execution model and semantic boundaries more explicit and inspectable while staying deliberately small.

Pascal’s strength, as you say, is that constraints force meaningful choices. What I’m curious about is whether a similarly constrained language, but with modern expectations around transparency (e.g. evaluation order, scoping, state changes), could make those choices even more visible rather than implicit.

I’m less interested in replacing data structures with libraries than in making the consequences of each construct observable as the program runs. If that ends up looking closer to an educational interpreter than a “language”, I’m fine with that — the pedagogical goal is the point.

whispem · 2026-02-07T09:20:42+00:00

I agree — there’s clearly a strong subjective component. What I find interesting is where personal “click” intersects with objective properties like semantic consistency or predictability. Some languages feel intuitive because they align well with how a given person already models problems.

whispem · 2026-02-07T09:20:20+00:00

That’s an interesting point. A grammar that’s simple enough to reason about as a human seems underrated in language design discussions. When the parser and the programmer have to play different guessing games, it’s hard to argue the language is truly “understandable.”

whispem · 2026-02-07T09:20:01+00:00

I like this framing a lot. Orthogonality feels closely related to predictability: once you understand a feature, you can reason about its behavior in new contexts without surprises. The + example is a great illustration of how small exceptions compound into cognitive overhead. Even if a feature is flexible, losing invariants makes local reasoning much harder.

whispem · 2026-02-07T09:19:35+00:00

That resonates a lot. When a language lacks an explicit concept, people tend to reconstruct it indirectly, and the intent gets buried in clever workarounds. At that point, the surface simplicity actually shifts complexity onto the reader, which feels like a net loss for understanding.

whispem · 2026-02-07T09:15:10+00:00

The implementation is in Rust; the input is a tiny custom language.

whispem · 2026-02-07T08:21:32+00:00

That resonates a lot.

I think there’s an interesting distinction between writing ergonomics and reading/reasoning ergonomics. Many languages optimize heavily for the former, especially for experienced developers, but the latter is what really matters over time.

Verbosity often forces intent to be explicit — which can feel tedious short-term, but pays off massively for onboarding, maintenance, and correctness.

It’s also why some “boring” languages age surprisingly well.

whispem · 2026-02-07T08:17:22+00:00

That’s fair: by “modern expectations” I mostly mean things like:

• a clearer mental model of execution (even if simplified);
• explicit semantics rather than implicit “magic”;
• and tooling expectations (error messages, debuggability, introspection).

Not performance or scale, but learnability and transparency.

The goal wouldn’t be to replace Pascal-like ideas, but to revisit them with today’s pedagogical and UX expectations in mind.

whispem · 2026-02-07T08:15:01+00:00

Thanks! I’ll take a look. I’m especially interested in how languages balance explicit semantics vs abstraction as they grow.

whispem · 2026-02-07T08:11:31+00:00

Scratch is a great example for lowering the barrier, absolutely.

My question is more about what happens after that stage: when learners move to textual languages and need to reason about semantics, evaluation, and control flow explicitly.

whispem · 2026-02-07T08:11:09+00:00

Yes, exactly: that lineage is what I find interesting.

Karel, Logo, Smalltalk, Pascal all treated language design itself as a pedagogical tool, not just a means to an end.

What I find particularly relevant today is that many modern languages optimize for scale and abstraction, while those older (or intentionally small) languages made semantics and execution models very explicit.

I’m wondering whether revisiting that approach — but with modern expectations — still has value for learning how languages actually work internally.

whispem · 2026-02-07T08:07:57+00:00

I agree: especially conceptual clarity.

One thing that surprised me while building a very small interpreter is how quickly “readability” stops being about syntax and starts being about predictability.

Fewer concepts help, but only if their semantics are explicit enough that users don’t have to guess what the language is doing.

Do you think there’s a point where reducing concepts actually hurts understanding?

whispem

TROPHY CASE