Evaluating Dolphin

Hi,

Being an active Java developer I understand that Java is not well
suited enough (at least now)
for windows application development. Therefore I started to look at
different languages/technologies
which might be better suited for windows. I was eveluating Dolphin for
several weekends and would like
to share my opinion (I really want to here that I'm wrong in some
points and to to start anti-smalltalk
war).

I'll start from PROS:

1. Memory usage/resulting executable size. They are quite small (but
can be smaller). Anyway, looks like
they are be convinient for most GUI development.

2. Win32 connectivty. It's really simple to call a function from DLL
from Dolphin. This is good.

3. The language. Sometimes it has some features which are not found in
Java/C#. Sometimes it lacks some. But still
it's a good one. OO, reflective, with automatic memory management.
Much better suited for rapid development
than C++ (as for me).

And now, the main part, CONS:

1. Documentation, documentation, documentation. There are no
documentation. The only thing we get are
class comments (they are simply not enough) & source code. I've spent
two hours to try to queryCommand:
to be executed in my presenter for commands from toolbar. I haven't
succeded. The lack of documentation
is terrific. 90% of time I was looking through dolphin source code in
order to understand how to do X & Y.
The tutorials which are available don't explain anything. Class
comment don't help. (Don't tell me that
there's a book at amazon which can you should by in order to
understand our framework. Is dolphin a
commercial app or not?). QT, Swing have thouthands pages of
documentation available. There are dozens
of tutorials. Dolphin has nothing!

