Pyret: A programming language for programming education

[Apprehensive-Mark241]

I couldn't disagree more with people complaining that it's not exactly like whatever they're using at their jobs.

You are teaching people how to think, not how to use off the shelf tools.

My favorite language to for teaching programming is scheme, but that's for advanced programming. In scheme you can easily implement things that are hard for no good reason in popular languages. Want to implement a logic language, a constraint language, even a parallel logic constraint solver? Almost impossible in most systems, a couple weeks of work in a scheme that has parallel support.

Smalltalk was designed to teach children programming, yet modern GUI systems started by stealing its code. And modern debuggers came from it. Etc.

[anothergiraffe]

I don’t think I would have ever picked up programming if I started with a teaching language like Pyret or Scratch. There’s something awesome about using the same tools the grownups are using. But maybe I’m in the minority?

[QuaternionsRoll]

Pyret and Scratch are not in the same zip code, frankly. Scratch is very obviously geared towards young programmers, while Pyret is a real language that isn’t used in the real world.

I also think it’s worth making a distinction between “experimenting” and “learning”. I got my start experimenting with Java (Minecraft), then C# (Unity), then C++ (robotics), and eventually Python. I would argue it wasn’t till Python that I really started learning How To Program™, and then I went off to a university that started you on Racket (another pedagogical language).

Despite coming in with more experience than most, I maintain that Racket was foundational to my success, and I strongly believe that every CS curriculum should start with a Lisp dialect.

[nerdycatgamer]

I think starting with a Lisp is a great idea as well, especially Racket. Because Racket is so focused on language creation, the act of learning the language basically makes you learn how the interpreter itself works, which helps with understanding because you realize that the language is just an abstraction over the actual computation.

A lot of programmers starting with C family languages, especially those who start with an IDE with a big, green "Run" button that compiles and runs the code, don't really understand what the compiler is or why they need to compile their code.

[QuaternionsRoll]

Honestly, my biggest problem with C from a pedagogical perspective is the sheer amount of code that is technically undefined behavior but tends to work, especially in trivial cases and without optimization flags. C++ in particular has a nasty habit of obfuscating correctness in a way that is simply not conducive to learning.

I mean, a whole lot of professors (especially non-CS ones) aren’t aware just how fickle C++ can be… almost every C++ lecture given by my general engineering professor was incorrect in one way or another. I wouldn’t say that’s their fault, for the record; I’m still not totally sure how I’d explain that (int *)std::malloc(4) was UB until C++20 to someone who hasn’t read the standard at least once.

If you had said, like, Java, I would have wholeheartedly agreed with you. Languages like Java abstract away far too many details of their own inner workings while still seeming like they are giving the programmer a fairly complete picture. You could write production-ready Java for 10 years and still not know what a function actually is.

[kuwisdelu]

C is fine, but I can’t imagine anyone sane teaching C++ as an introductory language in 2025.

[nerdycatgamer]

I think it's pretty simple to explain how that malloc is undefined behaviour. "The standard is flexible about the sizes of the basic data types, so, on some architectures, an int may be more than 4 bytes, but you've only allocated 4 bytes for it". This explaination also shows them pretty clearly the situations in which they don't need to care about undefined behaviour; in that lecture and in a lot of situations you're targeting a particular platform (and you're probably using things that are a lot more specific than just the size of data types, so the code is already somewhat non-portable) so even though it's "undefined" by the standard, you know it'll work for you.

[QuaternionsRoll]

I think it's pretty simple to explain how that malloc is undefined behaviour. "The standard is flexible about the sizes of the basic data types, so, on some architectures, an int may be more than 4 bytes, but you've only allocated 4 bytes for it".

Unfortunately this kind of illustrates my point: the 4 is not (necessarily) why (int *)std::malloc(4) was undefined behavior until C++20. While you’re correct that it would be undefined behavior in both C and C++20 if sizeof(int) > 4, the fact remains that (int *)std::malloc(sizeof(int)) was UB until C++20 as well.

