3 ms·

While they're very obviously in the "competition-induced" panic, there is still a point. The disconnected VSC model - main company in charge of the editor, and

While they're very obviously in the "competition-induced" panic, there is still a point. The disconnected VSC model - main company in charge of the editor, and third parties in charge of certain language plugin[s] - puts some languages' support at risk of being insufficiently developed. I "only really want advanced editing + syntax highlighting + language server", and use VSC, but, while its support for "statically typed languge #1" is ok, the support for "dynamic language #2" is atrocious, to the point of being unusable (poor "go to definition", editor aggressively misaligning lines of code, etc.). I'm not sure it will ever reach sufficient support. On an IDE, this doesn't happen, because the developing company must, within a certain qualititative extent, take care of all the functionalities.

kitd 6y ago
Yes, that is always the risk with nuturing an OSS community to provide the less-than-core functionality. OTOH: 1. it encourages the main company to simplify and/or extend the plugin API to make writing plugins v simple, or even possible in the first place. 2. it gives a smoother path for the inclusion of new trending technologies into the IDE. 3. it encourages devs to offer improvements to features that aren't high priority for the large IDE company. For the latter, I'm thinking of Lombok support which, via a plugin, is much better in VSCode than it is in either Intellij or Eclipse.
int_19h 6y ago
I'm not sure what your definition of an IDE is, but the notion of a core platform with language-specific extensions on top long predates VSCode. Visual Studio proper works in exactly the same way, for one; and then there's Eclipse, NetBeans etc. If anything, this has been the conventional way to do IDEs since early 00s or so.
- pjmlp 6y ago
  Even earlier, Turbo Pascal 6 came with the Turbo Vision framework which was used to create the IDE as well. Studying how the IDE made use of Turbo Vision was a good introduction to OOP ideas.
- jolux 6y ago
  With Code they’re running out of process and communicating via IPC/RPC most of the time which introduces instability that I’ve never experienced in Visual Studio, Rider, or IntelliJ
  - int_19h 6y ago
    There are many things in Visual Studio that run out-of-process, and coordinate via IPC. It's an implementation detail, and does not change the fundamental approach. Also, many things in VSCode can be done in-proc as well if one so desires, including debuggers and language servers. Most extensions do them out-of-proc because it gives them more flexibility (esp. wrt implementation language for those components), and because it's easier to test such isolated components.
    - jolux 6y ago
      Yeah, and I hate Visual Studio for the most part too. It's a bloated mess. JetBrains' .NET IDE Rider is much better.

kitd 6y ago

Yes, that is always the risk with nuturing an OSS community to provide the less-than-core functionality. OTOH: 1. it encourages the main company to simplify and/or extend the plugin API to make writing plugins v simple, or even possible in the first place. 2. it gives a smoother path for the inclusion of new trending technologies into the IDE. 3. it encourages devs to offer improvements to features that aren't high priority for the large IDE company. For the latter, I'm thinking of Lombok support which, via a plugin, is much better in VSCode than it is in either Intellij or Eclipse.

int_19h 6y ago

I'm not sure what your definition of an IDE is, but the notion of a core platform with language-specific extensions on top long predates VSCode. Visual Studio proper works in exactly the same way, for one; and then there's Eclipse, NetBeans etc. If anything, this has been the conventional way to do IDEs since early 00s or so.

pjmlp 6y ago
Even earlier, Turbo Pascal 6 came with the Turbo Vision framework which was used to create the IDE as well. Studying how the IDE made use of Turbo Vision was a good introduction to OOP ideas.
jolux 6y ago
With Code they’re running out of process and communicating via IPC/RPC most of the time which introduces instability that I’ve never experienced in Visual Studio, Rider, or IntelliJ
- int_19h 6y ago
  There are many things in Visual Studio that run out-of-process, and coordinate via IPC. It's an implementation detail, and does not change the fundamental approach. Also, many things in VSCode can be done in-proc as well if one so desires, including debuggers and language servers. Most extensions do them out-of-proc because it gives them more flexibility (esp. wrt implementation language for those components), and because it's easier to test such isolated components.
  - jolux 6y ago
    Yeah, and I hate Visual Studio for the most part too. It's a bloated mess. JetBrains' .NET IDE Rider is much better.