You're making two points, either or both of which may be good, but they are two different points. First, are they hard or easy? Second, are they distracting because they're fun/engaging? Either "problem" may lead to them being a huge time sink for startups and either may lead to them being perennially unfinished.
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 would say reasonably easy to start with, but needing a lot of ongoing effort for improvements, bug fixes, and so on, which is exactly why I think it's a dangerous combination for a small company.
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.
"I think it's ... dangerous .. for a small company."
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.
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.
yeah sure. I first wrote "arc" and then replaced it with "a variant of lisp" then replaced "another company" with "a company" so the sentence reads oddly.
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.