I wish to be proved wrong too. The current situation of "LLM" and "GPT" are very much like a hype. I cannot see how they can be used beyond problems that does NOT require accuracy and precision.
IMO the problem lies on "magical thinking" that we can just say a spell and have the computer presenting the best solution ever without even knowing what we specifically want at the first space. Kind of like asking the AI for the answer to the meaning of life, the universe, and everything - "forty-two" (from <<A Hitchhiker's Guide to Galaxy>>)
Personally, when I use them a lot of time I realised I am basically typing the whole detailed requirement specification out. First, it will be much more efficient for me to just do it myself. Second, in such cases existing technologies like formal methods seem more suitable as we can verify our specification's soundness too. And most modern approach to formal methods can do code generation too.
Latest research (https://arxiv.org/abs/2404.04125v1) on image-text and text-to-image models shows that these pre-trained few-shots learners exhibit a log-linear relationship with "concept frequencies" and their performance on tasks. Hopefully this does not translate to LLMs but my bet is that they do.
I love Emacs but I just don't find editing LaTeX on Emacs an enjoyable.
I am mostly using Overleaf (overleaf.com) which is free for individual use.
They only charge for collaboration features and integration with bibliography management software. Free for universities and institutions back then when I was using it a lot, not sure about it now.
Now I find that writing in org-mode then export to LaTeX is the best experience you can have on Emacs. I can do pretty much everything I wanted to do, math typsetting, and even Beamer.
A big warning though, is that you still need some configuration and you will need to be aware of that you are writing for LaTeX export in order for a smooth experience. Especially when you have code blocks with long lines.
Maybe I should write up an article on this some day as tutorials, such as the one for Beamer (https://orgmode.org/worg/exporters/beamer/tutorial.html) does NOT completely cover all the issues that you will face during writing.
As much as I love my experience with Homebrew, it is not easy to maintain it so understandably the project tends to only support the latest few OS versions.
This can be problematic for older laptops.
Linux on the other hand tends to work better, even for older computers.
The Homebrew project is also said to be insecure, and have a tendency to be a bit authoritative, as in ignoring criticisms, but thats another story.
When I first switched I mainly rely on easy custom, with minimal lisp code. However, a few issues:
1. many popular packages did NOT implement for custom (e.g. by declaring with defcustom), especially those that are not in MELPA.
2. the built-in customisation is NOT efficient, especially on startup
3. The customisation UI is sometime buggy, especially for themes.
So I ended up switching to configuration with straight + use-package + org-mode after Emacs 29 got released for a while. I done some GC optimisation as well and this made my Emacs startup gone from ~5s to ~1s, also much smoother response in general.
Now that I have been using Emacs as my main editor for a few years, I can't really imagine my life without org-mode.
Really it is just too good of a feature, if for somehow I have to switch in the feature, my number 1 requirement would be feature parity for org-mode (extremely unlikely). AFAIK, none of the "magical" modern editors have that, except the most basic org file text editing functionality.
I was mainly using the now sunset Atom (VSCode forked from Atom) back in school and a little bit Emacs 28 when using terminal.
With the built-in custom it is not too difficult for me to make the switch after Atom got killed by Microsoft. I can't imagine how difficult it must have been back then for new users before the easy customisation features. It is a good decision by the maintainers. I probably would have gone for VSCode otherwise.
Org-mode is also another killer feature that I chose Emacs over VSCode. Now I do work management, literate programming, and typesetting via LaTeX in org-mode.
Maybe I haven't used Emacs for long enough but I don't think any other editor could be any better except the commercial ones which you have paid for maintenance.
The thing I like about Emacs is that the community really supportive of hacking the editor to work the way you want it to work. The new LSP and tree-sitter feature are both originated from the community! The community's preference of keyboard-centric editing is also quite appealing to me.
Admittedly, without any configurations Emacs is not very good to use, and improper configurations such as lack of `with-eval-after-load` can lead to slow startup. Poor Garbage Collection mechanism and lack of multi-threading makes it pretty slow at times.
However, I can see that the community is still very active, and with the existence of the many community-maintained configuration (Doom Emacs, Spacemacs, etc.) you can defer many of the configuration burden to people who care and only focus on the features that you are using the most. Hopefully this can translate to slowing down the "emacs bankruptcy" to a rate that is slower than your own configuration commit frequency, then "emacs bankruptcy" can be practically irrelevant. Combining this with introduction of official LSP (and unofficial DAP) it should be able to stay relevant for a long time.
IMO the problem lies on "magical thinking" that we can just say a spell and have the computer presenting the best solution ever without even knowing what we specifically want at the first space. Kind of like asking the AI for the answer to the meaning of life, the universe, and everything - "forty-two" (from <<A Hitchhiker's Guide to Galaxy>>)
Personally, when I use them a lot of time I realised I am basically typing the whole detailed requirement specification out. First, it will be much more efficient for me to just do it myself. Second, in such cases existing technologies like formal methods seem more suitable as we can verify our specification's soundness too. And most modern approach to formal methods can do code generation too.
Latest research (https://arxiv.org/abs/2404.04125v1) on image-text and text-to-image models shows that these pre-trained few-shots learners exhibit a log-linear relationship with "concept frequencies" and their performance on tasks. Hopefully this does not translate to LLMs but my bet is that they do.