You might want to look at Lua, FWIW. It focuses more on being a "really clever small language for embedding in C". (It also actually has tail call optimization, non-broken lambdas, no need for a GIL, etc.)
I've never really looked much into Lua before? Does it also have some sort of unifying base underneath it all? I liked Why's Potion because it reused many of the same syntax constructs in different places, so that there were few special cases.
It does, actually. Lua uses tables as its underlying data structure in the same way that Lisp uses the list. This is where a lot of its power and simplicity comes from. In fact, the language authors have stated how Lisp was one of their inspirations for the language.
Lua is intentionally very small ("doing more with less"). It has a lot in common with Python, Scheme, and Javascript, but was designed for embedding, and where Python prioritizes "batteries included", it puts more emphasis on "small/simple/powerful". (If you're extending a C project, you've already got libraries.)
The _Programming in Lua_ book is the best place to start. The previous version is free at http://www.lua.org and will give you a good impression. (The main diff between 5.0 and 5.1 is the module system.)
"Worse is Better" is just an inaccurate way of saying it. More accurately, "It's the Culture, Stupid!"
If a language fits a group's culture better, it will be adopted more. Smalltalk lacked operator precedence for algebras -- big lose for the non CS sci/tech crowd. At first Java had some of what Smalltalk had, but fit general programming culture better in terms of C-like syntax, free (beer) tools, and static types.
Lisp is close to timeless mathematics, but a bit farther away from everything else than everything else. I don't think it's a coincidence that the AI field gravitated towards Lisp -- those guys were used to meta-abstraction.
Perl just threw every Unix tool there was into a burgeoning scripting Swiss-Army knife. As a result, everyone in the Unix camp could relate to it instantly.
Worse is not better. Better is better. But designing to fit existing cultures has a big short-term payoff for a programming language. This means a bigger user base, which means more eyeballs, more libraries, and other dynamics that also get you lots of Better.
The Best would be: a programming language that has a high fit with non-CS/programming sci/tech types and elegant design, first-rate implementation, and mathematical universality.
"Worse is Better" is just an inaccurate way of saying it. More accurately, "It's the Culture, Stupid!"
No, this is an oversimplification. Richard Gabriel's original essay[1] says it best near the end:
The lesson to be learned from this is that it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing.
Loathe as I am to engage in a programming language pissing-match, I think you will be surprised at how widely lua is embedded, perhaps even in products that you have used.
Pithy and sounds good, but totally discounts network effects. Programming languages are subject to network effects -- users create libraries in the language, increasing the usefulness of the language. Of course, interoperation between languages is possible to some degree, but that doesn't detract from the core statement.
It's really not hard to use C libraries from Lua, and its design for embedding / use as an off-the-shelf extension language has made interfacing easily with other languages a high priority.
There are projects that supposedly allow interoperability with Python, Perl, and several other languages (http://lua-users.org/wiki/BindingCodeToLua), though I have only used the C API thus far.
The core language is also small and simple enough that adding major language extensions, such as Erlang's concurrency model (http://concurrentlua.luaforge.net/), is feasible.
