The good news is that a language for in-house use need not be finished to be useful. For example, FB's PHP compiler can't compile "eval." No problem, don't use eval in-house. If they were trying to "finish" it in the sense of writing a compiler for every possible PHP app, they would have to address that somehow. But instead, they punt on it and carry on using it in house.

I think they're likely to be an ongoing distraction for the above reason, and also because of the fun/intellectual challenge reason.

> punt on it and carry on using it in house.

Over time, that kind of thing can (if you're not careful) lead to dangerous cruft, where the in-house divergences pile up to the point where it's no longer so easy to go back and forth between the public/open version. And thus is born a new species with a far smaller ecosystem than the original.

of non compiler/language processing experts.

If you've built compilers before and know what you are doing (I have no idea if these guys are such experts or not) , it may be a reasoned decision taken after weighing benefits and costs.

Leon Bottou and Yann LeCun seems to have built the Lush dialect of lisp to build commercial systems. (http://lush.sourceforge.net/credits.html)

For example, I can easily imagine PG building a variant of lisp and building a product/company around that . Of course if you only have a vague idea of how to build a compiler/interpreter/whatever, then building a company around your first such project may be ... interesting.

Or perhaps using Lisp to write his own continuation-based web framework and building a company around that?

I'll grant that investing in language development is unusual. But the risks involved aren't sufficiently different from those taken by 37signals in choosing Ruby and developing a framework. There are payoffs for core technology development.