Slashdot Mirror

You forgot to mention the even more impressive format function in Common Lisp that can print out roman numerals for you, not to mention its built-in iteration constructs, which you folks copied for your fmt function.

No language is perfect.

Wrong!

... it's that improvements to the language are made without breaking legacy support -- no compromise and at any cost.

Well, maybe if the C++ folk had designed a language that could absorb new paradigms and features without breaking or becoming syntactically unwieldy, it would be better.

There are a few problems with functional programming languages that have prevented their true adoption anywhere.

1. Limited paradigms - I always prefer languages that let me write my code the way I want, a la C++, than a language that requires a strict paradigm from academia like Lisp. If I want to use the inherent hardware property based side effects of certain code structures, let me. Programming languages =/= mothers.

Common Lisp (and Scheme, even more so, although the community is more oriented toward impure functional style) enforces no fixed paradigm. It can be used functionally (conses happen to be a pretty good data structure for functional algorithms), but is more often used in an object-oriented manner. It was even one of the first OO languages, and AFAIK the first to implement multiple dispatch. It even has a powerful imperative operators.

Thanks to macros and the metaobject protocol you can even add new paradigms to the language. Paternalistic, Lisp is not.

3. Most functional languages except Ocaml are like Ruby and Python in that they have tremendous performance overhead. For a consumer application, that overhead usually doesnt impede adoption (its more like the software is poorly written than the applications environment is too inefficient). But when talking about server programming the costs of running something under Ruby vs C are astronomical, and the same problem arises with functional programming. It might not hurt the consumer that the Python implementation of their music player consuming 30% more clock cycles than the exact same program written in C, but it does cause huge scaling issues with popular resources like Twitter.

4. In extension of 3, functional programming is getting away from how the hardware actually works. It is good for a novice that doesnt want to get into the details of pointers and caching and disk IO, but professionals should enter the game knowing how the underlying system runs and that making tradeoffs for readability by someone who doesnt know the language anyway vs performance benefits falls to the wayside. Developer time is important, but when you factor in the massive overhead trying to get 20+ year professional developers in C to try to think functionally you are never justifying the upfront cost of using the languages.

Languages like SML and OCaml are actually more optimizable than C. Thanks to providing more type information &c they can take advantage of fancy whole program optimization and whatnot.

The "way hardware works" is an artifact of C being the dominant language. There's no reason hardware couldn't (and it has before) have GC assistance, type checking, capabilities, etc. It's really not appropriate and scalable to view the computer as something that flips bits around a gigantic linear array... it was reasonable to deal with that when you had 4000 words, but not when you have 400000000 words.

Software is nice because you can abstract! Writing programs to a model of an infinite store that Just Works (tm) is beneficial to everyone -- it frees source code from a particular hardware implementation, is easier to reason with, and separates the concern of hardware resource management.

Lisp is used for a whole bunch of things in highly complicated current fields. Like aircraft ticket booking, stock trading, and missile defence:

http://www.franz.com/success/

http://www.lispworks.com/success-stories/

Yes, as the experiments clearly show: as long as you write tiny numerical computations and programs that require code-as-data anyway.

Those papers do not show, and their authors do not state, that such a qualification is justified...

toy examples aren't going to convince anyone.

...and if they had, they'd have made laughing stocks of themselves:

http://www.lispworks.com/success-stories/raytheon-siglab.html
http://www.franz.com/success/customer_apps/eda/amd.lhtml
http://www.franz.com/success/customer_apps/data_mining/itastory.php3 (also: http://www.itasoftware.com/careers/l_e_t_lisp.html?catid=8 )

etc.

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.

For Common Lisp, the Common Lisp HyperSpec is hard to beat, though at times a book like Practical Common Lisp can be a little more useful.

There's no need to clutter up source code with logging statements for debugging. Just trace appropriate functions as needed.

Whenever one uses pointers to members, one always winds up pairing it with a context pointer (this) anyway.

That's like saying that whenever one uses a function, one always winds up combining it with arguments: therefore function pointers are useless alone, they should always be bound with arguments when created. A pointer-to-member provides one more level of indirection than a delegate by making the target object a parameter. This parameter can be bound with an auxiliary class. C++ provides the support to make such classes behave very much like first class types.

Pointers to members are useful in their own right.By themselves, I don't agree. I've almost never seen any use for them in isolation.

I've found them useful for providing access to a private field or function of my choosing to a second class that will use it on multiple objects, i.e. an alternative to friend. The best part is that the target class can dispense different member pointers to provide different functionality, without modifying the calling class. An object can bottle an operation to be executed on an entire list of its peers, executed by a third party that needn't be privy to that operation.

No, only a subset, as unlike a true delegate, the pointer to member pair is bound to the class type. A delegate is bound to only the function signature.

A simple pointer to member is bound to the class type. However, any good C++ delegate class will not make the target class a part of its type: every compiler provides a way store a generic pointer to member, regardless of which class its a member of. As long as the delegate class guarantees that the class type and member pointer types match at runtime, it can safely cast to a generic pointer to member type. Users of the delegate class needn't worry about the details. The only remaining type information is the function signature.

