Slashdot Mirror

I think you fail to understand how adaptable C and C++ is

I don't. My first programming language was C++, and I programmed in C++ professionally. C++ is severely lacking in expressiveness, and there is an abundance of undefined behavior in C++. Debugging a C++ program is as much about low-level program mechanics as it is about high-level logic (even when you are writing a high level application). Dealing with errors in C++ is a giant ball of confusion -- there isn't even a good way to deal with errors that occur in constructors or destructors.

C++ is surviving because of its history -- a lot of C++ code was written in the 90s, and nobody has the time to rewrite any of it (not even to get it up to date with modern C++ standards -- I was once on a project that had to use a subset of C++ in order to maintain compatibility with old compilers from the early 90s). Schools keep teaching C++ because they believe their job is to prepare students for jobs in industry where they will be writing C++ code, which helps to keep C++ afloat by training programmers to think in C++. There is no real technical advantage that C++ has -- none of its features are unique, nor is the combination of its features -- and it carries plenty of technical disadvantages compared to other languages.

The strong point isn't how great it is at any given benchmark, but rather how good it is for solving a whole range of different problems

There are other languages that are good at solving problems in that range, which do not have C++'s deficiencies. If you are writing low-level code, do you really want to be dealing with implicit function calls? If you are writing high-level code, do you really want to spend your time deciding between shared_ptr and weak_ptr? If lives depend on your code, do you really want to have no idea about the order in which functions will be called?

If your OS provides mmap and its 10x faster than doing read/write style ops then you have that choice

What makes C/C++ special here? A typical FFI in a high level language let's you call functions in shared libraries (and by extension, functions that your OS provides), and many implementations of high-level languages have (non-portable) extensions for a particular target OS.

If you want to interface to lua, opencl, or even inline assembly, then you can do it with ease

OK, but what if I want to embed Lua in my C++ program, so that I can provide my users with an extension language? What if I want to write Lua code, have it translated to C++ and then compiled by my C++ compiler?

For what it's worth, it is possible to write inline assembly using non-standard extensions in some high-level languages. As for opencl, note that parallel computing in high level languages is not exactly novel -- side-effect free programs have a long history of automatic parallelization.

Just try doing GPGPU programming in a those languages you list

Sure:

http://www.cliki.net/cl-gpu

Really, there is nothing special about C or C++ that makes it better suited for parallel programming than any other general-purpose language. CUDA being written in C++ has nothing to do with any sort of technical advantage C++ has; C++ is well known among Nvidia's target market and the OSes that Nvidia targeted have C or C++ APIs. If we still had Lisp machines and Nvidia was targeting those, Cuda would have been written in Lisp. If the API for Linux were in ocaml, Cuda would have been written in ocaml.

If speed is an issue your application is going to fail, when your competitor figures out how to use a GPU to solve a problem at 10x the rate of a CPU

Well, we've seen that situation before. Orbitz was competing against hand-optimized and tuned code running on mainframes, which have lots

Yeah, I had to debug and fix some stuff too. If the module is not too crap, fixing it is usually still faster than writing it from scratch in Lisp. Add in the OK modules that perl has and lisp doesn't and it still could be faster.

Even so many of the modules are written by programmers who are better than I am. That's how I improve the code quality of my program - most of the code is written by better programmers :).

Lisp does have Cliki: http://www.cliki.net/index
But compare the documentation of the average module.

I know zip about other projects, but I was hacking on Maxima for use in my robotics assignments and something is to be said for conciseness of Lisp's way of dealing with data structures. Something more is to be said for macros: the programmatic generation of code (they are nothing like C macros). Of course you can generate code in C, but it's a shitty experience, and you have to roll it all yourself. The C/C++ languages do not come with any sort of a data structure to express themselves. Even Python has an ast module. I've found that programmatic generation of code is a big win in embedded world, especially on small microcontrollers (RAM in single kilobytes, etc). Most platform libraries become quite bloated if you want to truly fully support all peripherals, even if a typical application only uses a small subset of the functionality. The compilers are usually too stupid to properly optimize it, even if a fairly rudimentary constant propagation would indicate that 90% of the library is dead code. With macros you can easily generate just the code you need. Macros can easily and cleanly replace external tools like lexer and parser generators. They are also great for implementing extra language features. You don't need hacks like Duff's device or coroutine horkage. LISP is powerful enough that you can have features like yield implemented in a library.

In the end, it's all about ease of use. Even though I do a lot in C and C++, I detest their verbosity. I mean, come on, ML family had type inference for three decades! Heck, I have worked with a structured basic running on CP/M Z80 that had rudimentary type inference (although didn't have algebraic types). You didn't have to assign types to your variables, and if you tried adding an integer to a string it would balk -- not at runtime, but before it'd accept the new or modified line of program! Variables were assigned types at first use, and if you had a function returning a value (yes, it had functions, but sadly no tuples), it knew what type it'd be based on the code inside of the function. That was in late 80s! Then you come to C++ and get to experience template metaprogramming -- sure it's powerful, but it feels about as expressive as programming a Turing machine directly. And metaprograms are interpreted by the compiler, in a very inefficient way.

