Alright.
I''ve spent about a month working on clisp- writing various functions, mostly dealing with string handling and analyzing.
I have experienced no evidence that clisp provides any superiority relative to my personal favorite imperative language, C++.
It of course provides better facilities here and there; however, I see no advantage compared to a well-written imperative library.
Could I please see a clear, obvious example where the lisp paradigm makes programming a solution easier?
I''m not trying to make a c++ vs. lisp war, so no flames.
I''d just like a well-written example or two, or even a link to one.
Thanks alot.
~V''lion
Bugle4d

Worse is Better, Richard P. Gabriel''s thoughts on lisp and imperitive languages. Warning: he doesn''t come to any conclusions. The papers he links to come out in support of lisp and against lisp. And they''re all written by him. I just think they''re fun reads. Of course, I have a twisted definition of fun.

I could see a few reasons why Lisp is superior to other development platforms in application development due to code is data and data is code paradigm. If you''re interested dig up an old Lisp vs. XML thread. This superiority is minimized with recent advancements in .NET where classes are easily serialized into XML and back, and source code is generated from XML schema in a few seconds. Of course theoretically Lisp is still more powerful but practically .NET platform provides everything you need to successfully do data parsing, serialization and storage.

I do not see how Lisp would be superior specifically for AI. Of course I''m not a Lisp expert (I never wrote more than a few lines of code in it). May be someone else can give you a more qualified response.

quote:Original post by Extrarius Have you read What is so great about Lisp? and Lisp is King? They both contain a lot of information. Yes they are long, but if you haven''t read them I think it would be worth it to do so.

Lisp''s simple syntax lends itself to easy manipulation of the language. You can modify the language to suit your needs exactly and archieve abstraction levels higher than imaginable for most C++ programmers. If you don''t know macros and how to use macros well, you don''t know Lisp.

With Lisp, it''s relatively easy to create an actual compiler for a language of your own. Languages that deal with some subset of first order logic are pretty useful in AI. In C++ you have to settle for interpreting any sub-language you need, unless you''re going to use unimaginable amount of time to actually write a compiler for the job. With Lisp, you can compile code at run-time and run code at compile-time. Have you toyed with template metaprogramming in C++? It''s considered to be a hot topic these days since modern C++ compilers are starting to make it possible, but it''s a completely inferior system to what has been used in Lisp for ages through it''s macros.

Read Paul Graham''s On Lisp (free of charge):http://www.paulgraham.com/onlisp.htmland you won''t want to go back to C++ again

quote:Very. The C++ paradigm has taught you to work within its own limitations. You must explicitly define the exact structure of a class or struct and then work with it. Lisp doesn''t impose this on you. Lisp works well with incomplete data, or data structures which grow according to the evolving data that is being acquired.

From Lisp is King thread.

The last sentence illustrates a common thing I''ve heard WRT lisp- its flexibility.

Could I see some hard code here regarding that? Its a pretty thing to say, but due to my inexperience, I don''t perceive how to do that in clisp.

Anyway:I still don''t see why lisp is conclusively better than a well-written imperative langauge with a good library behind it.I''ve even looked through a goodly portion of On Lisp and don''t see why.

Really, I can''t think of any examples that would show how flexable lisp is without being complete programs. It is very difficult to find trivial examples that really demonstrate how usefull features can be =-/First, realize that Common Lisp is NOT the best language at everything (nor is any other language). There are some things, such as systems programming (drivers, OSes, etc) that are possible but not easily or best done in Lisp. Common Lisp is a good general purpose langauge that allows you to focus on more abstract things than byte alignment and calling conventions. While it isn''t as fast as native-compiled C++, it is close, and definitely fast enough for many, if not all, games and other real-time applications. Note that the speed depends quite heavily on which compiler you use. I don''t know about clisp (it might even be only an interpreter), but Corman''s compiler is quite good and makes fast code (an absolute measurement, I don''t have anything to compare it to).

The best example of flexibility I can think of (probably because its the only thing I''ve used Lisp for so far) is genetic programming. In C++ or some other low-level language, creating a genetic programming library would either require all kinds of trickery with assembly and manually managing the calling conventions of functions OR implementing an interpreter. In Lisp, you can just use the list functions to make a list, (optionally) compile it at runtime, and then execute it as if it had always been there. Since Lisp code is represented as a list, and Lisp (LISt Processing) is good at manipulating lists, it is also quite easy to manipulate code. I haven''t quite finished my implementation of GA yet so I don''t have much code to post, but it took me about 1 day to get a basic code generator up and running and spitting out random formulas with next to no Lisp knowledge (most of the time was spent looking up things in ''ANSI Common Lisp'' because I didn''t know the language at all =-). In that time, I wrote ~100 lines of code that can create a random numerical expression and have it ready to be executed. The operators allowed in the expression, the number of arguments each takes, and the variables the function operates on are all customizable by a few global variables. The only reason I haven''t finished it is because I''ve moved on to making my own Lisp interpreter (which turned out to be a lot harder than I thought it would).

