home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / rexx / 886 < prev    next >
Encoding:
Text File  |  1992-09-04  |  1.9 KB  |  43 lines

  1. Newsgroups: comp.lang.rexx
  2. Path: sparky!uunet!wrkgrp!ets
  3. From: ets@wrkgrp.COM (Edward T Spire)
  4. Subject: Re: Blanks, REXX, and portability...
  5. Message-ID: <1992Sep4.154621.2334@wrkgrp.COM>
  6. Organization: The Workstation Group
  7. References: <1992Sep3.003350.1@sejnet.sunet.se>
  8. Date: Fri, 4 Sep 92 15:46:21 GMT
  9. Lines: 32
  10.  
  11. eric@sejnet.sunet.se (Eric Thomas) writes:
  12. : In article <1992Sep2.162052.25264@wrkgrp.COM>, ets@wrkgrp.COM (Edward T Spire) writes:
  13. : > 3.  REXX is used as a macro language for other applications (XEDIT
  14. : > and ISPF come to mind) that have themselves been "ported".  XEDIT macros
  15. : > ported from CMS to Unix port very nicely indeed (since the primary
  16. : > addressible environments are very similar).
  17. : No question here. But wouldn't the unix version of XEDIT exhibit the same kind
  18. : of behaviour as the CMS version? Or does it, too, use tabs in the data returned
  19. : by (say) EXTRACT?
  20.  
  21. Not normally, but if you were editing a makefile that had tabs as part
  22. of the data lines and you extracted a data line...
  23.  
  24. : > 4.  Even if you did need to essentially re-implement a large OS macro
  25. : > on Unix, doing it in REXX again may be your best choice.  You cannot be
  26. : > as productive in C or PERL (unless you code these languages all day
  27. : > long every day, and even then I doubt it...)
  28. : I hope this is a joke. I don't want to make a 300-lines post explaining why
  29. : REXX is unsuitable for large applications, but believe me, you spend more time
  30. : reaching your business goals (especially in the area of performance) than you
  31. : might ever possibly waste rewriting all the REXX library functions in C and
  32. : then keying in the extra keystrokes C requires. Note that I despise C and will
  33. : go a LONG way to avoid having to use it.
  34.  
  35. I am not joking, nor are the other folks who choose this route.
  36. Hardware performance bottlenecks are becoming less important as
  37. price/performance ratios change.  Note that I'm writing this on a
  38. 25 MIP RS/6000 that is essentially a single user system.
  39.  
  40. -Ed
  41.