ZIM vs PROGRESS

Tom Betz tbetz at dasys1.UUCP
Fri Jun 24 05:24:23 AEST 1988


x
     In evaluating 4GL/RDBMS products available for Xenix 386, with an 
 aim of using one of these to develop an order proccessing/inventory 
 management/production database system, I've come down to a choice 
 between Zim and Progress...  and right now I'm leaning toward Zim, for 
 several reasons:  
 
     1:  Zim has a richer set of built-in mathematical functions, while 
 retaining all the capabilities of Progress.  
 
     2: Zim's set- and entity-based approach (including ROLES, a sort 
 of aliasing) appeals to my sense of how a business is actually 
 structured.  I do feel a bit of discomfort at letting go of arrays, 
 since Zim does not employ them, but I also feel that the power offered 
 by set handling will easily offset this.
 
     3:  Zim's self-documentation features far outstrip Progress's.  
 One example - when one adds or deletes a field from a file, one needs 
 must recompile any compiled procedures using that file.  Zim is kind 
 enough to tell you which procedures need to be recompiled, so you are 
 less likely to miss one.  This could save a lot of grief in an OLTP 
 system!
 
     4: Progress automatically compiles every procedure before running 
 it, while Zim permits considerable debugging in an interpreter, then 
 lets the user decide when it's time to compile.  Zim even permits 
 compiled procedures to call uncompiled procedures, and vice-versa!  
 Zim's approach, while offering considerable power to the user, also 
 leaves itself open to some hazards (if the interpreted procedure 
 happens to return something the procedure calling it doesn't 
 anticipate) but I think the power it offers is well worth the 
 tradeoff.
 
     These are just a few of the points I have observed in a couple 
 weeks' part-time exploration of these two packages.
 
     I would very much appreciate comments from anyone who has used 
 either or both of these packages regarding points I may have missed or 
 should look out for... also from partisans of other 4GL packages that 
 can offer reasons why I'm missing the boat here.
 
     As usual, if sufficient response is generated, I will summarize to 
 the Net.
  
 
     

-- 
Tom Betz                      
ZCNY                               {bellcore,cmcl2}!cucard!dasys1!tbetz
Yonkers, NY, USA 10701-2509                    
"Opinions? What opinions? These are >facts<!!"



More information about the Comp.unix.questions mailing list