Hello,
I don't understand NOTHING to AI. But, since the time I've discovered
computers I've allways wanted to master an AI oriented language (just for
fun, nothing else).
The most common AI languages are Prolog and Lisp. I've been through several
Prolog tutorial and even if I would not be able to do nothing with Prolog
(I'm too bad for now), at least I understand it because the common samples
make sense for me (isgrandfather(tom)) : I don't master the language at all
but I understand (feel) his logic.
In the mean time, each time I've tried to start to learn LISP I've never
been able to understand NOTHING at all.
So, I would appreciate a link to LISP tutorial that deals with simple BUT
interesting subjects (like AdventureInProlog for Prolog stuff) and not only
with lists, lists and lists without providing interesting (sensible)
samples on how to use them.
What's the problem ? Is it me (may be), or LISP is inadequate for geek
programmers ? ;-)
Thank you.
watsacham wrote:
> What's the problem ? Is it me (may be), or LISP is inadequate for geek
> programmers ? ;-)
>
Yes. Definitely. Lisp IS inadequate for *geek* programmers. Become a
non-geek programmer and Lisp will suit you perfectly. Until then you couls
always try Perl or Ruby.
faa
P.S. Or else, it could be you...
I gotta jump in here because my NG server seems to have missed the OP...
watsacham wrote:
>
> Hello,
>
> I don't understand NOTHING to AI. But, since the time I've discovered
> computers I've allways wanted to master an AI oriented language (just for
> fun, nothing else).
That's what drew me to programming, as well.
>
> The most common AI languages are Prolog and Lisp. I've been through several
> Prolog tutorial and even if I would not be able to do nothing with Prolog
> (I'm too bad for now), at least I understand it because the common samples
> make sense for me (isgrandfather(tom)) : I don't master the language at all
> but I understand (feel) his logic.
>
> In the mean time, each time I've tried to start to learn LISP I've never
> been able to understand NOTHING at all.
I saw a power user interested in being able to maintain the logic rules
go through the same thing, tho the comparison was between SmallTalk and
Prolog. He dug the Prolog tutorial big time, had no idea what the
SmallTalk tutorial was going on about.
But that is because Prolog, as the name suggests, is a logic-empowered
language. Out of the box you can get nifty results that seem smart.
Lisp may be associated with AI in folks' minds, but that does not mean
Lisp comes with fancy logic stuff out of the box. One has to build that
up from scratch (but see next) and that is what you and the power user
have run into: you have to do a bunch of programming to get to the AI
fun, and youse guys are not so strong on the programming (and might not
want to be).
Next: others have posted links to lotsa Lisp resources. I am pretty sure
you can find free packages to pull into your Lisp environment which will
let you do prolog-in-lisp, or at least expert-system-in-lisp.
And Lisp might be the way to go. You /could/ just play with Prolog, but
my experience was that getting beyond the simple tutorials was not so
easy. Things got nasty in a hurry; I found myself fighting the language.
Still great fun, mind you.
Overall, tho, I am afraid you are going to have to become quite a good
programmer before you start having fun with AI.
kenny
clinisys
In an attempt to throw the authorities off his trail, Kenny Tilton <·······@nyc.rr.com> transmitted:
> And Lisp might be the way to go. You /could/ just play with Prolog,
> but my experience was that getting beyond the simple tutorials was
> not so easy. Things got nasty in a hurry; I found myself fighting
> the language. Still great fun, mind you.
The problem with Prolog is that it is so /staunchly/ non-procedural.
It's great for processing things that are intended to be pretty
nondeterministic, but when it comes time to do things that /are/
procedural, like looping and modifying variable values, it becomes
necessary to, as you say, "fight the language."
It's great fun for solving suitable problems; I /love/ the way it lets
you do things like:
natural(X) :- X #=< 9, X #>= 1.
numeric(X) :- member(X, [0,1,2,3,4,5,6,7,8,9]).
solution(X) :-
natural(A), natural(B), natural(C), natural(D),
natural(E), natural(F), natural(G), natural(H), natural(J),
fd_all_different([A, B, C, D, E, F, G, H, J]),
% Whole bunch of silly rules about relationships between seat
% numbers
A + D #= 2 * B,
E #= D - A,
H - F #= 6,
J #>= 3 * B,
J #>= H,
H #>= G,
G #>= C,
numeric(A), numeric(B), numeric(C), numeric(D),
numeric(E), numeric(F), numeric(G), numeric(H), numeric(J),
X=[A, B, C, D, E, F, G, H, J].
But when trying to do /real work/, I'd *far* rather write most of the
application in something procedural (Lisp, Python, Perl, for that
matter), and push the "unification" problems at some form of embedded
Prolog.
--
(concatenate 'string "cbbrowne" ·@ntlug.org")
http://www.ntlug.org/~cbbrowne/prolog.html
If there's one thing I can't stand, it's intolerance.
Christopher Browne wrote:
> It's great for processing things that are intended to be pretty
> nondeterministic, but when it comes time to do things that /are/
> procedural, like looping and modifying variable values, it becomes
> necessary to, as you say, "fight the language."
If all you knew was Prolog would you still fight it?
Barry Watson <············@uab.ericsson.se> wrote in message news:<·················@uab.ericsson.se>...
>
> If all you knew was Prolog would you still fight it?
Code written by very export prolog people that I've seen tends to be
full of red cuts to force things to be procedural. I guess you could
argue that they all know other languages, but ...
--tim
Tim Bradshaw wrote:
>
> Barry Watson <············@uab.ericsson.se> wrote in message news:<·················@uab.ericsson.se>...
> >
> > If all you knew was Prolog would you still fight it?
>
> Code written by very export prolog people that I've seen tends to be
> full of red cuts to force things to be procedural. I guess you could
> argue that they all know other languages, but ...
I didn't want to argue about procedural being bad, I wanted to make a
point about fighting languages. They're not fighting a Prolog when they
use cuts.
* Barry Watson wrote:
> I didn't want to argue about procedural being bad, I wanted to make a
> point about fighting languages. They're not fighting a Prolog when they
> use cuts.
I think they are, if they use copious red cuts to avoid any kind of
backtracking.
--tim
Tim Bradshaw <···@cley.com> writes on prolog programmers fighting
prolog to make it more procedural:
> I think they are, if they use copious red cuts to avoid any kind of
> backtracking.
you are right in that a clause with a red cut in it has no logical
reading, as red cut prunes away logical solutions. on the other hand
i think your observation of red cuts is a bit exaggerated or maybe
you are confusing them with the grue cuts...
oz
--
there is a fault in reality. do not adjust your minds. -- salman rushdie
* ozan s yigit wrote:
> you are right in that a clause with a red cut in it has no logical
> reading, as red cut prunes away logical solutions. on the other hand
> i think your observation of red cuts is a bit exaggerated or maybe
> you are confusing them with the grue cuts...
Well, I'll generalise my statement: code with lots of cuts (red or
green) is fighting the language. The only reason I can see for green
cuts is efficiency, and if you're having to put in hacks all over the
place to get efficiency to be reasonable, then you're fighting the
language.
--tim
Barry Watson wrote:
> Christopher Browne wrote:
>
>
>>It's great for processing things that are intended to be pretty
>>nondeterministic, but when it comes time to do things that /are/
>>procedural, like looping and modifying variable values, it becomes
>>necessary to, as you say, "fight the language."
>
>
> If all you knew was Prolog would you still fight it?
Sure, I just would not know I was.
Or, if as you imply, my knowledge only of prolog meant my mind could not
even conceive of the procedural ("hey, what's cut for anyway?"), I would
not fight Prolog, but neither would any interesting program have the
time to run to completion.
I really enjoyed the paradigm shift of Prolog, mind you, ran out, bought
all the books, bought a couple of Prologs... quickly ground to a halt
trying to get a logic engine to do straightforward things to which the
logic engine could add no value.
kenny
clinisys
Kenny Tilton wrote:
>
>
> I really enjoyed the paradigm shift of Prolog, mind you, ran out, bought
> all the books, bought a couple of Prologs... quickly ground to a halt
> trying to get a logic engine to do straightforward things to which the
> logic engine could add no value.
What sort of things?
Barry Watson wrote in message <·················@uab.ericsson.se>...
>Kenny Tilton wrote:
>>
>>
>> I really enjoyed the paradigm shift of Prolog, mind you, ran out, bought
>> all the books, bought a couple of Prologs... quickly ground to a halt
>> trying to get a logic engine to do straightforward things to which the
>> logic engine could add no value.
>
>What sort of things?
Looking back at the books, I see I was hard at it in O'Keefe, "The Craft of
Prolog" and realized Prolog was a mistake after two chapters. counting,
appending, and searching were ghastly when forced into the
one-paradigm-serves-all of Prolog.
Classic example: the rule of thumb at the end of chapter one: "What will
your predicate do if it is backtracked into?" ie, Logic programming? Only on
the surface. You have to program the imperative mechanics of the logic
engine while typing declarative forms. O'Keefe talks about this dichotomy:
"we bring to the reading our knowledge of how the prolog system executes
such specifications."
How's that for a recipe for disaster? You have to code in one style and
think in another?
It's OK to think hard about the internals to get efficient searches truly
leveraging the logical power of prolog, but not to count or search or
append.
To repeat: the big mistake is getting so stoked over something that one
decides "let's use it for everything!".
kenny
clinisys
A long time ago, in a galaxy far, far away, Barry Watson <············@uab.ericsson.se> wrote:
> Christopher Browne wrote:
>> It's great for processing things that are intended to be pretty
>> nondeterministic, but when it comes time to do things that /are/
>> procedural, like looping and modifying variable values, it becomes
>> necessary to, as you say, "fight the language."
>
> If all you knew was Prolog would you still fight it?
Probably not, but Prolog wasn't anywhere near the first language I was
exposed to, so I can only imagine that, as opposed to being sure.
--
(concatenate 'string "cbbrowne" ·@ntlug.org")
http://www.ntlug.org/~cbbrowne/wp.html
"If Bill Gates had a dime for every time a Windows box crashed...
... Oh, wait a minute, he already does."
* Barry Watson <············@uab.ericsson.se>:
> If all you knew was Prolog would you still fight it?
If you only know one language can you ever know that you're fighting it?
--
Dave Pearson: | lbdb.el - LBDB interface.
http://www.davep.org/ | sawfish.el - Sawfish mode.
Emacs: | uptimes.el - Record emacs uptimes.
http://www.davep.org/emacs/ | quickurl.el - Recall lists of URLs.
Dave Pearson wrote:
>
> * Barry Watson <············@uab.ericsson.se>:
>
> > If all you knew was Prolog would you still fight it?
>
> If you only know one language can you ever know that you're fighting it?
Which only really leaves the adequacy of a language and I think that
Prolog is quite adequate for a great many tasks.
* Dave Pearson wrote:
> If you only know one language can you ever know that you're fighting it?
I think so. If the default thing that the language does results in
programs which are hugely more computationally complex than they need
to be (say exponential rather than small-exponent polynomial, or just
failing to terminate rather than anything), and you spend a lot of
time doing stuff to work around this, then you know that there is
something wrong with the language. In particular you know that
whatever is causing this explosion should probably be left out. My
experience of prolog applications, mostly for NLP, is that the default
backtracking behaviour of prolog is exactly such a problem. The
pattern matching is good, but you spend all your time implementing
your own search algorithms if you want your system to run in
non-exponential time.
--tim
"watsacham" <·····@grouik.com> wrote in message
···························@213.228.0.138...
> Hello,
Hi
> In the mean time, each time I've tried to start to learn LISP I've never
> been able to understand NOTHING at all.
>
> So, I would appreciate a link to LISP tutorial that deals with simple BUT
> interesting subjects (like AdventureInProlog for Prolog stuff) and not
only
> with lists, lists and lists without providing interesting (sensible)
> samples on how to use them.
Start at www.lisp.org and you will find links to online resources including
tutorials. Good luck and come back with any specific problems you have!
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
On 08 Oct 2002 19:07:37 GMT, watsacham <·····@grouik.com> wrote:
>What's the problem ? Is it me (may be), or LISP is inadequate for geek
>programmers ? ;-)
sheez.
I have programmed a little in Prolog but shifted promptly to Lisp as
soon as was introduced to it. At least for me, Lisp makes much more
sense.
But the example angle. Aaah. You could try "Lisp" by Horn as that
contains some (:sensible) examples. Like factorials, etc.
have a little patience.
quasi
--
What?
watsacham <·····@grouik.com> writes:
> So, I would appreciate a link to LISP tutorial that deals with simple BUT
> interesting subjects (like AdventureInProlog for Prolog stuff) and not only
> with lists, lists and lists without providing interesting (sensible)
> samples on how to use them.
I recommend "ANSI Common Lisp" by Paul Graham.
The example programs he gives are very striking, including a
ray tracer in chapter 9, and a simple implementation of
something like Prolog in chapter 15.
OK it is 432 page book, rather than an online tutorial, but
I think you will like the big examples.
Alan Crowe
Alan S. Crowe wrote:
> watsacham <·····@grouik.com> writes:
>
>
>>So, I would appreciate a link to LISP tutorial that deals with simple BUT
>>interesting subjects (like AdventureInProlog for Prolog stuff) and not only
>>with lists, lists and lists without providing interesting (sensible)
>>samples on how to use them.
>
>
> I recommend "ANSI Common Lisp" by Paul Graham.
[...]
> OK it is 432 page book, rather than an online tutorial, but
> I think you will like the big examples.
Two chapters are available for free at
http://www.paulgraham.com/articles.html - they give you a good
impression what the book is like.
Pascal
--
Given any rule, however �fundamental� or �necessary� for science, there
are always circumstances when it is advisable not only to ignore the
rule, but to adopt its opposite. - Paul Feyerabend