&gt; &quot;Lisp is itself a unique model of computing, and it generally unifies Turing&#x27;s and Church&#x27;s computational model in a relatively unbiased manner IMO. For that reason, I regard Lisp as the most flexible languages of all &quot;multi-paradigmed&quot; languages.&quot;<p>I agree that Lisp is a flexible language, what I disagree with is that this automatically makes it the &#x27;ultimate&#x27; language. By ultimate language I mean the best language we can ever create.<p>The reason I can say that is I see Lisp&#x27;s flexibility as a double-edged sword. On one hand you can adapt Lisp to match a task, effectively creating a DSL for the particular application you&#x27;re working on. On the other hand, the flexibility means that you cannot automatically assume as much about an application structure compared to some other languages.<p>This point about application structure is probably easiest to explain through the lens of type systems. Some of the benefits that type systems can give to other languages do not necessarily apply to Lisp. Do any Lisps have type systems? Sure they do, but they&#x27;re always optional. It is this that causes an issue. Consider if you were writing some application that used a Lisp type system, and now you want to pull in an external library that performs a set of functions that it would be non-trivial to implement. There are no guarantees that this external library has any types you can query, regardless of how you designed your own code.<p>Whilst I appreciate that some Lisp coders are comfortable with &#x27;rolling their own&#x27; when it comes to reusable libraries, I&#x27;m sure you can think of libraries that would be a lot of work to put together. For example, a library on natural-language processing.<p>Lisp has its advantages, but I think we still have room to improve when it comes to programming languages. Even if Lisp can express everything that can be calculated, there are other factors to consider when looking at the merits of programming languages.