Can anyone post links to any Lisp web application? It can be something different then the HTML & SVG web game, though I would be extra keen to see that run...

Can't find it hosted but found the code to the book at the homepage that includes both the svg.lisp and webserver.lisp (also check out CL-HTTP). As to your more generic question, I think this year's lisp game expo competition had a few good Lisp web games.

common-lisp-controller is an attempt to make Common Lisp package management play nicely with Debian package management, so, for example, trying to load a package within ASDF (Lisp) finds the appropriate Debian package if it's installed (like the linked article discusses doing for CPAN).

Strongly package-manager-based distributions like Debian usually don't put a lot of effort into making stuff outside the distribution work well, though. If you want some C library that isn't in Debian, you're going to have to build it yourself and stick it somewhere, and all the stuff in Debian isn't going to know about it. Similarly, if you want some CPAN module that isn't packaged in Debian (the Perl equivalent of a third-party shared library that isn't packaged in Debian), you're going to have to muck with it yourself, and it won't be in the usual dependency chain.

The usual Debian answer to these sorts of problems is: well, if it's maintained, useful, and under a DSFG license, let's just package it! Things get much less nice if the user is installing a bunch of custom stuff, and especially trying to get locally installed and package-managed stuff to play together nicely. CPAN having trouble with that is just one instance of nearly every other system that has its own custom package manager, from Python to GNU R to Scheme.

As you hinted at Common Lisp being an interpreted language, a clarification is in place.

Most Common Lisp implementations are compiled. As it has been for some time now. Some lisp implementation compile the code themselvel (SBCL for instance), others walk around and compile C-code (ecl for instance).

An overview of free CL implementations can be found at http://www.cliki.net/Common%20Lisp%20implementation .

For the language: Common Lisp HyperSpec. Every language should have one.

For things not part of the ANSI standard: Cliki. A wiki with everything from utility libraries to suggested projects to benefit the community.

A know the answers for some of your questions:

1. What is Lisp, and where to find the community web sites

Cliki is a good start:

http://www.cliki.net/index

2. How to locate, download, and install all the major Lisps on Linux, Mac, and Windows

On Debian: apt-get install sbcl

For windows try Lispbox:

http://www.gigamonkeys.com/lispbox/

3. Basic language grammar, including CLOS

The best text is "Practical Common Lisp":

http://www.gigamonkeys.com/book/

4. How to use ASDF (including complex examples)
5. How to fully interface with the operating system, including implementation-specific functions for file i/o, network i/o, command-line arguments, the environment, threads, and more
6. How to package a standalone Lisp application to deliver to customers
7. How to use UFFI

CFFI seens to be a better option:

http://common-lisp.net/project/cffi/

With a good manual:

http://common-lisp.net/project/cffi/manual/index.h tml

8. How to set up a Lisp web application server (modlisp or Araneida or ...)
9. How to use the most common libraries: CLSQL, OpenGL, SDL

Common lisp community is growing, and the OS integration, libraries and documention is improving.

http://www.cliki.net/Parenscript http://www.cliki.net/jsgen looks like parenscript was there before october 2005

http://www.cliki.net/Parenscript http://www.cliki.net/jsgen looks like parenscript was there before october 2005

I am surprised that no one has yet brought up lisp macros which can be used to develop a similar framework. Code can be written in Lisp and compiles/generates to javascript. See http://www.cliki.net/Parenscript and http://www.cliki.net/jsgen for implementations in common lisp. The problem I see with any form of generated javascript is that it will be hard to debug should something unexpectedly go wrong.

I am surprised that no one has yet brought up lisp macros which can be used to develop a similar framework. Code can be written in Lisp and compiles/generates to javascript. See http://www.cliki.net/Parenscript and http://www.cliki.net/jsgen for implementations in common lisp. The problem I see with any form of generated javascript is that it will be hard to debug should something unexpectedly go wrong.

Open source stuff, installs, usually without any reboot,

Unless, of course, it doesn't.
While things are getting better, the number of times a configure; make; make install run works properly is still far too low. Adding to this are the far too high number of packages that toss an "oh yeah... you also need to download and install packages X, Y, Z, and libSnood first, then alter Makefile.in appropriately," at the installer (who may have no clue what the appropriate changes to make are). Admittedly, a lot of this is made better via package management systems, but they aren't exactly foolproof either. There was an entry over at Mac DevCenter about the subversion packages being broken for both Fink and DarwinPorts. That's the kind of stuff that's truly maddening.

If I do need help there is usually better documentation than the commercial stuff provides