Since you like C++ you may also appreciate OOP. It''s interesting that the Common Lisp object system (CLOS) was not created by heavily modifying the Lisp language (or modifying it at all actually). Instead, it was added as a sort of library, as an embedded language. You cannot even begin to imagine some such wizardry in the C based crowd of languages.

Lisp changes the way you think. It''s a very slow process, but it is real. No longer do you ask yourself "what is the best way to use this language to solve this problem?", but "what is the best language to solve this problem?". You stop being a slave of a single language, of its particular way of thinking and of the limited things you can express in that language - instead each language gives you ideas of things you can say in Lisp. Prolog, CLIPS, GPSS or XML Schema - all look at programming in different ways - but you can have their philosophies directly imported in Lisp.

I think the following quote from one of the three guys who specified the Java language sums Lisp up quite nicely. As Fortran is imperitive, his quote can also be applied to C++/Java etc.

quote:"If you give someone Fortran, he has Fortran. If you give someone Lisp, he has any language he pleases. –Guy L. Steele Jr"

If you write a library to interface to a database in C/C++, you end up with librares, classes/methods that must be called to interface to the database. If you do the same in Lisp, you end up with a language like SQL that becomes integrated within Lisp.

You may point out that the standard way to interface to a database in C/C++ is via SQL. However someone would have had to have written the SQL parser that translates the SQL expressions into a lower level language. In Lisp the parser is never written, SQL just becomes a direct extension of Lisp.

If you write a game in C/C++, you end up with a game as well as libraries, classes/methods. If you write a game in Lisp you end up with a game, as well as a language that is used for writing games. Lisp becomes the scripting language.

Doing the same in C/C++ requires writing a parser/compiler (or including Lua etc.) then some way to graft the new language into the game engine. And even then, you are either inside the script calling out, or inside C/C++ calling into the script.

quote:Original post by HairyTroll I think the following quote from one of the three guys who specified the Java language sums Lisp up quite nicely. As Fortran is imperitive, his quote can also be applied to C++/Java etc.

quote:"If you give someone Fortran, he has Fortran. If you give someone Lisp, he has any language he pleases. –Guy L. Steele Jr"

How far should this logic be taken? Why not hand someone a box of wires and a soldering iron? Obviously, this pushes the concept to the limit, but many problems can be effectively solved with the current crop of "one-language" tools. I suppose my question is: under what circumstances would Lisp provide an advantage?

quote:Original post by Predictor I suppose my question is: under what circumstances would Lisp provide an advantage?

