Discussion on:

Poll: Have you used Lisp?

We had several weeks of Lithp as part of a survey course, and it seemed (a) deterministic and (b) useless. Several years later I came across a different interpreter that was more robust and full-featured, and thus had more interesting uses. But it was still a mere play-thing, and never seemed to have any relationship to anything that could honestly be called "artificial intelligence".

OTOH, a friend did some work at the state dept. of educationism and used APL for all sorts of nifty things, from budget projections to data-basing of their data archives. I fiddled with it, but never found a good-fit use on the job.

My favorite quirk language was SNOBOL for string/sequence processing. It could be totally amorphous with every instruction including a branch, but mostly we played nice. Pascal straight from ETH Zurich was mostly a toy, too, but Apple seemed to pound a version of it into productive form.

Mostly, Fortran (with various pre-compilers and bits of assembly language) was the bread-and-butter super-computing language of the 1980s, until we followed the mob to C in 1986 and then C++ in the mid-1990s and then Objective-C in 2000-2002 (trying to make the transition amidst the recession and taking a financial hit in the process).

Others preferred TUTOR (developed at UIUC for PLAyTOy) for game programming. The educationists turned it into a hog, though, by building in a horrendous amount of logging.

i knew some people who took a Cobol class. One wrote a Fortran program to generate the required long Cobol programs from a few lines of directives. Another wrote a program to generate machine language instructions and then performed them. A third had a prof who kept having to stop to ask him whether that's the way it worked on our systems.

If you look at Smalltalk code, there are a lot of square braces, which represent lambdas. Incidentally, if you look at the Lisp 1.5 Programmer's Manual (http://www.softwarepreservation.org/projects/LISP/book/LISP%201.5%20Programmers%20Manual.pdf), you can see that McCarthy and his co-authors had worked on M-expressions for Lisp that made it look more like a conventional language (which also used square braces). This wasn't adopted in the Lisp community though, which opted for S-expressions, with all the parentheses.

I have always like Forth as a good meta-assembly language. In fact all compilers will generate internally an intermediate form similar to Forth, before compiling it to a more final binary form or running it directly with a very simple interpreter (including Java or MSIL for .Net). And there's absoutely no reason why Forth or Lisp or Postscript would not be supported the same way, with the benefits of the modern VMs that support *managed code* which has proven now to be very fast, much more reliable, supporting more architecture, being more easily scalable to newer architectures, benefiting automatically of the additional CPU or GPU acceleration technologies and of virtualized networking environments (including flexivility and optimizations in deployements between servers and workstations).
The world is going now to manaed code, because we need it also to scale it on multiple hosts, or support the same programs over a larger set of devices (including mobile devices).
I've said goodbye forever to C and C++, which only produce a static optimization only targetting specific architectures. Yes we have now "managed C" or "managed C++", but things are much less tricky when using Java or .Net: now the same applications compiled for VMs are MUCH faster in those VMs (because they are optimized only for a specific range of CPUs, or fail completely or are incompatible if they are not specifically recompiled for others, or are underoptimized only to offer better compatibility, or are unnecessarily inflated with slow dynamic load of platform-specific code and lots of tests throughout the code), and work on a much larger set of devices or computers, and offer a MUCH simplified deployment scheme to developers.

Today, VMs rock ! Because there's a clear separation between the application code and the architecture-specific support built in the VM, that can produce very specific optimizations on the fly and locally without altering the application code (for example reschdeduling the application for parallelism, including large-scale parallelism using GPUs, or distributed computing in a virtual OS running over a network, even when this network includes heterogeneous systems with different CPUs such as x86, x64, IA64, GPU/APU, and mobile RISC processors, with or without multiple cores): if some code cannot run locally with enough performance, a VM can rescedule the code to work somewhere else, and we have a much better global reuse of available computing resources (including those available on demand in a cloud, if the network links or buses are fast enough to support some reasonnable response time constraints).

Forget C and C++, these are languages of the past that have costed too much to support. Let's go to managed code supported by VMs.

Ah, a rabid C++ practitioner speaks up!

1. The ability to "write and execute new code on the fly" is not unique to Lisp, and in fact since several Lisp compilers (and most compilers for other languages) have been written in C, it should be obvious that there's nothing wholly new here besides making abstraction easier. I've never once seen Lisp create dangerous code on-the-fly in actual use, but I have seen countless programs in C++ with silent buffer overflows, silent integer overflow, and so on -- aren't these even worse "clever" optimizations that have caused actual damage?

2. False. It was originally designed to be a way of talking about recursive algorithms on a blackboard, not for computers at all. There was one dialect in the 1980's (Lisp Machine Lisp) that was written specifically for tagged architectures, but it was never very popular even in Lisp circles, and in only a couple years its performance had been bypassed by general-purpose machines. Today's Lisp compilers are some of the fastest compilers to be found. (Even if it was true that Lisp was designed for a tagged architecture, that doesn't say anything about modern compilers. After all, C was designed for writing a computer game for an 18-bit, wire-wrapped minicomputer, but we don't hold that against it today.)

3. I don't know why you keep bringing up old canards like "AI", "security", "commodity platforms", and such. (It sounds like you got all your information from a 1983 marketing brochure!) I would, however, ask you to demonstrate why you think C++ is sufficient. For example, get a copy of SICP or PAIP and show how the algorithms there can be implemented in C++. I've tried this, and you'll find it takes many, many pages of C++ code (or external libraries), to do some things that Lisp can do quite simply.

4. Again with the AI! At least this time it's a bit different because you threw in an ad hominem attack. I guess I don't have the experience you did. I've never used Lisp for AI, and I've never heard anyone say that Lisp programmers "were a unique species of super-intellects". I'm sorry you were treated poorly, and I hope that someday you can learn to separate the message from the messenger. I hated my high school English teacher but I didn't respond by abandoning English and telling others they should, too.

S?? se cerchi 'alessi xoom' mi trovi. Ero qui di passaggio non frequento molto questo sito,
'Viva il Lisp, Abbasso il Lisp' dove lo trovo?
Buone Feste a te. Marco