Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ide-dev] The LangEclipseIDE project

Hi Simon,

after all Eclipse is Open Source - you cannot expect other to step up and do exactly what you need essentially for free.

Please find inline comments.

On 7 July 2015 at 01:57, Simon Schäfer <mail@xxxxxxxxxxxxxxxxxxx> wrote:


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.

So you started writing everything in Scala from the very first day so you never had the chance to contribute 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.

This is all very vague and a general criticism that doesn't help those who do the hard work on the platform. Saying 'everything is bad thus I don't tell you what exactly is wrong' is just not helpful.
 

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.

Agreed, JDT is not easily extensible in its core abstractions. I also understand that many different parties are crying for an extensible JDT. But this is the tragedy here: so far nobody contributed any patches back that would change this situation.
 

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.

Which kind of extensible APIs do you miss? Again saying 'nothing works' won't yield anything.
 

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.

Agree, I also think this is a problem. Still it's not how things work. In the end, the members of the foundation pay the bill and thus they help to steer. On average, they don't build IDEs though.
 

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.

Still no concrete point that could be worked on so far.
I understand that you're frustrated, but staying in the mood won't change anything. Since you build an IDE on top of Eclipse, you probably have an interest to improve the platform. It would already be helpful if you could at least name concrete issues or file tickets for the things that piss you off.

Best,
Sebastian
 


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.


_______________________________________________
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


_______________________________________________
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