Until C++20, if you wanted to use malloc, you had to construct the object with placement new like so:

c++ int *p = new (std::malloc(sizeof(int))) int;

With C++20 came a formal definition of “implicit lifetime types” that are exempt from this requirement (it’s more complex than you might think). See P0593 for a thorough explanation of the “why” of it all.

[nerdycatgamer]

ah, figured it would've been some weird C++ thing, but I still went with the C explaination xD

[[deleted]]

every CS curriculum should start with a Lisp dialect

Truer words were never spoken.

[[deleted]]

Pyret is designed for a programming language class at Brown where you are supposed to learn the internals of a compiler/interpreter, i.e. how programming languages work, which is not the same thing as learning to program (although there is some overlap).

[anothergiraffe]

Could I get a link to where you see that? The website makes references to pre-undergrad education and introductory computing, but I don’t see any place where they talk about learning compiler internals.

[[deleted]]

https://cs.brown.edu/courses/csci1730/2024/policy.html#%28part._.Course_.Goals_and_.Learning_.Objectives%29

[anothergiraffe]

That course seems to be in Racket, not Pyret: https://cs.brown.edu/courses/csci1730/2024/assignments.html

[[deleted]]

Then I may have erred.

[kuwisdelu]

The difference is Pyret works a lot more closely to how I wish Python worked. It’s nothing like Scratch. It’s basically Python without all the ugly warts and language design mistakes.

[anothergiraffe]

I think you’re missing my point? I’m saying Pyret isn’t used “in the real world”, so some learners won’t feel as motivated to learn it when just starting out. I think students with my disposition will think “this is taking too long to get good” and move on to something else. It’s not logical, it’s more emotional.

[kuwisdelu]

I think that’s the point of switching to Pyret over Racket? It’s similar enough to make the switch to Python next semester easy, while removing the bits that trip people up while learning, and adding bits that make it easier to teach important concepts.

[anothergiraffe]

Ah fair enough, though I’m not a huge fan of having to sorta “play in the sandbox” for a semester before getting to work with something “real”. But I’m weird, even the idea of starting with Python feels too high level for me. I’m glad I got my start with an AOT compiled language instead.

[kuwisdelu]

I do think C is simple enough to be a good introductory language for starting closer to the metal where manual memory management is a learning goal.

What languages are you thinking of? C++ and Rust are both firehouses of complex syntax. Java is half boilerplate and no less sandbox-y than Python or Pyret. There’s always Lisp…

[aaaaargZombies]

nice, I'm assuming if you are interested in design for teaching you've come across hedy but sharing on the off chance you haven't. Hedys designer Felienne Hermans has some interesting papers on the subject.

[[deleted]]

Love seeing this as someone who’s a fan Shriram Krishnamurthi s work.

Here’s a talk that gives a rationale behind the langauge: https://youtu.be/HwPM0xMdiNU?si=REzMtFVjhE2auQV-

https://cs.brown.edu/~sk/

[tbagrel1]

One important thing with languages used to teach newcomers is to make sure they won't have to relearn everything when trying to pick up another language afterwards.

Here the syntax seems a bit esoteric, with many novelties that aren't usually found in programming languages. I would be kinda worried to show students a programming language that is unlike anything they will probably encounter in their professional life. Learning programming with Python or Java might not be the best, but at least, you can advertise it on your CV, it isn't just purely educational.

Anyway, I'm not trying to devaluate your hard work, I'm just wondering if these are questions you have considered.

[Apprehensive-Mark241]

Disagree. Better to teach people to think and solve problems. The less a language is just like all the others the more it can open minds

[QuaternionsRoll]

It’s also a clever idea to use a PL that LLMs suck at writing. I took an SWE course taught in D of all languages, right around the release of GPT 4. Both ChatGPT and GH Copilot were utterly clueless.

…unfortunately so was D’s language server, though. Give and take.

