I remember loving these papers back in the day.<p>First, I would be far less skeptical than this author is over the tradeoffs of scripting languages. Given the tools offered by scripting languages, there is one obvious way to do things. The overhead of building a fancy "just right" data structure almost always makes things perform worse than the straightforward solution using dictionaries, arrays and scalars. Given that, people go directly to that solution, leading to less variation in length of code, time and performance. It is always possible to beat a scripting language's performance, but a surprising number of programmers won't.<p>This is a lesson that generation after generation of programmers have learned in a variety of scripting languages. With the latest winner being Python. But the differences between popular scripting languages generally matter a lot less than the commonalities. (There are exceptions, specialized languages like Lua, R and Julia have very specific strengths and weaknesses despite being aimed at scripting.)<p>Second, there are two basic reasons why Lisp loses.<p>The first is the disadvantage of being an image based system. This has a lot of upsides, but the downside is that people lose access to a long toolchain that they are used to for dealing with files. Tools including editors, source control, and so on. Programming expertise is fragile, and that is a pretty big shock.<p>The second is that Lisp attracts people who want a perfect language. Unfortunately people's ideas of perfection different. So we get a large number of related dialects of Lisp, which are almost compatible with each other. And fail to get critical mass behind any of them.<p>That said, how big a deal is achieving critical mass? Well obviously it matters. If you're using a mainstream language you can find packages for things that you need, answers on StackOverflow, and so on. But there are diminishing returns. The size of CPAN didn't keep Ruby from rising, and JavaScript and Python in turn have seen meteoric growth.<p>But that said, there is a fundamental tradeoff. Working in a popular language matters more if you're planning on leveraging lots of existing work. The more your project is building on what you yourself have built, the less important the easy start of external packages is relative to your own development familiarity. The more specialized the thing that you're building, the more it makes sense to use the perfect language for you/your space, rather than going with what's popular.