Talking about fexprs

"A good programming language takes a small core idea that allows us to do as much as possible in libraries.

The reason for that is that changes to a language are harder than changes to libraries, so the less there is to change in a language the better. The well-known lambda calculus can implement any computable function, and encode any data type.
In theory, we could write everything in pure lambda calculus. But because we program for the next poor soul that has to maintain our code and not for the computer, we have built languages that have more (technically superfluous) structure.

Scheme, for example, is explicitly based on the lambda calculus, but adds syntax for function definition, variable binding, and more. Scheme also has something called macros that lets programmers define new syntax. These two things--lamda calculus and macros--are sufficient to define quite a lot of useful syntax.
But we can do better, and with only one concept instead of two. "fexprs", known from the first Lisps, are a simple abstraction that let us define lambdas and macros as library code."

Join us on Tuesday the 14th and listen to what Tim has to say about fexprs. After which we can discuss this and/or just casually talk about what's cooking in the world of functional programming.