Re: [ide-dev] VS Code

[Mickael Istria <mistria@xxxxxxxxxx>]

On 09/13/2016 10:46 PM, Pascal Rapicault wrote:

Project-less workspace is the way to go for all projects. At at time where Java did not had build tools to structure things, Eclipse concept of project made sense. Now that every language and ecosystem comes with a build tool, the concept of project a-la Eclipse is becoming an annoyance.

Several other languages still don't have decent build tools, and if you think about people beginning with Java, they don't have build tools.
This concept of "projects" is IMO a natural and good one, the issue in Eclipse IDE isn't its existence but its interaction with overlapping concepts, such as build tools or edition capabilities according to enabled natures. All IDEs have some project or module concept, and it's pretty convenient to browse an enriched scoped tree when manipulating them.
The issue with Eclipse IDE is that many code assistance features only work if 1. file is part of an existing Eclipse project (with .project), 2. this project is loaded in the workspace and 3. the project has the right nature; whereas several of them could work without these constraint.
So yes, every feature should do its best to work directly on a File (not requiring an IFile). Should it be a recommendation for the UI Working Group?

It seems though that VS Code is very reluctant to introduce anything resembling forms, or even widgets. Everything seems to be text based, even their Preferences settings brings you to a JSON editor. I think it’s kind of ridiculous, especially for new users.

    This is a strategy that makes sense for a number of reason:
    - It allows to tool a language / fwk faster
    - You don't have to play catch up with the tool as options are being added, removed, etc.
    - Guard you from knowledge gap / leaky abstractions. The typical case would be you change something in the fancy UI, then something fail in a strange way, you go to stackoverflow to discover there is a file you did not know and don't know how to edit (worst to find that your tool is busting the file)

Giving opportunity to edit directly the preferences as a file would be nice for some users, but a dialog that gives clear explanations, shows the right widget for the possible value, layout widgets logically according to their interactions, show validatiors... seems really good and necessary for the vast majority of people IMO.
--

Mickael Istria
Eclipse developer at JBoss, by Red Hat
My blog - My Tweets