[gjvc]

That's how all their IDEs work. It's all the same software with different sets of allowed plugins.

From where did you get this idea -- basic use? It most certainly is not this to as great a degree as you might like to think. Source: JB employee.

[notpushkin]

Could you get into more detail please? From my (brief) experience with your products I think the differences are indeed mostly in the plugins, apart from cosmetic / UX ones, like different keyboard shortcuts (which by the way never made sense to me).

There's nothing wrong with selling sets of plugins by the way. I don't really get why it must be different IDEs though.

[gjvc]

There's nothing wrong with selling sets of plugins by the way. I don't really get why it must be different IDEs though.

This was exactly the line of questioning I had for my JB friend, some time ago.

[bornfreddy]

So... Did you get some answers? :)

[gjvc]

Only insofar is that there is less of a grand framework for the language analysis and manipulation, refactoring, and syntax and error highlighting than one might think. (I still find this hard to believe, but perhaps this was due to an impedance mismatch between me and my JB interlocutor.)

I was under my own (pretty pedestrian) assumption that the secret sauce of JB IDES is/was the MPS system in which they are/were able to create libraries for source code analysis and manipulation on a language-by-language basis. I further assumed that this per-language library plus some language-specific GUI tooling, plus the language-independent GUI libraries and processing (local history, VCS integration, side-by-side textual (not semantic) diffing tools, and so on)

The response I got, which was quite a while ago (2019 or before) was that the individual language IDEs did not use MPS-generated libraries in perhaps the extensive way I've alluded to above, and this surprised and disillusioned me somewhat. I was hoping to get as much of an answer from my JB friend as, presumably, you were from me in this thread. :-)

Yes of course, there must be massive code reuse between projects, and yes, this was an entirely hand-waving set of assumptions, and no, I haven't researched the composition of any given JB IDE to find out the proportions of language-independent vs language-specific code volume.

I'm surprised someone at JB hasn't given a talk on this sort of thing over the years.

[bornfreddy]

Thank you for the extensive answer! Yes, I guess some code reuse would make sense, but when growing it is difficult to know which abstractoon makes sense, so from the business perspective it is often a better strategy to copy and adapt code, even if that means worse maintainability down the road.

[0x457]

> There's nothing wrong with selling sets of plugins by the way. I don't really get why it must be different IDEs though.

Uhm, I've tried using Ultimate for Java and Rust. It wasn't pleasant at all. Different IDEs make total sense to me.

[notpushkin]

What difficulties did you run into?

[mroche]

In my relatively limited experience with PyCharm and GoLand (with a hint of CLion/IDEA), the individual IDE's make working with a language much simpler and straightforward. Using the language plugins within another IDE adds a few layers of friction with trying to find settings, panels, etc, whereas the IDEs offer workflows OOTB designed for that particular language.

Sorry I can't provide specifics, it's been a hot minute since I've used a JB product but I did enjoy my time with them.

[0x457]

Well, Ultimate is very java specific out of the box. Doesn't help that I use it for java as well. I could possibly have multiple profiles for different use cases, but why? All Product bundle after 3 years is cheap enough that paying for it isn't noticeable at all.

[gjvc]

BTW, to avoid ambiguity.... I am not a JB employee, my source is/was a JB employee.