Re: break into Smalltalk?

Nevin Pratt <[hidden email]> wrote in message
news:[hidden email]...
...
> I think Squeak, Dolphin, and SmallScript have promise, but right now in
> my opinion, VA and VW are the only games in town.  I think Dolphin is
> cheap enough, though, that it doesn't hurt to buy a license just to play
> with it (I did), but I personally don't know anybody that is currently
> gainfully employed with it, although I would like to hear from people
> who are.  Same goes for Squeak-- in many ways it is best-of-breed, and
> in the areas that it is not, it is rapidly developing into
> best-of-breed.  But nobody that I know is currently using it
> commercially (I'd sure like to see that change, though).
...

I would like to think that I am gainfully employed using Dolphin, and I know
a few other people who are as well.  I think that Dolphin tends to be used
on smaller projects consisting of a few developers rather than large
projects with many developers.  Dolphin is an excellent choice for small to
medium Windows only projects.  You don't have as much multi-OS abstraction
as some environments have (which can be a burden if you don't need it).  The
licensing is straightforward and affordable for small companies or even
individuals.  It also has a very nice development UI.  We have a very active
user community.  The Object-Arts developers are very attentive to the needs
of their users.  I can suggest improvements to Dolphin, and often actually
see my suggestions implemented in the next version.  These days we also have
some nice add-ons that can be purchased from third parties.  David Gorisek's
STS program ( http://www.gorisek.com/ ) adds features to improve multi-user
development with version control.  Solutions Software's ReStore
 http://www.solutionsoft.pwp.blueyonder.co.uk/restore_main.htm ) is a very
cool Object relational database framework that I am currently having some
fun with.  For what I am doing I think Dolphin is a great place to be.  I
used to use IBM VAST, I looked at VisualWorks, but I chose Dolphin
Smalltalk.  There may not be a large market for Dolphin developers at the
moment, but there are definitely people earning a living with it.

Chris Demers

Well, might you tell us a bit about who is doing what with it, Financial,
Medical/Imaging, TelCo, Trading?  What is Dolphin being used for with
small groups?  And how are the addons helping folks other than being
neat and cool?  Is it OK to assume that http://www.mitchellscientific.com/
is
using Dolphin for its internal, and external work/contracts/projects?  How
long, and what kind of delivery scheduling problems (good or bad) have
occured (good meaning before expected of course).  Your elaboration on this
idea that Dolphin is a viable small to medium sized project tool is greatly
appreciated.

\t

Christopher J. Demers <[hidden email]> wrote in message
news:9k4g1v$2kpap$[hidden email]... know
> a few other people who are as well.  I think that Dolphin tends to be used
> on smaller projects consisting of a few developers rather than large
> projects with many developers.  Dolphin is an excellent choice for small
to
> medium Windows only projects.  You don't have as much multi-OS abstraction
> as some environments have (which can be a burden if you don't need it).
The
> licensing is straightforward and affordable for small companies or even
> individuals.  It also has a very nice development UI.  We have a very
active
> user community.  The Object-Arts developers are very attentive to the
needs
> of their users.  I can suggest improvements to Dolphin, and often actually
> see my suggestions implemented in the next version.  These days we also
have
> some nice add-ons that can be purchased from third parties.  David
Gorisek's
> STS program ( http://www.gorisek.com/ ) adds features to improve
multi-user

Todd Nathan <[hidden email]> wrote in message
news:4ft97.6$[hidden email]...
> Well, might you tell us a bit about who is doing what with it, Financial,
> Medical/Imaging, TelCo, Trading?  What is Dolphin being used for with
> small groups?  And how are the addons helping folks other than being
> neat and cool?  Is it OK to assume that http://www.mitchellscientific.com/
> is
> using Dolphin for its internal, and external work/contracts/projects?  How
> long, and what kind of delivery scheduling problems (good or bad) have
> occured (good meaning before expected of course).  Your elaboration on
this
> idea that Dolphin is a viable small to medium sized project tool is
greatly
> appreciated.

We (at Mitchell) are currently using Dolphin to do a rewrite of our air
emission modeling application, it was originally developed in Actor (an old
Smalltalk like language).  That project is being developed and has not been
released yet.  We have developed some custom software for clients in
Dolphin.  We have been able to deliver on time.  The deployment process in
Dolphin is fairly straight forward.  This was not so in VSE or VAST.  I can
remember a time when I was pulling my hair out trying to get the right
combination of SLL's required by a VSE application, fortunately that is not
an issue with Dolphin.  I even had trouble deploying an IBM VAST
application,  the stripper kept stripping my application, it also took a
long time (>30 min) to strip so I could not experiment very easily.  Dolphin
strips relatively quickly so even if there is a problem I can fix it and
restrip easily.

We started out using VSE 6 years ago.  When PP-D ran it into the ground we
moved to IBM VAST.  I generally liked VAST, but it added a bit of complexity
over VSE.  I evaluated Dolphin about a year ago and decided to move.  We had
developed quite a bit of experimental prototype (concept demonstration)
software in VSE and VAST, but not actual products.  I really liked the
Dolphin IDE (it was much nicer than VAST's at the time, version 4.0 I
think), and the system had seemed smaller and more elegant for our needs.

The tools (included and third-party) available in any programming
environment  can be an important productivity factor.  I mentioned some of
the tools I am using as an example of what is out there for Dolphin.  I can
elaborate on the tools I mentioned, however a more through description is
available at the URLs I included in my previous post.  STS assists multiple
user development by providing version control in a central OODB source
repository.  This was a feature that was not available in Dolphin for quite
a while.  STS actually makes it manageable to have multiple developers using
Dolphin.  ReStore is an object to relational database persistence tool.  It
provides an almost seamless way of interfacing with relational databases.
It actually creates the database structure based on your object structure
(so it is not really intended for legacy systems).

I think that Smalltalk in general is fun to work with.  You code your
objects and as you are working with them you can see them come alive.  I
think Dolphin is especially fun to work with, in that it makes most
programming tasks easy.  The syntax highlighted code is easy on the eyes,
and there are powerful context menus in all the right places.

No Dolphin is not perfect.  I think the UI (MVP) builder could be improved.
It took some time and experience before I started becoming comfortable with
MVP.  Some of the UI tools seem a bit primitive given the advanced nature of
the rest of the Dolphin IDE.  However I have seen Dolphin evolve quite a
bit, and it just keeps getting better.  I believe that its few weak areas
will continue to improve.  Even as it stands now I still think it is a great
environment for some kinds of projects when you know how to use it.

Chris

> > I think Squeak, Dolphin, and SmallScript have promise, but right now in
> > my opinion, VA and VW are the only games in town.

Squeak has has some problems which result from its roots in Smalltalk-80 and
the fact that Squeak Central didn't see them as serious compared with
missing features.  With that said, there are at least two independent
efforts to "fix" Squeak, and I think they will succeed.  Whether or not
Squeak Central will fold the changes into the official product remains to be
seen.  Worst case (well, other than Alan Kay telling us to switch to C#<g>),
SC will continue to create interesting things, and the other projects (which
would ideally merge if possible) would pick up new features as time allows.
I could be wrong, but, I think we're seeing another Linux in the making.

What about MT?  I haven't looked at it for a long time - Dolphin was a lot
nicer in the early days of both products, and since then,  I've been too
busy using Dolphin to re-evaluate MT.  I make time for looking at Squeak
because of its ability to run on Linux.  Still, for new projects, I think MT
should at least be considered.

I have reservations about VW due to licensing issues.  IMHO, it would make
sense for heavily funded quick projects that will never make a dime;
otherwise, I'd find another platform.


> > I think Dolphin is
> > cheap enough, though, that it doesn't hurt to buy a license just to play
> > with it (I did), but I personally don't know anybody that is currently
> > gainfully employed with it, although I would like to hear from people
> > who are.

I pretty much qualify.  Whether it's to create or support custom software,
or to analyze data captured at least in part with something I wrote in
Dolphin, I spend a lot of time looking at Dolphin's debugger :)



> Well, might you tell us a bit about who is doing what with it, Financial,
> Medical/Imaging, TelCo, Trading? '

Primarily medical, though that doesn't really say what we're doing with it.
We deliver active web content (with various security measures), including OR
schedules, patient records, and we've done some electronic signatures at
various points.  There are a couple of small/supporting things coded in C++,
but, otherwise it's all Dolphin.

We have a Dolphin client-server app that's used to track patients in one of
clinics, and we're working to wire another clinic.  The second clinic will
add some new features and will generate a part of the patient's medical
record from the events that occured.

Perhaps the most significant app is my automated recordkeeper.  This is
hardly a new idea, companies have been going out of business for years
trying to sell them.  Anesthesiologists are more active in surgery than you
might expect, at least for highly invasive procedures and/or with very sick
patients.  The only legal protection they have is a record showing vital
signs, drugs and fluids they gave, and terse but detailed notes about what
happened during the surgery.  In addition to being useful for any future
surgery the patient might need, the record shows that the anesthesiologist
was responding to problems.

Electronic recordkeepers ideally reduce an anesthesiologist's workload by
automatically gathering and charting all of the physiologic data.  The
patient wins too, becasue the physican isn't as distracted with
recordkeeping, and future physicians can actually read the resulting record.
The catch is that the environment is crowded because the recordkeeper has to
compete with monitors, ventilators, defibrillators, pumps, ultrasound
machines, etc., and it has to be really easy to use because the
physician/user is busy with the patient, the surgeons, nurses, and all that
other equipment.  Worse, many would-be users take the attitude that "paper
is cheap, and the drug reps give us pens for free".  Obvioulsy they don't
all view it that way, or I wouldn't be writing this having built one of
these things that gets used.

At this point, we've been putting electronic anesthetic records in patient
charts for over a year, and have (IIRC) roughly 350 of them.  During that
year, we've gone from one OR to two, to "two and half" and now we're at
three with a fourth in the works.  Records are accumlating much faster now
than in the beginning.

Technolgically, the recordkeeper has two very different subsystems.  The
user's view of it is a shotgun wedding between a spreadsheet and a database
with some graphics and a (very) little PDA/wordprocessing capability.  It
also does a lot of serial communications to acquire data from multiple
physiologic monitors.


> And how are the addons helping folks other than being
> neat and cool?

I owe Ian just over two weeks for all the time his chunk browser has saved
me.  His profiler has helped me improve performance.  I use "forked"
versions of his serial communications and DI bitmap packages; the reasons
for the forks are long since forgotten, but, everything works.  SuiteBuilder
helps me get consistent builds of my apps, though Lagoon now includes the
most essential features, except for sequencing multiple deployments.
Migrate helps me get my myriad packages and loose methods out of one image
and into the next.  QuickCode saves me a lot of time hunting down important
but rarely used expressions, as well as things that I use every day.


> Your elaboration on this
> idea that Dolphin is a viable small to medium sized project tool is
greatly
> appreciated.

I'd even go so far as to say it's good for large projects; the difference
being that I don't (usually) have much help.  When I do, I typically seal
off an image and give it to a graduate student with a mission to enhance or
add something.  When they're done, I take one last look (it wouldn't be the
first) and then file their work into my image after making a backup.  The
student then gets a copy of the new image and new project.  Ok, a VCS would
be useful, except that I don't have sufficient need for the technology to
risk misapplying it, and this approach allows me to do whatever I need to
anything anytime and then reconcile the student's work with it later.


> I think that Smalltalk in general is fun to work with.  You code your
> objects and as you are working with them you can see them come alive.  I
> think Dolphin is especially fun to work with, in that it makes most
> programming tasks easy.  The syntax highlighted code is easy on the eyes,
> and there are powerful context menus in all the right places.

Seconded.  The Dolphin IDE is excellent.


> No Dolphin is not perfect.  I think the UI (MVP) builder could be
improved.
> It took some time and experience before I started becoming comfortable
with
> MVP.

It's funny, because having climbed the learning curve, I can't understand
what was so hard about it.  The fact that choice presenters didn't have
search policies (they were identity gizmos) was a big part of it.  Before
that, long-since-squashed bugs in the event system didn't help, and
EndPaint() calls were not ensured, so exceptions in paint code were pretty
much fatal - that's fixed, though paint bugs can still become recursive w/o
too much trouble (that's a consequence of debugging inside a windowed
environment).

My wish list of MVP includes everything you see in my PaneHolders package,
only done well :)   There needs to be an easy way to create dynamic user
interfaces involving arbitrary presenters.  Beyond that, there also needs to
be a slick framework for emulated widgets.  What???  EMULATE?????  Yup.  The
native stuff is just too darned slow when the widget counts go up.  Users
(at least my users) don't care that things don't look exactly like the
native widgets; they do demand rapid responses.  Every time I've added
emulation, they've gotten happier.


> Some of the UI tools seem a bit primitive given the advanced nature of
> the rest of the Dolphin IDE.  However I have seen Dolphin evolve quite a
> bit, and it just keeps getting better.  I believe that its few weak areas
> will continue to improve.  Even as it stands now I still think it is a
great
> environment for some kinds of projects when you know how to use it.

My hunch is that most things can be done in Dolphin.  There's no framework
for OLE compound documents; I'd start with server items, as they are easier
to write (so more of us would be likely to write them) and containers (Word,
Excel, Access) already exist.  The container framework would be a lot more
work as I recall.  Is it possible/legal to write containers that don't
support in-place activation of servers?  If so, that might be a good second
(and perhaps near-final?) goal for compound documents.

Overlapped calls go a long way to address making calls on OS threads.
There's still a weakness with COM, though Blair was starting to suggest that
it might be possible to guarantee the OS thread to be used and make that
work.  That would be a great enhancement.  Once Dolphin can protect itself
against the temporal tantrums of external components, then it can (and
perhaps should) wait on becoming truly multi-threaded at the OS level.

A generational GC should be added to the Dolphin VM.

Dolphin needs a really good printing framework.  Some things can be done by
scripting Word, but, that assumes that it is installed, and will not solve
all problems, nor will it necessarily guarantee the appearance of the
hardcopy.

Support for CORBA would be nice.  Davorin convinced me a long time ago that
building the whole ORB is the way to go.  His argument is only strengthened
by Xerox's apparently softening support for ILU.  CORBA support is not
something that I expect OA to build.

Have a good one,

Bill

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