2. Development environment. I've being reading numerous times in books
that 'smalltalk development
environments are much more comortable & feature-packed than others'.
C'mon guys, have you ever came out
of your shell? IntelliJ IDEA & Eclipse are hundred times better than
dolphin's environment. In dolphin
there's no
syntax highlighting, completion (I'm quite sure that it's possible to
implement in 99% of cases), rapid
code navigation, almost no keyboard support (I can't develop in
smalltalk without a mouse, can you?),
refactorings are already behind the mentioned IDEs (I was really
surprised, when extract temporary
didn't suggest me to extract common expression), there are no
on-the-fly error highlighting, refactorings
can't be performed on not-saved code, the necessity not to forget to
save an image & to save package
sources periodically drives me crazy (should I again develop a
forgotten instinct?) and many other
frustrating things.
Looks like Object-artists should carefully look at the other IDEs
outside smalltalk world.

3. Debugger. Debugger stinks! I'm not able to see all local values at
the same time. No watches.
No breakpoints. Is 'self halt' the best debugging method which was
developed during 20 years? I was
also reading that 'in smalltalk you can't debug the system and
understand how is it working'. Ha!
Try adding 'self halt' to Presenter>>queryCommand:.

4. Image-based development. Well, it is really fun to be able to play
with your object in a workspace.
It's also possible to develop an application in a hilarious manner of
creating live objects & their
interconnections right in the image. But the last method should be
forgotten if you are not the only
programmer in a team (or should we share an image somehow?). Also the
whole paradigm leads to a situation
when I can't change/debug the library. It will lead to a corrupted
image. All I'm allowed is to add
methods to a library and make changes which won't touch the IDE
(taking into account that IDE is using
not less than 50% of library, at least all its critical part, I can't
change methods code). I had no
problems with separation of IDE from my application. And it will solve
many of the problems.

5. Library. I do understand that noone at Object-Arts have ever needed
Canvas>>pie method, which is
the standard GDI function. But is what I expect from a commercial
library? Do guys at Object-Arts have
commctrl.dll at their computer? Looks like they don't. If yes, where's
the support for the following
controls: animation, ip address, rebar, property editor, syslink,
tooltip, up-down control?
Where's the support
for commctrl5 features (I bet it will be hard to find a desk at your
office with common controls's version
less than 5). You even have no constants in your pools for all that
staff! I know that I can support
anything for myself. But is what we expect from XXI century?

6. Team support. Hardly any. A possibilty to use PAX source format.
Yea. Cool. But you should don't forget
to save packages (have I mentioned this? Yeas. I've), than you should
use your VCS's tool. Also, after
checking out changes, you should uninstall packages and install them
again. Doesn't seem to be really
comfortable.

7. Price. It's to high if you take into account the above items.
What's the advantage of having DB support if
you even have no sample of DB support. $349 without a support. And
with $100 per support incident. Wow! Compare it compare with Java
price.
And please remember that Dolphin (smalltalk) community is not too
large if you expect to leave without support and documentation.
(Don't mention the QT price ;) ).



Conclusion

Dolphin smalltalk has a good chances to be used in commercial GUI
application development. However much should
be done by Object-Arts to achieve this goal.

Perhaps I should have dropped this, but I did enough typing early on that
I'm going to post anyway.  To the poster, please take this as a long-time
Smalltalk user and Dolphin advocate trying to help you make the transition
to a great language and an excellent implementation of it.  However, I'll
admit that the more I read, the less I believe that you are anything other
than a troll.  If that characterization is unfair, you can reveal it best by
addressing specific issues that I have raised.


> 1. Documentation, documentation, documentation. There are no
> documentation.

Yes and no.  Take a look at Ian Bartholomew's web site, which among many
other great things includes archives of this newsgroup, and privately hosted
group(s) before it.

Also, please note that Smalltalkers view the image itself as being
documentation, and some of the best in existence.  In searching the
archives, you'll note that some of us have expressed concern that the
Refactoring Browser (and really eXtreme Programming) have degraded the
readability somewhat, but there is still a LOT of good reading in the image.

The D4 help files are still quite applicable.


> The only thing we get are
> class comments (they are simply not enough) & source code. I've spent
> two hours to try to queryCommand:
> to be executed in my presenter for commands from toolbar. I haven't
> succeded.

Some searching in the archives will likely help you.  Also, look at Ian's
site for samples.  Also, are you certain that you haven't succeeded?  You
might print something to the transcript to see if the code is being called.
It it's not, then you might simply have a problem with a selector name
(sometimes a missing colon or something can cause frustration, at least
until you learn when to look for it, and especially so _after_ you should
have learned to look for it<g>).


> The lack of documentation
> is terrific. 90% of time I was looking through dolphin source code in
> order to understand how to do X & Y.

At the risk of sounding critical or insensitive, I'm not convinced that
documentation will help all that much.  There is no shortage of
documentation (books, magazines, stacks of CDs that arrive every few months,
etc.), and I still sometimes find questions that are all but unanswerable re
Windows.  Sometimes reverse engineering is the most direct method.  The
beauty of Smalltalk is that the IDE is built with that in mind, and once you
learn to use it effectively, you will be able to answer most questions quite
easily.  Other questions have ready answers in the archives, and then there
are those questions that have yet to be asked - you can help us tackle that
list.


> The tutorials which are available don't explain anything.

Sorry, I know better, having read some of them.


> 2. Development environment. I've being reading numerous times in books
> that 'smalltalk development
> environments are much more comortable & feature-packed than others'.
> C'mon guys, have you ever came out
> of your shell? IntelliJ IDEA & Eclipse are hundred times better than
> dolphin's environment. In dolphin
> there's no
> syntax highlighting,

I'm not sure what to say: you are loosing credibility.


> completion (I'm quite sure that it's possible to
> implement in 99% of cases), rapid
> code navigation, almost no keyboard support (I can't develop in
> smalltalk without a mouse, can you?),

Why would I want to do so?  As for writing apps that end users can use w/o a
mouse, that should not be a problem.


> refactorings are already behind the mentioned IDEs (I was really
> surprised, when extract temporary
> didn't suggest me to extract common expression), there are no
> on-the-fly error highlighting, refactorings
> can't be performed on not-saved code, the necessity not to forget to
> save an image

There is a prompt before exit, so that shouldn't be a problem.

>  & to save package
> sources periodically drives me crazy (should I again develop a
> forgotten instinct?)

One can arrange to save packages automatically, though I would advise
against it.  If you are truly interested in learning about Dolphin and
Smalltalk in general (which I'm starting to doubt), then I will happily
explain further.  Saving the image is all that you really need to do though,
at least for short-term protection of your work.


> and many other
> frustrating things.
> Looks like Object-artists should carefully look at the other IDEs
> outside smalltalk world.

I assure you they have, and they've built one of the best ones that I've
seen.


> 3. Debugger. Debugger stinks!

I must disagree.


> I'm not able to see all local values at
> the same time. No watches.
> No breakpoints. Is 'self halt' the best debugging method which was
> developed during 20 years? I was
> also reading that 'in smalltalk you can't debug the system and
> understand how is it working'. Ha!
> Try adding 'self halt' to Presenter>>queryCommand:.

That's a consequence of "working on the engine while it's running".  Cases
in which it is a problem are rare.


I'm reminded of a time some years ago when OA shipped a database connection
package with a bug in an error handler.  Five minutes after starting my
(then not automated) tests, I had it fixed, by doing specifically what you
seem to feel is not possible.  IIRC, OA patched it later that day, but I was
able to do so w/o their involvement.


>All I'm allowed is to add
> methods to a library and make changes which won't touch the IDE

Not true.  You can change anything, you simply need to be careful if you
touch the sensitive parts.  Experience will reveal them to you.


They do.

As you pointed out in your pros section, Dolphin's Win32 connectivity is
excellent.  If something is mising, you can generally add it in a matter of
minutes.



> 6. Team support. Hardly any. A possibilty to use PAX source format.
> Yea. Cool. But you should don't forget
> to save packages (have I mentioned this? Yeas. I've), than you should
> use your VCS's tool. Also, after
> checking out changes, you should uninstall packages and install them
> again. Doesn't seem to be really
> comfortable.

I'll leave this one to others to comment.  When I have help, I tend to send
people off on fairly discrete missions and we then have a file-in party,
after which I give them a new gold-standard and another mission.  It's not
the traditional team development approach, but it works well, especially
with graduate students vs. full-time warmware.


Sincerely,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

mm_aa wrote:
Well, Dolphin has something, this newsgroup!  Seriously, I converted to
IBM VisualAge, from Visual Smalltalk.  VisualAge has tons of
documentation, but I've had questions hang unanswered on the newsgroup
for months going on years.  I've have found answers to most of my
questions simply by searching this group on Google.  The few questions
I've had that I couldn't find an answer to were answered here within
hours!  I have Visual Studio.net, also replete with documentation, not
to mention MSDN.  Those are great sources for api specs, and simple
examples, but I still find myself searching for good examples in books
or elsewhere on the web.  While I also like documentation, I haven't
found the lack of it to be a problem.  Dolphin is very different from
VisualAge, but it's been easier to learn.  Maybe that's because it's the
third smalltlk I've used, but it's also due to the way Object Arts put
this product together.
I guess I'm missing something here.  I think it has syntax highlighting.
  I've used other IDEs, and I think Dolphin is better in some areas, as
good in most, and I could recommend some changes.  Some of the things
you want, I don't see as issues, particularly since the language is
growing.  I'd hate to see these guys spend any time on adding keyboard
support for example.  So far I haven't forgotten to save anything.


> 3. Debugger. Debugger stinks! I'm not able to see all local values at
> the same time. No watches.
> No breakpoints. Is 'self halt' the best debugging method which was
> developed during 20 years? I was
> also reading that 'in smalltalk you can't debug the system and
> understand how is it working'. Ha!
> Try adding 'self halt' to Presenter>>queryCommand:.
>
Breakpoints would be nice, but I hardly think the debugger stinks.  As a
new user to Dolphin, I've spent a lot of time lokking at the debugger,
and it's usually led me to the source of my trouble.

Well, I don't work in a team environment with Dolphin, but I'm using
code from several other developers, including an evolving wrapper of
GDI+. This seems to be working well enough.  Also, if you add the
(reasonably priced) code management package from Goresek, finding your
changes, rolling back, etc becomes very easy.
So far, I've found almost everything I've needed.  The few things I've
wanted to add, took less time to add than any other language I've ever
worked in.  I've used many languages during my career and I've always
had to purchase additional libraries to do things I've wanted.  I don't
see how this is really that different, but I'm not in your situation, so
I won't argue too hard on this one.


> 6. Team support. Hardly any. A possibilty to use PAX source format.
> Yea. Cool. But you should don't forget
> to save packages (have I mentioned this? Yeas. I've), than you should
> use your VCS's tool. Also, after
> checking out changes, you should uninstall packages and install them
> again. Doesn't seem to be really
> comfortable.

VisualAge has team support nailed solid with Envy, but I don't use it.
I develop in a small team, and we work out of separate images.  We merge
code often and it usually works, sometimes we step on our toes, but it's
never that much of a hassle.  Plus, I work at home, at work and on the
road, sometimes connected, sometimes not.  I don't think team management
  software is always the answer (your-milage-may-vary).

>
> 7. Price. It's to high if you take into account the above items.
> What's the advantage of having DB support if
> you even have no sample of DB support. $349 without a support. And
> with $100 per support incident. Wow! Compare it compare with Java
> price.
> And please remember that Dolphin (smalltalk) community is not too
> large if you expect to leave without support and documentation.
> (Don't mention the QT price ;) ).

$349 high? I don't think I see the problem.  Visual Studio.net was over
$1,000, with 3 free support calls then they go for $249 each.  Other
Smalltalks are orders of magnitude more expensive.  Full blown Java
development environments are multiples more expensive as well. For less
that $600 I have the professional version of Dolphin, a code library and
an Object Database - where's the problem here? That's the stuff I
bought, take a look at the stuff that's available for free.  Not only
can you add some very nice features to your image, you can learn how to
do almost anything (because you can view the source and do all that live
image stuff you don't seem to like).

>
>
>
> Conclusion
>
> Dolphin smalltalk has a good chances to be used in commercial GUI
> application development. However much should
> be done by Object-Arts to achieve this goal.

Object-Arts has done a very good job with this product to-date, and I am
confident that will continue.  I originally purchased Dolphin for some
small pet projects that could benefit from being a little closer to the
Microsoft OS than the cross platform smalltalks.  After using it for
about two months, I'm making plans for working it into our business
development environment.

-Dan
Dan Antion

mm_aa wrote:

<snip>

> 1. Documentation, documentation, documentation.

As mentioned by Bill, Ian Bartholomew has some goodies that can be used to
access documentation at:

   http://www.idb.me.uk/

Additionally, installing all of Ian's goodies into your image provides a
good source of example code.

<snip>

> two hours to try to queryCommand:
> to be executed in my presenter for commands from toolbar. I haven't
> succeded.

Just guessing at the problem; have a look at the Toolbar>>commandSource
method. The effect of this method is that the commands get routed starting
from your Shell, which is not necessarily the container presenter that you
have placed the Toolbar in.

One solution is to manually modify the command routing so that your
presenter is in the command route.

For example if you have a Shell, that has a Presenter childComponent, that
contains the toolbar ... you would add the following method to your Shell;

  MyShell>>addToCommandRoute: route.
    route
      appendPresenter: self;
      appendPresenter: myPresenter.

Dolphin's command framework is powerful, but as you found out, it can be
hard to follow because of the difficulty of putting "self halt"s in the
code. One trick is to use a Global switch to ensure that only a single
debugger is opened;

     ShouldHalt == true ifTrue: [ShouldHalt := false. self halt].

Once you have a debugger open, you can step through the routing in the
debugger.

> 2. Development environment. I've being reading numerous times in books
> that 'smalltalk development
> environments are much more comortable & feature-packed than others'.

Not sure about "feature-packed", but the environment is very consistent and
accessible. For example, there is an add-on for Dolphin; Tools+ by Solutions
Software, that adds some of the features you mentioned:

     http://www.solutionsoft.co.uk/toolsplus/index.htm

<snip>

> controls: animation, ip address, rebar, property editor, syslink,
> tooltip, up-down control?

I cant argue with this, more wrapping done by Object-Arts is better than
less.

FWIW: I have a wrapping of the animation control at:
    http://www.stevewaring.net/blog/articles/animationControl.html

Ian Bartholomew has a wrapping of the up-down control (in the IDB Spinner
package).

I also have an unreleased wrapping of the tooltip control, which only needed
one class and a couple of methods to implement.

<snip>

> 6. Team support.

There is STS by David Gorisek. From his web-page: "Source Tracking System is
an add-on for the Dolphin Smalltalk development environment that lets you
track your project in a team environment".

There are many Dolphin programmers who use STS for their source management:

   http://www.gorisek.com/homepage/index.html

Hope this helps!
Steve

--
Steve Waring
Email: [hidden email]
Journal: http://www.stevewaring.net/blog/home/index.html

mm_aa,

> And now, the main part, CONS:
>
> 1. Documentation, documentation, documentation. There are no
> documentation.

<snip>

> QT, Swing have thouthands pages of
> documentation available. There are dozens
> of tutorials. Dolphin has nothing!

Somewhat of an exageration, I feel. Did you read this (linked off the D5
downloads page)?

http://www.object-arts.com/UsingD4HelpWithD5.htm

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

Hi...

first, let me tell you that I have many of the same problems with the
Dolphin environment that you mentioned.
I am using IDEA most of my day to work with, and the stunning keyboard
support and refactoring abilities are the best I have ever seen in my life
(and I am in busibness for quite some years). So, to be fair, you should
mention this when comparing to Dolphin. Ever used Netbeans or JBuilder? ;-).

Documentation is indeed lacking. You have to get used to search the image
(e.g. with full text search) to get some examples. However, the lack of
documentation is a big barrier for professional usage.  You can buy Ted
Brachts book, but it is just an introduction. Also, with Dolphin you need an
MSDN subscription if you want to understand in depth the underlying
mechanics, as many things are in fact windows based.

> 1. Memory usage/resulting executable size. They are quite small (but
> can be smaller). Anyway, looks like
> they are be convinient for most GUI development.

Memory usage is really great in Dolphin. Performance is about factor twenty
lower than Java HotSpot VM, OTOH. But: surprisingly often this does not
matter, as the native widget approach makes a dolphin GUI feels MUCH
snappier than a Java Swing GUI.

> 2. Win32 connectivty. It's really simple to call a function from DLL
> from Dolphin. This is good.

This is especially great, as Dolphin hides so many Windows woes from us.
Integration improved a lot in PL3, BTW.


> 3. The language. Sometimes it has some features which are not found in
> Java/C#. Sometimes it lacks some. But still
> it's a good one. OO, reflective, with automatic memory management.
> Much better suited for rapid development
> than C++ (as for me).

Yep, ST is the best prototyping env. I was ever in. Con is that Dolphin is
likely to crash if you have errors (or self halt's) in GUI related code due
to the strong connection with windows (you always pay this price for native
interactions).

> 1. Documentation, documentation, documentation. There are no

Get EducationCenter 4 (big marketing mistake IMO not to deliver it with D5
and have dead links in the Help menu).
Get Ted Brachts book
Search the image
Search the web
Most of all: ask here in this newsgroup. Best help you can possibly get!

> syntax highlighting, completion (I'm quite sure that it's possible to
> implement in 99% of cases), rapid
> code navigation, almost no keyboard support (I can't develop in
> smalltalk without a mouse, can you?),

Syntax hiliting is not real time, which is not so nice, but not soo bad
either. The formatter (on save) is good.
Refactoring is definitely ok to work with (except sometime restriction to
package level is missing). Completion is really missing, although often not
so easy in ST as you have dynamic typing (which is very nice OTOH). Also, I
remember there is a free add-on out there...

>
> 3. Debugger. Debugger stinks!
> I'm not able to see all local values at the same time. No watches.
Yep, this is a big drawback. You can open inpectors on the vars of interest,
but they do not update automatically :-(.

> No breakpoints. Is 'self halt' the best debugging method which was
developed during 20 years?

They are coming in D6. Also, you might want to try the solutionssoft
commercial add-on. I had problems with it, however (e.g. circular
dependencies on package save with AXControlSite resources inside).


> 4. Image-based development. Well, it is really fun to be able to play
> with your object in a workspace.

Come on, this is the biggest benefit over Java, at least  in prototyping.
You just have to get used to it.
I would have needed at least 4 times as long in my algorithm development if
I had used Java for prototyping.

> 5. Library. I do understand that noone at Object-Arts have ever needed
> Canvas>>pie method, which is
> the standard GDI function. But is what I expect from a commercial
> library?

The other issue you forgot is to keep the image small and comprehensive. It
is not hard to add this method by yourself.


> 6. Team support. Hardly any.

This is unfortunately true. Frequent installing and uninstalling (possibly
dependent) of packages is a nightmare. A "reload package" command would help
out of this.


> 7. Price. It's to high if you take into account the above items.

Definitely not. Dolphin Pro is worth every buck. I never needed a support
incident as we have this group :-).
Also, Java is sponsored and NOT profitable by itself. I guess Andy and Blair
(as all of us) are not in this state.
Again, have you seen e.g. JBuilder prices...


> Dolphin smalltalk has a good chances to be used in commercial GUI
Oh yes.

Just my two cents

Ciao

...Jochen

Bill,

"Bill Schwab" <[hidden email]> wrote in message news:<b2u6fc$1gqtdg$[hidden email]>...


> > The lack of documentation
> > is terrific. 90% of time I was looking through dolphin source code in
> > order to understand how to do X & Y.
>
> At the risk of sounding critical or insensitive, I'm not convinced that
> documentation will help all that much.  There is no shortage of
> documentation (books, magazines, stacks of CDs that arrive every few months,
> etc.), and I still sometimes find questions that are all but unanswerable re
> Windows.  Sometimes reverse engineering is the most direct method.  

I'm not against reading the code. I'm against this way when I need to
perform a really simple task. I do read Swing source code when I need
to implement custom event queue. But I don't when I don't know how to
create a table. I just open a documentation, look through numerous
examples and quickly get an idea.

> > The tutorials which are available don't explain anything.
> Sorry, I know better, having read some of them.

I also did it. And I still don't know what's the right (proposed) way
to create list/detail UI relationship. I tried to create a value
model, which value I change in selection - that didn't work. Now I
simply do:

onSelectionChanged
   presenter1 model: (self selectedItem).
   presenter2 model: (self selectedItem).
   presenter3 model: (self selectedItem).
   presenter4 model: (self selectedItem).

Doesn't seem to be a right way.

> > 2. Development environment. I've being reading numerous times in books
> > that 'smalltalk development
> > environments are much more comortable & feature-packed than others'.
> > C'mon guys, have you ever came out
> > of your shell? IntelliJ IDEA & Eclipse are hundred times better than
> > dolphin's environment.

> > In dolphin
> > there's no
> > syntax highlighting,
>
> I'm not sure what to say: you are loosing credibility.

What I do mean is that there're no on-the fly syntax, error
highlighting and automatic indenting during editing. Or is there?

I'm quite sure that you haven't used the mentioned IDE more than
several hours. (I was developing in Dolphin during 8-10 days. Not to
much but I think it's enough to get a taste).

>
>
> > completion (I'm quite sure that it's possible to
> > implement in 99% of cases), rapid
> > code navigation, almost no keyboard support (I can't develop in
> > smalltalk without a mouse, can you?),
>
> Why would I want to do so?  As for writing apps that end users can use w/o a
> mouse, that should not be a problem.

I'm quite sure that ability to develop without the need to reach a
mouse has improved my productivity. in IDEA I'm working at the speed
I'm thinking.

> > and many other
> > frustrating things.
> > Looks like Object-artists should carefully look at the other IDEs
> > outside smalltalk world.
> I assure you they have, and they've built one of the best ones that I've
> seen.

Which ones were you actively using in the past (present?).

> > 3. Debugger. Debugger stinks!
> I must disagree.

C'mon guys. You disagree, but there's still plenty of features
available in other debuggers which makes debugging more pleasant.
That's what I mean when I say 'it stinks'. Currently all the features
present in Dolphin debugger are present in Java debuggers (even method
code hot swap). And a bunch of other ones. So, which thing do you
disagree with?

> > developed during 20 years? I was
> > also reading that 'in smalltalk you can't debug the system and
> > understand how is it working'. Ha!
> > Try adding 'self halt' to Presenter>>queryCommand:.
>
> That's a consequence of "working on the engine while it's running".  Cases
> in which it is a problem are rare.

I did have several times. I'm not able to debug the engine at all.
Yes, I can add "Notification signal:" but I've found myself looking
through thousands of transcript lines in search of the ones I'm
intereseted for.

I don't think that it's impossible to change the code development
environment doesn't use. There're no problem. But try to change MVP
part. I'll stuck.

A quote from the site: "It is a highly productive development
environment targeted at the graphical Visual Basic / C++ / Java
developer who wishes to adopt a pure approach to object-oriented
programming." So, I exepect all this to be already present.

mm_aa,

I too am not convinced that you are not just trolling. For example, why an
anonymous post with no e-mail address.

However, my impression from reading your comments is that you are missing
one critical thing when comparing Dolphin with various Java incarnations.
That is that it is Smalltalk. This is Dolphin's big advantage over Java. If
you grock that then you will be more willing to relish the good points about
the Dolphin IDE rather than concentrating on the differences that you seem
to see as bad points. Here are some examples:

1) It is the "Smalltalk way" to peruse source code to find examples of it's
use. This is often not the case in other languages because the full source
isn't always available (and when it is - is typically much more verbose). In
Smalltalk you (virutally) always get the full source code to everything.

2) It is the "Smalltalk way" to write very small methods. This, together
with the fact that a method compile is virtually instantaneous, means that
dynamic syntax highlighting is not generally considered important.
Personally, I've never found a need for it. However, a third party product
is available that adds this amongst other things:

http://www.solutionsoft.co.uk/toolsplus/index.htm

Small methods also means that the method editor can be relatively simplistic
(as it is in Dolphin). When you are editing huge Java class files you may
need emacs bells and whistles; editing five lines at a time probably not.

3) It is the "Smalltalk way" to work inside a "sea of live objects" (the
image) that contains the development tools along with the source. Providing
you learn to take care this is virtually never a problem. Yes, you can break
something by putting breakpoints in key bits of code but just restart and
remember not to do it again. It has been over a year since I accidentally
broke an image like this.

4) It is the "Smalltalk way" to develop inside the debugger while the
application is running. I've heard that you can (at last) recompile methods
inside some Javas' debuggers, but can you define new methods (as a result of
a #doesNotUnderstand: fault) create new classes and refactor the entire
system? I haven't seen it but I suspect not. Certainly in all the Java IDEs
I've seen (I admit to not having used IDEA - I note it is 150% the price of
Dolphin Pro) when you are debugging an application you are working on a
static "dead" thing. In Smalltalk the objects are just so much more
malleable and "alive".

I'm not sure whether the point of your message is to "bash" Smalltalk or
Dolphin's implementation of it. If it is the former then you should first
try and understand why many people here believe Smalltalk is so much better
and productive than other languages like Java. It is because of things that
comprise the dynamic "Smalltalk way". If you are complaining, in particular,
about Dolphin's implementation of a Smalltalk environment then perhaps you
would be so kind as to compare its useablity with other Smalltalk IDEs.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

"Jochen Riekhof" <[hidden email]> wrote in message
news:[hidden email]...
> ...
> I am using IDEA most of my day to work with, and the stunning keyboard
> support and refactoring abilities are the best I have ever seen in my life
> (and I am in busibness for quite some years).
>....

I'd be interested in hearing more constructive criticism here. What specific
refactoring features does IDEA (and/or Eclipse) have that Dolphin lacks?
What specific things do you want to do from the keyboard that you can't
already?

>...
> > I'm not able to see all local values at the same time. No watches.
>
> Yep, this is a big drawback. You can open inpectors on the vars of
interest,
> but they do not update automatically :-(.
>
> > No breakpoints. Is 'self halt' the best debugging method which was
> > developed during 20 years?
>

Certainly these features would be useful, but they are not essential in the
way that they are for file-based static languages. The key to productive
debugging in Smalltalk is to realise is that "whole program" debugging is
hardly ever needed, and is almost never the best approach. In a static
environment one needs sophisticated breakpoint capabilities just to be able
to get to the point where one can begin debugging the problem. In the live
Smalltalk environment one can set things up so that one can repeatably start
debugging at the level of an expression. One can also open subsidiary
debuggers to investigate details as one goes along by simply selecting an
expression in an open debugger and debugging that. I've don't think I've
ever missed the lack of a watch list, despite using such things a great deal
when programming in other languages. I don't think many others could have
missed it either, since it would be fairly trivial to implement and I
haven't seen any examples of such an extension, or felt compelled to add it
myself.

A key point is that one can do just about all ones programming in the
debugger (including refactoring), and this is a very productive and powerful
way of working. In my view a key reason for this is that it allows one to
work at a concrete level, rather than in the abstract, and most people find
this much easier. None of the various edit and continue mechanisms I've seen
(outside dynamic languages) come even close to the virtually unlimited
capabilities of Smalltalk in this regard, because the latter doesn't have
any any artificial distinction between development and runtime. In Smalltalk
I can make any code modification, and evaluate any expression, in the
debugger, or any other coding tool, at any time.

Lastly it simply isn't true to say that one can't debug through large parts
of the system. Cite a specific circumstance, and I or someone else will tell
you how to do it. The techniques are simple. If you don't know how to do
something, don't complain that it isn't possible, just ask.

Regards

Blair

Dear Jochen,

you say:

'Memory usage is really great in Dolphin. Performance is about factor twenty
lower than Java HotSpot VM, OTOH. But: surprisingly often this does not
matter, as the native widget approach makes a dolphin GUI feels MUCH
snappier than a Java Swing GUI.'

please could you explain more about 'Performance is about factor twenty
lower than Java HotSpot'
what do you mean? what is your experience?

thanks,

Seb




"Jochen Riekhof" <[hidden email]> escribió en el mensaje
news:[hidden email]...
> Hi...
>
> first, let me tell you that I have many of the same problems with the
> Dolphin environment that you mentioned.
> I am using IDEA most of my day to work with, and the stunning keyboard
> support and refactoring abilities are the best I have ever seen in my life
> (and I am in busibness for quite some years). So, to be fair, you should
> mention this when comparing to Dolphin. Ever used Netbeans or JBuilder?
;-).
>
> Documentation is indeed lacking. You have to get used to search the image
> (e.g. with full text search) to get some examples. However, the lack of
> documentation is a big barrier for professional usage.  You can buy Ted
> Brachts book, but it is just an introduction. Also, with Dolphin you need
an
> MSDN subscription if you want to understand in depth the underlying
> mechanics, as many things are in fact windows based.
>
> > 1. Memory usage/resulting executable size. They are quite small (but
> > can be smaller). Anyway, looks like
> > they are be convinient for most GUI development.
>
> Memory usage is really great in Dolphin. Performance is about factor
twenty due
> to the strong connection with windows (you always pay this price for
native not
> so easy in ST as you have dynamic typing (which is very nice OTOH). Also,
I
> remember there is a free add-on out there...
>
> >
> > 3. Debugger. Debugger stinks!
> > I'm not able to see all local values at the same time. No watches.
> Yep, this is a big drawback. You can open inpectors on the vars of
interest, if
> I had used Java for prototyping.
>
> > 5. Library. I do understand that noone at Object-Arts have ever needed
> > Canvas>>pie method, which is
> > the standard GDI function. But is what I expect from a commercial
> > library?
>
> The other issue you forgot is to keep the image small and comprehensive.
It
> is not hard to add this method by yourself.
>
>
> > 6. Team support. Hardly any.
>
> This is unfortunately true. Frequent installing and uninstalling (possibly
> dependent) of packages is a nightmare. A "reload package" command would
help
> out of this.
>
>
> > 7. Price. It's to high if you take into account the above items.
>
> Definitely not. Dolphin Pro is worth every buck. I never needed a support
> incident as we have this group :-).
> Also, Java is sponsored and NOT profitable by itself. I guess Andy and
Blair

> I'm not against reading the code. I'm against this way when I need to
> perform a really simple task. I do read Swing source code when I need
> to implement custom event queue. But I don't when I don't know how to
> create a table. I just open a documentation, look through numerous
> examples and quickly get an idea.

Give DSDN or Ian's news browser a try.  A search on one keyword followed by
a search of the results for another is usually sufficient to locate good
information, or at least show you where to look in the image for the answer.


If presenter1 through present4 are value presenters, then it's
enough/prefered to send #value:.  If they are more complicated, then I have
good news and bad news.  My PaneHolders package provides alternative
solutions.  The bad news is that it's been brought to my attention that the
package on my web site won't load for want of an unintended dependence on
another package.  The fix will be to eliminate the dependence.  The guy who
reported the problem was able to work around it and might be able to email
you a loadable package faster than I can fix it and update my web site.  If
you are in a hurry, you could probably also file in chunks from the package
until PaneHolder works.


> What I do mean is that there're no on-the fly syntax, error
> highlighting and automatic indenting during editing. Or is there?

You are correct; it happens in the compiler.


> I'm quite sure that you haven't used the mentioned IDE more than
> several hours. (I was developing in Dolphin during 8-10 days. Not to
> much but I think it's enough to get a taste).

If you are (as this sounds) editing my CV, then you are starting to sound
like a troll again.



> I'm quite sure that ability to develop without the need to reach a
> mouse has improved my productivity. in IDEA I'm working at the speed
> I'm thinking.




> > > and many other
> > > frustrating things.
> > > Looks like Object-artists should carefully look at the other IDEs
> > > outside smalltalk world.
> > I assure you they have, and they've built one of the best ones that I've
> > seen.
>
> Which ones were you actively using in the past (present?).

Aside from those that I evaluated and never really used (an exhaustive list
escapes me), the usual offerings from Borland, Microsoft, pretty much every
Smalltalk that has existed in the past 12 years, if only briefly (haven't
touched VA in _years_).  Dolphin (obviously), and the other Smalltalk that I
use most is Squeak.  I'm getting away from Visual Studio in favor of MinGW
and have more or less settled on Dev-C++ which isn't at all feature rich but
it is small and a good match for the little bit of C++ coding that I do.


> > > 3. Debugger. Debugger stinks!
> > I must disagree.
>
> C'mon guys. You disagree, but there's still plenty of features
> available in other debuggers which makes debugging more pleasant.

Would you care to give us a list of specifics?


> That's what I mean when I say 'it stinks'. Currently all the features
> present in Dolphin debugger are present in Java debuggers (even method
> code hot swap). And a bunch of other ones. So, which thing do you
> disagree with?

Your statement that it stinks, to be precise.  I have spent quite a few
hours poking around in the Dolphin debugger, and have found it to be more
than satisfactory.


> > > developed during 20 years? I was
> > > also reading that 'in smalltalk you can't debug the system and
> > > understand how is it working'. Ha!
> > > Try adding 'self halt' to Presenter>>queryCommand:.
> >
> > That's a consequence of "working on the engine while it's running".
Cases
> > in which it is a problem are rare.
>
> I did have several times. I'm not able to debug the engine at all.
> Yes, I can add "Notification signal:" but I've found myself looking
> through thousands of transcript lines in search of the ones I'm
> intereseted for.

Then you might try making the notification conditional.  You might simply be
seeing the results of extensive code reuse.


> > I'm reminded of a time some years ago when OA shipped a database
connection
> > package with a bug in an error handler.  Five minutes after starting my
> > (then not automated) tests, I had it fixed, by doing specifically what
you
> > seem to feel is not possible.  IIRC, OA patched it later that day, but I
was
> > able to do so w/o their involvement.
>
> I don't think that it's impossible to change the code development
> environment doesn't use. There're no problem. But try to change MVP
> part. I'll stuck.

Ok, then explain the existence of Dolphin, or of any Smalltalk IDE.
**Somebody** was able to change the type of code you mention.


> A quote from the site: "It is a highly productive development
> environment targeted at the graphical Visual Basic / C++ / Java
> developer who wishes to adopt a pure approach to object-oriented
> programming." So, I exepect all this to be already present.

Given that Dolphin is very clever with Automation, most things are just a
wizard away, and by deferring that work and code, we have a smaller system
that learns what each developer expects of it.  Ironically, my one complaint
(well, call it a concern) about Dolphin is that it is overly dependent on
Microsoft technologies.

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Andy,

> 2) It is the "Smalltalk way" to write very small methods. This, together
> with the fact that a method compile is virtually instantaneous, means that
> dynamic syntax highlighting is not generally considered important.

One minor comment: compilation errors result in a very bright red color.  I
once patched an image of mine to use the symbol color instead, which still
gave the obvious impression that somethig wasn't right, but was a little
easier to read to find the problem.  I'd really like to see a similar change
in the base system.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Hi Seb...

> please could you explain more about 'Performance is about factor twenty
lower than Java HotSpot'

My current main use of Dolphin is to prototype all sorts of algorithms e.g.
image processing and numerics. The image-based and interpreted apoproach of
Smalltalk is ideal for this. My experience so far is that the average speed
of execution of the algorithms is about twenty times faster when ported to
java (No, I do NOT optimize the Java code and write dumb ST code, but rather
profile the ST code with Ians great Profiler and usually do no more
optimizing on Java side).

The difference is that in Dolphin code is interpreted, while Java compiles
down to native code.

On the other had, most applications do not calculate very much, they do
computational simple tasks or forward complicated ones (like database
queries) but have a lot of GUI to allow the user to operate. Java Swing is
traditionally slow as the entire GUI framework sits on the Java side and
burdens the VM with tons of Objects it has to deal with. In Dolphin, all is
quickly passed down to Windows, so the VM is released of this burden. The
Windows code is native code that is quick but not very clean from the object
oriented viewpoint to say the least. Dolphin does a nice job in hiding the
latter fact from you, the GUI developer, while maintaining the speed of the
native GUI framework. Also, a deployed Dolphin app is very small and needs
no further installations, Java OTOH is quite a fat lady. For this reason it
is the main issue in a court fighting between SUN and Microsoft to forde MS
to deliver the Java runtime with the OS. You donÄt have to care if you use
Dolphin :-).

Due to the Swing slowness, e.g. IBM proposes its native SWT widget library
for some time now, most prominent implementor of this library is IBM's
Eclipse IDE.

 Sidenote: Java is currently fighting not with speed problems, the VM is
actually very fast, but with slowness due to memory management with millions
of Objects on the heap. The VM is very memory intensive and we are dealing a
lot with optimizing garbage collection on bigger projects. We had on 2GHz
systems GC times sometimes exceeding 2 seconds! Garbage collection is great,
but the bookkeeping work it keeps from the programmer has to be done
elsewhere, apparently.

Ciao

...Jochen

Hi Blair...

>I'd be interested in hearing more constructive criticism here. What
specific
>refactoring features does IDEA (and/or Eclipse) have that Dolphin lacks?
>What specific things do you want to do from the keyboard that you can't
>already?

Hum, this simple sounding question is easily spoken out but not so short to
answer.
I though quite a lot of how to answer it in limited space and my conclusion
is that
the answer must be somewhat philosophical. Having said that here is the main
difference
I see between Dolphin ST and the new generation of Java IDEs in the context
of this thread:

Code awareness

This means that IDE's like IDEA are not text editors any more, but
intelligent realtime coding assistants.
I will say IDEA from now on but all major Java IDEs are going in this
direction.
I know that you are thinking in this direction as I read about your AIBO
assistant. However
the IDEA approach is a bit different. To me it was actually a bit of a
surprise that the static typers were first in implementing this
consequently. What is done is that the entire code base (!) is parsed,
analyzed and put into an internal database. This resembles the compilation
process up to just before the code generation step. The old annoying process
to repeatedly compile the text to get feedback is dead here. This gives
first point:
1. Feedback - On each keystroke the IDE deliveres EXACT feedback about the
validity of the code. The IDE show e.g. unused variables, missing methods,
wrong parameters, missing braces, semicolons, unreachable code, etc.
Moreover it shows redundant coding like superfluous casts, calls to
deprecated methods as warnings.
The other point is
2. Assistance - I actually type less and search for information MUCH less in
Java than in any ST environment. The code completion shows me the methods
that are possible in the context under cursor, the assistant generates the
missing method under the cursor. I can generate all sorts of code wrappers
around code I selected and much more. Allowing refactorings is just a small
part of this. Documentation on any method or class can be popped up as a
tooltip. All is possble entirely keyboard driven (usually used) or mouse
controlled (for beginners).

Last but also very important point is
3. Supportive -The IDE is supporting but never controlling you. Contrary to
other IDEs in IDEA all support is on demand, fine grained and suppportive.

Again, this is not written to advertise IDEA (although this one is the best
of it's kind I know), but shows the general tendency of current Java IDEs.

There is much more to be said but the idea is clear I think. Support the
(mostly mechanical) programming process as much as possible and let the user
focus on the actual design problems.

I strongly believe that all surviving programming environments will be
intelligent, code aware systems. Also, I believe that this is in no way
related to the nature of the environment - all developers will like this
kind of support. I agree that for static type languages this is somewhat
more important and probably also easier to implement.

> > I'm not able to see all local values at the same time. No watches.
>Certainly these features would be useful, but they are not essential in the
>way that they are for file-based static languages.

This is absolutely unrelated to the type of environment IMO. When debugging
I always want to see ALL my local and object vars at a glance and not by
iterating through them. It does not occupy more screen space, either.

Regarding breakpoints, the advantage is that this is a managed feature,
while placing salf halt is unmanaged by the system. This kind of management
is shurely better than self coding, especially for the insecure beginner.

Blair, I will take the time to report any info I can give if you ask for it,
as long as it helps to improve Dolphin.


Ciao

...Jochen

Hi,

"Blair McGlashan" <[hidden email]> wrote in message news:<b30da1$1fd90h$[hidden email]>...
Extract temporary in IDEA suggests to change all the expression usages
to the
temporary. I don't need to select anything to perform a rename - just
put a cursor on it. I can't create methods just from usage (I guess
Tools++ does it by I didn't get it to work). I also find it quite
frustrating, that renamings doesn't perform at least small usage
analysis. Create a class and add a _class_ method 'do:'. Try to
rename.

> What specific things do you want to do from the keyboard that you can't
> already?

Main problems are: I can't quickly navigate between classes/methods
without a mouse.

BTW. Have you ever tried syntax-based selection? Just try in IDEA -
Ctrl+W.

Jochen,

"Jochen Riekhof" <[hidden email]> wrote in message news:<[hidden email]>...
> So, to be fair, you should
> mention this when comparing to Dolphin. Ever used Netbeans or JBuilder? ;-).

Never, since IDEA is available. ;)

Steve,

"Steve Waring" <[hidden email]> wrote in message news:<b2v6cl$1gu2br$[hidden email]>...

> For example if you have a Shell, that has a Presenter childComponent, that
> contains the toolbar ... you would add the following method to your Shell;
>
>   MyShell>>addToCommandRoute: route.
>     route
>       appendPresenter: self;
>       appendPresenter: myPresenter.


That helped. Thanks a lot.

> I also have an unreleased wrapping of the tooltip control, which only needed
> one class and a couple of methods to implement.

I've enhanced it a bit. It doesn't require to have a toolbar in the
Shell. As a result, all the initialization can be performed in a View.
I'm trying to extract all the Tooltip stuff into class. Everything is
OK until I'm trying to add the support for "dynamic text". Is there a
way to handle a specific View message from another class?

Andy,

"Andy Bower" <[hidden email]> wrote in message news:<3e53b46c$[hidden email]>...
> mm_aa,
>
> I too am not convinced that you are not just trolling.

It's quite interesting that almost everyone has ignored my "PROS" part
;)


> However, my impression from reading your comments is that you are missing
> one critical thing when comparing Dolphin with various Java incarnations.

It's not suprprising - I'm an active Java developer.

> That is that it is Smalltalk.

I'm not trying to touch languages. I was just trying to use a product:
an IDE + Library + Language implementation.

> 1) It is the "Smalltalk way" to peruse source code to find examples of it's
> use.

Honestly saying, that's the usual excuse of the documentation lack ;)

Andy, imaging the situation: I've convinced to transit the whole team
(say, 10 developers) to Dolphin smalltalk. What should we do? The best
way will be to open the box, get the user manual (or to print a pdf)
and to read about IDE, all details about external interfacing, MVP
framework, OLE support etc. etc. Instead, 10 developers would be
forced to read the source code and try to exchange the information
instead of rapidly creating the software.

[I do know the cases, when documentation is present but is extremely
bad. I'm not talking about this case].


> 2) It is the "Smalltalk way" to write very small methods. This, together
> with the fact that a method compile is virtually instantaneous, means that
> dynamic syntax highlighting is not generally considered important.
> Personally, I've never found a need for it.

That's the reason of IDEA success: none had found a need for
everything it did. But now, every IDEA users is _so_ accustomed that
features... And many IDEs are now copying them.

> Small methods also means that the method editor can be relatively simplistic
> (as it is in Dolphin). When you are editing huge Java class files you may
> need emacs bells and whistles; editing five lines at a time probably not.

BTW, even with small methods I've found it really frustrating not to
have "Undo" working through method code saves.

And what about completion for all that wrappers for external methods?
(whith 5/7 parameters)

> 3) It is the "Smalltalk way" to work inside a "sea of live objects" (the
> image) that contains the development tools along with the source. Providing
> you learn to take care this is virtually never a problem. Yes, you can break
> something by putting breakpoints in key bits of code but just restart and
> remember not to do it again. It has been over a year since I accidentally
> broke an image like this.