This means that delegates can be nested functions, too. The various C++ attempts to do this require a lot of complexity and overloaded functions.

Any good delegate implementation will support static functions. It would be nice to have directly nested functions, but you can still have functions nested in classes nested in functions.

The only function I can think of overloading on a delegate class is the parenthesis operator to make invocation pretty. If comparison would be useful, the default binary comparison operator would be sufficient. I once created a Sink class that implements single argument delegates in 48 text lines. It only overloads operator (). I wouldn't call that complex. And it isn't hard to use:

struct C
{
int _x;
C(int x) : _x(x) {}
void f(int y) {cout << _x + y << endl;}
};

void f2(int y) {cout << y << endl;}

void g()
{
C c(6);
Sink<int> d(&c, &C::f); //a member function
d(5);
Sink<int> d2(&f2); //a non-member function
d2(11);
}

Granted, functions with variable arguments will require more work on the part of the library writer, but as a user of the class you don't have to worry about that.

That's an odd thing to say about a language that is, by far, the most complex core language ever devised.

Complexity isn't the same thing as implementing things in the core language that could be done in a library. Besides, there are definitely other language specs massive in size compared to C++'s: for example, Common LISP's specification is quite massive (about 1300 pages; there's a joke that Scheme LISP's entire language spec fits inside just the INDEX to index to Guy Steele's "Common Lisp: the Language, 2nd Edition"), and Perl certa

Scheme/Lisp/Erlang/others. Every one of these I've looked at has one fatal flaw: It's not JIT'ed, or compiled. Erlang can be compiled, but then you lose one killer feature: even if they're just bytecode-compiled, compiled functions cannot be replaced at runtime, the way other Erlang functions can.

• CMUCL
• SBCL
• ABCL (compiles to Java bytecode)
• CLISP (compiles to bytecode)

I know that in all of these you can replace a compiled function at runtime with another compiled function, both from personal experience and because the ANSI standard says so.

You seem to have made a mistake many people do: confusing Common Lisp with Scheme. Scheme is a useful language, but it's primarily a teaching language, and it's extremely limited. The simplicity of Scheme makes it useful as well as a simple base for embedded languages. However Common Lisp is far more useful as a language for developing large robust systems, because it doesn't force you to implement everything from scratch and much much more is standardized between implementations.

I don't want to be the cliché of the Lisp programmer saying "Lisp had it first", but I am amused when people find dynamic compilation new and exciting, or an integrated object system, or bemoan the lack of certification by a standards body.

I've taken no offense what so ever to this conversation.

Sorry, but everyone seems to take offense at everything here, so I've learned to just assume I should worry, and to write very defensively. Sigh. Glad to know there are others besides myself here who just come to offer and receive information, not to fight.

Some reasons I would not recommend scheme besides maintainence costs are: 1. Speed for some things, but if that's not important then it doesn't matter, though with Scheme you can always write the performance critical pieces in C or C++ and write an extension.

Likewise with Lisp if you needed it, you could always write a few subroutines in C/C++ and there are packages for doing "foreign" (some say it should be called "native") callout very straightforwardly. e.g., although Lisp will do array processing, if I had routines already optimized for doing (un)compression, display algorithms, raster effects, numerical algorithms, etc. I might just call those directly. The modern environment is heterogeneous, and the good implementations of CL accomodate that even though the standard stops short. It's enough similar that if you have to share between multiple implementations or you write in one and later port to another, it's likely to be a pretty modular accommodation.

2. Lack on an object system.

CLOS (the Common Lisp Object System) is pretty much the reference model for a good object system based on multiple inheritance. It's powerful, efficient, and flexible.

3. I'll talk about the maintainence costs again. Pyton, perl and other interpretted languages seem better at catching errors when loading the source code. This may just be the implementation of Scheme I have used (ELK). This definitely does not say anything about LISP.

I haven't used ELK so can't compare directly. In general, the Scheme standard is small and what made it usable was often the implementation details. (CL is bigger, so more of its usable stuff is common to all implementations, but even then, there are new things that are post-standard that are common to most implementations, yet really not standard.) Scheme has traditionally placed more of a premium on aesthetics and teachability, while CL more explicitly on the reverse (practicality over aesthetics). Traditionally, it has been individual Scheme vendors, rather than the language itself, that have had to tend to pragmatics, which has left some Scheme implementations hugely more usable than others. Common Lisp has been traditionally pragmatic, so the individual implementations, while they do vary somewhat, also tend to care about commonality more because that sense of shared community is built into the language itself. (I sat on both the Scheme authors committee for a number of years and on the CL design committee, so it gave me an interesting view of the differences, but I'm always fascinated to hear how users perceive it, since they often don't see either the intent or the process, just the effect.)

4. The exception mechanism is very rough. Error recovery in general is funny, though you can write your own very elegant error handling mechanisms.

