quote:

---

Original post by flangazor
Is this a discrepency?

---

No. Nowhere in this thread have I made direct reference to a specific example.

quote:

---

I don''t really think of actually doing that as an especially important advantage. The fact that you can, and then use that power to do useful stuff, is the advantage.

---

This is the part of the assertions that I have a problem with. You CAN do it in any other language by writing a parser/compiler, or extending what is already there. Is it necessarily easier, or more productive to do it using Lisp macros? The prolog implementation in low-line-count is one thing. However, prolog is very well explored area of programming, and it is already possible to mix prolog within other languages by using libraries and compiler extensions.

One could extend the GNU C++ compiler to handle any language they want, really. Seeing how Lisp proponents seem to place great value on all programmers on a project being highly talented, it shouldn''t be much of an ordeal for them to compile a compiler before using it. You could create a XMSQVisualLisplog++#.ORG language in pure assembler if you wanted to. Being able to do so doesn''t make it particularly useful. Being able to do so in a productive manner, i.e. not taking 60 years to flesh out the compiler, could be useful.

What would make Lisp useful is if it would be significantly easier to create the object model that I need (even better if it already exists), with a more intuitive interface, without losing a lot of performance. Since ideally it would combine multiple languages in one: XML with embedded logic and scripting that has random access to other objects and elements that are defined in XML, in a way that doesn''t break the XML spec insofar as reading and analyzing XML with other third-party XML tools, while still allowing lower-level manipulation from non-XML codebases, it would seem to be a problem that Lisp should shine on given the abundance of bold assertions about being able to implement any language in Lisp being it''s strongpoint.


And that is the crux of my project. I need to be able to do what I want to do in a productive manner, in a way that can garner equal productivity to the other programmers who work with it (who are all generally academics expert in computer science theory and able to adapt to any language). None of the other languages seem well suited for the problem, but by reading the words of the Lispers in this thread (and most others), Lisp should be well suited for it. (And I talk with a lisp, so it would suit me in another area )


There is another similar project being worked on in Lisp, but it doesn''t appear to be going particularly well. However, I am not especially informed about their experience and talent, so I won''t make judgement based on that. I will give Lisp a run and see what it''s all about. I used lisp in college many years ago, but there was no Common Lisp then that I was aware of. We''ll see how it goes.

Peace

quote:

---

Original post by Krippy2k
This is the part of the assertions that I have a problem with. You CAN do it in any other language by writing a parser/compiler, or extending what is already there. Is it necessarily easier, or more productive to do it using Lisp macros?

---

Well, take a look at existing macros for a measure. "On Lisp" features quite a bunch of them, and should give you some hint of how much code a useful macro takes.

quote:

---

The prolog implementation in low-line-count is one thing.

---

It''s quite a thing indeed. I wouldn''t believe it could be so (relatively) easy before I got to know Lisp.

quote:

---

One could extend the GNU C++ compiler to handle any language they want, really.

---

But it sure wouldn''t be easy. I''d say it would be total hell, knowing what a mess C++ is.

quote:

---

Seeing how Lisp proponents seem to place great value on all programmers on a project being highly talented, it shouldn''t be much of an ordeal for them to compile a compiler before using it.

---

Well, the main programmer at Naughty Dog did just that. But he didn''t do a compiler for a language that has only a set of features that the compiler defines. Instead, he did a Lisp compiler so that the other programmers could easily extend it with Lisp. He did it simply because extending a language through Lisp, versus by writing and extending a "traditional" compiler, aren''t really comparable tasks.

quote:

---

What would make Lisp useful is if it would be significantly easier to create the object model that I need (even better if it already exists), with a more intuitive interface, without losing a lot of performance.

---

Macros transform code to forms that you could''ve written by hand, so you won''t lose performance with them. Instead, since they can hide harder idioms in such a way that they''re nice to use, they encourage writing efficient code. Much like in C++ where STL provides a set of well made containers and algorithms so that people can just as easily use a heap as they could use a basic array, Lisp macros open up new ways to make efficient code as easy to write as sloppy/simple code.