I'm breaking it 3 times a day ;)


> 4) It is the "Smalltalk way" to develop inside the debugger while the
> application is running. I've heard that you can (at last) recompile methods
> inside some Javas' debuggers, but can you define new methods (as a result of
> a #doesNotUnderstand: fault) create new classes and refactor the entire
> system?

Nope. But due to static typing I rarely need that.

> I haven't seen it but I suspect not. Certainly in all the Java IDEs
> I've seen (I admit to not having used IDEA - I note it is 150% the price of
> Dolphin Pro) when you are debugging an application you are working on a
> static "dead" thing.

Why? You can look at objects, create new instances, invoke methods,
evaluate expressions, inspect results.

> I'm not sure whether the point of your message is to "bash" Smalltalk or
> Dolphin's implementation of it.

I'm not trying to "bash". I've just forumalated all the things, which
don't allow me to fall into love from the very first sight.

> If it is the former then you should first
> try and understand why many people here believe Smalltalk is so much better
> and productive than other languages like Java.

Currently, I'm being much more productive with Java ;)

"mm_aa" <[hidden email]> wrote in message
news:[hidden email]...
> Hi,
>
> "Blair McGlashan" <[hidden email]> wrote in message
news:<b30da1$1fd90h$[hidden email]>...
> > "Jochen Riekhof" <[hidden email]> wrote in message
> > news:[hidden email]...
> > > ...
> > > I am using IDEA most of my day to work with, and the stunning keyboard
> > > support and refactoring abilities are the best I have ever seen in my
life
> > > (and I am in busibness for quite some years).
> > >....
> >
> > I'd be interested in hearing more constructive criticism here. What
specific
> > refactoring features does IDEA (and/or Eclipse) have that Dolphin lacks?
>
> Extract temporary in IDEA suggests to change all the expression usages
> to the
> temporary.

