Next Generation Eclipse IDE
eclipse.org
eclipse.org
Considering how much of a resource hog modern C++ compiler is for example (I hear good things about Scala as well) it would be nice if I could use a lightweight low powered front end machine to edit code and then have the backend bother with parsing, compiling, etc. People do this already with distributed builds so why not make it baked into IDE with code analysis as well. Maybe the OS can even save memory if you run multiple instances on stuff like executables, etc.
What I really don't like is how developers are pretending that HTML is the only client side technology if you go client->server route. To me architecting this as a HTML app shows 0 benefits - the install time is irrelevant - I am a developer - I know how to install applications and I do this for all my other IDEs, the time it takes me to install a thin client is irrelevant.
All this "use JS/DOM as front end" does is either :
compile to JS -> introduce an extra compile step, a shitty VM emulation, worries with interop and leaky abstractions
use JS -> poor semantics
and both are abusing a layout model made for documents into application development model that gets really inefficient at rendering.
IDEs are at the top of GUI complexity - why make shit even more complicated by doing things that slow development down - if they would for example write the frontend in something like JavaFX (not having used JavaFX I'm only speculating here, but I heard good things) it would probably be equally good (if not better) and at the same time it would make development a lot simpler.
Back in the bad old days GNU emacs was written in LISP but it always seemed pretty peppy.
Today there are a lot of editors written in modern scripting languages and/or the JS/DOM environment such as Atom and Light Table and they all seem just a little bit laggy.
I had a simple thought - it should be possible to let anyone anywhere contribute to any project without first installing software. you should be able to click a link and then everything you need is generated for you - the workspace, the projects in that workspace, the environments that power those workspaces.
Now, if you are on a desktop, you may want to wire in your existing IDE to integrate with that workspace. But if you are a product manager and just want to test some code, you don't want to install anything. So a browser experience is necessary then.
Generally, we have never seen the browser experience as the replacement objective or substitute. But it is a necessary deliverable for those who do not wnat to bother with installing software first.
Codenvy takes Che and is working to provide this sort of no-install workflow around a concept we call factories. You start in a private anonymous screen, click a link and everything you need to continue working is there. Really hard problem - that is what we focus on commercially.
But at the core of it, we needed a portable workspace server that had a web IDE. We chose GWT for the development of the GUI because of the cross browser portability and performance optimization. It's a brutal technology but we get a lot of nice optimizations. We have started some explorations to support Vaadin for dynamic reloading of widgets and have some partners who may help us with a pure JavaScript client, too.
We are embedding all of the language services within the machines that power the environments that the workspace is bound to. We use either localhost or docker depending upon your configuration. Since everything is within, the actual comms between browser and the workspace machine is limited. So you can get a pretty darn good expeirence. The file operations are localhost native, so we are able to process Java files with 50K lines at about the same speed that Eclipse or Netbeans does (minus the part of the file system being inside of the docker container).
I don't have any objective data, but perhaps it's due to the Kool-aid. It was the second text editor I used (Notepad++ being the first). I fell in love immediately.
When I put my ear to the ground and listen really hard, I can hear the vibrations of a herd thundering by in the distance. I think I know that noise, I've first heard it when people were XMLifying everything back in 2000.
It does have a problem with files bigger than a few MB tho - but native editors like gedit chooked on that too so I can't blame them too much.
And it has that smooth input animation that not many native editors have but it adds so much to the feeling of responsiveness (other editor I've noticed using this is latest intellij versions).
My point wasn't even so much about performance, with enough effort you could work around most of the issues (at least in some browsers, kind of dumps on the idea of "portability").
My point was that the whole GWT -> JS this took or the coffeescript Atom took is such a pain on the ass to develop with compared to a real GUI toolkit - just think of the developer productivity without the stupid GWT compile times, special cases, etc.
Think how nice of a development expirience you would have with something like Kotlin + JavaFX, or C# and WPF.
I really really wish Microsoft would open source GUI stack from Silverlight and let community maintain it as a cross platform GUI framework for CoreCLR - they already had it running on OSX meaning it can run on non-windows tech - meaning the porting path exists, and a lot of work went into silverlight GUI controls historically, plus it's WPF compatible. They could make "portable profile WPF" from it if they wanted, and also target mobile and desktop, from Visual Studio and Visual Studio Blend - the ultimate Enterprise app development platform
In the 2nd and 3rd generation codenvy systems, we tried to duplicate some of the JDT capabilities for Java directly within the browser with webworkers. We had to write that in JavaScript. I believe this is how C9 handles their support for HTML, CSS, and JavaScript.
We had pretty decent support, but there were all sorts of issues: having to rewrite JDT services is nearly impossible and really the domain of language teams, the browser has limited context where many intellisense services need access to multiple directories and meta information, and there were some performance issues in certain edge cases that are hard to resolve without having certain I/O and cache mechanisms (which are readily available on file systems).
So the VSCode model of reusing the language services and then layering on a stdin / stdout protocol is pretty smart. We are doing a similar approach with Che, but instead of stdin / stdout, we are packing a restful interface on top of the JDT & JavaScript services. We see some potential to consolidate vscode & other approaches into a multi-language intellisence server, powered by REST + stdin + stdout. That would be really fun to have all programming languages remotely accessible through a common protocol.
Back in the really old days, when desktop computers came with just a few megabytes of RAM at most, people used to joke that emacs stood for "eight megs and constantly swapping."
Of course I am biased as I am the cofounder of Codeanywhere.com which is a Cloud IDE its self.
But just to make a point we actually built all of Codeanywhere inside Codeanywhere. Welcome any comments...good or bad :)
Coding from a hammock on a tropical beach with nothing more exotic than a generator running for a few hours in the evening to keep the lights on and the beers cool in the bar (and your battery topped up). Sailing in remote parts of the Caribbean, with a little wind turbine on the boat to charge your machine (and again keep the beer cold). Hell, even trying to work from a coffee shop in England with their quaint idea of "internet" and "wifi" even in 2015.
Your laptop weighs three pounds. Take it someplace nicer than your living room!
I'm so much less productive when I try to work without internet, that I don't try. I can read, write, play games, or get off the computer and get my head right for work, during that downtime, but the idea of writing code without internet just doesn't appeal to me. We are beyond that point in terms of software complexity. Building things of value is no longer simple enough to do all on your own, a lone coder in the woods (or on the beach or on a boat).
I'm curious how many of the things you've suggested are activities you've actually done while writing code? Sounds like a Corona commercial...not really a software engineering story.
Arusi, Columbia (a tiny fishing village a 2 hour launch from the nearest town where you can get an overnight boat to a city connected to the rest of the country by a road), Tonsai Beach, Thailand, back before they had power or internet. And a couple months sailing in the San Blas islands off Panama. Parks, campsites and random comfortable boulders in the forest are pretty regular worksites, even building real shipping products with paying customers.
Even the dreaded English Coffee Shop really happened (I live there half the time and have a hard enough time getting BT to deliver internet to my house with any reliability).
I find that a good IDE removes pretty much all the Googling from my life. I know what you mean though, having written my share of Ruby and Python, where you're constantly on Google trying to remind yourself what order to pass parameters to File.Open(), and completely aswim with a 3rd party API. But Intellisense knows everything there is to know about C#, Javascript, CSS, etc. and will either tell me about it or just finish writing my line of code for me with a quick key chord.
I tend not to rely on 3rd party code for simple things I can write myself, so I don't spend as much time Googling React or Angular into submission as your average modern dev. For genuine 3rd party APIs like AWS or Stripe, you're right. It's hard to test that stuff until you're back online. They all have libraries though, and again the IDE has your back as far as implementation is concerned.
Good luck with the RV life!
http://www.expatsoftware.com/articles/uploaded_images/parrot... http://www.blogabond.com/Photos/PhotoView.aspx?imageID=8479 http://www.blogabond.com/Photos/PhotoView.aspx?imageID=992
For the more easily distracted among us, it works the other way around :)
Wouldn't he have said "you fail, that is why"?
But setting up JDK and IntelliJ|Eclipse|NetBeans typically takes five or ten minutes. After that you can use your environment everywhere and have a native experience (as far as native is possible using Java ;)).
It will be fast with or without internet, it will continue to work as-is when the company creating the IDE goes under or decides to double prices, I can use it with local tools (Git, Mercurial, JVisualVM), and my secret sauce does not end up on somebody else's server.
Everyone asks what the core value proposition. In a distributed cloud environment, it's developer bootstrapping, securing distributed workspaces, and moderning legacy build processes. These are capabilities that only exist when you have a shared distributed server system.
We took the kernel and created a new IDE out of it to demonstrate a couple things: 1. Environment & workspace portability 2. RESTful services on top of language tools like JDT 3. Production / development container interoperability 4. Extension framework for a cloud IDE
We haven't launched Che yet becuase the legal & branding review process at Eclipse is extensive. We hope to finally be done within 3 more months.
But we encourage everyone to check out 4.0 branch of git and then build that.
It is doing a few things: 1. Worksapces are quietly powered by environments, backed by machines which are docker or localhost. This enables each workspace to be isolated with a stack apart from others.
2. We will also demonstrate workspace portability. You can move an entire workspace and all of its tools from Che to Che, or from Che to cloud. And the environment will continue to run identically in each location.
3. We are running the full JDT and other language services inside of the machine. We wrap these with RESTful wrapper. And then it allows the browser to gain capabilities for maven, refactoring, and a variety of powerful intellisence, and it's generally the same speed as localhost.
4. You can then exec commands, debuggers, and ssh into the workspace machines.
5. We have also done a project with Red Hat to enable your workspace environments to have the same docker container structure as production. We will shortly release a plug-in for OpenShift and Kubernetes that let's projects move back and forth with limited configuration. Becuase they are both running on a common container architecture.
While we can solve workflow problems in our distributed system, such as a workflow we call continuous development, we wanted to have a fully fledged desktop IDE to demonstrate that this could have the performance and security of other types of tools. So we are working to have this installation be very fast and lightweight.
You guys are seeing the intermediate builds so it's got a lot of rough edges.
Note: Please if you are going to do some testing, try it on the 4.0 branch. The design is much better and the performance is very good. The 4.0 branch is when we started embedding the JDT services into the mini Che that runs inside of the workspace machines. git clone https://github.com/codenv/che git checkout 4.0 cd assembly-sdk mvn clean install
Collectively, we are working on a broader platform that has a goal of letting anyone anywhere make contributions without first installing software.
Orion is primarily a client-side technology. It's designed to offer a multi-page browser experience that has simple plug-in approach for customizing the client side experience.
Che is primarily a workspace server, with a focus on workspace portability and interoperability.
In fact, Che embeds Orion as the core editor, the diff editor, and some other components.
Che has a browser IDE that we have built that embeds Orion on the client side, along with adding in additional constructs that we needed for debugging, single page management in the browser, and some other items.
We use Gitblit. Since it is self-contained application, it (literally) takes just a few minutes to set up [1]. After that, the number of repositories, users, and repository size is only bound to technical limitations. I get the impression that GitLab is also pretty simple to install these days with the GitLab Omnibus packages.
And even if you want to use GitHub or BitBucket for your proprietary code, adding yet another company to the loop only increases the probability that your code will be stolen in e.g. a security incident.
[1] Perhaps also important: it integrates with internal authentication servers (LDAP, etc.).
So again I don't see a difference between GiTHub and Codeanwyhere in that aspect.
Of course if you don't use GitHub you people by wont use us...and that's OK.
Microcomputers solved the problem of portable powerful processing, so I do not see why I would defer the processing elsewhere. It isn't a problem that needs solving.
Also, I have yet to find a cloud IDE that has proper support for building iOS apps. Sure you can delegate the builds to some external build service, but sometimes you do need the flexibility of a local build environment for advanced debugging and working around certain issues.
Further, even if it is there, if you have bad reception, assuming a good connection is in place hurts the experience. If you design your product as "connection is needed for some things", it will be way better than "connection is always perfect".
As an example, I hate when I'm about to read a webpage opened previously on my browser, and then somehow, something triggers a refresh, I don't have good reception, and I need to wait minutes for the page. One person assumed connection will be quick and it is ok to discard my copy and wait with a blank page until the next one loads; another assumed that huge pages are ok, and putting the content last in the html is also ok, and then, I end up without the content.
As someone who isn't a web developer, the question seems ludicrous to me.
It's important to note that when you need to do offline development, you need to do offline development. A toolchain that requires an active internet connection is still fundamentally unreliable, even in 2015.
Edit: Used to work on personal projects in a previous job that included long commutes. For me it is often the best time of the day for programming: Nobody to interrupt, few distractions, a very specific start time and stop time.
Honestly this would be like saying "GitHub doesn't accept git pushes anymore, all changes to files have to be made through the Web UI".
http://www.paulgraham.com/distraction.html
Myself, I'd be glad to be disconnected. But it is hard in our world right now. Still, I try to do as much without access to internet as I could.
We in Codeanywhere are web devs, and we made Codeanywhere for us :)
Always-connected working is widespread enough that you can sell the product you sell, but pretending like it's a well-established hard requirement everyone easily meets is bullshit.
I don't understand the "must be on the Internet" complaint. As someone else said, other online resources are large parts of developer workflows - it has been a long time since I have coded without an Internet connection (perhaps a few times a year on an airplane, but I am happy enough writing (I am also an author) or reading on planes).
Thanks again!
Codeanywhere is an Editor just like Sublime, Atom and so on. It's just available everywhere and just how you configured an left it.
There's one thing I really hate about coding and that is getting my environment up and synced.
This is why I would consider using CodeAnywhere.
Throw your IDE into Electron and make offline counterparts to the online stuff and it would be a nice package.
But writing a config sync plugin for Atom would be enough for many, I guess
Keep the IDE's config between reinstalls/new machines? Some IDEs even have a specific option to export the config and import it into another instance.
One of the key objectives that we are exploring with Eclipse Che is the idea of workspace portability. The workspace itself is composed of two things: 1. The projects (and their source bindings), and: 2. Their environments, which are the stack of tools and runtimes that you need to perform work on the code such as refactoring, debugging, compiling.
We have created an abstraction of the worksapce to the environment that it is bound to. And then this entire definition is exportable and movable between Che instances or to a cloud that is supporting Che, such as what Codenvy will run.
Because the workspace definition defines its machines in the workspace object, then we can recreate the exact machine you need to do the same work on another node.
We use docker to implement this behavior.
We are not fully done with all of this work, but we have a lot of prototypes that prove this can do well.
There are some challenges - if you want to "save" your workspace, do we snapshot the machines every time, or only sometime? Do we force a remote commit & push? it'll be up to the user. But once all of the commits are done, then we have to push the images into a shared registry and ensure that everything is remotely accessible.
Once all of this is done then any other machine can reproduce an identical workspace.
If the primary idea is to work remotely, ssh+vim+your toolchain should be just as serviceable.
This is not a new version of the existing Eclipse (or Intellij). It's not a desktop app at all, it's a web server that starts and then your browser opens the EclipseCHE "web app." The IDE is merely a web interface - everything is happening on the CHE server (which would make the most sense if you install it on a separate machine altogether).
As far as the IDE, it's actually kinda amazing for a web app. If the browser chrome was missing it would seem like a desktop app (except the menus are in the wrong place for OSX). The intellisense doesn't seem to be working yet as far as I can tell. Maybe this is just PHP, though? It shows valid PHP code highlighted in red as if it were an error (edit - restart seems to have fixed this). I wish so badly that one of the dark themes for Eclipse looked this good, though. I've tried for days to get a decent dark Eclipse theme going - they all suck.
It seems that it may be creating a docker container for your project. You don't open local files on your machine (there is actually an 'upload' function to add a file to your project though). The files don't exist on your normal filesystem - they exist on the server, perhaps in a container, or just some internal folder structure that the server controls..? It seems to want to handle it all magically, which means I can't easily try it out on one of my existing apps. This is not really normal for my PHP workflow, but perhaps it would be perfect for those who have their app already in docker containers?
I can't get an application to run at this point. I have docker installed, but it just hangs with the message "Your request is queued waiting for a node to become available..."
Overall, it looks extremely interesting - especially for a team environment where everything is containerized. Just point a new team member at a URL - and the IDE and server environment is 100% set up, ready for them to start coding, debugging and running the app. There would be essentially zero setup time for working on your app.
If you are playing with it - try out 4.0 branch, it has the new designs & architecture which makes it near localhost.
What we are doing behind the scenes is binding your workspace into an environment which is powered by machines. You can either have a localhost machine or a docker machine. Right now each workspace can only be bound to a single machine environment, but in a couple months we'll release multi machine bindings, so that you could launch a docker compose, for example, as a way to bind your workspace.
The binding of your workspace happens behind the scenes. When you boot or shutdown the workspace, we take care of managing the machines. If you are using docker, then those machines are running out of process. If on linux we use docker natively. We use docker machine on mac or windows.
Once the machines are booted, we bind all of your projects into the workspace, which are mounted into the machines. Inside of the workspace machine, we launch another version of che. Based upon the programming language you choose, we are running intellisense services inside of the machines. For java, we actually run the native JDT code.
We then put RESTful wrappers around this, which enables the browser to have full intellisense capability. We have more work to do in integrating the JDT code with our restful wrappers and the UI, but it works well.
We now support refactoring, a lot of content suggestions, find usages, and so forth.
You can snapshot your workspace and use that image to load it again.
Your files are dual mounted between Che the workspace manager and your workspace environment. If you edit files in one, they are updated in the other. so you can ssh into your workspace or not. We provide a terminal into the workspace as well.
When you execute a command, we translate that into a process and then docker exec it inot a machine as well.
I found the dark themes to look great with certain, staged screenshots. But then when you use it, the scrollbars are blaring white. Or the bar that shows your code blocks can't be styled (controlled by the OS). So you wind up with a mostly dark theme that has 2 or 3 blaring, ugly, mismatched elements that defeat the purpose.
Styling the editor window is something I've spend days tediously trying to tweak a nice pastel color pallet (that pretty much every app with a dark theme uses). But all the included ones are bright neon colors or just radically weird color choices. I've been able to get my code window 95% the way I'd want, but then all of the other windows like the explorer or the console don't match! The settings are all over the place and sometimes take a restart of Eclipse to if you got the right setting or not.
Basically I just gave up with the dark theme because it seems there's no way to get it consistent.
Besides that, it looks very promising. The feature set is fairly humble, which is imo a good thing.
The best thing the devs could do now (they may have already did this) is to thoroughly document the server side API.
Most of the extensions I'd be interested in writing wouldn't really fit into the standard IDE paradigm, and that's what I think could be really cool about this. The ability to code an env (eg. in a seperate .html file) while I code is a very appealing prospect.
A couple of things: 1. If you checkout che. 2. Go into assembly-sdk 3. mvn clean install
If you do this directory, you just download the binaries - will take only a couple minutes.
You will want to checkout 4.0 branch, which has all of the new capabilities and design into it. We have swagger APIs that you can access for all of the RESTful stuff. It should be at http://localhost:8080/im-api-docs-ui/. I am going to verify with the engineers and get back to you if the URL has changed for Che 4.
Che is focused on workspace portability and interoperability. As a result, there is a hard abstraction between the worksapce and the environments that power it. the workspace definition includes the definitions of the environments. This makes it possible to move a workspace that is bound to a stack of docker containers containing debugging, runtime, and compilation tools from one node to another node, and then the 2nd node can recreate the entire workspace.
Then within this workspace and the machines that are powering it, to embed industry native tools like JDT into it, and then place RESTful wrappers around it so that a browser or other tool may gain access to it.
The C9 goal is to build a cloud IDE and provide the best overall experience for developers. And Che was primarily a focus around workspace movement and interoperability.
https://github.com/codenvy/che/commit/db5b0bc2a1e2b4f3d7a7a2...
We started on it about 18 months ago. It takes a long time to get through the branding and legal process.
We believe that the 4.0 release in a couple months will have finally resolved the branding items and the remaining Codenvy elements will have been removed.
Java tends to be "Star Trek Borg like" [1] in sense it's often impossible or at least cumbersome to use libraries written in it in non-JVM languages. When can we write a .so/.dylib/.dll in Java? There are of course some (cumbersome) ways around this, but it tends to involve RPC of some sort and multiple processes.
Not exactly technical reason, but a matter of opinion: The shadow of Oracle Corp. Makes me feel uneasy using Java.
[1]: Borg is an alien race in Star Trek that considered other species inferior, assimilated their technology and turned them into more Borgs.
Curious there are no replies on any of the points, given several people seem to agree and disagree with them.
For what it is worth, I've been working with Java more or less since 1.1 days. Lately it's been less, while working with very low level systems.
Surely the first point has prevented many memory intensive projects from using idiomatic Java, and opted on serialization to byte[], memory mapped files or Unsafe tricks. Forced to go objects of arrays instead of idiomatic arrays of objects. You can make it fast and consume little memory, but not without some considerable pain.
The second point has prevented me from choosing Java as a technology quite a few times. Sometimes you just need to provide a shared object (dynamically linked library) that can be loaded with all those languages with C-linkage.
Third point is of course a matter of opinion. While OpenJDK is great and all, Oracle has behaved like a cage rattling gorilla in the past. Who knows what they'll still be up to, if they get in a tough enough situation? They sure have a lot of ammo, and I don't want me or the organization(s) I represent to suffer any collateral damage.
That sure didn't stop Go from gaining popularity.
It is clumsy at some stuff, and doesn't do some kinds of abstraction, so you might have to repeat yourself some, but comparing it to Java? That's not something I've seen anyone who's worked in both do, I don't think.
I just hope the backend is thoroughly decoupled from the UI, and that appears to be the case from first glance. I can't wait to try to pair this with neovim.
edit: the more I look at this the less this seems to be the focus of the project. That makes me a little sad.
The client side can interact with any server side component over REST or web sockets.
is there a particular use case that you'd like some elaboration on?
Is this an update of the "traditional" Eclipse IDE, or a new browser based IDE? What does a "workspace server" mean?
This is exactly what I didn't want. Please tell me that this "next generation" stuff is just inaccurate hype, and that this is really just some minor Eclipse offshoot.
The existing Eclipse IDE will continue for a long time yet - Eclipse Neon will be released in six months time with full Java 9 support, for example.
In general, a cloud IDE has some nice promises: Initial setup is trivial; More efficient building and testing due to resource sharing in the cloud; Live collaboration is simpler. However, so far I'm underwhelmed by everything available.
Writing some huge web/analytic application that needs a huge cluster? Throw in a few docker nodes with applications that have APIs that are needed for running the project.
Good luck starting that on your laptop.
For me, I want to ultimately have my laptop be downgraded to a chromebook or something small, cheap, and with a long battery life. To do that, tools like this really fill a nice area.
Something I've been looking for.
From source management, to email servers, to a hastebin for sending errors between my team. Nothing touches a public server if I have it my way.
It' partially a control thing, and also a security thing for me. I want to make sure that I'm never held a 'ransom'.
Also the fetish for centralized control and tool standardization.
Just imagine: you may soon be developing in a SAP-based IDE, chosen by feature checklist!
[0] https://github.com/codenvy/che-core/blob/master/platform-api...
Maybe I could have the same thing with VMs or containers (disclaimer: I've never even set up docker or vagrant), but I still would like to have that in the cloud where somebody else takes care of patching stuff, backing up data, etc, and I can share it with a URL if I want to, instead of with a multi-GB file.
I'm too lazy to care about my infrastructure anymore, and I'm happy I can pay other people to do it for me.
The cloud IDE takes this concept even further by only ever having a single source of truth for the dev environment, but this comes at the cost of offline access and choice of editors, which is a compromise I'm not willing to make yet.
I've tried to use Vim+ctags over ssh for this purpose but am not really satisfied with the results.
My nvim init.vim is here:
https://github.com/sielickin/dotfiles_nvim/blob/master/.conf...
Make sure you call :UpdateRemotePlugins
Anyways, autocompletion and jump-to-definition weren't all I was missing. Smart syntax highlighting that could deemphasize macro blocks (eg. #ifdef) that would evaluate to false for the project is some thing could not find a plugin for.
Source: Am PHP Developer.
Anybody done it yet?
Already at that time I thought - why leave such a nice idea on the street? Others will pick it up ...
https://karussell.wordpress.com/2008/06/22/real-time-editing...
At the text-editor level, SubEthaEdit has it, and the same library is used by Coda (and thus they are compatible)
I vaguely remember there as a company providing plugins for multiple IDE's to accomplish some kind of pair programming - ah i found it: https://floobits.com
But things have gotten to boiling point. It can't handle newer technologies, like LESS, there is no good extensions for anything relatively new.
I think Atom (and my preferred VS Code) is the future of IDEs, there is a lot of people behind these working on new features and extensions for these. And having HTML rendering engine behind the IDE does make it more approachable for hacks, simple and useful ones.
Although the community version of IntelliJ at PHPStorm's core is open-sourced, PHPStorm itself is not. Regardless, the productivity gain it provides is WELL worth the cost and inconvenience.
(1) the folders break all the time. And refreshing the folder list doesn't fix it. The hierarchy gets broken, and I regretfully can't screenshot it.
(2) where is the junit runner? One of the reasons I think IDEs are pretty great is that I can run single junits, and I don't see this working in any capacity.
(3) Why do I see menus for svn / git? What about hg? I prefer to use command line for source control, can I hide these?
(4) Is the timeout for the build configurable? I have a build that takes several minutes due to a large number of tests, and it is unable to build due to a timeout
(5) the auto complete seems very broken; maybe it is my project (using maven). It appears to import the dependencies just fine, but beyond that it produces a lot of errors.
(6) I thought this would have the eclipse refactor support, but I do not see it.
Would you do a couple things: 1. Check out the 4.0 branch. 2. Go into assembly-sdk 3. mvn clean instal.
Now run the next generation version. We are a few months away from having it fully stabilized, but many of the experiences you are seeking are in this branch.
We are running the JDT underneath inside of your workspace machine, and we have refactoring, debugging, find usages, etc in there.
As much as I hate being a buzz kill, I am wishing you guys my best. This is pretty awesome, and I'm looking forward to more progress.
I'll start following trunk once I get time to set it up. I'm in the camp that can't use docker since I have to mount eclipse to a sub directory of a very large repository.
Ubuntu 15.04, Docker 1.9.1
But the intellisense is pretty seamless. We use Eclipse JDT services and have a lot of intellij-like experiences. so the experience is fairly similar.
In the screenshots I'm looking at, there are dropdowns inside panels inside tabs inside more panels. There are five tab bars. There are completely unnecessary icons for "cut", "copy", and "paste". There's a "Subversion" menu and a "Git" menu at the same time. There's... a user switcher? I don't even know what that means. The actual code takes up like 40% of the screen.
Is this actually what programmers want from an IDE, or just what they have come to expect?
I don't want a tab or button for everything. I want to primarily write text (i.e. code) but I also want it to be intelligent about what I'm writing - i.e. I want the autocomplete, the parameter hinting, the type checking (i.e. can't use the result of a void method, or can't do string ops on an array etc). I also want the option to have refactor helpers (moving methods, renaming methods, changing argument order, etc).
I've found IDEA (and before that PhpStorm, but it supports less plugins) are generally able to meet that need but you have to be careful about which plugins you install. I want Lua support, that doesn't mean I want a Lua console button in all projects.
I daily write in Xcode and that is very slimmed-down. In fact, Visual Studio developers typically hate it on first using it because there is only editors on the screen as opposed to property panes both sides of the editor!
And I would say that it is ONLY C++ is truly a benefit to QtCreator!! No use trying to be everything to everyone. Plus, C++ is the best language for everything isn't it? (I jest, I jest)
Unfortunately the only IDE's which seem to support languages I use and work on OS X are java based, and it seems the best option is IDEA or one of it's siblings.
Also, Eclipse tends to try to do everything in their IDE: Transition an issue, commit, execute a command-line program, browse the database, etc. It's a very different spirit from, say, SublimeText where each program is dedicated to one thing well. It has a lot of impact on the UI, hence the critics "Code is 40% of my screen". I personally prefer IDEA now because it comes with thin shims.
Btw, the HN rules say "No negativity". Just a reminder to be considerate for the Eclipse team.
Isn't that the whole point of an IDE? I mean, an Integrated Development Environment, by definition, should have all the tools integrated, as opposed to a text editor which is only one tool in an unintegrated development environment.
I prefer Emacs myself, but if I wanted an IDE, I'd probably go for the one that can do everything I want to do.
I have worked in IT services companies. They wrap almost a full OS into Eclipse (or WSAD). They have people who don't have a clue about programming [1], they need to onboard them and they do little to upgrade their knowledge. I used to wonder how architects learnt about Git and Maven, until the day I decided not to use IDE buttons, tried them on the command line and discovered "--help". It's all self-documented, output is all logged, I can debug compilation errors alone!
[1] Recruitment and HR is a cost center for consultancies. At one point they just took graduates from Chemistry major with a mild interest in Excel. Needless to say those who stayed became PMs. I've seen millions of euros from government, banks and insurances thrown into multiplying employees, rather than improving employees.
It's more like a tiling window manager
You can choose how many of those panels you have and which tabs are in each panel and which buttons you have in your toolbars.
> The actual code takes up like 40% of the screen.
considering that many projects still have guidelines regarding line-length (something around 80-120 characters) there's only so much horizontal space you can utilize. I can easily fit two source files side by side on my monitor and still have room for additional panels.
> Is this actually what programmers want from an IDE, or just what they have come to expect?
The more you can have on the screen at the same time the fewer permutations of arrangements you need for different tasks.
If we are to extend the desktop analogy, it's a work bench with a wall of tools hanging in front of you, every individual tool within grasping distance.
Mind you it's not just Eclipse, seem every IDE took their cue on how to do stuff from a VisualStudio from the 90's and decided it whas THE way to do it.
I still use Eclipse a lot (and Geany[0], for a lighter editor) -- the Code Indexer is the best I've ever tried. I can index the whole Linux Kernel in there, and it's a real blessing.
I don't understand how you can be stuck with that. You can close the panel, move it somewhere else or minimize it.
Eclipse does not force any particular layout on you.
You can even have 4 editor views side by side and only partition one of the 4 vertically to have the console at 1/4th width.
You don't, hide it via CSS[1]. Entire Eclipse UI is customizable. Install CSS Spy[2] to experiment live before committing changes.
My Eclipse setup actually looks like VIM with split buffers, there is nary a wasted pixel. To get to that point that though (e.g. hiding right side gutters and always-on scrollbars) is a bit more involved, need to take custom plugin route for that.
[1] http://stackoverflow.com/a/17027501/185840 [2] http://marketplace.eclipse.org/content/eclipse-4-tools-css-s...
disclaimer: I was responsible for the shell user interface of Visual Studio 2005 and 2008, but haven't worked for Microsoft for more than eight years or used any version of Visual Studio later than 2008. That said, I'm still rather anti-Eclipse.
I've since found out about Emacs and the contrast is striking; Emacs being a shining example of simplicity and extreme power while Eclipse is literally bloated boilerplate central in comparison.
This pretty much prevents me from taking anything coming out of the Eclipse Foundation seriously.
Yes, the purple and orange lettering on a black background is especially painful.
I'm not sure what to think about a "cloud IDE" yet. It strikes me as the sort of thing which, if it doesn't work perfectly, will break in mysterious ways. When such things break, it's usually necessary to look behind the pretty graphical environment at vast numbers of text files, environment variables, and whatever other state the thing has.
And things go both ways: Some of us do have multiple 30"+ monitors and appreciate UIs that manage to utilize all that space.
Remember that responsive design doesn't just mean scaling down to tiny mobile devices, it also means scaling up to large screens.
Those were concept drawings. In the finalized version, all of the panels & tabs are removable. There is a "+" in the tool bar that will let you add / remove any button, menu, panel entry. This is in the 4.0 branch that we are working on.
How is the UI latency if one opens a Java file with 1 KLOC or a 2MB XML?
Re performance I've seen demos of Eclipse Orion (another web based IDE experiment) where they had 100kloc JavaScript files and still be pretty performant.