Wow. What kind of crap products are you buying? Documentation is the single biggest annoyance that I have when it comes to OSS. People just don't want to take the time to write something that is both complete and clear to a newcomer. Again, things are a bit nicer now that a developer can throw up a wiki and rely on his userbase to write the documentation for him, but it's still no great shakes.

The most annoying example of this that I had lately? Trying to figure out how to use OpenMCL to compile some code as a standalone, native app. The ability to do this is listed as one of its features, but I'll be damned if I can find that information in the "documentation". This is covered (albeit in a less than stellar manner) in e.g. the Franz-Allegro documentation.

and practical help is much easier to get if I should need it.

Well, here you're pretty much right. There are an awful lot of mailing lists, newsgroups, etc. out there where you can get help in a jiffy. Some of them still suffer from the RTFM disease, but this is getting much better.

It's 2006 --- no programmer of desktop/workstation/server programs is going to spend time optimizing their code [...]

1) Programs are becoming platform-agnostic. [...]

2) The world is moving towards higher-level languages and higher-level programming constructs. [...]

http://www.cliki.net/database

http://www.cliki.net/networking

Try searching CLiki for anything you might want. Most of what's there is good stuff.

http://www.cliki.net/database

http://www.cliki.net/networking

Try searching CLiki for anything you might want. Most of what's there is good stuff.

Oh, that's not really any more of a problem than figuring out someone's CPAN module works. And you don't really need to worry about a different dialect of Lisp for each programmer--it actually works out pretty nice (there are Lisp dialects, but they are essentially different languages which share similar ideas).

I think what you're saying is that you enjoy having a language with lots of pre-built modules, such that you can tie them together to achieve your goals. That's really not so much a characteristic of the language as it is of community around it. But me saying that doesn't help you if there's a library you'd like which doesn't exist--OTOH writing such libraries is often pretty fun! There is a short list of Common Lisp packages at cliki.net; there are lots more out there, though. Some recent interesting work has been done in auto-wrapping C libraries for easy use from Lisp.

One unfortunate thing in a language like Perl or Python is that often to get good performance one must write the innards of a module in some other language like C--in Common Lisp this isn't a factor: just write it in Lisp, compile it and it runs as fast as possible (in some domains, faster than C, in most somewhat more slowly).

Something you might like about CL is its object system, which is very easy to use, and yet can be extended to do some pretty crazy things.

I am just barely getting into Lisp, and actually enjoying it a lot. However, be prepared for anything beyond "hello world" to take a bit longer that you are normally accustomed to. :)

1) What to you do/get for a GUI? Like Algol famously leaving "IO to the library" meaning they punted on IO and this really hurt Algol, Python leaves the GUI to the library, but there are two mainline choices -- TKInter and wxWidgets/wxPython. Does Lisp in a Box have no GUI, some homebrew Smalltalk/Squeek sandboxed GUI, or does it link to TK or wx?

Most CommonLisps can reach the GUI via Tk, Xlib, GTK, wx, etc. I don't know which ones actually ship with said libraries, but there are easy to find (see below for CLiki).

2) Can you link to C/C++ to do drivers, low level stuff, reuse DLLs or SO modules, or is Lisp beyond connecting outside of the Lisp runtime? Even Java can reach outside with the much-maligned but really isn't too hard to use JNI -- I like JNI because it allows C/C++ to call Java and Java to call C/C++.

Yes, Common Lisp has a "Foreign Function Interface" that supposedly is pretty easy to use. Most implementations also provide access to OS-specific functionality via non-standard functions (i.e. "(unix:unix-getpid)" returns getpid()).

Check out the Common Lisp Wiki: http://www.cliki.net/index . There's loads of code that can get you going.

the perception is that Lisp is like some Smalltalk implementations -- so highly sandboxed to prevent this sort of thing. What is the story on this?

My personal perception of Lisp: whereas Java has essentially one mainline JVM (I include the libraries java.*/javax.* in the definition of JVM BTW, so until GNU Classpath is complete there is only one mainline JVM) and a handful of secondary JVMs (just the VM) for specialized environments, Lisp has about half a dozen mainline VMs including both commercial and open-source implementations. Each Lisp VM is cross-platform and in total they probably cover about as many platforms as the one Java VM. Code can be ported between the Lisp implementations without too much hassle. Most Lisp VMs are fast enough that they can actually be used for shell scripting (0.5s startup), and they have the same garbage collection and runtime optimization advantages as Perl, and they hover around 3MB RAM footprint like Perl.

I think the perception of Lisp as slow, RAM-hungry, and hard to interface with non-Lisp was probably true back when machines were small enough that 3MB RAM was enormous. By today's standards, a Lisp VM is quite snappy and can be (relatively) easily integrated into a non-Lisp environment.

I have chosen to learn Lisp because I want to think differently about programming, and see what people mean by "functions are first-class objects". So far it IS different but refreshing.

It's insane to outsource a mission-critical app to another corporation or group of people. If your idea is good, exposing it will only generate a competitor who has the full specs for a better system than the one you currently have very quickly (5 hours after you send out the spec it will be spread across the Internet, make its way to India and China for sure, etc.).

