for advanced undergrads, the university of michigan (i'm speaking from my own experience here) has a course progression of (1) programming languages for 1st year grad students, (2) compilers for undergraduates, (3) compiler optimization for 1st year grad students. the expectation is that you can write a fast implementation of a simple language (~scheme) on your own, and you have the knowledge to write a simple optimizing compiler for e.g. c89/99 if you were to take it on as a longer project. any compiler written in a semester probably doesn't have enough manpower to be optimized to a point of usefulness, and you'll learn some things only via implementation struggles, but you'll have the capability to try, search for literature to get unstuck, etc. which is cool!
replyVery similar at University of Warsaw, at least couple of years ago.
replyLanguages were simpler (except for certain ones, like C++ which was a beast even in 1992), and incredibly complex and magical optimizers weren’t yet a thing, never mind a feature expected of a "passable" compiler. One could still write a reasonable non-optimizing Pascal or C89 compiler in a weekend more or less, and it would be both faster to write (thanks to more expressive languages) and faster at compiling (thanks to itself being compiled by an optimizing compiler) than in 1992!
replyI dunno, Chez Scheme is from 1985 and remains today one of the most magically optimizing compilers for a dynamic language in existence... kind of makes you wonder how we went so far wrong with Python.
replyPeople like to say that "languages aren't fast or slow, that's a property of the implementation."
replyThis is true, but the implementation is constrained by the specification. Python is not just dynamic, but in many cases over-specified. If you read e.g. the Common Lisp specification, you will find that things are under-specified in places that leave a lot of low-hanging fruit for an optimizing implementation.
Scheme (particularly prior to R6RS) is so lightly specified as to allow a lot of variation in implementation strategies, even more so than Common Lisp.
> The definition of "passable compiler" in 1992 must have been very different from what it is today;
replyIt was.