[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ide-dev] The LangEclipseIDE project
|
On 7 Jul 2015, at 8:31, Maarten Meijer wrote:
The problems all come from the fact that Platform and JDT are/were
different groups of people. Conway's Law: Code comes to represent the
organisation that creates it.
So Eclipse Foundation should restructure the projects to solve this.
The Eclipse Foundation does not really have that power/mandate.
This is up to the projects and companies behind them to do.
/max
Kind regards/vriendelijke groeten
Maarten Meijer
@eclipsophy
Op 7 jul. 2015 om 01:57 heeft Simon Schäfer
<mail@xxxxxxxxxxxxxxxxxxx> het volgende geschreven:
On 07/06/2015 03:38 AM, Lars Vogel wrote:
Non-blocking code completion with a stream as input would IMHO also
enhance the JDT code completion quite a bit.
Simon, did you ever try to contribute that back to JDT?
No, I did not. Since we write everything in Scala nowadays, we would
have to rewrite our code in Java if we want to contribute it back.
Also for the limitations in eclipse.core could you give same
examples?
The first that comes to mind are the internals. As a Scala developer
I care a lot about (subjective) great code quality and its
maintainability. By looking at the internals of eclipse.core,
eclipse.ui and nearly everything in JDT the only impression I get is
that its developers tried hard to take Effective Java (the book by
Joshua Bloch), reverse all the rules and then apply them to one
codebase. Code quality may not matter if you can pay all the devs but
it matters if you want to find new contributors and nowadays there
are not even a lot of payed devs anymore.
A related problem is that Eclipse wants to be a platform to build
IDEs upon but refused for its entire existence to provide the
abstractions to build an IDE. Nearly everything is in JDT, which was
only made for Java. Every other language implementation had to either
fork JDT, extend it or rewrite everything from scratch.
Extensiblitiy looks different. The LangEclipseIDE project comes 10
years too late actually, people moved on to IntelliJ and they will
never come back.
When I look at the code of Eclipse (better: the projects mentioned
above, which are relevant for building an IDE) I always get the
impression that no one of the contributors actually understood what
abstraction means. This more or less means that nothing is
extensible. There is this great plugin system Eclipse is built upon
but it was created to handle JDT and when the chance of handling
other languages came up, it was not taken.
Instead of pushing IDE features, people pushed the RCP stuff. While
doing that they forgot that Eclipse is being sold as an IDE and by
refusing to accept that they moved the entire platform on ground.
Over the years it was easy for IntelliJ to take over. And other
platforms like Atom, Visual Studio Code and even Neovim are rising
because they fill gaps Eclipse just can't fill.
I don't know why the Eclipse foundation just couldn't see that the
IDE sector is what made Eclipse important and what keeps Eclipse
alive. I only know that they killed Eclipse for IDE/plugin developers
by completely fucking up the internals and by doing that they also
killed the platform for all of their users.
As a concrete example, just look at eclipse.ui: All of the
improvements you and others did there lately were mostly none for me
or for my coworkers. In fact there were so many regressions
introduced we couldn't even report all of them back, we just get
pissed off. It took me half a year to even adopt Luna and Mars
doesn't look better. In fact I only moved on to Luna because I had
to. This is not how you gain trust in a platform. What did I hear
lately? Android IDE completely moved to IntelliJ, guess why.
Best regards, Lars
Am 04.07.2015 3:42 vorm. schrieb "Simon Schäfer"
<mail@xxxxxxxxxxxxxxxxxxx>:
On 07/03/2015 06:35 PM, Bruno Medeiros wrote:
"Do you have any plans to provide programming language
independent UI components"
Yes, in fact that is the main focus of LangEclipseIDE at the
moment. However, being currently a one-man project, it's not as
feature-full as JDT, nor will it be any time soon. But it's not
too shabby either. This section has an overview of
what UI functionality/components it currently provides:
https://github.com/bruno-medeiros/LangEclipseIDE/blob/master/README-LangEclipseIDE.md#functionality
Ok, great to hear. I'll have a look if there is something we could
use.
So yeah, for example: content assist, code snippets ("Templates"
in JDT lingo), preference pages for all that, outline and
quick-outline (no hierarchical outline support though).
However, no Junit view, nor package explorer support. Well not for
displaying Java-like flat packages at least, but there is some
support for other Project Explorer extensions: stuff like project
dependencies and (in an upcoming version) build targets. I dunno
how well that applies to Scala though.
No code folding support either (DDT has that functionality, but
it's crappy code copied from DLTK that hasn't yet been
cleaned-up/refactored, and put into LangEclipseIDE).
One interesting thing that LangEclipseIDE has, that doesn't come
from JDT or JDT-like IDEs, is functionality to help you integrate
external, command-line tools to provide IDE functionality. For
example in Goclipse, the outline is provided by an external parser
(updated on the fly as the user types in the editor). Again dunno
if that would apply well to Scala.
Calling command line tools is not necessary in Scala IDE, since all
the tools are already written in Scala and therefore can simply
added as a library to the IDE.
Sidenote: Funny enough, unlike JDT, the Goclipse outline is
updated almost instantly as the user types, because there is no
artificial delay to start the reconciler (I dunno why that delay
is in JDT in the first place). Not that it matter much anyways -
personally I haven't used the Outline view in ages, Quick-Outline
is much more handy.
We use the reconciliation time because the Scala compiler is slow
as hell and takes enormous resources during compilation. It can't
be aborted during compilation of a single file either. Therefore,
calling it on every keystroke would more or less be impossible.
Given that the Scala compiler is so slow a lot of APIs can't be
used or make some features difficult to implement. Code completion
for example can take some seconds before completion. Because the
JDT API just takes a list of completions we have to block users
until the compiler is finished. If the API would take a potentially
infinite stream of completions, we wouldn't have to block but could
show new completions once they appear. This forces us more or less
to re-implement all APIs in a non-blocking/reactive way and makes
it more difficult to use work from others because for most
languages one does not need to think about the compiler being to
slow.
-
On Fri, Jul 3, 2015 at 3:06 PM, Simon Schäfer
<mail@xxxxxxxxxxxxxxxxxxx> wrote:
Scala IDE dev here. A few years ago I would have welcomed such a
project, nowadays I lost faith in the Eclipse platform. There are
too many internal issues and
limitations that make using the eclipse.core and especially the
jdt.core API a pain. This means that over the years we reduced
dependencies to these APIs as much as possible and replaced them
with our own implementations.
We still depend on JDT because that is how we started and while
our core is ready in moving away from JDT our UI is not. JDT
provides some useful stuff like the package explorer, the outline
view, the junit integration etc. and we don't have the resources
to replace them by ourselves. Do you have any plans to provide
programming language independent UI components? This could make
your project useful to us, for core API we probably don't have a
need anymore.
On 07/03/2015 03:34 PM, Bruno Medeiros wrote:
Hi guys. Doug pointed me to this mailing list, so I wanted to
let you know about a project I've been working on:
LangEclipseIDE.
LangEclipseIDE is a framework/library for building language IDEs
on top of Eclipse. It aims to provide common functionality that
is present in IDEs like JDT or CDT but is not refactored out
into an externally reusable component. So the aim here is
similar to DLTK, but the overall design is different in some
ways (even though we reuse bits of code from JDT and DLTK).
https://github.com/bruno-medeiros/LangEclipseIDE/blob/master/README-LangEclipseIDE.md
LangEclipseIDE is currently used by 3 IDEs: DDT, RustDT, and
Goclipse. It's still a young project so there is much more that
could be done. It would be nice to get some collaboration going
with other IDE projects as there is a lot of potential for that.
--
Bruno Medeiros
https://twitter.com/brunodomedeiros
_______________________________________________
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
--
Bruno Medeiros
https://twitter.com/brunodomedeiros
_______________________________________________
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
_______________________________________________
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
/max
http://about.me/maxandersen
