On Sunday, 27 September 2015 at 10:38:39 UTC, cym13 wrote:
You might like to read http://www.paulgraham.com/avg.html if that's not already done.
Startups have a different logic to them, they might try to attract developers to build a small tight team, for less pay, by providing a more exciting cutting edge environment or might just aim to produce a proof of concept within their means/know-how with the goal of attracting investors... so whatever works for them.
But going with Lisp today in web development seems to represent a fairly high level of lockin. I wouldn't do it.
Of course risk must be reduced to a sane minimum, but a project without any kind of risk is often a project without value, sometimes taking a calculated risk to gain a competitive advantage proves useful.
Calculated risk is one thing, unnecessary risk something else. If you are doing projects for external customers you really don't want to end up in a situation where they say "we want to port to platform X, we know that can be done in C++/Java" and then have to admit that you cannot do that with whatever non-standard language you pushed for. Another issue is that you don't want to develop on 10 different platforms, so sticking with a good allrounder language platform is not a bad strategy for many development teams.
I see it a bit like software security (more my field): of course security risk must be kept low, but not at the expense of the ability for the company to produce its product. After all what you're protecting is the ability for the company to make money.
I don't really think choosing one of the more common modern algol-like languages over the less common ones affects your ability to produce the product. The software development process itself is more likely to play a significant role.
For software that is made for supporting organizations as much as 80% of the total development costs might come after deployment. There are usually too many unknown factors in long term software development at the early project stages, so you cannot reduce the risks to the level you would like. What you can be pretty sure of is that requirements will change and that you need flexibility and the ability to evolve in new directions.
The department I was with, belonged to the scandinavian school within systems development which is largely looking at user-centered development where you involve/focus on real end users throughout the process. That is one way to reduce risk and increase acceptance among end users.
