Re: [ide-dev] The LangEclipseIDE project

[Aleksandar Kurtakov <akurtako@xxxxxxxxxx>]

----- Original Message -----
> From: "Bruno Medeiros" <bruno.do.medeiros@xxxxxxxxx>
> To: "Discussions about the IDE" <ide-dev@xxxxxxxxxxx>
> Sent: Tuesday, 7 July, 2015 2:58:20 PM
> Subject: Re: [ide-dev] The LangEclipseIDE project
> 
> I have to echo some of what Simon Schäfer said. The (subjective) code quality
> of JDT is poor in many cases, several abstractions not very well done. (it's
> a bit too much to go into detail on what exactly)
> 
> I also echo that it is unfortunate that a project that tries to refactor
> common IDE infrastructure never successfully came to life. TBH, before
> LangEclipseIDE there was DLTK - Dynamic Languages Toolkit, which I consider
> to be the first serious attempt at this. DLTK is also based on cloned JDT
> code, and despite being named for "dynamic" languages, 80-90% of the common
> IDE infrastructure it provides applies equally well to any language, dynamic
> or not. That's why DDT used DLTK for most of its life span. But DLTK was
> short-lived and quickly lost backing, and this before they even had a chance
> to cleanup/refactor some of JDT's cloned code, so DLTK is left in a very
> poor state too.
> 
> So, despite the idea of a common IDE infrastructure project being discussed
> and talked about many, many times over, it never came to fruition. However,
> I am not surprised, or even disappointed that this is the case. This is
> because I understand that, Eclipse being open-source and having the
> corporate backers it has, such a big project would never materialize unless
> there was a corporate/business interest behind it. And there never was. IBM
> - for many years and probably still the main backer of JDT - does not really
> have any significant business interest in refactoring JDT out to make it
> easier for new languages IDE to be made (non JVM languages at least). It has
> some business interest in allowing the IDE to be extensible so that new
> *Java-related tools* could be built on top of JDT. Like Java EE tools, Java
> code analysis tools, etc.. And indeed there are lots of those.
> But if there is no business interest in a common IDE infrastructure project,
> I can't really expect it to happen, from that team at least.
> 
> The same thing happened with CDT. CDT copied JDT's code, and of course, could
> theoretically also have refactored that into a common IDE infrastructure
> project. But realistically, it would also not serve the business interests
> of whatever companies where backing CDT, so it didn't happen. (well, yes, it
> might have some minor benefits, but not enough to justify the *cost*)
> 
> Part II:
> 
> The thing that actually disappoints in the state of Eclipse, is shortcomings
> within the Platform code itself, core and UI. Not as in major new
> functionality I would want, but rather many outstanding bugs, both for me as
> an IDE user, and as an IDE plugin developer. Let me give some examples,
> which should also work as actionable items for people wanting to improve the
> state of things.
> 
> For example this bug:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=438765
> It affects me constantly, because it affects me every time I debug. Basically
> I had to live with the fact that my debug toolbar has to stay on the far
> left side of the workbench toolbar, I basically had to learn to live with it
> for the last year or so. This was reported in 4.4, not fixed on 4.4.1, and
> not fixed in 4.5 (Mars) either....
> 
> This is reflective of a general decline in technical quality and robustness
> of the Platform UI, which I blogged/commented on before here:
> http://pureconcepture.blogspot.co.uk/2013/08/the-state-and-future-of-eclipse-as-ide.html
> (originally a comment on Doug's blog)
> 
> 
> Going back on the issue of IDE plugin developers, let me pick up this comment
> from Mickael Istria:
> 
> 
> On Tue, Jul 7, 2015 at 9:17 AM, Mickael Istria < mistria@xxxxxxxxxx > wrote:
> 
> 
> 
> 
> 
> 
> 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. That's not true, there are multiple pieces of JDT
> that are now in platform.ui that were originally only Java-centric, and that
> were abstracted to be re-usable for other languages. Examples include
> Navigator, Working Sets and probably many others.
> But there are still some pieces of JDT that could be abstracted. There is a
> lot of interest for that, there have been many discussions, but not often
> actions so far. It would be nice to have you contributing to this effort.
> 
> 
> 
> Yes, the idea of the Navigator was quite good, fundamental in many ways to
> move the general UI design of the Eclipse workbench forward. Particularly, I
> think the way perspectives work is essentially flawed, limited. It's not
> good to have to switch perspectives merely for wanting to work with a
> different language. And for that to happen the Project Explorer view is
> essential.
> 
> The problem here is that the Project Explorer was never adopted fully, and
> remains rough in the edges. Why isn't JDT using Project Explorer as the
> default navigation view, instead of Package Explorer? I suspect I know the
> answer: the Project Explorer has several limitations and/or bugs, compared
> to Package Explorer, and the JDT ream doesn't care about it enough to fully
> move to it. They've had more than enough time...
> 
> Here's some bugs I've reported just on Navigator, as an example (which remain
> open despite being an year old)
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=447737
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=429572
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=430005
> 
> Again, I get the feeling that because none of this bugs directly affect JDT
> (or other JDT-like IDEs), they get no love...

I'm not directly involved in JDT but I closely monitor it for a number of reasons.
I can ensure you that your perception is not correct - it's not like JDT developers ignore such bugs as non interesting. My observation is that the current developers have their hands full with only supporting new Java language and JVM changes and this is an area which is with critical priority. Also working on this area requires deep compiler/bytecode/jvm internals knowledge thus being quite hard to get into. And supporting running on/targetting latest JVM is the thing that is the N1 priority as otherwise it renders the whole IDE unusable for big group of devs. 
The bugs you referred to are way more isolated and allowing for others to join the project. We need people spending few days to contribute a patch and as soon as majority of users understand that they can really make a change the quality will grow significantly. There are just so many hours in the days so most people start from priority 1 problems and sometimes manage to get to lower priorities.
In short this is not ignorance - it's pure physics (aka hours in the day).


Alexander Kurtakov
Red Hat Eclipse team

> 
> 
> --
> 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