> That's the thing that Lisp/Smalltalk/Forth/Tcl proponents, who lament the unpopularity of their favorite language [1], frequently get wrong. ... but that th

> That's the thing that Lisp/Smalltalk/Forth/Tcl proponents, who lament the unpopularity of their favorite language [1], frequently get wrong. ... but that those don't really matter that much in most practical use cases, This statement does a good job of summarizing where I've landed on these sorts of languages, myself. Viewed in terms of Amdahl's law, the most you can improve a system by adjusting a single component is the impact of that single component. From a systems development point of view, the most impact you can have by changing programming language is to eliminate or reduce the cost of expressing your system's processes in a form the machine can understand. Notably, this still leaves open most or all the other problems that beset software projects. The requirements are still under specified, the team is still subject to staffing constraints, funding still has to be justified and acquired, legal and business and scheduling constraints are all still there, and is the business viable at all in the timeline that you have? [1] The list goes on and on... and because the language doesn't really help, the value prop for niche languages goes way down. That negativity aside, I do see potential counterarguments to this in the fact that an expressive enough language can help you improve your process to the point where you get answers faster and more reliably. But even that argument requires both a leap of faith and the willingness to take on the risks that implies. 1] Looking at this list, it's written in a way that might seem to imply startup/VC-funded project work - but that's not intentional. Those issues are also almost all faced by internal corporate development projects - either IT or for externally facing projects. > [1] I don't mean to imply that you're one of them, I'm talking in general. I didn't think you were, but thanks! :-)