Slashdot Mirror

Well, you can. It's actually dead simple: CORBA is RPC, just that you don't address some particular service, you invoke a method on an object reference, which contains the servers address. Add in an interoperable binary protocol, a standard language to define interfaces and some standard mappings to common programming languages, that's all there is to it. Services are completely optional, the ORB, commonly depicted as an all encompassing cloud with mystic abilities, is just a support library to decode object references and speak the wire protocol. For the long version, here's CORBA in 5 Minutes.

Now why the confusing websites? Well, what would you do as a vendor? Tell your clients (managers!) that you're selling them an RPC library? No way! It has to be Object Oriented Middleware, it must be Enterprise, and everything ties into the mystic ORB. You absolutely need an ORB! Well, you didn't in the 80's, but this is the 21st century and there you need an ORB! Oh, and what a remarkable conincidence... we are just selling ORBs!

Anyway, have a look at ORBit. CORBA can actually be simple. It's commercial software that cannot.

CLiki is a Common Lisp wiki written using Araneida. Other popular web systems for Common Lisp include CL-HTTPD, used for Bill Clinton's 96 campaign and Howard Dean's 2004 campaign, and Franz's AllegroServe.

So why would you pick Lisp for a web server? You said it yourself - "the standards change so fast". Lisp is not a language for AI, it's a language for rapid development in a changing domain, and it provides good-to-excellent performance at the same time (much better than Perl, PHP, and Java). The fact that it's an ANSI standard brings it much closer to "write once, run anywhere" than Java, and the large standard library makes certain programs even more portable than their C counterparts. So, the question is not "why Lisp?", it's "why not Lisp?".

hey,

If anyone has even used the strokes-mode in (X)Emacs, I have taken that to the X level by writing what is a higher-level application of gesture recognition. Consider this:

Why should each application implement gestures differently? For example WM commands (close, kill, iconify, maximize, resize, etc.) apply to all windows. Then, within each application, you might imagine some application-specific gestures. This can all be done at the X level. I decided to take the elisp code that's been doing gestures in (X)Emacs since '97 and ported it to Common Lisp (using GNU CLISP). This implementation if CL is GPL'd, and has an implementation of Xlib (called CLX) that plugs right in.

Anyway, CLISP is just about as portable as gcc is, so the same goes for the CL version of strokes.

What I havn't done, though, is to build a nice GUI for editing all the different strokes bindings for all the applications.

I've been playing with the idea of releasing this for years so that people could control all their applications using gestures. I figured that someone probably has done this (though probably not in Lisp, which is a shame).

Are people interested in X-level gestures?

dave

The best tools to build parsers and manipulate parsed syntax trees are functional languages, such as OCaml (with its streams parsers, camlp4, ocamllex/ocamlyacc, etc.), or SML, Haskell, etc.

Of course, if you were a LISPer, you'd know that although you have lots of well-known tools to build new parsers, such as Meta or Zebu, the best thing to do about a parser is not to write it, but rather to reuse the builtin extensible universal parser, READ, and its extensible universal unparser, WRITE.

If you spend most of your time writing parsers, you're not just using the wrong tools, you're also using the wrong approach.

Just my .2 mg of e-gold worth...

The best tools to build parsers and manipulate parsed syntax trees are functional languages, such as OCaml (with its streams parsers, camlp4, ocamllex/ocamlyacc, etc.), or SML, Haskell, etc.

Of course, if you were a LISPer, you'd know that although you have lots of well-known tools to build new parsers, such as Meta or Zebu, the best thing to do about a parser is not to write it, but rather to reuse the builtin extensible universal parser, READ, and its extensible universal unparser, WRITE.

If you spend most of your time writing parsers, you're not just using the wrong tools, you're also using the wrong approach.

Just my .2 mg of e-gold worth...

Common Lisp doesn't guarentee tail-call elision was my point =) It's just that all good compilers do it.

Are you aware of SBCL by any chance? It's a fork of CMUCL and while it's still very Unix-bound there's a lot of cleanup going on and development is quite active (so is CMUCL for that matter). Besides that there is OpenMCL, CLISP, and ECL all are being worked on, and even GCL might get its act together someday. You should visit CLiki and cCLan too, or stop by OPN #lisp. There are people out there making efforts, though they may not be as visible as someone like Paul Graham.

I can't tell whether you're being sarcastic or whether you really don't know about Common Lisp. Dynamic, strong typing, compilers and interpreters, great IDEs and debuggers, easy runtime modification and incremental compilation, flexible and powerful object system (including multiple-inheritance, multiple-dispatch, method combination... and the ability to modify its behavior), macros that have the full power of the language, etc...

Also see CLiki and The Common Lisp Hyper Spec

FYI, It was sold for quite a bit of money.

What is LISP bad at? Well, its libraries can be rather weak and nonstandard (although ANSI Common LISP itself comes with a large array of useful functions); GUI stuff, multithreading, and networking all fit in this category and are often implementation specific. (Of course, this is nothing to do with the language itself but just with what tools are available.) Its use for really low level bit-twiddling stuff is somewhat awkward. Iteration in LISP suffers somewhat from being only a little bit more powerful than iteration in C; the upside is you can still combine it with all the other great stuff in LISP, but the downside is that the parenthisis-style syntax, which is so much better for writing macros and functional code, only clutters up iterative code.

