Today's (Smalltalk) IDE's

I'm not sure why Cedric Beust (whoever this guy is) should be one of the forward thinkers in the Java community when he says something like this in an interview:

"A lot of veteran developers point out that Smalltalk showed that it was possible to have such an IDE in a dynamic language, but they are only partially right. Today's IDE's are doing much more than anything Smalltalk's environment ever did, so the problem is still wide open (and maybe impossible to solve)."

I used/use both: Smalltalk IDE's and Eclipse/VisualStudio like IDE's - also wrote plugins/goodies/tools for both (including an own standalone IDE). So I know what I'm talking about and have to disagree:

Today's IDE's are doing nothing more than Smalltalk IDE's in the past and present and will never be able to do more than a Smalltalk IDE in the future!

You ask why? Here is my answer:

One can easily build tools in a Smalltalk IDE without spending much time or relying on a predefined plugin architecture. That's why so many features in 'modern' IDE's have their history in Smalltalk. You can also modify the predefined Smalltalk tools to suit your needs since they come with full source code and are easily changeable.
(Ever tried to fix a bug in an Eclipse core package or plugin and you know what I'm talking about)

If there is no predefined Smalltalk tool for your task you can also write a simple script and run it. An example? Let's delete all (S)Unit test cases currently implemented using a single line of code:

TestCase allInstances do: [:each | each removeFromSystem]

Or maybe you need some statistics for your boss: let's count the number of SUnit test case classes in the system:

TestCase allSubclasses size

You can easily access the compiler:

Compiler evaluate: '3 + 4'

or directly evalute your code in a workspace.

Another example: you want to know how long a particular action or piece of code will take, so just write a profiler script or add the profiler into the particular method:

TimeProfiler profile: [self myLongRunningAction]

Next example: we want to watch an object. So just send

anObject inspect

to open an inspector showing the object and it's structure. We can also open a browser on the object's class by sending

anObject class browse

browsing the behavior and send new messages after that.

Try to do all this in VisualStudio or Eclipse. Even with additional script support added by the vendor/community you will never get the flexibilty of a Smalltalk IDE where you can access anything, including your projects, packages, classes, methods, files and not to forget the language itself. Other scriptable IDE's are mostly limited to predefined objects exposed by the IDE.

And you dont need to know a different scripting language with a different syntax. In a Smalltalk IDE you can use one simple and powerfull language to develop your program, enhance the IDE with tools, build your program and packages and deploy it, ...

So additional stuff like plugin architectures, build systems based on XML (Ant), setup managers, ... are not necessary in Smalltalk. Just use Smalltalk.

In a Smalltalk system there is also no difference between the IDE and the developed application. Typically you throw the IDE out of the image (where any object lives in) before delivering the application. Sometimes an IDE tool is also usefull for the end user of your application so you just leave it there. If you want you can leave the debugger or the whole IDE tools in the deployed application. So you can track problems happening only on the customer side, directly fix them in the debugger and continue running the application...

To transform this example into the java world: try to build and deliver an Eclipse RCP application with the java debugger included, fixing a bug and continue without restarting ...

This is mostly the problem developers from traditionall IDE's face when working with a Smalltalk IDE for the first time. They are too much bound to code in files, IDE tools like a compiler or a debugger as separate application, ...

Maybe some of the Smalltalk IDE's have to catch up with a better look or provide some newbee wizards and templates found in other commercial IDE's. Maybe then people like Cedric Beust will accept to work with them and learn about the power of Smalltalk.

Cees also wonders why anyone is wasting time interviewing this Cedric Beust.