Strictly speaking that means it is not probably a refactoring, since the
expressions may have side effects. In Java it is presumably possible by
static analysis to determine that a limited range of expressions are safe to
treat as common subexpressions, but in Smalltalk even operations such as '+'
are messages and theoretically can be redefined, so there is not much one
could do to prove that the refactoring is safe. However, I agree with you
that this would be useful, even if it means the result may not be a
behaviour-preserving refactoring. Also the reverse, 'Inline Temporary',
refactoring will happily insert multiple copies of the expression, so that
is not guaranteed behaviour preserving either.

>...I don't need to select anything to perform a rename - just
> put a cursor on it.

A minor issue IMO, but already sorted for the next release.

>...I can't create methods just from usage (I guess
> Tools++ does it by I didn't get it to work).

I don't really understand what you mean by creating methods "from usage".
Can you elaborate please?

>...I also find it quite
> frustrating, that renamings doesn't perform at least small usage
> analysis. Create a class and add a _class_ method 'do:'. Try to
> rename.

As I say, I'm not really sure what you are getting at by "usage" here, but I
would comment that in Smalltalk classes are first class objects, therefore a
method defined on the class side is no different from one on the instance
side. Yes, by convention one tends to use different messages, but not
always, and it is not illegal to polymorphically operate on classes or
instances, since Smalltalk recognises no difference.  In Dolphin we have
scoped renames (and other refactorings) to help out with this sort of thing,
even though this may mean the refactoring does not provably preserve
behaviour. For example we allow the scope of a method rename to be limited
to just the individual method, its immediate class, the class hierarchy, its
owning package, or globally. This doesn't help in all situations, but it is
still very useful in practice.

