Am 30.11.2014 um 06:53 schrieb Richard Fateman:
Sorry to be argumentative, but Norvig's book is teaching about how one
can go about solving certain problems common in "symbolic" artificial
intelligence, and that is relevant in any language.
Agreed.
> The book probably
shows you how some of these ideas are more neatly encapsulated in
Lisp than some other languages, but Python should not be so far off
in terms of complexity of code and expressiveness. (Exceptions --
I don't know -- maybe the occasional use of first-class functions, or the
tiny use of macros for essentially abbreviating code segments. )
First-class functions are easy in Python (easier than in C/C++).
What you can't do easily is macros. There's a "lambda" construct but
it's a bit too clunkly to be useful for the small helpful things, so if
you can't do it in a function it's no more good Python design.
Partial evaluation isn't doable at all.
For that, firstly, you'd need to understand what exactly each design
decision in Peter's (or anybody else's) code was intended to achieve.
I think the book is pretty clear about that.
That would make it a more valuable read then.
Though it's very easy to overlook implicit assumptions, particularly if
both author and reader share them. I suspect strongly that both Peter
and you "think in Lisp", and that there's a real risk that a reader of
the book will miss these assumptions as well.
For that, merely learning Lisp is not enough, you need to have mastered
it - which is a few years of experience away for most of us (except for
you, I assume, and maybe the odd one or two lurkers on this list).
You do not need to master Lisp at the expense of years. I have taught
undergrad classes where students get up to the level of Lisp in Norvig's
book after 3 assignments (writing pieces of a compiler for a language
like Java-- ).
I tend to disagree.
You can do working code with less than mastership, true. That's what all
the CS grads (Yours Truly included) did at university. However, creating
a framework that does not paint us into some corner without us even
noticing it - now that's an entirely different thing.
Let me put up an analogy: What I fear is that the Lisp patterns
presented are a shiny, working, elegant racing car. However, when doing
it in Python, the best design might be an SUV because the track is a bit
rougher, and we'd end up with something with a really good engine but it
would be difficult to put that power to actual use.
Like all analogies, this is going to break down at some point, so I
don't want to elaborate further. The general point is: I know from
several decades of experience that the value in each design lies in its
trade-offs. Things that are irrelevant or invisible to the designer tend
to degrade, or get lost entirely. A design honed to 100% perfection is
also 100% specialized, and usually nontransferrable; it's
Second, you need to understand all about how to design the equivalents
in Python, dropping those design patterns that don't work in Python, and
replacing them with something that works as well.
This is unconvincing to me. Norvig has written a cheat sheet for Lisp <-->
Python.
That cheat sheet is really good, I just read it and even took away some
things (being at a low Lisp and intermediate Python level).
Still... his use of Python is purely pedagogical, framework design
mastership is a different skill.
In fact he marks something in read as a Python misfeature that isn't (if
an assertion message should be the just the tested expression, simply
omit the message, it will get printed as part of the stack trace).
The salient point here is that Peter shows an excellent grasp of
Python-in-the-small, but what we're doing here is the design groundwork
for core features in the next iteration of SymPy (and hopefully more
iterations).
(For example,
everything macro would have to be replaced or redone; is there anything
relevant left if you take out macros in the useful Lisp work?)
This is a boogie-man often thrown up as a barrier to understanding Lisp.
It isn't.
1. Macros are generally rare and easy to understand.
The salient point being "generally" here.
I had several instances of MEGO trying to understand why the CL standard
library did what it does. (Particularly the parts that enable multiple
dispatch - those facilities made me think of a toolbox full of loaded
and unlocked guns.)
Also, you need to be 150% clear about the semantics of quote. I found it
extremely hard to deal with that - the theory was easy enough, yet in
practice I found myself tripping over it at every other opportunity, and
it didn't get better with practice.
2. If they are not, it is probably a crappy unnecessary use of macros,
written by a naive programmer.
:-)
3. Look at Norvig's book and see how often he uses macros. Rarely.
And see how long they are. (2 lines?)
I'm unconcerned about Peter's use of macros.
What I'm concerned about is the code that they replace, and how good
that code could be abstracted out on the Python side. What kind of
design we'd need, whether it would fit with the rest of the design. What
I fear most is a downhill creep in quality - each time you build a
workaround for a macro you can't do in Python, you lose just a small
amount of design quality, but if you have a dozen macros, the overall
design could have become so bad it's unusable.
Third, the resulting code needs to be maintainable by people who do not
know anything about Lisp, and barely enough of Python to become a GSoC
student.
This is a real problem. If you have unskilled and unknowledgeable personnel
"maintaining" a code base, that's a tragedy in the works. It means that
someone
who is skilled and knowledgeable will have to go over the code and fix it.
Fortunately, the unskilled people who do not become skilled tend to go
away in a volunteer project.
It's still something to look out for. Some of our codebase has become
unmaintainable already (I'm looking at you, runtests.py - though that
specific file does not suffer from design problems but from too many
feature additions and too little refactoring).
I suppose I could write programs that are challenging to understand and
to translate; I understand Python is lacking functional objects with more
than one argument;
Actually that's not the case.
> I could write stuff relying on multiprocessing which
presumably would differ. But that's not run-of-the-mill.
Agreed.
So right now, my point of view is that trying to get that (doubtlessly
very valuable) Lisp experience into SymPy, while it could do all kinds
of good, is probably not practically possible.
All I can say is, try to read Norvig's book. My sincere belief is that
even if you never write a single line of Lisp, it will improve your
programming
in Python, because you will think about problems (like pattern matching)
more clearly.
Quite possible.
My suggestion would be to try one's hand, then read Peter's book, then
integrate the new ideas.
YMMV.
Sure, but if his book makes you learn Lisp, the presentation is heavily
biased towards Lisp, and much of what he writes won't be transferrable.
Totally disagree.
I can imagine.
Let me say the more it makes you learn Lisp, the less it's probably
going to be useful if you don't do Lisp. Maybe I was overestimating how
much it makes you learn Lisp - a dose of Lisp is certainly useful, the
full Kool-Aid can become a liability (due to overspecialization, and
because Kool-Aid is generally problematic unless you can switch entirely).
There is an old saying, 2 weeks in the computer lab can save 1 hour in
the library.
True when learning tried-and-true issues.
False when it comes to trying and judging whether it's true.
We can certainly benefit from algorithms.
Less so from "doing things the Lisp way" if we're working in Python.
The problem is that separating algorithms from "the Lisp way" isn't
always easy. And an important part of writing a framework in programming
language X is "doing it the X way" (says he who has participated in such
projects for multiple values of X).
Regards,
Jo
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/547AE8C4.3000804%40durchholz.org.
For more options, visit https://groups.google.com/d/optout.
