Some people, it must be said, dislike Lisp. Even to experienced (non-Lisp) programmers, the language looks like a tangled mess of brackets with the occasional word thrown in, in what seems like an unsuccessful attempt to keep the brackets from getting too close together. This initial visual lack of appeal, combined with the paradigm shift from procedural to functional languages makes many people reticent to learn Lisp. This is not an insurmountable problem.
When Lisp interpreters read a line of code, they translate this into an internal 'byte-compiled' representation that consists of a prefix notation evaluation tree, or a postfix notation evaluation stack. This is typical of how multi-platform compilers generate intermediate code before generating assembler or machine language files. This similarity is sufficiently obvious to compiler designers that GNU's GCC compiler uses Lisp syntax in its machine definition files which inform the compiler of the intermediate 'code-to-machine-code' mappings for different platforms.
In the case of compilers for languages such as C, Pascal, FORTRAN, etc., the compiler may generate an internal representation that is very similar to the internal representation in a Lisp system. The implication of this is that procedural languages can be pre-compiled into Lisp code. An extremely fast and powerful embedded script language can be created with any procedural front end using a Lisp engine as the underlying execution mechanism. A user of such a system may never know that the language engine is Lisp, yet can reap all of the benefits of the Lisp engine, such as garbage collection, data abstraction, and in the case of SCADALisp, object oriented programming.
Gamma is one such implementation of a YACC grammar using the SCADALisp engine as the execution mechanism. It provides a procedural language which will be very familiar to C programmers, and easily understood by programmers of FORTRAN, BASIC and Pascal. It inherits the data abstraction, data types, garbage collection and dynamic scoping of SCADALisp with no loss in speed or versatility.
The single most daunting argument against Lisp is its comparative lack of performance. When Lisp was introduced in the late 1950s, computers were running on kilohertz clocks. Every cycle counted, and every byte of memory was worth an ounce of gold. While the rest of the world was writing assembler programs, John McCarthy (the inventor of Lisp) was writing interpreted Lisp programs. Any speed and memory comparisons between the two were very unflattering to Lisp. As CPU speed has risen and memory costs have dropped over the years, these perceptions of Lisp have remained. This has been aggravated by the Lisp community itself, which has created exhaustive Lisp standards. The Common Lisp standard in particular, which defines such a huge and complex feature set that in fact the resource requirements of Lisp interpreters have consistently met or exceeded the abilities of the computers they were running on. It is not unusual for a Common Lisp implementation to consume six megabytes of memory before the user program is even loaded.
This is not necessary. Lisp is a syntactically trivial language, requiring very few parsing rules and a relatively simple evaluator. A quick and richly featured Lisp implementation need not have such ridiculous resource requirements.
A SCADALisp executable with over 400 built-in functions, including object oriented extensions and inter-process communication, consumes less than 140 Kbytes on disk, and less than 300 Kbytes of RAM at runtime. This is more than an order of magnitude less than typical Lisp systems, and far less than many commercial language packages that provide only a fraction of SCADALisp's features. The addition of window system support naturally increases resource requirements, but still to a level that is nowhere near what people have traditionally expected.
As computer speeds have increased, better operating systems and GUI environments have become a reality. GUI environments in particular have been very greedy of CPU cycles and memory. In fact, the CPU time spent updating a screen in a process control GUI application far outweighs the CPU time spent in language execution. Tests with SCADALisp in both QNX Windows and Photon have demonstrated that in a control GUI application the GUI API consumes between 65% and 80% of the time consumed by the application. This does not include the graphics drivers and GUI server, which can only increase these numbers.
In short, interpreted languages no longer represent a CPU bottleneck in graphical environments. Even if the speed of the interpreter were 10 times slower than equivalent compiled code, a switch to compiled code in these environments (a factor of 10 difference in execution of non-GUI portions of the application) would provide at most an overall application performance improvement of between 18% and 32%. (For those who are interested, this is similar to the sad mathematical facts which have stopped fine-grained multiprocessing from ever gaining wide popularity). If certain functions absolutely must run quickly (for example, image processing functions), they can be written in C or assembly and encapsulated into Lisp functions.
This is not to say that all applications will fare as well in comparisons between interpreted and compiled languages. There are cases where a Lisp program may be 2 or possibly 3 orders or magnitude slower than a C program. These would be applications such as those performing a convolution on an image, where register optimization can be heavily used and single machine instruction operations are common. Other applications, such as symbolic processing and some forms of data manipulation may be comparable in speed between the two systems (no more than a factor of 2 or 3 difference in favor of compiled code). In such an instance, though, the development cost of the compiled application may be higher by 1 or 2 orders of magnitude.