If you want a flavor of what the Common Lisp condition system offers, you could see my 1990 paper and my 2001 paper, each of which touch on this in different ways.

5. Lack of data structures such as O(log(n)) maps and sets, though you can roll your own...

Common Lisp has built in hash ta

I think the remarks others have made about cross-platform issues are good ones, but I would add to that one other important comment: Don't make a big fuss about why not to use VB unless you're prepared to offer a substitute. If you do have a substitute, focus on its good qualities rather than on VB's bad ones. Show what additional things you could do if only you had that other choice. Sounds more positive that way.

I do a lot of Scheme too, but I'd be an idiot to recommend that to you!

Common Lisp is industrial strength, scales well to large applications, and works cross-platform. For example, LispWorks offers a Common API (CAPI) that allows writing portable code for deploy on Mac/Windows/Linux.

Not unless I want to have my clients pay a runtime fee for every running copy of the software.

Apparently, there's this rumour that all commercial lisps charge runtime royalties. This is not true, and such a rumour spreading would be disastrous to lisp vendors.
Who you're talking about is Franz. Franz wants to be your your business partner, that's what they say on comp.lang.lisp. ;-)
Other vendors aren't so mean, e.g., LispWorks (the havey Lisp for UNIX, Windows and Mac OS) and don't impose a sick licensing scheme like Franz. The LispWorks LispWorks reads:
"Q. What's the royalty for delivering my own application?

A. End-user applications delivered from the Professional and Enterprise Editions are royalty-free, including those using LispWorks ORB, KnowledgeWorks, Common SQL or CLIM 2.0. We believe this is the least restrictive commercial Lisp deployment model available."

Not unless I want to have my clients pay a runtime fee for every running copy of the software.

Apparently, there's this rumour that all commercial lisps charge runtime royalties. This is not true, and such a rumour spreading would be disastrous to lisp vendors.
Who you're talking about is Franz. Franz wants to be your your business partner, that's what they say on comp.lang.lisp. ;-)
Other vendors aren't so mean, e.g., LispWorks (the havey Lisp for UNIX, Windows and Mac OS) and don't impose a sick licensing scheme like Franz. The LispWorks LispWorks reads:
"Q. What's the royalty for delivering my own application?

A. End-user applications delivered from the Professional and Enterprise Editions are royalty-free, including those using LispWorks ORB, KnowledgeWorks, Common SQL or CLIM 2.0. We believe this is the least restrictive commercial Lisp deployment model available."

I've used to have rather profound C++ experience (about ten years now). I've wrote a Race-Track Microtron control system in it and some other stuff like that, really :-) But I still fail see in which way it's better than Lisp, besides some (but not 10x-20x as when compared to languages like Python in Perl) performance gain, which is not always critical. It's possible to write applications, device drivers and operating systems in it, as well as databases, compilers, GUIs, web applications and lots of other stuff in it. I have some doubts concerning hard real time, but given the fact that GC can be locally avoided/inhibited using rather simple techniques, I think there should be no much problems there. C++ experience is useful thing, but I think that Lisp is in no way less important.

It really pleases me as a (semi-)closet Lisp programmer to see such extensions, as they closely resemble something so near to my heart, such as this or this ;-)

It really pleases me as a (semi-)closet Lisp programmer to see such extensions, as they closely resemble something so near to my heart, such as this or this ;-)

There definitely are "good libraries with multiplatform support", and I listed a few of them elsewhere in this topic.

As for "Visual Lisp", if what you mean is a powerful IDE for Common Lisp, the commercial implementations have had these for years. Download the trial versions of Allegro Common Lisp and LispWorks and take them for a spin. They're expensive to license, but they're also (arguably) the best implementations of Common Lisp you'll find.

The function names don't make sense to most people who have been raised on higher-level (1980s+) languages. I mean, 'car' to grab the first element of a list, and 'cdr' to grab all the others? It can get downright confusing sometimes.

The function names don't make sense to most people who have been raised on higher-level (1980s+) languages. I mean, 'car' to grab the first element of a list, and 'cdr' to grab all the others? It can get downright confusing sometimes.

I mean something that highlights the logical structure of what's going on. The most trivial example is probably picking out sequential vs. iterative vs. conditional logic in algorithms. Of course you can do these things in LISP, via cond and such, but there's no particular emphasis on them; they just look like any other bit of LISP.

That's true for most languages. Many languages, like C, Perl, and Java, don't diffferntiate between how a condition is used. It's simply a condition. Others, like COBOL and even Common Lisp, take a more natural language approach to loops (i.e (loop for i from 1 to 10 do ...)). Python also has a natural language like loop syntax, but its loops are primarily of the "for each element in" type, which makes them only marginally more clear than C's (i = 0; i < 10; i++).

Actually, let me backtrack on that statement. Yes. Lisp's use of parens in atypical, especially when parens are typically only used in arithmetic and logical expressions in Algol like languages. That said, syntax is a pretty trivial thing especially when there's much bigger things like expressability to be concerned with.