quote:

---

XML with embedded logic and scripting that has random access to other objects and elements that are defined in XML, in a way that doesn''t break the XML spec insofar as reading and analyzing XML with other third-party XML tools, while still allowing lower-level manipulation from non-XML codebases

---

Sounds pretty reasonable to me.

Cool. I got On Lisp and am printing it out now, don''t think i want to read 400 pages in acrobat, lol. I read the introductory material, and so far it sounds good. If it works out good, the next time somebody asks for an example, you can point to me It will be open sourced eventually.

Peace

quote:

---

Original post by Krippy2k
Java and C# appeared to be better suited in this regard, but the performance hits were too much when the information database grew beyond 100,000 or so entries. I was able to cut down on the performance problems in C# much better than in Java, but it posed a problem in portability, where it was desirable to run the application on Unix/Linux servers which are what is mostly available in academia.

---

There are a couple of things to be aware of:

- It''s very easy to get something working in Lisp. It''s more work to get it running fast (by fast, think something on the order of a comparable C++ implementation).

- In C++, most of the work put in is just to get something working. Usually when it works it''s already fast enough.

quote:

---

Original post by Krippy2k
This is a case where I would want to define my own object model, which many Lisp proponents seem to think is a major advantage of Lisp.

---

I think the advantage is that Lisp allows one to add OO to an implementation of Lisp that doesn''t support OO: without having to rewrite the Lisp compiler (you have to do this in Java/C++ etc.) I wouldn''t consider rewriting CLOS just because. The Lisp object model is a superset of the C++ object model. Please have a look at what CLOS offers before you decide to write your own.

quote:

---

Original post by Krippy2k
The project data is entirely XML-based, which is another area that proponents have harped on. In fact, ideally, I would want tight integration of the object model and XML schema, as XML should be able to fully define the structure and interface of the objects.

---

Do you plan to exchange your object model described in XML with other implementations in C++/Java ? If not, just use Lisp forms (i.e. expressions). It gets you closer to Lisp, and you can read in all your descriptions from a file and execute then without having to build a parser. For example you can create a text file containing the form

(+ 1 1) ; Add 1 + 1 

and then read it in and execute it in your program doing no additional work. In C/Java/C++ you would have to build a whole parser for a new language etc.

quote:

---

Original post by Krippy2k
If Lisp is as useful for implementing these types of things as people make it out to be, I will join them in their Lispdom.

---

Your first stop should be the newsgroup comp.lang.lisp on Usenet. In fact, if you want help with anything, go here.

A couple of things you should keep in mind when asking for help:
Don''t just say "I want to do this, how do I do it". Which tends to stir people up. Rather say, "I want to do this. I have tried *this*, is there a better way ?". Which shows them that you are making an effort.

The contributors in comp.lang.lisp are very good at not giving an answer directly, but providing enough information that you will be able to work it out for yourself. Which in my mind is more useful than having someone post their code.

Of course I will thoroughly review the existing libraries and features, I''m not a big fan of reinventing the harmonica (the wheel is just too cliche to stomach anymore)

I am not real certain whether I will need to share the object model yet. At the least, I will need to be able to convert XML into the object model, and vice versa. The reason is that most of it will be created using third party XML tools, and there are several million lines of XML already in existence that would need to be imported.

However, it is possible that the best solution might be to use my existing C++ or C# codebase to create a converter. THe creative content doesn''t necessarily have to encompass all of the components. The content creators would be using a limited script set, and myself and other backend folks will both tweak what they present and analyze it to find new ways for them to present their creativity.

The overall idea (in case you are wondering) is to create a computerized entity that has a reasoning/logic model, a personality model, a learning model, and a human interface model. Eventually the personality should be derived from experience, reasoning, filtered randomness, observable input, and simulated experiences. But to get to that point we need an extensive set of existing human-identifiable personalities to start from unless we want to wait hundreds or thousands of years for it to come up with them on it''s own. A series of such entities can then interact and learn from each other, and the personality of one entity may affect the personality of others. Much as in the same way that people often take up the habits and personalities of others when they spend a lot of time with them.

