cgi and forth cgi and forth antypaladin (MIS) (OP) 14 Nov 07 03:14 anyone got cgi working with forth?forth seems ideal because cgi always has problems with too little memory on the computer, and forth uses little to get work done... RE: cgi and forth MikeHalloran (TechnicalUser) 26 Nov 07 15:15 I had to look up "cgi", but I remember a little about FORTH.FORTH uses little code space for executables, and grows slowly with program size, mostly because of intensive re-use of tiny atomic functions.I'd imagine that cgi would have memory problems because of the requirement to process, store, and cache, large numbers of long strings.If I'm understanding the problem correctly, I don't think FORTH would bring much to the party, because the strings would still be long and numerous. Reducing the size of the code to zero (which is effectively what FORTH does relative to equivalent current scripting languages), would just free up that much memory.Or, I could be wrong; it happens regularly. RE: cgi and forth antypaladin (MIS) (OP) 26 Nov 07 19:58 Interesting; has anyone ever tried to reduce the strings? say numbering words from 1 to 10,000 and replacing all the words with numbers the machine can easily deal with. Then having the client cache this mapping, then letting the machine be blindingly fast...?? (theory heavy here) RE: cgi and forth MikeHalloran (TechnicalUser) 11 Dec 07 23:13 You could compress the strings, but you'd pay heavily in execution time for decompression for all but the simplest compression, e.g. run length encoding.You'd lose more speed by doing it in FORTH; most dialects are slower at run-time than the binaries produced by a C compiler. The speed penalty comes from the tiny tight loop that's responsible for much of FORTH's power and code density; the inner interpreter.