Why lisp?

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.

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.

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.

---

I''ll second that. Very good threads.

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.

~V''lion

Bugle4d

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.

______________________________________

Pax Solaris

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?

-Predictor
http://will.dwinnell.com

quote:

---

Original post by Anonymous Poster

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", 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.

DotLisp.
And, although not derived from lisp, there is Nemerle, which continues the ML tradition on .NET.

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++?

Peace

[edited by - krippy2k on February 19, 2004 9:13:44 AM]

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.

Peace

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"

Objects Have Failed

To Lisp/Scheme people, the GoF book is a joke because the patterns there are simply covering for lack of programming and abstractional power.


Peter Norvig:
Design Patterns in Dylan or Lisp

16 of 23 patterns are either invisible or simpler, due to:

• - First-class types (6): Abstract-Factory, Flyweight, Factory-Method, State, Proxy, Chain-Of-Responsibility
  
  
• - First-class functions (4): Command, Strategy, Template-Method, Visitor
  
  
• -Macros (2): Interpreter, Iterator
  
  
• -Method Combination (2): Mediator, Observer
  
  
• -Multimethods (1): Builder
  
  
• -Modules (1): Facade
  

[edited by - HairyTroll on February 19, 2004 12:44:13 PM]

[edited by - HairyTroll on February 19, 2004 12:46:48 PM]

The best thing about Lisp is that all it''s proponents are so humble.

quote:

---

Original post by Arild Fines
The best thing about Lisp is that all it's proponents are so humble.

---

You actually hit the nail on the head. This puts most newbies off Lisp completely and it's been written about quite often.

Why we hate Lisp

Smug Lisp Weenies

Social Problems of Lisp

It's just difficult discussing the merits of *any* language without coming across as "My C64 rules, your Spectrum sucks", "My Amiga rules, PeeCee sucks", "NVidia versus ATI". etc.

If you want to read a very balanced discussion on the merits of Lisp, try this Q/A session on Slashdot by Kent M Pitman. It's what got me interested in Lisp in the first place.

Kent M. Pitman Answers On Lisp And Much More

Kent M. Pitman's Second Wind

Things like being able to patch a Lisp program - while it is running - really blew me away.


[edited by - HairyTroll on February 19, 2004 1:18:10 PM]

quote:

---

Original post by Arild Fines
The best thing about Lisp is that all it''s proponents are so humble.

---

Makes you cringe doesn''t it?

Interesting.
I still don''t percieve any practical advantage Lisp has over .

I think that theres no good reason to write lisp over Prolog or .

Language theory aside- it seems to be needlessly simplified and with a minimum of constructs.

I know that is due to reasonable factors- don''t get me wrong, its a very "nice" language- but I think I''d sooner burn my time on Ruby and advanced C++ constructs and understand the procedural paradigm throughly. I''ve no beef with Lisp- it just takes way too long and too much kludging to get anywhere in terms of what I write: even if I''m doing logical types of questions.

Prolog seems to be a better "other" langauge, frankly.

*shrug*

Peace out.

~V''lion

Bugle4d