>I learned Emacs in September, 1983
>It is now November, 2019
>...that’s over thirty six years!
>An amazingly long time.
Hmm, I think I learned Emacs around the same time. Yes, sometimes I think it is weird that I'm still using it.
I get a lot of pushback when I say that the developer environment hasn't advanced amazingly in all those years. Devs will point to one or more rather small incremental improvement. I'm sorry but I think we are still in the Bronze Age of programming.
But some of the main productivity drivers are distributed version control systems, dependency management libraries, and sites like GitHub for sharing code and libraries.
Being able to automatically generate a project from a template, and pull in any open source library written by anyone on the planet with a single line in a config file, is amazing.
Also, remote hosting and cloud provisioning to quickly deploy any code to be used by anyone in the world with a web browser. Arguably even app stores by eliminating the need to figure out distribution and payments on your own. (The stuff maybe not everyone considers "development", but is key to the overall productivity of any software project.)
Internet and resources like stack overflow.
Back in the days, I remember the isolation.
First from the domain, we could only run part of the application or use unnaturally tiny dataset meaning that the application behaviour in prod was an abstract concept. Hell, we could not even build the app at all on large application.
Second from knowledge. If you didn't know something, you needed to pick a book and read or find someone who knew. Nowadays, with a few hours on the net, you can build enough of a working knowledge of a tech to at least know if it is worth the investment.
There were newsgroups, basically SO on comp.* subgroups.
When working with code it's very powerful to work on a higher abstraction level. E.g. move this method to an other class and update all references to it automatically keeping the code correct. It takes a few seconds in a modern IDE while in a text editor you have to do most of it manually.
When you get used to the power of refactoring, you start to use it more and more, like a sculptor getting a more powerful tool.
Open source editors should pool their resources to create such powerful refactoring tools which can be accessible in any editor via LSP or something.
It would be much less efficient to create a program in a point and click gui, dragging visual elements onto the syntax tree.
So both is necessary. Efficient text editing is required to work quickly with the code, edit things locally efficiently. And refactoring is also needed if you want to perform bigger operations which span methods or classes.
An efficient text editor with completion + powerful refactoring. This is the winning combination.
Text programs are pretty efficent when writing, editing code, because you can access a large number of elements quickly with the syntax.
E.g. writing let a = 3 can be much quicker than starting some command palette from the keyboard, choosing the "declare variable" action and then fill some dialog with the name and value of the variable.
I have doubts it can be made as efficient as typing, otherwise we would have seen such prototypes already. Have you?
PyCharm: Yes
VS Code: Yes
Eclipse: Yes
The rant itself is probably misdirected towards LSP when it should be directed to the circumstances that it has to deal with.
That said, LSP is more supposed to be thought as the backend to the editor, not just a library. And the problem it solves are twofold:
1. Having to rewrite the same logic in all the programming languages used by all editors. Since as far as know, there are no language agnostic libraries, but a server is.
2. A strong boundary protects from accidental coupling of the UI/UX and the business logic. Without this, maybe at first you'd think you use some part of some other editor in yours until slowly over time it becomes more and more coupled to that particular editor's UX/UI. Even LSP actually suffers a little from that in that the APIs are totally designed with VSCode in mind first, but that stronger boundary protects it getting even worse.
The thing with Emacs is that you need to embrace Elisp, and the workflow of working inside a REPL. If you're someone who like to have things your way, and who are more comfortable with a programming language then a UI, Emacs is for you!
I personally use Spacemacs in Holy mode with Ivy and my own customization and some custom layers. I find this to be a great combination.
I use it for Clojure development with Cider and Java development with lsp-java. And for editing most files, like configs, scripts, bash files, json files, etc. I also use it for notes in org-mode.
The only things I rely on a different editor is Vim and less for dealing with large files like log files, and Notepad++ for when I need to do fancy search and replace stuff especially if the file is large.
Specifically, I feel that there is an anti-fragility to agreeing that we should all be able to write a program that can tell us about the programs we are writing. Getting languages that make this so that we all have to use a central server seems to put us at the mercy of who wrote that server. When it is that same group that wrote the compiler, it seems more likely that they will have the same blind spots.
I still do some of my personal projects in Emacs, and I still use Magit, and dired, and a few others, but by and large my professional development is mostly in the family of JetBrains editors.
Ideally, their code analysis could work through a server and use Emacs as a frontend, but the existing tools don't even come close to what those IDEs can do. Emacs is great, but it's not the most productive tool for me to edit large projects.
And that's being generous.