Eclipse Che

Red Hat & Eclipse Che

Red Hat & Eclipse Che

plmuir
By Pete Muir

During the DevNation General Session today we talked about how we need to rethink some of the basic concepts of software development. We think it’s essential to make developers more effective and get started quickly. Rethinking what and how developers write and debug their code (what we normally call the “IDE”) is central to that.

Today, during the DevNation keynote, Red Hat announced that it is making a strategic investment in Eclipse Che. In this blog post I’ll talk about why, and also where we are starting to contribute.

One of the things that has struck me, that I realized as I’ve worked with Che over the last nine months, is that I had forgotten what the acronym “IDE” stands for — Integrated Development Environment. As I spent more time with Che, I realized that most IDEs and coding tools I used to date have focused heavily on source code (editing, compiling, building, visualizing) and have ignored the environment part — you nearly always have to follow a README to get the application running.

Che has fundamentally rethought the whole development experience, and put source code and environments on an equal level. At Red Hat we feel that Eclipse Che is fundamentally changing the very approach many of us take towards developing software. We think that the notion of a universal workspace is incredibly liberating for developers.

Continue reading “Red Hat & Eclipse Che”

Share

A common interface for building developer tools

gorkeme
By Gorkem Ercan

“There is already a command line for it, why can’t my favorite editor support this language?” As a developer, you’re probably familiar with this sentiment, and in reality there has never been a better time to be a software developer.

Developers have access to a growing list of languages, frameworks, libraries, and technologies that can help them solve the problems they are tasked to tackle. However, the abundance of choices often hinders the ability of Integrated Development Environments (IDEs) and code editors to support such an abundance of choice. As a result,  developers often choose to use multiple IDEs and editors for building their solutions, in order to get access to best IDE support.

IDEs are frequently architected to have direct access to the tools related to the technology for which they were designed — for programming languages this often means that IDE has access to parsers, compilers and an in memory presentation of the developed code usually in the form of an Abstract Syntax Tree (AST). This approach also means that IDE developers need to create and maintain these tools.

As an example, Eclipse Java Development Tools (JDT) project provides a compiler for Java and a Java editor which in turn uses the AST generated to implement features like code assist, outlines, refactoring, etc.

Another approach is to define an API that the IDE will invoke to provide language features. In this architecture, the IDE has no real knowledge of the programming language and instead relies on the implementations of the interface.

We think this approach has a couple of advantages: first, it allows the interfaces to be implemented by the communities that create the technology, and so know it best; second, it frees up IDE developers for what they know best — we think this results in better IDEs and editors.

Unfortunately, we do not get the full benefits of the approach because there are as many of such interfaces defined as there are editors and IDEs.

Continue reading “A common interface for building developer tools”

Share