Many years ago, Eclipse as a whole had a few promising points: * Open-source, with an apparently large community * Extensible within itself via plugins * Som

Many years ago, Eclipse as a whole had a few promising points: * Open-source, with an apparently large community * Extensible within itself via plugins * Some interesting GUI features: * User- and plugin- definable and customizable "perspectives" that captured specific workflows, e.g. debugging, language X editing, schema editing, etc. * For its time, relative to other IDEs (Visual Studio, I'm lookin' at you) a much easier approach to managing panes and tabs to the user's liking. * The fantastic ability to quickly narrow the settings pane navigation via text search. OS X's System Preferences later added a similar feature to find & narrow pref panes based on a keyword search. I still feel that there's untapped opportunity for GUIs and traditional editor modes (emacs/vim) to leverage spinoffs from this interaction model. That said, Eclipse never seemed to surmount what I feel were its major difficulties: * The Workspace -- IMO the most absolutely toxic abstraction an IDE has ever had. All "projects" must live under a "workspace" which is both an on-disk top-level directory+data that users must cope with above their project(s) and an inescapable in-code monstrosity that plugin writers must also cope with. This was a mimicking of other IDEs that thought it was a good idea to maintain an entire separate organizational data structure for code that created a separate hierarchy that duplicated and obscured the on-disk organization, and a short-sighted hard-coding of a Java-centric mindset where any non-trivial codebase was certainly going to consist of multiple interdependent projects. The Workspace was a core architectural disaster. A symptom: it made Eclipse ridiculously painful to use to, e.g., "just edit a python file". Contrast with TextMate's lightweight approach of "a directory is a project" and fast in-project navigation/fuzzy search tools. No state was required other than what was on disk. TextMate's full power and bundles were available with zero friction for either project-centric for file-centric work. * Speed -- The more time goes on, the less excusable Eclipse's dog-slow performance is. Early on, it was easy to overlook its slugishness, because reasons. Some recent work has had me suddenly delving back into (two different!) Eclipse projects, and its amazing just how the poor the UI responsiveness compares to other modern environments, even on screamingly fast hardware. * Extensibility schizophrenia -- Despite Eclipse being extensible through plugins, those were really envisioned as third-party shippable modules. User configuration was a separate second-class sytem, entirely GUI-managed, and a major pain to clone to a new system. Compare to how Emacs & Vim work with a VCS-managed home directory, or even just a zip file or tarball. In no small part, this came from Eclipse's foundations on an early Java/JVM compiled-only mindset. With no scriptability baked into that platform, there was little choice but to have a strong divide between code (plugin) vs. data (configuration).