scaling and linking?

3 views
Skip to first unread message

qt...@my-deja.com

unread,
Jun 5, 2000, 3:00:00 AM6/5/00
to
Hi,

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.

Could anyone comment on these points?

Thanks,
Tom


Sent via Deja.com http://www.deja.com/
Before you buy.

Fernando Rodríguez

unread,
Jun 5, 2000, 3:00:00 AM6/5/00
to

qt...@my-deja.com escribió:

>
>
> 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. :-(


William Deakin

unread,
Jun 5, 2000, 3:00:00 AM6/5/00
to
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. ;)


foot...@thcsv01.trafford.ford.com

unread,
Jun 5, 2000, 3:00:00 AM6/5/00
to
qt...@my-deja.com writes:

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

[snip]


> Could anyone comment on these points?
>

Just my 2c

Guy.

Tim Bradshaw

unread,
Jun 5, 2000, 3:00:00 AM6/5/00
to
* 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++?).

--tim


Thom Goodsell

unread,
Jun 5, 2000, 3:00:00 AM6/5/00
to
qt...@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.

Thom

Joe Marshall

unread,
Jun 5, 2000, 3:00:00 AM6/5/00
to
qt...@my-deja.com writes:

> Hi,


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

Marc Battyani

unread,
Jun 5, 2000, 3:00:00 AM6/5/00
to
William Deakin <wi...@pindar.com> wrote in message
news:393B7808...@pindar.com...

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

Marc Battyani

Christopher C Stacy

unread,
Jun 6, 2000, 3:00:00 AM6/6/00
to
>>>>> 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.


Courageous

unread,
Jun 6, 2000, 3:00:00 AM6/6/00
to

> 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. :)-

C/

Erik Naggum

unread,
Jun 6, 2000, 3:00:00 AM6/6/00
to
* 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.

William Deakin

unread,
Jun 6, 2000, 3:00:00 AM6/6/00
to
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


Fernando Rodríguez

unread,
Jun 6, 2000, 3:00:00 AM6/6/00
to

William Deakin escribió:

> 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).
>

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

Is this your new job? ;-)


William Deakin

unread,
Jun 6, 2000, 3:00:00 AM6/6/00
to
Fernando Rodríguez wrote:

> > :) The Great Nailo
> >
> > --- Weddings, Christenings and Funerals at competive rates
>
> Is this your new job? ;-)

Yes. Do you have a opening (a gig even) for a novely nailing act ;) will


Reply all
Reply to author
Forward
0 new messages