I work on the development of Computer-Aided Language Learning materials. Most of my work has been with authoring packages or Visual Basic, but I want to get into implementation of AI and Natural Language Processing that requires more sophisticated programming ability.
Since Lisp is the most popular langauge (in the USA) for AI and NLP, I thought that would be the best choice. But I have heard there are some problems.
1. Lisp code does not link well with other programs. For instance, I might want to use a Lisp expert system with a GUI created in VB and a spectral analysis tool written in C.
2. Because of the automatic memory management, Lisp does not scale up well. On the comp.ai.nat-lang NG, someone that that for this reason, Lisp is not used for commercial NLP apps.
3. There is no good GUI development capability for Lisp programs.
I am interested in Lisp not just because it is popular with researchers, but because I'm hoping that its versatility would allow me to do a wide variety of thing with just one language, thus minimizing calls to foreign language routines. Also, I heard that you can get pretty good speed out of a compiled Lisp program. This is very important because multimedia apps stretch resource use to the limit.
> 1. Lisp code does not link well with other programs. For instance, I > might want to use a Lisp expert system with a GUI created in VB and a > spectral analysis tool written in C.
See the recent thread "lisp to Java resources?" for some possible solutions.
> 2. Because of the automatic memory management, Lisp does not scale up > well. On the comp.ai.nat-lang NG, someone that that for this reason, > Lisp is not used for commercial NLP apps.
I don't think this is correct: the more complex the app, the more bugs you avoid by using the GC. Even complex C++ apps are using GC (see http://www.geodesic.com ). Take a look at the sample apps developed with Lisp at Franz's web site, some are pretty "heavy weight" stuff.
> 3. There is no good GUI development capability for Lisp programs.
I don't have any experience with GUI apps in CL, but it seems that almost nobody here is fully staisfied with the existing options (CAPI, CLIM, Common Graphics), so I guess you're right. :-(
Fernando Rodríguez wrote: > > 3. There is no good GUI development capability for Lisp programs.
> I don't have any experience with GUI apps in CL, but it seems that almost > nobody here is fully staisfied with the existing options (CAPI, CLIM, Common > Graphics), so I guess you're right. :-(
I would question this. Are people genuinely satisfied with GUI applications written with other options? (for example: VB or MFC). Having spent some time wrestling with MFC, I would not say I was happy [1] with the the GUI's produced (badly implementated, unstable, ugly) but within the context of GUI applications under Windows/NT you have little choice.
Yes, I am sure there are rough bits with all the options you mention but this is also because people who talk about them on this newsgroup want something better and are, by all accounts, a bit fussy.
Cheers,
:) will
[1] Infact, rather than continue to do this I would join a circus and perfect the trick of nailing 6''-nails into bricks -- under the pseudonym of `The Great Nailo.' Although it has probably already done by other disillusioned MFC programmers. ;)
> I work on the development of Computer-Aided Language Learning materials. > Most of my work has been with authoring packages or Visual Basic, but I > want to get into implementation of AI and Natural Language Processing > that requires more sophisticated programming ability.
> Since Lisp is the most popular langauge (in the USA) for AI and NLP, I > thought that would be the best choice. But I have heard there are some > problems.
> 1. Lisp code does not link well with other programs. For instance, I > might want to use a Lisp expert system with a GUI created in VB and a > spectral analysis tool written in C.
Lisp code links as well with other languages as any other language does, in my experience. In fact I'd probably say somewhat better. The Lisp application I'm working on uses a VB front end and, apart from the difficulty in getting documentation on the VB data formats and the way VB does some automatic data conversions for you, it wasn't a big problem to interface to it (this was at a DLL level - COM would have got around the data-formats issues trivially). Also Lisp macros make it really easy to define the mechanism once and hide all the details thereafter. All the Lisp/VB linkages are defined by simple (defun-VB->Lisp (...) ....) and (defun-Lisp->VB (...) ...) calls.
* qtom wrote: > 1. Lisp code does not link well with other programs. For instance, I > might want to use a Lisp expert system with a GUI created in VB and a > spectral analysis tool written in C.
Commercial Lisps typically have pretty good FFIs, as well as CORBA and all that stuff.
> 2. Because of the automatic memory management, Lisp does not scale up > well. On the comp.ai.nat-lang NG, someone that that for this reason, > Lisp is not used for commercial NLP apps.
This is the opposite of the truth. Large systems in languages without automatic memory management often end up crippled by multiple, poor implementations of garbage collection and so on. Whoever told you that was being pretty stupid.
> 3. There is no good GUI development capability for Lisp programs.
Most of the commercial systems have some kind of GUI tool On windows ACL has some very whizzy thing (I haven't used it, so can't really comment further). Lack of an x-platform tool is probably a weak pojnt (but is there a reasonable one for C/C++?).
q...@my-deja.com wrote: > 2. Because of the automatic memory management, Lisp does not scale up > well. On the comp.ai.nat-lang NG, someone that that for this reason, > Lisp is not used for commercial NLP apps.
Check out the thread "How can i stop the garbage collector from running when i want?" The gist of it is, all commercial Lisps provide ways to adjust the way garbage collection is done. When you first create your application, the GC may cause problems with responsiveness. This is normal -- the out-of-the-box settings are best for a certain class of problems, but certainly not all. If someone tried CL and didn't take the time to tweak the GC, they could easily get the impression that the GC doesn't scale up. In reality, the GC scales up great -- you just have to adjust the parameters.
> 1. Lisp code does not link well with other programs. For instance, I > might want to use a Lisp expert system with a GUI created in VB and a > spectral analysis tool written in C.
A good foreign function interface solves this problem nicely, and many lisps have one. Writing the foreign function calls and callbacks can be tricky, especially for a beginner --- it isn't as easy as just including a .h file. However, you don't have to be a rocket scientist, either. I regularly write Lisp code that makes direct calls into OS or other C libraries.
> 2. Because of the automatic memory management, Lisp does not scale up > well. On the comp.ai.nat-lang NG, someone that that for this reason, > Lisp is not used for commercial NLP apps.
Lisp usually uses a tagged pointer representation for objects. It *may* be the case that the tags take up enough room so as to limit the address space addressable by lisp. There may be limits on the sizes of arrays and strings as well. These limits are usually quiet large, though, so it would be unusual for a program to regularly come up against them. In the cases where you *do* come up against them, it is easy enough to create an abstract layer that masks the limitations.
Certain ephemeral GC algorithms don't scale up well when the number of addressable pages gets large, but that is unlikely to be an issue.
The GC parameters generally *don't* scale. If the GC is tuned for a small image, it is likely that trying to allocate a lot of objects will cause lisp to waste far too much time in the GC. But it is not difficult to find a set of GC tunings optimized for large images, and most systems have sophisticated mechanisms for manually managing object allocation. (Memory pools, pure and constant space, etc.)
It is easier to scale up a lisp program than a C program.
> 3. There is no good GUI development capability for Lisp programs.
What's wrong with emacs?
I do practically no gui development, but I understand that there are many lisp gui systems out there, some quiet impressive.
> I am interested in Lisp not just because it is popular with researchers, > but because I'm hoping that its versatility would allow me to do a wide > variety of thing with just one language, thus minimizing calls to > foreign language routines.
Yes, Lisp is much more versatile and flexible than any other language.
> Also, I heard that you can get pretty good > speed out of a compiled Lisp program. This is very important because > multimedia apps stretch resource use to the limit.
With a small bit of practice, it is easy to tune a lisp program to run very quickly. With a multimedia app, you probably want to use some C libraries to handle the media presentation and use the lisp to co-ordinate it.
> I would question this. Are people genuinely satisfied with GUI applications > written with other options? (for example: VB or MFC). Having spent some time > wrestling with MFC, I would not say I was happy [1] with the the GUI's produced > (badly implementated, unstable, ugly) but within the context of GUI applications > under Windows/NT you have little choice.
MFC is one of the worst thing to use for UIs. MFC and it's wizards are here only to enable people to write C++ when they don't understand C++ or the Win32 API or both. If you want to do UIs the M$ way in C++, try and use ATL. Otherwise use the WIN32 API directly from Lisp.
>>>>> On Mon, 05 Jun 2000 09:27:26 -0400, Thom Goodsell ("Thom") writes:
Thom> 2. Because of the automatic memory management, Lisp does not scale up Thom> well. On the comp.ai.nat-lang NG, someone that that for this reason, Thom> Lisp is not used for commercial NLP apps.
This is such a backwards statement that I wonder if it's trolling.
I am assuming that "scale up" in the above statement is referring to performance issues rather than complexity management. It is certainly true that it is possible to write Lisp programs with bad performance. I have seen lots of it, some written by people who were very experienced programmers in other languages. I would go so far as to say that it is easier to write badly performing programs in Lisp than in most other languages. However, other languages do not have anywhere near the flexibility of correcting or improving the suboptimal design decisions that might have been made.
In the statement above, it sounds suspiciously as though Lisp is being a scapegoat for programmers who didn't really know how to program in Lisp. If they were able to develop their prototypes using Lisp, and then were able to accomplish their delivery in another language, more power to them. However, at the point they switched from Lisp, they almost certainly threw away all the significant flexibility that allowed them to create and maintain their product in the first place.
Or, perhaps they really had a relatively simple program all along.
Or perhaps the whole claim is just nonsense that someone made up.
> Or perhaps the whole claim is just nonsense that someone made up.
I'm favoring the notion of programmers who didn't know a thing or two about their environment. For example, in a recent user- level thread scaleability test, I noticed a lisp environment that I was using would bog incredibly after a certain number of threads was hit. It wasn't really important at the time, but what I did notice was that the dramatic slowdown seemed to be related to an inability of the interpreter to allocate memory rapidly enough past a certain threshhold. It was my guess at the time that there was some kind of configuration issue going on. But of course, in saying this, I'm admitting that I don't know a thing or two about that environment. :)-
* Christopher C Stacy <cst...@world.std.com> | In the statement above, it sounds suspiciously as though Lisp is | being a scapegoat for programmers who didn't really know how to | program in Lisp.
The problem, then, is that they're allowed to do that. A good craftsman doesn't blame his tools, but somehow, certain tools can be labeled "bad tools", and it's suddenly OK for anyone to blame it, especially those who are worse than the "bad tool". Go figure.
#:Erik -- If this is not what you expected, please alter your expectations.
Marc Battyani wrote: > MFC is one of the worst thing to use for UIs. MFC and it's wizards are here > only to enable people to write C++ when they don't understand C++ or the > Win32 API or both.
Cheers. As somebody who clearly cannot understand C++ and the Win32 API I thank you for advice :)
> If you want to do UIs the M$ way in C++, try and use ATL.
Since I changed jobs, I am not sure I want to develop UI the M$ way (or learn ATL for that matter).
> Otherwise use the WIN32 API directly from Lisp.
Yes.
:) The Great Nailo
--- Weddings, Christenings and Funerals at competive rates
> > MFC is one of the worst thing to use for UIs. MFC and it's wizards are here > > only to enable people to write C++ when they don't understand C++ or the > > Win32 API or both.
> Cheers. As somebody who clearly cannot understand C++ and the Win32 API I thank > you for advice :)
> > If you want to do UIs the M$ way in C++, try and use ATL.
> Since I changed jobs, I am not sure I want to develop UI the M$ way (or learn > ATL for that matter).
I just bought a copy of Borland Builder for this purpose, I think it's a nice alternative to raw api...
> > Otherwise use the WIN32 API directly from Lisp.
> Yes.
> :) The Great Nailo
> --- Weddings, Christenings and Funerals at competive rates