As any program grows larger, it will surely have many instances where typical mass-market languages fail to provide the proper abstraction. You''ll end up with code duplication or very complex "hackish" code to handle the situation. I''d say that Lisp provides an advantage in any project in the long run. At first (which may be a pretty long "at first&quot, Lisp won''t give advantage, because it''s existing libraries are pretty outdated as compared to e.g. Java or C#. You''ll need to use some time to create a set of useful tools or language extensions for the specific field you''re working in, and then you''ll start getting the benefits of tidier code.

quote:Original post by Predictor I suppose my question is: under what circumstances would Lisp provide an advantage?

As any program grows larger, it will surely have many instances where typical mass-market languages fail to provide the proper abstraction. You''ll end up with code duplication or very complex "hackish" code to handle the situation. I''d say that Lisp provides an advantage in any project in the long run. At first (which may be a pretty long "at first&quot, Lisp won''t give advantage, because it''s existing libraries are pretty outdated as compared to e.g. Java or C#. You''ll need to use some time to create a set of useful tools or language extensions for the specific field you''re working in, and then you''ll start getting the benefits of tidier code.

So basicly you are advocating remaking the wheel on a wide range of tools & langauge extensions? For potential ''advantages'' which are dubious to start with?

One of the reasons C/C++ have been so popular, even if the languages themselves are crud, is the vast amount of libraries and other things which add functionality to the language which is relevant for most tasks the langauge is used for . This isnt before you add the existing tools.

Microsoft has managed to force C# into the development comunity by offering massive amounts of tools, very complete libraries bundled with the language, near seamless interoperability to existing traditional code, and a clear roadmap on the expected features to the language in the next few years.

Quit frankly, I never expect Lisp or derivatives to ever make it ''big''. Lisp just doesnt offer enough clear advantages to existing and upcoming technologies. Nor is it seen to be backed by of the large IT companies.

The upcomming additions to .NET (generics & anonymous delegates being the most important), it should be possible to implement a Lisp-derived language as a 1st class language without significant hoop jumping. It should be interesting to see a Lispy language in .NET, but the fact remains: it doesnt have the tools for it.

quote:Original post by ggs So basicly you are advocating remaking the wheel on a wide range of tools & langauge extensions?

You''re making it sound worse than it really is. If some existing, non-Lisp large libraries feel very useful, you can call them via a foreign language interface. It''s a matter of interfacing them, not constructing them from scratch. The time spent there is insignificant when compared to the time taken to finish a project.

Besides, several game developers design most of their tools from scratch, starting at very low level. It''s popular to e.g. redevelop STL for PS2 development. So even remaking the wheel wouldn''t be that bad.

And with Lisp, you wouldn''t be "remaking language extensions". For example Common Lisp''s own object system kicks the C++ counterpart''s ass right out of the box. I''m talking about *creating* language extensions that you wouldn''t even dream of when thinking within the tiny box of a rigid macroless language. Creating stuff those languages don''t offer, to suit your specific needs.

quote:For potential ''advantages'' which are dubious to start with?

Dubious for those who don''t know what they are.

quote:One of the reasons C/C++ have been so popular, even if the languages themselves are crud, is the vast amount of libraries and other things which add functionality to the language which is relevant for most tasks the langauge is used for . This isnt before you add the existing tools.

Existing libraries (i.e. libraries you don''t have to interface) only get you some benefit, in the beginning of the project. Then you''ll hit the roof with the crud language.

quote:Quit frankly, I never expect Lisp or derivatives to ever make it ''big''.

Me neither, but the reason is that Lisp doesn''t suit most programmers. Most programmers aren''t very competent so they need a language that gives them a couple of clear components they can use. With Lisp, you become a language designer that needs to be pretty intelligent to actually make use of what Lisp can do. It''s better for a big company to not rely on a language that only relatively few are able to really understand and make use of. For them, it''s important that they can replace a C# coder with another cheap slave. Lisp gives an advantage to small teams in which all programmers are highly competent.

I have spent a reasonable amount of time using both Lisp and C++. They both have advantages and disadvantages out of the box. Lisp lacks much of the powerful functionality provided by the STL, and the countless libraries. C++ is much wordier than Lisp. Lisp comes with inherent support for Lambda functions, and most things are functional: operations return new values rather than modifying existing values.

However, I have come to the conclusion that the areas where Lisp provides a significant practical advantage are few and far between. With a little work you can do most of the things you can do in lisp in C++, and then still have the power to harness STL and other libraries, within a framework of a more common language like C++. A recent C/C++ Users Journal showed a reasonably simple way to add lambda functions to C++. And it's a pretty simple task to rewrite STL algorithms to work on and return containers and values rather than iterators, which I did a long time ago because I find excessive use of iterators in my code as being ugly and making things harder to follow. C++ can be modified too

The main thing touted as Lisp's superiority is the use of macros to extend the language. However, unless you are working on a project that requires a bottom-up approach with little knowledge of what the upper tiers might look like, this is not a great advantage in itself, as you can get C++ to do most of these things with macros and templates, just a bit differently. Maybe the difference will be that things like SQL will need to be enclosed in quotes and passed to a macro or function rather than used as a natural extension of the language. I don't see that as much of an issue from a practical standpoint.

It is true that harnessing the power of Lisp requires more critical thinking than many languages, but a team of all critical thinkers can work equally well in C++ or other languages.

I don't knock Lisp, I think Lisp is nice, but the notion that it's not as widespread mainly because you have to be smarter to use it is pretty shaky. Requiring more gray matter does not make something better.

It all boils down to your preferences, what you use it for, and who you are using it with. If your coworkers are more experienced in Lisp than C++, then that would probably be a good reason to use Lisp. If you are all equally experienced in Lisp and C++, I fail to see how Lisp would be a better choice for a particular problem.

quote:I'm talking about *creating* language extensions that you wouldn't even dream of when thinking within the tiny box of a rigid macroless language. Creating stuff those languages don't offer, to suit your specific needs.

A good example of this would probably answer the original authors question, as well as mine. What would be a language extension that you could create in Lisp that you wouldnt even dream of doing in C++?

quote:A good example of this would probably answer the original authors question, as well as mine. What would be a language extension that you could create in Lisp that you wouldnt even dream of doing in C++?

Can you decide you don''t like the object system of C++ and you want to make your own? (disclaimer: I don''t know how to do that in Lisp)

What do you mean by making your own object system? A bit ambiguous. Perhaps an example of some feature of an object system that one would want that is either not already available through C++, through operator overloading, templates, or by using macros? Macros in C++ can accomplish quite a bit, as can be seen with pluggable factories, and in another recent C/C++ Users Journal it was shown how to create a ''foreach'' feature with macros in C++ that operates on containers similar to the C# feature.

quote:Original post by Krippy2k WPerhaps an example of some feature of an object system that one would want that is either not already available through C++

There is a famous book on Design Patterns by the gang of four. It should be required reading for anyone programming in the Java/C++ domains; most of the examples are implemented in C++. Most of those design patterns have been developed to get around various limitations in the C++/Java OO model.

Here's a section from a paper by Richard P. Gabriel, "Objects Have Failed"