I'm assuming this your last point must be very significant to you, because
otherwise that list would hardly be sufficient to justify your claim that
the refactoring support in IDEA is really that much better. I was really
looking for a point-by-point comparison as a constructive way to help
improve the product, but it looks like I'll have to do it myself :-).

The refactorings supported by Dolphin are mostly those supported by the
basic Refactory engine, with a few additions. A brief description of the
standard refactorings can be found here:

http://st-www.cs.uiuc.edu/~brant/RefactoringBrowser/Refactorings.html

I'll use the terminology from there in what follows. A significant point
about the Refactoring Engine, is that it is (like everything in the IDE
really) extensible by the user. You an add your own custom refactorings if
you wish, and indeed some people have:

http://wiki.cs.uiuc.edu/CampSmalltalk/Custom+Refactorings+and+Rewrite+Editor
+Usability

Working from http://www.intellij.com/idea/features/features.jsp?part=7, I
identified 9 IDEA refactorings that are apparently not relevant in
Smalltalk, these being Rename Package, Move Package, Move Class (between
packages), Move Static Member, Move Inner (class) to Upper, Extract
Interface, Use Interface Where Possible, Convert Anonymous Class to Inner,
Replace Constructor with Factory Method.

I identified 5 refactorings definitely not supported by Dolphin:

1) Copy/Clone class
2) Introduce Field
3) Extract Superclass
4) Replace Inheritance with Delegation
5) Replace temp with query

[In addition the 'Introduce Constant' refactoring, on the face of it Java
specific, is arguably missing, since I believe there are occassions when one
wants to be able to extract a constant to either a class or pool variable].

Of these, the first is not a refactoring at all. In Dolphin one would
achieve this by saving a class definition, and then a single drag & drop
operation to copy all methods to the new class. Frankly I'm not sure I would
want to encourage this sort of cut and paste coding by making it any easier.

The second is similar in concept to 'Extract Temporary', but to (in
Smalltalk terminology) a class or instance variable. While not as useful as
Extract Temporary, there have been circumstances I can recall where I've
wanted to do just this. However, since Smalltalk doesn't have the concept of
initializers or constructors it might be difficult to implement some of the
possibilities in a correct way. The simplest case of extracting to a new
instance variable with assignment of the value at the extract point seems
fairly straightforward, being effectively an 'Extract to Temporary' followed
by a 'Convert to Instance Variable'. Certainly, worth putting on the list
though.

Extract Superclass would appear to be a composite of 'Create subclass', and
a sequence of 'Pull Up instance/class variable' and 'Push Up method'
refactorings. The only really difficulty with providing this refactoring is
an appropriate UI that allows one to select all the pieces one wants to
extract out. If there were sufficient demand we could consider doing it.