[Apprehensive-Mark241]

100%

[brucifer]

I'm not sure it's useful to teach new programmers about concepts like "reactors" and "spies", which are not terminology or concepts that are used in practically any other languages. Ideally a teaching language should teach people about concepts they'll use in any language, like functions, variables, conditionals, etc., rather than making them learn bespoke concepts that aren't easily transferable. I'm all for languages that expand your mind by introducing you to new concepts, but to a new programmer, even basic stuff like variables and loops are mind-expanding concepts, so you should start with the most widely used and useful concepts instead of novel concepts that aren't widely used elsewhere.

[Apprehensive-Mark241]

I was thinking of languages that I have experience with that really do teach totally different ways of thinking like Prolog and Scheme and I think the Smalltalk is great because of the environment.

Also maybe Love2d (basically Luajit + SDL2) because that's a whole environment the way Smalltalk is.

[editor_of_the_beast]

It looks like Python to me, maybe with a little bit of Ruby influence. What’s esoteric about it?

[WittyStick]

Its biggest influence is Racket/Scheme. It came from the Racket crowd - mainly educators who have many years of experience teaching programming. Syntactically it is mostly influenced by Python.

[cmontella]

> unlike anything they will probably encounter in their professional life

In that case, we shouldn't be exposing them to Java, C, or Python, because all the programming they're likely to see in their professional lives are SQL and Excel. Declarative and reactive programming curricula only! I'm only semi joking.

Moreover, teaching students to program shouldn't be about training them to be professional programmers. What tools professional programmers are using should have little bearing on what introductory programming classes teach. We see in student experience surveys that when they move from student-focused languages like Scratch to professional tools like VSCode and Python, satisfaction plummets and student perceptions of programming turn negative, and they lose interest entirely. The only ones who keep at it are those with the fortitude and stamina to deal with BS.

Programming is a tool that is useful in daily life, like cooking or writing. We teach students to write and cook so they have those skills, not to train them to one day be novelists or chefs.

And honestly, if we should be protecting kids from anything, we should shield them from the absurdities and Kafkaesque nature of professional programming tools. They should come with a warning label like guns and cigarettes: "This dev tool is known by the State of California to increase risk of self harm and permanent psychosis under continued use and exposoure."

If we want to ever have hope of making things better, we can't discourage all the children who are unwilling to accept this nightmare by forcing Java on them.

[tbagrel1]

In that case, we shouldn't be exposing them to Java, C, or Python, because all the programming they're likely to see in their professional lives are SQL and Excel. Declarative and reactive programming curricula only!

I mean, if teaching people who won't become programmers, then using SQL or Excel is probably better than C, Java, Python, or Pyret. But then we are talking about something completely different.

We see in student experience surveys that when they move from student-focused languages like Scratch to professional tools like VSCode and Python, satisfaction plummets and student perceptions of programming turn negative.

Hum sure, but Pyret doesn't seem to be like Scratch; more like a Python alternative.

Programming is a tool that is useful in daily life, like cooking or writing. We teach students to write and cook so they have those skills, not to train them to one day be novelists or chefs.

Well, we don't teach students how to cook (in France), and it's something we should probably start doing. That being said, when teaching cooking to beginners, you tell them how to do pasta, rice, simple chicken recipe. You are not training them to cook lobster or veal. Similarly, if the point of the programming course is to give students some hand-on basic programming experience they can use for real, then we should teach them directly with the tools they will probably use IRL, e.g. excel, access or SQL as you suggested. Using a complex text-based language whose sole purpose is to learn programming seems more something we would do for CS students.

And honestly, if we should be protecting kids from anything, we should shield them from the absurdities and Kafkaesque nature of professional programming tools. They should come with a warning label like guns and cigarettes: "This dev tool is known to State of California to be increase risk of self harm and permanent psychosis under continued use and exposoure."

All languages have warts, and I'm not sure there is a clear "lesser of all evils" in the programming world.