Yet I digress... the main reason I am posting again was to ask which Common Lisp implementation would you recommend as a starting point

Peace

From the few I''ve looked at, Corman Lisp seems to be a good compiler. The trial IDE expires (I prefer Emacs to all the other Lisp IDEs I''ve used anyways), but the command-line compiler does not. It is the most reasonably priced compiler I''ve found (there are a lot of free implementations, but they don''t seem very mature in some respects and they seem to be mostyly interpreters, at least the ones for windows)

quote:

---

Original post by Extrarius
From the few I've looked at, Corman Lisp seems to be a good compiler. The trial IDE expires (I prefer Emacs to all the other Lisp IDEs I've used anyways), but the command-line compiler does not. It is the most reasonably priced compiler I've found

---

I agree. I've personally registered Corman Lisp, it's only $250. The IDE still allows usage after it expires, it just pops up a reminder/nag every 30 minutes or so.

Corman Lisp compiles into native x86. It is fast (not CLOS although Roger is working on that.) It uses native OS threads, it can compile Lisp applications into DLLs. And there are bindings to OpenGL and SDL for it, which are available on Balooga.com

[edited by - HairyTroll on February 23, 2004 7:29:10 PM]

Oh, and someone has even managed to get Corman Lisp working under Linux in Wine. So I would say all the bases are covered.


[edited by - HairyTroll on February 23, 2004 7:31:53 PM]

The other Lisps are LispWorks and Allegro Common Lisp. These are both much more expensive than Corman Lisp. However their 'Personal Editions' do not expire although their heaps are limited to a maximum size - which limits the size of the Lisp application that they can run. Their IDE's are also similar to what you might expect, coming from a VisualC++/Eclipse type environment.

Naughty Dog use Allegro Common Lisp.

[edited by - HairyTroll on February 23, 2004 7:39:08 PM]

The general opinion I get is that lisp can do anything, given sufficint code and effort.
We already know that from CS courses.
Lisp is well suited to certain applications; such as the ones it was written for while under devolopment.
Everything else seems to be a problem and headache, given the opinion of people in this thread.
I''m not surprised: C++ is a reasonably good systems language and a decent jack-of-all trades langauge at general fast computation.
By itself, it fails miserably at certain applications.

What I see is that C++''s(or arbitrary good OO langauge) capabilities for getting lots of different stuff done is better than lisp.

Before the flames restart, I''d like to mention a arcticles topic I read some time back.
Theres two kinds of programming styles:
Programming it perfect the first time, also called the MIT method.
Programming it working and so-so the first time. I forget this philosophys name.

My point is that lisp embodies the mit method: you get it perfect and right. Thats stinking hard and doesn''t always work.
C++ embodies the other one: its not great and is quite dirty, but gets the job done.

You guys follow ?
Please don''t reflame things again.

Good luck Krippy!

~V''lion


~V''lion

Bugle4d

quote:

---

Original post by Vlion
Theres two kinds of programming styles:
Programming it perfect the first time, also called the MIT method.
Programming it working and so-so the first time. I forget this philosophys name.

My point is that lisp embodies the mit method: you get it perfect and right. Thats stinking hard and doesn''t always work.
C++ embodies the other one: its not great and is quite dirty, but gets the job done.

---

Actually, IMHO, it is exactly the opposite.

Lisp allows for a testing of little pieces of ones ideas with immediate feedback, with which errors can be corrected and assumptions verified or rejected immediately. C++, on the other hand, tends to force you to lay the whole project out from the start and often times even subtle changes require hacks, kludges or have large repercussions for your code base. Lisp absolutely does not require one to be brilliant and perfect, though some may like for you to be of that opinion. Cheers.