I've been asked to look into a legacy Smalltalk app in our group.  I
know
nothing about Smalltalk other than that its a OO language with english
like syntax.  My background is Systems Engineering with some sofware
development experience, but mostly integration.

My original take on this project was to get it converted into C++ or
java
and go from there with our in-house expertise in these languages.
Another reason is that we pay a yearly develpment license for
Smalltalk which is
not exactly cheap (in terms of our group's budget).

The other option it to come to speed on Smalltalk.

So my question is given the proliferation of C++ and java, do I want
to spend
the next 6months learning Smalltalk to some level of proficiency and
making
a (temp) career move into this ie. Is it worth it for me, as opposed
to just the technical merit of Smalltalk vs C++.

Any responses appreciated,
Gurvinder.

Understanding that I (and probably most others on this newsgroup) have a
very pro-Smalltalk bias, I'll try to give you as objective an answer as
I can.

The feasibility of converting any software package from one language to
another clearly depends on the size and complexity of the package. In
general, conversion to another language is a difficult project and
requires good knowledge of both languages.  Simply re-writing from
scratch is sometimes easier.

Converting from Smalltalk to C++ is complicated by C++'s lack of a
garbage collector.  You'll find that Smalltalk applications generally
depend heavily on the garbage collector.

Converting from Smalltalk to either C++ or Java would run into static
type declarations.  Smalltalk has no static type declarations permitting
all variables to be dynamically typed instead.  Java and C++ require
type declarations on all variables.

This can be a valid consideration.  Which dialect of Smalltalk do you
use?  Your vendor may be able to offer better options for your project.
  Contact your sales rep.

In my experience, the speed of Smalltalk is the least of your worries.
There's a perception that Smalltalk is slow compared to C++ or Java.
This is unfounded for the most part.  If you have algorithms that do
heavy floating point calculations or bit manipulations, it may be slower
than C++. I wrote a Smalltalk ray-tracer (graphics renderer) which was 5
times slower than POV-Ray (a C ray-tracer with heavy optimization).

I have (on several occasions) written performance critical sections of a
system in C and interfaced to it from Smalltalk.  This is an effective
solution even if the C code is harder to maintain than the Smalltalk
code.  Smalltalk development tools are far superior to those in any
other language (no exageration).

For normal business processing, however, Smalltalk is very close in
speed to C++.

Ultimately, you are the only one who can make that choice.  I would
suggest that learning Smalltalk would be a valuable investment even if
it was only to improve your programming techniques in other languages.
If it's any re-assurance, we are seeing a re-bound in Smalltalk
popularity recently and I expect that to continue.  At our shop, I tell
managers that we don't need to hire someone with Smalltalk skills - just
someone with programming skills. Smalltalk is quite easy for us to teach
to a new person. You situation may differ.

I generally find that converting large amounts of software from one
language to another is a waste of time.  It's more cost effective to
maintain it in the original language than to try porting or re-writing it.

I'm not worried about the future of Smalltalk at this point (a few years
ago was a different story).

David Buck
Simberon Inc.
www.simberon.com

Hi:
<bias>
Come up to speed in Smalltalk.  Then you will be able to be 3 to 5
times as productive as your Java colleagues.
</bias>

--
Thanks!!
Joseph Bacanskas [|]
--- I use Smalltalk.  My amp goes to eleven.

I would not normally advise spending much time on a legacy
application. Typical factors to consider would normally include
quality/quantity of the design, test, validation, source code
documentation etc. is there much evidence of continous use of standard
design methodology and source code change control throughout the life
cycle?

Typical indicators of potential difficulties expected in rapid
application development may be incomplete/inconsistent documentation,
poor source code management, methods too long, classes with large
numbers of instance variables, copies of classes into subclasses, no
evidence of refactoring (ie of RefactoringBrowser) or storage in long
lived system like SourceSafe for easy retrieval by anybody...

David

David Buck schrieb:

I would like to underline this. Most business applications wait for the user
most of the time. It's not really important how fast they do that...

What are your experiences here?
A) with the managers
B) with people hired without Smalltalk skills?

I often hear of people quite unwilling to learn Smalltalk as they think of it
as being legacy, outdated, kinda the COBOL of the nineties ;-)

Unfortunately, many companies tried to do exactly this. They planned to go
away from Smalltalk to Java. Many of them just bought the latest versions of
their Smalltalk IDE lately as the results of their porting efforts were
A) expensive
B) unmaintainable
C) unusable

I see it simirlar, though the situation still needs to improve.
joe