Who do you mean? The author of the tweet is Levent Alpöge, who does not have a PhD in math from Cambridge... but does have a PhD in math from Princeton. And his advisor was Fields Medalist Manjul Bhargava.
Also, there is no way this counterexample is wrong. You can very easily check it for yourself. (I did, I don't know why, obviously Levent wouldn't be wrong about this, but I guess I was in shock.)
Emacs can run external processes asynchronously. It is true that Emacs locks up while updating packages but it is actually not while downloading or unpacking them! It locks up while byte-compiling them. :)
> feel a little exhausted just thinking about needing to be on 14 different chat networks.
You do not need to be on all 14 to find Beeper useful! Even if you only use a few you might still want them to be together in a single app. As to why you might be on several different chat networks, you might have different friend or family circles that use different chat networks and may have failed to convinced them to move to a single one or, like me, may think it is a bad use of time to even attempt to convince them to. I'm using Beeper for WhatsApp, Telegram, Facebook Messenger and Discord and it's great!
And people wishing to delve even deeper switch back to R? I don't use it, but I understood that most advanced techniques in statistics are implemented first, and sometimes only, as R packages, no?
> As the link shows, the syntax section of the Vim manual offers suggestions to increase speed on slow computers for all syntax categories, tex being one of them. That does not mean all those categories are a problem in Vim itself.
Oh, absolutely! I should have said before that I edited many file types in Vim on that netbook and syntax highlighting was lighting fast on all types except LaTeX. Sorry if I gave the wrong impression. Unfortunately for me, LaTeX is by far what I most wrote at the time, so it was an annoying problem.
> So, baffling discrepancies; I wish software performance was more predictable.
Amen to that! I've even been on the other side of this issue, with some Emacs packages I've written. I've received reports of some operations being very slow that I've been unable to reproduce (even though I continue to use underpowered hardware because I value battery life more than speed —I'm typing this, in Emacs, on a 10 year old Chromebook!).
I was using a third-party plugin for markdown (I think it was called pandoc.vim), but for LaTeX files I was using only plugins that come with Vim. The documentation in :help tex-slow did suggest things to put in .vimrc to help make syntax-highlighting faster and I did try all of them. The only thing that solved the lag was disabling syntax highlighting for LaTeX completely.
The slowness I experienced for LaTeX files happened even without any third-party plugins installed, using a one-line .vimrc that only turned on syntax highlighting. So I think it is unfair to say "the slowness has nothing to do with Vim itself". Probably also "or the low power of the netbook" is unjustified, in the sense that the tips in :help tex-slow do likely solve the problem on computers a little beefier than my old netbook (which is probably more than 15 years old at this point). I mean, those suggestions are in the official Vim documentation presumably because they did work for someone.
Think of it this way: if the slowness of LaTeX syntax-highlighting were not a problem in Vim itself (where by "Vim itself" I'm including the vimscript files that ship with Vim, not just the executable), would it be documented in the official Vim documentation?
Taking notes in math courses in Vim on a netbook (remember those?) is what made me switch to Emacs! I tried taking notes both in LaTeX and in Markdown with syntax highlighting for embedded LaTeX math formulas, and Vim just lagged behind my typing —and I'm not that fast a typist. In the case of LaTeX this is a well-known problem that's addressed in the manual (see :help tex-slow). I tried all the tips the manual suggested and Vim still lagged, the only thing that fixed it was turning off syntax-highlighting completely. On a whim I tried Emacs, saw it was perfectly snappy (like Vim with non-LaTeX files) and switched.
My impression is that all of those are fads, we jsut haven't seen VS Code fade way yet, like the others have. I've used Emacs throughout all of those fads, seems easier than switching editors every few years.
I wouldn't characterize languages in the K family as particularly focused on math. They have vectors, but do not have matrices or higher dimensional arrays, they don't have a built-in to compute factorials, binomial coefficients, roots of a polynomial or hypergeometric functions. And Ks do have dictionaries and tables. Maybe you're thinking of J or some dialects of APL?
In my opinion, the language that comes closest to K's functionality and is also understandable by mere mortals is K itself. It is obviously extremely close to K's functionality and is a very simple language, the only reason it doesn't seem simple is that most people are used to verbose languages. A couple of days of practice is enough to make K readable, in my experience.
Also, I am constantly amazed at how concise K is, easily rivaling not only conventional languages but also much larger array languages like APL or J. Arthur Whitney's taste in selecting primitives is out of this world.
In what sense is @\: folding? Doesn't it take a list of functions on the left and a thing on the right, and returns the list of values obtained by applying each function to the thing?
Briefly: yes, you generate lots of temporary arrays, but it is not slow because it often allows the use of vector instructions and parallelism, it can be faster than a constant-memory loop that does not take advantage of vectorization or parallelization. Also note that most array language implementations reuse temporary arrays a lot doing in-place modification when possible.
If the necessary temporary arrays are really huge, array programmers will just do the computation in chunks that fit comfortably in memory.
Also, there is no way this counterexample is wrong. You can very easily check it for yourself. (I did, I don't know why, obviously Levent wouldn't be wrong about this, but I guess I was in shock.)