Instead spend 6 months bringing your developers up to speed on the application requirements and Common Lisp and then implement it in that framework. Keep the knowledge in-house, keep developers happy and you will have a system that can handle growth and load.

SBCL w/ Threading on OS X!? Dare I dream!?!?

While not magazines, I've found these resources to be useful in becoming a better programmer:

CLiki, a programming language blog. Contains lots of stuff on programming languages and paradigms, including debates on merits and disadvantages.

ll-discuss, a mailing list related to programming language concepts. Perhaps most interesting if you're into language implementation, but it's the closest thing to a magazine that I can recommend.

Bugtraq, a (the?) security list. This will teach you what things to avoid; at least, the 3 most common errors.

Practical Common Lisp, a book that basically provides a crash course on Common Lisp. It shows you how things are done in Common Lisp, why they are done that way, and occasionally draws comparisons with other languages, everything including practical examples. It is said that, even if you don't program in Lisp, knowing it makes you a better programmer.

How to Design Programs, a fairly extensive book on program design. I haven't read the whole book, but it seems to both solidly and concisely cover many fundamentals. It uses Scheme for explaining things, but the material applies to other languages just as well.

Not true - CLiki is writtin in Common Lisp. See here: http://www.cliki.net/CLiki

It is perhaps ironic that the Dylan Language Wiki is written in PHP, but that is being rectified.

Lots of people are using Lisp to write programs under Linux/FreeBSD/Mac OS/etc. these days. CLiki is a collection of free/open-source Lisp implementations and programs. A lot of them are hosted at common-lisp.net . The Association of Lisp Users hosts conferences and serves as a center for language advocacy.

how many languages have real support for creating gui's?

Surprisingly many. GTK+ website lists, unless I coffeedly counted wrong, 29 supported languages. Can't seem to find the list of languages supported by Tk, but I presume mindboggling number of languages have Tk bindings (not as slick as GTK+, but more cross-platform, for sure). And, a lot of languages have way to mess with C/C++ functions, so you probably could write a wrapper you need yourself...

is there a way to do a gui in lisp? seems so improbable to me

Sure there is! Pick any of the dozens of ways! Most are for X11 but some cross-platform ones are there too, like Tk and GTK+ and Qt =)

You can write in lots of nice languages for it, wheras Java afaik only has Java and Ruby.

No offense, but I guess you don't know much. Here are just a few of the available languages for the JVM:

• Smalltalk
• Pascal
• Modula-2
• Oberon-2
• Lisp
• Schema
• Python
• Perl
• TCL
• Logo
• Prolog

Your point is well taken, but note that your problem is basically a combination of lacking documentation and you still learning the language. The first is the fault of the language (well, the implementation, but still), while the latter is nobody's fault, because it's an inevitable situation. I would assume that if you were on the clock, you would already know the language you were working in. Ie. if the project were in C++, you'd already know C++, or else you wouldn't have gotten hired to work on it.

What implementation are you on, anyway? Depending on what kind of networking you need, the trivial-sockets library could be up your ally. Very simple way to connect Lisp to a network. If you're on SBCL, there is SB-BSD-SOCKETS, which exports an API pretty similar to standard UNIX sockets. Of course, for the best in documentation quality, springing for a copy of Allegro CL will get you the ACL socket API. Since you're a student, you can get a copy for a mere $99, or about what you'd pay for an academic version of any other commercial software.

Then answer to the original ask slashdot is, of course, LISP.

It's written "Lisp" these days, and yes, it could well be a suitable answer for the original ask slashdot question. Common Lisp has quite a decent set of Lisp-based web libraries, servers in lisp, and app. frameworks. e.g. Get Uncommon Web here - Watch the Video!

zlib written in CL, sans buffer overflows: http://www.cliki.net/Salza

