Jajwuth wrote:
>
> How is it that using lisp can make your programs appear intelligent? What is
> the mechanism for accomplishing this?
> Thanks
> Al
People who choose Lisp are often intelligent, so they have something to
build in their programs :-)
Lisp is just a better tool for writing complex, dynamic applications
(including AI) in comparison to other languages - the same way Java is
better suited for writing distributed, mobile code for the Internet than
Cobol. It's not to say you can't program AI in Fortran, it's the
suitability (hence efficiency) that matters. BTW, you can even link
your assembly NN program to Lisp.
Robert
·······@aol.com (Jajwuth) writes:
>How is it that using lisp can make your programs appear intelligent? What is
>the mechanism for accomplishing this?
Lisp is better suited to organize your code in a way that make later
changes and later uses for unseen purposes easier.
When developing the so-called "intelligent" programs, the key is that
you usually start coding at a stage where you don't understand the
whole problem. The more you can bent the code you base the next step
on, the better progress you make.
If you have to restart from scratch or are often held up by debugging
low level breakages (i.e. memory management, bad collection accesses,
integer overflows), you get nowhere. Overspecifying things like data
types is also not useful for such explorative work.
Another factor (at least in the old days) is that Lisp treats errors
in a way that you can do something about them without aborting and
restarting the program (not always, of course). The same "often
restarting from scratch gets you nowhere".
BTW, this way of handling errors makes Lisp's style of typing (dynamic
typing unless optimized) desirable. As advocates of strong typing
point out: With dynamic typing you *will* run into type errors, sooner
or later. But Lisp often allows you to handle the type error without
breaking the program. Together, these properties of Lisp make sense.
Dynamic typing without a way to catch errors softly is less fun.
Once you successfully coded your "intelligent" behaviour (that means,
you have a complete model of what the machine does) you can usually
reimplement it in any language you want.
Other Lisp programmer of course feel different, just my opinion.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
"Where do you want to do today?" Hard to tell running your calendar
program on a junk operating system, eh?
Martin Cracauer wrote:
>
> ·······@aol.com (Jajwuth) writes:
>
> >How is it that using lisp can make your programs appear intelligent? What is
> >the mechanism for accomplishing this?
>
> Lisp is better suited to organize your code in a way that make later
> changes and later uses for unseen purposes easier.
>
> When developing the so-called "intelligent" programs, the key is that
> you usually start coding at a stage where you don't understand the
> whole problem. The more you can bent the code you base the next step
> on, the better progress you make.
>
> If you have to restart from scratch or are often held up by debugging
> low level breakages (i.e. memory management, bad collection accesses,
> integer overflows), you get nowhere. Overspecifying things like data
> types is also not useful for such explorative work.
>
> Another factor (at least in the old days) is that Lisp treats errors
> in a way that you can do something about them without aborting and
> restarting the program (not always, of course). The same "often
> restarting from scratch gets you nowhere".
>
> BTW, this way of handling errors makes Lisp's style of typing (dynamic
> typing unless optimized) desirable. As advocates of strong typing
> point out: With dynamic typing you *will* run into type errors, sooner
> or later. But Lisp often allows you to handle the type error without
> breaking the program. Together, these properties of Lisp make sense.
> Dynamic typing without a way to catch errors softly is less fun.
>
> Once you successfully coded your "intelligent" behaviour (that means,
> you have a complete model of what the machine does) you can usually
> reimplement it in any language you want.
>
> Other Lisp programmer of course feel different, just my opinion.
>
While there are sometimes benefits to prototyping in Lisp and recoding
in a different language, by doing so one gives up the benefit you
pointed out in the beginning of your post:
"Lisp is better suited to organize your code in a way that make later
changes and later uses for unseen purposes easier."
If you recode your Lisp program in another language you've lost the ease
of
future enhancements, code reuse, and debugging. No matter how
"intelligent"
a program, it will need to at least be maintained.
Larry
Larry Kramer <······@stsci.edu> writes:
> While there are sometimes benefits to prototyping in Lisp and recoding
> in a different language, by doing so one gives up the benefit you
> pointed out in the beginning of your post:
>
> "Lisp is better suited to organize your code in a way that make later
> changes and later uses for unseen purposes easier."
And those "unseen purposes" comes in at least two flavors for a
software developer:
1. Bugs
2. Unintended uses of the software.
Any self-respecting software developer will underestimate in both
of these categories.
> If you recode your Lisp program in another language you've lost the ease
> of
> future enhancements, code reuse, and debugging. No matter how
> "intelligent"
> a program, it will need to at least be maintained.
A very important point, since properly productized software is
mostly maintenance. I use 80% as a rule-of-thumb, but it varies,
and in the case of the software I maintain, it is more like 90%.
In fact, when I see people discussing LOC (lines-of-code measurements)
and paying programmers based on that, I have to smile; I do on
occasion write a new piece of code, but mostly I get paid for
exactly the opposite: lines of code _removed_ ...
Since so much of my work involves maintenance, I'm glad to stay
with a language that makes maintenance so much easier.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig wrote:
>And those "unseen purposes" comes in at least two flavors for a
>software developer:
> 1. Bugs
> 2. Unintended uses of the software.
>
>Any self-respecting software developer will underestimate in both
>of these categories.
True for the second, but I doubt if for the first. This was the first
fear of every novice programmer and I think underestimated by self
respecting programmers. Timeframes are hopelessly underestimated but not
bugs.
>> If you recode your Lisp program in another language you've lost the ease
>> of future enhancements, code reuse, and debugging. No matter how
>> "intelligent" a program, it will need to at least be maintained.
>
>A very important point, since properly productized software is
>mostly maintenance. I use 80% as a rule-of-thumb, but it varies,
>and in the case of the software I maintain, it is more like 90%.
>In fact, when I see people discussing LOC (lines-of-code measurements)
>and paying programmers based on that, I have to smile; I do on
>occasion write a new piece of code, but mostly I get paid for
>exactly the opposite: lines of code _removed_ ...
>
>Since so much of my work involves maintenance, I'm glad to stay
>with a language that makes maintenance so much easier.
True.
But I doubt if it has anything to do with "intelligent" programs or
languages.
My guess is that COBOL and COMMON LISP are the two easiest to maintain
languages. Both start with CO. The two other things starting with CO and
the single letter are a nightmare.
But honestly said, Common Lisp might be a little bit too dynamic to be
maintained efficiently.
Removing all runtime issues (eval-when, change-class) wouldn't be a bad
idea solely for the prospect of maintenance, if not for efficiency :)
(And this to franz who carry dynamic on their shirts. Partially joking.)
Assembler, perl and C++ might be the worst to maintain.
comp.software-eng should have numbers.
--
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
Duane Rettig wrote:
>And those "unseen purposes" comes in at least two flavors for a
>software developer:
> 1. Bugs
> 2. Unintended uses of the software.
>
>Any self-respecting software developer will underestimate in both
>of these categories.
True for the second, but I doubt if for the first. This was the first
and worst fear of every novice programmer (and users) and I do not think
underestimated by self respecting programmers (and still users).
Timeframes are hopelessly underestimated but not bugs. Esp. Lisp people
who make far more errors in other languages and therefore also chose
lisp (at least me).
>> If you recode your Lisp program in another language you've lost the ease
>> of future enhancements, code reuse, and debugging. No matter how
>> "intelligent" a program, it will need to at least be maintained.
>
>A very important point, since properly productized software is
>mostly maintenance. I use 80% as a rule-of-thumb, but it varies,
>and in the case of the software I maintain, it is more like 90%.
>In fact, when I see people discussing LOC (lines-of-code measurements)
>and paying programmers based on that, I have to smile; I do on
>occasion write a new piece of code, but mostly I get paid for
>exactly the opposite: lines of code _removed_ ...
>
>Since so much of my work involves maintenance, I'm glad to stay
>with a language that makes maintenance so much easier.
True.
But I doubt if it has anything to do with "intelligent" programs or
languages.
My guess is that COBOL and COMMON LISP are the two easiest to maintain
languages. Both start with CO. The two other things starting with CO and
the single letter are a nightmare.
But honestly said, Common Lisp might be a little bit too dynamic to be
maintained efficiently.
Removing all runtime issues (eval-when, change-class) wouldn't be a bad
idea solely for the prospect of maintenance, if not for efficiency :)
(And this to franz who carry dynamic on their shirts. Partially joking.)
Assembler, perl and C++ might be the worst to maintain.
comp.software-eng should have numbers.
--
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
Larry Kramer <······@stsci.edu> writes:
>While there are sometimes benefits to prototyping in Lisp and recoding
>in a different language, by doing so one gives up the benefit you
>pointed out in the beginning of your post:
>"Lisp is better suited to organize your code in a way that make later
> changes and later uses for unseen purposes easier."
You're overinterpretating my sentense.
we have the same position in this discussion.
>If you recode your Lisp program in another language you've lost the ease
>of
>future enhancements, code reuse, and debugging. No matter how
>"intelligent"
>a program, it will need to at least be maintained.
Didn't mean you *should* move to a different language.
It was just to illustrate the point that there is nothing in
programming language Lisp that makes programs written in it behave
intelligent by themself. The process of writing "itelligent" programs
is in your head. The real question here is: how do you get it into
your head other than by explorative programming?
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
"Where do you want to do today?" Hard to tell running your calendar
program on a junk operating system, eh?