I’ve talked about the history of computer languages some in previous blog posts. In particular, I’ve talked about the difference between compiled languages and interpreted languages. Now I’d like to make a further distinction. Some languages are static and others are dynamic. More specifically, static languages are reduced to executable instructions ahead of time during a compilation phase where dynamic languages are processed interactively as the programmer explores the solution space defined by her program.
Static languages can more easily be made to run fast and can more readily be analyzed for correctness. Dynamic languages support organic exploration of the problem and its solution. Dynamic languages can, and have, been made to run fast and analyze themselves for correctness. It’s just typically more difficult to do so.
The surprising thing, to me anyway, is that we have had examples of both kinds of languages pretty much since the first higher level languages were written. FORTRAN was a static language written for engineers to automate the solution of numeric problems. Lisp was a dynamic language to explore the potential for computers to do things other than just numeric computation.
Engineers and Managers liked FORTRAN and its descendants. The applications that were written in them were immediately practical and it was easy to measure how much work the programmers had done. Initially this was measured in Source Lines Of Code or SLOCs. This was all well and good until the programmers realized that a more complicated solution requiring more source lines made them look better to the managers that were measuring their performance.
Over time, we learned a lot about how to write programs in static languages until finally, in recent years, most “serious” programming is done in static languages like C++ and Java. This is a sad situation. Static languages are good for many things but there are a lot of problems that are better served by dynamic languages.
Lisp has a bad reputation among many engineers including many computer scientists. This is often because they were forced to write a project using Lisp in a Computer Languages course by an instructor that didn’t understand Lisp themself. But, to be fair, Lisp does require a little bit of a different mind set from most static languages.
There are also a bunch of myths about Lisp that may have had some basis in fact at one point but over time, Lisp has improved and the hardware that all languages run on have improved, and the myths are, for the most part no longer valid. For instance, it was initially said that Lisp wasn’t any good for doing numerical computing. That was initially true, largely because the authors of Lisp language systems were interested in exploring the non-numerical aspects of programming and consequently made little effort to make the language handle numbers efficiently. This was remedied in the early seventies but Lisp retains a reputation for being bad with numbers in some circles.
The main thing that Lisp is better at than its static conterparts is allowing the programmer to interactively explore a problem space. In a static language, one typically has to write a substantial amount of code before you get to the point where you can run it and see how it behaves. If it doesn’t do what you intend, which is typical for the first couple of attempts, you have to go back to the source and change it, recompile the program, and rerun it to see if you’ve fixed the problem.
With Lisp, one types expressions directly to the interpreter using what is called a Read Eval Print Loop or REPL. The REPL reads a line of code, interprets it and prints the resulting value. Then it repeats the process (hence the Loop). This allows the programmer to explore the problem and potential solutions interactively, getting feedback from the computer after each line. It is amazing how much faster correct programs are developed using this approach.
I’ll talk more about dynamic languages in another post soon. There is much that I want to say about them. And Lisp may have been the first dynamic language but it certainly wasn’t the last. I’ll have more to say about other members of the dynamic language family. I’ll also have something to say about ways that we can realize the best aspects of both of these styles of language by combining them into hybrid languages.