On 12/14/06, Ken Tilton <[EMAIL PROTECTED]> wrote: > > > Andrew Reilly wrote: > >> Each skill seems to have a title, a > > list of annotations, and a list of hints (and a reverse, which I don't > > understand). > > There's the problem. > > > That all looks like data. > > No, not reverse, the part you did not understand. I do not mean what the > code was doing, I meant that it was code. > > > Couldn't you do that with a table > > containing those fields, and key it off the defskill argument (or even the > > title?) at startup? > > Not the code. In reverse. > > > Then you don't have to worry about re-factoring the > > code: there's only going to be one piece of code, driven by a table. > > What if it turns into an SQL lookup during refactoring? > > > > > I only mentioned interpolation because it seemed likely that you might > > want to be mutating these strings to be more specific to what your student > > was actually doing. > > Interpolation does not mean what you think it means. :) That's OK, I > figgered it out. Yes, that is what the program does, it substitutes > terms from the student's problem to produce a hint or annotation. The > function is called "expand". Because the text is like a macro. :) > > > I didn't expect that "42" was necessarily the right > > answer... > > No, but it so happens any #STR...# token is a literal bit of math > encoded as an ascii string. That gets translated to proper math notation > (by which I mean, what you would see in tex output). During template > conversion. So this hint is just saying to the kid, "Dude, |-42|=42, > |42|=42, get over it." > > > > > To back out a bit, here, and get back to the meat of the matter: if one is > > using Python, then it's because one doesn't much care about performance, > > I'll try again: this has nothing to do with performance. > > > and it's reasonable to do expansions, pattern matching and domain specific > > language creation/use at run-time. After all, that's how the language > > itself works, mostly. > > The last example showed the macro inserting code to magically produce a > binding inside the reverse function. It would be easier to compare and > contrast with the Python equivalent if someone had posted such, but your > troops have fallen back to Fort So What? and pulled up the drawbridge. > > Peace. Out. Ken >
I think this specific sub-thread is a great example of what a lot of people roll their eyes about when Lispers start talking, and it's a great contrast to the foot stomping earlier where all the Lispers were swearing that macros didn't complicate anything. You start out with a fairly simple task, and use a macro instead of a function even though you don't need to. That's "Arguments against LISP 101" right there. Then, you're (by your own indication - I find the lisp code unreadably idiomatic) overly clever and spend several iterations walking around in circles making your macro more clever, rather than fixing your problem (spending too much time creating clever genericness is a trap I'm sure many programmers have fallen in, I've done it myself, but I have a feeling that Lispers are more susceptible than most). You finally have your macro doing all the cleverness you need, and (again by your own account, I can't judge the code on any merit other than "this looks like garbage to me") it's getting nasty and contrived. So you went from "look how simple and powerful this macro is", in a trivial case that didn't even need a macro to "well, it's ugly and nasty and idiomatic, but look how powerful this macro is!". This is exactly the sort of thing that I (and, in my experience, many Python programmers) strive to avoid in our work, and the readability and clarity (more than simple character counts) of Python is a tool that helps me achieve this goal. I'd produce an equivalent Python version, but since you're totally unclear in why you're adding these changes, and I can't read the lisp well enough to see what it's doing, you're going to have to back up a few steps if you want a Python implementation of your final solution. I expect, however, that I wouldn't use a function at all = I'd make it a data driven solution, because it (seems to be) a data oriented problem. > -- > Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm > > "Well, I've wrestled with reality for thirty-five > years, Doctor, and I'm happy to state I finally > won out over it." -- Elwood P. Dowd > > "I'll say I'm losing my grip, and it feels terrific." > -- Smiling husband to scowling wife, New Yorker cartoon > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