I realise that this is necessary in a language that prides itself on simple-but-flexible syntax, and indeed that a lot of LISPers would argue that it's an advantage, but experience suggests that most programmers prefer something a bit more explicit.

Maybe you thought that, but I don't think you've had much experience using Lisp.

Consider, for example, the loop example shown here (scroll down a page or so). While the Scheme code shown has power and a certain elegance, the same algorithm could have been written significantly more clearly and concisely in a language that provides syntactic sugar for list manipulation and pattern matching.

First off, that's Scheme not Common Lisp. Scheme has some interesting and unique features that differ it from Common Lisp and pretty much other every other language out there. For instance Scheme is has first-order proceedures, where Common Lisp does not. (Symbols have both function-value and a seperate symbol-value in CLISP.) Scheme also has continuations, which I believe is a unique feature among all languages.

That said, the example shows an ass syntax, but that's not the way loops are typically done in CLISP. Instead there's widespread use of the loop macro, which has gobs and gobs of syntatic sugar. So much so, a loop statement resembles an English language sentence. The loop macro also has a handy collect mode that makes the loop return a list containing the value of the last expression on each iteration through the loop. For instance (loop for i from 1 to 5 collect i) would return the list (1 2 3 4 5). It's quite useful.

I don't know what you think counts as "most things that are in standard libraries", so I'm going to guess that you're talking about the minimalist approach taken by, say, C.

And C++.

I'm talking about the behemoth that is Java's standard library, or a rather more powerful approach like Perl's CPAN.

It's hardly fair to compare CPAN to anything. CPAN pretty much let's anyone who has thrown some code and perldoc together to submit. It's more like freshmeat than any sort of standardization group. This isn't a knock against CPAN. CPAN is great. I use it all the time. I wish more langugages had a clearinghouse like Perl. But CPAN is by no means "a standard library", since there's no standardization going on what so ever. Yes, certain CPAN packages are included with each Perl release, but not all 15 slightly incompatable MIME modules make the cut.
In fact, I don't believe any MIME module is included in the standard distribution. If you want to talk about Perl's standard library,

If all you have is a hammer, all your problems start to look like nails. If all you have is LISP, all your problems start to look like recursion.

It simply isn't true that lisp forces you to do everything recursively. Common Lisp has a well documented iteration facility through the LOOP and DO macros. These macros have existed for decades. And yes, they are real iteration, not recursion.

Common Lisp also supports object oriented programming natively through the use of generic functions. Yes, it's a bit different from message passing architectures like C++ and Java, but it is much cleaner and natural than say Perl's bastardized OOP concepts.

And yes, I Lisp daily.

"Where is the development environment that is as simple to use as lego blocks which anyone over the age of 6 can use to quickly create powerful apps?"

Of course there is.

And for the big boys, there is this.

The problem with dynamic languages, like Python, is that they can't be easily compiled to native code and optimized.

Ok, so all the highly- optimizing Common Lisp compilers are fakes?

Or maybe you have no idea what you're talking about? I'm guessing the latter.

