Eduardo Cavazos
1 HN recommender · recommended in 8 months, 2014–2025
1:58:46 · 16K views · Apr 4, 2012
A 2001 panel with Paul Graham, John Maeda, Jonathan Rees and Guy Steele on programming language design, part of the Dynamic Languages Wizards Series.
HN users mine it for design wisdom and history from luminaries, and often quote Guy Steele's remarks.
9 comments from Hacker News
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]
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
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 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. From the Dynamic Languages Wizards series, in the panel on language design (1:09:05) [1] I've not yet employed Yacc in this fashion, but it did give me a tool for thinking about object models. A while ago when I was puzzling over how some classes in an entity relationship diagram should be related, and I considered it from the point of view of how would I design a grammar for serializing an instance of the model into text. This essentially made my decision for me in a principled way, though I never reached the point of writing up a grammar for the whole model, just consider
First impressions apply to languages too. A lot of mathematicians went into AI but didn't start out with any programming experience. They dabbled in some languages and gravitated toward the one(s) they found most useful. Paraphrasing Guy Steele [1]: > It's important that when you design a language that does a familiar thing, that you do the familiar thing exactly... it's criminal that you can write 1/2 and get values nowhere near one-half. Python >>> 1/2 0.5 Ruby irb(main):001> 1/2 0 To a novice programmer, ruby's result makes no sense, and introduces an incredible degree of doubt into the mind of the user. Sure, they could explore why it gives that result, but if that's not helping them get toward solving the problem they're using the programming language for in the first place, then it could seem like an indulgent tangent. [1] this video
> 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