Common Eclipse support for language IDEs
Upcoming Eclipse Events on Eclipse Events ·
Common Eclipse support for language IDEs Position Paper for Eclipse Languages Symposium John Duimovich October 21, 2005 Position I am interested in making it simpler to create new programmming language IDEs for the Eclipse platform. I am motivated by my work on a Smalltalk IDE for Eclipse in which I found I was writing too much code for the functionality I was getting in return. I found that was that much of the code ends up being very similiar to code found in JDT and CDT. In fact, it has become a common joke that the way to get a new IDE for eclipse, is to take code from JDT and replace the “J” with your language letter in the class name (I used ST). I have seen many initial ports of new languages done this way and as a quick and dirty way to get started it’s a pretty good way to go, especially if you borrow ideas (and code) from a well architected piece of code like JDT. Of course, the drawback to this technique is that you “bake in” the bugs you copied from the original code and you don’t get the fixes as they are made in the original. You also miss new innovations as they appear in JDT and the underlying platform. Given that many of these components end up being quite similiar I feel it should be possible to create generic components for creating language IDEs, possibly starting from existing components from the existing language IDEs and generalizing them to allow re-use in other contexts. Clearly over time as you re-use components from one language in another, you will create common components as the problem accross many languages becomes better understood.
Common Eclipse support for language IDEs Position Paper for Eclipse Languages Symposium John Duimovich October 21, 2005 Position I am interested in making it simpler to create new programmming language IDEs for the Eclipse platform. I am motivated by my work on a Smalltalk IDE for Eclipse in which I found I was writing too much code for the functionality I was getting in return. I found that was that much of the code ends up being very similiar to code found in JDT and CDT. In fact, it has become a common joke that the way to get a new IDE for eclipse, is to take code from JDT and replace the “J” with your language letter in the class name (I used ST). I have seen many initial ports of new languages done this way and as a quick and dirty way to get started it’s a pretty good way to go, especially if you borrow ideas (and code) from a well architected piece of code like JDT. Of course, the drawback to this technique is that you “bake in” the bugs you copied from the original code and you don’t get the fixes as they are made in the original. You also miss new innovations as they appear in JDT and the underlying platform. Given that many of these components end up being quite similiar I feel it should be possible to create generic components for creating language IDEs, possibly starting from existing components from the existing language IDEs and generalizing them to allow re-use in other contexts. Clearly over time as you re-use components from one language in another, you will create common components as the problem accross many languages becomes better understood.