Eclipse: a decent open-source tool for development
November 05, 2019
Eclipse: a decent open-source tool for development
Score 7 out of 10
Vetted Review
Verified User
Overall Satisfaction with Eclipse
Eclipse is used by various people but is not generally used by the organization. I was a user before I started at SurveyMonkey and continued to use it up until early in 2019. The company has generally not encouraged any particular IDE until this year. Most folks tended to use SublimeText, with a fair number using PyCharm, and only a few of us on Eclipse. Those of us using Eclipse like it's fully integrated debugging environment for Python (which also attracted users to PyCharm, which is essentially Eclipse with paid-for enhancements). I particularly liked being able to use it to access SQL Server in the same environment as Python and Javascript.
- It is very good at managing many files under edit. I like the ability to manage multiple projects and multiple files. It supports a wide variety of file formats with type-specific syntax formatting.
- I like the integrated debugging facility. In particular, we used a remote file system debugger with Python in external VMs to great effect.
- I like the ability to access multiple types of databases in the integrated development environment. It provides connectors for a wide variety of databases and supports most basic DB access methods.
- GIT integration is very effective. You can easily manage repositories and connect them to projects, and the project integration into GIT is virtually seamless.
- While the DB integration is broad (many connectors) it isn't particularly deep. So if you need to do serious DB work on (for example) SQL Server, it is sometimes necessary to go directly to the SQL Server Studio. But for general access and manipulation, it is ok.
- The syntax formatting is sometimes painful to set up and doesn't always support things well. For example, it doesn't effectively support SCSS.
- Using it for remote debugging in a VM works pretty well, but it is difficult to set up and there is no documentation I could find to really explain how to do it. When remote debugging, the editor does not necessarily integrate the remote context. So, for example, things like Pylint don't always find the libraries in the VM and display spurious errors.
- The debugging console is not the default, and my choice is never remembered, so every time I restart my program, it's a dialog and several clicks to get it back. The debugging console has the same contextual problems with remote debugging that the editor does.
- It worked very well for me for many years. Alternate environments were available, but the integrations were never quite as thorough. Overall, it had a positive impact on my development by allowing me to work in multiple environments and many different projects relatively seamlessly.
- Since we developed in VM environments, Eclipse was painful to set up, but once set up worked better than the alternatives. Most of my colleagues using environments other than PyCharm revered to CLI debugging of python clients, which was quite painful. Overall, Eclipse made my development process smoother and more efficient.
- The plethora of tools and integrations available for Eclipse was often confusing and made upgrading painful. I tended not to upgrade on major revisions despite the improvements because the process was too painful.
I've used Microsoft Visual Studio, Eclipse, and VSCode. Visual Studio was very good but highly oriented towards a rather limited set of uses. I chose to use Eclipse for two primary reasons:
First, it was more flexible, Open Source, and supported a much wider variety of languages and tools.
Second, I wanted an environment that was independent of any of the ones companies I worked for would standardize on because I did a fair amount of development for personal reasons and I didn't want to be switching back and forth all the time.
This past year, I switched to VSCode because my company standardized on it and maintaining Eclipse separately became too much trouble. For those areas in which most of my development occurred, VSCode worked pretty well.
First, it was more flexible, Open Source, and supported a much wider variety of languages and tools.
Second, I wanted an environment that was independent of any of the ones companies I worked for would standardize on because I did a fair amount of development for personal reasons and I didn't want to be switching back and forth all the time.
This past year, I switched to VSCode because my company standardized on it and maintaining Eclipse separately became too much trouble. For those areas in which most of my development occurred, VSCode worked pretty well.
Do you think Eclipse delivers good value for the price?
Yes
Are you happy with Eclipse's feature set?
Yes
Did Eclipse live up to sales and marketing promises?
I wasn't involved with the selection/purchase process
Did implementation of Eclipse go as expected?
No
Would you buy Eclipse again?
Yes