Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ide-dev] Benefits of integration with code server and new generic editor for average Eclipse user
Just to give an example, having a language server for JDT would bring JDT support to Eclipse Orion, assuming the Orion editor supports the language server protocol.

Dani



From:        "Gorkem Ercan" <gorkem.ercan@xxxxxxxxx>
To:        "Discussions about the IDE" <ide-dev@xxxxxxxxxxx>
Date:        30.06.2016 15:42
Subject:        Re: [ide-dev] Benefits of integration with code server and new generic editor for average Eclipse user
Sent by:        ide-dev-bounces@xxxxxxxxxxx




The language server initiative is not aiming ONLY Eclipse IDE. It aims
to cover desktop editors, online IDEs and classic desktop IDEs.
Most of the work related to definition and implementation of language
servers — at least for the time being — is happening
outside Eclipse.

I think what we are discussing mostly on this list is “how should
Eclipse IDE enable easy access to language servers?”
IMHO, Eclipse has nothing to gain by ignoring language servers. Of
course adding easy access to language servers does
not mean abandoning JDT and CDT or any other successful language tooling
but rather adding new languages to Eclipse IDE and hence
widening its audience and community.

Language servers are also beneficial for the language tooling projects
too. For instance, I have been using JDT and M2E to implement
the java-language-server and I hope through language servers these
projects will be exposed to new communities.

—
Gorkem


On 30 Jun 2016, at 9:13, Serhiy wrote:

> Mickael,
>
> You wrote that
>> IMO, there are much more users not using Eclipse IDE because of
>> average
> TypeScript support or non-existing C# support than because of those
> missing
> completions on lambdas.
> Do you really think that .net developers will start downloading
> Eclipse as
> crazy just after you add C# editor? I know many .net developers and
> they
> will laugh hearing such statement. If you can't run VS on Red Hat
> Linux
> there is MonoDevelop for this and you can run VS Code on Linux. This
> may be
> my personal problem but I do not get why would people choose Eclipse
> for C#
> development. Really don't get it. Are you going to port all of the
> additional functionality they (VS) have beyond code editor as well?
> Debugger, mobile development tools (to replace Android development
> tools)
> and so on.
>
>
> By reusing existing code server for TypeScript you by definition will
> get
> the same features as VS Code already has. This is the best case
> scenario
> you can get from this. So why should anyone bother to use Eclipse if
> they
> already have same features in VS Code and VS? Why not to use VS Code
> or
> WebStorm instead starting from right now? In any case you will be
> offering
> the same features in best case.
>
>
> I agree with one statement:
> --
>> We cannot say the current state is good for everything and will
>> remain
> forever.
> --
> Yes, this is what I was telling that there are issues even for JDT.
> And
> they will never be solved by adding new editors for new not yet
> existing
> (or just different) languages.
>
>
> The bottom line is that your answer is very clear. And it is:
> --
> Some of Eclipse contributors have goals that go beyond the current
> Eclipse
> user base. The current user base isn't necessarily what drives all of
> us.
> --
> plus
> --
> so far, it seems like those issues are not top-priority of any
> contributor
> according to their vision of the IDE.
> --
> clear and honest.
>
> Serhiy
>
> On Thu, Jun 30, 2016 at 2:44 PM, Mickael Istria <mistria@xxxxxxxxxx>
> wrote:
>
>> On 06/30/2016 01:04 PM, Serhiy wrote:
>>
>> I do understand that new editor can get TypeScript support by means
>> of
>> tsserver. At the same time there are multiple existing TypeScript
>> plugins
>> for Eclipse and one of them already uses tsserver:
>> https://github.com/angelozerr/typescript.java/wiki/Why-TypeScript-IDE
>>
>> This plugin is somehow a lesson to learn. Client-server is a very
>> good
>> approach to developing dev tools. The idea now is to make it easier
>> to
>> consume consistently inside Eclipse IDE rather than expecting
>> developers to
>> repeat the same work over and over again.
>> TypeScript editor inherit from the JSDT editors, which requires a lot
>> of
>> other plugins to work and that provide many useful extensions. One of
>> the
>> current goals from Eclipse IDE point-of-view is to provide this
>> extensibility in a lower layer that anyone could more easily reuse
>> without
>> depending the the JSDT editor stack.
>> The work of making an editor generic and extensible enough was
>> already
>> done in WebTools SSE editors. We're trying to move it to Platform.
>>
>> It is possible to get support for C# in Eclipse.
>>
>> How? Do you know decent C# tools for Eclipse IDE?
>>
>> And I am absolutely positive that this is not the most needed feature
>> across current Eclipse user base.
>>
>> Some of Eclipse contributors have goals that go beyond the current
>> Eclipse
>> user base. The current user base isn't necessarily what drives all of
>> us.
>>
>> I understand that others (non-Eclipse) can benefit from converting
>> JDT to
>> code server. But for Eclipse IDE and JDT itself it will hardly give
>> any
>> benefits.
>>
>> Some Eclipse contributors also have goals that go beyond just the
>> Eclipse
>> IDE ;)
>>
>> I mean that all understand that Microsoft will not contribute any
>> features
>> to Eclipse or JDT.
>>
>> Never say never. I guess a couple of years ago, someone wrote
>> "Microsoft
>> will never contribute .NET under MIT license". See where we are now.
>>
>> Why would they help to develop any free Java based project after they
>> killed robovm and do not support Java in their "Azure Functions"
>> (just for
>> reference PHP and Bash are supported).
>>
>> Those proposals regarding generic editors and language services are
>> not
>> meant to attract more help from anyone in particular. They're mostly
>> meant
>> to provide a faster and factorized way to develop features in all
>> IDEs/editors at once.
>> With or without Microsoft contributing to Eclipse IDE or JDT
>> directly, the
>> Eclipse IDE can take advantage of the proposed approach of Language
>> Services.
>>
>> Eclipse already has plugins for all major languages
>>
>> correction: all *current* major languages and file formats. And even
>> so,
>> some major languages of the software industry are still missing good
>> support. We cannot say the current state is good for everything and
>> will
>> remain forever.
>>
>> so rewriting them to be able to expose same functionality via code
>> server
>> by definition will not add anything few to Eclipse IDE.
>>
>> There is no plan to rewrite anything AFAIK. The proposals so far are
>> about
>> supporting a new editor/set of services to implement support for new
>> features.
>> Imagine tomorrow, someone contributes an awesome language server for
>> Go;
>> with an unbeatable completion. Then if we already have the framework
>> to
>> consume it, this can be adopted trivially and Eclipse IDE can take
>> advantage of it ASAP. If we're not ready for it, then all competitors
>> will
>> adopt it, they will have a critical advantage on Eclipse IDE, Eclipse
>> IDE
>> will loose users.
>> Remember algorithmic: Greedy decisions are usually not the optimal
>> one.
>> Focusing only on the current state without vision may lead to
>> irrelevancy.
>>
>> At the same time there are requests for Eclipse core features which
>> are
>> not addressed for years. For example, even now after more that 2
>> years
>> after Java 8 was officially released (not counting time it was in
>> developement) Eclipse content assist functionality still has no
>> support for
>> lambda _expression_ completions. Other example is that
>> <https://www.eclipsecon.org/na2016/session/faster-index-java-or-cdt-pays-its-debt-jdt>
>> https://www.eclipsecon.org/na2016/session/faster-index-java-or-cdt-pays-its-debt-jdt
>> is developed outside of Eclipse. Eclipse Android tools are not very
>> actively maintained.
>>
>> Every contributor is free to work on what is the most important for
>> them.
>> So far, it seems like those issues are not top-priority of any
>> contributor
>> according to their vision of the IDE.
>> However, there are programs by the Eclipse Foundation and some member
>> organization that basically allows one to "buy a feature" by a
>> regular
>> development contract. If someone is willing to pay for that, they'll
>> probably find some contributors to do it...
>>
>> Don't get me wrong. It's open source project and you decide what to
>> implement. And I really don't want to offend anyone. I am just
>> struggling
>> to understand what this can give to average Eclipse IDE user. And it
>> is
>> quite sad for me to realize there is a chance that Eclipse can get
>> yet
>> another TypeScript editor or even C# support before having that
>> (reported
>> in 2014) issue with lambda auto completion support addressed.
>>
>> IMO, there are much more users not using Eclipse IDE because of
>> average
>> TypeScript support or non-existing C# support than because of those
>> missing
>> completions on lambdas.
>> Contributors cannot be in every fight at once. This generic editor
>> and
>> language server seems to be the fight many contributors are
>> interested in
>> winning now. IMO, it's a good tactical choice, but your mileage may
>> vary,
>> and you and all other contributors are free to work on other topics.
>>
>> Cheers,
>> --
>> Mickael Istria
>> Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
>> My blog <http://mickaelistria.wordpress.com> - My Tweets
>> <http://twitter.com/mickaelistria>
>>
>> _______________________________________________
>> ide-dev mailing list
>> ide-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or
>> unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/ide-dev
>>
> _______________________________________________
> ide-dev mailing list
> ide-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/ide-dev
_______________________________________________
ide-dev mailing list
ide-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ide-dev

Back to the top