On Sunday, November 30, 2014 1:52:08 AM UTC-8, Joachim Durchholz wrote: > > Am 30.11.2014 um 06:53 schrieb Richard Fateman: > > First-class functions are easy in Python (easier than in C/C++). >
OK, I thought I read somewhere about some limitations. > > 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. > I just don't understand this emphasis on the difficulty of macros. Some people are happy to run their source code through a macro processor like M6, just for the fun of it. But I don't think that is at all necessary. > > Partial evaluation isn't doable at all. > I don't know what you mean by partial evaluation. Is this something you think that Lisp does? Maybe confused about quote? (+ 3 4) evaluates to 7 '(+ 3 4) evaluates to a lisp list of 3 items, + , 3, 4 . Is that what you mean? > >> 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. > That's not really what Norvig does. Quite the contrary. His programs are a minimal framework to exhibit the performance that he wants to demonstrate, for the most part. Thus he has a chapter that shows how to do integration of symbolic expressions, but it can be accused of being just a hack ... no Risch algorithm etc. Similarly for natural language understanding. etc. Doing a full-fledged efficient version of these would require much more work. > 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. > I give up. If you are convinced that macros are a problem, then to you they are a problem. > > 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. > I find this surprising. You can read (in Norvig's book) a program that is the Lisp evaluator (actually, Scheme). It shows what quote means. If I recall correctly, Scheme originally did not have macros. Maybe still doesn't, just as an "extension". > > > 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. Each time a piece of macro code is used in a Lisp program one can replace it with a piece of regular code. In fact that is exactly what macro expansion does. Presumably Python programmers could do the same by hand. > 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. > Again, you assume that a lisp program is a tangle of macros. > > >> 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 don't know about sympy code base, but I think the general belief in my (computer science) department is that programs written by students must be reworked by others before it is ready for prime-time (95%). distribution outside our department. > > > 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. > Well, I could repeat myself. > > >> 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. I think that pattern matching is pretty well understood by some people. > > > 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). > I think that writing programs in Lisp does not define 'a way' because there are generally many ways of accomplishing the same task using different "paradigms" ... e.g. functional, imperative, ... whereas it seems to me that Python is supposed to have one way to do each thing. (true?). So maybe a lisp program that is heavily "functional programming" style is hard to do in Python ? But you insist that Python supports this, so I don't know. RJf > > 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/8d644831-9bea-4120-8dc4-edbdb61e4ffc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
