I'm familiar with the LISP metacircular interpreter and programming language theory. I know you can define all sorts of things with a very small set of primitives.
It's one thing to build a minimal implementation where your main constraint is that it works and its concise. It gets a lot messier once you start worry about constraints like efficiency on real machines - there are limits to how much you can abstract out the heuristics and special cases.
And its macro support has a major impact on the small code-base size of their class libraries.
Right, if you need it to be efficient than mechanical sympathy starts creeping into your code-base, though language design should optimally be designed to capture human thought - that's the part that doesn't scale well or solved by adding more machines.
The Nile/OMeta work is an example of using DSL's as one way to reduce the LOC's required, it captures the required top-level math fn's for image processing and uses OMeta to convert it to runnable source code. DSL's might not be the best way forward in all situations, but investing in research of different ways to the solve the problem can only help.
It's one thing to build a minimal implementation where your main constraint is that it works and its concise. It gets a lot messier once you start worry about constraints like efficiency on real machines - there are limits to how much you can abstract out the heuristics and special cases.