Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!gatech!newsfeed.internetmci.com!in2.uu.net!news.new-york.net!ritz.mordor.com!jpletzke
From: jpletzke@ritz.mordor.com (Jonathan Pletzke)
Subject: Re: Unhappy Smalltalk Users
X-Newsreader: TIN [UNIX 1.3 950824BETA PL0]
Lines: 75
Organization: Mordor International
Message-ID: <DLLJ23.FFn@ritz.mordor.com>
References: <4e02qn$9v4@bigjohn.bmi.net>
Date: Mon, 22 Jan 1996 18:51:39 GMT

Frank Skorina (skorina@bmi.com) wrote:
: We are considering abandoning Smalltalk.

Oh no! 

: 1) Smalltalk is slow.  We have optimized screen loading so the GUI response is adequate.  Using 
: and manipulating images (bitmaps) crawl in our present implementation.
Compared to what?  I must agree that in terms of primitive graphics 
behavior, Smalltalk can be slow.  But the tradeoff is in terms of a 
faster to develop application (the very complex GUI behavior is IMHO much 
harder to do in C/C++ )

: 2) Since the application controls hardware, we are forced to write DLLs (in C) to interface to 
: the drivers.  We have also written DLLs for some image processing and other math intensive 
: modules.  This has forced us to maintain two environments.
Most projects that I work on involve a heterogeneous development 
environment.  It does create additional angst, but is the direction that 
the industry is taking.  With the advancement of "Component Software" the 
headaches may be reduced but it will still be the right tool (language) 
for the problem.

: 
: 3) We have been using Smalltalk and PARTS from Digitalk and have found them (especially the 
: latter) to contain numerous bugs.
Yes. I find much software to contain bugs (even Windows! ;) ) but these 
are annoying.
 
: 4) We have difficulty using the Enterprise system, both in managing the code and and navigating 
: through its less than stellar interface.
Nail on the head?  Imagine how hard it would have been without it!  I 
believe that management tools for software development can really mature 
to enhance the development process and that were at a primitive state.  
C/C++ programmers are faced with the same type of problems in source code 
management and cant customize their tools as easily.

: 5) The Smalltalk documentation is poor.
It's tough to write documentation that addresses this newer organization 
of information.  Since the syntax can be summarized in a few pages 
(unlike other languages that take a whole volume) the focus is then on 
the libraries and how to present them.  Most of the time the only 
documentation is the class source code, or an example if you're lucky!

: 6) Our documentation of what we developed is poor.  This is our own fault and the cause of some, 
: but not all of our problems.
Without a good pattern for Smalltalk documentation to follow, it's no 
surprise.  There are documentation tools available now (i.e. Synopsis for 
STV ) that improve this process.

To answer the implied question of whether you should continue to develop 
in Smalltalk and whether it may have been a mistake:
1. Did you pick the right tool?  Hard to answer with the level of detail 
presented in your posting.  If the bulk of your code is outside ST, and 
you are not building a re-useable, evolutionary system that needs direct 
memory addressing and the maximum percentage of CPU utilization for 
calculation, then Smalltalk is not the right choice.

2. You state that you were learning Smalltalk as you developed. Did you 
develop the application once, and how did the changes affect the 
application?  Would a major re-architecting resolve the problems?  What 
about the hardware platform being used?  Have you tested a deployment 
image versus a development image?

3. Most problems that I've encountered in all development have to do with 
the process.  How do you feel about the process that brought you to where 
you are today?  If the process is at fault, perhaps a different process 
can resolve problems?

I came into a project similar to yours (yet different) where the right 
application of knowledge improved system performance significantly.

More details would assist in understanding the situation.

-Jonathan Pletzke
President
The Technical Expertise Corporation
