[krick]

Most comments here either praise IDEA-variants as "outstanding", or blame it for being "slow and complicated", both of which feel odd to me (especially the first one). I strongly prefer JetBrains products over anything else, so if it's possible to use PyCharm, I will use PyCharm instead of Vim/VSCode. Yet I cannot imagine calling it outstanding. Maybe, that's just my bad character overall, but I just am surprised why is it that all IDEs/code editors suck so much. About 5 years ago, when LSP appeared (introduced by VSCode IIRC), many people predicted that soon they will far surpass IDEA's (and the likes) autocompletion, etc. And honestly, I believed them. Why wouldn't it? It seems like a simple task, once you have generic LSP functionality, the rest should be "just details", like finding/making good data source for particular language/lib/etc.

And all that JetBrains IDEs do, feels to me like a pretty simple stuff. Like all these refactoring options (pretty much the main reason why I prefer their IDEs over simpler editors, it feels like a natural extension of Vim keybindings: why should I do anything as simple as extracting a method manually?), it seems like a thing that should be easily scriptable once you have powerful code-editing API, so I feel annoyed by the fact they are pretty much "hard-coded" into IDE and I cannot easily add a couple of my own simple refactorings. BTW, they didn't really change over the last 5 years or so. Some bugs get fixed, static code analysis gets smarter and more specialized for a current version of some language, but nothing that would feel like real progress. It's hundreds of tiny distinct things, and it seems like that would progress much faster, if all these things were open-source plugins. As people predicted, when LSP came about. Yet apparently it doesn't, because as imperfect PyCharm is, VSCode cannot do even as much.

So, basically, what distinguishes IDEA from anything else seem like super simple things, and it seems weird that for it it must compromise to use that clunky, configurable via UI (instead of neat JSON/TOML/whatever), memory-hungry IDE. And it still puzzles me. Of course, if it seems so simple, it's fair to ask why I didn't make my own yet. Well, yes, I didn't even look into it. But I just cannot understand, what's the hard problem that community struggles to solve, why all opensource or semi-opensource editors didn't leave clunky "traditioinal IDEs" far behind yet with regard to these core function, even though it seems those traditional IDEs haven't evolved for years?

[jeroenhd]

> I cannot easily add a couple of my own simple refactorings

While this isn't as powerful as the full plugin API, there is Edit > Find > Replace Structurally which can be used to write some pretty complex code alterations, and you can save/load templates to reuse them later.

IMO Jetbrains IDEs are the best IDEs. That doesn't make them amazing or great or outstanding. They have their bugs, their resource leaks, and sometimes just plain weird design decisions, but they're ahead of the competition by a long shot for many programming languages. Other IDEs can match what Jetbrains has to offer, but you have to install and configure every feature yourself, while the Jetbrains stuff mostly comes with batteries included.

[sesm]

JB products have in-memory PSI (as opposed to LSP queried over network), and this PSI by it's nature is multi-language, so they support language injections naturally. This comes in very handy when you are writing an HTML file with embedded CSS and JS, or when you have inline HTML strings or regexps in your code.

[mike_hearn]

A lot of what you're talking about is open source. Here's the extract method refactoring (Version 2):

https://github.com/JetBrains/intellij-community/tree/44a42be...

As you can see it's not that easy. At the core of an IDE is a database that has to incrementally update itself based on real time edits that can arbitrarily break the datasource (code) that the database is modeling, often in highly confusing ways. Refactorings often require sophisticated data analysis in order to not break code themselves, they aren't simple at all.

The LSP architecture complicates things further by introducing an asynchronous data structure synchronization problem between frontend and backend. Jetbrain's architecture is conventional, with analysis and UI running in-process. They can share data directly and use locks for mutual exclusion. The downside of this is that if locking isn't fine grained enough, or if the GC causes stalls, you can get UI hitches and sluggishness. The upside is that it's a pretty dramatic productivity upgrade because you aren't solving all these hard distributed computing problems that the LSP design introduces.

So the question becomes who solves their problems first? Jetbrains and Oracle have done a ton of work in recent years on solving these problems. Java GC pause times have been driven down aggressively, now there are fully pauseless GCs available although I don't know if IDEA uses them yet. GC pauses haven't been visible for me in years at any rate. And Jetbrains have done lots of work over time to reduce the amount of lock contention that can cause UI stalls, to introduce limited amounts of asynchronous replication within the process and so on.

The thing is, when you're in-process you can use the same ideas as in the LSP to reduce UI latency but to whatever extent makes sense or is necessary in a specific context. Nothing stops you tossing in an actor with a queue if you want that, or introducing a lock if a UI stall is in fact preferable to the alternatives (and sometimes it is). But you aren't bound to it all the time. Whereas the LSP design with separate processes and a hard address space separation doesn't allow that. To add anything you need to extend the protocol and handle the possibility of data skew between frontend and backend, which introduces a lot of surface area for bugs, which then drains time that could be spent on fixing refactoring bugs or adding new static analyses. So it's a hard tradeoff and one isn't clearly a winner to the other.