Wednesday, December 21, 2005

 

Intelli-Dolphin1.1

Remember the discussion about Smalltalk IDE's and possible problems in Dolphins autocomplete package some days ago?

Meanwhile Tim has announced a new and powerfull auto completion package. Have a look at the flash demo or download the code right here.


Monday, December 19, 2005

 

Will the future start to happen ...

There is a new webcast presentation available on Croquet technology build in Squeak Smalltalk. I'm not sure which impact this technology will have on computing in the next years but I think it would be wise for many companies to have a look at it before their competitors do...


Monday, December 12, 2005

 

Today's (Smalltalk) IDE's Part II

The discussion about the power of Smalltalk IDE's continues. Some comments again:

Looks like Talios only accepts an IDE as powerfull if it supports auto completion. Dolphin Smalltalk may have some problems here. But why generalize then?

The eCompletion (Eclipse style completion) package from Squeak works quite nicely and only shows the appropriate selectors:



But there are cases where auto completion is not able to quess the type of an object (for instance when you play with reflection).

I dont claim Smalltalk IDE's to be the holy grail, but compared to other IDE's they are flexible and open. If it doesnt work in Dolphin you can change the auto completion very easily. Ever tried to change the auto completion of VisualStudio? ;)

 

Squeak is on fire

Cees has set up a build bot for Squeak 3.9alpha on his website. Read his blog why Squeak is on fire or have a look at his posting to the Squeak mailing list to get more infos.

Thursday, December 08, 2005

 

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.

Wednesday, December 07, 2005

 

SqueakSource Server image

I managed to build a working SqueakSource server image using the instructions from http://source.squeakfoundation.org.

With this predefined image you are able to run an own local SqueakSource repository server very easily.

Cees De Groot will host the image and put a download link onto the project page tomorrow. Here is a short preview of the image and the server running on localhost:





Many thanks to Doug Way for the instructions, the SqueakSource authors for this nice piece of Software, Cees for hosting and others who helped to make it available.

 

ComSwiki 1.5

Jochen "Jeff" Rick (J77) has announced a new version of ComSwiki (codename "One Of These Days").

The new release includes AniAniWeb - a personal home page system.


This page is powered by Blogger. Isn't yours?