Bling and the future of IDEs
At EclipseCon 2013, L33t Labs revealed a port of SWT running on OpenGL, and used it to demonstrate an Eclipse instance with graphical effects animated by the OpenGL hardware.
The presentation was one of the most highly praised at the time, and recently, a video on YouTube has been released which demonstrates the ability to render the IDE with the affects applied:
SWT is Eclipse's widget rendering library, which can have implementations provided for a variety of different windowing systems whilst taking advantage of native rendering and compositing engines. It was created at a time when the Java-based graphics suffered poor performance and did not look like the native operating system's controls. Since then, the JavaVM and Java UI has increased in performance, and new initiatives such as Java FX have allowed Java to catch up with SWT.
Although the OpenGL example showed a lot of eye candy (including effects which would never likely be used in a real environment) there has been a shift in expectations over the last half decade. Since the release of the iPhone in 2007, the mobile industry as a whole has been focussed on not only eye candy but specifically on targeted user interface improvements that enable the user's attention to be drawn to specific locations of the code.
Many IDEs share the heritage of those created in the previous millennium; Eclipse's “Java Browsing” perspective is based on Visual Age for Java's user interface (which itself is based on Visual Age for Smalltalk, released in the 1980s). Little has changed with the UX of development environments for any of the major Java development tools over the last decade, other than minor tweaks in interface colours or underlying rendering technology changes. (For more on the history of Eclipse, see InfoQ's interview with Mike Milinkovich on the past, present and future of Eclipse .)
Perhaps the biggest change of development environments over the last few years has been Apple's Xcode, which introduced a new way of working with Git repositories (visualising the change history as a TimeMachine-esque effect) and the paths which could lead to a static leak:
These days, the focus of the IDE has swung to the web, with Eclipse Orion aiming to be a web-based editor. In the age of always on-line Git repositories, having an editor which only works in a browser would be an ideal way to work with code remotely. Some of this requires that the UX be reconsidered to fit in with the way in which browsers work, but provides an experimental playground for trying out new techniques and mechanisms.
Whether OpenGL as a rendering platform for an IDE remains to be seen, but the next decade is likely to bring about significant UX changes in the way that code is edited, debugged and built.
Missing the point
The problem with Eclipse is not that it doesn't animate the panes going in and out the sidebar, but that it freezes while trying to download a DTD file when the proxy is not properly configured.
And, the move to 'The Cloud' may work for dynamic language programmers, since they are already used to crippled tools, but it simply can't scale to the degree of complexity we ('enterprisey' developers) need. They fu**ed up Eclipse with this Juno crap, and waste resources in these pointless endeavours. I think the time of relearn my keyboard shortcuts is really coming this time.
CloudSharper is another Web IDE that looks to be feature rich by
Will always need desktop IDE, why not make it great
Having an IDE on the desktop will always be the best solution for many environments so why not make it great. I look at other content provider tools, especially those used by designers, the Blender 3D modelling tool as an example, and they're beautiful. To see the IDE in that mode as the l33t labs guys have done with the guts of Eclipse driving it gave me a lot of hope that we can make Eclipse look great and a pleasure to use.
But I have to agree with Ronald as well, you can make the IDE look great but if the workflows are horrible, or worse - don't work, that rips away the "pleasure to use" part and just makes users angry.
So we really need both and there's lots of work ahead. I just fear that the focus of the Eclipse community is being pushed towards Orion and that takes away focus on making the Eclipse the desktop IDE great. And seeing the passion of Eclipse users, they deserve a great IDE.
Any IDE should worry about workflows
I think some focus on Orion is a good thing for Eclipse as well. The workflows are being thought through, and lean and clean a methodology toward providing what you need when you need it. There's nothing stopping doing the same thing to Eclipse to make it great. IDEs should not just have features for the sake of having them. Workflows need to be part of the picture.
Re: Any IDE should worry about workflows
And if the user community I support wants that, I'll be there to help support it, just as I do users who don't want to use any IDE and are happy with vi and command-line tools.
But my worry is that in the desktop IDE space, Eclipse has strong competition. If my users start see the alternatives as more desirable, I'll need to follow them there. And that would be a sad day. But it doesn't need to happen that way and I will keep fighting to keep the Eclipse desktop IDE relevant.
Random stuff about Eclipse
IDE in the web
I just don't buy this whole "IDE-in-the-cloud" thing yet.
Robustness, that's all we need from Eclipse
Eclipse has been losing in robustness and performance at each release.
Juno is really a crap.
That's what I need. Robustness and performance.
Fancy effects are good for videogamers, not for Enterprise developers.
Re: IDE in the web by
IP protection is an issue but with CIA singing a deal to use the Amazon cloud the trend is clearly towards cloud for almost everything. See fcw.com/articles/2013/03/18/amazon-cia-cloud.aspx.
I think the key question is whether a web IDE can provide a similar experience to a full featured desktop IDE. Only time will tell.
As developers we are very finicky and can get easily frustrated if the IDE is not working for us.
Re: IDE in the web
Storing sensitive data and intellectual property the existence of your company depends on at cloud storage providers where any secret service might (and actually does, see PRISM) access your data in uncontrollable ways seems like a total no-go to me, not even talking of security problems like hacking or leaking. Maybe locally hosted "cloud" IDEs might be safe enough.
Re: IDE in the web
Our community has over 65K users and we learned a lot about the value of cloud relative to desktop IDEs. The pain that we solve is around administration. Developers surveyed on LinkedIn by Electric Cloud indicated that they spend 13 hours / week administering their desktop environment. This is about 2/3 of their time coding, and 1/3 dealing with administration, maintenance, starvation, merge, and human costs. If you happen to be using Eclipse, this number tends to even be higher.
The value of a cloud IDE is that is an instantly provisioned environment. Our IDE is targeted for use by teams working on complex applications with multiple dependencies. We do have intellisense capabilities, but not the degree of an IntelliJ or Eclipse. But the cloud IDE contains a complete workspace: IDE, project, build system, and runtime for debugging. All of the components are automatically configured by project type or PAAS deployment target. We do heavy lifting to reduce failure rates.
The workspaces themselves are team oriented, so they can be used in a Webex style, a google docs style, or replicated like a GitHub clone.
The programmatic nature of an IDE is a big benefit for ISVs who are seeking ways to simplify the evaluation workflow for developers of an SDK or API. It is possible to launch a cloud IDE that is integrated to an SDK or API, taking the time to Hello World down significantly. Reducing the error rate for evaluation or support scenarios means a developer is more likely to adopt a technology.
As a result of this, we see three types of users adopting a cloud IDE. Those that kick the tires, and compare it against their desktop equivalent. It's more of an experiment. The primary users who are using it entirely as their primary workbench. And a new class of users that I call Auxiliary. These users have a primary workbench that is another tool, but use a cloud IDE for commutes, on vacation, with a mobile device (say to check an issue), hackathons for brief periods, or for onboarding to a new project, or those pinned to a chromebook. It's all of the situations where someone just wants to hack briefly, and not deal with the setup or configuration.
Other commenters are stating a concern about always-on connectivity. Interestingly, on our feedback page where we have 1000s of votes, offline access isn't in the top 5 requested features. It is a concern for some people, but for the most part, those with chromebooks are always connected. But even so, it will be possible for companies like us to offer an offline mode by syncing the code repository to the local machine. There are ways to enable this activity.
Thanks for the great conversation.
Re: IDE in the web
But seriously. I'd live to hear from a cloud IDE user. They're the ones who matter.
One can only hope
Yes, let's fundamentally rethink IDEs, not just a simple web-based or not discourse.
How to Think Like a Pioneer
Re: One can only hope by
Essentially type providers allow you to take external metadata and expose that as types in your language -- as you write code.
For example lets say you want to access a Hadoop dataset in typed way. Here is what you can do:
type HadoopData = HiveTypeProvider< ... connection info ...>
let hive = HadoopData.GetDataContext()
let avgAge =
|> Seq.averageBy (fun b -> float b.age)
The code above is calculating the average "age" across the "bankmarketing" dataset. The actual calculation runs in Hadoop; here we are just expressing the logic.
The key is that all datasets (including "bankmarketing") and all their fields are available as F# types with full support for code completion (intellisense in MS world) -- just by referencing the type provider with connection info.
There is a behind-the-scenes interaction between the type provider the IDE and the compiler that makes it all seamless.
You can actually tryout this code here www.tryfsharp.org/Learn/data-science#hadoop .
There many type providers available already and new ones are being written all the time. It is a very successful innovation.
Brandon Holt, Preston Briggs, Luis Ceze, Mark Oskin May 21, 2015
Kai Kreuzer, Olaf Weinmann May 21, 2015