Languages are not slow or fast; their implementations are. There's absolutely nothing wrong with Emacs being programmed in Lisp and it sure as hell isn't "a poor architectural decision". If Emacs is slow because of its implementation of Emacs Lisp, it's time to fix its implementation of Emacs Lisp.
> There's absolutely nothing wrong with Emacs being programmed in Lisp and it sure as hell isn't "a poor architectural decision"
I love Scheme and Lisp. I've probably written several million lines of code in both Scheme and Lisp and I've contributed code to several Lisp and Scheme compilers.
But languages are absolutely slow or fast! There are fast Schemes and Lisps and there are slow ones. Emacs has probably the slowest one by far. For example, Emacs still relies on dynamic binding after all of this time. That's a performance disaster.
There is simply no efficient implementation of Elisp possible as it stands and as it is used today. Even with JIT compiling Elisp performance is simply wretched.
> I've probably written several million lines of code in both Scheme and Lisp
BTW you do realize that this would put you at (sustained, average) several hundred lines of code per day (every day) over your lifetime? That sounds almost depressingly bleak to me. How does one have a life outside of that?
> BTW you do realize that this would put you at (sustained, average) several hundred lines of code per day (every day) over your lifetime? That sounds almost depressingly bleak to me. How does one have a life outside of that?
Grad school sure puts you on the right track of getting good numbers like this! :) And the answer was, not having a life outside of grad school.
Well, you did say "several millions", so that would be more like 2000 lines. And depending on the environment, I'm aware of many people who do much less (not of their own volition or choice), so I have little faith in a long-term average being this high. I'll have to take a look that what Capers Jones wrote on this...
Then the codebase needs to fully (or as much as feasible) transition to the use of lexical bindings. It's not like we don't know if it will work; Common Lisp supports dynamic variables but you don't pay for them unless you actually use them, and good implementations of CL are fast enough. So what exactly is it that prevents the Emacs Lisp code base from becoming fast enough by abandoning dynamic variables wherever it can? By all rights it should not be any slower than Common Lisp at that point, unless some other obstacle has somehow eluded my attention.
> But languages are absolutely slow or fast! There are fast Schemes and Lisps and there are slow ones.
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.
Actually, I would go even further than saying only implementations are slow or fast, they are slow or fast for certain use cases.
> There is simply no efficient implementation of Elisp possible as it stands and as it is used today. Even with JIT compiling Elisp performance is simply wretched.
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.
> 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).
Languages are not slow or fast; their implementations are. There's absolutely nothing wrong with Emacs being programmed in Lisp and it sure as hell isn't "a poor architectural decision". If Emacs is slow because of its implementation of Emacs Lisp, it's time to fix its implementation of Emacs Lisp.