On Mon, 13 Sep 1993 08:06:21 PDT Dave Gomberg <[log in to unmask]> said: >Gee, is that your entire gripe list? No, just the most obvious things. I run a number of lists for Swedish professors. When setting up one of them, I deleted the line with the "Default-Options=" keyword by mistake. The owner pointed this problem out to me and I updated the list header and issued the usual QUIET SET ... FOR *@*. After 30 seconds the command had still not completed, so I logged on to LISTSERV and typed TS (I'm beta-testing 1.8a as you know). It didn't look like it was in a loop. Strange. I checked LISTSERV 191 from another account, and saw the list had almost a thousand subscribers (since I had created it 2 days before, I had assumed it would be almost empty). Ah well, SET EXECTRAC OFF and I waited. After 5 minutes it still had not completed, so I rebooted LISTSERV and decided I'd just have to do this at 3am, or better yet, wait until the weekend when I normally update the production system with new code, since SET has been rewritten to PASCAL recently. The PASCAL version ate 3 seconds of CPU time for the same thing, mostly because it sent me 941 messages (I stupidly asked for interactive reply). Now, obviously compiled PASCAL code is faster than REXX, and SEARN is a very slow machine, but that doesn't explain the difference. There is a lot of I/O to be done, and system calls that will take the same time no matter the language. In addition, all the parsing work was already in PASCAL (ie the interpreter didn't have to run through 50-lines SELECT statements with ABBREV calls for each subscriber). The problem is that the REXX code generally has to use o(n2) algorithms because there is no pointer, no way to explore a stem after setting it, and so on. The mistake is to use REXX for a large application. It is an excellent language for self-contained applications, and the best procedural ("shell" in unix terms) language I know. But it just isn't suited to anything that spans more than a handful of source files, or that is longer than a few thousand lines. >BTW, the passing of stems is now addressed in the draft standard, so I >expect there will be little to fear on that subject. As usual, this is too little, too late. By the time the standard passes, the generally adopted procedural language will be BASIC, because that is what Microsoft is pushing and IBM is doing its best to make sure REXX gets as little exposure as possible, and nobody will care. Let's face it, most people, at least on BITNET for which I have statistics, are still using CMS release 5 (5.x comes second and 8 is third). CMS 10 finally introduces support for stream I/O, but without RECFM F files, heck, why should we support RECFM F files? We will have to wait for CMS 11 for this. By the time all that stuff comes out, LISTSERV will have been entirely rewritten in PASCAL and I won't have to explain that I am not going to use the new REXX features because 95% of the installed base does not support it - it will all have become irrelevant. The world is the way it is, and there are mistakes it just doesn't tolerate; this is a perfect example. Eric