Cheers!
The fastest composite Python "framework" is uvicorn at 17.9% of the fastest run in Java (officefloor). The fastest Clojure run is Aleph at 36.4%.
https://www.techempower.com/benchmarks/#section=data-r21&l=z...
About SBCL, I get conflicting results. The Benchmarks Game shows it roughly as fast as Java for many problems:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
But here it's significantly worse than the Clojure runs, likely due to the slow DB bindings (the other test types show it roughly in line with Clojure; though it uses a "Stripped"/unrealistic HTTP implementation):
https://www.techempower.com/benchmarks/#section=data-r21&l=z...
I am not sure which Lisp implementation is used; is it SBCL? Does this file speak to you?
https://github.com/TechEmpower/FrameworkBenchmarks/blob/73eb...
[1] https://renato.athaydes.com/posts/revenge_of_lisp-part-2.htm...
You're 90% there. Lisp notation obviates the need for arity tracking, which is why in lisp + and sum are the same function:
Add higher order functions, e.g. (λ (x) (x x)), and lisp notation is the simplest/only way to deal with the general case where you don't know ahead of time the arity of the function you'd be applying because of partial currying and data persistence.As for the parsers this was 10 years ago at university. I've long since lost the source code. There weren't any problems with python, it's just that once I wrote the lisp version I realized just how useful the brackets actually are. There's a reason why every computer language is more or less context free. Lisp just takes that to its logical conclusion.