OSNews

L.I.S.P. = "lots of silly paranthesis"

Haven't heared this before. (insert smile here)

Attention! Dear Sir, this is the Oldspeak language correction department:
It's parenthesis pl.: parentheses
It's not paradentosis, of course. :-)

What does the "I" stand for?

The actual joke is: "lots of irritating superfluous/silly parentheses"

Lot's of things. Among others:

- ITA's QPX system (the engine behind Orbitz) is written in Common Lisp.
- Viaweb (now Yahoo! Store) is/was written in Common Lisp*.
- Naughty Dog software used custom Lisp-based language (GOOL and GOAL) for Crash Bandicoot and the Jak and Daxter games (PS1/PS2)+.
- The mission planning system for the Mars Pathfinder mission was written in Common Lisp.
- Common Lisp has been used at JPL and NASA, and has even flown on a space probe (Deep Space 1): http://www.flownet.com/gat/jpl-lisp.html
- Mirai, a 3D modeler written in Common Lisp, was used, among other things, to create all of Gollum's facial expressions in Lord of the Rings.

These are a few high-profile ones off the top of my head. There is a very big list here: http://bc.tech.coop/blog/041027.html

Lot's of people also use Lisp for one-man projects. For example, I know a researcher that prototypes network algorithms in Lisp. Personally, I use it for almost all my hobby coding (compilers).

In the last five years or so, Lisp has actually seen something of a resurgence. Lisp is one of the few languages supporting multiple commercial implementations. LispWorks and Allegro CL are profitable products for LispWorks Ltd and Franz Inc, respectively. There are also several companies (like Clozure), that find it profitable to work on open-source Lisp implementations in addition to their Lisp consulting businesses.

*) The Yahoo! folks rewrote it in C++ after they bought it, because it was easier to get C++ developers. Except they didn't really rewrite it --- a lot of the code is still actually Lisp, and so they wrote a Lisp interpreter in C++ to run it...

+) Even though the use of Lisp was successful in both products, Naughty Dog is now transitioning to a C++-based pipeline, since Andy Gavin, the inventor of GOOL/GOAL left the company to start another venture.

Bunch of stuff, almost all of it internal projects rather than flag waving public projects.

And the commerical products tend to be nichey vertical applications.

But, you can program pretty much anything you want in Lisp. The good compilers are pretty performant out of the box, but you still need to jump through some hoops to get your tight loop code as fast as it can be (through things like type declarations, etc.).

And there are several implementations of the language, many free.

http://www.gigamonkeys.com/book/ is a link to Practical Common Lisp which gives you an idea of how to go about doing all the stuff that everyone does in everything else.

Common Lisp has long been a favorite of mine, but I'm mostly a Java monkey now. But the beauty of the internet is making implementation languages less and less of an issue save for those who need to support the actual source code of the application. But in the modern services based systems we're bolting together today, Lisp is certainly a viable choice for applications.

Well, a more mundane example is Autocad (OK, I know, not perfect). I did, and many friends of mine too, lots of code in AutoLISP to improve the automation of some things in engineering projects, and it is a joy to work with.

PS.: To the jokers, when wanting to joke about something, do it right: L.I.S.P. - Lots of Irritating Superfluous Parentheses.

oh wow that's interesting. i didn't know that lisp was adapted to do so much. thanks.

Python is weaker than Common Lisp on both the imperative and functional fronts. Python doesn't have "real" closures, and purposefully leaves out certain important functional primitives. In fact, a lot of the stuff is just plain going away in Python 3k. At the same time, Python can't touch the looping facilities that are available for Common Lisp (LOOP, Iterate). Complicated imperative loops that are very messy in Python are a cinch to express with LOOP or Iterate.

Simple example: write a "zip" function that operates on two lists of integers. The result is a list of pairs. If lists are unequal length, stop at shortest list (basically, Python's zip function).

In Python (with dots because otherwise OSNews messes up):

def myzip(a, b):
. result = []
. for idx in xrange(0, min(len(a), len(b))):
. . k.append((a[idx], b[idx]))
. return result

If you can afford to be less efficient (creating a new temporary list with "zip"), you can also write:

def myzip(a, b):
. result = []
. for (x, y) in zip(a, b):
. . k.append((x, y))
. return result

In Common Lisp, with Iterate (again, with dots):

(defun myzip (a b)
. (iter (for x in a) (for y in b)
. . (collect (cons x y))))

The disparity only grows as the loop gets more complex (multiple iteration variables, multiple results, etc). Best of all, "Iterate" is just a user-made library, written entirely in Lisp. If it doesn't do something you need, you can easily extend it. If Python's "for" doesn't do something you need (in this case, parallel iteration), you have to wait for the next version of Python...

Edited 2007-10-28 02:35

Rayiner, have you tried ltk toolkit? Or is there another gui environment you prefer?

I don't do any GUI development in Lisp, sorry. But I will spout some hearsay and rumor

Ltk is simple and well-documented (also actively maintained).

If you're on a commercial implementation, use it's GUI toolkit. That's CLIM or GTK+ on Allegro, or CAPI or CLIM on LispWorks. You'll get developer support too!

On OS X, OpenMCL has a pretty complete Cocoa bridge.

McCLIM is quite reasonable (documented and actively maintained) on *NIX and CMUCL/SBCL. CLIM in general is probably the best from an API-standpoint --- it's a native Lisp toolkit.

There are multiple GTK 2.x bindings. http://sourceforge.net/projects/clg is supposed to be a good one for CMUCL/SBCL. It works with Glade too apparently.

It really depends on what your goals are/what your platform is. For making native-looking Mac apps, OpenMCL with Cocoa is really a no-brainer. On Windows and for cross-platform, LispWorks and CAPI is the ticket. On *NIX, GTK+ is the way to go if you want native-looking, while McCLIM is good if you don't mind dated-looking widgets (GNUStep problem --- hi-tech core with 1990's artwork).

PS) If you're on SBCL, remember that McCLIM is available via ASDF-INSTALL.

Edited 2007-10-28 07:57

Here's a response to your Python code:

def myzip(a,b):
. return [(a[ i ], b[ i ]) for i in range(min(len(a), len(b)))]

If I wish to strictly use more functional programming constructs:

def myzip(a,b):
. return map(lambda i: (a[ i ], b[ i ]), range(min(len(a), len(b))))

Seems simple to me.

Edited 2007-10-28 18:54

Hehe, couldn't help but notice that your code uses more parentheses than the Lisp code.
Oh, the irony!

I was specifically comparing imperative constructs, so both the Python code and the Lisp code were written as loops with side-effects. Both of your examples are in functional style. They could be written (more succinctly) in Common Lisp as:

(defun myzip (a b) (mapcar 'cons a b))

well to be fair DrScheme is scheme, not lisp.
While they're similar they aren't the same.

Scheme is a dialect of Lisp, just as Common Lisp is a dialect of Lisp.

Yes, but in the same way that Java is a dialect of C. They're similar, but mostly in appearance only. There are significant and fundamental differences between Scheme and Lisp, especially Common Lisp.

technically true but when most people (including me) say lisp we mean common lisp, and in fact the article is about SBCL a common lisp interpreter

I have heard a lot of good things about Practical Common Lisp, but I haven't read it myself. I've read ANSI Common Lisp, and it's very good. Graham writes in a very straightforward way, and the book is short and to the point (~350 pages). The appendices in the back of the book also serve as a nice hardcopy quick-reference that complements the more detailed Hyperspec (which you can find online).