This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Black Knight - Eclipse for Smalltalk
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
Eric Clayberg and John O'Keefe gave this talk. Starts with a brief overview of Eclipse. Eclipse is an integration platform built in Java. Number of services, etc. Platform services, Common Frameworks (SWT, for instance).
User's Perspective - Looks like a native app, since it uses SWT (similar to Common Widgets in VAST). Eclipse is a "state of the art" IDE for any language. Feature by feature comparision shows that Eclipse is good, probably better than most IDE's - not as full featured as most Smalltalks, although it's likely snazzier looking with better polish (there's a large Eclipse dev team). One of the new things Java people are excited about is "hot code replacement" (in the debugger).
Extending Eclipse is limited to the plugin points and the reflective capabilities of the environment. Eclipse does make deployment easier than it is in Smalltalk. The UI is a classic "C" style multi-paned, single window environment. The IDE type of features exposed to a developer are better in Smalltalk, with the exception of "Code Assist" type tools, aided by the manifest typing.
Eclipse now has decent refactoring capabilities, not as extensive or as scriptable as the RB in VW or VA. One can add more, via plugins. By default, no method categories. There are options via plugins. Many, many people creating plugins.
Developer's View There are a number of layers with extension (plugin) points for adding new/improved tools. The weaknesses are all due to Java language restrictions. The architecture is based on layered, dependent plugins. Isolation for plugins is better in Eclipse (although, namespaces in VW help here, a lot). Experimentation is a lot more restricted due to the structured nature of plugins.
Plugins - written in Java, integrated via XML (describes the plugin, etc.). Eric lists some of the workbench extension points - there are a lot of them. Question in my mind - yes, the plugins provide better idolation - but at the same time, they limit what you can actually do. If the original designers didn't envision it as a possibility, how limited are you?
Now a Demo of Eclipse VisualStudio style - tree views of packages - newer view offers a Smalltalk style 4 pane browser view. Instead of method categories, some kind of Type split.
Now onto John O'Keefe and the Eclipse for Smalltalk part of the show. First, he addresses the obvious question - Why are they doing this. Indeed, from my perspective, why aren't they improving VAST instead? I guess they get more developers this way, but.... Assertion - Smalltalk too closed a space, too introspective. There's truth in that. However, I'm not sure that getting commonality this way is the best path. Anyway....
The idea: Leverage the Eclipse environment (and the huge amount of work that has gone into it). Accomodate existing Smalltalk applications in. Use Smalltalk within Eclipse. I see a red flag there - if this works, VAST as an independent environment will be sunsetted. No, they didn't say that, but I read it that way.
Ahh, there we go. Second point here - choose WSAD over .NET. The enemy is Microsoft :) The plan, provide one IDE for everyone (note - monocultures are not good, IMHO). A partially unstated desire - it's a way to migrate the existing smalltalk base - VA and otherwise - over to this environment. What is it?
A "technical preview"
STDT - Eclipse Smalltalk Development Tools
STCL - Smalltalk Class Library (part of VA class lib)
STRT - Smalltalk Runtime Support
STDT - Another plugin for Eclipse. Nothing "unique" about this from the Eclipse standpoint. Interesting that there's no actual Smalltalk innovation here - no namespaces, for instance. File based Smalltalk source - source versioning with whatever Eclipse is hooked to. Provides a debugger, intent is to be Smalltalk neutral. Interesting, but VW has moved along - namespaces, shared variables, etc. Would likely take a fair bit of work to get that in - how much sharing with what IBM has done would be possible? I don't know; I'm sure that some of the VW engineers will eventually comment on that aspect.
What it has now - Package Explorer View, Editor. Search support - all based on underlying Eclipse code. Debugger is basic at this point.
Pragma methods for pools are now Pool Definition files
STRT Command line Smalltalk. Compiler, runtime with dynamic class loading. Image is used as a performance enhancer. Not released through Eclipse.org - this part will not be open source. Proprietary VM, free download. Windows (possibly Linux) only at start
Whew. It's got some interesting ideas - could provide a scripting alternative to S# with the command line compiler. Not sure that the IDE is a step forward for Smalltalkers - it may well allow greater access to people who don't know Smalltalk though, since it will look a lot more familiar. Ack! The source format is Smalltalk chunk format. That will be fun to edit. They will cover that from the user and offer method level editing. They will not support SIF, will likely do XML.
Platform speceific code? A bit crufty in VAST - had to use an additional tool. In the Eclipse env, that is no longer a problem.
A Demo - running an app from the env. You can customize the launch from within Eclipse. Launches a VM and Image, loading the code. When you resave a method, it does hot-load the new code into a running version of it. It's an extension to his demo at present, but will be a core feature eventually. Now we get a look at the debugger. Clearly a work in progress - no inspector yet. much further along than at OOPSLA 2002 though.
STDT - what's next? Will create JAR like files for packaging Smalltalk code collections. Will add method at a time editing. Will add a Class Hierarchy Browser. Will add wizards for - source folder, package, class creation. The greatest benefit out of this effort will likely be the creation of a Smalltalk runtime environment for VA. Will add a JNI bridge. Debugger will be improved greatly. Support for "halt".
STCL - what's next Additional apps ported from VA - SST in particular. Will rework lifecycle, expand the API for dynamic loading. Will rework catalog files, will move NLS to pools. Will reorganize projects into config map like scheme. This is going to cause as much of a migration issue for VAST users (ENVY to CVS style and new tools) as the move from VW ENVY to Store has. Will add scripting support:
stdin/out/err
synch and asynch exec
unix shell and WSH startup
Compile and Go support
STRT - what's next Dynamic loading from JARs, saving of the class cache, performance tuning, more platforms (Linux, zOS)
So in summary - John wants to remind everyone that this is early dev days for this - it's at technology preview level, not beta (or even alpha!). Everything is in flux, so things stated in the talk may not go forward as planned now. He's interested in feedback, wants to know if the VA customers (and others) see value in all this.
Questions Vendor Neutral? How would that work? They would like to work with other ST vendors - like us, for instance :) - and see if there's shared interest in this. Licensing - the libraries will be open source (as will be the IDE plugins). The VM will be a free download, but will not be open source. It will be available under goodie style license restrictions - binary style license. Other Eclipse Plugins - would they fit in? Likely not well, at least not at this point. Follow up - if the goal is to leverage Eclipse, how doe it do that if most plugins are orthogonal? Good question. According to Eric, resource based (not language specific) plugins will be usable. Joseph Pelrine - use Rosetta (XML) and you get a lot of the meta-data you want. Resource constraints limit this at the moment. Audience member - Idiocy (no ENVY - where have I heard that before?). The main point seems to be why try to recreate what you already have (a valid question, IMHO). This complaint is all about two things - wasted effort (we already have all this), and What, no ENVY??? The VW move to Store had a lot (and still has some) of the latter. Follow up, Bob Nemec - why would an existing VAST shop consider moving to this? With the resources all in this, what (if anything) is being done for VAST? Likely, little benefit now. Probably more later as contributions come along. Secondly, this is a spare time, nights and weekends project. Team at IBM still working on VAST. The danger for IBM here is that some customers will read this like people read the PPD problems in the 2.5.2/3.0 era. IBM has not blessed (officially) this, while the Eclipse board has done so. No way to write Eclipse plugins in Smalltalk? Not at this point, no. Will it ever be? Not exactly. There will be the JNI hooks, might be possible - needs to be explored. Follow up - looks like a boil the frogs strategy. It will look that way, and it will be a question these guys get asked a lot. Unified Debugger?? Not an initial goal, it's a hard problem all by itself.
I have to admit, there's schadenfreude in hearing the IBM guys get the commitment questions that I used to get. It's dangerous for Smalltalk in general though, so I can't take too much enjoymenet in it.
Previous Topic
