Day 2: Scripting Eclipse
The second session on Tuesday was the panel on Scripting Eclipse . Ken Dyck, from AMI Semiconductor was the moderator. Here's a rough transcript of the panel, as fast as I could type.
Ken (standing): Who are you and what is your interest in scripting?
Ed Warnicke, Cisco. (left to right): We'd have a whole bunch of people who want to add little bits of functionality easily.
Bjorn Freeman-Benson, Eclipse Foundation: I'm interested in making it possible to write plug-ins in more than just Java (e.g., Python). Ward and I are working on providing more simplified DOMs that are easier to use than the whole API.
Ward Cunningham, Eclipse Foundation: I'm interested in scripting as a style of programming instead of a style of languages. You're writing the program to serve YOUR needs, not somebody else's needs so there's a different set of trade offs. We get caught up in serving the needs of our customers that we forget to meet our own needs.
Ken: What is the purpose of scripting?
Ward: We care about being more overt in your own processes. When you know them well enough you can write them down and automate them then you can improve them.
Bjorn: What are people in the audience interested in using scripting for?
Audience member: Macro recording and replaying. (many agreed).
Ed: You could roll out a set of cheat sheets, but there are impediments.
Audience: We want to enable developers to set up their dev environment, checking out some things, filling out fields automatically.
Mark: That's important, we're using Ant for that now but it could be easier.
Audience: We want tools to make it easier to program in scripting language.
Audience2: We want dynamic validation of forms on the client using logic coming down from the server.
Audience3: We'd like to have the DOMs open up to a variety of languages.
Ward: The Eclipse-shell project demonstrated the DOMs would work with different language.
Mark: We have more of a 'try things out' attitude rather than design up front. I've used some wrappers in Jython. One obstacle we found, when you get into SWT, there are GUI thread problems. It would be nice to solve that in a generic way.
Bjorn (to Mark): What makes Jython interesting to you?
Mark: Our debugger has a command line mode like GDB. That allows you to create scripts that does all kinds of things on the device outside Eclipse. We have a Jython console that accepts commands.
Bjorn: So you're scripting the debugger not Eclipse?
Mark: Yes and now, we've been experimenting with adding other actions from the debug window. We've been playing with other things though like calling actions and key bindings inside Eclipse though.
Bjorn: I'm trying to get at what makes scripting interesting. You could write plug-ins and use hot-swap. If that were super fast would you still need scripting?
Mark: Our users are fairly savvy and used to scripting.
Bjorn: But with all these ideas of what scripting is, for YOU what does scripting mean? For me it means simplifying the APIs.
Ward: There's a theme that somehow we believe scripting is easier than regular programming.
Ed: I may have lots of programmers comfortable in language A. Calculate the retraining costs for adding little bits of functionality. That would be really expensive when you're talking about a large number of people. Limit the learning curve.
Bjorn: You want to write plug-ins in other languages, like TCL.
Ed: Yes, it's hard to find people with multi-language skills.
Audience: One big difference between scripting and regular programming of plug-ins, you have to install it into an Eclipse instance and restart but scripts tend to be more instant and flexible. For an end user to write a plug-in to do what he wants to do, it's unlikely because they have to educate themselves on the vast Eclipse framework. When I started, I spent hours and days.
Bjorn: Mine was really easy, Hello world. (laughs)
Bjorn: Sounds what you're saying is that extending Eclipse is so heavy weight it discourages people.
Audience: Yes, my first plug-in was a custom builder for CDT. I wanted to use a different tool besides Make. I had to figure how to do launchers, launch configurations, plug-ins, etc.. Scripting might be easier. The user doesn't want to learn all the infrastructure.
Ward: So if it isn't scripting, it isn't easy? Is that the definition of scripting?
Bjorn: If that's the definition, you can never win.
Ward: To be fair, there's some pretty amazing support for Java in Eclipse so it's a high hurdle to surpass.
Audience: I want to run code in the same Eclipse instance that I use to edit the code. I'm from a smalltalk background. I don't want to restart.
Ward: Yes, you want to run in your own environment.
Bjorn: What if the PDE could attach to the same VM you're currently running? OSGi to load/unload. Would that satisfy you?
Audience: Yes.
Bjorn: "Jim, make it work" (laughs)
Ward: The time from the moment you have an idea to you realize the idea in code should be really short.
Audience: I want my end users to have glorified preferences, add business logic. Java is not applicable for business analysts.
Audience2: Running in the same VM isn't the issue. If I'm building an RCP app, they might want to do something simple like add a new filter. You don't necessarily need those guys to have full JDT shipped as part of the app. If there was a scripting mechanism in place, they could say 'when this menu is selected I want this little bit of code to run'.
Bjorn: You're saying a scripting engine environment would be smaller.
Audience: Yes but also it's about setup simplicity as well.
Audience2: You often don't want to send the JDT with your application.
Ward: How many people want to script an RCP all? (lots of hands up) Wow we should write that down.
Mark: Also you don't want to build and deploy things.
Audience: We've got a rich client app, with a plug-in with a Jython console, and it works great. We can access the whole environment, direct to the APIs.
Ed: There could be packaging problems with Jython couldn't there?
Mark: No we solved that too. You get a handle on every class available in Eclipse but it's not particularly clean and simple.
Audience: For RCP apps it has to be robust and bullet proof so people can't break it.
Ed: This gets back to the service/DOM concept. if you have the full API, you can do horrible things. But if you expose service facades, you potentially could make things a lot safer.
Audience: If I'm scripting the IDE I probably want full access, but if I'm scripting an RCP app I probably don't.
Audience: Not everybody is familiar with Java. We want to let people add functionality to that. How's that get interpreted? Contribute a view by scripting without having to learn all the Eclipse extension points and whatnot. Might as well just go the full way and do java.
Ward: That's engineering, takes forethought, process, reason about the future and get it right.
Audience: May be within the same company, somebody new gets it and they have no idea about Java, maybe they know Perl.
Ed: So we have to make simple things simple to do. If you want to do something extremely complicated you have to deal with complicated APIs. For some users you'd like to be able to offer a simple way.
Ward: Programming for yourself doesn't necessarily mean you don't have users. For example web applications. You know what your server is like, what your config is like. Somebody asks for a copy, but it's written specific for your environment. Making the stuff go anywhere, work in any config, requires engineering. Scripting is popular because of the web. Non-engineers can do interesting thing. But to be an engineer is still an honorable profession. (laughs)
Audience: Anybody try running Ant in same VM? Seems like it should be possible.
Audience2: The distinction for me is if I'm scripting, I want the environment to provide a sandbox. The scripting environment should make sure I can't do anything that suddenly makes Eclipse go away (crash). If I'm writing a plug-in, I'm willing to take the risk and take the additional development time to do that.
Ward: It's how much personal responsibility you're willing to take if things go wrong.
Mark: That's our problem with Jython, you can easily crash the VM. This will be demoed later (laughs).
Audience: Another use case for scripting, is to be able to script JDT to do queries on my Java code, like find all methods that can return null.
Ward: Searching the JDT model is in the style of refactoring.
Audience: We're programmers but consumers of an RCP app are not. Language is one issue, but it's important to have a facade. They don't know what plug-ins are. They're scripting the user interaction, a dialog comes up, click here, etc.
Ed: You can potentially do more with service facades. For example embedded scripting language lives in your JVM that acts as a protective wall. For example, external tool in perl that knows how to understand your code, I want it to stick markers in the editor. Communicate back and forth.
Audience: One issue for RCP apps, do you want your users to be users or to be developers? If user then script needs to do user like things. Slam in some scripting framework and do it.
Mark: Users of course. As developers we know the internals and are tempted to use it.
Audience: Look at Excel or Word, VBA has been around for a while. It's an IDE within Excel and Word. It's really really hard. Somewhere there is data that the user is manipulating; that core piece of data, you're manipulating it through java now and it should be possible to manipulate it through a script.
Ward: We'd like to see scripting embraced, it's not hard to put the engines in there. We want to see the service facades/DOMs shared. Find what the right abstractions are, knowing it's different than an engineers.
Ken: With that we're out of time, thanks all for coming.