Lambda the Ultimate

According to a Management Insights study software designers have incentives to pursue more complex solutions than necessary.

I guess that the language and language platform is part of that complexity... I did not read the actual paper (not a free download).

Addendum
Ruediger Hanke provided this link which details better the scope of the study. Notably:

Drawing upon existing theory, we subject participants in our experiments to a context in which they act as agents for a principal, and have to convince this principal of their capability in order reap financial incentives. [...]Theory suggests that the difficulty of the task influences their expected gain in reputation. The data from the experiment supports that people have a higher propensity to choose a difficult solution as the expected reputation they can gain by choosing this solution increases.

I've a question for the group concerning domain-specific languages. One taxon by which DSLs can be categorized is whether or not they are standalone or embedded (my terms; don't know if there are better or more precise terms for the concepts in the literature). A standalone DSL is one which contains little or no trace of the language used to implement it (and indeed, implementations of the DSL may be written in any decent general-purpose language, with similar effort). When general-purpose computing constructs (flow control, recursion, arithmetic, error handling, type processing) is needed, it must be added as part of the DSL.

HTML, to the extent that it is a programming language, would be one example.

An embedded DSL is one which extends, in some fashion, an existing general-purpose language which I shall refer to as the host language (one which is typically the language of implementation)--code written in the host language, or a subset thereof, is also valid in the DSL. In such languages. Such language may be implemented via macros or similar "compile-time" metaprogramming means; by standalone programs which translate the DSL into the host language, or by interpreters which include the ability to evaluate statements in the host language (possibly relying on an eval() facility present in the host language itself). Generally, such DSLs are tightly coupled to their host, and writing code in the DSL will often require knowing the host language. Writing the DSL implementation in a different language than the host may be difficult; especially if the DSL is interpreted. (Writing a DSL compiler/translator is more easily done in a "third" language).

Yacc is one example; while the part of the language for describing productions themselves isn't dependent on any other language, semantic actions pretty much have to be written in C/C++. If you want to write a LALR(1) parser in some other language, you're better off with a different tool. The universe is replete with experimental languages which compile into Java, and which typically allow Java to be embedded within. (Java generics started off this way, although adding decent polymorphism to Java is hardly domain-specific).

The questions are: What are the design trade-offs between the two approaches? The embedded approach seems to be easier, especially in a language with decent metaprogramming. The standalone approach seems better for a language which is intended to be used by non-programmers, or which need to spread beyond a single project, organization, or language community--but when general-purpose programming facilities are needed, that wheel is often implemented poorly. (And in the degenerate case, the result is not really a DSL but yet another general-purpose language--quite a few general-purpose languages started off as DSLs but became generalized).