Attitudes like this are short-sighted, and part of the problem. Finding innovative and elegant solutions to solving problems is more scalable than the brute-force approach of throwing resources and having them churn out more LOCs to solve it. Not saying its easier and requires less effort to do, just that it results in less LOC's that scales better and provides better building blocks to build on.
Its more powerful and extensible than most languages despite requiring orders of magnitude less effort to implement (see: Peter Norvig's Lisp interpreter in 60 lines of Python http://norvig.com/lispy.html, and re-written in 40 lines of Ruby http://stuff.thedeemon.com/rispy/).
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.
Look into the special properties of LISP which Alan refers to as the Maxwell’s equations of software: http://www.michaelnielsen.org/ddi/lisp-as-the-maxwells-equat...
Its more powerful and extensible than most languages despite requiring orders of magnitude less effort to implement (see: Peter Norvig's Lisp interpreter in 60 lines of Python http://norvig.com/lispy.html, and re-written in 40 lines of Ruby http://stuff.thedeemon.com/rispy/).