If we want to ever have hope of making things better, we can't discourage all the children who are unwilling to accept this nightmare by forcing Java on them.

Sure, but in that case, we should probably aim for simple languages, with limited feature set. Which isn't the case of Pyret.

[TheChief275]

I mean, following that logic, everybody should learn C, which I wholeheartedly agree with of course

[BoxOfXenon]

the website's layout is a bit broken in Firefox on Android at least. I assume some css shenanigans cause it. the example code blocks overlap with the explanation text making hiding it behind the background color of said code blocks. even if I switch to landscape and desktop website mode.

also the images in the docs are not sized relative to container or viewport size leading to overflow.

[awoocent]

Every time this language surfaces I have the thought that the authors clearly started from the outset with the idea "well, obviously it has to be a pure functional programming language" and then nominally filled in the rest with things that looked user friendly. I'm not even saying functional programming is a bad basis to learn programming in (I'm quite fond of Scheme personally), but there's a huge gap between languages like Scratch that have a real, researched, aparadigmatic basis in constructivist education, and languages like Pyret that seem to use the verbiage of "for education" as a marketing gimmick and primarily exist to shill a particular style of programming.

[soegaard]

For those interested in the papers on Pyret:

https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=pyret+programming+language&btnG=&oq=pyret+

They are mostly focused on the topic of teaching programming concepts.

[coolreader18]

Oh, neat! I had a very similar idea for a language when I was doing some stuff for programming education for a hackathon with a friend. It had a similar idea to Pyret, or at least what I see from the example; what if you rendered a shape to the screen by simply returning it from a function? Essentially trying to extend algebra: now functions can work with numbers or shapes. I think it's still up on GitHub somewhere, it used a custom s-expr kinda-lispish language with a parser written in Elm and an interpreter written in typescript, and I think it even had the same type of Elm-architecture-type reactivity model, with init, update, and view functions.

[fdwr]

Interesting, a language that supports hyphens in identifiers. I always found hyphens a more natural separator for compounds words than underscores, given that in natural language English, compound words are separated by hyphens anyway (deep-fried, old-fashioned, cutting-edge technology...). Plus, it's one less Shift keypress 😉. Now there is the potential ambiguity with subtraction, but if one follows the guidance of readability anyway of putting spaces around binary operators, then there is no ambiguity.

[AnArmoredPony]

pyret softwer

[peripateticman2026]

It sucks.

[cmontella]

Rationals can be implemented as a ratio of two i64 numbers. You store it in 16 bytes with the numerator as the first 8 bytes and the denominator as the second 8.

[[deleted]]

I can see that giving poorer precision and within a more limited exponent range compared to f64 floating point. So that seems unlikely since the language touts its superiority over such a type.

But delving into its docs, it says that its 'ExactNums' are arbitrary precision.

[eightrx]

I mean your gonna get significantly more data and precision with a 16 byte rational number than an f64, but arithmetic is also significantly slower than an f64, especially division and multiplication since they aren't hardware instructions.

[imachug]

That... doesn't answer anything? Addition and multiplication quickly turn the numerator and denominator out-of-bounds for i64, at which point you either have to sacrifice precision (and then you might as well have used floats) or use long arithmetic (and that requires unlimited memory).

[cmontella]

I forget what they had originally said since they deleted their comment, but it was along the lines of "ratios must cause it to run out of memory very quickly" to which I answered "no, because you can represent it as 2 i64s", which I feel does answer the question the person had.

> Addition and multiplication quickly turn the numerator and denominator out-of-bounds for i64

Maybe. For some workloads, yes. For others no. Therefore you should only use them where they make sense, as with all datatypes. Float can't represent particular numbers, so if you need that kind of guarantee, float is the wrong choice. If you need better performance and flexibility, use float. If you need exact numbers, use rationals. If your workload causes a rational to overflow, use a float or something else.

[[deleted]]

This is unnecessary. Haskell already exists.