Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!ix.netcom.com!netcom.com!jnedzel
From: jnedzel@netcom.com (Gared Nedzel)
Subject: Re: smalltalk performance in data intensive application
Message-ID: <jnedzelD09IFo.nE@netcom.com>
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
References: <carlmD0485s.4n6@netcom.com>
Date: Sun, 4 Dec 1994 01:21:24 GMT
Lines: 59

In article <carlmD0485s.4n6@netcom.com> carlm@netcom.com (Carl Margolis) writes:
>My situation is this:
>        I have been charged by my corporate taskmasters with building a 
>Query/EIS/DSS/etc. tool in no time for no money for sale to their current 
>client list which includes Disney's, Macy's, Sears, and other large retailers. 

Fun.

>Their current transactional systems are all mainframe based. I have been 
>programming in ASM/C/C++ for 14 years. I have a team of 3-4 programmers with 
>1-4 years experience. I'm strongly considering going to smalltalk for this 
>project but I'm worried about smalltalk's performance in applications which 
>require intensive data manipulation of very large data sets. In particular, 
>the kind of multi-dimensional data cube manipulation ("slicing & dicing",etc) 
>have got me worried. I find it hard to believe that a link-list or b-tree 
>collection will provide near the performance I can get out of C/C++. I know I 
>can build a hybrid system but this is not nearly as re-usuable or maintainable.
>        I'm also concerned about the SQL - OO mapping problem. There are now a 
>number of solutions just available but I don't know much about the smalltalk 
>products in this area. I don't mean just putting SQL behind a control but a 
>real engine which will build high quality SQL on the fly as the user 
>manipulates the product.

You should be concerned.  The impedence mismatch is very real.

>        Currently we're assuming a Windows 3.1 client talking to a variety of 
>Unix back-end. Any advice people have about the various commercial smalltalks 
>would be greatly appreciated. We're currently interested in Digi-talk, IBM, 
>Enfin from Easel, and H.P.'s version of ParcPlace. 

In terms of speed, the ParcPlace and Digitalk engines are the fastest.  HP
Distributed smalltalk adds some really elegant distribution capabilities. If
you don't need the CORBA stuff, though, plain old ParcPlace will do just fine.
In terms of helping with the impedence mismatch, ParcPlace's Datalens is so
limited that it's essentially useless;  Easel's Synchronicity is far more 
powerful.  Unfortunately, Easel's smalltalk engine is relatively slow and 
somewhat buggy.

ParcPlace's engine is fast, but VisualWorks (their GUI builder) is very hard
to learn.  Digitalk has a nice engine, but their Parts GUI builder tends
to make you develop two layer applications (GUI and database), rather than
the more flexible multi-layer applications (GUI, model, access, database)
that you went to Smalltalk in the first place for...


IBM is giving away VisualAge to large mainframe sites, but it is still rather
young.  It requires 24Mb for development machines and is rather slow.  However,
IBM is putting a huge amount of resources behind it.  IBM will be a player,
but it just isn't clear quite when...

Don't underestimate the learing curve.  Smalltalk itself is quite easy to 
learn, but it takes quite a while to learn to think in objects.


>        Carl Margolis

Best of luck....


