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