'Replace Inheritance with Delegation' is an interesting one, that needs some
thought. I don't have a particular opinion on its usefulness.

'Replate temp with query' is effectively a repeated sequence of 'Extract
Methods', since after the first 'Extract Method' the refactory engine would
identify and use the same method. It would be nice to automate it, however,
as I do find myself doing this quite a lot.

Now looking at it the other way around, I identified 8 refactorings in
Dolphin that (judging purely from the web page) are not supported by IDEA:

1) (Safe) Remove Variable
2) (Safe) Add Variable
3) Protect/Concrete Variable
4) Convert class to Sibling (not explained on John Brant's page, this
effectively pushes down a superclass to be a sibling of its subclasses all
under a new abstract superclass, leaving all common methods in the new
superclass)
5) Remove Duplicate Methods - Dolphin specific.
6) Inline Parameter
7) Rename Method References - Dolphin specific, and not a behaviour
preserving refactoring. Useful nonetheless.
8) Move to Inner Scope.

'Add Variable' may not be relevant to Java, since it is legal (I think) to
have temps with same names as instance variables, and for subclasses to
define same named instance variables. Even it is legal, this is still a
useful refactoring because inadvertent hiding of a variable by another of
the same name in an inner scope is the source of a significant number of
errors in my experience.

Protect/Concrete Variable is the inverse of Abstract Variable/Encapsulate
field, so I'd be surprised if IDEA really omits that.

