> You are contradicting yourself. If languages instead of implementations were slow or fast, then their would not be fast and slow Schemes and Lisps. Scheme would be either slow or fast.
You are unfamiliar with the huge differences between what counts as a "Scheme" or a "Lisp". Neither "Scheme" or "Lisp" are a language, they're language families. The difference between Schemes is larger than the difference between say C and Ocaml, or Haskell and Javascript.
Depending on what features a particular Scheme or Lisp has, it can range from insanely fast (like, faster than an optimizing C compiler), to mediocre (like Python), to dirt slow, like current Elisp. It all depends on what the language has, and how it encourages you to write code. For example, having a type system tends to make your language very fast.
> Actually, I would go even further than saying only implementations are slow or fast, they are slow or fast for certain use cases.
Compilers are not magic. And compiler technology has not fundamentally advanced for decades now. There are basic limits to what a compiler can do. Some language features simply destroy performance, and the lack of some language features prevent compilers from getting good performance. And then, yes, there is also style. For example, relying heavily on language features that are inherently slow, will do you no favors.
Elisp is the pinnacle of a terrible language used in a terrible way. It lacks all features that make languages fast. It has plenty of features to defeat optimizations and preclude having any fast implementations. And people write Elisp in a gory style that makes everything worse.
> I agree in so far as there will --- probably --- never be an Elisp implementation which can run numeric intensive code as fast as the best Fortran or C compiler for this task. But it is certainly possible to improve the performance of ELisp even more than native-comp branch did. The question is whether there are people capable and willing to invest the time to develop that and whether spending that time on the language implementation is the most useful way to spend that time.
I don't care about numerical code. I care about the fact that emacs is dirt slow.
It's been many decades now. Elisp performance has barely budged. Even the native branch only marginally improved things in some edges cases. There is zero evidence that more effort for faster implementations will go anywhere.
In general. More developer time doesn't meaningfully speed up a language even on the timespan of decades; this means like even say a huge effort, a millenium worth of hours of developer time (100 developers full time for 10 years), makes no serious difference to the performance of the average app running on the JVM (a few percent), it mostly just patches edge cases. It's the same in Haskell. GHC 7, from 10 years ago, is marginally slower than GHC 9.4 if you run the same large app in both.
What makes a difference to performance is changing the language. Adding language features that the compiler can understand (that's why say, Haskell code is far faster today than it was 10 years ago, it's a different language, with different features, that we write in a different way).