You think lisp doesn't have good RDBMS tools??? CLSQL http://www.cliki.net/CLSQL runs rings around most any other DB interface I've seen, while AP5 (http://www.ap5.com/) has been the "real relational system, not pseudo-relational SQL" you tend to drone on about for YEARS already (though its licensing is problematic for Open Source people, as it's not freely redistributable, the author just publishes the source without a copyright license as far as I can see (so AFAIK it defaults to closed under the current (stupid) copyright system)).

A "power user" is NOT a power user if he can't cope with prefix syntax - e.g. almost all of C is prefix syntax: print("xyzzy"), OpenWindow(x,y,z) etc. Only difference is in lisp, the function name is the first thing inside the bracket, spaces as argument separators instead of commas, and C has a SMALL number of infix operators that you COULD emulate with macros in lisp if you were a masochist. APL on the other hand is a pervasively-infix language.

Xkeycaps allows to remap keys easily, so you can get a Lisp friendly layout.

Hm. Lisp philosophy: Lisp is a language for writing languages. A good lisp program extends the lisp language vocabulary in an application-specific way.

The "standardisation" of 4th gen languages is indeed futile, as they are by definition domain-specific. What you can standardise howevert is the best way to integrate a bunch of domain-specific languages together. Then you get Lisp: around since 60s, and constantly evolving to the present day.

Or, given the amount of NIH the computing world displays, we'll probably see some misbegotten lisp clone only with perverse XML instead of straightforward sexp syntax. And it will be hailed as a Great New Thing, similar to the way compsci researchers get funding for AI/KR by rehashing in XML+Java/C# the oodles of toy 20-year-old programs written in Lisp before the AI Winter.

If you're asking how to manipulate OS processes in Common Lisp in general, the answer is that it is not defined by the ANSI standard. (The reason for this is that each operating system has a different idea what a "process" is, what you can do with them and how you do it, some operating systems don't have processes at all, etc. Processes are beyond the scope of the ANSI standard.) So each implementation does it slightly differently. The leading commercial implementations, in particular, have all these kinds of facilities, and they are portable across operating systems (Mac, Unix, Windows). So if you write your program to those APIs, your program will run on all operating systems.

If you really meant "clisp", and you want to use their proprietary interface for this, then refer to the documentation entitled, "Implementation Notes". These notes are not about the internals of how clisp is implemented, but rather about the implementation-specific extensions to the language. (That label on their documentation confused me!) These notes come with your clisp distribution.

If that's not acceptable, because you didn't mean "clisp", or you really need portability not just across operating systems, but also across different vendors' implementations of Common Lisp, people have written libraries which give you portable APIs to things like process manipulation (and network sockets, multiprocessing, and so on).

These kinds of libraries are much easier to write in Lisp than in other languages. However, I don't know where to get the particular portability library (process manipulation) that you are seeking. I wrote my own. Maybe they are harder to find because it's so easy for people to write their own, but then people don't want to publish them for free. (Or maybe most people are just not writing programs that do a lot of process manipulation. Or they're happy with the non-portability of their programs and consider whatever solution they're using to be "practical" enough.) Anyway, here are some links to places I'd recommend exploring. I don't know if they've got what you want burried in there or not.

• Common-Lisp-POSIX
• ACL Compat (various interfaces)
• CLOCC PORT (shell/pipe interfaces)

A third solution to your problem, and maybe this is what you're looking for, is that you can just make Unix (or other C-language compatible) calls yourself directly from Common Lisp. The portability library for this is UFFI, the "Universal Foreign Function Interface". You will have to write a function-prototype for the function that you want to call. There might be issues with Unix signals or something. Your code will run in pretty much any ANSI Common Lisp implementation, on any operating system. (The not-yet-identified-maybe-hypothetical portability library for doing process/pid manipulation would itself be written using UFFI library. Not sure if anyone bothered. Extensive libraries for things like SQL database access has been written using UFFI, also.)

Not having a comprehensive one-stop shopping place for libraries and OS interfaces is one of the things lacking in Common Lisp. Java and Perl have done a somewhat better job in that area, so far.

Some other good places to look around for libraries and solutions are:

• Your vendor's proprietary portable interfaces
• CLiki, The Common Lisp wiki
• The Common Lisp Cookbook

If you're asking how to manipulate OS processes in Common Lisp in general, the answer is that it is not defined by the ANSI standard. (The reason for this is that each operating system has a different idea what a "process" is, what you can do with them and how you do it, some operating systems don't have processes at all, etc. Processes are beyond the scope of the ANSI standard.) So each implementation does it slightly differently. The leading commercial implementations, in particular, have all these kinds of facilities, and they are portable across operating systems (Mac, Unix, Windows). So if you write your program to those APIs, your program will run on all operating systems.

If you really meant "clisp", and you want to use their proprietary interface for this, then refer to the documentation entitled, "Implementation Notes". These notes are not about the internals of how clisp is implemented, but rather about the implementation-specific extensions to the language. (That label on their documentation confused me!) These notes come with your clisp distribution.

If that's not acceptable, because you didn't mean "clisp", or you really need portability not just across operating systems, but also across different vendors' implementations of Common Lisp, people have written libraries which give you portable APIs to things like process manipulation (and network sockets, multiprocessing, and so on).

These kinds of libraries are much easier to write in Lisp than in other languages. However, I don't know where to get the particular portability library (process manipulation) that you are seeking. I wrote my own. Maybe they are harder to find because it's so easy for people to write their own, but then people don't want to publish them for free. (Or maybe most people are just not writing programs that do a lot of process manipulation. Or they're happy with the non-portability of their programs and consider whatever solution they're using to be "practical" enough.) Anyway, here are some links to places I'd recommend exploring. I don't know if they've got what you want burried in there or not.

• Common-Lisp-POSIX
• ACL Compat (various interfaces)
• CLOCC PORT (shell/pipe interfaces)