I identified a further 4 refactorings that may not be supported in IDEA (I
couldn't tell from reading the Web site):

1) Extract Method to Component - the IDEA Extract Method write up makes no
mention of its ability to extract the method to another class, so I assume
it cannot do this?
2) Inline Method (from Component). The inverse of (1), this allows to inline
implementation from another class.
3) Create Accessors. Since this is a part of Abstract Variable (called
Encapsulate field in IDEA) I imagine this must be supported.
4) Move Method to Component. The IDEA page mentions a Move Members
refactoring, which might well do this, but there is no further information
about it.

In summary, there are some refactorings supported by both environments that
are not supported by the other. In fact there are rather more missing from
IDEA, but its arguable as to which has the more comprehensive refactoring
support. Both support the core refactorings that one uses all the time like
Extract Temporary, and Extract Method (does IDEA support Extract to
Component and the reverse inline, I hope so, because that would be a fairly
major omission if not).

All of this also leaves out the fact that the Refactoring Engine underlying
the bindings in the Dolphin IDE is a powerful and flexible code rewriting
tool that can be scripted to perform custom code rewrites. There is no UI
onto this in Dolphin 5 (there will be in the next release), but the original
Refactoring Browser has one called the Rewrite Tool. Do you have access to
this kind of machinery in IDEA? I couldn't find any mention of it.

>
> > What specific things do you want to do from the keyboard that you can't
> > already?
>
> Main problems are: I can't quickly navigate between classes/methods
> without a mouse.

If you can, please be more specific. What exactly would you like to be able
to do? For example do you want to be able to step between methods in the
method list using single key presses? I really do want to know how people
want to use the IDE.

Incidentally if you have installed PL2, you can easily view a list of all
accelerator keys in the browsers by choosing the 'Key Bindings' command on
the common Help menu.

>
> BTW. Have you ever tried syntax-based selection? Just try in IDEA -
> Ctrl+W.

I read about, and it seems like a neat idea, so I implemented it (see
attached). I've used Ctrl+Y simply because its available and Ctrl+W isn't.
You'll have to open a new browser to get the accelerator recognised. Also
the patch relies on a method installed by PL2. It isn't quite as useful in
D5 as it might be, because it doesn't work in modified source text, but if
in some future version the methods were parsed dynamically...

Regards

Blair

--------------------------------------------------------
!MethodBrowser methodsFor!

expandSourceSelection
 | node |
 node := self selectedNode.
 node isNil
  ifTrue:
   ["Normally we'd just disable the command, but to avoid patch to
#queryCommand: ..."
   Sound warningBeep.
   ^self].
 sourcePresenter selectionRange = node sourceInterval
  ifTrue:
   [node := node parent.
   node isNil
    ifTrue:
     [Sound warningBeep.
     ^self]].
 sourcePresenter selectionRange: node sourceInterval!

additionalAccelerators
 ^#(#(#expandSourceSelection 'Ctrl+Y'))! !
!MethodBrowser categoriesFor: #additionalAccelerators!constants!public! !
!MethodBrowser categoriesFor: #expandSourceSelection!commands!public! !

"mm_aa" <[hidden email]> wrote in message
news:[hidden email]...
[Andy Bower wrote]
> > 2) It is the "Smalltalk way" to write very small methods. This, together
> > with the fact that a method compile is virtually instantaneous, means
that
> > dynamic syntax highlighting is not generally considered important.
> > Personally, I've never found a need for it.
>
> That's the reason of IDEA success: none had found a need for
> everything it did. But now, every IDEA users is _so_ accustomed that
> features... And many IDEs are now copying them.
>
[snip]
>
> > 4) It is the "Smalltalk way" to develop inside the debugger while the
> > application is running. I've heard that you can (at last) recompile
methods
> > inside some Javas' debuggers, but can you define new methods (as a
result of
> > a #doesNotUnderstand: fault) create new classes and refactor the entire
> > system?
>
> Nope. But due to static typing I rarely need that.

Turning your own answer to (2) around, you don't think you need it because
you haven't (apparently) experienced how powerful it is. What Andy is
talking about is much more than just the ability to recover from a missing
method (though you can fail to override things you need to, even with static
typing). Once you get used to the idea of being able to do much more
programming in the debugger, I'd be surprised if you want to lose that
capability either. In Dolphin I can modify the GUI of my application as its
running. I can mess around with the properties of the windows without
closing them to see what happens or how it looks. I can implement it
progressively as I go, without needing to shut it down and lose all the
context I've built up. If I'm about to do something dangerous, I can save
the image and proceed, confident in the knowledge I'll be able to get back
my debugging session exactly as it was before. I can even file in a patch
level and see if it fixes that bug I just spotted in the IDE :-).

>
> > I haven't seen it but I suspect not. Certainly in all the Java IDEs
> > I've seen (I admit to not having used IDEA - I note it is 150% the price
of
> > Dolphin Pro) when you are debugging an application you are working on a
> > static "dead" thing.
>
> Why? You can look at objects, create new instances, invoke methods,
> evaluate expressions, inspect results.

Because at the end of all that, you press 'stop debugging', and it goes back
to being a dead thing. I don't know about you, but when I shut down my
machines, any of them whether desktop of laptop, I always user 'Hibernate',
never 'Shut Down'. When I'm developing, I don't want a distinction between
developing something and running it, I want it live the whole time, even if
this is more dangerous!

[snip]

> > If it is the former then you should first
> > try and understand why many people here believe Smalltalk is so much
better
> > and productive than other languages like Java.
>
> Currently, I'm being much more productive with Java ;)

When one is an expert in something one is not only more productive in it,
but one also tends to tailor ones approach to suit it. In a new environment
one suffers from both inexperience with the new tool, and overspecialisation
with the old.

Regards

Blair