Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ide-dev] Java IDEs comparison


----- Original Message -----
> From: "Pascal Rapicault" <pascal@xxxxxxxxxxxx>
> To: ide-dev@xxxxxxxxxxx
> Sent: Thursday, 8 September, 2016 2:26:43 AM
> Subject: Re: [ide-dev] Java IDEs comparison
> 
> On 9/7/2016 5:34 PM, Greg Watson wrote:
> 
> 
> 
> 
> 
> 
> On Sep 7, 2016, at 1:34 PM, Doug Schaefer < dschaefer@xxxxxxxxxxxxxx > wrote:
> 
> I don’t know the internal organization of JetBrains, but their products show
> they have a strong architect who sees the big picture of their entire
> product suite and makes sure they have the frameworks in place that they all
> can reuse to make their products consistent, integrated, and easy to
> construct. And they have a strong product manager who knows what excites
> users and drives the development team to build those things.
> 
> Well, we have an architecture council. Shouldn’t they be the ones charged
> with doing this? Otherwise, what do they do exactly?
> This is definitely something that the architecture council would work on,
> because many of its members deeply care about the IDE.
> But for this to work, project leads have to agree that they are not sovereign
> in their projects and have to adhere to requests like:
> - Cleanup your UI, UI contributions.
> - Make sure your keybindings are those
> - Integrate better with this or that plugin
> - ...
> 
> Would you agree to such a thing? How would your employer react to that?

I would agree with it and believe that my (and any other employer who invests in Eclipse) will benefit from it thus not object. But the main issue arises after the agreement - who will do it? Should your/my employer have to put more resources? Should architecture council come up with decisions that are executable with resources provided from people there? The first is not an easy sell as history has proven, the second (if answered positively) will limit the decisions taken from architecture council as it effectively bounce back to first question for people at the architecture council.
 

> 
> 
> 
> 
> 
> 
> Greg
> 
> 
> 
> 
> 
> 
> Doug.
> 
> From: < ide-dev-bounces@xxxxxxxxxxx > on behalf of Dawid Pakuła <
> zulus@xxxxxxxxx >
> Reply-To: Discussions about the IDE < ide-dev@xxxxxxxxxxx >
> Date: Wednesday, September 7, 2016 at 1:08 PM
> To: Discussions about the IDE < ide-dev@xxxxxxxxxxx >
> Subject: Re: [ide-dev] Java IDEs comparison
> 
> 
> 
> 
> My 5 cent: consistency, consistency and again consistency...
> 
> Problems that I always hear from IDEA/Neatbeans fan’s. I know that lot’s of
> them are already on bugzilla.
> 1. Language-specific perspective is a horrible idea as they mostly replace
> Project Explorer by <Language_Name> Explorer, simplify “New” menu, overwrite
> default ctrl/cmd+shift+t and add couple tabs to bottom area. For me
> Java/RAP/PHP/CDT in future could have by default only two perspectives
> opened: Resource (please rename it) and Debug.
> 2. Madness in “New” wizard first page. Netbeans/IDEA have strong separation
> between creating project and file (any other element)
> 3. Working sets, one of most powerfull thing in eclipse isn’t widely
> supported across projects, examples:
> 3.1. “Window Working Set” entry sometimes isn’t available in fast view menu
> (Platform views), sometimes is (JDT school based views)
> 3.2. Working sets types not always available between views, for example still
> is not possible to import existing project into mylyn working set directly
> 4. Lot’s of problems and incositency between editors. Eclipse 4.7 may bring a
> hope ;)
> 5. Lack of suport for in-languages (SQL, template engines, etc...). Writing
> support for them across file types is mostly immpossible becuase most
> editors haven’t generic (any) support for color and assist extensions.
> 6. Freezing UI during CA. Still may happen, especially if extension need
> access to web during CA and something goes wrong. Bugzilla record pending
> since years.
> 
> --
> Dawid Pakuła
> 
> From: Carsten Reckord <reckord@xxxxxxxx>
> Reply: Discussions about the IDE <ide-dev@xxxxxxxxxxx>
> Date: 7 September 2016 at 17:38:39
> To: Discussions about the IDE <ide-dev@xxxxxxxxxxx>
> Subject: Re: [ide-dev] Java IDEs comparison
> 
> 
> 
> 
> > It's surprising how the code completion of IntelliJ (checking target type,
> > frequency of calls, chain completion...) is still listed as better than
> > the one in Eclipse IDE. Wasn't Code Recommender providing that in all
> > Java-based packages?
> 
> I don't have empirical evidence, just my subjective impression, but one
> problem with completion that I frequently encounter in Eclipse and that IJ
> seems to get better is the local context that I'm working in. If there are a
> dozen proposals for the current completion, we often don't have to look as
> far as global frequency, chains and all that:
> 
> Just prefer the type that is already imported in the current class over the
> one that isn't, the type or variable that I've used in the line just above
> where I'm asking for completion over other applicable ones, the method in my
> current class over some external type proposal, etc.
> 
> > Also, it's strange that IJ is congratulated for its "Polyglot
> > development", where the Eclipse ecosystem has a much better offering. The
> > reason is probably that people compare IDEs as they're shipped, not
> > ecosystem.
> 
> In general, the IJ people shine in two "polyglot" areas here:
> 
> 1. Consistency: editors and tools look and work the same across languages,
> whereas there are many (small but annoying) UX differences between different
> editors and language scopes in Eclipse.
> 2. Cross-Language features: I haven't tried this in Neon, but before,
> navigating between artifacts of different languages, getting usages etc was
> just way more seamless in IJ.
> 
> But I hope with the new extensible editors and the language server initiative
> this is about to improve dramatically :)
> 
> 
> _______________________________________________
> 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

-- 
Alexander Kurtakov
Red Hat Eclipse team


Back to the top