It is possible to make a dynamic language natively compiled and very fast. Common Lisp is arguably even more dynamic than Python, and SBCL manages to generate code that rivals C in performance.
I don't consider Common Lisp “more dynamic” than Python; at least in that you modify code at runtime and such. Frequently Common Lisp code is not particularly dynamic, because you can get the same level of expressiveness without relying on mucking around with magic at runtime.
Also SBCL only generates really fast code if you use a lot of type hints and (optimize (speed 3) (safety 0)). That said, when you do, it's really fast.
Typically Common Lisp and its implementations provides a wide range of performance options. It's not limited to the model of some more primitive language runtimes, which provide only two modes (simplified): slow if implemented in the language, fast if it runs mostly in its runtime and library functions written in C. There are Common Lisp implementations which follow this model, too. But there are also many which have sophisticated runtimes with optimizing native code compilers.
To get to really fast code in Common Lisp one needs to write relatively low-level code with type declarations, optimization hints, low-level operators etc.
There is a part of Common Lisp which is as dynamic (more?) as Python: everything written in CLOS (multi-dispatch, multi-methods, method-combinations, ...) and expecially when using the CLOS MOP. Is it slower or faster than comparable Python code? I have no idea and I haven't seen any interesting benchmarks. The amount of CLOS use depends on the implementations. Some implementations have a lot of their library code and also much of the language itself (everything IO, error handling, ...) written using CLOS.
I have written plenty of heavily CLOS-based code that is still very fast. I doubt that Python could come close in performance.
I think it would be an interesting exercise to do some benchmarks to get some actual data behind both of our guesses.
As I am not a very experienced Python developer, would you be interested in writing some test code that is representative of typical Python code, and I'd be happy to port it over to CLOS and so that we can run some benchmarks?
I think such results would be of interest to the HN audience.
Well, whatever the problem is, setting up the processing, parsing input files, checking inputs might not need to be fast but much more secure and user friendly.
This -at my experience- often requires very «dynamic» structures in the form of intricated hash table/dict that requires to be correctly set, malloced, modified. JSON like stuff.
You may do it safely in python/perl/php/tcl way more than handling your memory in C/C++/ASM. It is easier, more error prone, and faster. And no real speed is required.
Sometimes what we search is the right tool for the right problem.
Setting up a software is often a big part of the code that consume a lot of lines of code, while often a small part of the execution time. And the priority is often on correctly handling/checking the input without buffer overflow/undefined behaviour much more than speed.
So I totally think that the idea of using the right tools for the jobs is a good idea. Imagining one language can do all, is pure religion.
I wouldn't even be surprised that one day we have a description language used only for setting up and distributing messages à la VHDL instead of trying to "integrate it" either in the OS with "dynamic buses" or with "runtimes".
Also SBCL only generates really fast code if you use a lot of type hints and (optimize (speed 3) (safety 0)). That said, when you do, it's really fast.