A third solution to your problem, and maybe this is what you're looking for, is that you can just make Unix (or other C-language compatible) calls yourself directly from Common Lisp. The portability library for this is UFFI, the "Universal Foreign Function Interface". You will have to write a function-prototype for the function that you want to call. There might be issues with Unix signals or something. Your code will run in pretty much any ANSI Common Lisp implementation, on any operating system. (The not-yet-identified-maybe-hypothetical portability library for doing process/pid manipulation would itself be written using UFFI library. Not sure if anyone bothered. Extensive libraries for things like SQL database access has been written using UFFI, also.)

Not having a comprehensive one-stop shopping place for libraries and OS interfaces is one of the things lacking in Common Lisp. Java and Perl have done a somewhat better job in that area, so far.

Some other good places to look around for libraries and solutions are:

• Your vendor's proprietary portable interfaces
• CLiki, The Common Lisp wiki
• The Common Lisp Cookbook

If you're asking how to manipulate OS processes in Common Lisp in general, the answer is that it is not defined by the ANSI standard. (The reason for this is that each operating system has a different idea what a "process" is, what you can do with them and how you do it, some operating systems don't have processes at all, etc. Processes are beyond the scope of the ANSI standard.) So each implementation does it slightly differently. The leading commercial implementations, in particular, have all these kinds of facilities, and they are portable across operating systems (Mac, Unix, Windows). So if you write your program to those APIs, your program will run on all operating systems.

If you really meant "clisp", and you want to use their proprietary interface for this, then refer to the documentation entitled, "Implementation Notes". These notes are not about the internals of how clisp is implemented, but rather about the implementation-specific extensions to the language. (That label on their documentation confused me!) These notes come with your clisp distribution.

If that's not acceptable, because you didn't mean "clisp", or you really need portability not just across operating systems, but also across different vendors' implementations of Common Lisp, people have written libraries which give you portable APIs to things like process manipulation (and network sockets, multiprocessing, and so on).

These kinds of libraries are much easier to write in Lisp than in other languages. However, I don't know where to get the particular portability library (process manipulation) that you are seeking. I wrote my own. Maybe they are harder to find because it's so easy for people to write their own, but then people don't want to publish them for free. (Or maybe most people are just not writing programs that do a lot of process manipulation. Or they're happy with the non-portability of their programs and consider whatever solution they're using to be "practical" enough.) Anyway, here are some links to places I'd recommend exploring. I don't know if they've got what you want burried in there or not.

• Common-Lisp-POSIX
• ACL Compat (various interfaces)
• CLOCC PORT (shell/pipe interfaces)

A third solution to your problem, and maybe this is what you're looking for, is that you can just make Unix (or other C-language compatible) calls yourself directly from Common Lisp. The portability library for this is UFFI, the "Universal Foreign Function Interface". You will have to write a function-prototype for the function that you want to call. There might be issues with Unix signals or something. Your code will run in pretty much any ANSI Common Lisp implementation, on any operating system. (The not-yet-identified-maybe-hypothetical portability library for doing process/pid manipulation would itself be written using UFFI library. Not sure if anyone bothered. Extensive libraries for things like SQL database access has been written using UFFI, also.)

Not having a comprehensive one-stop shopping place for libraries and OS interfaces is one of the things lacking in Common Lisp. Java and Perl have done a somewhat better job in that area, so far.

Some other good places to look around for libraries and solutions are:

• Your vendor's proprietary portable interfaces
• CLiki, The Common Lisp wiki
• The Common Lisp Cookbook

If you're asking how to manipulate OS processes in Common Lisp in general, the answer is that it is not defined by the ANSI standard. (The reason for this is that each operating system has a different idea what a "process" is, what you can do with them and how you do it, some operating systems don't have processes at all, etc. Processes are beyond the scope of the ANSI standard.) So each implementation does it slightly differently. The leading commercial implementations, in particular, have all these kinds of facilities, and they are portable across operating systems (Mac, Unix, Windows). So if you write your program to those APIs, your program will run on all operating systems.

If you really meant "clisp", and you want to use their proprietary interface for this, then refer to the documentation entitled, "Implementation Notes". These notes are not about the internals of how clisp is implemented, but rather about the implementation-specific extensions to the language. (That label on their documentation confused me!) These notes come with your clisp distribution.

If that's not acceptable, because you didn't mean "clisp", or you really need portability not just across operating systems, but also across different vendors' implementations of Common Lisp, people have written libraries which give you portable APIs to things like process manipulation (and network sockets, multiprocessing, and so on).

These kinds of libraries are much easier to write in Lisp than in other languages. However, I don't know where to get the particular portability library (process manipulation) that you are seeking. I wrote my own. Maybe they are harder to find because it's so easy for people to write their own, but then people don't want to publish them for free. (Or maybe most people are just not writing programs that do a lot of process manipulation. Or they're happy with the non-portability of their programs and consider whatever solution they're using to be "practical" enough.) Anyway, here are some links to places I'd recommend exploring. I don't know if they've got what you want burried in there or not.

