Today we're chatting with Werner Schuster about his Eclipse plug-in Eclipse Shell. Werner is giving a talk on his work at eclipseCON 2007, March 5th-8th in Santa Clara, California. I was able to get a few words with Werner about Eclipse Shell and Eclipse Plug-in development before he headed off to the conference.
Screencast: Beanshell editing
What does all this mean? A Javascript interpreter inside an IDE? A plug-in debugger? Let's take a step back and survey the landscape before returning to these questions.
Eclipse and software development
While we've had IDEs for a while, even ones you can extend, nothing has caught on like the zero-cost Eclipse "open development platform" with its system of plug-ins and rich-client applications.
"Eclipse is the new EMACS" is something we've been hearing lately. And there's a striking similarity. Both are useful programming tools right out of the box, intended to be widely extended. Out of the box, Eclipse has an extensive set of Java development tools complete with web browser. With plug-ins you can not only get development tools for other languages but email and ssh clients, tetris and sudoku diversions, and stock quotes. I haven't yet found an equivalent of M-x doctor but I'm sure it's out there somewhere or soon coming.
Eclipse may be the new EMACS, but it's headed toward a higher goal: becoming the old Smalltalk. A lot of the people involved with Eclipse, such as Erich Gamma, came from a Smalltalk background. Eclipse itself grew out of Visual Age for Java. If you compare the interfaces, you see similarities, like the Smalltalk class browser and the Eclipse Java browsing perspective. But where Smalltalk historically has combined the language and the development environment, that's not the case with Java and Eclipse (note the origin of the name "Eclipse"), where Sun first brought us the language and then IBM the environment. The Java language is not Smalltalk, and the Eclipse environment inherits the limitations. "You can fiddle with the bytecodes for a class," says Werner, "but you can't change the class hierarchy at runtime." Java is also something that is not generally interpreted, whereas Smalltalk has the workspace.
Smalltalk workspace
One of the nice things about the Smalltalk environment is that you can change the development environment while you're using it. This is a little mind-blowing, so let's focus on one aspect, the workspace. The workspace is a Smalltalk shell window, or interpreter window. You enter code, evaluate it, see the results.
An interpreter is nice to have, even for a compiled language. It lets you quickly experiment with language features without the overhead of creating a file and building it. What makes the workspace more powerful than a command-line interpreter is that it's running within the same virtual machine that your deployed code is running, giving you access to the code and data you're already working with. It's a little like the difference between the artificial practice situations in a foreign language classroom compared with the immersion experience of being in the country where that language is spoken; it's the power of the language plus the environment where the language is really needed and used.
That's what Eclipse Shell is, the Smalltalk Workspace for Eclipse.
Interacting with Eclipse internals
Screencast: Prototyping
You can leverage the interactivity for prototyping. I know when I was developing Swing applications, compiling and running soon got very old for activities like tweaking layouts, and I started to long for the interactivity of HTML. Other people had the same idea that occurred to me at that point, and invented a slew of UIMLs (User Interface Markup Languages) for AWT/Swing. To help me figure out layout issues, I spent time writing an object inspector that walked the Component hierarchy and showed me all the settings, a tool which had to be compiled and built into the original application. An alternative technique to both of these is an interactive interpreter that allows you to inspect and tweak the layout at runtime without recompiling. When developing Eclipse plug-ins, which are based on SWT, Eclipse's own GUI widget toolkit, you have similar issues. Something like Eclipse Shell can be a welcome change to launching a new copy of Eclipse each time you want to tweak that great object heap walker GUI you're writing.
Guerrilla debugging
Prototyping and debugging are sometimes very similar. Russ Olsen describes the technique of using BeanShell to debug Java programs live in Guerrilla Debugging for Java. He talks about debugging a Java web application by creating a servlet wrapper for one of the scripting languages, allowing you to use something like JRuby to poke at the state of your web application. If you're developing Eclipse Plug-ins, the equivalent approach is Eclipse Shell.
"This is the way I most often use Eclipse Shell myself," says Werner. "When I'm running a plug-in and something doesn't look right, I can fire up Eclipse Shell and examine the live data."
Conclusion: towards a more Smalltalkish Eclipse
The Eclipse Shell is a useful utility and finds its place in the software development toolkit universe alongside Smalltalk Workspace and the Emacs-Lisp interpreter. It definitely finds its best use by Eclipse plug-in developers, but as Eclipse matures I think it also has room to grow as an Eclipse task scripting tool. And even if you're not a Java programmer let alone an Eclipse user, I hope you've gotten an idea or two about the advantages of interactivity in the programmer's development environment.
Werner Schuster (murphee) is a programmer with a focus on Java, Eclipse, and dynamic languages such as (J)Ruby and Mathematica. Among other things, he's developed Eclipse plugins since 2003, both commercially and in the OpenSource space. His blog is at http://jroller.com/page/murphee.
1 comment:
See also the SchemeScript plugin for Scheme. It can also be used to script Eclipse and features a similar level of integration between the editor and the shell. Almost like Emacs.
http://schemeway.sf.net/schemescript.html
Post a Comment