The definition of "passable compiler" in 1992 must have been very different from what it is today; while third year students write interpreters and compilers, nobody would call them useful or passable.
Languages 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!
I 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.
People like to say that "languages aren't fast or slow, that's a property of the implementation."
This 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.
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!
It is possible to frontload the effort though and FIRE.
It makes sense too, if I worked two days of the week right now, I'd spend giant majority of that time just catching up and understanding the changing context. It would make more sense to work 4 months a year; 5 days a week.
Unfortunately, it's one of those things that only work in theory and isolation.
Not only that. The strict adherence to things like ESRB ratings dumbs down today's kids.
I'm firmly in the camp that I am a better person today because things like parental controls did not really exist in the world when I was a kid, and I was playing GTA at like 10. While kids today at that age are forced to read, listen, watch or play dumbed down crap.
The big 3 are the only ones capable of bringing forth a glut, IMO. Of the Chinese challengers, CXMT is the frontrunner, there's also JHICC and others, but I don't think any of them will have sizable volumes in the next 2 years, despite extremely favorable market conditions. This is not a dig against them; they (and their domestic vendors) will need time and experience to get the yields up, and will undoubtedly eventually dominate the consumer market in about 5 years, according to my outsider crystal ball.
CXMT is a tiny supplier, it will take years before they significantly expand the market. They're pretty much in the same boat as Samsung and SK Hynix, they just have less of an incentive to actively curtail supply.
For some definitions of tiny. Their current monthly wafer production is about 1/2 that of Samsung, SK Hynix, or Micron. They're rapidly expanding, but so are the others, so they're unlikely to catch up anytime soon, but that alone doesn't make them tiny. Maybe tiny in the HBM space or even DDR5, given their trailing process nodes.
reply