Personally, I've used Macintosh Common Lisp (now from Digitool) since it was available from Apple, but I've tried Lispworks (since that's what I use on a Linux box at work), and CLISP of course. Most of the other versions, including Franz's, I've used in the past on other platforms (Sun) since I lost my beloved Symbolics box. MCL was by far the best experience under OS9 and prior, though the user interface elements haven't completely tracked the change to OS X, though I usually use CLIM anyway for code portability so we're really just talking look and feel issues. The Xanalys product is very nice, the demo is pretty unrestricted (just the continuous time to use it, and inability to dump images so you need to load up your system after you start - pretty reasonable for what you get), and the full unrestricted version isn't too expensive.

If you're just starting out and want to poke around, I'd have to recommend Xanalys personal as the best bang for the buck, since you get a pretty nice IDE with it (though Digitool's might be easier to learn if you're used to OS 9). Once you get to the point of needing to dump applications, you can either spend the money to upgrade to professional, or use one of the free lisps to dump images. Your main limitation in these alternatives will be the user interface, as that is generally unique to the implementation unless you use CLIM (and CLIM is not free) or something like Garnet, neither of which will give you something very mac-like.

Personally, I've used (now from Digitool) since it was available from Apple, but I've tried Lispworks (since that's what I use on a Linux box at work), and CLISP of course. Most of the other versions, including Franz's, I've used in the past on other platforms (Sun) since I lost my beloved box. MCL was by far the best experience under OS9 and prior, though the user interface elements haven't completely tracked the change to OS X, though I usually use CLIM anyway for code portability so we're really just talking look and feel issues. The Xanalys product is very nice, the demo is pretty unrestricted (just the continuous time to use it, and inability to dump images so you need to load up your system after you start - pretty reasonable for what you get), and the full unrestricted version isn't too expensive.

If you're just starting out and want to poke around, I'd have to recommend Xanalys personal as the best bang for the buck, since you get a pretty nice IDE with it (though Digitool's might be easier to learn if you're used to OS 9). Once you get to the point of needing to dump applications, you can either spend the money to upgrade to professional, or use one of the free lisps to dump images. Your main limitation in these alternatives will be the user interface, as that is generally unique to the implementation unless you use CLIM (and CLIM is not free) or something like Garnet, neither of which will give you something very mac-like.

There are a few Common Lisp implementations as well

Open Source:

Open MCL
SBCL

Commercial:

Macintosh Common Lisp
Allegro Common Lisp
Xanalys Lispworks

gene

Please note that if you learn real, modern lisp, you kinda get both anyway- ANSI standard Common Lisp requires in-language integrated debugging facilities, including a tracer and a disassembler.

Please note that if you learn real, modern lisp, you kinda get both anyway- ANSI standard Common Lisp requires in-language integrated debugging facilities, including a tracer and a disassembler.

Because everybody sees the parens and runs like hell. "Aaaah! Its syntax is not like C's!"

Because Lisp is seen as the language of the smartest coders, and therefore inaccessible to the masses. While it is (IMHO) the language of the smartest coders, that doesn't mean the language itself is inaccessible. However, the things that the smart people can do with it may be. (Imagine explaining shell scripts to somebody who's been using command.com all their life.)

Because there's a lot of Lisp myths still floating around.

Because most programmers and PHBs don't realize that different languages make different problems easy, so they assume that everybody can use a language that is widely-known. This language is almost always a clear ALGOL descendant. As peoples' careers spread, they learn other ALGOL-descended languages, and decide that all computer languages are pretty similar. This perpetuates the problem.

Because there's still a lot of repressed resentment among PHBs who associate it with AI, which was the .com bust of the 80s. A lot of the PHB culture has forgotten the AI heyday and bust, but they haven't forgotten the prejudice against Lisp.

Because most PHBs learned a week's worth of Lisp-- often something ancient like LISP 1.5-- in college, and assume that they learned all it had to offer.

I'm not coming off as bitter, am I?

Sorry, but you're comparing apples and oranges here. LISP is adheres more to a completely different programming paradigm (functional programming) as opposed to Java/C/C++ and all the other OO languages.

If you actually believe this, you don't know Lisp very well. While Schemers often emphasize the functional use of their language, Common Lispers move about as they wish in the realms of procedural, object-oriented, and functional programming in order to most easily solve their problems.

You might have a look at the Table of Contents of the Hyperspec to have a better idea of the things available in Common Lisp as a language proper, and something like Cliki for links to Lisp libraries and such whose source code will indicate how people actually program in Lisp these days.

Sure.

Common Lisp

ANSI Common Lisp standard (X3.226-1994)

Popular commercial implementations:

Allegro Common Lisp
Xanalys Lispworks
Macintosh Common Lisp
Corman Common Lisp

Popular free implementations:

CMUCL
CLISP
Open MCL
SBCL
GCL

All of these implement the Standard, some better than others. All have interesting extensions which are not portable. All bring different elements of interest to the table of developers looking to solve different problems.

Perl and Python haven't for whatever reason needed to be forked to provide a better implementation for a specific market segment. While large applications are being written in these languages, they're obiviously not in environments where the demand on the engines is high enough to warrant someone funding a fork and a port. (say, Perl for Palm, or Embedded Python, or Enterprise Ruby, whatever -- there is no complete "Python Compiler", for example, that I'm aware of at least). Though ActivePerl et al should be acknowlegded.

BEA has JRockit which is its own JVM, though it may well ship Suns class library. They felt that they wanted a better JVM to meet their markets needs better than IBM and Sun were.

Put an implementation to work and the market will fork it as necessary. Just ask MS.

That's why languages with paradigms that don't translate well onto von Neumann-y notions (eg, LISP or Prolog) are interpreted as a rule.

• CMU CL: natively compiled
• SBCL: natively compiled
• MCL: natively compiled
• OpenMCL: natively compiled
• Xanalys LispWorks: natively compiled
• Allegro Common Lisp: natively compiled
• Corman Common Lisp: natively compiled
• Scieneer Common Lisp: natively compiled
• Embeddable Common Lisp: natively compiled, via GCC
• GNU Common Lisp: natively compiled, via GCC
• GNU CLISP: bytecode compiled
• Armed Bear Lisp: Interpreted, only used as an extension language for an unpopular editor

I am a happy user of Common Lisp, which supports imperative, functional, OO etc. out of the box. But what is more important is that the language itself is extensible. It is a rather common approach to write applications by first extending the language, and such extensions can go quite far. For example, people have integrated prolog style logic programming into Lisp, there are libraries that support nondeterministic evaluation and backtracking, prototype-based alternatives to the native OO system, dataflow, you can use it as a dynamic markup language etc. The nice thing is that all this gets part of the Lisp system just like the builtins, so that a programmer can mix and match all of these, and the features of CL itself.

Paul Graham has written a really cool book on that topic, which is freely available.

There are enough people using Lisp to sustain it as a community. This means that if you want to use it, you won't really want for support - it's an acceptable choice. So, if you can "turn your head inside out" you'll get a lot of advantages for it.

BTW, I still enjoy using my HP48GX, and HP has their new 49G+ out, with a 75MHz ARM processor and a SD slot. It's far beyond any other calculator on the market. Sometimes the slightly more difficult syntax has great advantages :-)

The Rete algorithim (Rete: A Fast Algorithm for the Many Pattern/Many Object Pattern Match Problem by Forgy in Artificial Intelligence 19, September 1982) is an efficient solution to a problems given in a specification that should never be used because of conceptual nastiness.

The attractive promise of declarative rule-based systems is that each "fact" (base or implicational) in the problem domain can be stated as a rule. But this is hardly the case in Rete based systems.

The Rete algorithm was designed to efficiently implement the non-monotonic forward chaining "blackboard" paradigm. A Rete inference system has a "blackboard" of facts that a large number of rules monitor, and when the some facts on the blackboard match the condition of a rule, the rule can fire and add information to the blackboard (monotonic) or change or delete information from the blackboard (non-monotonic). The main conceptual issue in this sort of system is what to do when the blackboard satisfies more than one rule. The problem is that firing one rule may change the blackboard so that another rule that could have fired can no longer do so. So Rete ranks the applicability or rules.

Thus a blackboard system winds up with rules whose meaning is not just contained in a rule but has to be inferred from all of the other rules that might be fired by similar input conditions. Most Rete based applications I've looked at wind up using the blackboard to essentially implement program counters to control program flow. And in general, adding a new rule may generate new solutions but it also may break prior solutions.

Pure monotonic systems (with forward and/or backward chaining) are conceptually very easy to analyze because all of the "facts" are truly independent.

One can add a form of non-monotonic behavior to monotonic systems by ranking their solutions. E.g. a monotonic system generates N solutions but ranking via some ordering prunes these down to say 1 or 2 best solutions. This external ranking is non-monotonic because adding new facts to the monotonic part may result in different "best" solutions.

So, basically I am advocating an inference system which is conceptually defined as results = rank(infer(facts, data)). If these functions have good mathematical definitions then it may be possible to implement their combination so that ranking controls or happens during the inference process but the results look as if it was external, and thus one avoids the computational horror of over-generation by the "infer" function.

Rete however explicitly and globally performs the ranking process during inference and an arbitrary Rete rule set is probably NP complete to analyze. But maybe a good implementation of a conceptual separation of "rank" and "infer" could be realized by a Rete-like network.

princable

Is that the name of the thing that connects my Laserjet to my computer? :P

No, it means you can use the lisp function princ on the object in question.

For a more cross-lisp portable approach, there's always CLIM, the Common Lisp Interface Manager, with implementations for ACL, Lispworks, Macintosh CL and others. A free version is in the works, right now it runs on CMUCL, SBCL and OpenMCL (well, to be honest it walks more than it runs). CLIM is a really cool API, very lispy, but the implementations tend to lack somehow in the eye candy department.

As for online resources, a good place to start is probably the cliki, a CL-related WikiWeb with emphasis on free software.

There are some free online books, like Successful Lisp, Loving Lisp - the Savy Programmers Secret Weapon, or Paul Grahams On Lisp (which isn't really a beginners book, but very enlightening once you are familiar with the basics). The Common Lisp Cookbook is not as big as it should be, but does contain useful information, and is growing.

An absolutely invaluable reference is the HyperSpec, a heavily hyperlinked online version of the standard. You definitely need that.

You might also want to check out the comp.lang.lisp newsgroup, or the #lisp channel at freenode. Depending on your specific interests, the LispWeb or Clump mailing lists may be interesting, the first deals with web programming using Lisp (surprise!), the second with general application developers issues.

Last but not least, there has been a movement of Lispniks gathering to drink beer and talk about all things Lisp (and everything else) in the last months. Check out this site, maybe there's a user group in your area. The people I've met so far are generally a nice and interesting bunch, and won't bite you even if you don't know the argument lisp of update-instance-for-redefined-class from the top of your head.

Happy hacking!

IMHO, the problem with Swing is mostly that it is horribly overengineered and, frankly, that the implementation sucks. It's all in src.jar - read it and tell me if you would hire someone who would present that piece of crap as their prior experience.

Oh, it's about static languages. Never mind.

While it won't stop you there is packages and namespaces. Common Lisp sperates the notion of "you can't touch this" (packages and you can still touch if you really want to) from objectness.

Common Lisp doesn't have "access modifiers" because they wanted open access.

So you loose on those too. :-) Now if you had said Design by contract (Effiel), Declarative pattern specifications (SML), Safe and Unsafe dataypes( Modula-3), Predicate Classes (Cecil), etc. I'd be more apt to aggree. But the vast majority of the "new age" stuff in these "mainstream" languages (Java, C++) ...... been done....

static type checking is not what Jackpot is about. And there is slippery slope between parametric types and macros.

P.S. Jackpot sounds very similar to this..... Refine

Ooooh Look there that pesky Common Lisp again....

P.P.S. Common Lisp has many more datatypes than just lists. (hash tables, structures/records, vectors, pathnames, restarts, exceptions, ....... ). Most "intro to lisp in a quarter/semster" don't touch on these... but that is a much longer topic.

HyperSpec

P.P.P.S. An AST and a nested list are quite similar if you'll look past the lisp surface syntax. Draw it out in Lisp cons cell box and pointer representation if you wish.

I wouldn't say that I always need type safety in all it's glory - actually, when I deploy, I usually change optimization settings to disable most automatic checking. I like it during development, though. In case you aren't aware of, Common Lisp allows you to declare types, but doesn't force you - if you do, they can be either used as assertions, notifying you when you fucked something up, or as an optimization hint. As opposed to C, which forces you to declare all types at all times, and yet fails to be strongly typed, thus giving you optimization as the only choice, even where you don't need it.

I guess the major difference is that bad Lisp programmers will produce code that runs slowly, while bad C programmers (and these obviously include the authors of Linux, Apache, OpenBSD or OpenSSL, which all had C-typical vulnerabilities) will produce code with exploitable bugs. Buffer overflows or format string errors just don't happen with Lisp, because arrays are bounds checked (and may be size-adjusted, if you want them to), and cl:format, while more powerful than printf, just wont let you play tricks with the stack. At least not unless you explicitly ask for it.

Not to mention that Lisp actually rocks for bit fiddling, compared to C: not only are all relevant binary operators availabe (and them some, let alone the ability to convenitently extend the language if something is missing), I also have the ability to arbitrarily mess with memory locations. I just don't see why I should. I have other things to do, like solving real problems that are not ideally described in terms of binary numbers of various lengths.

I wouldn't say that I always need type safety in all it's glory - actually, when I deploy, I usually change optimization settings to disable most automatic checking. I like it during development, though. In case you aren't aware of, Common Lisp allows you to declare types, but doesn't force you - if you do, they can be either used as assertions, notifying you when you fucked something up, or as an optimization hint. As opposed to C, which forces you to declare all types at all times, and yet fails to be strongly typed, thus giving you optimization as the only choice, even where you don't need it.

I guess the major difference is that bad Lisp programmers will produce code that runs slowly, while bad C programmers (and these obviously include the authors of Linux, Apache, OpenBSD or OpenSSL, which all had C-typical vulnerabilities) will produce code with exploitable bugs. Buffer overflows or format string errors just don't happen with Lisp, because arrays are bounds checked (and may be size-adjusted, if you want them to), and cl:format, while more powerful than printf, just wont let you play tricks with the stack. At least not unless you explicitly ask for it.

Not to mention that Lisp actually rocks for bit fiddling, compared to C: not only are all relevant binary operators availabe (and them some, let alone the ability to convenitently extend the language if something is missing), I also have the ability to arbitrarily mess with memory locations. I just don't see why I should. I have other things to do, like solving real problems that are not ideally described in terms of binary numbers of various lengths.

I wouldn't say that I always need type safety in all it's glory - actually, when I deploy, I usually change optimization settings to disable most automatic checking. I like it during development, though. In case you aren't aware of, Common Lisp allows you to declare types, but doesn't force you - if you do, they can be either used as assertions, notifying you when you fucked something up, or as an optimization hint. As opposed to C, which forces you to declare all types at all times, and yet fails to be strongly typed, thus giving you optimization as the only choice, even where you don't need it.

I guess the major difference is that bad Lisp programmers will produce code that runs slowly, while bad C programmers (and these obviously include the authors of Linux, Apache, OpenBSD or OpenSSL, which all had C-typical vulnerabilities) will produce code with exploitable bugs. Buffer overflows or format string errors just don't happen with Lisp, because arrays are bounds checked (and may be size-adjusted, if you want them to), and cl:format, while more powerful than printf, just wont let you play tricks with the stack. At least not unless you explicitly ask for it.

Not to mention that Lisp actually rocks for bit fiddling, compared to C: not only are all relevant binary operators availabe (and them some, let alone the ability to convenitently extend the language if something is missing), I also have the ability to arbitrarily mess with memory locations. I just don't see why I should. I have other things to do, like solving real problems that are not ideally described in terms of binary numbers of various lengths.

I wouldn't say that I always need type safety in all it's glory - actually, when I deploy, I usually change optimization settings to disable most automatic checking. I like it during development, though. In case you aren't aware of, Common Lisp allows you to declare types, but doesn't force you - if you do, they can be either used as assertions, notifying you when you fucked something up, or as an optimization hint. As opposed to C, which forces you to declare all types at all times, and yet fails to be strongly typed, thus giving you optimization as the only choice, even where you don't need it.

I guess the major difference is that bad Lisp programmers will produce code that runs slowly, while bad C programmers (and these obviously include the authors of Linux, Apache, OpenBSD or OpenSSL, which all had C-typical vulnerabilities) will produce code with exploitable bugs. Buffer overflows or format string errors just don't happen with Lisp, because arrays are bounds checked (and may be size-adjusted, if you want them to), and cl:format, while more powerful than printf, just wont let you play tricks with the stack. At least not unless you explicitly ask for it.

Not to mention that Lisp actually rocks for bit fiddling, compared to C: not only are all relevant binary operators availabe (and them some, let alone the ability to convenitently extend the language if something is missing), I also have the ability to arbitrarily mess with memory locations. I just don't see why I should. I have other things to do, like solving real problems that are not ideally described in terms of binary numbers of various lengths.

I wouldn't say that I always need type safety in all it's glory - actually, when I deploy, I usually change optimization settings to disable most automatic checking. I like it during development, though. In case you aren't aware of, Common Lisp allows you to declare types, but doesn't force you - if you do, they can be either used as assertions, notifying you when you fucked something up, or as an optimization hint. As opposed to C, which forces you to declare all types at all times, and yet fails to be strongly typed, thus giving you optimization as the only choice, even where you don't need it.

I guess the major difference is that bad Lisp programmers will produce code that runs slowly, while bad C programmers (and these obviously include the authors of Linux, Apache, OpenBSD or OpenSSL, which all had C-typical vulnerabilities) will produce code with exploitable bugs. Buffer overflows or format string errors just don't happen with Lisp, because arrays are bounds checked (and may be size-adjusted, if you want them to), and cl:format, while more powerful than printf, just wont let you play tricks with the stack. At least not unless you explicitly ask for it.

Not to mention that Lisp actually rocks for bit fiddling, compared to C: not only are all relevant binary operators availabe (and them some, let alone the ability to convenitently extend the language if something is missing), I also have the ability to arbitrarily mess with memory locations. I just don't see why I should. I have other things to do, like solving real problems that are not ideally described in terms of binary numbers of various lengths.

CLISP is a fairly well-established implementation but due to some reason I cannot fathom, the implementors choose not to be fully ANSI-compliant. You won't notice it at first, but if you get into advanced object-system hacking CLISP will become unsuitable. Also, it's a byte-code interpreter system. This severely affects performance (except in bignums, due to some numerical methods magic), but it does have a smaller memory footprint. And it's widely ported.

CMUCL does purport to be a complete ANSI-conforming implementation, and it has a high-performance native-code compiler. But it's not ported very much (some ports have gone unmaintained) and only to Unixy systems. The current maintainers are interested mostly in features and speed, whereas...

SBCL is a fork of CMUCL, with the goal of being more easily maintained, cleaner, and conforming. It's also more widely ported now, having resurrected some of the old CMUCL ports and added some new ones (someone is working on OS X now). SBCL has been adding features back that were dropped, sometimes improving, for example, kernel-threads recently (vs user-threads in CMUCL).

Lately they've been driving the development of each other, since many patches can be cross-ported easily. This is all the better for the users :-).

I use CMUCL for most of my work, which involves database-driven web-app development, and it works fine. Though I am thinking about switching to SBCL soon, with nice features like kernel-threads coming around. Well, presumably I would be able to use either. I use libraries like AllegroServe (HTTP server), UncommonSQL (RDBMS OO interface), and IMHO (web apps w/Apache).

Neither work on Windows (yet) so there you would need to look into Allegro, LispWorks, or Corman Lisp (which I forgot to list in the previous post). All these are native compilers that can produce Windows applications. There are no free compilers for Windows which produce native code, afaik. You can investigate GCL or ECLS, which compile to C and may work under mingw. The commercial compilers all have GUI toolkits or bindings to the Windows API. Allegro is probably out of your price range, LispWorks is ~$900 and Corman is ~$150. All have free personal editions to play with.

Why do I say Scheme isn't as practical? Well, most Scheme implementations aren't anywhere near the same quality as the CL ones (with a few notable exceptions) and they all have to implement incompatible supersets of the language (because R5RS defines approximately nothing). Personally I think the design of Scheme itself works against practical usage and implementation, but there are those who disagree. In universities they teach Scheme, but as I was saying, as an academic exercise and not something to be used in industry. Which is a real shame.

Anyway, if you want a learning environment, I recommend the LispWorks personal edition IDE (Linux, Windows, Unix, and soon OS X). This will get you started with a minimum of fuss. Later on, you can setup Emacs with the ILISP package and interface with your CL implementation; this is a popular way. Or you may find some other IDE. The minimum needed really is parenthesis-matching and auto-indentation. After that you might like interactive features such as shortcuts to compile code-fragments, documentation at a keystroke, easy access to a Lisp listener, inspector, debugger, etc.

There are many books, such as Paul Graham's ANSI Common Lisp, Peter Norvig's Paradigms of AI Programming, online tutorial Successful Lisp, and sites such as CLiki with lots of pointers to resources.

CMUCL
SBCL
LispWorks
Corman Lisp