Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!gatech!newsfeed.internetmci.com!in2.uu.net!usc!sdd.hp.com!news.cs.indiana.edu!umn.edu!dialup-12-b-30
From: jhgreve@epx.cis.umn.edu (John Greve)
Subject: Re: Unhappy Smalltalk Users
Message-ID: <DLoDrp.K2K@news.cis.umn.edu>
Sender: news@news.cis.umn.edu (Usenet News Administration)
Nntp-Posting-Host: dialup-10-a-14.gw.umn.edu
Organization: University of Minnesota, Twin Cities
References: <4e02qn$9v4@bigjohn.bmi.net>
Date: Wed, 24 Jan 1996 06:55:56 GMT
Lines: 88

In article <4e02qn$9v4@bigjohn.bmi.net>,
   Frank Skorina <skorina@bmi.com> wrote (in a somewhat different order):

>This post is to solicit opinions on our situation, especially from people who 
>have developed applications similar to our own.
2 general things on the food-for-thought list.
	1) A Microsoft book (Shipping Quality Software?) raised the point that
	it is silly to work in a bad environment.  Then the author raised a
	question to the effect of "If your current situation isn't bad enough
	to leave, ask yourself how much worse it would have to get."
	How much worse would the current situation have to get before you 
	abandon it for something different?

	2) What other direction can you go? C++? Visual Basic?
	What other environments would be more immune to the ills
	befalling the current implementation?

Now for the problems, here's what comes to mind (they came to mind
in a different order - sorry for the shuffling):

>Our problems are numerous.
>3) We have been using Smalltalk and PARTS from Digitalk and have found
>them (especially the latter) to contain numerous bugs.
This means Windows.  Windows 3.1 perchance?
I hear OS/2 is better at multitasking than Windows 3.x, and I haven't
heard much about Win95.  Windows NT is also better at multitasking than
Windows whatever.
A few possiblities here:
	1) mass market app, must develop for windows
	2) limited/custom app, can run on any platform.
	3) special hardware only comes w/Windows drivers.
	Windows is not my first choice when looking for high
	performance real time systems (as opposed to embedded
	systems).
Does the kind of system you run on matter?
Yes, windows boxes are the cheapest cpu, pound for pound.
So I don't know what kinds of budgets you have to work with.


>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.
Is the application doing image processing?
Or do the bitmaps handle state feedback to the user?
(Is your machine well stocked for RAM?)

>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.
Hmm... its hard to offer ideas about how to improve DLL throughput.
Give the DLL more responsibility for maintaining device state?
Send it change messages, or reset, or whatever.
What about a little 3-tier client server here?
	GUI <---> DRIVER/DLL <---> DEVICE
I need to know more about the device's control protocol before
speculating about this.


>4) We have difficulty using the Enterprise system, both in managing the code 
>and and navigating through its less than stellar interface.
Where do the "devices" live? Are they local on the same CPU bus?
Out across a network somwehre?
I have no idea what the Enterprise system, but it evokes a mental
image of LAN/WAN things.

>5) The Smalltalk documentation is poor.
My weak link here is achieving a clear mental vision of the class libraries.
I still havent decided if its due to lame documentation or human bandwidth.

>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.
I have done this.  The project I'm working on now has received
some of the most serious design I've ever been involved with.
Early on it really annoyed the managers to have weeks go by and no
tangible results appear (eventually they forgot about this and
drifted away to other crisis).  But the design has paid huge dividends
in terms of surviving the implementation.  I hope the maintenance people
appreciate the work some time down the road after I'm just a memory.

Some of the implementation constraints I work on with software systems are
laughable - "No, really: we need it to run in Dos, Windows, OS/2, and Unix".
You cna't exploit strengths of any one systems when it has to across every 
one.


John Greve
jhgreve@epx.cis.umn.edu
