&quot;There aren&#x27;t any, that&#x27;s the problem.&quot;<p>&quot;I&#x27;m not writing these posts to try to get developers to use DSLs more often. I&#x27;m writing them to try to get language designers to design DSLs more often.&quot;<p>I was actually baiting you to blast you given I guessed the answer to number 1. However, I decided against it since you have the more reasonable position of identifying the problem then pushing responsibility onto language designers rather than users. Many posts seem other way around. So, that&#x27;s refreshing. :)<p>&quot;There are rare occasions I see DSLs used to fulfill these roles, and it&#x27;s to great benefit.&quot;<p>I agree. iMatix, REBOL&#x2F;RED, and LISP community (esp Racket) have shown it consistently in terms of productivity and reliability with performance being better sometimes. True even for general-purpose, systems programming: see Ivory langauge from Galois.<p>&quot;SMC rather than hand-coding stuff as C++ boilerplate. Same with using a process coordinator like Erlang&#x27;s OTP (which isn&#x27;t a DSL but is close enough).&quot;<p>OTP as a coordinator DSL I haven&#x27;t thought about. Might look into it to see if there&#x27;s design wisdom to learn for a future DSL outside of Erlang.<p>&quot;I&#x27;m writing them to try to get language designers to design DSLs more often.&quot;<p>I know there&#x27;s been some good books and essays on how to best design DSL&#x27;s. Most of us don&#x27;t know which ones are the good ones. Do you have any links for me or others following along on that? I figure the old wisdom augmented with lessons learned from LANGSEC stuff will be a good start.<p>&quot; This is exactly as it should be, since Coq is focused precisely on the domain of functional algorithms (and proofs). And, I have found that, within that domain, the restriction that all my algorithms must provably terminate is nearly invisible.&quot;<p>Wait, are we discussing avoiding Turing completeness or requirements for a termination proof? Termination proofs are done on code in Turing complete languages many times a year in academia. Harder than Coq model of an algorithm for sure but way more useful. I&#x27;ll just let you elaborate on why you focused on that point.<p>So, trying to cut through the fog that remains, would you say a good approach is using a language like Haskell or ML that compiles to System F (Turing incomplete) with DSL&#x27;s where possible? Aside from your DSL point, is building on or alternatives to things like System F what you would like to see?<p>&quot; Turing-completeness is not a feature I need in a programming language.&quot;<p>Curious, how do you handle I&#x2F;O and other OS interaction without making it so complex a new programmer must learn Haskell, monads, etc? Is there a simple route to that part of things?