Dynamic Languages Wizards Series - Panel on Language Design

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

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 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

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

> 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

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?

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

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