LISP-like languages aren't attractive solely for implementation reasons, I think; LISP wins for ease of programming. Fewer lines of code is a great reason to pick one language over another for a DSL. I would imagine it would be easier to code the high-level logic for an application in Scheme or CL rather than Forth or Perl. In a hypothetical large enough project that the implementation cost of a DSL were no object, I think a case could be made that a higher-order functional language with garbage collection and code = data etc. would still be the best choice. I think these are just great features in any language, or at least any where expressiveness and programmer time are valued above memory footprint and execution speed. The nature of a DSL in particular is to have a relatively small amount of 'executive' code, with the heavy lifting done elsewhere (or within language primitives), so I would think even a naive, slow, memory hungry interpreter could fit in to many application designs on today's hardware. Provided we draw the boundaries in the right place. :-D
Dan Sugalski wrote:
On Sun, 16 Nov 2003, Mike Newhall wrote:This is consistent with the semi-humorous comment that all large systems eventually implement an ad hoc version of LISP -- perhaps what they are really doing is implementing a DSL, and a LISP-like language is the ideal type of language to implement DSLs.I've been involved in a number of projects that either already implemented a LISP-like language as a DSL or were in the process of doing so. The two biggest (and, in fact, sole) reasons for a Lisp-like language were ease of implementation and small memory footprint.