Dynamic Languages Wizards Series - Panel on Language Design

What Hacker News said

Strong rec EdwardCoffin · 2025-11 · on “Designing a Language (2017)”

In a similar vein is this 2003 post in an MIT discussion forum by Scott McKay [1]. I'd also highly recommend that anyone interested in this kind of thing listen to all three of the Dynamic Languages Wizards Series panels from 2001: runtime [2], language design [3], and compilation [4] Note that though these are videos, there isn't that much compelling in the visual portion, you could easily rip them to audio files and lose little. [1] [LINK] [2] [LINK] [3] [this video] [4] [LINK]

Recommends EdwardCoffin · 2015-07 · on “Ask HN: What are some good resources on the history of programming languages?”

In 2001 MIT had the Dynamic Languages Wizards Series [1], which consisted of three panels of luminaries in the field (videos and participants names on the linked page). A lot of history was discussed in their 5+ hours. They are also on YouTube: Panel on Runtime: Richard Kelsey, David Moon, Tucker Withington, Kim Barrett, Scott McKay [2] Panel on Compilation: David Detlefs, Will Clinger, Martin Rinard, and Mat Hostetter [3] Panel on Language Design: Paul Graham, John Maeda, Jonathan Rees, Guy Steele [4] --- [1] [LINK] [2] [LINK] [3] [LINK] [4] [this video]

Cites EdwardCoffin · 2014-04 · on “Great Programmers (2004)”

This reminds me of a tip Guy Steele gave in his talk on the Language Design panel of the Dynamic Languages Wizards Series in 2001 [1]. He said: It's important to establish design principles early on, that is in effect to do meta-design, because as you evolve the design, or as the language grows later, you want to remain true to an initial vision. This has to do with keeping the description small, and if you can resort to a meta-principle to help you resolve a particular design decision, it keeps the language more consistent. (17:09-17:29) [2] [1] [this video] [2] [this video]

Cites platz · 2015-06 · on “What to know before debating type systems (2010)”

Guy Steele: "A dynamic language is one that defers as many decisions as possible until runtime.." [this video]

Cites lukego · 2017-06 · on “What Challenges and Trade-Offs Do Optimising Compilers Face?”

Paul Graham once made a point about designing languages for yourself, or for people who are not as smart as you are, or for people who are smarter than you are. [this video] Somehow this blog and the debate with djb reminds me of this point. What kind of person is are the compiler optimizations intended to benefit?

Cites EdwardCoffin · 2020-03 · on “Why not to use (f)lex, yacc or bison”

Guy Steele said this in the Dynamic Languages Wizards series, in the panel on language design [1]: Be sure that your language will parse. It seems stupid to sit down and start designing constructs and not worry how they will fit together. You can get a language that's difficult if not impossible to parse, not only for a computer, but for a person. I use YACC constantly as a check of all my language designs, but I very seldom use YACC in the implementation. I use it as a tester, to be sure that it's LR(1) ... because if a language is LR(1) it's more likely that a person can deal with it. [1] [this video]

Cites EdwardCoffin · 2020-03 · on “Open access to ACM Digital Library during coronavirus pandemic”

> I'm biased because this one is effectively "What if we make an APL Lisp?" You might like this excerpt from the MIT Dynamic Languages Wizard's panel, where Guy Steele said [1]: > Higher order functionals, I think, are underrated, and can be very good. As the years pass, the more I use Common Lisp, the more I find myself using the sequence functions, including a lot of mapcars. I had to do a matrix tensor product routine about two weeks ago, and I was puzzling over how to do the nested do loops and so forth, and finally I realized it was just mapcar of mapcar of apply of append to mapcar and mapcar, done. No big deal. In other words, thinking in APL should improve your Lisp code. [1] [this video]

Cites EdwardCoffin · 2023-08 · on “Practical Parsing with Flex and Bison”

I used Lex and Yacc (as the article mentions, the direct predecessors of the Flex and Bison it talks about) a bit a long time ago, but more recently when I've written parsers I've just used recursive descent - but I was parsing a well-defined grammar. It did leave me with the knowledge of how to describe grammars in Yacc though, which I have found useful. Guy Steele said something about a use of Yacc that stuck with me : Be sure that your language will parse. It seems stupid to sit down and start designing constructs and not worry how they will fit together. You can get a language that's difficult if not impossible to parse, not only for a computer, but for a person. I use YACC constantly as