Multithreading is found in the commercial Common Lisp environments and in the CMUCL/x86 port. CLOCC maintains several libraries for cross-implementation usage of non-standard features such as networking. CLIM solves the GUI problem, the problem is that there was no free CLIM implementation for a long time due to legal issues. Finally, a free CLIM is being developed: McCLIM and I'm sure they can use help. As for iteration, perhaps your mind has been clouded by Paul Graham; who has an irrational fear of the LOOP macro. The LOOP macro, however, provides one of the most powerful iteration constructs I've seen; and it's not parenthesized like the DO macro is. Example:

(loop for x from 1 to 10 summing x do (format t "~&~A" x))

Prints out a list of numbers from 1 to 10 and the sum of them all at the end.
The equivalent DO:

(let ((sum 0))
(do ((x 1 (1+ x)))
((> x 10) sum)
(incf sum x)
(format t "~&~A" x)))

Also the LOOP macro provides yet more keywords for all sorts of handy features which aren't so easy to do with DO; collecting, appending, finally, initially, if/else, etc... Please read the section in the HyperSpec about LOOP, Section 6.1
I even once wrote a finite-state-machine entirely within a single LOOP macro that processed the Unix mbox format. It's quite nearly a language in itself (speaking of which, FORMAT is in a similar category, except for formatted output instead).

I would argue that CL is better at bit-twiddling than C is. Take a look at the CLHS Section 12.1.1.3.2 and the functions BYTE, LDB, and DPB. It's a different perspective than the C view, but more interesting since you can extract and replace any number of bits that you want. Also it's not dependent on 8 bits per byte.

Still, there are many areas where CL just doesn't have the sheer effort put into the libraries, likely due to the lack of manpower. Particularly in the Free-software category; Lisp has a tradition extending long before the current wave of Free-software and while many commercial vendors will provide good support and lots of libraries, the Free implementations often lack this. Many Lisp programmers use the commercial Lisps and have the features they want; if not they ask/pay the vendor to implement them. Another issue is that Common Lisp is not Unix-centric, unlike *ahem* most popular languages today. CL was designed to be workable in any environment, so the designers could not take shortcuts with things like pathnames, executable formats, system libraries, or other system-dependent issues. After all; Common Lisp was conceived in the era of the Lisp Machine. Unix was just another OS in the vast array. Finally, it is unfair to compare the Common Lisp standard against a single-implementation language such as Perl. Standards cost $$$$$ and require a great deal of effort and responsibility. If a Common Lisp implementation does not comply with the standard then it is at fault. But with Perl, whatever Larry Wall does goes. Even if it breaks all your code; too bad.

Some interesting sites with regard to libraries:

• CLiki
• cCLan

(Back to the OP's topic) Franz's Success Stories has plenty of examples of Lisp applications. Franz develops Allegro Common Lisp, a popular commercial CL.

Here are some, and some more, and a few others.

I personally use IMHO with mod_webapp to write web applications for work. People write similar things in Java, but Lisp is a far more suitable language due to the interactive runtime compiler and introspective capabilities. I find CLOS to be a better, more flexible object system for these tasks than the Java/C++ model as well. Multi-method dispatch, multiple-inheritance, call-next-method, :around methods, and even some Meta-Object Protocol I have used in my programs. And I nearly forgot the really neat HTML macros that let you write out HTML in s-expressions. It's much less clunky writing HTML in Lisp than HTML as HTML, especially in Emacs.

I personally use IMHO with mod_webapp to write web applications for work. People write similar things in Java, but Lisp is a far more suitable language due to the interactive runtime compiler and introspective capabilities. I find CLOS to be a better, more flexible object system for these tasks than the Java/C++ model as well. Multi-method dispatch, multiple-inheritance, call-next-method, :around methods, and even some Meta-Object Protocol I have used in my programs. And I nearly forgot the really neat HTML macros that let you write out HTML in s-expressions. It's much less clunky writing HTML in Lisp than HTML as HTML, especially in Emacs.

Portable AllegroServe can be found here http://sourceforge.net/projects/portableaserve

Well, the obvious answer, though perhaps not the one you're looking for, is to get one of several serious commercial, enterprise quality Common Lisp implementations. (Don't bother with Scheme.) But if you're feeling cheap or you're into "freedom" and such, you might find some answers at CLiki.

To the parent of previous poster, try http://ww.telent.net/cliki/ for a starting point or http://clisp.sourceforge.net/

The point about a decent editor is very true. I'm still suprised seeing people use Notepad or an old-skool vi (Vim, however, is very decent).

• http://www.franz.com/products/
• http://www.xanalys.com/software_tools/products/ide .html

More Lisp vendors:

• http://www.digitool.com/ (Mac)
• http://www.corman.net/

'Free' (whatever the current definition of that is nowadays) Lisps:

• http://clisp.sourceforge.net/
• http://www.cons.org/cmucl/

I'm not sure exactly what you mean by "domain-aware, learning type assistant" but CL compilers that check types are out there already

The compiler in CMUCL (called Python, but not to be confused with the language of that name), for example, has a very nice type inferencer in it already, and when you set your compilation settings appropriately will even warn you where it hasn't been able to infer things so you know what explicit declarations to add

See the appropriate bit of the CMUCL User Manual

(with-gratuitous-plug

If you want to try CMUCL on Linux you could probably do worse than scan through my CMUCL proto-HOWTO. )