> Why would investors care whether it's done in $LANG? I thought they cared more about the business and business-related concerns.
I think the concern is around how hard long term sustainability of the codebase. If it's built in a relatively minor tool, there's merit to the belief that it'll be hard to find people that know it well. (And this is discounting the possibility that a dynamically typed language might be less suitable than programming in the large than something that has more static checking.)
When I was 23 and fresh out of school, I'd probably called this line of reasoning ill-informed at best... after all, a good developer can learn any language, and you'd only want to hire _good_ developers anyway. Twenty years later, I'm a lot more sympathetic. If you're trying to deliver business value under time/budget/risk constraints, adding a known, short-term risk (a minority language) for an unknown, longer-term benefit is a hard sell.
I think the Lisp-like languages are particularly prone to this in that they derive so much of their power by providing lots of mechanisms for abstraction. (Higher-order functions, syntactic macros, multi-methods, etc.) If you have the right abstractions in your code it can be great, but getting to that point and maintaining it can be expensive. (And in the meantime, you also have a great deal of power for shooting yourself in the foot.)
My general sense of languages like Clojure is they are very good for people with experience and time to very carefully consider their problem space. However, that's not necessarily a great description of the modern IT profession.
I think the concern is around how hard long term sustainability of the codebase. If it's built in a relatively minor tool, there's merit to the belief that it'll be hard to find people that know it well. (And this is discounting the possibility that a dynamically typed language might be less suitable than programming in the large than something that has more static checking.)
When I was 23 and fresh out of school, I'd probably called this line of reasoning ill-informed at best... after all, a good developer can learn any language, and you'd only want to hire _good_ developers anyway. Twenty years later, I'm a lot more sympathetic. If you're trying to deliver business value under time/budget/risk constraints, adding a known, short-term risk (a minority language) for an unknown, longer-term benefit is a hard sell.
I think the Lisp-like languages are particularly prone to this in that they derive so much of their power by providing lots of mechanisms for abstraction. (Higher-order functions, syntactic macros, multi-methods, etc.) If you have the right abstractions in your code it can be great, but getting to that point and maintaining it can be expensive. (And in the meantime, you also have a great deal of power for shooting yourself in the foot.)
My general sense of languages like Clojure is they are very good for people with experience and time to very carefully consider their problem space. However, that's not necessarily a great description of the modern IT profession.