• Common-Lisp-POSIX
• ACL Compat (various interfaces)
• CLOCC PORT (shell/pipe interfaces)

A third solution to your problem, and maybe this is what you're looking for, is that you can just make Unix (or other C-language compatible) calls yourself directly from Common Lisp. The portability library for this is UFFI, the "Universal Foreign Function Interface". You will have to write a function-prototype for the function that you want to call. There might be issues with Unix signals or something. Your code will run in pretty much any ANSI Common Lisp implementation, on any operating system. (The not-yet-identified-maybe-hypothetical portability library for doing process/pid manipulation would itself be written using UFFI library. Not sure if anyone bothered. Extensive libraries for things like SQL database access has been written using UFFI, also.)

Not having a comprehensive one-stop shopping place for libraries and OS interfaces is one of the things lacking in Common Lisp. Java and Perl have done a somewhat better job in that area, so far.

Some other good places to look around for libraries and solutions are:

• Your vendor's proprietary portable interfaces
• CLiki, The Common Lisp wiki
• The Common Lisp Cookbook

My biggest gripe with LISP is that there are so many fragmented implementations that if you're looking for an app that does something cool (Like dynamic web page generation) it typically won't be in the variant of Lisp that you're currently using.

While this does happen in areas which are not treated by the Common Lisp standard (notably network programming and concurrency), it really isn't the problem you make it out to be.

Here's just a handful of code libraries and frameworks for Common Lisp and the implementations they support:

• Araneida, an extensible web server and webapp framework: SBCL, CMUCL, OpenMCL, ABCL, CLISP, AllegroCL, LispWorks
• UnCommonWeb, a continuations-based web application framework: OpenMCL, CMUCL, SBCL, CLISP, AllegroCL
• CL-SQL, a powerful database library: AllegroCL, LispWorks, SBCL, CMUCL, OpenMCL
• McCLIM, a free implementation of the CLIM user interface library: AllegroCL, CMUCL, SBCL, OpenMCL, LispWorks, CLISP
• Cells-GTK, a GTK library built on top of Cells, for declarative UI development (a very powerful approach): AllegroCL, LispWorks, CMUCL, CLISP
• CL-PPCRE, a fast Perl-compatible regular expression library (which is faster than Perl's regexp engine, incidentally): AllegroCL, CLISP, CMUCL, Corman Lisp, ECL, MCL, OpenMCL, SBCL, SCL, LispWorks, Genera
• XMLisp, a very interesting intersection of XML and CLOS objects: MCL, LispWorks, OpenMCL, SBCL, CLISP
• ACL-COMPAT , a library with socket programming support (et. al.): CLISP, CMUCL, Corman Lisp, LispWorks, MCL, OpenMCL, SBCL, SCL

My biggest gripe with LISP is that there are so many fragmented implementations that if you're looking for an app that does something cool (Like dynamic web page generation) it typically won't be in the variant of Lisp that you're currently using.

While this does happen in areas which are not treated by the Common Lisp standard (notably network programming and concurrency), it really isn't the problem you make it out to be.

Here's just a handful of code libraries and frameworks for Common Lisp and the implementations they support:

• Araneida, an extensible web server and webapp framework: SBCL, CMUCL, OpenMCL, ABCL, CLISP, AllegroCL, LispWorks
• UnCommonWeb, a continuations-based web application framework: OpenMCL, CMUCL, SBCL, CLISP, AllegroCL
• CL-SQL, a powerful database library: AllegroCL, LispWorks, SBCL, CMUCL, OpenMCL
• McCLIM, a free implementation of the CLIM user interface library: AllegroCL, CMUCL, SBCL, OpenMCL, LispWorks, CLISP
• Cells-GTK, a GTK library built on top of Cells, for declarative UI development (a very powerful approach): AllegroCL, LispWorks, CMUCL, CLISP
• CL-PPCRE, a fast Perl-compatible regular expression library (which is faster than Perl's regexp engine, incidentally): AllegroCL, CLISP, CMUCL, Corman Lisp, ECL, MCL, OpenMCL, SBCL, SCL, LispWorks, Genera
• XMLisp, a very interesting intersection of XML and CLOS objects: MCL, LispWorks, OpenMCL, SBCL, CLISP
• ACL-COMPAT , a library with socket programming support (et. al.): CLISP, CMUCL, Corman Lisp, LispWorks, MCL, OpenMCL, SBCL, SCL

My biggest gripe with LISP is that there are so many fragmented implementations that if you're looking for an app that does something cool (Like dynamic web page generation) it typically won't be in the variant of Lisp that you're currently using.

While this does happen in areas which are not treated by the Common Lisp standard (notably network programming and concurrency), it really isn't the problem you make it out to be.

Here's just a handful of code libraries and frameworks for Common Lisp and the implementations they support:

• Araneida, an extensible web server and webapp framework: SBCL, CMUCL, OpenMCL, ABCL, CLISP, AllegroCL, LispWorks
• UnCommonWeb, a continuations-based web application framework: OpenMCL, CMUCL, SBCL, CLISP, AllegroCL
• CL-SQL, a powerful database library: AllegroCL, LispWorks, SBCL, CMUCL, OpenMCL
• McCLIM, a free implementation of the CLIM user interface library: AllegroCL, CMUCL, SBCL, OpenMCL, LispWorks, CLISP
• Cells-GTK, a GTK library built on top of Cells, for declarative UI development (a very powerful approach): AllegroCL, LispWorks, CMUCL, CLISP
• CL-PPCRE, a fast Perl-compatible regular expression library (which is faster than Perl's regexp engine, incidentally): AllegroCL, CLISP, CMUCL, Corman Lisp, ECL, MCL, OpenMCL, SBCL, SCL, LispWorks, Genera
• XMLisp, a very interesting intersection of XML and CLOS objects: MCL, LispWorks, OpenMCL, SBCL, CLISP
• ACL-COMPAT , a library with socket programming support (et. al.): CLISP, CMUCL, Corman Lisp, LispWorks, MCL, OpenMCL, SBCL, SCL

this is a good set to start with, and look up asdf and asdf install for further libraries that are cross platform/implementation for lisp. saves a lot of trouble, and evens out the differences between the various lithpssssssss

Why don't you use a real shell environment, like Common Lisp?

The de facto way of interfacing with C in Common Lisp is the UFFI library. It runs on most Lisp implementations, but sadly it does not yet support GCL or CLISP. If you decide to play with either of those, you should probably just try its foreign function interface. CLISP in particular is noted for having an excellent FFI.

Warning, your post is full of misconceptions. Lisp was the first ANSI-standardised object-oriented language, actually - CLOS? ringing any bells? And it is accurate to call symbolics lisp machines an "object oriented operating system" - why, Sonja Keene's book "Object Oriented Programming in Common Lisp" uses as its main examples throughout toy implementations of the object-oriented DOS bits from symbolics.

And it's not a "functional language". It's a multi-paradigm language. Actually, ML and Haskell people scorn lisp because lispers won't commit to the functional programming "one true path". You can do functional programming with type inferencing in lisp with a compiler like CMUCL or SBCL. But you don't _have_ to. And lispers, not being the nazis of the purist FP community, like it that way.

So I suggest you get on over to http://cliki.net/ and get clue. k thx bye.

Yet, no Lisp flavor has a feature that comes close to CPAN in saving
http://www.cliki.net/asdf-install
is a package, going that way. But You are insofar right, the community of Lispers is not that large to
produce tons of halfbaked code...

Martin

Trolling about Java and Lisp at the same time? Isn't that a little bit like ASKING FOR IT? Fast Fourier Transform is actually one of the traditional benchmarks for Common Lisp, the Gabriel series. Now run along and play in traffic.

Um. Lisp is still around doing just fine, thankyouverymuch. We don't pine for it, we just use it. "Lisp Machine" hardware is another matter, but lisp machines were never affordable by mere mortals anyway.

Take a look at Common Lisp (see: http://www.common-lisp.net/ or http://www.cliki.net/ or http://sbcl.sf.net/ ).

It is a language supporting every paradigm you'll ever need. And if not you can (portably!) code it. The hacker's language of choice.

Huh? Lisp is multi-paradigm because you can implement other paradigm languages in lisp? By that logic C must be the most multi-paradigm language in existence.

The point here is that when you implement a mini-language in lisp you still have access to lisp itself. This is a natural way of working with lisp, but fairly unnatural in C and most other languages. For example, when I define a binary tree, I could also define a do-preorder control construct to iterate through the tree in preorder and use it like

(do-preorder (item tree)
(print item))

Common Lisp is not a pure functional programming language. In pure functional languages functions are purely mathematical: the result with the same parameters is always the same (state enters a function only through arguments). You should look up setq and setf. I suggest you read some books, see http://www.cliki.net/.

The Common Lisp standard library offers "just about everything" except sockets, threads, a relational database API, a GUI API, standard HTTP/FTP/XML-RPC libraries, XML libraries, cryptographic libraries, imaging libraries, and the list goes on. There's also nothing even approaching a consensus on web development frameworks, as exists in Java servlets and EJBs. Plus, the most technically excellent open source implementations don't work on Windows.

Wrong and wrong again.

But you knew that, didn't you?

Sockets are almost universally available, but they're implementation specific. Threads are much the same. There are several relational database APIs, GUI APIs, HTTP/FTP/XML-RPC libraries, XML libraries, cryptographic libraries, imaging libraries, and more. The biggest problem is that the fancier commercial implementations (which have all the stuff you mentioned built in) cost so much money.